Lossless path switching involving sidelink relays

Abstract

In response to a trigger of an inter-gNB path switch for a remote UE having an indirect connection to a gNB (56) via a relay UE, a CU-UP entity (72) of the gNB (56) receives an indication from a CU-CP entity (72) of the gNB (56). In response to the indication, the CU-UP entity (72) buffers packets for the remote UE.

Description

Technical Field

[0001] This disclosure relates to methods for controlling the operation of wireless communication networks, as well as corresponding devices, systems, and computer programs. Background Technology

[0002] In wireless communication networks such as those defined by 3GPP (3rd Generation Partnership Project), a mode of providing direct wireless communication between user equipment (UEs) is known. For example, this direct communication mode is supported for 4G (4th generation) LTE (Long Term Evolution) technology and 5G (5th generation) NR (New Radio) technology.

[0003] Side link

[0004] 3GPP specified LTE D2D (Device-to-Device) technology, also known as sidelink (SL) or PC5 interface, as part of Release 12 (Rel-12). The target use case (UC) is proximity service (communication and discovery). Support for such services was enhanced in Rel-13 and Rel-14, with the LTE sidelink being extensively redesigned to support vehicle-to-vehicle communication, commonly referred to as V2X (“Vehicle-to-Everything” or V2V (Vehicle-to-Vehicle)). Further enhancements were made in Release 15 (Rel-15) from a lower radio layer perspective. LTE SL uses broadcast communication, meaning that transmissions from the UE are targeted at any receiver within range.

[0005] In Release 16 (Rel-16), 3GPP introduced sidelinks for 5G NR. The driving use case is vehicle communication, which has more stringent requirements than what LTE SL can typically serve. To meet these stringent requirements, NR SL can perform broadcast, multicast, and unicast communication. In multicast communication, the intended receivers of the message are typically a subset of vehicles near the transmitter, while in unicast communication, there is only a single intended receiver.

[0006] Both LTE SL and NR SL can operate with and without network coverage, and the degree of interaction between the UE and the NW (network) differs, including support for independent network-free operation.

[0007] In 3GPP Release 17 (Rel-17), public safety is one of the most important use cases, which can benefit from the NR sidelink features already developed in Rel.16. Therefore, 3GPP has specified enhancements related to public safety use cases, based on NR Rel-16 SL. Furthermore, in some scenarios, public safety services need to operate with partial or no NW coverage, such as during indoor firefighting, forest firefighting, earthquake rescue, and maritime rescue, where infrastructure is (partially) destroyed or unavailable. Therefore, coverage extension is a key enabler for both services communicating between the UE and cellular NW and services communicating between UEs via SL.

[0008] Rel-17 introduced a Study Item Description (SID) for NR sidelink relay (see 3GPP document RP-193253), which aims to further explore coverage extensions for sidelink-based communications, including both UE-to-NW relays for cellular coverage extensions and UE-to-UE relays for sidelink coverage extensions. Currently, in the relevant Work Item Description (WID) (see 3GPP document RP-213585, 3GPP meeting RAN#94-e), only UE-to-NW relays are considered for Rel-17. With the exception of public safety applications, NR sidelink relays (WIs) are also designed to support other commercial use cases that will also benefit from coverage extensions. Two solutions for UE-to-NW relays are specified: Layer 2 (L2) UE-to-NW (U2N) relays and Layer 3 (L3) U2N relays.

[0009] As seen in 3GPP document R-213585, discussions were initiated in RAN#94 to identify the detailed motivations and areas of work for the evolution of NR SL and NR SL trunks in Rel-18. For NR SL trunks, consensus was reached on the remaining topics regarding service continuity for L2 trunks, including the introduction of support for indirect-to-indirect path handovers. Furthermore, the restriction in Rel-17 that service continuity was limited to intra-gNB scenarios was removed in Rel-18. Rel-18 should also introduce support for inter-gNB scenarios involving path handovers between direct and indirect paths.

[0010] Layer 2 UE to network relay

[0011] 3GPP TR 23.752 V17.0.0 (2021-03) and 3GPP TS 38.300 V17.5.0 (2023-06) further describe L2-based UE-to-network (U2N) relay.

[0012] Figure 1The protocol stack for user plane transport associated with a PDU session is shown, including Layer 2 UE to network relay UE. The PDU layer corresponds to the PDU carried between the remote UE and the data network (DN) via the PDU session. It is important to note that the two endpoints of the PDCP link are the remote UE and the gNB (i.e., the base station for NR technology). The relay function is performed under PDCP. This means that data security is ensured between the remote UE and the gNB without exposing the original data at the UE to network relay UE level.

[0013] The UE-to-network relay UE adaptation layer can distinguish between signaling radio bearers (SRBs) and data radio bearers (DRBs) for a specific remote UE. The adaptation relay layer is also responsible for mapping PC5 services to one or more DRBs of the Uu.

[0014] Figure 2 The protocol stack for NAS (Non-Access Stratum) connections between remote UEs and NAS-MM (NAS Mobility Management) and NAS-SM (NAS Session Management) components is illustrated. NAS messages are transparently transmitted between the remote UE and the 5G-AN via a Layer 2 UE-to-Network Relay UE. The role of the UE-to-Network Relay UE is to relay PDUs from signaling radio bearers without any modifications.

[0015] Path switching process

[0016] Rel-17 only supports intra-gNB path switching between indirect and direct paths.

[0017] Figure 3 The intra-gNB path handover process from indirect to direct path is illustrated, including the associated RRC (Radio Resource Control) signaling:

[0018] Step 1: Measurement configuration and reporting.

[0019] Step 2: The gNB decides to switch to a direct path.

[0020] Step 3: RRC reconfiguration message to the remote UE.

[0021] Step 4: The remote UE performs random access to the gNB.

[0022] Step 5: The remote UE uses the target configuration provided in the RRC reconfiguration message to send RRCReconfigurationComplete (RRC reconfiguration complete) back to the gNB via the target path.

[0023] Step 6: Reconfigure the RRC of the relay UE.

[0024] Step 7: If necessary, release the PC5 link between the remote UE and the relay UE.

[0025] Step 8: The data path is switched.

[0026] It is important to note here that the order of steps 6 / 7 / 8 is not restricted.

[0027] Further issues to be discussed during the WI (Work Item) phase include:

[0028] - After step 3, should the remote UE suspend data transmission via the relay link?

[0029] - Whether step 6 can be before or after step 3, and its necessity;

[0030] - Whether step 7 can follow step 3 or step 5, and its necessity / whether it can be replaced by PC5 reconfiguration;

[0031] - Can step 8 be performed after step 5?

[0032] Figure 4 This illustrates the intra-gNB path switching process from a direct path to an indirect path:

[0033] Step 1: After the remote UE measures / discovers candidate relay UEs, the remote UE reports one or more candidate relay UEs.

[0034] - In step 1, the remote UE can filter appropriate relay UEs that meet higher-level criteria when reporting.

[0035] - The report may include the relay UE's ID (identifier) ​​and SL RSRP (reference signal received power) information, where the measurement of PC5 details in step 1 can be left to the WI stage.

[0036] Step 2: The gNB decides to switch to the target relay UE, and the target (re)configuration is optionally sent to the relay UE (like preparation).

[0037] Step 3: RRC reconfiguration message to the remote UE. This may include the following information: 1) Identifier of the target relay UE; 2) Target Uu and PC5 configuration.

[0038] Step 4: If no connection has been established yet, the remote UE establishes a PC5 connection with the target relay UE.

[0039] Step 5: The remote UE uses the target configuration provided in RRC Reconfiguration to send back RRC ReconfigurationComplete to the gNB via the target path.

[0040] Step 6: The data path is switched.

[0041] Further issues to be discussed in the WI phase include:

[0042] - Should step 2 be performed after the relay UE connects to the gNB (e.g., after step 4), or before if not?

[0043] - Can step 4 be performed before steps 2 / 3?

[0044] SDU discarded

[0045] According to 3GPP TS 38.323 V17.5.0 (2023-06), the discarding of SDUs (Service Data Units) at the PDCP (Packet Data Convergence Protocol) layer is organized as follows:

[0046] When the timer designated as discardTimer expires for a PDCP SDU, or when a PDCP status report confirms the successful delivery of the PDCP SDU, the sending PDCP entity should discard the PDCP SDU and its corresponding PDCP data PDU. If the corresponding PDCP data PDU has already been submitted to a lower layer, the entity should indicate to the lower layer that it should discard the SDU.

[0047] For SRB, when the upper layer requests the PDCP SDU to be discarded, the PDCP entity should discard all stored PDCP SDUs and PDCP PDUs.

[0048] It's important to note that discarding a PDCP SDU already associated with a PDCP SN will cause SN gaps in the transmitted PDCP data PDUs, which will increase PDCP reordering latency in the received PDCP entity. How to minimize the SN gaps after SDU discarding depends on the UE implementation.

[0049] E1AP

[0050] In current 3GPP networks, a distributed architecture can be used for NW nodes. For example, a gNB can be implemented based on a CU (Central Unit or Centralized Unit) and one or more DUs (Distributed Units). In addition, the functions of the CP (Control Plane) and UP (User Plane) can be distributed to different network nodes.

[0051] For example, the E1 Application Protocol (E1AP) specified in 3GPP 37.483 V17.6.0 (2023-09) provides signaling services between gNB-CU-CP and gNB-CU-UP of gNBs in the NG-RAN in a separated architecture, or between gNB-CU-CP and gNB-CU-UP of en-gNBs in the E-UTRAN (Evolved UMTS Terrestrial Radio Access Network). The services provided by E1AP are divided into UE-related and non-UE-related services.

[0052] Figure 5 The interface protocol structure for E1 is shown. TNL is based on IP transport, including SCTP over IP. The application layer signaling protocol corresponds to E1AP.

[0053] Downlink data delivery status

[0054] Downlink Data Delivery Status (DDDS) is a process used to convey information about the successful or unsuccessful delivery of data from the network to the UE. Its purpose is to provide feedback from the corresponding node to the node hosting the NR PDCP entity, allowing the node hosting the NR PDCP entity to control the downlink (DL) user data flow for the corresponding data radio bearer via the corresponding node. The corresponding node can also transmit the uplink (UL) user data of the relevant data radio bearer along with a DL DATA DELIVERY STATUS frame within the same GTP-U PDU (GPRS Tunneling Protocol Packet Data Unit) to the node hosting the NR PDCP entity.

[0055] The DDDS process is also used to provide feedback from the corresponding node to the node hosting the NR PDCP entity, allowing the node hosting the NR PDCP entity to control the successful delivery of DL control data to the corresponding node. Figure 6 An example of a successful DDDS is shown.

