Manipulation of buffered traffic during inter-cu migration of integrated access backhaul (iab) nodes

Abstract

Examples include methods for migrating an Integrated Access Backhaul (IAB) node from a first Centralized Unit (CU) to a second CU in a wireless network. Such methods include receiving a handover command from the first CU via a source parent IAB node. The handover command includes an identifier for the target cell for handover. These methods include determining that the handover command is for an inter-CU migration from the IAB node to the second CU, and performing modified manipulations on uplink and / or downlink data buffered in the IAB node based on the determination that the handover command is for an inter-CU migration, until the execution of the handover command. Examples also include supplementary methods for manipulating the migration of a child IAB node from the first CU to the second CU, and IAB nodes configured to perform such methods. Figure 17 has been selected for publication.

Description

Technical Field

[0001] Generally, this application relates to the field of wireless communication networks, and more specifically to integrated access backhaul (IAB) networks, in which available wireless communication resources are shared between user access to the network and backhaul of user services within the network (e.g., to / from the core network). Background Technology

[0002] Currently, fifth-generation (“5G”) cellular systems, also known as New Radio (NR), are being standardized within the 3rd Generation Partnership Project (3GPP). NR is being developed to achieve maximum flexibility in supporting multiple and fundamentally different use cases. These include enhanced mobile broadband (eMBB), machine-type communication (MTC), ultra-reliable low-latency communication (URLLC), sidelink device-to-device (D2D), and several other use cases.

[0003] Figure 1 This diagram presents a high-level view of a 5G network architecture comprised of a next-generation RAN (NG-RAN) 199 and a 5G core (5GC) 198. The NG-RAN 199 can include one or more gNodeBs (gNBs) connected to the 5GC via one or more NG interfaces, such as gNBs 100 and 150 connected via interfaces 102 and 152, respectively. More specifically, gNBs 100 and 150 can be connected to one or more Access and Mobility Management Functions (AMFs) in the 5GC 198 via corresponding NG-C interfaces. Similarly, gNBs 100 and 150 can be connected to one or more User Plane Functions (UPFs) in the 5GC 198 via corresponding NG-U interfaces. Various other network functions (NFs) can be included in the 5GC 198, including one or more Session Management Functions (SMFs).

[0004] Although not shown, in some deployments, the 5GC 198 can be replaced by the Evolved Packet Core (EPC), which is conventionally used together with Long Term Evolution (LTE) and Evolved UMTS RAN (E-UTRAN). In such deployments, gNBs 100 and 150 can connect to one or more Mobility Management Entities (MMEs) within the EPC 198 via their respective S1-C interfaces. Similarly, gNBs 100 and 150 can connect to one or more Serving Gateways (SGWs) within the EPC via their respective NG-U interfaces.

[0005] Additionally, gNBs can interconnect via one or more Xn interfaces (such as Xn interface 140 between gNBs 100 and 150). The radio technology used for NG-RAN is commonly referred to as "New Radio" (NR). Regarding the NR interface to the UE, each of these gNBs can support Frequency Division Duplex (FDD), Time Division Duplex (TDD), or a combination thereof.

[0006] NG-RAN 199 is layered into a Radio Network Layer (RNL) and a Transport Network Layer (TNL). The NG-RAN architecture (i.e., the NG-RAN logical nodes and the interfaces between them) is defined as a part of the RNL. For each NG-RAN interface (NG, Xn, F1), the associated TNL protocol and functionality are specified. The TNL provides services for user plane transport and signaling transport. In some example configurations, each gNB is connected to all 5GC nodes within the “AMF area” defined in 3GPP TS 23.501 (v15.5.0).

[0007] Figure 1 The NG RAN logical nodes shown include a central unit (CU or gNB-CU) and one or more distributed units (DUs or gNB-DUs). For example, gNB 100 includes gNB-CU 110 and gNB-DUs 120 and 130. A CU (e.g., gNB-CU 110) is a logical node that hosts higher-layer protocols and performs various gNB functions, such as controlling the operation of DUs. DUs (e.g., gNB-DUs 120, 130) are distributed logical nodes that host lower-layer protocols and are capable of including various subsets of gNB functions depending on a function splitting option. Therefore, each of these CUs and DUs can include various circuit modules required to perform its respective function, including processing circuit modules, transceiver circuit modules (e.g., for communication), and power supply circuit modules. Furthermore, the terms "central unit" and "centralized unit" are used interchangeably herein, as are the terms "distributed unit" and "distributed unit".

[0008] gNB-CU communicates through the corresponding F1 logic interface (such as...) Figure 1Interfaces 122 and 132 shown are used to connect to one or more gNB-DUs. However, a gNB-DU can only connect to a single gNB-CU. The gNB-CU and (one or more) connected gNB-DUs are only visible to other gNBs and the 5GC acting as a gNB. In other words, the F1 interface is not visible outside the gNB-CU. F1 separates the control plane (CP) and user plane (CP) into the corresponding F1-AP protocol and F1-U protocol, allowing the gNB-CU to also be separated in the CP and UP. F1 also separates the functionality of the radio network layer (RNL) and transport network layer (TNL).

[0009] The F1-U protocol is also used to transmit control information related to the management of user data streams carried by data radio, as defined in 3GPP TS 38.425 (v15.6.0). F1-U protocol data is transmitted via the GTP-U protocol, more specifically through the "RAN container" GTP-U extension header as defined in 3GPP TS 29.281 (v15.6.0). In other words, the GTP-U protocol over Internet Protocol (IP) and User Datagram Protocol (UDP) carries data streams on the F1 interface. A GTP-U "tunnel" between two nodes is identified in each node by the Tunnel Endpoint Identifier (TEID), IP address, and UDP port number. A GTP-U tunnel is necessary to enable packet forwarding between GTP-U entities.

[0010] The CU can host protocols such as RRC and PDCP, while the DU can host protocols such as RLC, MAC, and PHY. In other variants, the RLC protocol can be split between the CU and DU, with the Automatic Repeat Request (ARQ) functionality residing in the CU. In other variants, the CU can host both RRC and PDCP, with PDCP handling both UP (e.g., PDCP-U) and CP (e.g., PDCP-C) services.

[0011] Furthermore, centralized control plane protocols (such as PDCP-C and RRC) can be hosted in a different CU than centralized user plane protocols (such as PDCP-U). In particular, the 3GPP RAN3 Working Group (WG) has also agreed to support splitting the gNB-CU into CU-CP functions (including RRC and PDCP for signaling radio bearers) and CU-UP functions (including PDCP for user plane). Figure 2 An exemplary gNB architecture is shown, which includes two DUs, a CU-CP, and one or more CU-UPs. For example... Figure 2As shown, a single CU-CP can be associated with multiple CU-UPs in the gNB. CU-CPs and CU-UPs communicate with each other via an E1 interface using the E1-AP protocol, as specified in 3GPP TS 38.463 (v15.4.0). Additionally, there is an F1 interface between the CU and DU (see...). Figure 1 Functionally, it is split into F1-C between DU and CU-CP and F1-U between DU and CU-UP. Figure 2 The three deployment scenarios of the split gNB architecture shown are CU-CP and CU-UP centralized, CU-CP distributed / CU-UP centralized, and CU-CP centralized / CU-UP distributed.

[0012] Densification through the deployment of more base stations is a mechanism to meet the increasing demands for bandwidth and / or capacity in mobile networks, primarily driven by the growing use of video streaming services. Due to the availability of more spectrum in the millimeter-wave (mmW) band, deploying small cells operating in this band is an attractive deployment option for these purposes. However, the conventional approach of connecting small cells to the operator's backhaul network using fiber optics can ultimately be expensive and impractical. Using radio links to connect small cells to the operator's network is a cheaper and more practical alternative.

[0013] One such approach is the Integrated Access Backhaul (IAB) network, where operators can repurpose radio resources (e.g., those normally used for network access by radio devices or UEs) to connect small cells to the operator's backhaul network. IAB was studied as early as 3GPP within the LTE Rel-10 scope. That work resulted in an architecture based on a relay node (RN) with the functionality of an LTE eNB and a UE modem. The RN is connected to a donor eNB, which has S1 / X2 proxy functionality that hides the RN from the rest of the network. That architecture allows the donor eNB to also know about the UE behind the RN, but hides any UE mobility between the donor eNB and (or one or more) the connected RNs from the network.

[0014] Similar IAB options can also be considered for 5G / NR networks. One difference compared to LTE is the gNB-CU / DU split architecture described above, which separates the time-critical RLC / MAC / PHY protocols from the less time-critical RRC / PDCP protocols. Generally, the 3GPPNRIAB specification reuses existing functions and interfaces defined in NR. Each IAB node can include the functionality of a gNB-DU (also called an "IAB-DU"), which terminates the radio interface layer of the access link toward the served UE and the backhaul link toward the directly downstream (or "sub") IAB node.

[0015] Each IAB node can also include a mobile termination function (referred to as MT or "IAB-MT") that terminates the radio interface layer toward the backhaul link to the direct upstream (or "parent") DU (i.e., the IAB-DU or the donor gNB). The MT functionality is similar to the functionality already specified by 3GPP that enables the UE to access the IAB network as part of the mobile device (ME).

[0016] In addition to the connection to the downstream IAB-MT and / or UE, each IAB-DU also has an upstream F1 connection to the CU portion of the grantor gNB (also referred to as the "IAB grantor CU"). This connection is via a specific DU (also referred to as the "IAB grantor DU") of the grantor gNB. Each IAB grantor CU can be associated with multiple IAB grantor DUs, such as... Figure 1 As shown in the diagram. In some cases, an IAB node may need to be migrated (or moved) during operation, causing its connection to be switched to a different parent DU, i.e., an IAB-DU or an IAB grantor DU. This new parent DU can be connected to the same IAB grantor DU, a different IAB grantor DU but the same IAB grantor CU, or different IAB grantor DUs and CUs. Various issues, topics, and / or challenges arise accompanying the migration of an IAB node to a different IAB grantor CU. Summary of the Invention

[0017] Accordingly, embodiments of this disclosure address these and other challenges of integrating IAB nodes into the RAN, thereby enabling the originally advantageous deployment of IAB solutions.

[0018] Embodiments of this disclosure include methods (e.g., procedures) for migrating an Integrated Access Backhaul (IAB) node from a first Centralized Unit (CU) to a second CU in a wireless network. In various embodiments, these exemplary methods can be performed by the migrating IAB node or a Type 2 parent IAB node (e.g., IAB-DU and IAB-MT).

[0019] These exemplary methods can include receiving a first handover (HO) command from a first CU via a source parent IAB node. The HO command includes an identifier for the target cell for handover. These exemplary methods can also include determining, based on the HO command, that the HO command is for an inter-CU migration from the IAB node to a second CU. These exemplary methods can further include performing modified manipulation of uplink (UL) and / or downlink (DL) data buffered in the IAB node based on the determination that the HO command is for an inter-CU migration, until the execution of the HO command.

[0020] In some embodiments, performing modified manipulation of UL and / or DL ​​data buffered in the IAB node may include one or more of the following operations:

[0021] Forward at least a portion of the DL data buffered in the IAB node;

[0022] Forward at least a portion of the UL data buffered at the IAB node;

[0023] • Delete at least a portion of the DL data buffered in the IAB node; and

[0024] • Delete at least a portion of the UL data buffered in the IAB node.

[0025] In some embodiments, determining the use of HO commands for inter-CU migration can be based on one or more of the following:

[0026] • The target cell identifier does not match any identifier associated with the current serving cell used for the IAB node;

[0027] • The target base station identifier within the target cell identifier does not match the base station identifier associated with the first CU; and

[0028] The HO command contains an explicit indication that the HO is a migration between CUs.

[0029] In some embodiments, these exemplary methods may further include determining that one or more descendant nodes of the IAB node have also undergone inter-CU migration of the second CU. In various embodiments, the determination that one or more descendant nodes have also undergone inter-CU migration may be based on one or more of the following:

[0030] • Determining the use of the HO command for CU-to-CU migration from the IAB node to the second CU;

[0031] • Explicit indications within the HO command regarding one or more downstream nodes also undergoing inter-CU migration; and

[0032] • A second HO command for the child node of the IAB node, the second HO command being sent from the first CU to the child node via the IAB node.

[0033] In some embodiments, these exemplary methods may also include receiving instructions for modified manipulation of buffered UL data and / or buffered DL data. In such embodiments, modified manipulation of the UL and / or DL ​​data buffered at the IAB node is performed according to the instructions. In some embodiments, the instructions may include one or more of the following:

[0034] • One or more first criteria related to the amount of DL data buffered in the IAB node;

[0035] • One or more secondary criteria related to whether DL data buffered in the IAB node should be deleted or forwarded to the corresponding descendant node.

[0036] In such embodiments, the second criterion can include one or more of the following:

[0037] • Indicators that all types of buffered DL data should be deleted or forwarded;

[0038] • A list of backhaul radio link control (BH RLC channels) from which the buffered DL data should be forwarded;

[0039] • A list of BH RLC channels whose buffered DL data should be deleted;

[0040] • A list of access RLC channels to which the buffered DL data should be forwarded;

[0041] • A list of access RLC channels whose buffered DL data should be deleted;

[0042] • A QoS profile and / or priority list should be provided for the forwarding of buffered DL data;

[0043] • The QoS profiles and / or priority lists of the buffered DL data should be removed.

[0044] • A list of Backhaul Adaptation Protocol (BAP) routing identifiers should be provided for forwarding buffered DL data; and

[0045] • The list of BAP routing identifiers that buffer DL data should be removed.

[0046] In some embodiments of these embodiments, the instructions may also include one or more third criteria relating to the amount of UL data buffered at the IAB node and one or more fourth criteria relating to whether a Buffer Status Report (BSR) should be transmitted to the parent node for the UL data buffered at the IAB node. In some embodiments, each of the first and third criteria may identify the amount according to one or more of the following: all buffered data; an explicit amount of buffered data; a percentage of buffered data; duration. In some embodiments, the fourth criterion may include one or more of the following:

[0047] • Instructions that BSR should be transmitted for all types of buffered UL data;

[0048] • A list of BH RLC channels for which BSR should be transmitted;

[0049] • A list of BSR access RLC channels should be transmitted to it;

[0050] • A QoS profile and / or priority list for the BSR should be sent to it;

[0051] • A list of BAP routing identifiers for which BSR should be transmitted.

[0052] In some embodiments, the instructions for modified manipulation of buffered UL data and / or buffered DL data may further include instructions for modified manipulation of UL data buffered at one or more descendant nodes in the IAB node. In such embodiments, these exemplary methods may also include performing modified manipulation of UL data buffered at one or more descendant nodes according to the instructions based on determining an HO command for inter-CU migration, and up to the execution of the HO command.

[0053] In some embodiments, performing modified manipulation of UL data buffered at one or more downstream nodes may include one or more of the following:

[0054] • Provide UL permission for at least a portion of the UL data buffered in one or more child nodes of the IAB node;

[0055] • Suppressing the granting of UL permission to at least a portion of UL data buffered in one or more child nodes; and

[0056] • Provide instructions to one or more child nodes for manipulating UL data buffered in the descendant nodes of one or more child nodes.

[0057] In some embodiments, instructions for modified manipulation of UL data buffered in one or more descendant nodes may include one or more of the following:

[0058] • First configuration for manipulating UL data buffered in the first child node of the IAB node;

[0059] • A second configuration for manipulating UL data buffered in the second child node of the IAB node; and

[0060] • A third configuration for manipulating UL data buffered in the first and second child nodes.

[0061] In some embodiments, the instructions for modified manipulation of UL data buffered in one or more descendant nodes may further include one or more of the following:

[0062] • One or more fifth criteria relating to the amount of UL data buffered in one or more descendant nodes; and

[0063] • One or more sixth criteria related to whether UL approval should be provided for UL data buffered in one or more descendant nodes.

[0064] In various embodiments, the sixth criterion may include one or more of the following:

[0065] • Regarding the requirement to provide UL-approved indicators for all buffered UL data;

[0066] • A list of UL-approved BH RLC channels should be provided.

[0067] • A list of UL-approved access channels for RLC should be provided.

[0068] • A list of QoS profiles and / or priorities authorized by UL should be provided; and a list of BAP routing identifiers authorized by UL should be provided.

[0069] Other embodiments include methods (e.g., procedures) for manipulating the migration of child IAB nodes from a first CU to a second CU in a wireless network. These exemplary methods can be executed by a type 1 parent IAB node (e.g., IAB-DU and IAB-MT).

[0070] These exemplary methods can include receiving a message from a first CU, the message including a handover (HO) command from a sub-IAB node to a target cell. These exemplary methods can also include determining that the HO command is for an inter-CU migration from a sub-IAB node to a second CU. These exemplary methods can further include performing modified operations on one or more of the following based on determining that the HO command is for an inter-CU migration: UL buffered in the sub-IAB node; and DL data buffered in the IAB node and associated with the sub-IAB node.

[0071] In some embodiments, determining that an HO command is used for inter-CU migration can be based on an explicit indication within the message regarding the HO command being used for inter-CU migration in a sub-IAB node. In some embodiments, these exemplary methods may also include receiving instructions for modified manipulation of buffered UL and / or DL ​​data. In such embodiments, modified manipulation of UL data buffered in a sub-IAB node and / or DL ​​data buffered in an IAB node is performed according to the instructions. In several embodiments, the instructions may include one or more of the following:

[0072] • One or more first criteria related to the amount of DL data buffered in the IAB node;

[0073] • One or more second criteria related to whether DL data buffered in the IAB node should be deleted or forwarded to the corresponding downstream node;

[0074] • One or more third criteria relating to the amount of UL data buffered at one or more downstream nodes; and

[0075] • One or more fourth criteria related to whether UL approval should be provided for UL data buffered at downstream IAB nodes.

[0076] In some embodiments, each of the first and third criteria identifies a quantity according to one or more of the following: all buffered data; an explicit amount of buffered data; a percentage of buffered data; and duration (e.g., a timer value). In some embodiments, the second criterion may include one or more of the following:

[0077] • Indicators that all types of buffered DL data should be deleted or forwarded;

[0078] • A list of backhaul radio link control (BH RLC channels) from which the buffered DL data should be forwarded;

[0079] • A list of BH RLC channels whose buffered DL data should be deleted;

[0080] • A QoS profile and / or priority list should be provided for the forwarding of buffered DL data;

[0081] • The QoS profiles and / or priority lists of the buffered DL data should be removed.

[0082] • A list of Backhaul Adaptation Protocol (BAP) routing identifiers should be provided for forwarding buffered DL data; and

[0083] • The list of BAP routing identifiers that buffer DL data should be removed.

[0084] In some embodiments, the fourth criterion may include one or more of the following:

[0085] • Regarding the requirement to provide UL-approved indicators for all buffered UL data;

[0086] • A list of UL-approved backhaul radio link control (BH RLC channels) should be provided.

[0087] • A list of QoS profiles and / or priorities approved by UL should be provided; and

[0088] • A list of UL-approved Backhaul Adaptation Protocol (BAP) routing identifiers should be provided.

[0089] In some embodiments, the exemplary method may also include forwarding HO commands to the child IAB node after completing the modified manipulation of UL data buffered in the child IAB node and / or DL ​​data buffered in the IAB.

[0090] Other embodiments include IAB nodes (e.g., IAB-MT / DU) configured to perform operations corresponding to any of the exemplary methods described herein. Other exemplary embodiments also include non-transitory computer-readable media storing computer-executable instructions that, when executed by a processing circuitry module, configure such IAB nodes to perform operations corresponding to any of the exemplary methods described herein.

[0091] The embodiments disclosed herein can reduce and / or minimize data packet loss before the handover of the migrated IAB node is performed. Furthermore, the embodiments can accelerate the delivery of data packets in flight before the handover is performed. Additionally, the embodiments can avoid unnecessary transmission of packets destined for or sent by nodes that have been migrated to the second CU (i.e., IAB nodes, UEs). Therefore, the embodiments can reduce and / or avoid waste of radio and processing resources and unnecessary energy consumption at the UE and IAB nodes.

[0092] These and other objects, features, and advantages of this disclosure will become apparent when reading the following detailed description in consideration of the accompanying drawings, which are briefly described below. Attached Figure Description

[0093] Figure 1 This shows a high-level view of a 5G network architecture that includes a central unit (CU) – distributed unit (DU) split architecture with gNB.

[0094] Figure 2 Show Figure 1 The control plane (CP) and user plane (UP) interfaces within the split CU-DU architecture are shown.

[0095] Figure 3 A reference diagram showing the Integrated Access Backhaul (IAB) network in standalone mode.

[0096] Figure 4-5 The example IAB user plane (UP) and control plane (CP) protocol stacks are shown respectively.

[0097] Figure 6 This shows a functional view of the example IAB Backhaul Adaptation Protocol (BAP) sublayer.

[0098] Figure 7 The diagram shows four different IAB node migration scenarios labeled AD.

[0099] Figure 8 The example demonstrates the topology adaptation process within a CU, where the target parent IAB node uses an IAB grant DU that is different from the source parent IAB node.

[0100] Figure 9 The demonstration shows the mobility process between gNB-DU.