[0056] Several challenges exist. In Rel-17, as mentioned above, support for L2 U2N relays is introduced, where a remote UE can seek assistance from a neighboring relay UE to access the network; this is referred to as an indirect path. Service continuity aspects are also introduced, where a remote UE can continue its ongoing service while switching between direct (Uu) and indirect paths via a relay UE. The protocol stack for Rel-17 L2 U2N relays features end-to-end PDCP termination (i.e., between the remote UE and the network (gNB)) and hop-by-hop RLC (Radio Link Control) termination.

[0057] Therefore, in DL transmission, successful packet transmission from the gNB to the relay UE via the Uu link does not guarantee successful packet transmission via the PC5 link between the relay UE and the remote UE. The same applies to UL transmission, where successful transmission on the PC5 link does not guarantee successful transmission on the Uu link. From a protocol stack perspective, although PDCP is E2E (end-to-end), there is no feedback mechanism at the PDCP layer. Only lower layers (such as RLC) have feedback / retransmission mechanisms. Therefore, the feedback mechanism is hop-by-hop.

[0058] In non-relay scenarios, i.e., when the UE is connected to the network via a direct (Uu) link, the packet processing behavior at the PDCP layer in DL is that if an ACK (acknowledgment) is received from a lower layer, the corresponding packet is discarded. Similarly, in UL, the packet processing behavior is that the corresponding packet is discarded when the discard timer expires, or when the PDCP status report confirms successful packet delivery, or when a lower layer acknowledgment is successful. Therefore, no problems are expected in non-relay scenarios. The PDCP status of a packet is based on the assigned sequence number and buffer window, which will be aligned between the transmitter and receiver (i.e., gNB and UE).

[0059] However, in relay scenarios, due to the lack of E2E feedback, packets may be dropped prematurely (e.g., based on a successful transmission on the first hop, even though the packet may fail on the second hop) or stored for longer than necessary (potentially causing buffer overload). This is exacerbated during path handover scenarios, where the path switches from an indirect path to a direct / other indirect path. In such scenarios, misalignment of the UE and gNB PDCP states can lead to data loss and service interruption during the path handover process.

[0060] In Rel-17, this type of data loss was considered an extreme case. Since only intra-gNB scenarios were supported, PDCP status could be easily maintained when the path switch occurred within the same gNB. However, in Rel-18, inter-gNB scenarios should also be supported, as the data loss problem becomes more pronounced when switching between two different gNBs.

[0061] To prevent data loss due to premature packet dropping, networks can set longer discard times or wait for PDCP status reports before dropping packets. However, in both methods, even if the E2E transmission is successful, packets will be buffered for longer than necessary. Furthermore, while indicators such as DDDS exist to help the network understand the status of downlink data delivery, these indicators do not provide E2E status. Therefore, although packet transmission may succeed on the first hop, the associated DDDS does not provide the network with any information about the transmission on the second hop.

[0062] Therefore, a technology is needed that can effectively handle path switching in U2N relay scenarios. Summary of the Invention

[0063] Certain aspects and example embodiments of this disclosure can provide solutions to these or other challenges. One aspect is a solution to prevent data loss during path switching scenarios by preventing premature discarding. Furthermore, this solution can also help prevent packets from being stored for excessively long periods.

[0064] According to an embodiment, a method is provided performed by a gNB, which operates as a network node in a wireless communication network. According to the method, in response to the triggering of an inter-gNB path handover for a remote UE having an indirect connection to the gNB via a relay UE, the CU-UP entity of the gNB receives an indication from the CU-CP entity of the gNB. In response to the indication, the CU-UP entity buffers packets for the remote UE.

[0065] According to another embodiment, a method is provided performed by a gNB, which operates as a network node in a wireless communication network. According to the method, in response to the triggering of an inter-gNB path handover for a remote UE having an indirect connection to the gNB via a relay UE, the CU-CP entity of the gNB provides an indication to the CU-UP entity of the gNB. The indication causes the CU-UP entity to buffer packets for the remote UE.

[0066] According to another embodiment, a network node is provided. The network node is configured to perform operations of a gNB (gneighborhood network) in a wireless communication network. These operations include: in response to a triggering of an inter-gNB path handover for a remote UE having an indirect connection to the gNB via a relay UE, the CU-UP entity of the gNB receives an indication from the CU-CP entity of the gNB. Furthermore, these operations include: in response to the indication, the CU-UP entity buffers packets for the remote UE.

[0067] According to another embodiment, a network node is provided. The network node includes processing circuitry and a power supply circuitry configured to power the processing circuitry. The processing circuitry is configured to perform operations of a gNB (gneighborhood network) in a wireless communication network. These operations include: in response to a triggering of an inter-gNB path handover for a remote UE having an indirect connection to the gNB via a relay UE, the CU-UP entity of the gNB receives an indication from the CU-CP entity of the gNB. Furthermore, these operations include: in response to the indication, the CU-UP entity buffers packets for the remote UE.

[0068] According to another embodiment, a network node is provided. The network node is configured to perform operations of a gNB (gnB) in a wireless communication network. These operations include: in response to a triggering of an inter-gNB path handover for a remote UE having an indirect connection to the gNB via a relay UE, the CU-CP (CU-CP entity) of the gNB provides an indication to a CU-UP (CU-UP entity) of the gNB. The indication causes the CU-UP entity to buffer packets for the remote UE.

[0069] According to another embodiment, a network node is provided. The network node includes processing circuitry and power supply circuitry configured to power the processing circuitry. The processing circuitry is configured to perform operations of a gNB (gear network) in a wireless communication network. These operations include: in response to a triggering of an inter-gNB path handover for a remote UE having an indirect connection to the gNB via a relay UE, the CU-CP (Curricular Component Provider) entity of the gNB provides an indication to a CU-UP (Curricular Component Provider) entity of the gNB. The indication causes the CU-UP entity to buffer packets for the remote UE.

[0070] According to another embodiment, a computer program or computer program product is provided, for example, in the form of a non-transient storage medium, comprising program code executable by processing circuitry of a network node for a communication network. The program code may be stored in the memory of the network node. Execution of the program code causes the network node to perform operations of a gNB (gear network node) in a wireless communication network. These operations include: in response to a triggering of an inter-gNB path handover for a remote UE having an indirect connection to the gNB via a relay UE, the CU-UP entity of the gNB receives an indication from the CU-CP entity of the gNB. Furthermore, these operations include: in response to the indication, the CU-UP entity buffers packets for the remote UE.

[0071] According to another embodiment, a computer program or computer program product is provided, for example, in the form of a non-transient storage medium, comprising program code executable by processing circuitry of a network node for a communication network. The program code may be stored in the memory of the network node. Execution of the program code causes the network node to perform operations of a gNB (gear network node) in a wireless communication network. These operations include: in response to a triggering of an inter-gNB path handover for a remote UE having an indirect connection to the gNB via a relay UE, the CU-CP (Curricular Component Provider) entity of the gNB provides an indication to the CU-UP (Curricular Component Provider) entity of the gNB. The indication causes the CU-UP entity to buffer packets for the remote UE.

[0072] The details of these and other embodiments will become apparent from the following detailed description of the embodiments. Attached Figure Description

[0073] Figure 1 The UP stack used for L2 U2N relay is shown.

[0074] Figure 2 The CP stack for L2 U2N relay is shown.

[0075] Figure 3 The intra-gNB path handover process is illustrated, which involves switching from an indirect connection to a direct connection for the UE.

[0076] Figure 4 The intra-gNB path handover process is illustrated, which involves switching from a direct connection to an indirect connection for the UE.

[0077] Figure 5 The interface protocol structure of the E1 interface is shown.

[0078] Figure 6 An example of a successful DDDS process is shown.

[0079] Figure 7 An example of a U2N relay scenario according to an embodiment is illustrated schematically.

[0080] Figure 8 Details of a network node according to an embodiment are schematically shown.

[0081] Figure 9 Details of the processing circuitry of a network node according to an embodiment are schematically shown.

[0082] Figure 10 An example of a wireless communication network architecture according to an embodiment is illustrated schematically.

[0083] Figure 11 An example of a gNB architecture according to an embodiment is illustrated schematically.

[0084] Figure 12 A flowchart illustrating a method according to an embodiment is shown.

[0085] Figure 13 A flowchart illustrating a method according to an embodiment is shown.

[0086] Figure 14 An example of a communication system according to an embodiment is illustrated schematically.

[0087] Figure 15 An example of a UE according to an embodiment is illustrated schematically.

[0088] Figure 16 An example of a network node according to an embodiment is illustrated schematically.

[0089] Figure 17An example of a host according to an embodiment is illustrated schematically.

[0090] Figure 18 An example of a virtualized environment according to an embodiment is illustrated schematically. Detailed Implementation

[0091] In the following, the concepts according to exemplary embodiments of the present invention will be explained in more detail with reference to the accompanying drawings. The illustrated embodiments relate to the processing of path switching in a U2N relay scenario.

[0092] One or more solution implementations introduce a new indication from gNB-CU-CP to gNB-CU-UP, such as an indication that can be sent via the E1 interface, to indicate the triggering of a path handover procedure for the UE. Furthermore, using this new indication, gNB-CU-UP can begin buffering packets at the source gNB. All packets are then forwarded to the target gNB, or, by exchanging PDCP status reports, the source gNB can forward only those packets that were not successfully received at the UE.

[0093] Certain embodiments may provide one or more of the following technical advantages. The aforementioned instruction helps the source gNB buffer packets only when necessary, which helps prevent buffer overload. The instruction also helps prevent premature packet dropping that could lead to data loss and disruption during path switching scenarios.

[0094] Some embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Examples are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0095] The embodiments described herein are in the context of NR, i.e., two or more SL UEs are deployed in the same or different NR cells. However, the same principles can be applied to LTE or any other technology capable of enabling direct connections between two (or more) nearby devices. The embodiments are also applicable to relay scenarios including UE-to-network relay and / or UE-to-UE relay, where the remote UE and the relay UE can be based on an LTE sidelink or an NR sidelink, and the Uu connection between the relay UE and the base station can be LTE Uu or NR Uu. The embodiments are applicable to L2-based U2N relay scenarios.

[0096] In the following description, the term "direct link / connection" refers to the link / connection between the (remote) UE and the base station (gNB) via the Uu (NR / LTE) interface. The term "indirect link / connection" refers to the link / connection between the (remote) UE and the base station (gNB) via a relay UE, i.e., the connection / link between the (remote) UE and the relay UE is via the PC5 interface, and the connection / link between the relay UE and the base station is via the Uu interface.

[0097] The embodiments described reflect the perspectives of the (remote) UE, the relay UE, the source gNB, and the target gNB. The (remote) UE is initially under the coverage of the source gNB, and then performs a path handover to the target gNB.

[0098] The source / target gNB may include multiple cells that the (remote) UE can see. For simplicity, the following description is written as follows: the (remote) UE performs a handover (HO) or path handover from a cell in the source gNB to a cell in the target gNB. Therefore, in the following description, the terms "cell" and "gNB" are used interchangeably, but such interchangeability of terms does not imply limitation on the disclosed technology.