[0101] Figure 10 This demonstrates the process of establishing a sample bearer context.

[0102] Figure 11-12 The exemplary bearer context release procedures initiated by gNB-CU-CP and gNB-CU-UP are shown respectively.

[0103] Figure 13 A demonstration procedure for inter-gNB UE handover involving gNB-CU-UP changes is shown.

[0104] Figure 14 This demonstrates a sample procedure for gNB-CU-UP entity changes for UE.

[0105] Figure 15 This shows a sample ASN.1 data structure for the HandoverCommand message.

[0106] Figure 16 This illustrates a scenario of migration between IAB nodes (CUs) according to various embodiments of this disclosure.

[0107] Figure 17-18 Exemplary methods (e.g., procedures) performed by an Integrated Access Backhaul (IAB) node in a wireless network, according to various embodiments of this disclosure, are shown.

[0108] Figure 19 An exemplary embodiment of a wireless network is shown.

[0109] Figure 20An exemplary embodiment of the UE is shown.

[0110] Figure 21 Demonstration virtualization environments are shown that can be used to implement various embodiments of the network nodes described herein.

[0111] Figure 22-23 Various exemplary communication systems and / or networks are shown.

[0112] Figure 24-27 It is a flowchart of an exemplary method (e.g., process) for transmitting and / or receiving user data. Detailed Implementation

[0113] The briefly summarized embodiments described above will now be described more fully with reference to the accompanying drawings. These descriptions are provided as examples to illustrate the subject matter to those skilled in the art and should not be construed as limiting the scope of the subject matter solely to the embodiments described herein. More specifically, examples are provided below illustrating operation of various embodiments according to the advantages described above.

[0114] Generally, all terms used herein shall be interpreted in accordance with their ordinary meaning in the relevant art, unless a different meaning is explicitly given and / or implied by the context in which it is used. All references to an element, device, component, part, step, etc., are open-ended and are interpreted as referring to at least one instance of the element, device, component, part, step, etc., unless otherwise expressly stated. The steps of any method and / or process disclosed herein need not be performed in the exact order disclosed, unless a step is explicitly described as occurring after or before another step and / or implied that a step must occur after or before another step. Any feature of any embodiment of the disclosed embodiments can be applied to any other embodiment where appropriate. Similarly, any advantage of any embodiment of the embodiments can be applied to any other embodiment, and vice versa. Other objects, features, and advantages of the disclosed embodiments will be apparent from the following description.

[0115] In addition, the following terms are used throughout the description given below:

[0116] • Radio Access Node: As used herein, a “radio access node” (or equivalent “radio network node,” “radio access network node,” or “RAN node”) can be any node operating in the radio access network (RAN) of a cellular communication network to wirelessly transmit and / or receive signals. Some examples of radio access nodes include, but are not limited to, base stations (e.g., New Radio (NR) base stations (gNB) in 3GPP fifth-generation (5G) NR networks or enhanced or evolved Node B (eNB) in 3GPP LTE networks), base station distributed components (e.g., CU and DU), high-power or macro base stations, low-power base stations (e.g., micro, pico, or femto base stations), integrated access backhaul (IAB) nodes (or their components such as MT or DU), transport points, remote radio units (RRU or RRH), and relay nodes.

[0117] • Core Network Node: As used in this document, a “core network node” is any type of node in the core network. Some examples of core network nodes include, for example, a Mobility Management Entity (MME), a Serving Gateway (SGW), a Packet Data Network Gateway (P-GW), an Access and Mobility Management Function (AMF), a Session Management Function (AMF), a User Plane Function (UPF), a Service Capability Exposure Function (SCEF), and so on.