[0099] In the first embodiment, upon receiving a measurement report containing measurement results for initiating a path handover procedure from a remote UE, the control plane (CP) (e.g., CU-CP) of the gNB sends an instruction to the corresponding user plane (UP) (e.g., CU-UP) regarding the initiation of the path handover procedure for the remote UE. The interface between the gNB-CU or the gNB's CP and the gNB-CU or the gNB's UP can be via E1, i.e., the E1 interface.

[0100] In the second embodiment (which may be an extension of the operation in the first embodiment), upon receiving the instruction, the gNB-CU or the UP of the gNB begins to buffer even those packets that have been successfully transmitted on the first hop (i.e., the Uu link).

[0101] In the third embodiment (which may be a further extension of the above operation), upon receiving the instruction, the gNB-CU or the UP of the gNB will discard the packet from the buffer without considering the successful acknowledgment or downlink data delivery status (DDDS) received from the lower layer of the UP protocol stack.

[0102] In the fourth embodiment, the UP of gNB-CU or gNB continues to buffer packets based on instructions from the CP of gNB-CU or gNB until it:

[0103] - Receive another instruction from gNB-CU or gNB CP to stop buffering;

[0104] - Received an instruction to forward all buffered packets to date to another gNB's UP; or

[0105] - Received a PDCP status report from the UP of another gNB.

[0106] In the fifth embodiment, the indication from the gNB-CU or the CP of the gNB includes a timer that notifies the UP of the gNB how long the packets need to be buffered.

[0107] In the sixth embodiment, the CU-UP starts a timer after receiving the DDDS and determines how long it needs to buffer packets. After the timer expires, the CU-UP discards all buffered packets.

[0108] In the seventh embodiment, in the event of an unsuccessful path switching process, the CP of the gNB instructs the UP of the gNB to discard all buffered packets.

[0109] Therefore, in the example scenario, the remote UE operates in an L2-based U2N relay scenario, where it has an indirect connection to a first gNB. The relay UE supports indirect connections, where the first connection hops between the gNB and the relay UE, and the second connection hops between the relay UE and the remote UE. For the path handover process (handover) from the remote UE to the second gNB, the first gNB can be referred to as the "source" gNB, and the second gNB can be referred to as the "target" gNB.

[0110] In the example embodiment of the solution discussed herein, the central unit control plane (CU-CP) of the source gNB provides an indication of initiating the path switching process to the CU user plane (CU-UP) of the source gNB. As a specific example, the source gNB CU-CP sends the path switching indication to the source gNB CU-UP via the E1 interface between the source gNB CU-CP and the source gNB CU-UP.

[0111] The source gNB CU-UP responds to this indication by buffering those packets that have already been successfully transmitted even on the first hop (i.e., on the Uu link between the source gNB and the relay UE). Therefore, the path switching indication sent by the CU-CP to the CU-UP can also be understood as a buffer initiation indication.

[0112] In at least one embodiment, the source gNB CU-UP modifies its normal packet dropping behavior in response to receiving an indication. For example, even though it receives a transport ACK or DDDS from a lower layer of its protocol stack, it does not drop the corresponding packet from its buffer.

[0113] In one or more embodiments, the source gNB CU-UP continues to buffer packets for the UE until it receives any one or more of the following: (a) a stop buffering instruction from the source gNB CU-CP; (b) an instruction to forward all packets buffered for the UE to another gNB (e.g., the target gNB); or (c) a PDCP status report from the CU-CP of another gNB (e.g., the target gNB).

[0114] In at least one embodiment, the path switching indication provided by the source gNB CU-CP to the source gNB CU-UP includes a timer indicating how long the source gNB CU-UP should buffer packets. Here, saying that the path switching indication includes a timer means, for example, that the indication includes a value or other data item indicating the timer's expiration period, wherein the CU-UP configures and starts a timer / counter with the indicated expiration period. Optionally, the CU-UP determines the buffering duration and configures the expiration timer accordingly. In either approach, the CU-UP discards the buffered packets when the timer expires, where this behavior is an example of advantageously preventing or mitigating buffer overflow problems at the CU-CP.

[0115] Furthermore, in at least one embodiment, the source gNB CU-CP is configured to provide an indication to the source gNB CU-UP that the path handover process for the UE was unsuccessful, wherein the CU-UP is configured to discard buffered packets in response to the indication.

[0116] Figure 7 An example scenario is shown, in which network node 12 is communicatively coupled to remote UE 14 via connection 16.

[0117] Connection 16 includes a first-hop link 18 between network node 12 and relay UE 20, and a second-hop link 22 between relay UE 20 and remote UE 14. Remote UE 14 operates in an L2-based U2N relay scenario targeting network node 12, where network node 12 includes, for example, an access point of a cellular network. In a particular example, network node 12 is an eNB of an LTE network; in another example, network node 12 is a gNB of an NR 5G network.

[0118] exist Figure 7 The example embodiments described in the context relate to a path switching scenario where the connection path of a remote UE 14 switches from network node 12, which is a first or source node, to another network node 24, which is a second or target node. Network node 24 may be of the same type as network node 12 or may be of a different type. In at least one example, network node 12 is a first gNB or source gNB of a wireless communication network operating according to the 5G specifications issued by 3GPP, and network node 24 is a second gNB or target gNB.

[0119] Figure 8 Example details of network nodes 12 or 24 are shown.

[0120] The depicted node includes processing circuitry 30, radio communication circuitry 32, and network (NW) interface circuitry 34. Processing circuitry 30 is configured to perform overall control of the node and to perform communication processing of downlink (DL) and uplink (DL) data, while radio communication circuitry 32 includes one or more radio transmitters and receivers (radio frequency (RF) transceiver circuits) configured to transmit DL data and control signals according to defined air interface protocols, and to receive UL data and control signals according to these protocols.

[0121] Network node 12 or 24 uses radio communication circuitry 32, for example, to provide communication service coverage in one or more cells, while simultaneously using network interface circuitry 34 to communicate with other nodes in the cellular network (e.g., other radio access network (RAN) nodes or nodes in the core network (CN) of the cellular network). In this regard, network interface circuitry 34 may include more than one interface, or may support multiple signaling schemes or types, and it provides wired or wireless physical layer connectivity, as well as any associated timing and protocol processing, for anchoring network connections to other nodes.

[0122] The processing circuit 30 includes fixed circuitry or programmed circuitry, or a combination of both. Figure 9 An example is shown in which processing circuitry 30 includes one or more microprocessors 40 specifically adapted to perform output operations implementing one or more solutions described herein based on the execution of computer program instructions 42 stored in memory 44, which is included in or otherwise connected to the microprocessor 40. Here, "microprocessor" has a broad meaning, including microcontrollers, digital signal processors, etc.

[0123] Memory 44 may also contain one or more types of data 46, such as persistent data and / or dynamic data created and processed during live operation, such as provisioning information and configuration parameters. Memory 44 includes one or more types of computer-readable media and may include a mixture of working memory for live operation and program memory for long-term storage of instructions and persistent data. Examples include any one or more DRAMs, SRAMs, FLASH, EEPROMs, solid-state drives (SSDs), etc.

[0124] Figure 10An example wireless communication network 50 is illustrated, drawn within an example context of 5G New Radio (NR). In this example, network 50 includes a 5G core network (5GC) 52 and a Next Generation (NG) Radio Access Network (RAN) 54. RAN 54 includes one or more gNBs 56, as an example of the network node 12 described above. Here, two gNBs 56-1 and 56-2 are shown by way of example, configured as described above to perform the operations described in the context of path handover in an L2-based U2N relay scenario.

[0125] For example, each gNB 56 includes a gNB central unit (gNB-CU) 60 and one or more gNB distributed units (gNB-DU) 62, which are connected to the CU via an F1 interface.

[0126] The gNB-CU 60 provides overall processing and control as well as a network interface, while the gNB-DU 62 includes a radio interface. The gNB-CU 60 supports the Xn-C interface for inter-gNB communication.

[0127] Figure 11 The functional or logical entities in gNB 56 are shown, where such entities are implemented, for example, via underlying processing circuitry and memory.

[0128] gNB-CU-CP 70 is configured to handle control plane (CP) operations, while one or more instantiations of gNB-CU-UP 72 handle user plane (UP) operations. gNB-DU 62 has an F1-C interface to CU-CP 70 and an F1-U interface to CU-UP 72. CU-CP 70 has an E1 interface to CU-UP 72, which, in one or more example embodiments, it uses to provide the aforementioned path handover indications and related information for advantageous buffered control of packets associated with L2-relay-connected UEs undergoing inter-gNB path handover.

[0129] This operation can be understood as the gNB or other network nodes providing lossless path switching in the downlink direction for UEs indirectly connected to the network via sidelink relay connections. In other words, advantageous buffering prevents the loss of downlink packets for remote UEs by buffering packets at the source network node, including packets indicated as successfully transmitted on the first hop of the relay-based indirect connection for the remote UE. Furthermore, by providing timer-controlled retention of these buffered packets at the source network node and / or providing other drop triggers, buffered packets are not held indefinitely or unnecessarily at the source network node, thereby reducing buffer overflows that may result from such retention.

[0130] Figure 12 A flowchart illustrating a method for implementing the illustrated concepts in a network node performing gNB operations, specifically the operation of the gNB's CU-UP entities, such as one of the CU-UP entities 72 described above. This method can be used to implement the aforementioned functionalities in conjunction with path switching in a U2N relay scenario.

[0131] If a processor-based implementation of the network node is used, then Figure 12 At least some steps of the method can be executed and / or controlled by one or more processors of the network node. Such one or more processors can implement the processing circuitry of the network node. Such a network node may also include memory for storing program code for implementation. Figure 12 The method includes at least some of the following functions or steps.

[0132] In step 1210, in response to a triggering of an inter-gNB path handover for a remote UE having an indirect connection to the gNB via a relay UE, the gNB's CU-UP entity receives an indication from the gNB's CU-CP entity (e.g., CU-CP entity 70 mentioned above). In some scenarios, the CU-UP entity may receive the indication via an E1 interface. The inter-gNB path handover may involve a target gNB. The remote UE may correspond to the remote UE 14 mentioned above, the relay UE may correspond to the relay UE 20 mentioned above, and the gNB may correspond to the network node 12 mentioned above. The gNB may be implemented based on a distributed architecture, for example, as combined with Figure 10 and Figure 11 The explanation given.

[0133] In some scenarios, the CU-UP entity can start a timer in response to receiving an instruction. This instruction can include timer settings, such as the timer's start value.

[0134] In step 1220, in response to the instruction in step 1210, the CU-UP entity is a remote UE buffer packet.

[0135] Buffering packets for the remote UE in step 1220 may involve modifying the packet dropping behavior of the CU-UP entity so that the CU-UP entity does not drop those packets held in its buffer for the remote UE in response to an indication of successful transmission of packets held in its buffer for the remote UE to the relay UE. These indications of successful transmission may be provided, for example, via DDDS information and / or may include lower-level protocol acknowledgments from the CU-UP entity.

[0136] In some scenarios, buffering packets for the remote UE in step 1220 may include packets that retain the gNB’s indication that it has successfully transmitted to the relay UE.

[0137] In some scenarios, the CU-UP entity can responsively discard packets that are buffered by the remote UE in response to the expiration of a timer started in response to a received indication.

[0138] In some scenarios, the CU-UP entity can determine the duration of the buffer.

[0139] In some scenarios, a CU-UP entity may discard packets that are buffered for remote UEs in response to the earlier of the following events: timer expiration or the occurrence of a discard trigger.

[0140] In some scenarios, the drop trigger can be one or more of the following: receiving a drop instruction from a CU-CP entity, or receiving a PDCP status report from a target gNB for a remote UE.

[0141] In some scenarios, a CU-UP entity may discard packets that have been forwarded to another gNB as a remote UE buffer, or in response to receiving a PDCP report from another gNB (e.g., from the target gNB of a path handover).

[0142] In some scenarios, in response to reaching the time limit defined for the buffer, the CU-UP entity may discard packets that are buffered for remote UEs.

[0143] If the inter-gNB path handover involves the target gNB, the method may continue to step 1230, which involves the subsequent forwarding of packets to the target gNB as a remote UE buffer.

[0144] Figure 13 A flowchart illustrating a method for implementing the illustrated concepts, particularly the operation of the gNB's CU-CP entity (e.g., CU-CP entity 70 described above), within a network node performing gNB operations. This method can be used to implement the aforementioned functionalities in conjunction with path switching in a U2N relay scenario.

[0145] If a processor-based implementation of the network node is used, then Figure 13 At least some steps of the method can be executed and / or controlled by one or more processors of the network node. Such one or more processors can implement the processing circuitry of the network node. Such a network node may also include memory for storing program code for implementation. Figure 13 The method includes at least some of the following functions or steps.

[0146] In step 1310, an inter-gNB path handover is triggered for a remote UE with an indirect connection to the gNB via a relay UE. The inter-gNB path handover can be triggered by the CU-CP entity of the gNB, or the CU-CP entity of the gNB can be aware of the path handover triggering in other ways.

[0147] In step 1320, in response to the triggering of an inter-gNB path handover for a remote UE, the gNB's CU-CP entity provides an indication to the gNB's CU-UP entity, for example, to one or more of the aforementioned CU-UP entities 72. The remote UE may correspond to the aforementioned remote UE 14, the relay UE may correspond to the aforementioned relay UE 20, and the gNB may correspond to the aforementioned network node 12. The gNB may be implemented based on a distributed architecture, for example, as combined with... Figure 10 and Figure 11 The explanation given.

[0148] This instruction causes the CU-UP entity to buffer packets for the remote UE. The CU-CP entity can provide the instruction via the E1 interface.

[0149] Buffering packets for a remote UE may involve modifying the packet dropping behavior of the CU-UP entity so that the CU-UP entity does not drop those packets held in its buffer for the remote UE in response to an indication of successful transmission of packets held in its buffer for the remote UE to the relay UE. The indication of successful transmission may be provided via DDDS information or may include a lower protocol level acknowledgment from the CU-UP entity. Buffering packets for a remote UE may include retaining packets that the gNB has indicated to it that it has received a successful transmission to the relay UE. If an inter-gNB path handover involves a target gNB, buffering may involve, or subsequently, packets forwarded to the target gNB for buffering as a remote UE.

[0150] Figure 14 An example of a communication system 1400 according to some embodiments is shown.

[0151] In this example, communication system 1400 includes telecommunications network 1402, which includes access network 1404 (such as a radio access network (RAN)) and core network 1406, which includes one or more core network nodes 1408. Access network 1404 includes one or more access network nodes, such as network nodes 1410a and 1410b (one or more of which may generally be referred to as network node 1410), or any other similar 3GPP access node or non-3GPP access point. Furthermore, as those skilled in the art will understand, network nodes are not necessarily limited to implementations in which the radio and baseband portions are provided and integrated by a single vendor. Therefore, it is understood that network nodes include decomposed implementations or portions thereof. For example, in some embodiments, telecommunications network 1402 includes one or more Open RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunications network 1402 that supports ORAN specifications (e.g., specifications published by the O-RAN Alliance or any similar organization) and can operate alone or together with other nodes to perform one or more functions of any node in the telecommunications network 1402 (including one or more network nodes 1410 and / or core network node 1408).

[0152] One or more of network nodes 1410 can be configured as network node 12 / gNB 56 as described above. That is, one or more of network nodes 1410 are configured to support favorable buffering of packets for UEs connected via L2 relays that are undergoing inter-NW node path handover. For example, UE 1412A or 1412B has an indirect path / connection to network node 1410 via a relay UE, and its path is switched to network node 1410B. In this example scenario, network node 1410A performs favorable packet buffering.

[0153] Examples of ORAN network nodes include Open Radio Units (O-RUs), Open Distributed Units (O-DUs), Open Central Units (O-CUs), including O-CU control planes (O-CU-CPs) or O-CU user planes (O-CU-UPs), RAN intelligent controllers (near real-time or non-real-time) with managed software or software plug-ins, such as near real-time control applications (e.g., xApps) or non-real-time control applications (e.g., rApps), or any combination thereof (the adjective "open" indicates support for ORAN specifications). Network nodes can support specifications by, for example, supporting interfaces defined by ORAN specifications, such as A1, F1, W1, E1, E2, X2, Xn interfaces, Open Fronthaul User Plane interfaces, or Open Fronthaul Management Plane interfaces. Furthermore, ORAN access nodes can be logical nodes within physical nodes. Additionally, ORAN network nodes can be implemented in a virtualized environment (described further below), where one or more network functions are virtualized. For example, a virtualized environment may include an O-Cloud computing platform orchestrated by a service management and orchestration framework via an O-2 interface defined by the O-RAN Consortium or similar technologies. Network node 1410 facilitates direct or indirect connections of user equipment (UE), such as connecting UE 1412a, 1412b, 1412c and 1412d (one or more of which may generally be referred to as UE 1412) to core network 1406 via one or more wireless connections.

[0154] Examples of wireless communication via a wireless connection include sending and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transmitting information without the use of wires, cables, or other conductors. Furthermore, in various embodiments, the communication system 1400 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that can facilitate or participate in the communication of data and / or signals, whether via a wired or wireless connection. The communication system 1400 may include and / or interface with any type of communication, telecommunications, data, cellular, radio network, and / or other similar types of systems.

[0155] UE 1412 can be any of a wide variety of communication devices, including wireless devices that are arranged, configured, and / or operable to communicate wirelessly with network node 1410 and other communication devices. Similarly, network node 1410 is arranged, capable, configured, and / or operable to communicate directly or indirectly with UE 1412 and / or with other network nodes or devices in telecommunication network 1402 to enable and / or provide network access, such as wireless network access, and / or perform other functions, such as management in telecommunication network 1402.

[0156] In the depicted example, core network 1406 connects network node 1410 to one or more hosts, such as host 1416. These connections may be direct or indirect, via one or more intermediate networks or devices. In other examples, network nodes may be directly coupled to hosts. Core network 1406 includes one or more core network nodes (e.g., core network node 1408) constructed with hardware and software components. The characteristics of these components may be substantially similar to those described for UEs, network nodes, and / or hosts, such that the description generally applies to the corresponding components of core network node 1408. Example core network nodes include one or more of the following functions: Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier Dehiding Function (SIDF), Unified Data Management (UDM), Security Edge Protection Agent (SEPP), Network Open Function (NEF), and / or User Plane Function (UPF).

[0157] Host 1416 may be under the ownership or control of a service provider other than the operator or provider of access network 1404 and / or telecommunications network 1402, and may be operated by or on behalf of the service provider. Host 1416 may host various applications to provide one or more services. Examples of such applications include live and pre-recorded audio / video content, data collection services such as retrieving and compiling data detected by multiple UEs regarding various environmental conditions, analytics functions, social media, functions for controlling or otherwise interacting with remote devices, functions for alarm and monitoring centers, or any other such functions performed by a server.

[0158] Overall, Figure 14 The communication system 1400 enables connections between the UE, network nodes, and the host. In this sense, the communication system can be configured to operate according to predefined rules or procedures, such as specific standards, including but not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE) and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable next-generation standard, such as 6G (sixth generation); Wireless Local Area Network (WLAN) standards such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard (WiFi); and / or any other suitable wireless communication standards, such as Global Microwave Interconnection Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any Low Power Wide Area Network (LPWAN) standards such as LoRa and Sigfox.

[0159] In some examples, telecommunications network 1402 is a cellular network implementing 3GPP standardized features. Therefore, telecommunications network 1402 can support network slicing to provide different logical networks to different devices connected to it. For example, telecommunications network 1402 can provide ultra-reliable low-latency communication (URLLC) services to some UEs while providing enhanced mobile broadband (eMBB) services to other UEs, and / or massive machine-type communication (mMTC) / massive IoT services to yet another UE.

[0160] In some examples, UE 1412 is configured to send and / or receive information without direct human interaction. For example, the UE may be designed to send information to access network 1404 according to a predetermined schedule when triggered by internal or external events, or in response to a request from access network 1404. Furthermore, the UE may be configured to operate in single RAT, multi-RAT, or multi-standard modes. For example, the UE may operate using any or a combination of Wi-Fi, NR (New Radio), and LTE, i.e., configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved UMTS Terrestrial Radio Access Network) New Radio Dual Connectivity (EN-DC).

[0161] In this example, hub 1414 communicates with access network 1404 to facilitate indirect communication between one or more UEs (e.g., UE 1412c and / or 1412d) and network nodes (e.g., network node 1410b). In some examples, hub 1414 may be a controller, router, content source, and analytics, or any other communication device described herein with respect to a UE. For example, hub 1414 may be a broadband router enabling UE access to core network 1406. As another example, hub 1414 may be a controller that sends commands or instructions to one or more actuators in the UE. Commands or instructions may be received from the UE, network node 1410, or via executable code, scripts, processes, or other instructions within hub 1414. As another example, hub 1414 may be a data collector that acts as temporary storage for UE data, and in some embodiments, may perform data analytics or other processing. As another example, hub 1414 may be a content source. For example, for a UE acting as a VR headset, display, speaker, or other media delivery device, hub 1414 can retrieve VR assets, video, audio, or other media or data related to sensory information via network nodes, and then hub 1414 provides this information to the UE directly, after performing local processing and / or after adding additional local content. In yet another example, hub 1414 acts as a proxy server or orchestrator for the UE, particularly when one or more devices in the UE are low-power IoT devices.