[0118] • Wireless Device: As used herein, a “wireless device” (or simply “WD”) is any type of device that has the right to access a cellular communication network (i.e., served by it) through wireless communication with network nodes and / or other wireless devices. Wireless communication can involve transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transmitting information over the air. Unless otherwise stated, the term “wireless device” is used interchangeably herein with “user equipment” (or simply “UE”). Some examples of wireless devices include, but are not limited to, smartphones, mobile phones, cellular phones, Voice over IP (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, game consoles or devices, music storage devices, playback devices, wearable devices, wireless endpoints, mobile stations, tablets, laptops, laptop embedded devices (LEEs), laptop mounted devices (LMEs), smart devices, wireless customer premises equipment (CPEs), mobile type communication (MTC) devices, vehicle-to-everything (IoT) devices, in-vehicle wireless terminal devices, mobile terminals (MTs), etc.

[0119] • Radio node: As used herein, “radio node” can be a “radio access node” (or equivalent term) or a “wireless device”.

[0120] • Network Node: As used herein, “network node” is any node that is part of a radio access network (e.g., a radio access node or equivalent term) or a core network of a cellular communication network (e.g., a core network node as described above). A network node is functionally a device that is capable of, configured to, arranged to, and / or operable to communicate directly or indirectly with a wireless device and / or with other network nodes or devices in the cellular communication network, in order to enable and / or provide wireless access to the wireless device and / or perform other functions (e.g., management) in the cellular communication network.

[0121] • Node: As used herein, the term “node” (without any prefix) can be any type of node that can operate or work in conjunction with a wireless network (including RAN and / or core network), including radio access nodes (or equivalent terms), core network nodes, or wireless devices.

[0122] • Parent node: As used herein, the term “parent node” (or “parent IAB node”) refers to a node directly upstream of a particular IAB node in the IAB network (e.g., an IAB node one hop closer to the donor gNB). Even so, if, for example, there are multiple hops to the donor gNB, the parent node may simply be one of the nodes upstream of a particular IAB node in the network.

[0123] • Predecessor node: As used herein, the term “predecessor node” refers to any node upstream of a particular IAB node (e.g., toward the donor gNB) in an IAB network, including the parent node.

[0124] • Sub-node: As used herein, the term “sub-node” (or “sub-IAB node”) refers to a node directly downstream of a particular IAB node in the IAB network (e.g., an IAB node further away from the donor gNB by one hop). Even so, if, for example, there are multiple hops to the served UE, a sub-node may simply be one of the nodes downstream of a particular IAB node in the network.

[0125] • Descendant node: As used herein, the term “descendant node” refers to any node downstream of a particular IAB node (e.g., a node far from the donor gNB) in an IAB network, including child nodes.

[0126] It should be noted that the descriptions presented herein focus on 3GPP cellular communication systems, and therefore 3GPP terminology or similar terminology is generally used. However, the concepts disclosed herein are not limited to 3GPP systems. Other wireless systems (including, without limitation, Wideband Code Division Multiple Access (WCDMA), Global Microwave Access Interoperability (WiMax), Ultra Mobile Broadband (UMB), and Global System for Mobile Communications (GSM)) may also benefit from the concepts, principles, and / or embodiments described herein.

[0127] Furthermore, the functions and / or operations described herein as being performed by wireless devices or network nodes can be distributed across multiple wireless devices and / or network nodes. Additionally, although the term "cell" is used herein, it should be understood that (particularly for 5G NR) a beam can be used instead of a cell, and therefore the concepts described herein also apply to cells and beams.

[0128] As outlined above, IAB nodes may need to be migrated (or moved) during operation, causing their connections to be switched to a different parent node, i.e., an IAB-DU or an IAB grantor DU. This new parent node can be connected to the same IAB grantor DU, a different IAB grantor DU but with the same IAB grantor CU, or a different IAB grantor CU. There are various issues, topics, and / or challenges associated with IAB node migrations to different IAB grantor CUs. This aspect will be discussed in more detail below, following the discussion of the IAB network architecture and protocols.

[0129] Figure 3 A reference diagram is shown of an IAB network in standalone mode, as further described in 3GPP TR 38.874 (version 0.2.1). Figure 3 The IAB network shown includes an IAB entity 340 and multiple IAB nodes 311-315, all of which can be part of a radio access network (RAN 399) such as NG-RAN. IAB entity 340 includes DUs 321 and 322 connected to CUs 330, represented by functions CU-CP 331 and CU-UP 332. IAB entity 340 can communicate with the core network (CN) 350 via the illustrated CU functionality.

[0130] Each of IAB nodes 311-315 connects to the IAB provider via one or more radio backhaul links (also referred to herein as "hops"). More specifically, the mobile termination (MT) functionality of each IAB node 311-315 terminates toward the radio interface layer of the radio backhaul link corresponding to the previous generation DU functionality. This MT functionality is similar to the functionality already specified by 3GPP that enables the UE to access the IAB network and effectively function as part of the mobile device (ME). However, the IAB functionality is transparent to the UE, making it unaware that they are being served by a regular gNB or an IAB provider gNB via one or more intermediate IAB nodes.

[0131] exist Figure 3In this context, a predecessor DU can include DU321 or 322 of IAB implementer 340, and in some cases, the DU functionality of an intermediate IAB node that is a descendant of IAB implementer 340. As a more specific example, IAB node 314 is a descendant of IAB nodes 312 and DU 321, where IAB node 312 is a predecessor of IAB node 314, but DU 321 is a descendant of DU 321, and DU 321 is a predecessor of IAB nodes 312 and 314. The DU functionality of IAB nodes 311-315 also terminates the radio interface layer for radio access links toward the UE (e.g., for network access via the DU) and radio backhaul links toward other descendant IAB nodes. Accordingly, IAB nodes 311, 313, and 314 can be considered as “access IAB nodes” for UEs 301, 303, and 302, respectively, and that term will be used in the same manner below.

[0132] like Figure 3 As shown, the IAB grant 340 can be viewed as a single logical node, which includes a set of functions such as gNB-DU 321-322, gNB-CU-CP 331, gNB-CU-UP 332, and possibly other functions. In some deployments, the IAB grant can be split according to these functions, which can all coexist or not coexist, as allowed by the 3GPP NG-RAN architecture. Furthermore, if some functions currently associated with the IAB grant do not perform IAB-specific tasks, those functions can be moved outside the IAB grant.

[0133] Generally, existing MT, gNB-DU, gNB-CU, UPF, AMF, and SMF, along with their corresponding interfaces NR Uu (between MT and gNB), F1, NG, X2, and N4, serve as the baseline for the IAB architecture. For example, each IAB node DU uses a modified form of F1 (referred to as F1*) to connect to the IAB grant CU. The user plane portion of F1* (referred to as "F1*-U") operates on the RLC channel over the radio backhaul between the MT on the serving IAB node and the DU on the IAB grant.

[0134] Figure 4-5The sample IAB user plane (UP) and control plane (CP) protocol stacks as defined in 3GPP Rel-16 are shown. As illustrated in these figures, the selected protocol stacks reuse the current CU-DU split specified in 3GPP Rel-15. Full F1-U interfaces (GTP-U / UDP / IP) and full F1-C interfaces (F1-AP / SCTP / IP) are terminated at IAB nodes (e.g., regular DUs). Network Domain Security (NDS) can be used to protect UP and CP services: IPsec for UP and Datagram Transport Layer Security (DTLS) for CP. IPsec may also replace DTLS for CP protection.

[0135] A new Backhaul Adaptation Protocol (BAP) layer has been introduced into IAB nodes and IAB implements. The BAP layer routes packets to the appropriate descendant / predecessor nodes. It also maps UE radio bearer data to the appropriate backhaul RLC channel (also referred to herein as "backhaul RLC bearer") and between the ingress and egress backhaul RLC channels in intermediate IAB nodes. A node is a receiver on its ingress BH RLC channel and a transmitter on its egress BH RLC channel, regardless of whether the direction is towards a predecessor or descendant in the IAB network. Conversely, communication between the UE and its access IAB nodes occurs via the "access RLC channel."

[0136] The BAP layer can be configured to meet the end-to-end QoS requirements of radio bearers. On an IAB node, the BAP sublayer contains one BAP entity at the MT function and a separate, co-located BAP entity at the DU function. On an IAB grant DU, the BAP sublayer contains only one BAP entity. Each BAP entity has a transmit portion and a receive portion. Each transmit portion of the BAP entity at one end of the backhaul link has a corresponding receive portion at the other end of the backhaul link (e.g., in an IAB node or an IAB grant DU, depending on the situation).

[0137] Generally, the BAP sublayer expects the lower layers of each RLC entity to provide acknowledged or unacknowledged data transfer services for BAP SDUs. Additionally, the BAP sublayer supports the following functions:

[0138] Data transmission;

[0139] • Determine the BAP destination and path for packets from the upper layer;

[0140] • Determine the egress BH RLC channel for packets routed to the next hop;

[0141] • Route the packet to the next hop;

[0142] • Differentiate between traffic destined for the upper layer and traffic destined for the outbound link; and

[0143] • Process control feedback and polling signaling.

[0144] Figure 6 This diagram shows a demonstrative functional view of the IAB BAP sublayer based on the radio interface protocol architecture defined in 3GPP TS 38.300. Figure 6 In the example, the receiving part on a BAP entity delivers a BAP PDU (e.g., MT-to-DU, or vice versa) to the transmitting part on the same BAP entity in the same node (e.g., received on the ingress BH RLC channel). Similarly, the receiving part may deliver a BAP SDU (e.g., for transmission on the egress BH RLC channel) to the transmitting part on the same BAP entity in the same node. When delivering a BAP SDU, the receiving part removes the BAP PDU header, and the transmitting part adds a BAP header with the same BAP routing ID as that carried in the original BAP PDU header. Therefore, in the implementation, delivering a BAP SDU in this way is functionally equivalent to delivering a BAP PDU.

[0145] Figure 7 The diagram illustrates four different IAB node migration scenarios labeled AD. These scenarios are described below in order of complexity. In all scenarios, the migrated IAB node (“IAB node e”) serves three different UEs labeled UEc, UEd, and UEe.

[0146] In scenario A (“within the grant DU”), IAB node e and its served UEs are moved to a new parent node, IAB node b, within the same IAB grant DU (i.e., DU1). Successful migration within the grant DU requires establishing a UE context for IAB node e in the DU of the new parent node IAB node b, updating the routing table of the IAB node along the path to IAB node e, and allocating resources on the new path. The IP address of IAB node e will remain unchanged, but the F1-U tunnel / connection between grant CU1 and the DU of IAB node e will be redirected through IAB node b.

[0147] In scenario B (“within the grantor CU”), IAB node e and its served UEs are moved to a new parent node, IAB node c, under different IAB grants DU and DU2, but within the same grantor CU 1. The process requirements and / or complexity are the same as in scenario A described above. Furthermore, since the new IAB grant DU (DU2) is connected to the same L2 network, the migrated IAB node c can use the same IP address under the new grant DU2. However, the new grant DU2 will need to use the L2 address of IAB node e to notify the network so that, for example, a mechanism such as Address Resolution Protocol (ARP) can be used to obtain / maintain the same IP address for IAB node e.

[0148] Scenario C is a similar "within-granter CU" migration to Scenario B, but the new granter DU 3 is connected to granter CU1 via a different wired Layer 2 (L2) network. Therefore, a new IP address needs to be assigned to IAB node e. If IPsec is used for the F1-U tunnel / connection between granter CU1 and the DU of IAB node e, it might be possible to use the existing IP address along the path segment between granter CU1 and SeGw, and the new IP address for the IPsec tunnel between SeGw and the DU of IAB node e.

[0149] In scenario D (“Inter-CU” or “Inter-grant CU”), IAB node e and its served UEs are moved to a new parent node, IAB node f, under different grant DU, DU4 and different grant CU, CU2. This is the most complex scenario in terms of process requirements, which exceed the scope of the 3GPP Rel-16 specification.

[0150] During topology adaptation / migration within a CU, both the source parent IAB node and the target parent IAB node are connected to the same IAB grantor CU. The target parent IAB node can use a different IAB grantor DU than the source parent IAB node. The source path may also have one or more nodes shared with the target path. Figure 8 The example demonstrates the topology adaptation process within a CU, where the target parent IAB node uses a different IAB grant DU than the source parent IAB node. Although Figure 8 The operations shown are given numerical labels, but these labels are intended for the convenience of the following description and not to require and / or imply a specific order of operations. In the following description, the terms "parent node" and "parent IAB node" are used interchangeably.

[0151] In Operation 1, the migrated IAB-MT sends a measurement report message to its source parent node gNB-DU. This report is based on the measurement configuration previously received by the migrated IAB-MT from the IAB grantor CU. In Operation 2, the source parent node gNB-DU sends a UL RRC MESSAGE TRANSFER message to the IAB grantor CU to deliver the received measurement report.

[0152] In Operation 3, the IAB grantor CU sends a UE CONTEXT SETUP REQUEST message to the target parent node gNB-DU to create a UE context and establish one or more radio bearers for the migrated IAB-MT. These radio bearers are used by the migrated IAB-MT for its own data and signaling services. In Operation 4, the target parent node gNB-DU responds to the IAB grantor CU with a UE CONTEXT SETUP RESPONSE message.

[0153] In operation 5, the IAB grantor CU sends a UE CONTEXT MODIFICATION REQUEST message to the source parent node gNB-DU. This message includes a generated RRCReconfiguration message. The transmission action indicator in the UECONTEXT MODIFICATION REQUEST message indicates that data transmission to the migrating IAB node should be stopped. In operation 6, the source parent node gNB-DU forwards the received RRCReconfiguration message to the migrating IAB-MT. In operation 7, the source parent node gNB-DU responds to the IAB grantor CU with a UE CONTEXT MODIFICATION RESPONSE message.

[0154] In operation 8, a random access procedure is performed at the target parent node gNB-DU. In operation 9, the migrating IAB-MT responds to the target parent node gNB-DU with an RRCReconfigurationComplete message. In operation 10, the target parent node gNB-DU sends a UL RRC MESSAGE TRANSFER message to the IAB grant CU to transmit the received RRCReconfigurationComplete message. Additionally, UL packets can be sent from the migrating IAB-MT and forwarded to the IAB grant CU via the target parent node gNB-DU. These DL and UL packets belong to the MT's own signaling and data services.

[0155] In operation 11, the IAB grantor CU configures the migration of BH RLC channels and BAP layer routing entries on the target path between the IAB node and the target IAB grantor DU. This step also includes the allocation of one or more TNL addresses that can be routed via the target IAB grantor DU. These configurations can be performed, for example, in an earlier stage after operation 3. The one or more new TNL addresses are included in the RRCReconfiguration message in operation 5.

[0156] In operation 12, all F1-U tunnels and F1-C are switched to use one or more new TNL addresses of the migrated IAB node. In operation 13, the IAB grant CU sends a UE CONTEXT RELEASE COMMAND message to the source parent node gNB-DU. In operation 14, the source parent node gNB-DU releases the context of the migrated IAB-MT and responds to the IAB grant CU with a UE CONTEXT RELEASE COMPLETE message. In operation 15, the IAB grant CU releases the BH RLC channels and BAP routing entries on the source path. The migrated IAB node may further release one or more TNL addresses it uses on the source path. If the source route and destination route have common nodes, the BH RLC channels and BAP routing entries of those nodes do not need to be released in this operation.

[0157] Additionally, operations 11, 12, and 15 must also be performed on the child nodes and other descendant nodes of the migrated IAB node. During this process, the descendant nodes must also switch to the new TNL address anchored in the target IAB grant DU. The IAB grant CU can send these addresses to the descendant nodes and release the old addresses via corresponding RRC signaling. If necessary, the IAB grant CU configures the BH RLC channels on the target path of the descendant nodes, the BAP layer routing entries, and the BH RLC channel mappings on the descendant nodes in the same manner as described in operation 11 for the migrated IAB node. The descendant nodes switch their F1-U and F1-C tunnels to the new TNL address anchored in the new IAB grant DU in the same manner as described in operation 12 for the migrated IAB node. Depending on the implementation, these steps can be performed after or in parallel with the IAB node switchover. In Rel-16, in-flight packets in the UL direction dropped during the migration process may not be recoverable.

[0158] Additionally, in NG-RAN, when a UE moves from one gNB-DU to another gNB-DU within the same gNB-CU, it can utilize the inter-gNB-DU mobility procedure. Figure 9 This demonstrates the mobility process between gNB-DU. Although Figure 9 The operations shown are given numerical labels, but these labels are intended to facilitate the following description, rather than to require and / or imply a specific order of operations.

[0159] In Operation 1, the UE sends a MeasurementReport message to the source gNB-DU. In Operation 2, the source gNB-DU sends a UL RRC MESSAGE TRANSFER message to the gNB-CU to transmit the received MeasurementReport message. In Operation 3, the gNB-CU sends a UE CONTEXT SETUP REQUEST message to the target gNB-DU to create a UE context and establish one or more data radio bearers. The UE CONTEXT SETUP REQUEST message includes HandoverPreparationInformation. In Operation 4, the target gNB-DU responds to the gNB-CU with a UE CONTEXT SETUPRESPONSE message.

[0160] In operation 5, the gNB-CU sends a UE CONTEXT MODIFICATION REQUEST message to the source gNB-DU. This message includes the generated RRCReconfiguration message and indicates that data transmission for the UE should be stopped. The source gNB-DU also sends a downlink data delivery status frame to notify the gNB-CU of the unsuccessfully transmitted downlink data to the UE. In operation 6, the source gNB-DU forwards the received RRCReconfiguration message to the UE. In operation 7, the source gNB-DU responds to the gNB-CU with a UECONTEXT MODIFICATION RESPONSE message.

[0161] In operation 8, the UE performs a random access procedure toward the target gNB-DU. The target gNB-DU sends a downlink data delivery status frame to notify the gNB-CU. DL packets (which may include PDCPPDUs that were not successfully delivered in the source gNB-DU) are sent from the gNB-CU to the target gNB-DU. Whether DL user data transmission to the gNB-DU begins before or after receiving the downlink data delivery status depends on the gNB-CU implementation.

[0162] In operation 9, the UE responds to the target gNB-DU with an RRCReconfigurationComplete message. In operation 10, the target gNB-DU sends a UL RRC MESSAGE TRANSFER message to the gNB-CU to transmit the received RRCReconfigurationComplete message. DL packets are sent to the UE, and UL packets sent from the UE are forwarded to the gNB-CU via the target gNB-DU. In operation 11, the gNB-CU sends a UE CONTEXT RELEASECOMMAND message to the source gNB-DU. In operation 12, the source gNB-DU releases the UE context and responds to the gNB-CU with a UECONTEXT RELEASE COMPLETE message.

[0163] In the split CU-DU gNB architecture, the bearer context establishment process can be used to establish a context for the user plane bearer on the F1-U interface between gNB-CU and gNB-DU. Figure 10 This demonstrates the process of establishing a sample bearer context. Although Figure 10 The operations shown are given numerical labels, but these labels are intended to facilitate the following description, rather than to require and / or imply a specific order of operations.

[0164] In Operation 0, bearer context establishment is triggered in gNB-CU-CP. This can be associated, for example, with an SGNB ADDITION REQUEST message from another network, such as for initiating dual connectivity toward the UE. In Operation 1, gNB-CU-CP sends a BEARER CONTEXT SETUP REQUEST message containing ULTNL address information for S1-U or NG-U, and, if requested, DLTNL address information for X2-U or Xn-U, to establish a bearer context in gNB-CU-UP. For NG-RAN, gNB-CU-CP determines the flow to DRB mapping and sends the generated SDAP and PDCP configurations to gNB-CU-UP.

[0165] In operation 2, gNB-CU-UP responds with a BEARER CONTEXT SETUP RESPONSE message, which includes the ULTNL address information for F1-U and the DLTNL address information for S1-U or NG-U, and, if required, the ULTNL address information for X2-U or Xn-U. Indirect data transmission via gNB-CU-UP is not excluded here.

[0166] In operation 3, the F1 UE context establishment procedure is performed to establish one or more bearers in the gNB-DU. In operation 4, the gNB-CU-CP sends a BEARER CONTEXT MODIFICATION REQUEST message, which contains DLTNL address information and PDCP status for the F1-U. In operation 5, the gNB-CU-UP responds with a BEARER CONTEXT MODIFICATION RESPONSE message.

[0167] Similarly, the bearer context release procedure can be used to release the context of existing user plane bearers used on the F1-U interface between gNB-CU and gNB-DU. Figure 11 This demonstrates a sample bearer context release procedure initiated by gNB-CU-CP. Although Figure 11 The operations shown are given numerical labels, but these labels are intended to facilitate the following description and not to require and / or imply any particular order of operations.

[0168] In Operation 0, a bearer context release is triggered in the gNB-CU-CP. This can be associated, for example, with an SGNB RELEASE REQUEST message from the master node toward the UE in dual connectivity. In Operation 1, the gNB-CU-CP sends a BEARER CONTEXT MODIFICATION REQUEST message to the gNB-CU-UP. In Operation 2, the gNB-CU-UP responds with a BEARER CONTEXT MODIFICATION RESPONSE message carrying the PDCP UL / DL status.

[0169] In Operation 3, the F1 UE context modification procedure is executed to stop data transmission for the UE. When UE scheduling is stopped depends on the gNB-DU implementation. Generally, Operations 1-3 are only executed when it is necessary (e.g., for bearer type changes) to maintain the PDCP state of (one or more) bearers.

[0170] In operation 4, gNB-CU-CP receives a UE CONTEXT RELEASE message from the MeNB during EN-DC operation, as described in section 8.4.2.1 of 3GPP TS 38.331. In operation 5, gNB-CU-CP sends a BEARER CONTEXT RELEASE COMMAND to gNB-CU-UP. In operation 6, the F1 UE context release procedure is performed to release the UE context in gNB-DU. In operation 7, gNB-CU-UP responds to the message in operation 5 with a BEARER CONTEXTRELEASE COMPLETE message.

[0171] Figure 12 This demonstrates a sample bearer context release procedure initiated by gNB-CU-UP. Although Figure 12 The operations shown are given numerical labels, but these labels are intended to facilitate the following description, rather than to require and / or imply a specific order of operations.

[0172] In Operation 0, for example, a bearer context release is triggered in gNB-CU-UP due to a local fault. In Operation 1, gNB-CU-UP sends a BEARER CONTEXT RELEASE REQUEST message to request the release of the bearer context in gNB-CU-UP. This message may contain the PDCP state. In Operations 2-5, if the PDCP state needs to be maintained, the E1 bearer context modification and F1 UE context modification procedures are performed. The E1 bearer context modification procedure is used to deliver data forwarding information to gNB-CU-UP. gNB-CU-UP can receive the UE context release from the MeNB.

[0173] In operation 6, gNB-CU-CP sends a BEARER CONTEXT RELEASE COMMAND message to release the bearer context in gNB-CU-UP. In operation 7, gNB-CU-UP responds with a BEARER CONTEXTRELEASE COMPLETE message to confirm the release of the bearer context, including data forwarding information. In operation 8, the F1 UE context release procedure can be executed to release the UE context in gNB-DU.

[0174] In an NR network, a gNB can attempt to hand over a UE to another gNB. This may involve changes to the gNB-CU-CP entity used for the UE. Figure 13This illustrates a sample procedure for inter-gNB UE handover involving gNB-CU-UP changes. The UE (not shown) hands over from a source gNB to a target gNB; both have corresponding DU, CU-CP, and CU-UP entities. Although Figure 13 The operations shown are given numerical labels, but these labels are intended to facilitate the following description, rather than to require and / or imply a specific order of operations.

[0175] In Operation 1, the source gNB-CU-CP sends a HANDOVER REQUEST message to the target gNB-CU-CP. In Operations 2-4, the bearer context establishment procedure is performed as described in Section 8.9.2 of 3GPP TS 38.331. In Operation 5, the target gNB-CU-CP responds to the source gNB-CU-CP with a HANDOVER REQUEST ACKNOWLEDGE message. In Operation 6, the F1 UE context modification procedure is performed to stop UL data transmission on the gNB-DU and send a handover command to the UE.

[0176] In operations 7-8, the bearer context modification procedure initiated by the gNB-CU-CP is executed to enable the gNB-CU-CP to retrieve the PDCP UL / DL status and exchange bearer data forwarding information. In operation 9, the source gNB-CU-CP sends an SN STATUS TRANSFER message to the target gNB-CU-CP. In operations 10-11, the bearer context modification procedure is executed as described in section 8.9.2 of 3GPP TS38.331. In operation 12, data forwarding from the source gNB-CU-UP to the target gNB-CU-UP can be performed.

[0177] In operations 13-15, a path handover process is performed to update the DLTNL address information for the NG-U heading towards the core network. In operation 16, the target gNB-CU-CP sends a UE CONTEXT RELEASE message to the source gNB-CU-CP. Operations 17-19 can be related to the above. Figure 11 Operations 5-7 are basically similar.

[0178] In an NR network, a gNB can have multiple gNB-CU-UP entities. In some situations, the gNB may need to change which of the gNB-CU-UP entities is serving the UE, for example, due to a UE handover. Figure 14 This illustrates a demonstration procedure for intra-gNB changes to the gNB-CU-UP entity of a UE (not shown). The UE is changed from the source gNB-CU-UP to the target gNB-CU-UP. Although Figure 14The operations shown are given numerical labels, but these labels are intended to facilitate the following description, rather than to require and / or imply a specific order of operations.

[0179] In Operation 1, a change to gNB-CU-UP is triggered in gNB-CU-CP based on, for example, a measurement report from the UE. In Operations 2-3, the bearer context establishment process is as described above. Figure 10 The process is executed as described. In operation 4, the F1 UE context modification procedure is performed to change the ULTNL address information of the F1-U for one or more bearers in the gNB-DU. In operations 5-6, the bearer context modification procedure initiated by the gNB-CU-CP is performed to enable the gNB-CU-CP to retrieve the PDCP UL / DL status and exchange bearer data forwarding information.

[0180] In operations 7-8, the bearer context modification procedure is performed as described in section 8.9.2 of 3GPP TS 38.331. In operation 9, data forwarding from the source gNB-CU-UP to the destination gNB-CU-UP can be performed. In operations 10-12, a path switching procedure is performed to update the DLTNL address information of the NG-U toward the core network. In operations 13-14, the bearer context release procedure initiated by the gNB-CU-CP is as described above. Figure 11 It will be executed as described.

[0181] UE mobility operations across different gNBs (or different gNB-CUs) involve various messages via the Xn interface between gNBs, including the messages shown in the accompanying figures above. The following messages are particularly important:

[0182] • HANDOVER REQUEST, sent from the source gNB to the target gNB, requests resources to be prepared for UE handover. Example content is shown in Table 1 below.

[0183] • A HANDOVER REQUEST ACKNOWLEDGE is sent from the target gNB to the source gNB to notify it of the resources prepared for the UE in the target gNB. An example is shown in Table 2 below.

[0184] • SN STATUS TRANSFER, sent from the source gNB to the target gNB, to transmit the UL / DLPDCP sequence number (SN) and superframe number (HFN) status during handover or for dual connectivity toward the UE. An example is shown in Table 3 below.

[0185] • HandoverCommand, sent by the target gNB, to transmit the handover command message prepared by the target gNB for the UE. Figure 15 The example ASN.1 data structure for the HandoverCommand message is shown. Note that the handoverCommandMessage information element (IE) contains the RRCReconfiguration message used by the UE to perform the handover. In the following text, the term "handover command" generally refers to the RRCReconfiguration message, which contains the reconfigurationWithSync for the UE's primary cell group (MCG).

[0186] Table 1.

[0187]

[0188]

[0189]

[0190] Table 2.

[0191]

[0192]

[0193] Table 3.

[0194]

[0195] The list of PDU session resources to be established contained in the HANDOVER REQUEST message includes information related to the PDU session resources used during UE context transfers between NG-RAN nodes (e.g., gNBs). An example is shown in Table 4 below.

[0196] Table 4.

[0197]

[0198]

[0199] Similarly, the list of admitted PDU session resources and the list of unadmitted PDU session resources included in the HANDOVER REQUEST ACKNOWLEDGE message (each) report whether the admission of the requested PDU session resource was successful or failed. Examples are shown in Tables 5-6 below.

[0200] Table 5.

[0201]

[0202]

[0203] Table 6.

[0204]

[0205] In addition, the UE mobility procedure can involve various messages via the F1 interface between the CU and DU, including the messages shown in the accompanying figures above. The following messages are particularly important:

[0206] • INITIAL UL RRC MESSAGE TRANSFER, sent by gNB-DU, to transmit the initial UL layer 3 message to gNB-CU via the F1 interface. An example is shown in Table 7 below.

[0207] • INITIAL DL RRC MESSAGE TRANSFER, sent by gNB-CU, to transmit the initial DL layer 3 message to gNB-DU via the F1 interface. An example is shown in Table 8 below.

[0208] Table 7.

[0209]

[0210]

[0211] Table 8.

[0212]

[0213]

[0214] Unlike intra-CU migrations, all UEs and IAB nodes served by an IAB node (i.e., a “migrating node”) migrating directly or indirectly between two different CUs must also receive a corresponding `reconfigurationWithSync` message to change their security keys. This is because their respective UE / MT contexts are relocated, and the 3GPP specification mandates a security key change whenever the node terminating the PDCP connection changes. Such inter-CU migrations can be caused by radio link failures (RLFs), load balancing, and / or IAB node mobility, among other reasons. Unless otherwise stated, the terms “migration” and “handover” are used interchangeably in the following description of an IAB node that is changing its grantor CU (which may be referred to as a gNB-CU or more simply as a CU).

[0215] Once a handover command containing `reconfigurationWithSync` has been received and processed by the IAB node (i.e., the MT) or the UE, the security key is changed, and the M / UE will be unable to properly decrypt (and / or verify integrity, if configured) any old packets (which were encrypted with the old security key). The same applies to the key used by the CU to decrypt data received from the MT / UE.

[0216] Even so, it is unclear how to manipulate DL packets from the migrating IAB node and its parent node that have been transmitted from the source donor CU to the migrating IAB node (or to any other IAB node or UE directly or indirectly served by such a migrating IAB node) and are currently traversing the source path, but have not yet reached their destination when the HO command is issued from the network. Furthermore, it is unclear how to manipulate UL packets from the migrating IAB node and its parent node that are buffered when the HO command is issued from the network and are awaiting transmission from the migrating IAB node.

[0217] This lack of clarity can cause at least two problems. First, such packets may never be correctly received by the intended device, leading to packet loss and potentially increased data traffic due to retransmissions of lost packets. Second, because the intended device cannot correctly receive these packets, their transmission results in wasted radio and processing resources and unnecessary energy consumption at the UE and IAB nodes.

[0218] Embodiments of this disclosure address these and other problems, challenges, and / or issues by providing mechanisms for IAB nodes migrating from a first CU to a second CU (“migrating IAB nodes”) and for parent IAB nodes of the migrating IAB nodes to manipulate pending UL data from the migrating IAB nodes and / or DL ​​data buffered at the parent IAB node and associated with the migrating IAB nodes (i.e., expected to be sent to the migrating IAB nodes or any of their descendant nodes).

[0219] In various embodiments, such mechanisms can include operations such as determining whether an IAB node migration is an inter-CU handover, and / or receiving instructions / configurations regarding how to perform modified control over packets during the migration. Modified control can include receiving, transmitting, forwarding, and / or deleting UL and / or DL ​​data. Upon determining an inter-CU handover and / or receiving an explicit instruction to perform modified control over UL / DL packets, the parent IAB node can perform this modified control before, during, or after forwarding the handover command to the migrating IAB node, and / or the migrating IAB node can perform the modified control before executing the handover command. Modified control can be performed on DL packets buffered at the migrating IAB node, DL packets buffered at the parent IAB node, and / or UL packets buffered at the migrating IAB node.

[0220] By operating in this manner, the embodiments can reduce and / or minimize data packet loss before the handover of the migrated IAB node is performed. Furthermore, the embodiments can accelerate the delivery of data packets that are "in flight" before the handover is performed. Additionally, the embodiments can avoid unnecessary transmission of packets destined for or sent by nodes that have already been migrated to the second CU (i.e., IAB nodes, UEs).

[0221] While the embodiments are primarily described based on UP data, various embodiments are also suitable for performing similar operations on CP data (e.g., RRC messages, F1-AP messages, etc.). Generally, buffering CP data at intermediate IAB nodes is considered not a major problem because CP messages are associated with separate BH RLC channels that have higher priority than UP data. However, in some deployments, there may be prioritization among CP data from different UE / IAB nodes, which could lead to a considerable amount of CP data buffering in intermediate nodes. This buffered CP data can suffer from similar problems to buffered UP data, which can be addressed through various embodiments of this disclosure.

[0222] Figure 16 This illustrates exemplary IAB node CU migration scenarios of various embodiments of this disclosure. In particular, Figure 17 The diagram illustrates a scenario where node IAB2 is a child of node IAB1 at time t1, but is migrated to become a child of node IAB5 at time t1+x. IAB1 communicates with donor CU1 via donor DU1, while IAB5 communicates with donor CU2 via donor DU2.

[0223] Figure 16In this context, nodes IAB2, IAB3, and IAB4 are "migrating IAB nodes." In other words, even if IAB3 and IAB4 do not relocate their radio links with their respective parent IAB nodes, the default assumption is that IAB3 and IAB4 will also change the CU along with the migration of IAB2. Exceptions may exist, as discussed in more detail below.

[0224] In the following text, "Type 1 parent node" refers to the source parent node (IAB node or grantor DU) of an IAB node that is migrated to another CU, and the source parent node is different from the target parent node of the migrated IAB node. In other words, the Type 1 parent node is not migrated, but its descendant IAB nodes and / or UEs are migrated. Figure 17 In the diagram, node IAB1 is the parent node of type 1.

[0225] In the following text, "Type 2 parent node" refers to the source parent node (IAB node or grantor DU) of an IAB node that is migrated to another CU, and the source parent node is the same as the target parent node of the migrated IAB node. In other words, the Type 2 parent node is migrated together with its descendant IAB nodes and / or UEs. Figure 17 In the table, nodes IAB2 and IAB3 are type 2 parent nodes of IAB3 and IAB4, respectively.

[0226] Generally, a migration IAB node knows it is receiving a handover (HO) command (i.e., an RRCReconfiguration message containing MCG's reconfigurationWithSync), but it may not necessarily know whether the HO command is for an inter-CU handover. In various embodiments, the migration IAB node can determine whether the handover it is performing is an inter-CU handover in several ways, as described below.

[0227] In some embodiments, the migration IAB node can check whether the target cell indicated in the HO command is the same as the current serving cell (for no CA) or whether it is the current PCell or SCell (if a CA is used). If any of those criteria are met, the migration IAB node can infer that it is not involved in inter-CU migration. However, if none of these criteria are met, the migration IAB node will still not be able to distinguish the following: 1) the target cell belongs to the same DU as the currently serving cell(s) that are providing services to the migration IAB node; 2) the target cell belongs to another DU within the same CU as the current serving DU; and 3) the target cell belongs to a DU of another CU.

[0228] In NR, the CGI (Cell Global Identifier) ​​is 36 bits in size. The leftmost (most significant) bit of the CGI provides a unique gNB identifier (i.e., gNB ID, bits 22 to 32, depending on the network implementation). The rightmost (least significant) bit identifies the cell within that gNB and is called the cell identifier (i.e., CI, bits 4 to 14). In other words, CGI = gNB ID + CI.

[0229] In some embodiments, the migrating IAB node can detect whether the source and target cells used for handover belong to the same CU based on the gNB ID portion of the CGI associated with the corresponding cell. For example, the migrating node can compare two gNB IDs, and if the two gNB IDs are different, determine that the HO is within the CU.

[0230] In other embodiments, an explicit indicator is included in the HO command to indicate that the switch involves an inter-CU migration. For example, a new field can be included in the reconfigurationWithSyncIE of the MCG configuration. Example values ​​for this field can include {non-HO, intra-DU, intra-CU, inter-CU}.

[0231] Other techniques can be used by the Type 1 parent node to determine whether the handover of the migrating IAB node is between CUs. As described above, during the HO (Hogging) period, the gNB-CU sends a UE CONTEXT MODIFICATION REQUEST message to the source gNB-DU. This message includes the HO command and indicates that data transmission to the UE or IAB-MT should be stopped (i.e., the transmission action indicator IE is set to the value "stop"). The source gNB-DU also sends a Downlink Data Delivery Status (DDDS) frame to notify the gNB-CU of any unsuccessfully transmitted DL data to the UE or IAM-MT.

[0232] However, the "stop" instruction for UE or IAB-MT transmissions does not necessarily indicate that the handover is between CUs. For example, the transmission action indicator can also take the value "restart," and a CU may use this value to start / stop DL transmissions for various reasons (such as flow control). In fact, the Type 1 parent node typically does not know whether a UE CONTEXT MODIFICATION REQUEST has been sent for handover, as it should transparently convey the content of that message to the UE. In other words, from the parent node's perspective, the HO command is simply an octal string.

[0233] Later during the HO process, the parent node (IAB-DU or Applicant-DU) will receive a UE CONTEXT RELEASE message from the CU. Even through that message, the Type 1 parent node cannot be certain that an HO is in progress. This is because the CU may have already decided to release the UE to the RRC_IDLE state (from RRC_CONNECTED) in the previous RRC message included in the UE CONTEXT MODIFICATION REQUEST message, and subsequently sent a UE CONTEXT RELEASE message to the DU.

[0234] Accordingly, embodiments include various techniques for a Type 1 parent node to determine whether a UE CONTEXT MODIFICATION REQUEST message contains a HO command, and if so, whether it is an inter-CU HO. In some embodiments, the IAB-DU is able to decrypt / understand the RRC message contained in the UE CONTEXT MODIFICATION REQUEST message, and thereby determine whether it is a HO, and also whether it is an inter-CU HO. However, this may conflict with the CU / DU split security principle, where security keys should only be available to the CU terminating the PDCP. Furthermore, security keys are typically deployed in a physically secure location that is not physically accessible to intruders / hackers for tampering.

[0235] In other embodiments, new explicit indicators can be included in the F1 UE CONTEXT MODIFICATIONREQUEST message to indicate that the RRC message contained in that message is a HO command. Table 9 below describes exemplary indicators according to these embodiments. The fields are enumerated data types, where the value “intra-DU” indicates that it is a HO served by the source DU as well as the target cell, “intra-CU” indicates an intra-CU handover with a change in the DU, “inter-CU” indicates a change in both the CU and the DU, and “non-HO” indicates that it is a non-HO related message.