[0162] Hub 1414 may have a constant / persistent or intermittent connection to network node 1410b. Hub 1414 may also allow different communication schemes and / or scheduling between hub 1414 and UEs (e.g., UEs 1412c and / or 1412d) and between hub 1414 and core network 1406. In other examples, hub 1414 is connected to core network 1406 and / or one or more UEs via a wired connection. Furthermore, hub 1414 may be configured to be connected to an M2M service provider via access network 1404 and / or to another UE via a direct connection. In some scenarios, a UE may establish a wireless connection with network node 1410 while still being connected via hub 1414 through a wired or wireless connection. In some embodiments, hub 1414 may be a dedicated hub, i.e., a hub whose primary function is to route communication from network node 1410b to or from UE to network node 1410b. In other embodiments, hub 1414 may be a non-dedicated hub, i.e., a device capable of operating to route communication between the UE and network node 1410b, but also capable of operating as a communication start and / or end point for certain data channels.

[0163] Figure 15 A UE 1500 according to some embodiments is illustrated. As used herein, a UE refers to a device capable of, configured, positioned, and / or operable to wirelessly communicate with network nodes and / or other UEs. Examples of UEs include, but are not limited to: smartphones, mobile phones, cellular phones, IP-based voice (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, gaming consoles or devices, music storage devices, playback devices, wearable terminal devices, wireless endpoints, mobile stations, tablet computers, laptop computers, laptop embedded devices (LEE), laptop mounted devices (LME), smart devices, wireless customer premises equipment (CPE), vehicles, in-vehicle or vehicle embedded / integrated wireless devices, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including narrowband Internet of Things (NB-IoT) UEs, machine-type communication (MTC) UEs, and / or enhanced MTC (eMTC) UEs.

[0164] The UE can support device-to-device (D2D) communication, for example, by implementing 3GPP standards for sidelink communication, dedicated short-range communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, the UE may not necessarily be a user in the sense of a human user who owns and / or operates the associated device. Instead, the UE can represent a device intended to be sold to or operated by a human user, but which may not be associated with a particular human user, or may not have been initially associated with one (e.g., a smart sprinkler controller). Alternatively, the UE can represent a device that is not intended to be sold to or operated by an end user, but may be associated with or operated for the benefit of a user (e.g., a smart meter).

[0165] UE 1500 includes processing circuitry 1502, operably coupled via bus 1504 to input / output interface 1506, power supply 1508, memory 1510, communication interface 1512, and / or any other component, or any combination thereof. Some UEs may utilize... Figure 15 The diagram shows all or a subset of components. The level of integration between components may vary from UE to UE. Furthermore, some UEs may contain multiple instances of components, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0166] Processing circuitry 1502 is configured to process instructions and data and can be configured to implement any sequential state machine operable to execute instructions stored in memory 1510 as a machine-readable computer program. Processing circuitry 1502 can be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc.); programmable logic and appropriate firmware; one or more stored computer programs, general-purpose processors such as microprocessors or digital signal processors (DSPs), and appropriate software; or any combination thereof. For example, processing circuitry 1502 may include multiple central processing units (CPUs).

[0167] In this example, the input / output interface 1506 can be configured to provide one or more interfaces to input devices, output devices, or one or more input and / or output devices. Examples of output devices include: speakers, sound cards, video cards, displays, monitors, printers, actuators, transmitters, smart cards, other output devices, or any combination thereof. Input devices can allow users to capture information into the UE 1500. Examples of input devices include: touch-sensitive or presence-sensitive displays, cameras (e.g., digital cameras, digital video cameras, webcams, etc.), microphones, sensors, mice, trackballs, steering wheels, scroll wheels, smart cards, etc. Presence-sensitive displays may include capacitive or resistive touch sensors to sense input from the user. Sensors may be, for example, accelerometers, gyroscopes, tilt sensors, force sensors, magnetometers, optical sensors, proximity sensors, biometric sensors, etc., or any combination thereof. Output devices can use the same type of interface port as input devices. For example, a Universal Serial Bus (USB) port can be used to provide both input and output devices.

[0168] In some embodiments, power supply 1508 is configured as a battery or battery pack. Other types of power sources can be used, such as external power sources (e.g., power outlets), photovoltaic devices, or batteries. Power supply 1508 may also include power supply circuitry for delivering power from power supply 1508 itself and / or external power sources to various parts of UE 1500 via input circuitry or an interface such as a power cable. For example, delivering power can be used to charge power supply 1508. The power supply circuitry can perform any formatting, conversion, or other modifications on the power from power supply 1508 to suit the power supply for the respective powered components of UE 1500.

[0169] Memory 1510 may be, or may be configured to include, memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), disk, optical disk, hard disk, removable cassette tape, flash drive, etc. In one example, memory 1510 includes one or more applications 1514, such as an operating system, web browser application, widget, utility engine, or other application, and corresponding data 1516. Memory 1510 may store any of a wide variety of operating systems or combinations of operating systems for use by UE 1500.

[0170] The memory 1510 can be configured to include multiple physical drive units, such as a redundant array of independent disks (RAID), flash memory, a USB flash drive, an external hard drive, a thumb drive, a pen drive, a key drive, a high-density digital multifunction disc (HD-DVD) optical disc drive, an internal hard drive, a Blu-ray disc drive, a holographic digital data storage (HDDS) optical disc drive, an external mini dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro DIMM SDRAM, smart card memory, tamper-proof modules such as universal integrated circuit cards (UICCs), including one or more subscriber identification modules (SIMs), such as USIM and / or ISIMs, other memories, or any combination thereof. The UICC can be, for example, an embedded UICC (eUICC), an integrated UICC (iUICC), or a removable UICC commonly referred to as a "SIM card." The memory 1510 can allow the UE 1500 to access instructions, applications, etc., stored on transient or non-transient storage media to offload or upload data. Articles of art (such as articles of art utilizing communication systems) may be tangibly embodied in or in memory 1510, which may be or include a device-readable storage medium.

[0171] Processing circuitry 1502 can be configured to communicate with an access network or other network using communication interface 1512. Communication interface 1512 may include one or more communication subsystems and may include or be communicatively coupled to antenna 1522. Communication interface 1512 may include one or more transceivers for communication, such as through one or more remote transceivers capable of wireless communication with another device (e.g., a network node in the access network or another UE). Each transceiver may include a transmitter 1518 and / or a receiver 1520 adapted to provide network communication (e.g., optical, electrical, frequency allocation, etc.). Furthermore, transmitter 1518 and receiver 1520 may be coupled to one or more antennas (e.g., antenna 1522) and may share circuitry, software, or firmware, or optionally may be implemented separately.

[0172] In the illustrated embodiment, the communication functions of the communication interface 1512 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communication (such as Bluetooth), near-field communication, location-based communication (such as using a Global Positioning System (GPS) to determine location), another similar communication function, or any combination thereof. Communication may be implemented according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, Transmission Control Protocol / Internet Protocol (TCP / IP), Synchronous Optical Network (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), etc.

[0173] Regardless of the sensor type, the UE can provide the output of data captured by its sensors via its communication interface 1512 and a wireless connection to the network node. Data captured by the UE's sensors can be transmitted wirelessly to the network node via another UE. The output can be periodic (e.g., every 15 minutes if it reports the sensed temperature), random (e.g., to balance the load of reports from multiple sensors), responsive to a triggered event (e.g., sending an alarm when moisture is detected), responsive to a request (e.g., a user-initiated request), or a continuous stream (e.g., a live video feed of a patient).

[0174] As another example, the UE includes an actuator, motor, or switch associated with a communication interface configured to receive wireless input from a network node via a wireless connection. The state of the actuator, motor, or switch can change in response to the received wireless input. For example, the UE may include a motor that adjusts the control surfaces or rotors of a flying drone based on the received input, or adjusts a robotic arm performing a medical procedure based on the received input.

[0175] When the UE is in the form of an Internet of Things (IoT) device, it can be a device used in one or more application areas, including but not limited to urban wearable technology, extended industrial applications, and healthcare. Non-limiting examples of such IoT devices include or embedded in devices such as: connected refrigerators or freezers, TVs, connected lighting fixtures, electricity meters, robotic vacuum cleaners, voice-controlled smart speakers, home security cameras, motion detectors, thermostats, smoke detectors, door / window sensors, flood / moisture sensors, electric door locks, connected doorbells, air conditioning systems such as heat pumps, autonomous vehicles, surveillance systems, weather monitoring devices, parking monitoring devices, electric vehicle charging stations, smartwatches, fitness trackers, head-mounted displays for augmented reality (AR) or virtual reality (VR), wearable devices for haptic or sensory enhancement, sprinklers, animal or object tracking devices, sensors for monitoring plants or animals, industrial robots, unmanned aerial vehicles (UAVs), and any type of medical device, such as heart rate monitors or remotely controlled surgical robots. UEs in the form of IoT devices, in addition to those mentioned above... Figure 15 In addition to the other components described in UE 1500, it also includes circuitry and / or software depending on the intended application of the IoT device.

[0176] As another specific example, in an IoT scenario, a UE can represent a machine or other device performing monitoring and / or measurement, and sending the results of such monitoring and / or measurement to another UE and / or network node. In this case, the UE can be an M2M device, which can be referred to as an MTC device in the 3GPP context. As a specific example, the UE can implement the 3GPP NB-IoT standard. In other scenarios, the UE can represent a vehicle, such as a car, bus, truck, ship, and aircraft, or other devices capable of monitoring and / or reporting their operational status or other functions related to their operation.

[0177] In practice, any number of UEs can be used together for a single use case. For example, the first UE may be or be integrated into a drone and provide the drone's speed information (obtained via a speed sensor) to a second UE, which acts as a remote controller for operating the drone. When the user makes changes from the remote controller, the first UE can adjust the throttle on the drone (e.g., by controlling the actuators) to increase or decrease the drone's speed. The first and / or second UEs may also include one or more of the functions described above. For example, the UE may include sensors and actuators and handle communication of data for both the speed sensor and the actuators.

[0178] Figure 16 A network node 1600 according to some embodiments is illustrated. As used herein, a network node refers to a device capable of, configured, arranged, and / or operable to communicate directly or indirectly with a UE and / or other network nodes or devices in a telecommunications network. Examples of network nodes include, but are not limited to: access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs), and NR Node Bs (gNBs)), O-RAN nodes, or components of O-RAN nodes (e.g., O-RUs, O-DUs, O-CUs). Network node 1600 may, for example, implement a CU-CP entity of a gNB, such as... Figure 11 The CU-CP entity 70, or network node 1600, can implement the gNB's CU-UP entity, such as... Figure 11 One of the CU-UP entities 72.

[0179] Base stations can be classified based on the coverage they provide (or, in other words, their transmit power level), and thus, depending on the coverage provided, can be called femtocells, picocells, microcells, or macrocells. A base station can be a relay node or a relay donor node controlling a relay. Network nodes can also include one or more (or all) portions of a distributed radio base station, such as centralized digital units, distributed units (e.g., in O-RAN access nodes), and / or remote radio units (RRUs), sometimes referred to as remote radio headends (RRHs). Such remote radio units may or may not be integrated with an antenna, either as an antenna-integrated radio or not. A portion of a distributed radio base station can also be referred to as a node in a distributed antenna system (DAS).

[0180] Other examples of network nodes include: multi-transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment (such as MSR BS), network controllers (such as radio network controller (RNC) or base station controller (BSC)), base transceiver station (BTS), transmission points, transmission nodes, multi-cell / multicast coordination entities (MCE), operation and maintenance (O&M) nodes, operation support system (OSS) nodes, self-organizing network (SON) nodes, location nodes (e.g., evolved serving mobile location center (E-SMLC)) and / or minimized drive test (MDT).

[0181] Network node 1600 includes processing circuitry 1602, memory 1604, communication interface 1606, and power supply 1608. Network node 1600 may consist of multiple physically separate components (e.g., NodeB components and RNC components, or BTS components and BSC components, etc.), each of which may have its own corresponding components. In some scenarios where network node 1600 includes multiple separate components (e.g., BTS and BSC components), one or more separate components may be shared among several network nodes. For example, a single RNC can control multiple NodeBs. In such scenarios, each unique NodeB and RNC pair may be considered a single, separate network node in some instances. In some embodiments, network node 1600 may be configured to support multiple Radio Access Technologies (RATs). In such embodiments, some components may be replicated (e.g., separate memory 1604 for different RATs), and some components may be reused (e.g., the same antenna 1610 may be shared by different RATs). Network node 1600 may also include multiple sets of various components for different wireless technologies integrated into network node 1600, such as GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, radio frequency identification (RFID), or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chips or chipsets and other components within network node 1600.

[0182] Processing circuitry 1602 may include a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field-programmable gate array, or any other suitable computing device or resource, or a combination of hardware, software, and / or coding logic, operable to provide network node 1600 functionality, either alone or in combination with other network node 1600 components, such as memory 1604.

[0183] In some embodiments, the processing circuitry 1602 includes a system-on-a-chip (SOC). In some embodiments, the processing circuitry 1602 includes one or more of a radio frequency (RF) transceiver circuitry 1612 and a baseband processing circuitry 1614. In some embodiments, the RF transceiver circuitry 1612 and the baseband processing circuitry 1614 may be on separate chips (or chipsets), boards, or units, such as radio units and digital units. In alternative embodiments, some or all of the RF transceiver circuitry 1612 and the baseband processing circuitry 1614 may be on the same chip or chipset, board, or unit.

[0184] Memory 1604 may include any form of volatile or non-volatile computer-readable memory, including but not limited to: persistent memory, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (e.g., hard disk), removable storage media (e.g., flash drive, optical disc (CD), or digital video disc (DVD)) and / or any other volatile or non-volatile, non-transient device-readable and / or computer-executable storage device (which stores information, data, and / or instructions that can be used by processing circuitry 1602). Memory 1604 may store any suitable instructions, data, or information, including computer programs, software, applications (including one or more of logic, rules, codes, tables, and / or other instructions that can be executed by processing circuitry 1602 and utilized by network node 1600). Memory 1604 may be used to store any calculations performed by processing circuitry 1602 and / or any data received via communication interface 1606. In some embodiments, processing circuitry 1602 and memory 1604 are integrated.

[0185] Communication interface 1606 is used for wired or wireless communication of signaling and / or data between network nodes, access networks, and / or UEs. As shown, communication interface 1606 includes a port / terminal 1616 for sending and receiving data to and from a network, for example, via a wired connection. Communication interface 1606 also includes radio front-end circuitry 1618, which may be coupled to antenna 1610, or in some embodiments, is part of antenna 1610. Radio front-end circuitry 1618 includes a filter 1620 and an amplifier 1622. Radio front-end circuitry 1618 may be connected to antenna 1610 and processing circuitry 1602. Radio front-end circuitry 1618 may be configured to modulate the signal transmitted between antenna 1610 and processing circuitry 1602. Radio front-end circuitry 1618 may receive digital data to be transmitted to other network nodes or UEs via a wireless connection. Radio front-end circuitry 1618 may use a combination of filter 1620 and / or amplifier 1622 to convert the digital data into a radio signal with appropriate channel and bandwidth parameters. The radio signal may then be transmitted via antenna 1610. Similarly, when receiving data, antenna 1610 can collect radio signals, which are then converted into digital data by radio front-end circuitry 1618. The digital data can then be passed to processing circuitry 1602. In other embodiments, the communication interface may include different components and / or different combinations of components.

[0186] In some alternative embodiments, network node 1600 does not include a separate radio front-end circuitry 1618; instead, processing circuitry 1602 includes radio front-end circuitry and is connected to antenna 1610. Similarly, in some embodiments, all or some of the RF transceiver circuitry 1612 is part of communication interface 1606. In other embodiments, communication interface 1606 includes one or more ports or terminals 1616, radio front-end circuitry 1618, and RF transceiver circuitry 1612 as part of a radio unit (not shown), and communication interface 1606 communicates with baseband processing circuitry 1614, which is part of a digital unit (not shown).

[0187] Antenna 1610 may include one or more antennas or an antenna array configured to transmit and / or receive wireless signals. Antenna 1610 may be coupled to radio front-end circuitry 1618 and may be any type of antenna capable of wirelessly transmitting and receiving data and / or signals. In some embodiments, antenna 1610 is separate from network node 1600 and may be connected to network node 1600 via an interface or port.

[0188] Antenna 1610, communication interface 1606, and / or processing circuitry 1602 can be configured to perform any receive operation and / or certain acquire operation as described herein by a network node. Any information, data, and / or signal can be received from the UE, another network node, and / or any other network device. Similarly, antenna 1610, communication interface 1606, and / or processing circuitry 1602 can be configured to perform any transmit operation as described herein by a network node. Any information, data, and / or signal can be transmitted to the UE, another network node, and / or any other network device.

[0189] Power supply 1608 provides power to the various components of network node 1600 in a form suitable for the respective components (e.g., at the voltage and current levels required by each respective component). Power supply 1608 may also include or be coupled to power management circuitry to power the components of network node 1600 for performing the functions described herein. For example, network node 1600 may be connected to an external power source (e.g., mains, power outlet) via input circuitry or an interface such as a cable, thereby supplying power to the power circuitry of power supply 1608. As another example, power supply 1608 may include a power source in the form of a battery or battery pack connected to or integrated into the power circuitry. The battery can provide backup power in the event of an external power failure.

[0190] Embodiments of network node 1600 may include Figure 16 Additional components, other than those shown, may be used to provide certain aspects of the functionality of the network node, including any of the functions described herein and / or any functions required to support the topics described herein. For example, network node 1600 may include a user interface device to allow information to be input into and output from network node 1600. This can allow users to perform diagnostic, maintenance, repair, and other management functions on network node 1600.

[0191] Figure 17 Based on the block diagram of the host 1700 described in this document, the host 1700 can be... Figure 14 This is an embodiment of host 1416. As used herein, host 1700 can be or includes various combinations of hardware and / or software, including standalone servers, blade servers, cloud-implemented servers, distributed servers, virtual machines, containers, or processing resources in a server farm. Host 1700 can provide one or more services to one or more UEs.

[0192] Host 1700 includes processing circuitry 1702 operably coupled via bus 1704 to input / output interface 1706, network interface 1708, power supply 1710, and memory 1712. Other components may be included in other embodiments. The features of these components may be similar to those described in the previous figures (such as...). Figure 15 and Figure 16 The features described in the device description are largely similar to those in the host 1700, so that the description is generally applicable to the corresponding components of the host 1700.

[0193] Memory 1712 may include one or more computer programs, including one or more host applications 1714 and data 1716. Data 1716 may include user data, such as data generated by the UE for the host 1700 or data generated by the host 1700 for the UE. Embodiments of the host 1700 may utilize only a subset or all of the illustrated components. Host application 1714 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Universal Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different categories, types, or implementations of the UE (e.g., mobile phone, desktop computer, wearable display system, head-up display system). Host application 1714 may also provide user authentication and authorization checks and may periodically report health status, routing, and content availability to a central node (such as a device at the edge of the core network or in the core network). Therefore, host 1700 can select and / or instruct different hosts for the UE's over-the-top service. Host application 1714 can support various protocols, such as HTTP Live Streaming (HLS), Real-Time Messaging Protocol (RTMP), Real-Time Streaming Protocol (RTSP), and HTTP-based Dynamic Adaptive Streaming (MPEG-DASH).

[0194] Figure 18This diagram illustrates a block diagram of a virtualization environment 1800 in which functionality implemented by some embodiments can be virtualized. In the current context, virtualization means creating virtual versions of devices or equipment, which may include virtualized hardware platforms, storage devices, and network resources. As used herein, virtualization can be applied to any device or component thereof described herein and relates to an implementation in which at least a portion of functionality is implemented as one or more virtual components. Some or all of the functionality described herein can be implemented as virtual components executed by one or more virtual machines (VMs) in one or more virtual environments 1800 hosted by one or more hardware nodes, such as hardware computing devices operating as network nodes, UEs, core network nodes, or hosts. Furthermore, in embodiments where virtual nodes do not require radio connectivity (e.g., core network nodes or hosts), the nodes can be fully virtualized. In some embodiments, the virtualization environment 1800 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a service management and orchestration framework via an O-2 interface.

[0195] Application 1802 (which may optionally be referred to as a software instance, virtual device, network function, virtual node, virtual network function, etc.) runs in a virtualization environment Q400 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.

[0196] Hardware 1804 includes processing circuitry, memory storing software and / or instructions executable by the hardware processing circuitry, and / or other hardware devices described herein, such as network interfaces, input / output interfaces, etc. The software can be executed by the processing circuitry to instantiate one or more virtualization layers 1806 (also referred to as managers or virtual machine monitors (VMMs)), provide VMs 1808a and 1808b (one or more of which may generally be referred to as VM 1808), and / or perform any functionality, features, and / or benefits related to some of the embodiments described herein. Virtualization layer 1806 can present a virtual operating platform to VM 1808 that appears to be network hardware.

[0197] VM 1808 includes virtual processing, virtual memory, virtual networks or interfaces, and virtual storage, and can be operated by a corresponding virtualization layer 1806. Different embodiments of instances of virtual appliances 1802 can be implemented on one or more VMs 1808, and can be implemented in different ways. Hardware virtualization is referred to in some contexts as Network Functions Virtualization (NFV). NFV can be used to consolidate many types of network devices onto industry-standard high-capacity server hardware, physical switches, and physical storage, which can reside in data centers and customer premises.