[0236] Table 9.

[0237]

[0238] The implementation that can be used by a Type 1 parent node can also be used by a Type 2 parent node to determine whether the handover of a migrating IAB node is between CUs. However, since a Type 2 parent node is also a migrating node, it receives the HO command of its MT before or simultaneously with the UE CONTEXT MODIFICATION REQUEST message (containing the HO command) is sent to its descendant node. For example, a UE CONTEXT MODIFICATION REQUEST message containing the HO command sent to IAB3-MT can be embedded in the HO command sent to IAB2-MT. Subsequently, IAB2-MT can pass the message to IAB2-DU, which extracts the HO command and passes it to IAB3-MT.

[0239] Accordingly, the Type 2 parent node can also use one of the embodiments described above for the migrating IAB node to determine whether the HO command for its MT is an inter-CU handover. If so, it can infer that its descendant UEs and IAB nodes will also encounter an inter-CU handover. However, there may be situations where this is not the case. One such situation is an implementation where the migrating IAB node can participate in the inter-CU migration, but its descendant IAB nodes remain connected to the source CU after the migration of the IAB node. In such cases, the target CU will act as a proxy for the CP / UP services of all IAB nodes and UEs served by the migrating IAB node. In these embodiments, an indication may be provided to the Type 2 parent node's MT in the handover command to indicate that the inter-CU handover is being performed for the migrating IAB node, but the descendant IAB nodes and UEs of the migrating node will not be subject to inter-CU migration.

[0240] In some embodiments, instructions can be provided to a Type 1 parent node relating to modified manipulation of buffered DL packets associated with the migrating child node or UE in its transport buffer, and buffered UL data awaiting transmission by the migrating child node. In some embodiments, instructions can be provided to a migrating IAB node parent relating to modified manipulation of buffered data in its own UL and DL transport buffers. In some embodiments, information provided to the Type 1 parent node and information provided to the migrating IAB node can be provided to a Type 2 parent node. Several options are described below.

[0241] As described above, the BAP layer delivers BAP PDUs to the RLC entity via BH RLC channels, each BH RLC channel being a BH RLC channel ID and / or a corresponding LCID identifier. The RLC entity processes RLC SDUs and delivers RLC PDUs to the MAC via BH logical channels identified by LCIDs. This means that each BH RLC channel ID maps to one LCID. Therefore, when the following discussion refers to a list of BH (RLC) channels, it may mean a list of RLC channel IDs or a list of LCIDs.

[0242] In various embodiments, the instructions provided to the type 1 or type 2 parent node in relation to the modified manipulation can include, individually or in any combination, any of the following items related to DL data (i.e., to the migration child IAB node):

[0243] • An indicator regarding whether DL data should be forwarded or deleted (i.e., applicable to all BH RLC channels);

[0244] • A list of BH RLC channels whose buffered data should be forwarded;

[0245] • A list of BH RLC channels whose data should be deleted;

[0246] • A list of QoS profiles (e.g., 5QI) and / or priorities (for user plane and control plane BH RLC channels, respectively) for which the buffered data should be forwarded;

[0247] • A list of QoS profiles (e.g., 5QI) and / or priorities (for user plane and control plane BH RLC channels respectively) for which buffered data should be deleted; and

[0248] • A list of BAP routing IDs, where packets carrying these BAP routing IDs will be forwarded or deleted.

[0249] In various embodiments, "DL data to be forwarded" can refer to any of the following:

[0250] • All buffered data.

[0251] • The amount of data or the number of groups that are explicitly indicated.

[0252] • Until a certain percentage of data is received (e.g., 50%), where the value / percentage is included in the configuration provided to the parent node. This may be provided individually for each BH RLC channel, for each BAP routing ID, for each QoS profile and / or BH RLC channel priority, for a set of BH RLC channels, for a set of BAP routing IDs, for a set of QoS profiles and / or BH RLC channel priorities, or only one value applicable to all data.

[0253] • The amount of data corresponding to a specific duration. For example, a timer value may also be included and specified with a similar granularity to the percentage values ​​described above. In some embodiments, both may be combined, for example, forwarding until 50% of the DL buffered data is reached or until 30ms have elapsed, whichever occurs first. After the timer expires, the data may be deleted.

[0254] In various embodiments, the instructions provided to the Type 1 or Type 2 parent node in relation to the modified manipulation can include, individually or in any combination, any of the following items related to UL data (i.e., from the migration sub-IAB node):

[0255] • An indicator that suggests whether UL permission should be granted for pending data (i.e., for all BH RLC channels);

[0256] • A list of UL-approved BH channels should be provided.

[0257] • A list of QoS profiles (e.g., 5QI) and / or priorities (for user plane and control plane BH RLC channels respectively) for UL-approved BH RLC channels should be provided; and

[0258] • A list of BAP routing IDs, where packets carrying these BAP routing IDs will be forwarded or deleted.

[0259] In various embodiments, "UL grant" can refer to one or more UL grants relating to any of the following quantities and / or conditions:

[0260] • Until all UL buffer data at the migration child node has been received.

[0261] • Until a certain percentage of UL data has been received (e.g., 50%), where the value / percentage is included in the configuration provided to the parent node. This may be provided individually for each BH RLC channel, for each BAP routing ID, for each QoS profile and / or BH RLC channel priority, for a set of BH RLC channels, for a set of BAP routing IDs, for a set of QoS profiles and / or BH RLC channel priorities, or only one value applicable to all UL data.

[0262] • UL grant corresponding to a specific duration. For example, a timer value may also be included and specified with a granularity similar to the percentage values ​​described above. In some embodiments, these two may be combined, for example, UL grant may be provided until 50% of the UL buffer data is received from the child node or until 30ms have elapsed, whichever occurs first. After the timer expires, the UL data may be deleted.

[0263] In various embodiments, the UL and DL configurations may be separate or identical, or they may have common and separate parts. Instructions can include the same or different values ​​for UL and DL, such as for the percentage and timer values ​​described above.

[0264] As described above, the migrating IAB node whose child IAB node is also migrating is called the Type 2 parent IAB node. Therefore, the migrating (Type 2 parent) IAB node can receive instructions related to the modified manipulation of UL and DL data described above for the Type 2 parent IAB node. If the migrating IAB node does not have migrating child IAB nodes, the migrating (non-parent) IAB node will not receive instructions related to the modified manipulation of UL and DL data described above for the Type 2 parent IAB node. The instructions provided to the migrating (non-parent) IAB node related to the modified manipulation can, individually or in any combination, include any of the following items related to UL data:

[0265] • An indicator regarding whether the UL Buffer Status Report (BSR) should be sent to the parent node (i.e., applicable to all BH RLC channels);

[0266] Its UL BSR should be sent to the parent node's list of BH RLC channels;

[0267] • A list of QoS profiles (e.g., 5QI) and / or priorities (for user plane and control plane BH RLC channels respectively) for which it will send UL BSRs to the parent node; and

[0268] • A list of BAP route selection IDs that should be provided for sending the UL BSR to the parent node.

[0269] In various embodiments, "UL BSR" can refer to one or more UL BSRs relating to any of the following quantities and / or conditions:

[0270] • Until all buffered UL data has been transmitted to the migration IAB node.

[0271] • Until the explicitly indicated amount of data or number of packets has been transmitted.

[0272] • Until a certain percentage of the buffered UL data has been transmitted (e.g., 50%), where the value / percentage is included in the instructions provided to the migration IAB node. This may be provided individually for each BH RLC channel, for each BAP routing ID, for each QoS profile and / or BH RLC channel priority, for a set of BH RLC channels, for a set of BAP routing IDs, for a set of QoS profiles and / or BH RLC channel priorities, or only one value applicable to all UL data.

[0273] • For a specific duration. For example, a timer value may also be included and specified with a granularity similar to the percentage values ​​described above. In some embodiments, these two may be combined, for example, a UL BSR may be provided until 50% of the UL buffered data has been transmitted or until 30ms has elapsed, whichever occurs first. After the timer expires, the buffered UL data may be deleted.

[0274] In the case of an immediate group switch, the above information can be provided for each migrated child node, in a group configuration applicable to all migrated child nodes, or in a combination thereof. For example, if child nodes x and y are part of the group switch, their Type 1 parent node may receive a modified control configuration, such as any of the following:

[0275] • Configurations related to x (e.g., forwarding data from BH RLC CH1, deleting data from BH RLC CH2) and configurations related to y (e.g., deleting data from BH RLC CH1, forwarding data from BH RLC CH2);

[0276] • Common configurations related to both x and y (e.g., forwarding data from BH RLC channels where 5QI = n, deleting data from BH RLC channels where 5QI = m); or

[0277] • Common configurations related to both x and y (e.g., forwarding data from BH RLC channels where 5QI = n), configurations related to x (e.g., deleting data from BH RLC channels where 5QI = m), and configurations related to y (e.g., deleting data from BH RLC channels where 5QI = m).

[0278] Compared to a Type 1 parent node, an additional consideration when migrating an IAB node is the data for the UE that will migrate with the IAB node. This includes, for example, DL data buffered at the IAB node and intended for transmission to the UE via the access RLC channel between the IAB node and the UE, and UL data buffered at the UE and intended for transmission via the access RLC channel. Several exemplary mechanisms can be envisioned for manipulating data associated with the access UE at the IAB node.

[0279] In some embodiments, all of the above considerations / configurations for data associated with the BH RLC channel may also be applied to the access RLC channel and its associated DL / UL data. In other embodiments, individual considerations / configurations may be provided that are applicable to the access RLC channel and its associated DL / UL data but not to the BH RLC channel. In other embodiments, combinations of these approaches may be used.

[0280] For example, a common configuration can be used for some data associated with the BH RLC channel and some data associated with the access RLC channel, while a separate configuration can be used for the remaining data associated with the BH RLC channel and the remaining data associated with the access RLC channel. As a more specific example, the example configurations of child nodes x and y can be adapted for use with both the access RLC channel and the BH RLC channel. Similar to the BH RLC embodiment described above, the modified control configurations of UL and DL for the access RLC channel can be common, separate, or have both separate and common parts. The embodiments described above for group handover of IAB nodes (e.g., BH RLC channels) can also be adapted for UE group handover (e.g., access RLC channels).

[0281] In most cases, IAB-MT is not expected to have an associated DRB (except perhaps for OAM purposes). However, if IAB-MT does have an associated DRB, the embodiments described above with respect to UE DRB / data can also be adapted to IAB-MTDRB / data.

[0282] In various embodiments, the Type 1 and Type 2 parent nodes and the migration IAB node are capable of performing a variety of operations when it is determined that: 1) the switching of the migration IAB node is an inter-CU switch, and / or 2) there is an explicit indication of modified manipulation of UL / DL data packets during migration. These are described in more detail below.

[0283] Regarding manipulation of DL data, a Type 1 parent node can perform any of the following operations during any of these determinations:

[0284] Before forwarding the switchover command to the child IAB node, the parent node forwards (e.g., schedules and / or transmits) the command for migrating the child IAB node (e.g., ...). Figure 16 All DL data packets buffered by IAB2 in the middle.

[0285] • Before forwarding the switch command to the child IAB node, the parent node deletes all DL data packets buffered for migrating the child IAB node.

[0286] Before forwarding the handover command to the child IAB node, forward a subset of the DL packets buffered by the child IAB node for migration, and delete the remaining data packets in these buffered DL data packets.

[0287] Several examples are provided to illustrate the third option among these options. In the first example, the Type 1 parent node forwards only buffered DL data packets with destination BAP routing IDs(s) corresponding to the child IAB nodes. Conversely, DL packets with destination BAP routing IDs(s) different from those of the child IAB nodes but mapped to be forwarded via the child IAB nodes are dropped. Figure 16 In the example shown, this means that only packets with IAB2(one or more) BAP routing IDs are forwarded, while those with IAB3 and IAB4 are dropped.

[0288] As a second example, the Type 1 parent node only forwards buffered DL packets mapped to the BH RLC channel and instructed to be forwarded, and deletes the remaining buffered DL data packets. As a third example, the Type 1 parent node deletes DL packets mapped to the BH RLC channel and instructed to be deleted, but forwards the remaining buffered DL data packets.

[0289] Regarding manipulation of UL data, a Type 1 parent node can perform any of the following operations during any of these determinations:

[0290] • Suppress the granting of more UL scheduling permissions to the migrating sub-IAB nodes.

[0291] • Grant UL scheduling permission to the migrating child IAB and wait for the reception of buffered UL packets. This may be for all buffered UL data at the child IAB node, for a certain percentage of data, for a certain indicated BH RLC channel, for timer-based duration, etc., as described above. When these conditions for scheduling the UL data of the migrating child node are no longer met, the Type 1 parent node forwards the HO command to the child node.

[0292] Regarding manipulation of DL data, a Type 2 parent node can perform any of the same operations as a Type 1 parent node when performing any of the above determinations. On the other hand, manipulation of UL data by a Type 1 parent node may not be related to a Type 2 parent node that is also a migration node. For example, in some cases, it may have already executed its MT's HO command before / when it recognizes that the child IAB node is also involved in the inter-CU migration.

[0293] In some embodiments, such as when a type 2 parent node does not execute its corresponding HO command but stores it for later execution, the type 1 parent node's UL grouping manipulation can also be applied to a type 2 parent node. This can be achieved by referring to... Figure 16 As shown. For example, instead of executing its MT's HO command, IAB2 stores it and forwards the HO command associated with IAB-3MT, in which IAB-3MT has already embedded the HO command of IAB4. IAB2 forwards this information to IAB3 within an F1 message or an embedded RRC message. While waiting for the HO completion message from IAB-3MT, IAB2 will execute IAB3's special DL / UL manipulation (e.g., DL packets with destination BAP routing IDs of IAB3 or IAB4) according to the Type 1 parent node procedure described above.

[0294] Furthermore, when receiving a message from IAB2, IAB3 does not execute its MT's HO command, but instead stores it and forwards the HO command associated with IAB-4MT to IAB4. While waiting for the HO completion message from IAB-4MT, IAB3 will perform special DL / UL manipulations on IAB4 according to the Type 1 parent node procedure described above.

[0295] Upon receiving a HO command from IAB3, IAB4 executes the HO command and sends an HO completion message to IAB3. IAB3 ceases its manipulation of IAB4's UL / DL data and refreshes any remaining DL buffer data that uses IAB4 as the destination BAP routing ID. IAB3 then executes its stored HO command and sends a completion message to IAB2, which ceases its manipulation of IAB3's UL / DL data and refreshes any remaining DL buffer data of IAB3.

[0296] In various embodiments, migrating an IAB node can perform a number of operations when it is determined that: 1) the handover of the migrating IAB node is an inter-CU handover, and / or 2) there is an explicit indication of modified manipulation of UL / DL data packets during the migration. These are described in more detail below.

[0297] In some embodiments, the migrating IAB node can be a type 2 parent node, whose descendant nodes are also migrating. An example is... Figure 16 The IAB2 and IAB3 are mentioned. In some embodiments, migrating an IAB node can perform the operations described above on a type 2 parent node before performing the operations described below. In other embodiments, migrating an IAB node can perform the operations described above on a type 2 parent node after performing the operations described below. The choice between these options can be configured by the network (e.g., F1 signaling, OAM, in the HO command of the IAB MT, in the F1 message including the HO command for the child node, etc.) or left to the IAB node to implement.

[0298] Regarding the manipulation of UL data, the migration IAB node can perform any of the following operations while performing any of the above determinations:

[0299] • Send a buffer status report (BSR) related to pending UL data.

[0300] • Suppress the transmission of BSRs related to pending UL data.

[0301] • When a HO command is received from the parent node and / or one or more other conditions are met, the migrated IAB node deletes its buffered UL data. Exemplary conditions can include any of the conditions described above in relation to other embodiments, such as a certain percentage of UL data has been transmitted, data for a specific BH RLC channel has been transmitted, a specific duration has elapsed, etc.

[0302] After the above manipulation of UP / CP services, the source CU needs to notify the target CU of the results of the actions performed. 3GPP TS 38.423 currently specifies that during Xn handover, the source CU indicates the UL and DL PDCP SN and HFN to the target CU by sending an SN STATUS TRANSFER message, as described above. This indication is used for all DRBs of the migrated UE (i.e., one message for one migrated UE).

[0303] In various embodiments, after the actions described above have been performed on the migrated IAB nodes and type 1 / 2 parent nodes, the source CU jointly indicates to the target CU the UL / DL PDCP SN and HFN status of all migrated IAB nodes and their served UEs. For group indication, the enhanced SN STATUS TRANSFER message or a newly defined message can also be used. Table 10 below shows example content of the newly defined XnAP message according to these embodiments.

[0304] Table 10.

[0305]

[0306] The embodiments described above can be referred to Figure 17-18 Further, Figure 17-18 This illustrates an exemplary method (e.g., procedure) performed by an IAB node (e.g., an IAB in a wireless network (e.g., NG-RAN)). In other words, various features of the operations described below correspond to the various embodiments described above. Figure 17-18 The exemplary methods shown are complementary, enabling them to work synergistically to provide benefits, advantages, and / or solutions to the problems described herein. While the exemplary methods... Figure 17-18 The blocks are shown in a specific order, but the operations corresponding to the blocks can be performed in a different order than shown, and can be combined and / or divided into blocks and / or operations with different functionalities than those shown. Optional blocks and / or operations are indicated by dashed lines.

[0307] More specifically, Figure 17 This disclosure illustrates exemplary methods (e.g., procedures) for migrating an Integrated Access Backhaul (IAB) node from a first Centralized Unit (CU) to a second CU in a wireless network, according to various embodiments of the present disclosure. In various embodiments, Figure 17 The exemplary method shown can be performed by migrating IAB nodes or type 2 parent IAB nodes (such as IAB-DU and IAB-MT), as described above.

[0308] The exemplary method may include the operation of block 1710, wherein the IAB node can receive a handover (HO) command from a first CU via a source parent IAB node. The HO command includes an identifier for the target cell for handover. The exemplary method may also include the operation of block 1720, wherein the IAB node can determine, based on the HO command, that the HO command is for an inter-CU migration from the IAB node to a second CU. The exemplary method may also include the operation of block 1750, wherein the IAB node can perform modified manipulation of uplink (UL) and / or downlink (DL) data buffered in the IAB node based on the determination that the HO command is for an inter-CU migration, until the execution of the HO command.

[0309] In some embodiments, performing modified manipulation of UL and / or DL ​​data buffered in the IAB node in block 1750 may include one or more of the following operations:

[0310] Forward at least a portion of the DL data buffered in the IAB node (subframe 1751).

[0311] Forward at least a portion of the UL data buffered in the IAB node (subframe 1752).

[0312] • Delete at least a portion of the DL data buffered in the IAB node (subframe 1753), and

[0313] • Delete at least a portion of the UL data buffered in the IAB node (subframe 1754).

[0314] In some embodiments, determining whether a HO command is used for inter-CU migration (e.g., in block 1720) can be based on one or more of the following:

[0315] • The target cell identifier does not match any identifier associated with the current serving cell of the IAB node;

[0316] • The target base station identifier within the target cell identifier does not match the base station identifier associated with the first CU; and

[0317] The HO command contains an explicit indication that the HO is a migration between CUs.

[0318] In some embodiments, the exemplary method may further include the operation of block 1730, wherein the IAB node is able to determine that one or more descendant nodes of the IAB node have also undergone inter-CU migration of the second CU. In various embodiments, the determination that one or more descendant nodes have also undergone inter-CU migration may be based on one or more of the following:

[0319] • Determining the use of the HO command for CU-to-CU migration from the IAB node to the second CU;

[0320] • Explicit indications within the HO command regarding one or more descendant nodes also undergoing inter-CU migration; and

[0321] • A second HO command for the child node of the IAB node, the second HO command being sent from the first CU to the child node via the IAB node.

[0322] In some embodiments, the exemplary method may also include the operation of block 1740, wherein the IAB node is capable of receiving instructions for modified manipulation of buffered UL data and / or buffered DL data. In such embodiments, modified manipulation of the UL and / or DL ​​data buffered at the IAB node is performed according to the instructions (e.g., in block 1750).

[0323] In some embodiments (e.g., when the IAB node is a type 2 parent IAB node), the instructions can include one or more of the following:

[0324] • One or more first criteria related to the amount of DL data buffered in the IAB node;

[0325] • One or more secondary criteria related to whether DL data buffered in the IAB node should be deleted or forwarded to the corresponding descendant node.

[0326] In such embodiments, the second criterion can include one or more of the following:

[0327] • Indicators that all types of buffered DL data should be deleted or forwarded;

[0328] • A list of backhaul radio link control (BH RLC channels) from which the buffered DL data should be forwarded;

[0329] • A list of BH RLC channels whose buffered DL data should be deleted;

[0330] • A list of access RLC channels to which the buffered DL data should be forwarded;

[0331] • A list of access RLC channels whose buffered DL data should be deleted;

[0332] • A QoS profile and / or priority list should be provided for the forwarding of buffered DL data;

[0333] • The QoS profiles and / or priority lists of the buffered DL data should be removed.

[0334] • A list of Backhaul Adaptation Protocol (BAP) routing identifiers should be provided for forwarding buffered DL data; and

[0335] • The list of BAP routing identifiers that buffer DL data should be removed.

[0336] In some embodiments of these embodiments, the instructions (e.g., received in block 1740) may also include one or more third criteria relating to the amount of UL data buffered at the IAB node and one or more fourth criteria relating to whether a Buffer Status Report (BSR) should be sent to the parent node for the UL data buffered at the IAB node. In some embodiments, each of the first and third criteria may identify the amount according to one or more of the following: all buffered data; an explicit amount of buffered data; a percentage of buffered data; duration. In some embodiments, the fourth criteria may include one or more of the following:

[0337] • Instructions that BSR should be transmitted for all types of buffered UL data;

[0338] • A list of BH RLC channels for which BSR should be transmitted;

[0339] • A list of BSR access RLC channels should be transmitted to it;

[0340] • A QoS profile and / or priority list for the BSR should be transmitted to it; and

[0341] • A list of BAP routing identifiers for which BSR should be transmitted.

[0342] In some embodiments, the instructions for modified manipulation of buffered UL and / or buffered DL data (e.g., received in block 1740) may also include instructions for modified manipulation of UL data buffered at one or more descendant nodes of the IAB node. In such embodiments, the exemplary method may also include the operation of block 1760, wherein the IAB node is able to perform modified manipulation of UL data buffered at one or more descendant nodes according to the instructions based on determining an HO command for inter-CU migration, and until the execution of the HO command.

[0343] In some embodiments, performing modified manipulation of UL data buffered at one or more downstream nodes in block 1760 may include one or more of the following operations:

[0344] • Provide UL permission for at least a portion of the UL data buffered in one or more child nodes of the IAB node (subframe 1761);

[0345] • Suppressing the granting of UL permission to at least a portion of UL data buffered in one or more child nodes (subframe 1762); and

[0346] • Provide instructions to one or more child nodes for manipulating UL data buffered in the descendant nodes of one or more child nodes (subframe 1763).

[0347] In some embodiments, instructions for modified manipulation of UL data buffered in one or more descendant nodes (e.g., received in block 1740) may include one or more of the following:

[0348] • First configuration for manipulating UL data buffered in the first child node of the IAB node;

[0349] • A second configuration for manipulating UL data buffered in the second child node of the IAB node; and

[0350] • A third configuration for manipulating UL data buffered in the first and second child nodes.

[0351] In some embodiments, instructions for modified manipulation of UL data buffered in one or more descendant nodes (e.g., received in block 1740) may also include one or more of the following:

[0352] • One or more fifth criteria relating to the amount of UL data buffered in one or more descendant nodes; and

[0353] • One or more sixth criteria related to whether UL approval should be provided for UL data buffered in one or more descendant nodes.

[0354] In various embodiments, the sixth criterion can include one or more of the following:

[0355] • Regarding the requirement to provide UL-approved indicators for all buffered UL data;

[0356] • A list of UL-approved backhaul radio link control (BH RLC channels) should be provided.

[0357] • A list of UL-approved access channels for RLC should be provided.

[0358] • It should provide a list of QoS profiles and / or priorities permitted by UL; and it should provide a list of Backhaul Adaptation Protocol (BAP) routing identifiers permitted by UL.

[0359] in addition, Figure 18 Exemplary methods (e.g., processes) for controlling the migration of any descendant node of a sub-IAB node and its descendant nodes from a first CU to a second CU in a wireless network, according to various exemplary embodiments of this disclosure, are illustrated. In various embodiments, Figure 18 The exemplary method shown can be executed by a type 1 parent IAB node (e.g., IAB-DU and IAB-MT), as described above. Therefore, the IAB node executing the exemplary method does not undergo the same migration from the first CU to the second CU as the child IAB node.

[0360] The exemplary method may include the operation of block 1810, wherein the IAB node is able to receive a message from a first CU, the message including a handover (HO) command from the sub-IAB node to the target cell. The exemplary method may also include the operation of block 1820, wherein the IAB node is able to determine that the HO command is for an inter-CU migration from the sub-IAB node to a second CU. The exemplary method may also include the operation of block 1840, wherein the IAB node is able to perform modified operations on one or more of the following based on the determination that the HO command is for an inter-CU migration: UL data buffered in the sub-IAB node; and DL data associated with the sub-IAB node buffered in the IAB node.

[0361] In some embodiments, performing modified manipulation of UL and / or DL ​​data buffered in the IAB node in block 1840 may include one or more of the following operations until the HO command is forwarded to the child IAB node:

[0362] Forward at least a portion of the DL data buffered in the IAB node (subframe 1751).

[0363] Forward at least a portion of the UL data buffered in the sub-IAB node (sub-frame 1752).

[0364] • Delete at least a portion of the DL data buffered in the IAB node (subframe 1753), and

[0365] • Delete at least a portion of the UL data buffered in the sub-IAB node (sub-frame 1754).

[0366] In some embodiments, determining that a HO command is used for inter-CU migration (e.g., in box 1820) can be based on an explicit indication within the message regarding the HO command being used for inter-CU migration of a sub-IAB node.

[0367] In some embodiments, the exemplary method may further include the operation of block 1830, wherein the IAB node is capable of receiving instructions for modified manipulation of buffered UL data and / or buffered DL data. In such embodiments, modified manipulation of UL data buffered at a child IAB node and / or DL ​​data buffered at an IAB node is performed according to the instructions (e.g., in block 1840). In some embodiments, the instructions may include one or more of the following:

[0368] • One or more first criteria related to the amount of DL data buffered in the IAB node;

[0369] • One or more second criteria related to whether DL data buffered in IAB nodes should be deleted or forwarded to the corresponding descendant nodes;

[0370] • One or more third criteria related to the amount of UL data buffered in one or more descendant nodes, and

[0371] • One or more fourth criteria related to whether UL approval should be provided for UL data buffered in one or more descendant nodes.

[0372] In some embodiments, each of the first and third criteria is identified according to one or more of the following: all buffered data; an explicit amount of buffered data; a percentage of buffered data; and duration (e.g., a timer value).

[0373] In some embodiments, the second criterion may include one or more of the following:

[0374] • Indicators that all types of buffered DL data should be deleted or forwarded;

[0375] • A list of BH RLC channels to which the buffered DL data should be forwarded;

[0376] • A list of BH RLC channels whose buffered DL data should be deleted;

[0377] • A list of radio bearers that should be used to forward buffered DL data should be provided;

[0378] • The list of radio bearers for the buffered DL data should be removed;

[0379] • A QoS profile and / or priority list should be provided for the forwarding of buffered DL data;

[0380] • The QoS profiles and / or priority lists of the buffered DL data should be removed.

[0381] • A list of BAP routing identifiers that should be provided for forwarding buffered DL data; and

[0382] • The list of BAP routing identifiers that buffer DL data should be removed.

[0383] In some embodiments, the fourth criterion may include one or more of the following:

[0384] • Regarding the requirement to provide UL-approved indicators for all buffered UL data;

[0385] • A list of UL-approved BH RLC channels should be provided.

[0386] • A list of QoS profiles and / or priorities approved by UL should be provided; and

[0387] • A list of BAP routing identifiers authorized by UL should be provided.

[0388] The above discussion presents different examples of the first, second, third, and fourth criteria.

[0389] In some embodiments, the exemplary method may also include the operation of block 1850, wherein the IAB node is able to forward the HO command to the child IAB node after completing modified manipulation of UL data buffered in the child IAB node and / or DL ​​data buffered in the IAB (e.g., in block 1840).

[0390] While the subject matter described herein can be implemented in any suitable type of system using any appropriate components, the embodiments disclosed herein relate to wireless networks (such as...). Figure 19 The example wireless network shown is used for description. For the sake of brevity, Figure 19 The wireless network shown only includes network 1906, network nodes 1960 and 1960b, and WD 1910, 1910b, and 1910c. In practice, the wireless network can further include any additional elements suitable for supporting communication between wireless devices or between a wireless device and another communication device (such as a landline telephone, service provider, or any other network node or terminal device). Among the components shown, network node 1960 and wireless device (WD) 1910 are shown in additional detail. The wireless network is capable of providing communication and other types of services to one or more wireless devices to facilitate access and / or use of services provided by or via the wireless network.

[0391] A wireless network can include and / or interface with any type of communication, telecommunications, data, cellular and / or radio network or other similar type of system. In some embodiments, the wireless network can be configured to operate according to a specific standard or other type of predefined rules or procedures. Thus, specific embodiments of the wireless network can implement: communication standards such as Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE) and / or other suitable 2G, 3G, 4G or 5G standards; wireless local area network (WLAN) standards such as the IEEE 802.11 standard; and / or any other suitable wireless communication standards such as Global Microwave Access Interoperability (WiMax), Bluetooth, Z-Wave and / or ZigBee standards.

[0392] Network 1906 can include one or more backhaul networks, core networks, IP networks, public switched telephone networks (PSTN), packet data networks, optical networks, wide area networks (WAN), local area networks (LAN), wireless local area networks (WLAN), wired networks, wireless networks, metropolitan area networks, and other networks to enable communication between devices.

[0393] Network node 1960 and WD 1910 include a variety of components, which are described in more detail below. These components work together to provide the functionality of the network node and / or wireless device, such as providing wireless connectivity in a wireless network. In various embodiments, the wireless network can include any number of wired or wireless networks, network nodes, base stations, controllers, wireless devices, relay stations, and / or any other components or systems that facilitate or participate in the communication of data and / or signals (whether via wired or wireless connections).

[0394] Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points) and base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs), and NRNode Bs (gNBs)). Base stations can be classified based on the coverage they provide (or, in other words, their transmission power level), and thus can also be called femtocells, picocells, microcells, or macrocells. A base station can be a relay node or a relay donor node controlling a repeater. Network nodes can also include one or more (or all) portions of a distributed radio base station, such as centralized digital units and / or remote radio units (RRUs), sometimes called remote radio headends (RRHs). These remote radio units may or may not be integrated as antenna-integrated radios with antennas. Portions of a distributed radio base station can also be called nodes in a distributed antenna system (DAS).

[0395] Other examples of network nodes include multi-standard radio (MSR) equipment (such as an MSR BS), network controllers (such as a radio network controller (RNC) or base station controller (BSC)), base transceiver stations (BTS), transport points, transport nodes, multi-cell / multicast coordination entities (MCEs), core network nodes (e.g., MSC, MME), O&M nodes, OSS nodes, SON nodes, location nodes (e.g., E-SMLC), and / or MDTs. As another example, a network node can be a virtual network node as described in more detail below. More generally, however, a network node can represent any suitable device (or group of devices) that is capable of, configured, arranged, and / or operable to enable access to a wireless network and / or provide access to a wireless network for wireless devices or provide some service to wireless devices already connected to the wireless network.

[0396] Figure 19 In this network node 1960, there are processing circuit modules 1970, device-readable media 1980, interfaces 1990, auxiliary equipment 1984, power supplies 1986, power circuit modules 1987, and antennas 1962. Although Figure 19The network node 1960 shown in the example wireless network can represent an apparatus including the illustrated combination of hardware components, but other embodiments can include network nodes with different combinations of components. It should be understood that a network node includes any suitable combination of hardware and / or software required to perform the tasks, features, functions, and methods and / or processes disclosed herein. Furthermore, although the components of network node 1960 are shown as a single frame within a larger frame or nested within multiple frames, in practice, a network node can include multiple different physical components that make up a single illustrated component (e.g., apparatus-readable medium 1980 can include multiple separate hard disk drives and multiple RAM modules).

[0397] Similarly, network node 1960 can be composed of multiple physically separate components (e.g., NodeB components and RNC components, or BTS components and BSC components, etc.), each of which can have its own corresponding components. In some cases where network node 1960 includes multiple separate components (e.g., BTS and BSC components), one or more of the separate components can be shared among several network nodes. For example, a single RNC can control multiple NodeBs. In such cases, each unique NodeB and RNC pair can be considered a single network node in some situations. In some embodiments, network node 1960 can be configured to support multiple radio access technologies (RATs). In such embodiments, some components (e.g., separate device-readable media 1980 for different RATs) can be duplicated, and some components can be reused (e.g., the same antenna 1962 can be shared by RATs). Network node 1960 can also include multiple sets of various illustrated components of different wireless technologies (e.g., GSM, WCDMA, LTE, NR, WiFi, or Bluetooth wireless technologies) integrated into network node 1960. These wireless technologies can be integrated into the same or different chips or chipsets and other components within the network node 1960.

[0398] The processing circuit module 1970 can be configured to perform any determination, calculation, or similar operation (e.g., certain acquisition operations) described herein as provided by a network node. These operations performed by the processing circuit module 1970 can include processing information acquired by the processing circuit module 1970 through steps such as: converting the acquired information into other information, comparing the acquired or converted information with information stored in the network node, and / or performing one or more operations based on the acquired or converted information, and making determinations as a result of the processing.

[0399] The processing circuitry module 1970 may include a combination of one or more of a microprocessor, controller, central processing unit, digital signal processor, application-specific integrated circuit, field-programmable gate array, or any other suitable computing device, resource, or combination of hardware, software, and / or coding logic operable alone or in combination with other network node 1960 components (e.g., device-readable medium 1980) to provide various functionalities of the network node 1960. Such functionalities may include any of the various wireless features, functions, or benefits described herein.

[0400] For example, the processing circuit module 1970 is capable of executing instructions stored in the device-readable medium 1980 or in memory within the processing circuit module 1970. In some embodiments, the processing circuit module 1970 may include a system-on-a-chip (SOC). As a more specific example, the instructions (also referred to as a computer program product) stored in the medium 1980 may include instructions that, when executed by the processing circuit module 1970, configure the network node 1960 to perform operations corresponding to the various exemplary methods (e.g., procedures) described herein.

[0401] In some embodiments, the processing circuit module 1970 may include one or more of a radio frequency (RF) transceiver circuit module 1972 and a baseband processing circuit module 1974. In some embodiments, the RF transceiver circuit module 1972 and the baseband processing circuit module 1974 may reside 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 circuit 1972 and the baseband processing circuit 1974 may reside on the same chip or chipset, board, or unit.

[0402] In some embodiments, some or all of the functionality described herein as being provided by a network node, base station, eNB, or other such network device can be executed by the processing circuit module 1970 of instructions stored on the device-readable medium 1980 or in memory within the processing circuit module 1970. In alternative embodiments, some or all of the functionality can be provided by the processing circuit module 1970, for example, in a hard-wired manner, without executing instructions stored on a separate or discrete device-readable medium. In any of those embodiments, the processing circuit module 1970 can be configured to perform the aforementioned functionality regardless of whether instructions stored on the device-readable storage medium are executed. The benefits provided by such functionality are not limited to the processing circuit module 1970 or other components of the network node 1960, but are generally enjoyed by the network node 1960 and / or generally by the end user and the wireless network.

[0403] Device-readable medium 1980 may include any form of volatile or non-volatile computer-readable storage, including, without limitation, permanent storage devices, solid-state storage, remotely mounted storage, 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 drives, compact optical discs (CDs), or digital video optical discs (DVDs)), and / or any other volatile or non-volatile non-transitory device-readable and / or computer-executable storage device that stores information, data, and / or instructions that can be used by processing circuitry module 1970. Device-readable medium 1980 may store any suitable instructions, data, or information, including computer programs, software, applications (including one or more of logic, rules, codes, tables, etc.) and / or other instructions (which can be executed by processing circuitry module 1970 and utilized by network node 1960). Device-readable medium 1980 may be used to store any calculations performed by processing circuitry module 1970 and / or any data received via interface 1990. In some embodiments, the processing circuit module 1970 and the device-readable medium 1980 can be considered integrated.

[0404] Interface 1990 is used for wired or wireless communication of signaling and / or data between network node 1960, network 1906, and / or WD 1910. As shown, interface 1990 includes one or more ports / terminals 1994 for sending and receiving data to and from network 1906 via a wired connection, for example. Interface 1990 also includes a radio front-end circuit module 1992, which can be coupled to antenna 1962 or, in some embodiments, to a portion of antenna 1662. Radio front-end circuit module 1992 includes a filter 1998 and an amplifier 1996. Radio front-end circuit module 1992 can be connected to antenna 1962 and processing circuit module 1970. Radio front-end circuit module 1992 can be configured to modulate the signal transmitted between antenna 1962 and processing circuit module 1970. Radio front-end circuit module 1992 can receive digital data that will be transmitted to other network nodes or WDs via a wireless connection. The radio front-end circuit module 1992 is capable of converting digital data into radio signals with appropriate channel and bandwidth parameters using a combination of filter 1998 and / or amplifier 1996. The radio signals can then be transmitted via antenna 1962. Similarly, when receiving data, antenna 1962 can collect radio signals, which are then converted into digital data by the radio front-end circuit module 1992. The digital data can be passed to processing circuit module 1970. In other embodiments, the interface can include different components and / or different combinations of components.

[0405] In some alternative embodiments, network node 1960 may not include a separate radio front-end circuit module 1992, and processing circuit module 1970 may instead include a radio front-end circuit module and be connected to antenna 1962 without a separate radio front-end circuit module 1992. Similarly, in some embodiments, all or part of RF transceiver circuit module 1972 may be considered part of interface 1990. In other embodiments, interface 1990 may include one or more ports or terminals 1994, radio front-end circuit module 1992, and RF transceiver circuit module 1972 as part of a radio unit (not shown), and interface 1990 may communicate with baseband processing circuit module 1974, which is part of a digital unit (not shown).

[0406] Antenna 1962 may include one or more antennas or antenna arrays configured to transmit and / or receive wireless signals. Antenna 1962 may be coupled to radio front-end circuit module 1990 and may be any type of antenna capable of wirelessly transmitting and receiving data and / or signals. In some embodiments, antenna 1962 may include one or more omnidirectional, sector, or planar antennas operable to transmit / receive radio signals, for example, between 2 GHz and 66 GHz. Omnidirectional antennas can be used to transmit / receive radio signals in any direction, sector antennas can be used to transmit / receive radio signals from devices within a specific area, and planar antennas can be line-of-sight antennas used to transmit / receive radio signals in relatively straight lines. In some cases, the use of more than one antenna may be referred to as MIMO. In some embodiments, antenna 1962 may be decoupled from network node 1960 and may be connectable to network node 1960 via an interface or port.

[0407] Antenna 1962, interface 1990, and / or processing circuit module 1970 can be configured to perform any receive operation and / or certain acquire operation described herein as being performed by a network node. They can receive any information, data, and / or signals from a wireless device, another network node, and / or any other network device. Similarly, antenna 1962, interface 1990, and / or processing circuit module 1970 can be configured to perform any transmit operation described herein as being performed by a network node. They can transmit any information, data, and / or signals to a wireless device, another network node, and / or any other network device.

[0408] Power circuit module 1987 may include or be coupled to power management circuit module and may be configured to supply power to components of network node 1960 for performing the functionality described herein. Power circuit 1987 may receive power from power source 1986. Power source 1986 and / or power circuit module 1987 may be configured to supply power to various components of network node 1960 in a manner suitable to the respective components (e.g., at the voltage and current levels required by each respective component). Power source 1986 may be included in power circuit module 1987 and / or network node 1960 or external to said power circuit module and / or said network node. For example, network node 1960 may be connectable to an external power source (e.g., an electrical outlet) via an input circuit module or interface (e.g., a cable), whereby the external power source supplies power to power circuit module 1987. As another example, power source 1986 may include a power source in the form of a battery or battery pack, which is connected to or integrated into power circuit module 1987. If the external power source fails, the battery may provide backup power. It can also use other types of power sources (such as photovoltaic devices).

[0409] Alternative embodiments of network node 1960 can include, in addition to Figure 19 Additional components beyond those shown may be responsible for providing certain aspects of the functionality of the network node, including any functionality described herein and / or any functionality required to support the topics described herein. For example, network node 1960 may include a user interface device to allow and / or facilitate input of information into network node 1960, and to allow and / or facilitate output of information from network node 1960. This enables and / or facilitates users to perform diagnostic, maintenance, repair, and other management functions of network node 1960.

[0410] In some embodiments, the wireless device (WD, such as WD 1910) can be configured to transmit and / or receive information without direct human interaction. For example, the WD can be designed to transmit information to the network according to a predetermined schedule, when triggered by internal or external events, or in response to a request from the network. Examples of WDs include, but are not limited to, smartphones, mobile phones, cellular phones, Voice over IP (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, game consoles or devices, music storage devices, playback devices, wearable devices, wireless endpoints, mobile stations, tablets, laptops, laptop embedded devices (LEEs), laptop mounted devices (LMEs), smart devices, wireless customer premises equipment (CPEs), mobile type communication (MTC) devices, Internet of Things (IoT) devices, in-vehicle wireless terminal devices, etc.

[0411] A WD can support device-to-device (D2D) communication, for example, through 3GPP standards implementing sidelink communication, vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X), and in this case, can be referred to as a D2D communication device. As another specific example, in the Internet of Things (IoT) context, a WD can represent a machine or other device that performs monitoring and / or measurement and transmits the results of such monitoring and / or measurement to another WD and / or network node. In this case, a WD can be a machine-to-machine (M2M) device, which in the 3GPP context can be referred to as an MTC device. As a specific example, a WD can be a UE implementing the 3GPP Narrowband Internet of Things (NB-IoT) standard. Specific examples of such machines or devices are sensors, metering devices (such as power meters), industrial machinery or household or personal appliances (such as refrigerators, televisions, etc.), and personal wearables (such as watches, fitness trackers, etc.). In other cases, a WD can represent a vehicle or other device that can monitor and / or report on the operational status or other functions associated with its operation. As described above, WD can represent a wireless connection endpoint, in which case the device can be called a wireless terminal. Furthermore, as described above, WD can be mobile, in which case it can also be called a mobile device or mobile terminal.