[0198] In the context of NFV, a VM 1808 can be a software implementation of a physical machine, whose programs run as if they were executed on a physical, non-virtualized machine. Each VM 1808, along with a portion of the hardware 1804 that executes that VM—whether dedicated to that VM or shared by that VM with other VMs—forms a separate virtual network element. Still within the NFV context, the virtual network function is responsible for handling the specific network functions running on one or more VMs 1808 above the hardware 1804 and corresponding to application 1802.

[0199] Hardware 1804 can be implemented in a standalone network node with general or specific components. Hardware 1804 may implement some functions via virtualization. Optionally, hardware 1804 may be part of a larger hardware cluster (e.g., in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 1810, which oversees the lifecycle management of application 1802. In some embodiments, hardware 1804 is coupled to one or more radio units, each radio unit including one or more transmitters that can be coupled to one or more antennas and one or more receivers. The radio units may communicate directly with other hardware nodes via one or more suitable network interfaces and may be used in conjunction with virtual components to provide radio capabilities, such as radio access nodes or base stations, to virtual nodes. In some embodiments, a control system 1812 may be used to provide signaling, which may optionally be used for communication between hardware nodes and radio units.

[0200] As can be seen, the above concepts can be used for efficient path switching in U2N relay scenarios. In particular, data loss can be avoided without resorting to E2D feedback mechanisms.

[0201] It should be understood that the examples and embodiments described above are merely illustrative and various modifications can be made. For example, the concepts shown can be applied in conjunction with various communication technologies and are not necessarily limited to wireless communication. Furthermore, it should be understood that the above concepts can be implemented using software of a corresponding design executed by one or more processors of an existing device or apparatus, or by using dedicated device hardware. Additionally, it should be noted that the illustrated apparatus or apparatus can be implemented as a single device or a system of multiple interactive devices or modules.

[0202] While the computing devices described herein (e.g., UE, network node, host) may include combinations of the hardware components shown, other embodiments may include computing devices with combinations of different components. It should be understood that these computing devices may include any suitable combination of hardware and / or software required to perform the tasks, features, functions, and methods disclosed herein. The determination, calculation, acquisition, or similar operations described herein may be performed by processing circuitry that processes information by, for example, converting acquired information into other information, comparing the acquired or converted information with information stored in a network node, and / or performing one or more operations based on the acquired or converted information, and making a determination as a result of said processing. Furthermore, although components are described as single boxes within larger boxes or nested within multiple boxes, in practice, computing devices may include multiple different physical components constituting a single illustrated component, and functionality may be partitioned between individual components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of a component may be partitioned between processing circuitry and the communication interface. In another example, the non-computationally intensive functionality of any such component may be implemented in software or firmware, while the computationally intensive functionality may be implemented in hardware.

[0203] In some embodiments, some or all of the functions described herein may be provided by processing circuitry that executes instructions stored in memory, which in some embodiments may be a computer program product in the form of a non-transient computer-readable storage medium. In alternative embodiments, some or all of the functions may be provided by processing circuitry without executing instructions stored on separate or discrete device-readable storage media, such as in a hard-wired manner. In any of these particular embodiments, processing circuitry may be configured to perform the functions regardless of whether instructions stored on a non-transient computer-readable storage medium are executed. The benefits provided by such functions are not limited to individual processing circuitry or other components of the computing device, but are shared by the entire computing device and / or by the end user and wireless network.

[0204] In view of the above, the examples covered by this disclosure include, but are not limited to:

[0205] Group A Example

[0206] 1. A method performed by a user equipment (UE), the method comprising: communicating with a network node of a wireless communication network via a relay UE, wherein the UE operates as a remote UE having a sidelink connection to the relay UE, and wherein the relay UE has a connection to the network node.

[0207] 2. The method according to Example 1 further includes:

[0208] Provide user data; and

[0209] The user data is forwarded to the host via transmission to the relay UE for relay to the network node.

[0210] Group B Example

[0211] 3. A method performed by a network node of a wireless communication network, the method comprising:

[0212] In response to the triggering of a path handover process for a remote user equipment (UE), a buffer packet is provided for the remote UE having an indirect connection to the network node via a relay UE operating as a Layer 2 (L2) relay, wherein the path handover process is a node-to-node handover of the remote UE from the network node as the source node to another network node as the destination node.

[0213] 4. The method according to Example 3, wherein buffering the packets for the remote UE comprises: buffering instead of discarding one or more packets indicated to have been successfully sent from the network node to the relay UE.

[0214] 5. A method performed by a network node in a wireless communication network, wherein the network node operates as a source node for a remote user equipment (UE) connected to the network node via a relay UE, the method comprising:

[0215] The source node modifies its packet dropping behavior for packets intended for the remote UE by not discarding packets that are indicated to have been sent to the relay UE but are buffered for the remote UE.

[0216] 6. A method performed by a gNB operating as a network node in a wireless communication network, the method comprising:

[0217] The gNB's Central Unit Control Plane (CU-CP) entity provides an indication to the gNB's CU User Plane (CU-UP) entity, the indication being provided in response to a triggering of an inter-gNB path handover for a remote UE having an indirect connection to the gNB via a relay UE; and

[0218] In response to the instruction, the CU-UP entity is the remote UE buffer packet.

[0219] 7. The method according to Example 6, wherein buffering packets for the remote UE includes: reserving packets for the UE in a buffer of the gNB, the gNB obtaining an indication of successful transmission to the relay UE for the packets.

[0220] 8. The method according to Example 6 or 7, wherein the CU-CP entity sends the instruction to the CU-UP entity via an E1 interface between the respective entities.

[0221] 9. The method according to any one of Examples 6-8, wherein the inter-gNB path handover involves a target gNB, and wherein the method includes: subsequently forwarding the packet buffered for the remote UE to the target gNB.

[0222] 10. The method according to any one of Examples 6-9, wherein, in response to receiving the instruction, the CU-UP entity starts a timer, and in response to the expiration of the timer, the packet buffered by the remote UE is discarded.

[0223] 11. The method according to Example 10, wherein the indication provided by the CU-CP includes the timer, such that the CU-CP determines the duration of the buffer.

[0224] 12. The method according to Example 10, wherein the CU-UP determines the duration of the buffer.

[0225] 13. The method according to any one of Examples 10-12, wherein the CU-UP discards the packet buffered by the remote UE in response to the earlier of the expiration of the timer or the occurrence of the discard trigger.

[0226] 14. The method according to Example 13, wherein the drop trigger is any one or more of the following: receiving a drop instruction from the CU-CP entity, or receiving a Packet Data Convergence Protocol (PDCP) status report from the target gNB for the remote UE.

[0227] 15. The method according to Example 6 further includes: in response to the packet already forwarded to another gNB as a buffer for the remote UE or receiving a Packet Data Convergence Protocol (PDCP) report from another gNB, the CU-UP discards the packet as a buffer for the remote UE.

[0228] 16. The method according to Example 6 further includes: in response to reaching a time limit defined for buffering the packet, the CU-UP discards the packet buffered for the remote UE, the time limit being determined for the buffer.

[0229] 17. The method according to Example 6, wherein buffering packets for the remote UE includes: temporarily modifying the packet dropping behavior of the CU-UP entity so that it does not drop the packets stored in its buffer for the remote UE in response to an indication that the packets stored in its buffer for the remote UE have been successfully transmitted to the relay UE.

[0230] 18. The method according to Example 17, wherein the indication includes a lower protocol level ACK from the CU-UP entity, or the indication is provided via downlink data delivery status (DDDS) information.

[0231] 19. The method according to any one of Examples 6-18 above, further comprising:

[0232] Obtaining user data; and

[0233] The user data is forwarded to the host or the remote UE.

[0234] Group C Example

[0235] 20. A user equipment, comprising:

[0236] Processing circuitry, configured to execute any step of any example from Group A; and

[0237] A power supply circuit is configured to supply power to the processing circuit.

[0238] 21. A network node, comprising:

[0239] Processing circuitry, configured to execute any step of any example in Group B;

[0240] A power supply circuit is configured to supply power to the processing circuit.

[0241] 22. A user equipment (UE), comprising:

[0242] An antenna, which is configured to transmit and receive wireless signals;

[0243] A radio front-end circuit, which is connected to the antenna and the processing circuit, and is configured to modulate the signal transmitted between the antenna and the processing circuit;

[0244] The processing circuit is configured to perform any step of any example in Group A of the examples;

[0245] An input interface is connected to the processing circuitry and configured to allow information to be input into the UE for processing by the processing circuitry.

[0246] An output interface, which is connected to the processing circuit and configured to output information that has been processed by the processing circuit from the UE; and

[0247] A battery is connected to the processing circuit and configured to power the UE.

[0248] 23. A host configured to operate in a communication system to provide over-the-top (OTT) services, the host comprising:

[0249] Processing circuitry, configured to provide user data; and

[0250] A network interface configured to initiate the transmission of the user data to a network node in a cellular network for transmission to a user equipment (UE), the network node having a communication interface and processing circuitry, the processing circuitry of the network node being configured to perform any operation of any example in the Group B examples to send the user data from the host to the UE.

[0251] 24. The host according to the foregoing example, wherein:

[0252] The processing circuitry of the host is configured to execute a host application that provides the user data; and

[0253] The UE includes processing circuitry configured to execute a client application associated with the host application to receive the transmission of user data from the host.

[0254] 25. A method implemented in a host, the host being configured to operate in a communication system, the communication system further comprising a network node and a user equipment (UE), the method comprising:

[0255] Provide user data to the UE; and

[0256] Initiate a transmission carrying the user data to the UE via a cellular network including the network node, wherein the network node performs any operation of any example in Group B to send the user data from the host to the UE.

[0257] 26. The method according to the foregoing example further includes: at the network node, transmitting the user data provided by the host to the UE.

[0258] 27. The method according to any one of the foregoing two examples, wherein the user data is provided at the host by executing a host application that interacts with a client application executed on the UE, the client application being associated with the host application.

[0259] 28. A communication system configured to provide over-the-top (OTT) services, the communication system comprising:

[0260] The host includes:

[0261] Processing circuitry configured to provide user data to a user equipment (UE), the user data being associated with the over-the-top service; and

[0262] A network interface configured to initiate the transmission of the user data to a cellular network node for transmission to the UE, the network node having a communication interface and processing circuitry, the processing circuitry of the network node being configured to perform any operation of any example in Group B examples to send the user data from the host to the UE.

[0263] 29. The communication system according to the foregoing example further includes:

[0264] The network node; and / or

[0265] The UE.

[0266] 30. A host configured to operate in a communication system to provide over-the-top (OTT) services, the host comprising:

[0267] Processing circuitry, configured to initiate the reception of user data; and

[0268] A network interface configured to receive the user data from a network node in a cellular network, the network node having a communication interface and processing circuitry, the processing circuitry of the network node being configured to perform any operation of any of the examples in Group B to receive the user data from the user equipment (UE) for the host.

[0269] 31. The host described in the two examples above, wherein:

[0270] The processing circuitry of the host is configured to execute a host application that receives the user data; and

[0271] The host application is configured to interact with a client application running on the UE, the client application being associated with the host application.

[0272] 32. The host according to any one of the foregoing two examples, wherein initiating the receipt of the user data includes: requesting the user data.

[0273] 33. A method implemented by a host configured to operate in a communication system, the communication system further comprising a network node and a user equipment (UE), the method comprising:

[0274] At the host, the reception of user data from the UE is initiated, the user data originating from a transmission received by the network node from the UE, wherein the network node performs any step of any example in Group B to receive the user data from the UE for the host.

[0275] 34. The method according to the foregoing example further includes: at the network node, sending the received user data to the host.

[0276] 35. A host configured to operate in a communication system to provide over-the-top (OTT) services, the host comprising:

[0277] Processing circuitry, configured to provide user data; and

[0278] A network interface configured to initiate the transmission of the user data to a cellular network for transmission to a user equipment (UE), wherein the UE includes a communication interface and processing circuitry, the communication interface and processing circuitry of the UE being configured to perform any operation of any example in Group A examples to receive the user data from the host.

[0279] 36. The host according to the foregoing example, wherein the cellular network further includes a network node configured to communicate with the UE to send the user data from the host to the UE.

[0280] 37. The host described in the two examples above, wherein:

[0281] The processing circuitry of the host is configured to execute a host application, thereby providing the user data; and

[0282] The host application is configured to interact with a client application running on the UE, the client application being associated with the host application.

[0283] 38. A method implemented by a host operating in a communication system, the communication system further comprising a network node and a user equipment (UE), the method comprising:

[0284] Provide user data to the UE; and

[0285] Initiate a transmission carrying the user data to the UE via a cellular network including the network node, wherein the UE performs any operation of any example in Group A to receive the user data from the host.

[0286] 39. The method according to the foregoing example further includes:

[0287] At the host, a host application associated with a client application running on the UE is executed to receive the user data from the host application.

[0288] 40. The method according to the foregoing example further includes:

[0289] At the host, input data is sent to the client application running on the UE, the input data being provided by executing the host application.

[0290] The user data is provided by the client application in response to the input data from the host application.

[0291] 41. A host configured to operate in a communication system to provide over-the-top (OTT) services, the host comprising:

[0292] Processing circuitry, configured to provide user data; and

[0293] A network interface configured to initiate the transmission of the user data to a cellular network for transmission to a user equipment (UE), wherein the UE includes a communication interface and processing circuitry, the communication interface and processing circuitry of the UE being configured to perform any step of any example in Group A examples to send the user data to the host.

[0294] 42. The host according to the foregoing example, wherein the cellular network further includes a network node configured to communicate with the UE to transmit the user data from the UE to the host.

[0295] 43. The host described in the two examples above, wherein:

[0296] The processing circuitry of the host is configured to execute a host application, thereby providing the user data; and

[0297] The host application is configured to interact with a client application running on the UE, the client application being associated with the host application.

[0298] 44. A method implemented by a host configured to operate in a communication system, the communication system further comprising a network node and a user equipment (UE), the method comprising:

[0299] At the host, user data sent by the UE to the host via the network node is received, wherein the UE performs any step of any example in Group A to send the user data to the host.

[0300] 45. The method according to the foregoing example further includes:

[0301] At the host, a host application associated with a client application running on the UE is executed to receive the user data from the UE.

[0302] 46. ​​The method described in the two examples above further includes:

[0303] At the host, input data is sent to the client application running on the UE, the input data being provided by executing the host application.

[0304] The user data is provided by the client application in response to the input data from the host application.

Claims

1. A gNB (12) based on a wireless communication network; 56-1, 56-2; 56) The method of execution, the method comprising: In response to the triggering of an inter-gNB path handover for a remote user equipment UE (14) having an indirect connection to a gNB (12; 56-1, 56-2; 56) via a relay UE (20), the central unit user plane CU-UP entity (72) of the gNB (12; 56-1, 56-2; 56) receives an indication from the central unit control plane CU-CP entity (70) of the gNB (12; 56-1, 56-2; 56); and In response to the instruction, the CU-UP entity (72) buffers packets for the remote UE (14).