[0412] As shown, the wireless device 1910 includes an antenna 1911, an interface 1914, a processing circuit module 1920, a device-readable medium 1930, a user interface device 1932, auxiliary devices 1934, a power supply 1936, and a power circuit module 1937. The WD 1910 can include one or more of the components shown, such as GSM, WCDMA, LTE, NR, WiFi, WiMAX, or Bluetooth wireless technologies, to name just a few. These wireless technologies can be integrated into chips or chipsets that are the same as or different from other components within the WD 1910.

[0413] Antenna 1911 may include one or more antennas or antenna arrays configured to transmit and / or receive wireless signals and is connected to interface 1914. In some alternative embodiments, antenna 1911 may be detachable from WD 1910 and may be connected to WD 1910 via an interface or port. Antenna 1911, interface 1914, and / or processing circuit module 1920 may be configured to perform any receive or transmit operations described herein as performed by a WD. Any information, data, and / or signals may be received from network nodes and / or another WD. In some embodiments, radio front-end circuit module and / or antenna 1911 may be considered as an interface.

[0414] As shown, interface 1914 includes a radio front-end circuit module 1912 and an antenna 1911. Radio front-end circuit module 1912 includes one or more filters 1918 and amplifiers 1916. Radio front-end circuit module 1914 is connected to antenna 1911 and processing circuit module 1920 and can be configured to modulate the signal transmitted between antenna 1911 and processing circuit module 1920. Radio front-end circuit module 1912 can be coupled to antenna 1911 or a portion thereof. In some embodiments, WD 1910 may not include a separate radio front-end circuit module 1912; instead, processing circuit module 1920 may include the radio front-end circuit module and be connected to antenna 1911. Similarly, in some embodiments, part or all of RF transceiver circuit module 1922 can be considered part of interface 1914. Radio front-end circuit module 1912 is capable of receiving digital data that will be transmitted wirelessly to other network nodes or WD. The radio front-end circuit module 1912 can use a combination of filter 1918 and / or amplifier 1916 to convert digital data into radio signals with appropriate channel and bandwidth parameters. The radio signals can then be transmitted via antenna 1911. Similarly, when receiving data, antenna 1911 can collect radio signals, which are then converted into digital data by the radio front-end circuit module 1912. The digital data can be passed to processing circuit module 1920. In other embodiments, the interface can include different components and / or different combinations of components.

[0415] The processing circuitry module 1920 may include a combination of one or more of the following: a microprocessor, controller, central processing unit, digital signal processor, application-specific integrated circuit, field-programmable gate array, or any other suitable computing device, resource, or combination of hardware, software, and / or coded logic operable alone or in combination with other WD 1910 components (such as device-readable medium 1930) to provide WD 1910 functionality. Such functionality may include any of the various wireless features or benefits described herein.

[0416] For example, the processing circuit module 1920 can execute instructions stored in the device-readable medium 1930 or in memory within the processing circuit module 1920 to provide the functionality disclosed herein. More specifically, the instructions (also referred to as a computer program product) stored in the medium 1930 can include instructions that, when executed by the processor 1920, can configure the wireless device 1910 to perform operations corresponding to the various exemplary methods (e.g., procedures) described herein.

[0417] As shown, the processing circuit module 1920 includes one or more of the following: RF transceiver circuit module 1922, baseband processing circuit module 1924, and application processing circuit module 1926. In other embodiments, the processing circuit module may include different components and / or different combinations of components. In some embodiments, the processing circuit module 1920 of WD 1910 may include a System-on-a-Chip (SOC). In some embodiments, the RF transceiver circuit module 1922, baseband processing circuit module 1924, and application processing circuit module 1926 may reside on a separate chip or chipset. In alternative embodiments, some or all of the baseband processing circuit module 1924 and application processing circuit module 1926 may be combined into a single chip or chipset, and the RF transceiver circuit module 1922 may reside on a separate chip or chipset. In still alternative embodiments, some or all of the RF transceiver circuit module 1922 and baseband processing circuit module 1924 may reside on the same chip or chipset, and the application processing circuit module 1926 may reside on a separate chip or chipset. In other alternative embodiments, some or all of the RF transceiver circuit module 1922, baseband processing circuit module 1924, and application processing circuit module 1926 can be combined on the same chip or chipset. In some embodiments, the RF transceiver circuit module 1922 can be part of interface 1914. The RF transceiver circuit module 1922 can modulate the RF signals used for processing circuit module 1920.

[0418] In some embodiments, some or all of the functionality described herein as being performed by WD can be provided by the processing circuitry module 1920 executing instructions stored on a device-readable medium 1930, which in some embodiments may be a computer-readable storage medium. In alternative embodiments, some or all of the functionality can be provided by the processing circuitry module 1920, such as in a hard-wired manner, without executing instructions stored on a separate or discrete device-readable storage medium. In any of those particular embodiments, the processing circuitry module 1920 can be configured to perform the functionality regardless of whether instructions stored on the device-readable storage medium are executed. The benefits provided by such functionality are not limited to the processing circuitry module 1920 or other components of the WD 1910, but are enjoyed generally by the WD 1910 and / or generally by the end user and wireless network.

[0419] The processing circuit module 1920 can be configured to perform any determination, calculation, or similar operation (e.g., certain acquisition operations) described herein as being performed by WD. Such operations performed by the processing circuit module 1920 can include processing information acquired by the processing circuit module 1920 by, for example, converting the acquired information into other information, comparing the acquired or converted information with information stored by WD 1910, and / or performing one or more operations based on the acquired or converted information, and making determinations as a result of the processing.

[0420] Device-readable medium 1930 is operable to store computer programs, software, applications (including one or more of logic, rules, code, tables, etc.) and / or other instructions (which can be executed by processing circuitry module 1920). Device-readable medium 1930 may include computer memory (e.g., random access memory (RAM) or read-only memory (ROM)), mass storage media (e.g., hard disk), removable storage media (e.g., CD or DVD)) and / or any other volatile or non-volatile non-transitory device-readable and / or computer-executable memory device (which stores information, data, and / or instructions that can be used by processing circuitry module 1920). In some embodiments, processing circuitry module 1920 and device-readable medium 1930 may be considered integrated.

[0421] User interface device 1932 may include components that allow and / or facilitate human user interaction with WD 1910. Such interaction may take many forms, such as visual, auditory, tactile, etc. User interface device 1932 may be operable to produce output to the user and allow and / or facilitate input from the user to WD 1910. The type of interaction may vary depending on the type of user interface device 1932 installed in WD 1910. For example, if WD 1910 is a smartphone, interaction may be via a touchscreen; if WD 1910 is a smart meter, interaction may be via a screen displaying usage (e.g., gallons used) or a speaker providing audible alarms (e.g., if smoke is detected). User interface device 1932 may include input interfaces, means, and circuitry, as well as output interfaces, means, and circuitry. User interface device 1932 may be configured to allow and / or facilitate input of information to WD 1910 and is connected to processing circuitry module 1920 to allow and / or facilitate processing of the input information by processing circuitry module 1920. User interface device 1932 may include, for example, a microphone, proximity or other sensors, buttons / buttons, a touch display, one or more cameras, a USB port, or other input circuitry modules. User interface device 1932 is also configured to allow and / or facilitate information output from WD 1910, and to allow and / or facilitate information output from WD 1910 by processing circuitry module 1920. User interface device 1932 may include, for example, a speaker, a display, a vibration circuitry module, a USB port, a headphone jack, or other output circuitry modules. Using one or more input and output interfaces, devices, and circuitry of user interface device 1932, WD 1910 can communicate with end users and / or wireless networks, and allows and / or facilitates them to benefit from the functionality described herein.

[0422] Auxiliary device 1934 is operable to provide more specific functionality, which may generally not be performed by WD. This can include dedicated sensors for measurements for a variety of purposes, interfaces for additional types of communication (such as wired communication), etc. The inclusion and type of components of auxiliary device 1934 can vary depending on the embodiment and / or circumstances.

[0423] In some embodiments, power supply 1936 may take the form of a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electrical outlet), a photovoltaic device, or a power battery, may also be used. WD 1910 may further include a power circuit module 1937 for supplying power from power supply 1936 to various components of WD 1910 that require power from power supply 1936 to perform any functionality described or shown herein. In some embodiments, power circuit module 1937 may include a power management circuit module. Alternatively or complementary, power circuit module 1937 may be operable to receive power from an external power source; in this case, WD 1910 may be connectable to an external power source (e.g., an electrical outlet) via an input circuit module or interface (such as a power cable). In some embodiments, power circuit module 1937 may also be operable to supply power from an external power source to power supply 1936. This may be used, for example, to charge power supply 1936. The power circuit module 1937 is capable of performing any conversion or other modification on the power from the power source 1936 to make it suitable for supplying to the corresponding components of the WD 1910.

[0424] Figure 20 An embodiment of a UE according to the various aspects described herein is illustrated. As used herein, a “User Equipment” or “UE” may not necessarily have the meaning of a human user who owns and / or operates the associated device. A UE can instead represent a device that is expected to be sold to or operated by a human user, but may not or initially not be associated with a particular human user (e.g., a smart sprinkler controller). Alternatively, a UE can represent a device that is not expected to be sold to or operated by an end user, but can be associated with or operated for the benefit of a user (e.g., a smart power meter). UE 20200 can be any UE recognized by the 3rd Generation Partnership Project (3GPP), including NB-IoT UEs, Machine Type Communication (MTC) UEs, and / or Enhanced MTC (eMTC) UEs. Figure 20 As shown, UE 2000 is an example of a WD configured for communication according to one or more communication standards (such as 3GPP's GSM, UMTS, LTE, and / or 5G standards) issued by the 3rd Generation Partnership Project (3GPP). As previously stated, the terms "WD" and "UE" can be used interchangeably. Accordingly, although... Figure 20 It is a UE, but the components described in this article are also applicable to WD, and vice versa.

[0425] Figure 20In this UE 2000, the following components are included: a processing circuit module 2001 operatively coupled to an input / output interface 2005; a radio frequency (RF) interface 2009; a network connectivity interface 2011; a memory 2015, including random access memory (RAM) 2017, read-only memory (ROM) 2019, and a storage medium 2021, or similar components; a communication subsystem 2031; a power supply 2033; and / or any other components or any combination thereof. The storage medium 2021 contains an operating system 2023, applications 2025, and data 2027. In other embodiments, the storage medium 2021 may include other similar types of information. Some UEs are capable of utilizing... Figure 20 The components shown can be all or only a subset of the components. The level of integration between components can change with the UE. Furthermore, some UEs can contain multiple instances of components, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0426] Figure 20 In this context, the processing circuit module 2001 can be configured to process computer instructions and data. The processing circuit module 2001 can be configured to implement: any sequential state machine operable to execute machine instructions stored in memory as a machine-readable computer program, such as one or more hardware-implemented state machines (e.g., in discrete logic, FPGA, ASIC, etc.); programmable logic along with appropriate firmware; one or more general-purpose processors, such as microprocessors or digital signal processors (DSPs), containing stored programs along with appropriate software; or any combination thereof. For example, the processing circuit module 2001 can include two central processing units (CPUs). The data can be information in a form suitable for computer use.

[0427] In the illustrated embodiment, the input / output interface 2005 can be configured to provide a communication interface to an input device, an output device, or both input and output devices. The UE 2000 can be configured to use an output device via the input / output interface 2005. The output device can use an interface port of the same type as the input device. For example, a USB port can be used to provide input / output to / from the UE 2000. The output device can be a speaker, sound card, video card, display, monitor, printer, actuator, transmitter, smart card, another output device, or any combination thereof. The UE 2000 can be configured to use an input device via the input / output interface 2005 to allow and / or facilitate the user to capture information entering the UE 2000. The input device can include a touch or presence-sensitive display, a camera (e.g., a digital camera, digital video camera, webcam, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a tracking pad, a scroll wheel, a smart card, etc. The presence-sensitive display can include a capacitive or resistive touch sensor to sense input from the user. The sensor can be, for example, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, a light sensor, a proximity sensor, another similar sensor, or any combination thereof. For example, the input device can be an accelerometer, a magnetometer, a digital camera, a microphone, and a light sensor.

[0428] Figure 20 In this configuration, RF interface 2009 can be configured to provide a communication interface to RF components (such as transmitters, receivers, and antennas). Network connectivity interface 2011 can be configured to provide a communication interface to network 2043a. Network 2043a can include wired and / or wireless networks, such as local area networks (LANs), wide area networks (WANs), computer networks, wireless networks, telecommunications networks, other similar networks, or any combination thereof. For example, network 2043a can include a Wi-Fi network. Network connectivity interface 2011 can be configured to include receiver and transmitter interfaces for communicating with one or more other devices over a communication network according to one or more communication protocols (such as Ethernet, TCP / IP, SONET, ATM, or the like). Network connectivity interface 2011 can implement receiver and transmitter functionality suitable for communication network links (e.g., optical, electrical, etc.). The transmitter and receiver functions can share circuit components, software, or firmware, or alternatively, can be implemented separately.

[0429] RAM 2017 can be configured to interface with processing circuitry module 2001 via bus 2002 to provide storage or caching of data or computer instructions during the execution of software programs (such as operating systems, application programs, and device drivers). ROM 2019 can be configured to provide computer instructions or data to processing circuitry module 2001. For example, ROM 2019 can be configured to store immutable low-level system code or data for basic system functions (such as basic input and output (I / O), startup, or acceptance of keystrokes from the keyboard, which are stored in non-volatile memory). Storage medium 2021 can be configured to include memory such as RAM, ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disk, optical disk, floppy disk, hard disk, removable magnetic tape, or flash drive.

[0430] In one example, storage medium 2021 can be configured to include operating system 2023, application 2025 (such as a web browser application, widget or accessory engine, or another application), and data file 2027. Storage medium 2021 can store any of a variety of operating systems or combinations of operating systems for use by UE 2000. For example, application 2025 can include executable program instructions (also called a computer program product) that, when executed by processor 2001, can configure UE 2000 to perform operations corresponding to the various exemplary methods (e.g., procedures) described herein.

[0431] Storage medium 2021 can be configured to include multiple physical drive units, such as redundant array of independent disks (RAID), floppy disk drives, flash memory, USB flash drives, external hard disk drives, thumb drives, pen drives, key drives, high-density digital versatile optical disc (HD-DVD) drives, internal hard disk drives, Blu-ray disc drives, holographic digital data storage (HDDS) disc drives, external micro dual in-line memory modules (DIMMs), synchronous dynamic random access memory (SDRAM), external micro DIMM SDRAM, smart card memory (such as subscriber identification modules or removable subscriber identification (SIM / RUIM) modules), other memory, or any combination thereof. Storage medium 2021 can allow and / or facilitate UE 2000 to access computer-executable instructions, applications, etc., stored on transient or non-transient storage media to offload or upload data. Articles of manufacture (e.g., articles of manufacture utilizing communication systems) can be tangibly embodied in storage medium 2021, which can include device-readable media.

[0432] Figure 20 In this configuration, the processing circuit module 2001 can be configured to communicate with network 2043b using communication subsystem 2031. Networks 2043a and 2043b can be one or more of the same networks or one or more different networks. Communication subsystem 2031 can be configured to include one or more transceivers for communicating with network 2043b. For example, communication subsystem 2031 can be configured to include one or more transceivers for communicating with one or more remote transceivers of another device (such as another WD, UE, or base station of a radio access network (RAN)) capable of wireless communication according to one or more communication protocols (such as IEEE 802.20, CDMA, WCDMA, GSM, LTE, UTRAN, WiMax, or the like). Each transceiver can include transmitter 2033 and / or receiver 2035 to respectively implement transmitter or receiver functionality suitable for the RAN link (e.g., frequency allocation and the like). Furthermore, the transmitter 2033 and receiver 2035 of each transceiver can share circuit components, software or firmware, or alternatively can be implemented separately.

[0433] In the illustrated embodiment, the communication functions of the communication subsystem 2031 can include data communication, voice communication, multimedia communication, short-range communication (such as Bluetooth, near-field communication), location-based communication (such as Global Positioning System (GPS) for determining location), another similar communication function, or any combination thereof. For example, the communication subsystem 2031 can include cellular communication, Wi-Fi communication, Bluetooth communication, and GPS communication. The network 2043b can include wired and / or wireless networks, such as a local area network (LAN), a wide area network (WAN), a computer network, a wireless network, a telecommunications network, another similar network, or any combination thereof. For example, the network 2043b can be a cellular network, a Wi-Fi network, and / or a near-field network. The power supply 2013 can be configured to provide alternating current (AC) or direct current (DC) power to the components of the UE2000.

[0434] The features, benefits, and / or functions described herein can be implemented in one component of the UE 2000 or divided across multiple components of the UE 2000. Furthermore, the features, benefits, and / or functions described herein can be implemented in any combination of hardware, software, or firmware. In one example, the communication subsystem 2031 can be configured to include any of the components described herein. Further, the processing circuit module 2001 can be configured to communicate with any of these components via bus 2002. In another example, any of these components can be represented by program instructions stored in memory, which, when executed by the processing circuit module 2001, perform the corresponding functions described herein. In another example, the functionality of any component in this type of component can be divided between the processing circuit module 2001 and the communication subsystem 2031. In yet another example, the non-computationally intensive functions of any component in this type of component can be implemented in software or firmware, while the computationally intensive functions can be implemented in hardware.

[0435] Figure 21 This is a schematic block diagram illustrating a virtualized environment 2100, in which functionality implemented through some embodiments can be virtualized. In this context, virtualization means creating a virtual version of a device or apparatus, which can include virtualizing hardware platforms, storage devices, and networking resources. As used herein, "virtualization" can be applied to nodes (e.g., virtualized base stations or virtualized radio access nodes) or to apparatuses (e.g., UEs, wireless devices, or any other type of communication device) or their components, and relates to at least a portion of its functionality being implemented as an implementation of one or more virtual components (e.g., one or more applications, components, functions, virtual machines, or containers executed via one or more physical processing nodes in one or more networks).

[0436] In some embodiments, some or all of the functions described herein can be implemented as virtual components executed by one or more virtual machines (which are implemented in one or more virtual environments 2100 hosted by one or more hardware nodes 2130). Furthermore, in embodiments where the virtual node is not a radio access node or does not require radio connectivity (e.g., a core network node), the network node can be fully virtualized.

[0437] These functionalities can be implemented by one or more applications 2120 (which may alternatively be referred to as software instances, virtual devices, network functions, virtual nodes, virtual network functions, etc.), operable to implement some of the features, functions, and / or benefits of some embodiments disclosed herein. Application 2120 runs in a virtualization environment 2100, which provides hardware 2130 including a processing circuitry module 2160 and a memory 2190. The memory 2190 contains instructions 2195 executable by the processing circuitry module 2160, thereby enabling application 2120 to operate to provide one or more of the features, benefits, and / or functions disclosed herein.

[0438] The virtualization environment 2100 may include general-purpose or special-purpose network hardware devices (or nodes) 2130, which include a collection of one or more processors or processing circuitry modules 2160. These processors or processing circuitry modules may be commercial off-the-shelf (COTS) processors, application-specific integrated circuits (ASICs), or any other type of processing circuitry module (including digital or analog hardware components or special-purpose processors). Each hardware device may include a memory 2190-1, which may be a non-permanent memory for temporarily storing instructions 2195 or software executed by the processing circuitry module 2160. For example, instructions 2195 may include program instructions (also called computer program products) that, when executed by the processing circuitry module 2160, can configure the hardware node 2120 to perform operations corresponding to the various exemplary methods (e.g., procedures) described herein. Such operations can also be considered to be performed by one or more virtual nodes 2120 hosted by the hardware node 2130.

[0439] Each hardware device may include one or more network interface controllers (NICs) 2170 (also referred to as network interface cards), said NIC including a physical network interface 2180. Each hardware device may also include a non-transitory, permanent machine-readable storage medium 2190-2, which stores software 2195 and / or instructions executable by the processing circuitry module 2160. The software 2195 may include any type of software, including software for executing one or more virtualization layers 2150 (also referred to as hypervisors), software for executing a virtual machine 2140, and software that allows it to perform the functions, features, and / or benefits described in relation to some embodiments described herein.

[0440] Virtual machine 2140 includes virtual processing, virtual memory, virtual networking or interfaces, and virtual storage devices, and can be run by a corresponding virtualization layer 2150 or hypervisor. Different embodiments of instances of virtual device 2120 can be implemented on one or more virtual machines in virtual machine 2140, and the implementation can be carried out in different ways.

[0441] During operation, the processing circuit module 2160 executes software 2195 to executor a hypervisor or virtualization layer 2150, which may sometimes be referred to as a virtual machine monitor (VMM). The virtualization layer 2150 can provide a virtual operating platform that appears to the virtual machine 2140 as networked hardware.

[0442] like Figure 21 As shown, hardware 2130 can be a standalone network node with general or specific components. Hardware 2130 can include antenna 21225 and can implement some functions via virtualization. Alternatively, hardware 2130 can be part of a larger cluster of hardware (e.g., in a data center or customer premises equipment (CPE)) where many hardware nodes work together and are managed via management and orchestration (MANO) 21100, which, among other things, oversees the lifecycle management of application 2120.

[0443] In some contexts, hardware virtualization is referred to as Network Functions Virtualization (NFV). NFV enables the integration of many network device types onto industry-standard high-capacity server hardware, physical switches, and physical storage devices, which can reside in data centers and customer premises.

[0444] In the context of NFV, virtual machine 2140 can be a software implementation of a physical machine, which runs programs as if they were executed on a physical, non-virtualized machine. Each virtual machine in virtual machine 2140, and the part of hardware 2130 that executes that virtual machine (if it is hardware dedicated to that virtual machine and / or hardware shared by that virtual machine and other virtual machines in virtual machine 2140), forms a separate virtual network element (VNE).

[0445] Within the context of NFV, a Virtual Network Function (VNF) is responsible for controlling a specific network function running in one or more virtual machines 2140 on top of the hardware networking infrastructure 2130, and corresponds to Figure 21 Application 2120 in the text.

[0446] In some embodiments, one or more radio units 21200, each including one or more transmitters 21220 and one or more receivers 21210, can be coupled to one or more antennas 21225. The radio units 21200 can communicate directly with the hardware node 2130 via one or more suitable network interfaces and can be used in combination with virtual components to provide radio capabilities (such as radio access nodes or base stations) for virtual nodes. Nodes arranged in this manner can also communicate with one or more UEs, as described elsewhere herein.

[0447] In some embodiments, a signaling can be executed via a control system 21230, which can alternatively be used for communication between hardware node 2130 and radio unit 21200.

[0448] Reference Figure 22 According to an embodiment, the communication system includes a telecommunications network 2210 (such as a 3GPP-type cellular network), which includes an access network 2211 (such as a radio access network) and a core network 2222. The access network 2211 includes multiple base stations 2212a, 2212b, and 2212c, such as NBs, eNBs, gNBs, or other types of wireless access points, each defining its own corresponding coverage areas 2213a, 2213b, and 2213c. Each base station 2212a, 2212b, and 2212c can be connected to the core network 2222 via a wired or wireless connection 2215. A first UE 2291 located in coverage area 2213c can be configured to wirelessly connect to or be paged by the corresponding base station 2212c. A second UE 2292 located in coverage area 2213a can wirelessly connect to the corresponding base station 2212a. Although multiple UEs 2291, 2292 are shown in this example, the disclosed embodiments are equally applicable to situations where a single UE is located in a coverage area or where a single UE is connected to a corresponding base station.

[0449] Telecommunications network 2210 is itself connected to host computer 2230, which can be implemented using hardware and / or software of a standalone server, cloud server, distributed server, or as a processing resource in a server cluster. Host computer 2230 can be owned or controlled by a service provider, or can be operated by or on behalf of the service provider. Connections 2221 and 2222 between telecommunications network 2210 and host computer 2230 can extend directly from core network 2222 to host computer 2230, or can be made via optional intermediate network 2220. Intermediate network 2220 can be one or more of public, private, or hosted networks; intermediate network 2220 (if any) can be a backbone network or the Internet; in particular, intermediate network 2220 can include two or more subnetworks (not shown).

[0450] Figure 22The communication system as a whole enables connectivity between the connected UEs 2291 and 2292 and the host computer 2230. This connectivity can be described as an over-the-top (OTT) connection 2250. The host computer 2230 and the connected UEs 2291 and 2292 are configured to transmit data and / or signaling via the OTT connection 2250 using the access network 2211, core network 2222, any intermediate network 2220, and other possible infrastructure (not shown) acting as intermediaries. The OTT connection 2250 can be transparent in the sense that the participating communication devices are unaware of the routing of uplink and downlink communications. For example, it may not be necessary or required to inform the base station 2212 of past routing choices for incoming downlink communications carrying data originating from the host computer 2230 for forwarding (e.g., handover) to the connected UE 2291. Similarly, base station 2212 does not need to know the future routing of outgoing uplink communication originating from UE 2291 toward host computer 2230.

[0451] Now refer to Figure 23 The following describes an example implementation of the UE, base station, and host computer described in the preceding paragraphs according to an embodiment. In the communication system 2300, the host computer 2310 includes hardware 2315, which includes a communication interface 2316 configured to establish and maintain wired or wireless connections with interfaces of different communication devices of the communication system 2300. The host computer 2310 further includes a processing circuit module 2318, which is capable of having storage and / or processing capabilities. In particular, the processing circuit module 2318 may include one or more programmable processors, application-specific integrated circuits, field-programmable gate arrays, or combinations thereof (not shown) suitable for executing instructions. The host computer 2310 further includes software 2311, which is stored in the host computer 2310 or accessible by the host computer 2310 and executable by the processing circuit module 2318. The software 2311 includes a host application 2312. Host application 2312 is operable to provide services to remote users, such as UE 2330 connected via OTT connection 2350 terminated between UE 2330 and host computer 2310. In providing services to remote users, host application 2312 is able to provide user data transmitted using OTT connection 2350.

[0452] The communication system 2300 may also include a base station 2320, provided in a telecommunications system, and including hardware 2325 enabling it to communicate with a host computer 2310 and a UE 2330. Hardware 2325 may include: a communication interface 2326 for establishing and maintaining wired or wireless connections with different communication devices of the communication system 2300; and a radio interface 2327 for establishing and maintaining at least a wireless connection 2370 with the UE 2330, the UE being located within the coverage area served by the base station 2320. Figure 23 (Not shown in the image). The communication interface 2326 can be configured to facilitate a connection 2360 to the host computer 2310. The connection 2360 can be direct, or it can be via the core network of a telecommunications system (…). Figure 23 (not shown) and / or via one or more intermediate networks outside the telecommunications system. In the illustrated embodiment, the hardware 2325 of the base station 2320 may also include a processing circuit module 2328, which may include one or more programmable processors, application-specific integrated circuits, field-programmable gate arrays, or combinations thereof (not shown) suitable for executing instructions.

[0453] Base station 2320 also includes software 2321, which is stored internally or accessible via an external connection. For example, software 2321 may include program instructions (also referred to as a computer program product) that, when executed by processing circuit module 2328, can configure base station 2320 to perform operations corresponding to the various exemplary methods (e.g., procedures) described herein.

[0454] The communication system 2300 may also include the previously mentioned UE 2330, whose hardware 2335 may include a radio interface 2337 configured to establish and maintain a wireless connection 2370 with a base station serving the coverage area where the UE 2330 is currently located. The hardware 2335 of the UE 2330 may also include a processing circuit module 2338, which may include one or more programmable processors, application-specific integrated circuits, field-programmable gate arrays, or combinations thereof (not shown) suitable for executing instructions.

[0455] UE 2330 also includes software 2331, which is stored in UE 2330 or accessible by UE 2330 and executable by processing circuitry module 2338. Software 2331 includes a client application 2332. Client application 2332 is operable to provide services to human or non-human users via UE 2330 with the support of host computer 2310. Host application 2312, executed in host computer 2310, can communicate with client application 2332 via OTT connection 2350 terminated between UE 2330 and host computer 2310. When providing services to a user, client application 2332 can receive request data from host application 2312 and provide user data in response to the request data. OTT connection 2350 can transmit request data and user data. Client application 2332 can interact with the user to generate the user data it provides. The software 2331 may also include program instructions (also known as computer program products) that, when executed by the processing circuit module 2338, can configure the UE 2330 to perform operations corresponding to the various exemplary methods (e.g., procedures) described herein.

[0456] As an example, Figure 23 The host computer 2310, base station 2320, and UE 2330 shown are respectively able to communicate with Figure 22 The host computer 2230, base stations 2212a, 2212b, and 2212c, and UEs 2291 and 2292 are similar to or identical to each other. That is, the internal operation of these entities is as follows: Figure 23 As shown, and unrelated to this, the surrounding network topology could be Figure 22 The network topology.

[0457] Figure 23 In this context, OTT connection 2350 abstractly represents communication between host computer 2310 and UE 2330 via base station 2320, without explicitly mentioning any intermediate devices or the exact routing of messages through these devices. The network infrastructure is capable of determining the routing, which can be configured to be hidden from UE 2330, the service provider operating host computer 2310, or both. While OTT connection 2350 is active, the network infrastructure can further make decisions, dynamically altering the routing (e.g., based on network load balancing considerations or reconfiguration).

[0458] The radio connection 2370 between UE 2330 and base station 2320 is based on the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments utilize OTT connection 2350 to improve the performance of OTT services provided to UE 2330, wherein radio connection 2370 forms the final segment. More precisely, the exemplary embodiments disclosed herein enable flexibility in the end-to-end Quality of Service (QoS) of data flows (including their corresponding radio bearers) associated with data sessions between network monitoring and user equipment (UE) and another entity (such as an OTT data application or service outside the 5G network). These and other advantages facilitate more timely design, implementation, and deployment of 5G / NR solutions. Furthermore, such embodiments facilitate flexible and timely control of data session QoS, which can lead to improvements in capacity, throughput, latency, etc., as envisioned by 5G / NR and important for the growth of OTT services.

[0459] A measurement process can be provided to monitor improvements in data rate, latency, and other network operational aspects of one or more embodiments. Optional network functionality for reconfiguring the OTT connection 2350 between host computer 2310 and UE 2330 in response to changes in measurement results is also possible. The measurement process and / or the network functionality for reconfiguring the OTT connection 2350 can be implemented using software 2311 and hardware 2315 of host computer 2310, or software 2331 and hardware 2335 of UE 2330, or both. In embodiments, sensors (not shown) can be deployed in or associated with communication devices through which the OTT connection 2350 passes; the sensors can participate in the measurement process by providing values ​​of the monitored quantities illustrated above, or by providing values ​​of other physical quantities from which software 2311, 2331 can calculate or estimate the monitored quantities. Reconfiguration of the OTT connection 2350 can include message formatting, retransmission settings, preferred routing, etc.; reconfiguration does not affect the base station 2320, and it can be unknown or undetected by the base station 2320. Such processes and functionalities are known and can be implemented in the art. In some embodiments, measurements can involve proprietary UE signaling that facilitates the host computer 2310 to measure throughput, propagation time, latency, etc. Measurements are possible because software 2311 and 2331 enable messages to be transmitted using the OTT connection 2350, particularly empty or 'pseudo' messages, while monitoring propagation time, errors, etc.

[0460] Figure 24This is a flowchart illustrating an exemplary method and / or process implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, which in some exemplary embodiments may be those host computers, base stations, and UEs described with reference to the other figures herein. For the sake of brevity, this section will only include descriptions of... Figure 24 The accompanying drawings are referenced. In step 2410, the host computer provides user data. In sub-step 2411 of step 2410 (which may be optional), the host computer provides user data by executing a host application. In step 2420, the host computer initiates a transmission carrying user data to the UE. According to the teachings of the embodiments described throughout this disclosure, in step 2430 (which may be optional), the base station transmits user data to the UE, the user data being carried in the transmission initiated by the host computer. In step 2440 (which may also be optional), the UE executes a client application associated with the host application executed by the host computer.

[0461] Figure 25 This is a flowchart illustrating an exemplary method and / or process implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, which can be those host computers, base stations, and UEs described with reference to the other figures herein. For the sake of brevity, this section will only include descriptions of... Figure 25 The accompanying drawings are referenced. In step 2510 of the method, the host computer provides user data. In an optional sub-step (not shown), the host computer provides user data by executing a host application. In step 2520, the host computer initiates a transmission carrying user data to the UE. According to the teachings of the embodiments described throughout this disclosure, the transmission can be carried out via a base station. In step 2530 (which may be optional), the UE receives the user data carried in the transmission.

[0462] Figure 26 This is a flowchart illustrating an exemplary method and / or process implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, which can be those host computers, base stations, and UEs described with reference to the other figures herein. For the sake of brevity, this section will only include descriptions of... Figure 26The accompanying drawings are referenced. In step 2610 (which may be optional), the UE receives input data provided by the host computer. Alternatively, in step 2620, the UE provides user data. In sub-step 2621 of step 2620 (which may be optional), the UE provides user data by executing a client application. In sub-step 2611 of step 2610 (which may be optional), the UE executes a client application that responds to the received input data provided by the host computer to provide user data. When providing user data, the executed client application may further consider user input received from the user. Regardless of the specific manner in which user data is provided, the UE provides the transmission of user data to the host computer in sub-step 2630 (which may be optional). According to the teachings of the embodiments described throughout this disclosure, in step 2640 of the method, the host computer receives user data transmitted from the UE.

[0463] Figure 27 This is a flowchart illustrating an exemplary method and / or process implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, which can be those host computers, base stations, and UEs described with reference to the other figures herein. For the sake of brevity, this section will only include descriptions of... Figure 27 The accompanying drawings are referenced. In step 2710 (which may be optional), the base station receives user data from the UE according to the teachings of the embodiments described throughout this disclosure. In step 2720 (which may be optional), the base station initiates a transmission of the received user data to the host computer. In step 2730 (which may be optional), the host computer receives the user data carried in the transmission initiated by the base station.

[0464] The above merely illustrates the principles of this disclosure. Various modifications and variations to the described embodiments will be readily apparent to those skilled in the art considering the teachings herein. Therefore, it will be appreciated that those skilled in the art will be able to design numerous systems, arrangements, and processes that, while not expressly shown or described herein, implement the principles of this disclosure and thus fall within its spirit and scope. Various exemplary embodiments can be used together and interchangeably with each other, as will be understood by those of ordinary skill in the art.

[0465] As used herein, the term "unit" can have the conventional meaning in the field of electronic, electrical and / or electronic devices, and can include, for example, electrical and / or electronic circuit modules, devices, modules, processors, memories, logic solid-state and / or discrete devices, computer programs or instructions for performing corresponding tasks, processes, calculations, output and / or display functions, and other aspects such as those described herein.

[0466] Any suitable steps, methods, features, functions, or benefits disclosed herein may be performed by one or more functional units or modules of one or more virtual devices. Each virtual device may include multiple such functional units. These functional units may be implemented via processing circuitry modules, which may include one or more microprocessors or microcontrollers and may include digital signal processors (DSPs), application-specific digital logic, and other digital hardware such as these. The processing circuitry modules may be configured to execute program code stored in memory, which may include one or more types of memory, such as read-only memory (ROM), random access memory (RAM), cache memory, flash memory devices, optical storage devices, etc. The program code stored in the memory includes program instructions for executing one or more remote communication and / or data communication protocols and instructions for executing one or more of the techniques described herein. In some implementations, according to one or more embodiments of this disclosure, the processing circuitry modules may be used to cause corresponding functional units to perform corresponding functions.

[0467] As described herein, devices and / or apparatuses can be represented by semiconductor chips, chipsets, or (hardware) modules comprising such chips or chipsets; however, this does not preclude the possibility that the functionality of a device or apparatus is implemented not in hardware but as a software module (such as a computer program or computer program product comprising executable software code portions for or running on a processor). Furthermore, the functionality of a device or apparatus can be implemented through any combination of hardware and software. A device or apparatus can also be viewed as a combination of multiple devices and / or apparatuses, whether functionally cooperative or independent. Moreover, devices and apparatuses can be implemented in a distributed manner throughout the system, provided that the functionality of the devices or apparatuses is maintained. Such and similar principles are considered known to those skilled in the art.

[0468] Unless otherwise defined, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. It will be further understood that the terms used herein shall be interpreted as having the same meaning as they have in the context of this specification and the relevant art, and not in an idealized or overly formal sense, unless expressly defined herein.

[0469] Furthermore, certain terms used in this disclosure (including the specification and drawings) can be used synonymously in certain instances (e.g., "data" and "information"). It should be understood that while these terms (and / or other terms that can be synonymous with each other) can be used synonymously herein, there may be instances where such terms are not expected to be used synonymously. Further, prior art knowledge is incorporated herein by reference in its entirety, unless otherwise explicitly stated above. All cited publications are incorporated herein by reference in their entirety.

[0470] Example embodiments of the technologies and devices described herein include, but are not limited to, the following enumerated examples:

[0471] A1. A method for migrating an Integrated Access Backhaul (IAB) node from a first Centralized Unit (CU) to a second CU in a wireless network, the method comprising:

[0472] A first handover (HO) command is received from the first CU via the source parent IAB node, wherein the HO command includes an identifier of the target cell for the handover;

[0473] The HO command is determined to be used for inter-CU migration from the IAB node to the second CU;

[0474] Based on the determination that the HO command is used for inter-CU migration, modified manipulation of uplink (UL) and / or downlink (DL) data buffered at the IAB node is performed until the execution of the HO command.

[0475] A2. The method of embodiment A1, wherein determining the HO command for inter-CU migration is based on one or more of the following:

[0476] The target cell identifier does not match any identifier associated with the current serving cell of the IAB node;

[0477] The target base station identifier within the target cell identifier does not match the base station identifier associated with the first CU;

[0478] The HO command contains an explicit indication that the HO is a migration between CUs.

[0479] A3. The method of any of the embodiments A1-A2 further includes: determining that one or more downstream nodes in the IAB network also undergo inter-CU migration of the second CU.

[0480] A4. The method of embodiment A3, wherein determining that the one or more downstream nodes also undergo the inter-CU migration is based on one or more of the following:

[0481] Regarding the determination of the HO command for CU-to-CU migration from the IAB node to the second CU;

[0482] The HO command contains an explicit indication that the one or more downstream nodes also undergo inter-CU migration; and

[0483] A second HO command for a child node of the IAB node, the second HO command being sent from the first CU to the child node via the IAB node.

[0484] A5. The method of any of the embodiments A1-A4 further includes: receiving instructions for modified manipulation of buffered UL and / or DL ​​data, wherein the modified manipulation of the data buffered at the IAB node is performed according to the instructions.

[0485] A6. The method of embodiment A5, wherein the instructions include:

[0486] One or more first criteria related to the amount of DL data buffered at the IAB node; and

[0487] One or more second criteria relating to whether DL data buffered at the IAB node should be deleted or forwarded to the corresponding downstream node.

[0488] A7. The method of embodiment A6, wherein the second criterion includes one or more of the following:

[0489] Indicators that all types of buffered DL data should be deleted or forwarded;

[0490] The list of backhaul radio link control (BH RLC channels) from which the buffered DL data should be forwarded;

[0491] A list of BH RLC channels whose buffered DL data should be deleted;

[0492] A QoS profile and / or priority list for the buffered DL data to be forwarded should be provided.

[0493] The QoS profiles and / or priority lists of the buffered DL data should be removed.

[0494] A list of Backhaul Adaptation Protocol (BAP) routing identifiers should be provided for forwarding the buffered DL data; and

[0495] The list of BAP routing identifiers that buffer DL data should be removed.

[0496] A8. The method of any of the embodiments A5-A7, wherein:

[0497] The instructions also include:

[0498] One or more third criteria related to the amount of UL data buffered at one or more downstream nodes, and

[0499] One or more fourth criteria relating to whether UL approval should be provided for UL data buffered at the downstream IAB node; and

[0500] The method further includes: based on determining that the HO command is used for inter-CU migration, performing modified manipulation of UL data buffered in one or more downstream IAB nodes according to the instruction until the HO command is executed.

[0501] A9. The method of embodiment A8, wherein the third criterion is used to identify the quantity according to one or more of the following:

[0502] All buffered UL data;

[0503] Explicit quantities of buffered UL data;

[0504] The percentage of buffered UL data;

[0505] Duration.

[0506] A10. The method of any of the embodiments A8-A9, wherein the fourth criterion includes one or more of the following:

[0507] Regarding the requirement that UL-approved indicators should be provided for all buffered UL data;

[0508] A list of UL-approved backhaul radio link control (BH RLC channels) should be provided.

[0509] They should be provided with a list of QoS profiles and / or priorities approved by UL; and

[0510] A list of UL-approved Backhaul Adaptation Protocol (BAP) routing identifiers should be provided.

[0511] A11. The method of embodiment A5, wherein the instructions include:

[0512] One or more first criteria related to the amount of UL data buffered at the IAB node; and

[0513] One or more second criteria relating to whether a Buffer Status Report (BSR) should be transmitted to the parent node for UL data buffered at the IAB node.

[0514] A12. The method of embodiment A11, wherein the second criterion includes one or more of the following:

[0515] Instructions regarding the transmission of BSR for all types of buffered UL data;

[0516] The list of backhaul radio link control (BH RLC channels) whose BSR should be transmitted;

[0517] The list of BH RLC channels to which its BSR should be transmitted;

[0518] Its BSR should be transmitted along with a QoS profile and / or a list of priorities;

[0519] Its BSR should be a list of Backhaul Adaptation Protocol (BAP) routing identifiers.

[0520] A13. The method of any of the embodiments A6-A12, wherein each of the first criteria is identified according to one or more of the following:

[0521] All buffered data;

[0522] The explicit amount of buffered data;

[0523] The percentage of buffered data;

[0524] Duration.

[0525] B1. A method for an Integrated Access Backhaul (IAB) node in a wireless network, the method being used to control the migration of a sub-IAB node from a first centralized unit (CU) to a second CU, the method comprising:

[0526] Receive a message from the first CU, the message including a handover (HO) command from the sub-IAB node to the target cell;

[0527] The HO command is determined to be used for CU-to-CU migration from the sub-IAB node to the second CU; and

[0528] Based on the determination that the HO command is used for inter-CU migration, perform modified operations on one or more of the following until the HO command is forwarded to the child IAB node:

[0529] The uplink (UL) buffered by the sub-IAB node and associated with the sub-IAB node; and

[0530] Downlink (DL) data buffered at the IAB node and associated with the child IAB node.

[0531] B2. The method of embodiment A1, wherein determining the HO command for inter-CU migration is based on an explicit indication within the message regarding the HO command for inter-CU migration of the sub-IAB node.

[0532] B3. The method of any of the embodiments B1-B2 further includes: receiving instructions for modified manipulation of buffered UL and / or DL ​​data, wherein the modified manipulation of the buffered UL and / or DL ​​data associated with the sub-IAB node is performed according to the instructions.

[0533] B4. The method of embodiment B3, wherein the instructions include one or more of the following:

[0534] One or more first criteria related to the amount of DL data buffered at the IAB node;

[0535] One or more second criteria relating to whether DL data buffered at the IAB node should be deleted or forwarded to the corresponding downstream node; and

[0536] One or more third criteria related to the amount of UL data buffered at one or more downstream nodes, and

[0537] One or more fourth criteria related to whether UL approval should be provided for UL data buffered at the downstream IAB node.

[0538] B5. The method of embodiment B4, wherein each of the first and third criteria is identified according to one or more of the following:

[0539] All buffered data;

[0540] The explicit amount of buffered data;

[0541] The percentage of buffered data;

[0542] Duration.

[0543] B6. The method of any of the embodiments B4-B5, wherein the second criterion includes one or more of the following:

[0544] Indicators that all types of buffered DL data should be deleted or forwarded;

[0545] The list of backhaul radio link control (BH RLC channels) from which the buffered DL data should be forwarded;

[0546] A list of BH RLC channels whose buffered DL data should be deleted;

[0547] A QoS profile and / or priority list for the buffered DL data to be forwarded should be provided.

[0548] The QoS profiles and / or priority lists of the buffered DL data should be removed.

[0549] A list of Backhaul Adaptation Protocol (BAP) routing identifiers should be provided for forwarding the buffered DL data; and

[0550] The list of BAP routing identifiers that buffer DL data should be removed.

[0551] B7. The method of any of the embodiments B4-B6, wherein the fourth criterion includes one or more of the following:

[0552] Regarding the requirement that UL-approved indicators should be provided for all buffered UL data;

[0553] A list of UL-approved backhaul radio link control (BH RLC channels) should be provided.

[0554] They should be provided with a list of QoS profiles and / or priorities approved by UL; and

[0555] A list of UL-approved Backhaul Adaptation Protocol (BAP) routing identifiers should be provided.

[0556] B8. The method of any of the embodiments B1-B7, wherein the IAB node has not undergone inter-CU migration of the second CU.

[0557] B9. The method of any of the embodiments B1-B8 further includes: forwarding the HO command to the sub-IAB node after completing the modified manipulation of the buffered UL and / or DL ​​data associated with the sub-IAB node.

[0558] C1. An Integrated Access Backhaul (IAB) node configured to operate in a wireless network, the IAB node comprising:

[0559] The radio interface circuit module and processing circuit module are configured as a mobile terminal (IAB-MT) and a distributed unit (IAB-DU).

[0560] The processing circuit module and the radio interface circuit module are further configured to perform operations corresponding to any of the methods in embodiments A1-A13 and B1-B9.

[0561] C2. An Integrated Access Backhaul (IAB) node configured to operate in a wireless network, the IAB node being arranged as a mobile terminal (IAB-MT) and a distributed unit (IAB-DU), and further configured to perform operations corresponding to any of the methods of embodiments A1-A13 and B1-B9.

[0562] C3. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by a processing circuitry module of an integrated access backhaul (IAB) node, configure the IAB node to perform operations corresponding to any of the methods in embodiments A1-A13 and B1-B9.

[0563] C4. A computer program product including computer-executable instructions that, when executed by a processing circuitry module of an integrated access backhaul (IAB) node, configure the IAB node to perform operations corresponding to any of the methods in embodiments A1-A13 and B1-B9.

Claims

1. A method for migrating an Integrated Access Backhaul (IAB) node from a first centralized unit (CU) to a second CU in a wireless network, the method comprising: A handover HO command (1710) is received from the first CU via the source parent IAB node, wherein the HO command includes an identifier of the target cell for the handover; It is determined that the HO command (1720) is used for CU-to-CU migration from the IAB node to the second CU; Receive (1740) an instruction for modified manipulation of uplink UL data and / or downlink DL data buffered at the IAB node, wherein the instruction includes one or more of the following: one or more first criteria related to the amount of DL data buffered at the IAB node; one or more second criteria related to whether the DL data buffered at the IAB node should be deleted or forwarded to the corresponding descendant node; and one or more third criteria related to the amount of UL data buffered at the IAB node. One or more fourth criteria relating to whether a Buffer Status Report (BSR) should be transmitted to the parent node for UL data buffered at the IAB node; and Based on the determination that the HO command is used for inter-CU migration, the modified manipulation of the UL data and / or DL ​​data buffered at the IAB node is performed according to the instruction (1750) until the execution of the HO command.

2. The method as described in claim 1, wherein, Performing modified manipulations on the UL data and / or DL ​​data buffered at the IAB node includes one or more of the following: Forward (1751) at least a portion of the DL data buffered at the IAB node. Forward (1752) at least a portion of the UL data buffered at the IAB node. Delete (1753) at least a portion of the DL data buffered in the IAB node, and Delete (1754) at least a portion of the UL data buffered at the IAB node.

3. The method as described in claim 1, wherein, The determination that the HO command (1720) is used for inter-CU migration is based on one or more of the following: The identifier of the target cell does not match any identifier associated with the current serving cell used for the IAB node; The target base station identifier within the identifier of the target cell does not match the base station identifier associated with the first CU; and The HO command contains an explicit indication that the HO is a migration between CUs.

4. The method of claim 1, further comprising determining (1730) that one or more descendant nodes of the IAB node also undergo inter-CU migration of the second CU.

5. The method of claim 4, wherein, The determination (1730) that the one or more descendant nodes also undergo the inter-CU migration is based on one or more of the following: It is determined that the HO command (1720) is used for CU-to-CU migration from the IAB node to the second CU; The HO command contains an explicit indication that the one or more descendant nodes also undergo the inter-CU migration; as well as A second HO command for a child node of the IAB node, the second HO command being sent from the first CU to the child node via the IAB node.

6. The method according to any one of claims 1-5, wherein, The second criterion includes one or more of the following: Indicators that all types of buffered DL data should be deleted or forwarded; The list of backhaul radio link control (BH) RLC channels to which the buffered DL data should be forwarded; A list of BH RLC channels whose buffered DL data should be deleted; The list of access RLC channels to which the buffered DL data should be forwarded; The list of access RLC channels whose buffered DL data should be deleted; A QoS profile and / or priority list for the buffered DL data to be forwarded should be provided. The QoS profiles and / or priority lists of the buffered DL data should be removed. It should be a list of BAP routing identifiers for the backhaul adaptation protocol that forwards buffered DL data; as well as The list of BAP routing identifiers that buffer DL data should be removed.

7. The method according to any one of claims 1-5, wherein, Each of the first and third criteria is identified according to one or more of the following: All buffered data; The explicit amount of buffered data; The percentage of buffered data; Duration.

8. The method according to any one of claims 1-5, wherein, The fourth criterion includes one or more of the following: Instructions regarding the transmission of BSR for all types of buffered UL data; A list of BSR backhaul radio link control (BH) RLC channels should be transmitted to it; A list of BSR access RLC channels should be transmitted to it; The QoS profile and / or priority list of the BSR should be sent to it; as well as A list of BSR backhaul adaptation protocol BAP routing identifiers should be transmitted to it.

9. The method according to any one of claims 1-5, wherein: Instructions for modified manipulation of buffered UL data and / or buffered DL data include instructions for modified manipulation of UL data buffered in one or more descendant nodes of the IAB node. as well as The method further includes: based on determining that the HO command is used for inter-CU migration, performing (1760) modified manipulation of UL data buffered in the one or more descendant nodes according to the instruction, and until the execution of the HO command.

10. The method of claim 9, wherein, Performing (1760) modified manipulation of UL data buffered at one or more downstream nodes includes one or more of the following: Provide (1761) UL permission for at least a portion of the UL data buffered in one or more child nodes of the IAB node; Suppression provides (1762) UL permission for at least a portion of the UL data buffered in one or more child nodes; as well as Provide (1763) instructions to the one or more child nodes for manipulating the UL data buffered in the descendant nodes of the one or more child nodes.

11. The method of claim 9, wherein, Instructions for modified manipulation of UL data buffered in the one or more descendant nodes include one or more of the following: A first configuration for manipulating the UL data buffered in the first child node of the IAB node; A second configuration for manipulating the UL data buffered in the second child node of the IAB node; as well as A third configuration is used to manipulate the UL data buffered in both the first and second child nodes.

12. The method of claim 9, wherein, Instructions for modified manipulation of UL data buffered in one or more descendant nodes include: One or more fifth criteria related to the amount of UL data buffered in one or more descendant nodes; and One or more sixth criteria relating to whether UL approval should be provided for UL data buffered at one or more descendant nodes.

13. The method of claim 12, wherein, The sixth criterion includes one or more of the following: Regarding the requirement that UL-approved indicators should be provided for all buffered UL data; A list of UL-approved Backhaul Radio Link Control (BH) RLC channels should be provided. A list of UL-approved access channels for RLC should be provided. They should be provided with a list of QoS profiles and / or priorities approved by UL; and A list of UL-approved Backhaul Adaptation Protocol (BAP) routing identifiers should be provided.

14. A method for integrating the migration of any node from a first centralized unit (CU) to a second CU in a wireless network by controlling the operation of an access backhaul IAB node, a sub-IAB node, and its descendant nodes, the method comprising: Receive message (1810) from the first CU, the message including a handover HO command for the sub-IAB node to the target cell; It is determined (1820) that the HO command is used for CU-to-CU migration from the sub-IAB node to the second CU; Receive (1830) instructions for modified manipulation of uplink UL data buffered at the sub-IAB node and / or downlink DL data buffered at the IAB node and associated with the sub-IAB node, wherein the instructions include one or more of the following: one or more first criteria related to the amount of DL data buffered at the IAB node; one or more second criteria related to whether the DL data buffered at the IAB node should be deleted or forwarded to the corresponding descendant node; one or more third criteria related to the amount of UL data buffered at one or more descendant nodes; and one or more fourth criteria related to whether UL permission should be granted for the UL data buffered at one or more descendant nodes; and Based on the determination that the HO command is used for inter-CU migration, the modified operation (1840) is performed according to the instruction on one or more of the following: The UL data buffered in the sub-IAB node; and DL data buffered in the IAB node and associated with the child IAB node.

15. The method of claim 14, wherein, Executing the modified operation described in (1840) includes one or more of the following until the HO command is forwarded to the child IAB node: Forward (1841) at least a portion of the DL data buffered in the IAB node. Forward (1842) at least a portion of the UL data buffered in the sub-IAB node. Delete (1843) at least a portion of the DL data buffered in the IAB node, and Delete (1844) at least a portion of the UL data buffered in the sub-IAB node.

16. The method of claim 14, wherein, The determination (1820) that the HO command is used for inter-CU migration is based on the explicit indication within the message regarding the HO command being used for inter-CU migration of the sub-IAB node.

17. The method of claim 14, wherein, Each of the first and third criteria is identified according to one or more of the following: All buffered data; The explicit amount of buffered data; The percentage of buffered data; Duration.

18. The method of claim 14, wherein, The second criterion includes one or more of the following: Indicators that all types of buffered DL data should be deleted or forwarded; The list of backhaul radio link control (BH) RLC channels to which the buffered DL data should be forwarded; A list of BH RLC channels whose buffered DL data should be deleted; A list of radio bearers that should be used to forward buffered DL data; The list of radio bearers for the buffered DL data should be removed. A QoS profile and / or priority list for the buffered DL data to be forwarded should be provided. The QoS profiles and / or priority lists of the buffered DL data should be removed. It should be a list of BAP routing identifiers for the backhaul adaptation protocol that forwards buffered DL data; as well as The list of BAP routing identifiers that buffer DL data should be removed.

19. The method according to any one of claims 14-18, wherein, The fourth criterion includes one or more of the following: Regarding the requirement that UL-approved indicators should be provided for all buffered UL data; A list of UL-approved Backhaul Radio Link Control (BH) RLC channels should be provided. A list of UL-approved radio bearers should be provided. They should be provided with a list of QoS profiles and / or priorities approved by UL; and A list of UL-approved Backhaul Adaptation Protocol (BAP) routing identifiers should be provided.

20. The method according to any one of claims 14-18, wherein, The IAB node did not undergo inter-CU migration of the second CU.

21. The method of any one of claims 14-18, further comprising: After completing the modified manipulation of the UL data buffered in the sub-IAB node and / or the DL data buffered in the IAB, the HO command is forwarded to the sub-IAB node.

22. An integrated access backhaul (IAB) node (311-315, 730, 1630) in a wireless network (399, 799), the integrated access backhaul (IAB) node being configured to migrate from a first centralized unit (CU) (710, 1610) to a second CU (720, 1620), the IAB node comprising: Radio interface circuit modules (1914, 1990, 2009, 2031, 2170, 21200, 2327, 2337) and processing circuit modules (1920, 1970, 2001, 2160, 2328, 2338) configured as mobile terminals (731) and distributed units (732). The processing circuit module and the radio interface circuit module are further configured as follows: The handover HO command is received from the first CU via the source parent IAB node, wherein the HO command includes an identifier of the target cell for the handover; The HO command is determined to be used for inter-CU migration from the IAB node to the second CU; Receive instructions for modified manipulation of uplink UL data and / or downlink DL data buffered at the IAB node, wherein the instructions include one or more of the following: one or more first criteria related to the amount of DL data buffered at the IAB node; one or more second criteria related to whether the DL data buffered at the IAB node should be deleted or forwarded to the corresponding descendant node; one or more third criteria related to the amount of UL data buffered at the IAB node; one or more fourth criteria related to whether a buffer status report (BSR) should be transmitted to the parent node for the UL data buffered at the IAB node; and Based on the determination that the HO command is used for inter-CU migration, modified manipulation of the UL data and / or DL ​​data buffered at the IAB node is performed according to the instruction until the HO command is executed.

23. The IAB node as described in claim 22, wherein, The processing circuit module and the radio interface circuit module are further configured to perform the method as described in any one of claims 2-13.

24. An integrated access backhaul (IAB) node (311-315, 730, 1630) in a wireless network (399, 799), the integrated access backhaul (IAB) node being configured to migrate from a first centralized unit (CU) (710, 1610) to a second CU (720, 1620), the IAB node being configured as a mobile terminal (731) and a distributed unit (732), the IAB node being further configured to: The handover HO command is received from the first CU via the source parent IAB node, wherein the HO command includes an identifier of the target cell for the handover; The HO command is determined to be used for inter-CU migration from the IAB node to the second CU; Receive instructions for modified manipulation of uplink UL data and / or downlink DL data buffered at the IAB node, wherein the instructions include one or more of the following: one or more first criteria related to the amount of DL data buffered at the IAB node; one or more second criteria related to whether the DL data buffered at the IAB node should be deleted or forwarded to the corresponding descendant node; and one or more third criteria related to the amount of UL data buffered at the IAB node. One or more fourth criteria related to whether or not a buffer status report (BSR) should be transmitted to the parent node for UL data buffered at the IAB node. as well as Based on the determination that the HO command is used for inter-CU migration, modified manipulation of the UL data and / or DL ​​data buffered at the IAB node is performed according to the instruction until the HO command is executed.

25. The IAB node of claim 24, further configured to perform the method of any one of claims 2-13.

26. A non-transitory computer-readable medium (1930, 1980, 2021, 2190) storing computer-executable instructions, which, when executed by a processing circuit module (1920, 1970, 2001, 2160, 2328, 2338) of an integrated access backhaul IAB node (311-315, 730, 1630) in a wireless network (399, 799), configure the IAB node to perform the method as described in any one of claims 1-13.

27. A computer program product (2025, 2195, 2321, 2331) comprising computer-executable instructions, wherein the computer-executable instructions, when executed by a processing circuit module (1920, 1970, 2001, 2160, 2328, 2338) of an integrated access backhaul IAB node (311-315, 730, 1630) in a wireless network (399, 799), configure the IAB node to perform the method as described in any one of claims 1-13.

28. An integrated access backhaul IAB node (311-315, 740, 1640) in a wireless network (399, 799), the integrated access backhaul IAB node being configured to control the migration of sub-IAB nodes (311-315, 730, 1630) from a first centralized unit CU (710, 1610) to a second CU (720, 1620), the IAB node comprising: Radio interface circuit modules (1914, 1990, 2009, 2031, 2170, 21200, 2327, 2337) and processing circuit modules (1920, 1970, 2001, 2160, 2328, 2338) configured as mobile terminals (731) and distributed units (732). The processing circuit module and the radio interface circuit module are further configured as follows: Receive a message from the first CU, the message including a handover HO command for the sub-IAB node to the target cell; The HO command is determined to be used for CU-to-CU migration from the sub-IAB node to the second CU; Receive instructions for modified manipulation of uplink UL data buffered at the sub-IAB node and / or downlink DL data buffered at the IAB node and associated with the sub-IAB node, wherein the instructions include one or more of the following: one or more first criteria related to the amount of DL data buffered at the IAB node; one or more second criteria related to whether the DL data buffered at the IAB node should be deleted or forwarded to the corresponding descendant node; one or more third criteria related to the amount of UL data buffered at one or more descendant nodes; and one or more fourth criteria related to whether UL approval should be granted for the UL data buffered at one or more descendant nodes; and Based on the determination that the HO command is used for inter-CU migration, modified operations are performed on one or more of the following according to the instructions: The UL data buffered in the sub-IAB node; and DL data buffered in the IAB node and associated with the child IAB node.

29. The IAB node as described in claim 28, wherein, The processing circuit module and the radio interface circuit module are further configured to perform the method as described in any one of claims 15-21.

30. An integrated access backhaul IAB node (311-315, 740, 1640) in a wireless network (399, 799), the integrated access backhaul IAB node being configured to control the migration of sub-IAB nodes (311-315, 730, 1630) from a first centralized unit CU (710, 1610) to a second CU (720, 1620), the IAB node being configured as a mobile terminal (741) and a distributed unit (742), the IAB node being further configured to: Receive a message from the first CU, the message including a handover HO command for the sub-IAB node to the target cell; The HO command is determined to be used for CU-to-CU migration from the sub-IAB node to the second CU; Receive instructions for modified manipulation of uplink UL data buffered at the child IAB node and / or downlink DL data buffered at the IAB node and associated with the child IAB node, wherein the instructions include one or more of the following: one or more first criteria related to the amount of DL data buffered at the IAB node; one or more second criteria related to whether the DL data buffered at the IAB node should be deleted or forwarded to the corresponding descendant node; one or more third criteria related to the amount of UL data buffered at one or more descendant nodes; and one or more fourth criteria related to whether UL approval should be granted for the UL data buffered at one or more descendant nodes; and Based on the determination that the HO command is used for inter-CU migration, modified operations are performed on one or more of the following according to the instructions: The UL data buffered in the sub-IAB node; and DL data buffered in the IAB node and associated with the child IAB node.

31. The IAB node of claim 30, further configured to perform the method of any one of claims 15-21.

32. A non-transitory computer-readable medium (1930, 1980, 2021, 2190) storing computer-executable instructions, which, when executed by a processing circuit module (1920, 1970, 2001, 2160, 2328, 2338) of an integrated access backhaul IAB node (311-315, 740, 1640) in a wireless network (399, 799), configure the IAB node to perform the method as described in any one of claims 14-21.

33. A computer program product (2025, 2195, 2321, 2331) comprising computer-executable instructions, wherein the computer-executable instructions, when executed by a processing circuit module (1920, 1970, 2001, 2160, 2328, 2338) of an integrated access backhaul IAB node (311-315, 740, 1640) in a wireless network (399, 799), configure the IAB node to perform the method as described in any one of claims 14-21.

Images