2. The method according to claim 1, wherein, The buffering of packets for the remote UE (14) includes: modifying the packet dropping behavior of the CU-UP entity (72) so that the CU-UP entity (72) does not drop the packets stored in its buffer for the remote user equipment (14) in response to an indication that the packets stored in its buffer for the remote user equipment (14) have been successfully transmitted to the relay UE (20).

3. The method according to claim 2, wherein, The indication of successful transmission is provided via downlink data delivery status (DDDS) information.

4. The method according to claim 2 or 3, wherein, The indication of successful transmission includes a lower protocol level acknowledgment from the CU-UP entity (72).

5. The method according to any one of the preceding claims, wherein, The buffered packets for the remote UE (14) include: packets that the gNB (12; 56-1, 56-2; 56) has received as an indication that it has successfully transmitted to the relay UE (20).

6. The method according to any one of the preceding claims, wherein, The CU-UP entity (72) receives the instruction via the E1 interface.

7. The method according to any one of the preceding claims, wherein, The inter-gNB path handover involves a target gNB (24), and the method includes: subsequently forwarding the packet, which is buffered for the remote UE (14), to the target gNB (24).

8. The method according to any one of the preceding claims, wherein, In response to receiving the instruction, the CU-UP entity (72) starts a timer and discards the packet buffered by the remote UE (14) in response to the expiration of the timer.

9. The method according to claim 8, wherein, The instruction includes the setting of the timer.

10. The method according to claim 8 or 9, wherein, The CU-UP entity (72) discards the packet buffered for the remote UE (14) in response to the earlier of the following: the expiration of the timer or the occurrence of the discard trigger.

11. The method according to claim 10, wherein, The drop trigger is one or more of the following: receiving a drop instruction from the CU-CP entity, or receiving a Packet Data Convergence Protocol (PDCP) status report from the target gNB (24) for the remote UE (14).

12. The method according to any one of the preceding claims, wherein, The CU-UP entity (72) determines the duration of the buffer.

13. The method according to any one of the preceding claims further comprises: The CU-UP entity (72) discards the packet buffered by the remote UE (14) in response to either the packet being forwarded to another gNB (24) or the packet being received from another gNB (24) as a PDCP report.

14. The method according to any one of the preceding claims further comprises: The CU-UP entity (72) discards the packet buffered for the remote UE (14) in response to reaching the time limit defined for the buffer.

15. A gNB (12) of a wireless communication network; 56-1, 56-2; 56) The method of execution, the method comprising: In response to the triggering of an inter-gNB path handover for a remote user equipment UE (14) having an indirect connection to a gNB (12; 56-1, 56-2; 56) via a relay UE (20), the central unit control plane CU-CP entity (70) of the gNB (12; 56-1, 56-2; 56) provides an instruction to the central unit user plane CU-UP entity (72) of the gNB (12; 56-1, 56-2; 56). The instruction causes the CU-UP entity to buffer packets for the remote UE.

16. The method according to claim 15, wherein, The buffering of packets for the remote UE (14) includes: modifying the packet dropping behavior of the CU-UP entity (72) so that the CU-UP entity (72) does not drop the packets stored in its buffer for the remote UE (14) in response to an indication that the packets stored in its buffer for the remote UE (14) have been successfully transmitted to the relay UE (20).

17. The method according to claim 16, wherein, The indication of successful transmission is provided via downlink data delivery status (DDDS) information.

18. The method according to claim 16 or 17, wherein, The indication of successful transmission includes a lower protocol level acknowledgment from the CU-UP entity (72).

19. The method according to any one of claims 15 to 18, wherein, The buffered packets for the remote UE (14) include: packets that the gNB (12; 56-1, 56-2; 56) has received as an indication that it has successfully transmitted to the relay UE (14).

20. The method according to any one of claims 15 to 19, wherein, The CU-CP entity (70) provides the instruction via the E1 interface.

21. The method according to any one of claims 15 to 20, wherein, The inter-gNB path handover involves a target gNB (24), and the buffer includes: the packet subsequently forwarded to the target gNB (24) for buffering by the remote UE (14).

22. A network node (1410A, 1410B; 1600) configured to perform a gNB (12; ) function in a wireless communication network. 56-1，56-2； 56) operations, the operations including: In response to the triggering of an inter-gNB path handover for a remote user equipment UE (14) having an indirect connection to the gNB (12; 56-1, 56-2; 56) via a relay UE (20), the central unit user plane CU-UP entity (72) of the gNB (12; 56-1, 56-2; 56) receives an indication from the central unit control plane CU-CP entity (70) of the gNB (12; 56-1, 56-2; 56); and In response to the instruction, the CU-UP entity (72) buffers packets for the remote UE (14).

23. The network node (1410A, 1410B; 1600) according to claim 22 is further configured to perform the operation of the method according to any one of claims 2 to 14.

24. The network node (1410A, 1410B; 1600) according to claim 22 or 23, comprising: Processing circuitry (30; 1602) configured to perform the method according to any one of claims 1 to 14; as well as A power supply circuit (1608) is configured to supply power to the processing circuit (30; 1602).

25. A network node (1410A, 1410B; 1600) configured to perform a gNB (12; ) wireless communication network. 56-1，56-2； 56) operations, the operations including: In response to the triggering of an inter-gNB path handover for a remote user equipment UE (14) having an indirect connection to a gNB (12; 56-1, 56-2; 56) via a relay UE (20), the central unit control plane CU-CP entity (70) of the gNB (12; 56-1, 56-2; 56) provides an instruction to the central unit user plane CU-UP entity (72) of the gNB (12; 56-1, 56-2; 56). The instruction causes the CU-UP entity (72) to buffer packets for the remote UE (14).

26. The network node (1410A, 1410B; 1600) according to claim 25 is further configured to perform the operation of the method according to any one of claims 16 to 21.

27. The network node (1410A, 1410B; 1600) according to claim 25 or 26, comprising: Processing circuitry (30; 1602) configured to perform the method according to any one of claims 15 to 21; as well as A power supply circuit (1608) is configured to supply power to the processing circuit (30; 1602).

28. A computer program or computer program product comprising program code to be executed by processing circuitry of a network node for a communication network, wherein, The execution of the program code by the processing circuit causes the network node to perform the method according to any one of claims 1 to 14.

29. A computer program or computer program product comprising program code to be executed by processing circuitry of a network node for a communication network, wherein, The execution of the program code by the processing circuit causes the network node to perform the method according to any one of claims 15 to 21.

Images