Managing connections to multiple centralized units

Abstract

A distributed unit (DU) operating in a radio access network (RAN) for establishing a connection with a centralized unit (CU) operating in the RAN, (i) sending (1802) a first interface message to a first CU to establish a first connection between the DU and the first CU, and (ii) sending (1804) a second interface message to a second CU via the first CU to establish a second connection between the DU and the second CU via the first CU, thereby maintaining the first connection and the second connection simultaneously.

Description

Technical Field

[0001] This disclosure generally relates to wireless communications, and more specifically, to F1 connections managed to multiple centralized unit (CUS) or integrated access and backhaul (IAB) donors. Background Technology

[0002] This background description is provided for the purpose of presenting the overall context of this disclosure. The work of the currently attributed inventors, to the extent described in this background section, and in respect of aspects that may not qualify as prior art at the time of filing for other different reasons, is neither expressly nor implicitly acknowledged as prior art to this disclosure.

[0003] Generally, Integrated Access and Backhaul (IAB) enables radio relay in a Radio Access Network (RAN). Relay nodes (referred to as IAB nodes) support access and backhaul via New Radio (NR). The terminating node of the NR backhaul on the network side is called the IAB donor, which represents a base station with the additional functionality to support IAB. Backhaul can occur via single hop or multi-hop, allowing User Equipment (UE) to communicate with the RAN via one or more IAB nodes and the IAB donor. The IAB donor provides network access to the UE through the system of backhaul and access links.

[0004] IAB donors enable a distributed architecture and include an IAB donor CU and one or more IAB donor DUs. In a 5G network architecture, the IAB donor CU is the gNB-CU of the IAB donor, terminating at the F1 interface with the IAB node and the IAB donor DU. An IAB donor DU can be a gNB-DU of the IAB donor. The IAB donor DU can host the IAB BAP sublayer (as defined in the TS 38.340 Backhaul Adaptation Protocol (BAP), v.16.2.0), which provides radio backhaul to the IAB node.

[0005] An IAB node is a RAN node capable of supporting NR access links to the UE and NR backhaul links to (multiple) parent nodes and (multiple) child nodes. A parent node can be an IAB node or an IAB donor, and child nodes are IAB nodes. IAB nodes support the gNB-DU function as defined in TS38.401v.15.5.0, terminating the NR access interface to the UE and the next-hop IAB node at the IAB donor, as defined in TS 38.401, and terminating the F1 protocol to the gNB-CU function. The gNB-DU function at the IAB node is also referred to as IAB-DU. The IAB node routes IAB-DU IP services on the radio backhaul via the BAP sublayer. In addition to the gNB-DU function, IAB nodes also support a subset of UE functions known as IAB Mobile Terminals (IAB-MT). This functionality includes, for example, physical layer, layer 2, RRC, and non-access stratum (NAS) functions to connect to another IAB node or the gNB-DU of the IAB donor, to the gNB-CU of the IAB donor, and to the core network (CN). IAB-MT can correspond to IAB-UE functions.

[0006] All IAB nodes connected to the IAB donor via one or more hops form a directed acyclic graph (DAG) topology, with the IAB donor at the root. According to this DAG topology, neighboring nodes on the interfaces of an IAB-DU are called child nodes, and neighboring nodes on the interfaces of an IAB-MT are called parent nodes. The direction towards a child node is called downstream, and the direction towards a parent node is called upstream. The IAB donor performs centralized resource, topology, and routing management for the DAG topology.

[0007] For backhaul transmissions within the IAB, IAB nodes route IP services of the IAB-DU over the wireless backhaul via the BAP sublayer. The BAP sublayer is specified in TS 38.340v.16.1.0. Downstream, the BAP sublayer encapsulates higher-layer packets from the IAB donor DU and decapsulates the packets at the destination IAB node. Upstream, the BAP layer encapsulates higher-layer packets at the IAB node and decapsulates the packets at the IAB donor DU. IAB-specific transports between the IAB donor CU and the IAB donor DU are specified in TS 38.401. The BAP sublayer routes packets based on the BAP route ID in the BAP header. When a packet arrives from a higher layer, the communication stack adds a BAP header to the packet and removes the BAP header when the packet has reached its destination node. The IAB donor CU selects and configures the BAP route ID for the packet. A BAP route ID has a BAP address and a BAP path ID. The BAP address indicates the destination node of the packet at the BAP sublayer, and the BAP path ID indicates the route path the packet should follow to that destination. To support routing, each IAB node and IAB donor DU has its own designated BAP address.

[0008] Several types of UE associations exist within NG-RAN nodes. The NG-RAN node UE context stores all the information required by the UE, as well as the association between the UE and the logical NG and the Xn connection used for NG / XnAP UE association messages. The NG-RAN node UE context is a block of information in the NG-RAN node associated with a UE when the UE is in the CM_CONNECTED state. This block contains the information required to maintain NG-RAN service for the active UE. The NG-RAN node establishes the NG-RAN node UE context after the handover resource allocation is completed during handover preparation, when the UE completes its transition to the RRC connected state. In the latter case, at least UE state information, security information, UE capability information, and the identifier of the logical NG connection associated with the UE are included in the NG-RAN node UE context. For dual connectivity, S-NG-RAN establishes the NG-RAN node UE context after completing the S-NG-RAN node add preparation procedure. If the UE context establishment or modification procedure involves the establishment of a radio bearer, UE capabilities are provided to the receiving node as part of the UE context establishment or modification procedure.

[0009] A bearer context is an information block within a gNB-CU-UP node associated with a UE. The bearer context is used for communication on the E1 interface. It can include information about data radio bearers, PDU sessions, and QoS flows associated with the UE. The information block contains information necessary to maintain user plane services for the UE.

[0010] Furthermore, the UE-associated logical NG / Xn / F1 / E1 connections NGAP, XnAP, F1AP, and E1AP provide means for exchanging UE-associated control plane messages on the NG-C, Xn-C, and F1-C interfaces, respectively. The UE-associated logical connection is established during the first NGAP / XnAP / F1AP message exchange between the NG / Xn / F1 peer nodes. The network maintains the connection as long as the nodes need to exchange UE-associated NG / XnAP / F1AP messages through the NG / Xn / F1 interface. The UE-associated logical NG connection uses the identifiers AMF_UE_NGAP_ID and RAN_UE_NGAP_ID. The UE-associated logical Xn connection uses the identifiers old NG-RAN node UE XnAPID and new NG-RAN node UE XnAPID, or M-NG-RAN node UE XnAPID and S-NG-RAN node UE XnAPID. The UE-associated logical F1 connection uses the identifiers gNB-CU UE F1AP ID and gNB-DU UE F1AP ID. When a node (AMF or gNB) receives a UE-associated NGAP / XnAP / F1AP message, the node retrieves the associated UE based on NGAP / XnAP / F1APID.

[0011] In topology adaptation scenarios, IAB nodes may need to migrate (e.g., switch over) from one parent node to another to continue communicating with the RAN. When an IAB node needs to migrate between donors (i.e., from one donor to another), it is unclear how the IAB node and donors should support signaling, management context, and topology modifications. For example, it is unclear how the IAB node should establish appropriate connections (e.g., F1 connections) to multiple IAB donors to perform inter-donor migrations. Attached Figure Description

[0012] Figure 1A This is a block diagram of an example system in which a distributed unit (DU) operating in a radio access network (RAN) is capable of implementing the techniques of this disclosure for connecting to multiple centralized units (CUs) operating in the RAN;

[0013] Figure 1B It is possible Figure 1A A block diagram of an example base station with CU and DU operating in the system;

[0014] Figure 2A and 2B yes Figure 1A The block diagram of the example protocol stack for the UE or IAB-MT to communicate with the base station;

[0015] Figure 3 This is a block diagram of an example system that supports IAB, where the DU of the IAB node establishes connections to multiple CUs.

[0016] Figure 4A This is a block diagram of an example protocol stack for an example system that supports IAB for the user plane;

[0017] Figure 4B This is a block diagram of an example protocol stack for an example system that supports IAB for the control plane;

[0018] Figure 5A This is a message transmission diagram of an example scenario where the DU of an IAB node establishes a first F1 connection with the first CU of the first IAB donor and establishes a second F1 connection with the second CU of the second IAB donor via the first CU.

[0019] Figure 5B In addition to establishing a second F1 connection with the second CU via the first CU and the core network (CN), it also connects with... Figure 5A The message delivery graph is similar to the example scenario in the example scenario;

[0020] Figure 6A Here is a message passing graph for an example scenario, where the DU of the IAB node is released to communicate with... Figure 5A The corresponding first F1 connection and second F1 connection with the first CU and the second CU are established in a similar manner, and after the immediate switch to the second CU is performed, a third F1 connection with the second CU and a fourth F1 connection with the first CU via the second CU are established.

[0021] Figure 6B In addition to establishing a fourth F1 connection with the first CU via the second CU and CN, it is also connected to... Figure 6A The message delivery graph is similar to the example scenario in the example scenario;

[0022] Figure 6C Is with Figure 6A The message passing graph of the example scenario is similar to that of the example scenario, except that instead of establishing a third F1 connection and a fourth F1 connection after the immediate handover to the second CU, the DU retains the first F1 connection and the second F1 connection and physically reroutes the first F1 connection between the DU and the second CU, and reroutes the second F1 connection between the DU and the first CU via the second CU.

[0023] Figure 6D Besides the rerouting of the second F1 connection via the second CU and CN between the DU and the first CU, it is also related to... Figure 6C The message delivery graph is similar to the example scenario in the example scenario;

[0024] Figure 7A Besides the DU establishing a third F1 connection, a fourth F1 connection, and a third F1 connection after executing the conditional switch of the second CU, this is in addition to... Figure 6AThe message delivery graph is similar to the example scenario in the example scenario;

[0025] Figure 7B In addition to establishing a fourth F1 connection with the first CU via the second CU and CN, it is also connected to... Figure 7A The message delivery graph is similar to the example scenario in the example scenario;

[0026] Figure 7C Besides DU rerouting the first F1 connection and the second F1 connection after performing a conditional switch to the second CU, it is also related to... Figure 6C The message delivery graph is similar to the example scenario in the example scenario;

[0027] Figure 7D Besides the rerouting of the second F1 connection via the second CU and CN between the DU and the first CU, it is also related to... Figure 7C The message delivery graph is similar to the example scenario in the example scenario;

[0028] Figure 8A Besides the fact that the first CU determines to switch the UE to the second CU before switching the DU to the second CU, it is related to... Figure 6A The message delivery graph is similar to the example scenario in the example scenario;

[0029] Figure 8B Besides involving CN during UE handover, it is related to Figure 8A The message delivery graph is similar to the example scenario in the example scenario;

[0030] Figure 9 It is possible Figure 1A , Figure 1B or Figure 3 A flowchart of an example method implemented in the DU, including sending an interface message including an identifier to the corresponding first CU and second CU;

[0031] Figure 10 It is possible Figure 1A , Figure 1B or Figure 3 A flowchart of an example method implemented in the DU, including sending interface messages to the corresponding first CU and second CU on the control plane and user plane;

[0032] Figure 11 It is possible Figure 1A , Figure 1B or Figure 3 A flowchart of an example method implemented in the DU, including sending interface messages containing corresponding packets to the corresponding first CU and second CU;

[0033] Figure 12 It is possible Figure 1A , Figure 1B or Figure 3A flowchart of an example method implemented in the first CU, including sending interface messages to the second CU to establish a connection between the DU and the second CU via the first CU;

[0034] Figure 13 It is possible Figure 1A , Figure 1B or Figure 3 A flowchart of an example method implemented in the first CU, including receiving an interface message containing a corresponding identifier for establishing a corresponding connection to the first CU and the second CU;

[0035] Figure 14 It is possible Figure 1A , Figure 1B or Figure 3 A flowchart of an example method implemented in the first CU, including receiving interface messages for establishing corresponding connections to the first CU and the second CU on the corresponding control plane and user plane;

[0036] Figure 15 It is possible Figure 1A , Figure 1B or Figure 3 The flowchart of an example method implemented in the first CU, including determining whether to process interface messages received from the DU;

[0037] Figure 16 It is possible Figure 1A , Figure 1B or Figure 3 A flowchart of an example method implemented in the second CU, including sending interface messages via the first CU or directly to the DU;

[0038] Figure 17 It is possible Figure 1A , Figure 1B or Figure 3 A flowchart of an example method implemented in the second CU, including sending a second interface message to the DU in response to receiving a first interface message from the first CU;

[0039] Figure 18 It is possible Figure 1A , Figure 1B or Figure 3 The flowchart shows an example method implemented in the DU that includes sending interface messages to the first CU and the second CU to establish corresponding connections.

[0040] Figure 19 It is possible Figure 1A , Figure 1B or Figure 3 A flowchart of an example method implemented in the first CU, the example method including: determining an interface message for the second CU to establish a connection between the DU and the second CU via the first CU; and

[0041] Figure 20 It is possible Figure 1A , Figure 1B or Figure 3 A flowchart of an example method implemented in the second CU, including sending interface messages to the DU via the first CU to establish a connection between the DU and the second CU via the first CU. Detailed Implementation

[0042] Typically, using the techniques disclosed herein, a distributed unit (DU) can establish corresponding connections with multiple centralized units (CUs). Specifically, a DU can establish a first connection with a first CU and, via the first CU, establish a second connection with a second CU. In some embodiments, the DU of an IAB node can establish a first connection with a first CU of a source IAB donor and, via the first CU, establish a second connection with a second CU of a target IAB donor. After establishing the corresponding connections, the IAB node can perform donor migration from the source donor to the target donor.

[0043] An example embodiment of these technologies is a method implemented in a DU operating in a RAN for establishing a connection with a CU operating in the RAN. The method can be executed by processing hardware and includes: sending a first interface message to a first CU to establish a first connection between the DU and the first CU; and sending a second interface message via the first CU to a second CU to establish a second connection between the DU and the second CU, thereby maintaining both the first and second connections simultaneously. Another example embodiment of these technologies is a DU including processing hardware configured to perform the above-described method.

[0044] Another example embodiment of these technologies is a method for establishing a connection between a CU operating in a RAN and a DU operating in the RAN. The method can be executed by processing hardware and includes: receiving a first interface message from the DU to establish a first connection between the DU and the CU; receiving a second interface message from the DU to establish a second connection between the DU and a second CU via the CU, to simultaneously maintain the first and second connections; determining that the second interface message is for the second CU; and sending the second interface message to the second CU to establish the second connection. Yet another embodiment of these technologies is a CU including processing hardware configured to perform the methods described above.

[0045] Another example embodiment of these technologies is a method for establishing a connection with a DU in a CU, the CU and the DU operating in a RAN. The method can be executed by processing hardware and includes: receiving an uplink interface message from the DU via a second CU; and sending a downlink interface message to the DU via the second CU to establish a connection between the DU and the CU via the second CU. Yet another embodiment of these technologies is a CU including processing hardware configured to perform the above-described method.

[0046] Figure 1A An example wireless communication system 100 in which communication devices are capable of implementing these technologies is depicted. The wireless communication system 100 includes UE 102A, UE 102B, CN 110, and RAN 105, where RAN 105 includes any one or more of IAB node 104, IAB node 106A, IAB node 106B, IAB donor 108A, IAB donor 108B, and IAB donor 108C. UE 102A or UE 102B is initially connected to IAB donor 108A via IAB node 104. In some implementations and scenarios, IAB node 104 may initially be directly connected to IAB donor 108A, for example, on an F1 connection.

[0047] In other implementations and scenarios, IAB node 104 can connect to IAB donor 108A via one or more intermediate IAB nodes (e.g., IAB node 106A). In such implementations and scenarios, IAB node 104 can establish an F1 connection with IAB donor 108A via one or more intermediate IAB nodes. Therefore, UE 102A or UE 102B connects to IAB donor 108A via IAB node 104 and one or more intermediate IAB nodes. Throughout this disclosure, the description of UE 102 (e.g., UE 102A and / or 102B) being connected to IAB donor 108 (e.g., IAB donor 108A, IAB donor 108B, or IAB donor 108C) via IAB node 104 can mean that UE 102 is connected to the IAB donor via IAB node 104, via IAB node 104 and IAB node 106 (e.g., IAB node 106A, IAB node 106B), or via IAB node 104, IAB node 106, and (multiple) other IAB nodes. Similarly, the description of IAB node 104 being connected to IAB donor 108 can mean that IAB node 104 is connected to IAB donor 108 directly, via IAB donor 106, or via IAB donor 106 and (multiple) other IAB nodes.

[0048] like Figure 1AAs shown, IAB nodes 104, 106A, and 106B operate cells 124, 126A, and 126B respectively, while IAB donors 108A, 108B, and 108C operate cells 128A, 128B, and 128C respectively. Cells 124, 126A, 126B, 128A, 128B, and 128C can partially overlap, allowing IAB node 104 or UE 102 to switch to IAB donor 108B or 108C, or to perform RRC connection reconstruction with IAB donor 108B or 108C.

[0049] In some scenarios, due to load balancing, service robustness, or other reasons, IAB donor 108A can configure UE 102 (e.g., UE 102A and / or UE 102B) to switch from IAB donor 108A to IAB donor 108B while maintaining the connection between UE 102 and IAB node 104. For example, IAB donor 108A can send a handover command message to UE 102 via IAB node 104 to switch UE 102 to IAB donor 108B. In response to the handover command message, the UE switches to IAB donor 108B while still maintaining the connection with IAB node 104. The inter-donor handover can be an immediate handover or a conditional handover.

[0050] In other scenarios, due to load balancing, service robustness, or based on (e.g., indicating that cell 128B is more suitable for UE 102 than cell 128A, that the signal strength / quality of cell 128B is better than a first threshold, or that the signal strength / quality of cell 128A is worse than a second threshold), IAB donor 108A can configure IAB node 104 to switch from IAB donor 108A to IAB donor 108B. For example, IAB donor 108A can send a handover command message to IAB node 104 directly, via IAB node 106, or via IAB node 106 and (multiple) other downstream IAB nodes to switch IAB node 104 to IAB donor 108B. In response to the handover command message, IAB node 104 switches to IAB donor 108B. In some embodiments, if the handover command message configures IAB node 104 to perform a handover to cell 128B, then IAB node 104 is able to perform random access with IAB donor 108B on cell 128B. In other embodiments, if the handover command message configures IAB node 104 to perform a handover to cell 126B, then IAB node 104 is able to perform random access on cell 126B, where IAB donor 106B is connected to IAB donor 108B. In some embodiments, before handing over to IAB donor 108B or performing random access on cell 128B or 126B, IAB node 104 disconnects from IAB donor 108A or cell 128A. In other embodiments, IAB node 104 maintains a connection with IAB donor 108A on cell 128A while and / or after performing a handover with IAB donor 108B or performing random access on cell 128B or 126B.

[0051] In various configurations of the wireless communication system 100, the UE 102 can communicate with the IAB node 104 via a first radio access technology (RAT) such as EUTRA or NR, and the IAB node 104 can communicate with the IAB donor (e.g., IAB donor 108A, 108B, or 108C) or IAB node 106A via a second RAT such as EUTRA or NR. The first RAT and the second RAT can be the same or different.

[0052] In scenarios where UE 102 and / or IAB node 104 switch from IAB donor 108A to IAB donor 108B, IAB donors 108A and 108B operate as the source base station (S-BS) and target base station (T-BS), respectively. Similarly, in other cases where IAB node 104 detects a fault in the connection with IAB donor 108A and performs an RRC connection re-establishment procedure with IAB donor 108B, IAB donors 108A and 108B operate as the S-BS and T-BS, respectively.

[0053] IAB donors 108A, 108B, and 108C can connect to the same CN 110, which can be an Evolved Packet Core (EPC) 111 or a Generation 5 Core (5GC) 160. Each of IAB donors 108A, 108B, or 108C can be implemented as an eNB supporting an S1 interface for communication with the EPC 111, an ng-eNB supporting an NG interface for communication with the 5GC 160, or a gNB supporting both an NR radio interface and an NG interface for communication with the 5GC 160. For direct message exchange during the scenarios discussed below, IAB donors 108A, 108B, and 108C can support X2 or Xn interfaces (e.g., as...). Figure 1A As shown, between donors 108A and 108B of IAB, between donors 108A and 108C of IAB, and between donors 108B and 108C of IAB).

[0054] Among other components, EPC 111 may include a Serving Gateway (SGW) 112, a Mobility Management Entity (MME) 114, and a Packet Data Network Gateway (PGW) 116. SGW 112 is typically configured to transmit user plane packets related to audio calls, video calls, Internet services, etc., and MME 114 is configured to manage authentication, registration, paging, and other related functions. PGW 116 provides connectivity from UE 102 to one or more external packet data networks (e.g., Internet networks and / or Internet Protocol (IP) Multimedia Subsystem (IMS) networks). 5GC 160 includes a User Plane Function (UPF) 162 and Access and Mobility Management (AMF) 164 and / or Session Management Function (SMF) 166. Generally, UPF 162 is configured to transmit user plane packets related to audio calls, video calls, Internet services, etc., AMF 164 is configured to manage authentication, registration, paging, and other related functions, and SMF 166 is configured to manage PDU sessions.

[0055] Typically, the wireless communication network 100 can include any suitable number of base stations supporting NR cells and / or EUTRA cells. More specifically, the EPC 111 or 5GC 160 can connect to any suitable number of base stations supporting NR cells and / or EUTRA cells. Although the examples below specifically relate to particular CN types (EPC, 5GC) and RAT types (5G NR and EUTRA), generally, the techniques disclosed herein can also be applied to other suitable radio access and / or core network technologies, such as sixth-generation (6G) radio access and / or 6G core networks or 5G NR-6G DC.

[0056] Continue to refer to Figure 1A IAB node 104 includes processing hardware 130, which may include one or more general-purpose processors (e.g., central processing unit (CPU)) and computer-readable memory storing machine-readable instructions that can be executed on the general-purpose processors and / or special-purpose processing units. Figure 1A In an example implementation, the processing hardware 130 includes an IAB mobile terminal (MT) 132 that uses procedures and behaviors specified for the UE 102 to terminate a Uu interface to a parent node (e.g., IAB donor 108 or IAB node 106). The IAB-MT 132 is configured to manage or control the connection with the IAB donor 108. In some implementations, the IAB-MT 132 may include a UE configuration controller similar to the UE configuration controller 152 of the UE 102 to manage or control RRC configuration and / or RRC procedures, for example, for communicating with the IAB donor 108 on the Uu interface. The processing hardware 130 also includes a DU controller 134 configured to manage or control the configuration techniques of this disclosure. For example, the DU controller 134 may be configured to provide and support lower-level configuration of RRC messages for the IAB-MT of the UE 102 or a descendant IAB node. In another example, DU controller 134 is configured to control or manage the IAB node RRC rebuild and reconfiguration process with IAB donor 108 (e.g., including context management processes or F1 Application Protocol (F1AP) processes). IAB nodes 106A, 106B are capable of having processing hardware similar to that of IAB node 104.

[0057] IAB donor 108A includes processing hardware 140, which may include one or more general-purpose processors (e.g., CPUs) and a computer-readable memory storing machine-readable instructions that can be executed on the general-purpose processors and / or special-purpose processing units(s). Figure 1A In an example implementation, the processing hardware 140 includes a base station configuration controller 142 configured to manage or control the RRC procedures and RRC configurations of the (multiple) IAB-MTs used for connection between the UE 102 and (multiple) IAB nodes (e.g., IAB nodes 104, 106A, or 106B). For example, the base station configuration controller 142 may be configured to support RRC message transmission associated with handover procedures and / or RRC connection re-establishment procedures. The processing hardware 140 also includes a CU controller 144 configured to manage or control the UE context management procedures or F1AP procedures with the IAB nodes (e.g., IAB nodes 104, 106A, or 106B). IAB donors 108B or 108C may have processing hardware similar to that of IAB donor 108A.

[0058] UE 102 includes processing hardware 150, which may include one or more general-purpose processors (e.g., CPUs) and computer-readable memory storing machine-readable instructions that can be executed on the general-purpose processors and / or dedicated processing units. Figure 1A In an example implementation, the processing hardware 150 includes a UE configuration controller 152 configured to manage or control RRC procedures and RRC configuration. For example, the configuration controller 152 may be configured to support the transmission of RRC messages associated with UE handover procedures and UE RRC rebuild and reconfiguration procedures, according to any of the implementations discussed below.

[0059] Figure 1B An example distributed implementation is depicted for any one or more of IAB nodes 104, 106A, or 106B, or IAB donors 108A, 108B, or 108C. In this implementation, any one of IAB nodes 104, 106A, or 106B, or IAB donors 108A, 108B, or 108C includes a centralized unit (CU) 172 and one or more distributed units (DUs) 174. CU 172 includes processing hardware, such as one or more general-purpose processors (e.g., CPUs), and a computer-readable memory storing machine-readable instructions executable on the general-purpose processor(s) and / or dedicated processing units. For example, CU 172 can include... Figure 1A The processing hardware is 130 or 140.

[0060] Each of DU 174 also includes processing hardware, which may include one or more general-purpose processors (e.g., CPUs) and computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors and / or dedicated processing units. For example, the processing hardware may include a Media Access Control (MAC) controller configured to manage or control one or more MAC operations or procedures (e.g., random access procedures), and a Radio Link Control (RLC) controller configured to manage or control one or more RLC operations or procedures when the base station (e.g., base station 106A) operates as a primary node (MN) or secondary node (SN). The processing hardware may also include a physical layer controller configured to manage or control one or more physical layer operations or procedures.

[0061] In some implementations, CU 172 may include a logical node CU-CP 171 that hosts the control plane (CP) portion of the Packet Data Convergence Protocol (PDCP) and / or the Radio Resource Control (RRC) protocol of CU 172. CU 172 may also include a logical node CU-UP 173 that hosts the user plane (UP) portion of the PDCP and / or the Service Data Adaptation Protocol (SDAP) protocol of CU 172.

[0062] CU-CP 171 can connect to multiple CU-UP 173s via the E1 interface. CU-CP 171 selects the appropriate CU-UP 173 for UE 102 for the requested service. In some implementations, a single CU-UP 173 can connect to multiple CU-CP 171s via the E1 interface. CU-CP 171 can connect to one or more DU 174s via the F1-C interface. CU-UP 173s can connect to one or more DU 174s via the F1-U interface under the control of the same CU-CP 171. In some implementations, a DU 174 can connect to multiple CU-UP 173s under the control of the same CU-CP 171. In such implementations, the connection between CU-UP 173s and DU 174s is established by CU-CP 171 using bearer context management functions.

[0063] Next, Figure 2A An example protocol stack 200 is illustrated in a simplified manner, according to which UE 102 can communicate with any of IAB donors 108A, 108B, or 108C. Each of IAB donors 108A, 108B, or 108C can be an eNB / ng-eNB or gNB. Each of IAB nodes 104, 106A, or 106B can contain the functionality of UE 102. Thus, each of IAB nodes 104, 106A, or 106B can also use radio protocol stack 200 to communicate with any of IAB donors 108A, 108B, or 108C.

[0064] In the example protocol stack 200, the EUTRA physical layer (PHY) 202A provides a transport channel to the EUTRA MAC sublayer 204A, which in turn provides a logical channel to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A then provides an RLC channel to the EUTRA PDCP sublayer 208, and in some cases, to the NR PDCP sublayer 210. Similarly, the NR PHY 202B provides a transport channel to the NR MAC sublayer 204B, which in turn provides a logical channel to the NR RLC sublayer 206B. The NR RLC sublayer 206B then provides data transmission services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 can then provide data transmission services to the Ethernet protocol layer (…). Figure 2A (not shown in the image), Internet Protocol (IP) layer ( Figure 2A (not shown in the image) Service Data Adaptation Protocol (SDAP) 212 and / or Radio Resource Control (RRC) sublayer ( Figure 2A(Not shown in the image) provides data transmission services. In some implementations, UE 102 supports, for example... Figure 2A The EUTRA and NR stacks shown are designed to support handover between EUTRA and NR base stations and / or support DC on the EUTRA and NR interfaces. Additionally, as... Figure 2A As shown, UE 102 can support the layering of NRPDCP210 on EUTRARLC 206A and SDAP sublayer 212 on NR PDCP sublayer 210.

[0065] EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 (e.g., from an Internet Protocol (IP) layer that is directly or indirectly layered on PDCP layer 208 or 210) receive packets that can be referred to as Service Data Units (SDUs), and (e.g., to RLC layer 206A or 206B) output packets that can be referred to as Protocol Data Units (PDUs). Except where the difference between SDU and PDU is relevant, for simplicity, this disclosure refers to both SDU and PDU as "packets".

[0066] On the control plane, EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 can provide SRBs to exchange, for example, RRC messages or NAS messages. On the user plane, EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 can provide DRBs to support data exchange. The data exchanged on NR PDCP sublayer 210 can be SDAP PDUs, Internet Protocol (IP) packets, or Ethernet packets.

[0067] In one implementation, IAB node 104 typically hosts two NR functions—an IAB-MT for maintaining radio backhaul connections to any of the IAB donors 108A, 108B, or 108C and any intermediate upstream IAB node (e.g., IAB node 106A), and an IAB-DU 174 for providing access connectivity to the downstream MT of UE 102 or any IAB node via the Uu interface. The DU 174 at IAB node 104 can connect via the F1 interface to a CU 172 hosted by any of the IAB donors 108A, 108B, or 108C. Therefore, the protocol stack can be functionally split, such as... Figure 2BThe protocol stack 250 is shown in the diagram. CU 172 at any IAB donor (108A, 108B, or 108C) maintains all control and higher-layer functions (e.g., RRC 214, SDAP 212, NR PDCP 210), while lower-layer operations (e.g., NR RLC 206B, NR MAC 204B, and NR PHY 202B) are delegated to DU 174 at any IAB node (104, 106A, or 106B). To support connectivity to the 5GC, NR PDCP 210 provides SRBs to RRC 214, and NR PDCP 210 provides DRBs to SDAP 212 and SRBs to RRC 214.

[0068] Next, Figure 3 An example wireless communication system 300 including CN 110, RAN 105, and UE 102 is illustrated. Typically, RAN 105 includes DU 174C, which has a connection established with CU 172A and another (second) connection established with another (second) CU 172B. In some embodiments, these connections may be F1 connections or F1 interfaces conforming to the F1 Application Protocol (F1AP). In some embodiments, DU 174C can be an IAB-DU of IAB node 104, CU 172A can be an IAB donor CU of IAB donor 108A, and CU 172B can be an IAB donor CU of IAB donor 108B. IAB donor 108A includes IAB donor CU 172A and one or more IAB donor DU 174A. IAB donor 108B includes IAB donor CU 172B and one or more IAB donor DU 174B.

[0069] UE 102 is wirelessly connected to IAB node 104 via the NR Uu interface. Similar to how UE 102 connects to IAB node 104 via the NR Uu interface, IAB node 104 (e.g., via IAB-MT 132) is also wirelessly connected to IAB donor 108A (e.g., via IAB donor DU 174A) via the NR Uu interface. IAB-DU 174C of IAB node 104 (e.g., via DU controller 134) exchanges F1-C and / or F1-U services with IAB donor 108A (e.g., via IAB donor DU 174A and / or IAB donor CU 172A) on (multiple) connections (e.g., SRB and / or DRB) via the NR Uu interface and / or F1 interface. In some implementations, IAB-DU 174C of IAB node 104 (e.g., via the same DU controller 134 or another controller) exchanges F1-C and / or F1-U services with IAB donor 108B (e.g., via IAB donor CU 172A) via IAB donor 108A (e.g., via IAB donor CU 172B). Although not shown, in some implementations, IAB-DU 174C of IAB node 104 can exchange F1-C and / or F1-U services with IAB donor 108B via IAB donor 108A and via CN 110.

[0070] Although not shown, in some embodiments, IAB donors CU 172A and 172B can both be divided into IAB donor CU-CP and IAB donor CU-UP.

[0071] In some implementations, IAB node 104, as a downstream IAB node 104, can be via Figure 3One or more intermediate or upstream IAB nodes (e.g., IAB node 106A) not shown in Figure A exchange F1-C and / or F1-U services with IAB donor 108A. In some embodiments, IAB node 104 can exchange F1-C services with IAB donor CU 172A via IAB donor DU 174A and zero or more intermediate IAB nodes (e.g., IAB node 106A). IAB node 104 can exchange F1-U services with IAB donor DU 174A via zero or more intermediate IAB nodes (e.g., IAB node 106A). In some embodiments, F1-C and F1-U services between IAB node 104 and IAB donor CU 172A are backhauled via IAB donor DU 174A and optional(multiple) intermediate IAB nodes(s). In some implementations, IAB node 104 can wirelessly connect to an upstream IAB node (e.g., IAB node 106A), which in turn can connect to IAB donor 108A or another upstream IAB node. Figure 1A and Figure 3 (Not shown in the image). Generally, upstream IAB nodes provide wireless backhaul to downstream IAB nodes via the NR Uu interface.

[0072] IAB nodes (e.g., IAB node 104, IAB node 106) are typically connected to IAB donor DU 174A and provide access connectivity to UE 102. As discussed above, IAB nodes (e.g., IAB node 104) are typically capable of supporting network functions of the NR Uu interface (e.g., via IAB-MT 132) for maintaining radio backhaul connections to IAB donor DU 174A and any intermediate upstream IAB nodes (e.g., IAB node 106A). IAB-MT 132 of IAB node 104 can include, for example, physical layer, layer 2, RRC, and NAS functions to connect to IAB-DU of IAB node 106, IAB donor CU of IAB donor 108, and CN 110. Operation of IAB-MT 132 is compliant with TS23.501. IAB node 104 is also typically able to support a subset of UE functions via the NR Uu interface (e.g., via IAB-DU 174C) to provide access connectivity to UE 102 or any downstream IAB node via IAB-MT.

[0073] IAB donor DU 174 (i.e., IAB donor DU 174A and / or IAB donor DU 174B) can host the IAB BAP sublayer (e.g., as defined in the TS 38.340 Backhaul Adaptation Protocol (BAP)) to provide wireless backhaul to IAB nodes 104 and / or 106, for example, according to TS 38.300. IP traffic from IAB-DU 174C can be routed over the wireless backhaul via the BAP sublayer. Downstream, higher-layer packets are encapsulated by the BAP sublayer at IAB donor DU 174 and decapsulated at the destination IAB node 104. Upstream, higher-layer packets are encapsulated at IAB node 104 and decapsulated at IAB donor DU 174. IAB-specific transmissions between IAB donor CU 172 and IAB donor DU 174 can occur according to TS 38.401. At the BAP sublayer, packets are routed based on the BAP route ID carried in the BAP header. A BAP header is added to the packet as it arrives from a higher layer, and it is stripped when the packet has reached its destination node. The selection of the packet's BAP route ID is configured by IAB donor CU 172 (i.e., IAB donor CU 172A and / or IAB donor CU 172B). The BAP route ID has a BAP address and a BAP path ID, where the BAP address indicates the packet's destination node at the BAP sublayer, and the BAP path ID indicates the routing path the packet should follow to that destination. For routing, each IAB node 104 and / or 106, as well as IAB donor DU 174, is also configured with a designated BAP address.

[0074] Figure 4A and 4B Examples of protocol stacks for RAN 105 supporting IAB for the user plane and control plane are shown respectively. As described above, in some implementations, the IAB donor CU 172 can be divided into IAB donor CU-CP and IAB donor CU-UP. Figure 4A The protocol stack for F1-U between the IAB-DU 174C and the IAB donor CU-UP is shown, and Figure 4B The protocol stack for F1-C between the IAB-DU 174C and the IAB donor CU-CP is shown. In these figures, F1-U and F1-C services are carried on two backhaul hops.

[0075] Next, Figures 5-8 illustrate several example scenarios in which a DU establishes a connection with a first CU (e.g., a first F1 connection) and another connection with a second CU (e.g., a second F2 connection). In the following description, unless otherwise stated, "IAB node 104" refers to the DU included in IAB node 104, "IAB donor 108A" refers to the CU included in IAB donor 108A (i.e., the "first CU"), and "IAB donor 108B" refers to the CU included in IAB donor 108B (i.e., the "second CU"). Although the examples below specifically relate to the DU, first CU, and second CU included in IAB-supporting nodes (i.e., IAB node 104, IAB donor 108A, and IAB donor 108B, respectively), the techniques of this disclosure can generally be applied to other nodes in the RAN.

[0076] In the following description, "IAB node 104" and "UE 102" can refer to one or more IAB nodes and UEs 102A and 102B, respectively. In the case of multiple UEs, unless otherwise stated, the procedure performed by UE 102 can mean the execution of a procedure in each of the multiple UEs (e.g., UE 102A, UE 102B). The description of UE 102 can be applied to the IAB-MT of IAB node 104. Similarly, the procedure performed by IAB donor 108A and IAB donor 108B can be applied to each of the multiple UEs (e.g., UE 102A, UE 102B).

[0077] Additionally, although the examples below do not show any intermediate IAB nodes between IAB node 104 and IAB donor 108A or between IAB node 104 and IAB donor 108B, the techniques disclosed herein are generally applicable to examples where there are (multiple) intermediate IAB nodes between IAB node 104 and IAB donor 108A or IAB donor 108B.

[0078] First refer to Figure 5A In scenario 500A, IAB node 104 initially executes F1 connection establishment procedure 550 to establish an F1 connection with IAB donor 108A.

[0079] To initiate the F1 connection establishment procedure 550, IAB node 104 performs the IAB-MT establishment procedure 502 with IAB donor 108A and CN 110. In the IAB-MT establishment procedure 502, IAB node 104 (e.g., IAB-MT 132) connects to IAB donor 108A and CN 110 in the same manner as UE 102. In some implementations, IAB node 104 connects to IAB donor 108A (e.g., IAB donor CU 172A) by performing an RRC connection establishment procedure, several context management procedures, and / or several other suitable RRC procedures (e.g., security activation procedure, RRC reconfiguration procedure, and / or UE capability delivery procedure) with IAB donor 108A. IAB node 104 can select IAB donor 108A for access based on an over-the-air indication (e.g., sent in the SIB) from IAB donor 108A (e.g., IAB donor DU). In some implementations, IAB node 104 connects to CN 110 by performing NAS procedures (e.g., registration, authentication, identification, security mode control, and / or PDU session establishment procedures) with CN 110.

[0080] Following the execution of IAB-MT establishment procedure 502, in some embodiments, IAB node 104 can perform a 504 backhaul (BH) RLC channel establishment procedure with IAB donor 108A to establish a backhaul RLC channel for carrying CP services (e.g., F1-C services / non-F1 services) to and from IAB node 104. In some embodiments of the BH RLC channel establishment procedure, IAB donor 108A and / or IAB node 104 can establish a default BH RLC channel and optionally establish (multiple) additional (non-default) BH RLC channels to carry non-UP services (e.g., CP services) to and from IAB node 104. In implementations where there are multiple intermediate IAB nodes (e.g., IAB node 106A) between IAB node 104 and IAB donor 108A, IAB donor 108A and / or IAB node 104 can establish a new BH RLC channel or modify an existing BH RLC channel between IAB node 106A and IAB donor 108A (e.g., IAB donor DU 174A). In some implementations of the BH RLC channel establishment process, IAB donor 108A (e.g., IAB donor CU 172A) can configure the BAP address of IAB node 104 and / or a default BAP route ID for the upstream direction.

[0081] After executing the IAB-MT establishment procedure 502 and the optional BH RLC channel establishment procedure 504, in some embodiments, IAB node 104 can perform a route update procedure 506 with IAB donor 108A to update the BAP layer, thereby supporting routing between IAB node 104 and IAB donor 108A. In some embodiments of the route update procedure, IAB donor 108A and / or IAB node 104 can perform one or more procedures on each other, such as multiple F1AP procedures (e.g., BAP mapping configuration procedures) and / or multiple RRC procedures. In some embodiments of the route update procedure, IAB donor CU 172A of IAB donor 108A initiates an F1AP procedure to configure IAB donor DU 174A of IAB donor 108A using a mapping from multiple IP header fields to BAP route IDs associated with IAB node 104. In implementations where there are intermediate IAB nodes (e.g., IAB node 106A) between IAB node 104 and IAB donor 108A, the routing table is updated on (multiple) intermediate IAB nodes and IAB donor DU 174A with routing entries using BAP route IDs. In some implementations of the route update process, IAB node 104 can perform (multiple) RRC procedures with IAB donor 108A (e.g., IAB donor CU 172A) to allocate one or more IP addresses at IAB node 104 by exchanging RRC messages (e.g., IABotherInformation messages, RRCReconfiguration messages). IAB donor CU 172A can obtain (multiple) IP addresses from IAB donor DU 174A in an F1AP message or through other means (e.g., OAM, DHCP).

[0082] In some implementations, IAB node 104 can perform (e.g., establish) a first Transport Network Layer (TNL) Association (TNLA) with IAB donor 108A after executing IAB-MT establishment procedure 502, BH RLC channel establishment procedure 504, and / or route update procedure 506. Specifically, IAB node 104 and IAB donor 108A can establish the first TNLA by associating the first TNL address of IAB node 104 with the second TNL address of IAB donor 108A. In some implementations, the first and second TNL addresses can be IP addresses. Therefore, IAB node 104 and IAB donor 108A can transmit F1AP messages (e.g., including F1 establishment requests, F1 establishment responses, and F1AP messages described below) to each other using a TNL protocol (e.g., the F1-C TNL protocol) and the first TNLA (i.e., the first and second TNL addresses). In some implementations, the TNL protocol includes Flow Control Transport Protocol (SCTP) and IP. For example, IAB node 104 can generate a packet including an F1AP message, multiple TNL protocol headers, a first TNL address (i.e., the source address), and a second TNL address (i.e., the destination address), and send the packet to IAB donor 108A. Similarly, IAB donor 108A can generate a packet including an F1AP message, multiple TNL protocol headers, a second TNL address (i.e., the source address), and a first TNL address (i.e., the destination address), and send the packet to IAB node 104.

[0083] After performing the IAB-MT establishment procedure 502, the BH RLC channel establishment procedure 504, the route update procedure 506, and / or the TNL association with the IAB donor 108A, in some embodiments, the IAB node 104 can perform a (first) F1 establishment procedure with the IAB donor 108A to establish a (first) F1 connection (e.g., an F1-C connection or an F1-C interface instance) with the IAB donor 108A, enabling the IAB node 104 (e.g., IAB-DU 174C) to exchange F1AP messages with the IAB donor 108A (e.g., IAB donor CU 172A) on the first F1 interface or connection.

[0084] To perform the first F1 establishment process, IAB node 104 sends a 508 First F1 Establishment Request Message to IAB donor 108A to convey information associated with the first F1 connection or interface instance. In some embodiments, IAB node 104 sends the 508 First F1 Establishment Request Message to IAB donor DU 174A, which forwards the First F1 Establishment Request Message to IAB donor CU 172A. In some embodiments, IAB node 104 may include a (first) identifier or information associated with IAB node 104 (e.g., IAB-DU 174C) in the First F1 Establishment Request Message, enabling IAB donor CU 172A to identify IAB node 104 upon receiving the First F1 Establishment Request Message. For example, the first F1 establishment request message may include the (first) identifier of IAB node 104 (e.g., IAB-DU 174C), the (first) transaction identifier (ID), (first) information indicating the (multiple) cells served by IAB node 104, (first) information indicating the RRC version supported by IAB node 104, the (first) transport layer address (TLA) used by IAB node 104, and / or the (first) BAP address used by IAB node 104.

[0085] In response to receiving a first F1 establishment request message, IAB donor 108A can initiate or create a first F1-C interface instance for exchanging F1AP messages with IAB node 104, and subsequently send a 512 first F1 establishment response message to IAB node 104. In some embodiments, IAB donor CU 172A sends a first F1 establishment response message to IAB donor DU 174A, which in turn sends a 512 first F1 establishment response message to IAB node 104. In some embodiments, IAB donor 108A can include a first transaction identifier associated with the first F1 connection in the first F1 establishment response message. In some implementations, IAB donor 108A (e.g., IAB donor CU 172A) can include a (first) list of cells(multiple) to be activated by IAB node 104 in the first F1 establishment response message, such that when IAB node 104 receives the first F1 establishment response message, if the (multiple) cells(multiple) are not active for other different reasons, IAB node 104 activates the (multiple) cells(multiple) in the first list (IAB node 104 can deactivate any active cells not included in the first list).

[0086] In some implementations, upon receiving a first F1 establishment request message or in response to sending a first F1 establishment response message, the IAB donor CU 172A may perform a 510NG establishment procedure and / or a gNB configuration procedure with CN 110 to establish or modify an NG connection with CN 110 in light of the established first F1 connection.

[0087] As a result of completing the first F1 establishment process with IAB donor 108A, IAB node 104 (e.g., IAB-DU174C) establishes a first F1 connection (i.e., F1-C interface) with IAB donor 108A (e.g., IAB donor CU 172A). Therefore, IAB node 104 is able to exchange F1AP messages with IAB donor 108A over the first F1 connection. In some embodiments, IAB node 104 is able to send an F1AP message (e.g., gNB-DU configuration update message) to IAB donor 108A that includes a list of active cells (i.e., serving cells) and / or a list of inactive cells (i.e., out-of-service cells). In other implementations, IAB donor 108A (e.g., IAB donor CU 172A) can send an F1AP message (e.g., a gNB-CU configuration update message) to IAB node 104, including a first list of cells(s) to be activated by IAB node 104, such that when IAB node 104 receives the F1AP message, if the cells(s) are not active for other reasons, IAB node 104 activates the cells(s) in the first list (IAB node 104 can deactivate any active cells not included in the first list). IAB node 104 can also send an F1AP response message (e.g., a gNB-CU configuration update acknowledgment message) back to IAB donor 108A in response to receiving the F1AP message.

[0088] Events 502, 504, 506, 508, 510, 512, and 514 can be collectively referred to as F1 connection establishment process 550.

[0089] During or after the execution of F1 connection establishment procedure 550, IAB node 104 executes another (second) F1 connection establishment procedure 560 to establish another (second) F1 connection with another IAB donor (e.g., IAB donor 108B). IAB node 104 may be triggered to execute the second F1 connection establishment procedure 560 in various ways.

[0090] In some implementations, during or after the F1 connection establishment process 550 and before the handover preparation with IAB donor 108B for switching the descendant IAB node of UE 102 or IAB node 104 to IAB donor 108B (e.g., as... Figures 8A-8B As described herein, IAB donor 108A can send an F1AP message to IAB node 104 (e.g., on an F1 connection established at event 514) to request or instruct the establishment of a second F1 connection with IAB donor 108B, enabling IAB node 104 to determine the establishment of the second F1 connection. IAB donor 108A can include the address (e.g., IP address, transport network layer address) or identifier (e.g., gNB identifier, gNB-CU identifier, TEID, or gNB-CU name) of IAB donor 108B or IAB donor CU 172B in the F1AP message.

[0091] In other embodiments, before, during, or after the F1 connection establishment process 550, the operation and maintenance (O&M) node of the wireless communication system 100 ( Figure 1A (Not shown) can send an O&M configuration message to IAB node 104 to instruct the establishment of a second F1 connection with IAB donor 108B or IAB donor CU 172B, enabling IAB node 104 to determine the establishment of the second F1 connection. The O&M node can include the address (e.g., IP address, TNL address) or identifier (e.g., gNB identifier, gNB-CU identifier, TEID, or gNB-CU name) of IAB donor 108B or IAB donor CU 172B in the O&M configuration message.

[0092] In other implementations, IAB node 104 may be pre-configured (e.g., programmed via a network operator or manufacturer) with an IAB donor list including the address or identifier of IAB donor 108B or IAB donor CU 172B, and includes logic that enables IAB node 104 to initiate a second F1 connection establishment process 560 after performing F1 connection establishment process 550.

[0093] In order to initiate the second F1 connection establishment process 560, IAB node 104 and IAB donor 108A perform another (second) F1 establishment process to establish a (second) F1 connection (e.g., F1-C connection or interface) via IAB donor 108A and IAB donor 108B, so that IAB node 104 (e.g., IAB-DU 174C) can exchange F1AP messages with IAB donor 108B (e.g., IAB donor CU 172B) on the second F1 interface or connection.

[0094] To perform the second F1 establishment process, IAB node 104 sends a 516 second F1 establishment request message to IAB donor 108A to convey information associated with the second F1 connection or interface instance. In some embodiments, IAB node 104 sends the 516 second F1 establishment request message to IAB donor DU 174A, which forwards the second F1 establishment request message to IAB donor CU 172A. In some embodiments, IAB node 104 may include a (second) identifier or information associated with IAB node 104 (e.g., IAB-DU 174C) in the second F1 establishment request message, enabling IAB donor CU 172A to identify IAB node 104 upon receiving the second F1 establishment request message. For example, the second F1 establishment request message may include a (second) identifier of IAB node 104 (e.g., IAB-DU 174C), a (second) transaction identifier associated with the second F1 connection, (second) information indicating the (multiple) cells served by IAB node 104, (second) information indicating the RRC version supported by IAB node 104, a (second) TLA used by IAB node 104, and / or a (second) BAP address used by IAB node 104. In other embodiments, IAB node 104 may include the first identifier or information described above in the second F1 establishment request message. The first identifier or information described above may be the same as or different from the second identifier or information. If the IAB node performs one of the first F1 establishment procedures and the second F1 establishment procedures in an overlapping manner, IAB node 104 sets the first identifier and the second identifier to different values ​​to uniquely identify the first F1 establishment procedure and the second F1 establishment procedure, respectively. Therefore, when IAB node 104 receives an F1 establishment response message from IAB donor 108A, IAB node 104 can determine whether the F1 establishment response message is a first F1 establishment response message or a second F1 establishment response message based on the transaction identifier in the F1 establishment response message. For example, if the transaction identifier is the first transaction identifier, then IAB node 104 determines that the received F1 establishment response message is the first F1 establishment response message. If the transaction identifier is the second transaction identifier, then IAB node 104 determines that the received F1 establishment response message is the second F1 establishment response message.

[0095] In response to receiving a second F1 establishment request message or after receiving a second F1 establishment request message, IAB donor 108A determines that the second F1 establishment request message is addressed to IAB donor 108B, and therefore sends a second F1 establishment request message 518 to IAB donor 108B (e.g., IAB donor CU 172B). IAB donor 108A can determine that the second F1 establishment request message is addressed to IAB donor 108B in various ways. In some embodiments, IAB node 104 can indicate or include the address / identifier (e.g., IP address, transport network layer address, gNB identifier, gNB-CU identifier, TEID, or gNB-CU name) of IAB donor 108B or IAB donor CU 172B in the second F1 establishment request message, such that upon receiving the second F1 establishment request message, IAB donor 108A can determine that the recipient of the second F1 establishment request message is IAB donor 108B based on the address / identifier. In other embodiments, the second F1 establishment request message does not contain the address / identifier of IAB donor 108B. Instead, IAB donor 108A or IAB donor CU 172A can generate a container message including the second F1 establishment request message to instruct that the recipient of the second F1 establishment request message is not IAB donor 108A, and if IAB donor 108B is the only adjacent IAB donor to which IAB donor 108A is connected or can be connected, then IAB donor 108A can determine that IAB donor 108B should be the appropriate recipient of the second F1 establishment request message and specify the container message accordingly. In embodiments where IAB donor 108A requests or instructs IAB node 104 to establish a second F1 connection with IAB donor 108B as described above, IAB donor 108A can determine, based on the container message, that the recipient of the second F1 establishment request message is IAB donor 108B.

[0096] In some implementations, IAB node 104 can perform (e.g., establish) a second TNLA with IAB donor 108B. Specifically, IAB node 104 and IAB donor 108B can establish the second TNLA by associating the third TNL address of IAB node 104 with the fourth TNL address of IAB donor 108B. In some implementations, the third and fourth TNL addresses can be IP addresses. Therefore, IAB node 104 and IAB donor 108B can transmit F1AP messages (e.g., including a second F1 establishment request, a second F1 establishment response, F1AP messages such as UE context request messages 808, 810 and UE context response messages 812, 814, and UL RRC message transmission messages described below) to each other using a TNL protocol (e.g., F1-C TNL protocol) and a second TNLA (i.e., the third and fourth TNL addresses). In some implementations, the first and third TNL addresses can be the same or different. For example, IAB node 104 can generate a (first) packet including an F1AP message (e.g., a second F1 setup request message or a UE context response message 812), (multiple) TNL protocol headers, a third TNL address (i.e., the source address), and a fourth TNL address (i.e., the destination address), and send the packet to IAB donor 108B via IAB donor 108A. Similarly, IAB donor 108B can generate a (second) packet including an F1AP message (e.g., a second F1 setup response message or a UE context request message 808), (multiple) TNL protocol headers, a fourth TNL address (i.e., the source address), and a third TNL address (i.e., the destination address), and send the packet to IAB node 104 via IAB donor 108A. In some implementations, IAB donor 108A may store the fourth TNL address. IAB donor 108A may obtain the fourth TNL address from an O&M node or may have the fourth TNL address pre-configured. Therefore, when IAB donor 108A receives the second packet, IAB donor 108A can determine that the recipient is IAB donor 108B based on the fourth TNL address. In other embodiments, IAB donor 108A can store routing information to route the second packet. IAB donor 108A can obtain routing information from the O&M node or has routing information pre-configured. Therefore, when IAB donor 108A receives the second packet, IAB donor 108A can route the second packet to IAB donor 108B directly or indirectly (e.g., via a router, gateway, or CN 110) based on the routing information.

[0097] like Figure 5AAs shown, IAB donor 108A can send a second F1 establishment request message 518 directly to IAB donor 108B via a BS-to-BS interface (e.g., the Xn interface). The BS-to-BS interface may have already been established before or during the F1 connection establishment process 550. In some embodiments, IAB donor CU 172A can perform a BS-to-BS interface establishment process (e.g., the Xn establishment process) with IAB donor CU 172B before or after the IAB-MT establishment process 502, before IAB node 104 sends the F1 establishment request message 508, before or after the NG establishment process or gNB configuration update process 510, or before IAB node 104 receives the F1 establishment response message.

[0098] To send a second F1 establishment request message 518 directly to IAB donor 108B via, for example, a BS-to-BS interface, IAB donor 108A can generate a first BS-to-BS interface message (e.g., an Xn interface message, an XnAP message, or a GTP-U packet) including the second F1 establishment request message (or a first packet) and send the first BS-to-BS interface message 518 to IAB donor 108B. In another embodiment, IAB donor 108A can generate a first container message including the second F1 establishment request message (or a first packet), such as a first RRC message or a first General Packet Radio System (GPRS) Tunneling Protocol User Plane (GTP) packet, and send the first container message 518 to IAB donor 108B. The first container message can include one or more first identifiers of IAB donor 108B and / or IAB donor 108A, such as a first tunnel endpoint identifier (TEID) (e.g., the TEID of IAB donor 108B and / or the TEID of IAB donor 108A). The first container message can include the fifth TNL address (i.e., the source address) of IAB donor 108A and the sixth TNL address (i.e., the destination address) of IAB donor 108B. The fifth TNL address can be the same as or different from the second TNL address. The sixth TNL address of IAB donor 108B can be the same as or different from the fourth TNL address.

[0099] In response to receiving the second F1 establishment request message 518, IAB donor 108B can initiate or create a second F1-C interface instance for exchanging F1AP messages with IAB node 104, and then send the second F1 establishment response message 522 directly to IAB donor 108A via the BS-to-BS interface. IAB donor 108A then sends the second F1 establishment response message 524 to IAB node 104. In some embodiments, IAB donor CU 172B sends the second F1 establishment response message 522 to IAB donor CU 172A via the BS-to-BS interface, and IAB donor CU 172A then sends the second F1 establishment response message to IAB node 104 via IAB donor DU 174A. In some implementations, to send the 522 second F1 setup response message, IAB donor 108B can generate a second BS-to-BS interface message (e.g., an Xn interface message, an XnAP message, or a GTP-U packet) including the second F1 setup response message (or a second packet) and send the 522 second BS-to-BS interface message to IAB donor 108A. In other implementations, IAB donor 108B can generate a second container message, such as a second RRC message or a second GTP packet, including the second F1 setup response message (or a second packet) and send the second container message to IAB donor 108A. The second container message can include one or more second identifiers of IAB donor 108B and / or IAB donor 108A, such as a second TEID that may be the same as or different from the first TEID described above (e.g., the TEID of IAB donor 108A and / or the TEID of IAB donor 108B). The second container message can include a fifth TNL address (i.e., the source address) and a sixth TNL (i.e., the destination address).

[0100] In some implementations, IAB donor 108B can include a second transaction identifier in the second F1 establishment response message. In some implementations, IAB donor 108B (e.g., IAB donor CU 172B) can include a (second) list of cells(s) to be activated by IAB node 104 in the second F1 establishment response message, such that when IAB node 104 receives the second F1 establishment response message, IAB node 104 suppresses activation of cells(s) in the second list but not included in the first list (IAB node 104 can suppress deactivation of any active cells not included in the second list but included in the first list).

[0101] In some implementations, in response to receiving a second F1 establishment request message from IAB donor 108B or sending a second F1 establishment response message to the IAB node, IAB donor CU 172A may, in view of the established second F1 connection, not perform or suppress the execution of the NG establishment process and / or gNB configuration process with CN 110.

[0102] As a result of completing the second F1 establishment process with IAB donor 108B, IAB node 104 (e.g., IAB-DU174C) establishes a second F1 connection with IAB donor 108B via IAB donor 108A. Therefore, IAB node 104 can exchange F1AP messages with IAB donor 108B via IAB donor 108A on the second F1 connection. In some embodiments, after IAB node 104 switches to IAB donor 108B (e.g., as...), Figures 6A-6D and Figures 7A-7D As described above, IAB node 104 can activate inactive cells in the second list and then send an F1AP message (e.g., a gNB-DU configuration update message) to IAB donor 108B, which includes a list of active cells (i.e., serving cells) and / or a list of inactive cells (i.e., out-of-service cells).

[0103] Events 516, 518, 522, 524, and 526 can be collectively referred to as F1 connection establishment procedure 560.

[0104] In some implementations, in response to or after the F1 connection establishment process 560, the IAB donor CU 172B avoids communication with the base station (e.g., IAB donor 108A, IAB donor 108C, IAB donor CU 172A, IAB donor CU 172B, ...). Figure 1A The gNB (not shown) performs the BS-to-BS interface establishment process (e.g., the Xn establishment process).

[0105] In some implementations, IAB donor 108A, IAB node 104, RAN 105, or O&M node ensure that IAB node 104 performs F1 connection establishment procedure 560 (e.g., as...) before IAB donor 108A and IAB donor 108B perform handover preparation to switch UE 102 or a descendant IAB node of IAB node 104 to IAB donor 108B. Figures 8A-8B (As described).

[0106] In some implementations, IAB node 104 includes a DU controller 134A for performing a first F1 establishment procedure with IAB donor 108A. Figure 1A(as shown in the diagram), and another DU controller for performing the second F1 establishment process with the IAB donor 108B (as shown in the diagram). Figure 1A (Not shown in the image). In other embodiments, the same DU controller (e.g., DU controller 134A) performs both the first F1 setup process and the second F1 setup process.

[0107] Now for reference Figure 5B ,although Figure 5A The IAB donor 108A can send a 518 second F1 setup request message directly to the IAB donor 108B through the established BS-to-BS interface, but Figure 5B IAB donor 108A does not have a BS-to-BS interface established with IAB donor 108B, and therefore can send a second F1 establishment request message to IAB donor 108B via CN 110. Therefore, IAB node 104 can establish a second F1 connection with IAB donor 108B via IAB donor 108A and CN 110. Otherwise, refer to the above... Figure 5A Any of the described implementations can be applied to Figure 5B Scene 500B.

[0108] Similar to scenario 500A, in Figure 5B In scenario 500B, IAB node 104 initially executes F1 connection establishment procedure 550 to establish an F1 connection with IAB donor 108A.

[0109] During or after the execution of F1 connection establishment procedure 550, IAB node 104 executes second F1 connection establishment procedure 561 to establish a second F1 connection with IAB donor 108B. Second F1 connection establishment procedure 561 is similar to second F1 connection establishment procedure 560, except that CN 110 coordinates the exchange of second F1 establishment request messages and second F1 establishment response messages between IAB donor 108A and IAB donor 108B, because IAB donor 108A does not have a direct BS-to-BS interface established with IAB donor 108B. Specifically, in response to receiving second F1 establishment request message 516 from IAB node 104, IAB donor 108A sends second F1 establishment request message 517 to CN 110, and CN 110 then forwards second F1 establishment request message 519 to IAB donor 108B. In response to receiving the second F1 establishment request message 519, IAB donor 108B sends a second F1 establishment response message 521 to CN 110, which in turn forwards the second F1 establishment response message 523 to IAB donor 108A. Then, IAB donor 108A sends a second F1 establishment response message 524 to IAB node 104. As a result, IAB node 104 (e.g., IAB-DU 174C) establishes a second F1 connection 526 with IAB donor 108B via IAB donor 108A and CN 110. Events 516, 517, 519, 521, 523, 524, and 526 can be collectively referred to as F1 connection establishment procedure 561.

[0110] In some implementations, the second F1 establishment request messages at events 516, 517, and 519 and the second F1 establishment response messages at events 521, 523, and 524 can be respectively generated by... Figure 5A The first and second groups described in the text are replaced.

[0111] Now for reference Figure 6A In IAB node 104 (e.g., IAB-DU 174C) as Figure 5A After establishing a first F1 connection with IAB donor 108A and a second F1 connection with IAB donor 108B as described above, IAB node 104 can switch to IAB donor 108B, thereby releasing the first F1 connection and the second F1 connection in the process. Figure 6A The following scenario is described in general, in which after IAB node 104 switches to IAB donor 108B, IAB node 104 establishes a third F1 connection with IAB donor 108B and establishes a fourth F1 connection with IAB donor 108A via IAB donor 108B.

[0112] Similar to scenario 500A, in Figure 6AIn scenario 600A, similar to F1 connection establishment process 550, IAB node 104 executes F1 connection establishment process 650 to establish an F1 connection with IAB donor 108A. During or after executing F1 connection establishment process 650, similar to F1 connection establishment process 560, IAB node 104 executes a second F1 connection establishment process 660 to establish a second F1 connection with IAB donor 108B via IAB donor 108A.

[0113] At some point, IAB donor 108A determines (602) that it should perform an (immediate) switchover from IAB node 104 to IAB donor 108B. IAB donor 108A can make this determination based on, for example, one or more measurements received from IAB node 104 or another suitable event (e.g., a topology change command from a network node such as an O&M node). In response to this determination, IAB donor 108A sends a 604 switchover request message to IAB donor 108B.

[0114] In some implementations, the handover request message includes a source access stratum (AS) configuration for IAB node 104 in the IAB donor 108A. IAB node 104 uses the source AS configuration to communicate with IAB donor 108A. The handover request message may also include user plane settings such as TNL information, which includes the transport layer addresses and GTP-TEIDs of (multiple) other intermediate IAB nodes (e.g., IAB node 106A). In other implementations, the handover request message may also include UE context and / or IAB-related information for IAB node 104, such as backhaul and topology-related information (e.g., BAP mapping configurations or aggregations of BAP mapping configurations for other intermediate IAB nodes) and / or UE context for (multiple) other intermediate IAB nodes.

[0115] In response to receiving a 604 handover request message, IAB donor 108B generates an RRC reconfiguration message for IAB node 104 (e.g., IAB-MT132) and includes the RRC reconfiguration message in the handover request acknowledgment message. Subsequently, IAB donor 108B sends a 606 handover request acknowledgment message to IAB donor 108A. Then, IAB donor 108A sends a 610 RRC reconfiguration message to IAB node 104, and IAB node 104 then attempts to perform a handover based on the RRC reconfiguration message.

[0116] In some implementations, if instructed in an RRC reconfiguration message, IAB node 104 can perform a 612 random access procedure with IAB donor 108B. In response to the RRC reconfiguration message, IAB node 104 sends a 614 RRC reconfiguration complete message to IAB donor 108B during or after the random procedure (if performed). In some implementations, upon receiving the 614 RRC reconfiguration complete message, IAB donor 108B can send a handover success message to IAB donor 108A to instruct IAB node 104 to successfully hand over to IAB donor 108B.

[0117] Events 602, 604, 606, 610, 612, and 614 can be collectively referred to as IAB node switching process 670.

[0118] In some embodiments, during or after the execution of the IAB node handover process 670, IAB node 104 releases the first and second F1 connections physically established at events 650 and 660, respectively. Therefore, in order to establish new F1 connections with multiple CUs after switching to IAB donor 108B, similar to how IAB node 104 establishes the first and second F1 connections before switching to IAB donor 10B, as further described below, IAB node 104 (e.g., IAB-DU 174C) can establish a (third) F1 connection with IAB donor 108B and, via IAB donor 108B, a (fourth) F1 connection with IAB donor 108A.

[0119] To establish a third F1 connection with IAB donor 108B, IAB node 104 executes F1 connection establishment procedure 676 to establish a third F1 connection with IAB donor 108B. To initiate F1 connection establishment procedure 676, IAB node 104 determines to execute F1 establishment procedure 616 (third) with IAB donor 108B. To execute the third F1 establishment procedure, similar to event 508, except that IAB node 104 sends a third F1 establishment request message 618 to IAB donor 108B. In response to receiving the third F1 establishment request message, IAB donor 108B can initiate or create a third F1-C interface instance for exchanging F1AP messages with IAB node 104, and subsequently send a third F1 establishment response message 512 to IAB node 104, similar to event 512, except that IAB donor 108B is executing an event. As a result of completing the third F1 connection establishment process with IAB donor 108B, similar to event 514, except that IAB node 104 (e.g., IAB-DU 174C) establishes a third F1 connection 622 with IAB donor 108B (e.g., IAB donor CU 172B). Therefore, similar to how IAB node 104 can exchange F1AP messages with IAB donor 108A on the first F1 connection, IAB node 104 can exchange F1AP messages with IAB donor 108B on the third F1 connection. Events 616, 618, 620, and 622 can be collectively referred to as F1 connection establishment process 676.

[0120] In some implementations, IAB node 104 can perform (i.e., establish) a third TNLA with IAB donor 108B after switching to IAB donor 108B. In some implementations, IAB node 104 and IAB donor 108B can establish a third TNLA by associating the TNL address of IAB node 104 (e.g., a first TNL address, a third TNL address, or another TNL address) with the TNL address of IAB donor 108B (e.g., a fourth TNL address or another TNL address). For example, after switching to IAB donor 108B, IAB node 104 can generate a packet including an F1AP message (e.g., a third F1 setup request message), multiple TNL protocol headers, the TNL address of IAB node 104 (i.e., the source address), and the TNL address of IAB donor 108B (i.e., the destination address), and send the packet to IAB donor 108B. Similarly, after IAB node 104 switches to IAB donor 108B, IAB donor 108B is able to generate a packet including an F1AP message (e.g., a third F1 establishment response message), (multiple) TNL protocol headers, the TNL address of IAB donor 108B (i.e., the source address) and the TNL address of IAB node 104 (i.e., the destination address), and send the packet to IAB node 104.

[0121] In other implementations, after switching to IAB donor 108B, IAB node 104 continues to use the second TNLA instead of performing a TNLA (e.g., a third TNLA) with IAB donor 108B. For example, after switching to IAB donor 108B, IAB node 104 is able to generate a packet including an F1AP message (e.g., a third F1 setup request message), (multiple) TNL protocol headers, the third TNL address (i.e., the source address) of IAB node 1014, and the fourth TNL address (i.e., the destination address) of IAB donor 108B, and send the packet to IAB donor 108B. Similarly, after IAB node 104 switches to IAB donor 108B, IAB donor 108B is able to generate a packet including an F1AP message (e.g., a third F1 setup response message), (multiple) TNL protocol headers, the fourth TNL address (i.e., the source address) of IAB donor 108B and the third TNL address (i.e., the destination address) of IAB node 104, and send the packet to IAB node 104.

[0122] During or after the execution of F1 connection establishment procedure 676, in some embodiments, IAB node 104 executes another (fourth) F1 connection establishment procedure 680, similar to how IAB node 104 executes the second F1 connection establishment procedure 660, except that IAB node 104 executes the fourth F1 connection establishment procedure 680 to establish another (fourth) F1 connection with IAB donor 108A via IAB donor 108B. In some embodiments, IAB node 104 may be triggered by IAB donor 108B, an O&M node, or otherwise pre-configured to execute the fourth F1 connection establishment procedure 680 in a manner similar to that described above with respect to the second F1 connection establishment procedure 660.

[0123] In order to initiate the fourth F1 connection establishment process 680, IAB node 104 and IAB donor 108B perform another (fourth) F1 establishment process to establish a (fourth) F1 connection (e.g., an F1-C connection) with IAB donor 108A via IAB donor 108B, so that IAB node 104 (e.g., IAB-DU 174C) can exchange F1AP messages with IAB donor 108A (e.g., IAB donor CU172B) on the fourth F1 interface or connection.

[0124] To execute the fourth F1 establishment process, similar to event 516, IAB node 104 sends a 630 fourth F1 establishment request message to IAB donor 108B. In response to receiving the fourth F1 establishment request message, similar to how IAB donor 108A determined that the second F1 establishment request message was for IAB donor 108B, IAB donor 108B determines that the fourth F1 establishment request message is for IAB donor 108A. Therefore, similar to how IAB donor 108A sends a 518 second F1 establishment request message to IAB donor 108B (e.g., directly via the BS-to-BS interface), IAB donor 108B sends a 632 fourth F1 establishment request message to IAB donor 108A (e.g., IAB donor CU 172A).

[0125] In response to receiving the fourth F1 establishment request message 632, similar to how IAB donor 108B directly sends the second F1 establishment response message 522 to IAB donor 108A, IAB donor 108A can initiate or create a fourth F1-C interface instance for exchanging F1AP messages with IAB node 104, and then directly send the fourth F1 establishment response message 634 to IAB donor 108B. Furthermore, similar to how IAB donor 108A sends the second F1 establishment response message 524 to IAB node 104, IAB donor 108B sends the fourth F1 establishment response message 636 to IAB node 104. As a result of completing the fourth F1 establishment process with IAB donor 108A, IAB node 104 (e.g., IAB-DU 174C) establishes a fourth F1 connection 640 with IAB donor 108A via IAB donor 108B. Therefore, IAB node 104 can exchange F1AP messages with IAB donor 108A via IAB donor 108B on the fourth F1 connection. Events 630, 632, 634, 636, and 640 can be collectively referred to as F1 connection establishment process 680.

[0126] In some implementations, after switching to IAB donor 108B, IAB node 104 can perform (i.e., establish) a fourth TNLA with IAB donor 108A, for example, via IAB donor 108B or CN 110. In some implementations, IAB node 104 and IAB donor 108A can establish the fourth TNLA by associating the TNL address of IAB node 104 (e.g., a first TNL address, a third TNL address, or another TNL address) with the TNL address of IAB donor 108A (e.g., a second TNL address or another TNL address). For example, after switching to IAB donor 108B, IAB node 104 can generate a packet including an F1AP message (e.g., a fourth F1 establishment request message), (multiple) TNL protocol headers, the TNL address of IAB node 104 (i.e., the source address), and the TNL address of IAB donor 108A (i.e., the destination address), and send the packet to IAB donor 108A via IAB donor 108B or CN 110. Similarly, after switching to IAB donor 108B, IAB donor 108A can generate a packet including an F1AP message (e.g., a fourth F1 establishment response message), (multiple) TNL protocol headers, the TNL address of IAB donor 108A (i.e., the source address), and the TNL address of IAB node 104 (i.e., the destination address), and send the packet to IAB node 104 via IAB donor 108B or CN 110.

[0127] In other implementations, after switching to IAB donor 108B, IAB node 104 continues to use the first TNLA instead of performing a TNLA (e.g., a fourth TNLA) with IAB donor 108A. For example, after switching to IAB donor 108B, IAB node 104 is able to generate a packet including an F1AP message (e.g., a fourth F1 setup request message), multiple TNL protocol headers, a first TNL address (i.e., the source address) of IAB node 104, and a second TNL address (i.e., the destination address) of IAB donor 108A, and send the packet to IAB donor 108A via IAB donor 108B or CN 110. Similarly, after IAB node 104 switches to IAB donor 108B, IAB donor 108B can generate a packet including an F1AP message (e.g., a third F1 setup response message), (multiple) TNL protocol headers, the second TNL address (i.e., the source address) of IAB donor 108A, and the first TNL address (i.e., the destination address) of IAB node 104, and send the packet to IAB node 104 via IAB donor 108B or CN 110.

[0128] Now for reference Figure 6B ,although Figure 6A IAB donor 108A and IAB donor 108B can communicate directly with each other through the established BS-to-BS interface, but Figure 6B IAB donor 108A and IAB donor 108B do not have a BS-to-BS interface established between them. Thus, CN 110 can coordinate communication between IAB donor 108A and IAB donor 108B. Otherwise, refer to the above... Figure 6A Any of the described implementations can be applied to Figure 6B Scene 600B.

[0129] Similar to scenario 600A, in Figure 6B In scenario 600B, IAB node 104 initially executes F1 connection establishment procedure 650 to establish an F1 connection with IAB donor 108A. During or after executing F1 connection establishment procedure 650, similar to F1 connection establishment procedure 561, IAB node 104 executes a second F1 connection establishment procedure 661 to establish a second F1 connection with IAB donor 108B via IAB donor 108A and CN 110.

[0130] IAB donor 108A determines at some point that it should switch IAB node 104 to IAB donor 108B, thereby executing IAB node handover procedure 671, which is similar to IAB node handover procedure 670 except that CN 110 is involved. Specifically, in order to initiate IAB node handover procedure 671, IAB donor 108A determines 602 to switch IAB node 104 to IAB donor 108B, and then sends 603 a handover required message to prepare for the handover from IAB node 104 to CN 110. CN 110 then sends a 605 handover request message to IAB donor 108B. In response, IAB donor 108B sends a 607 handover request confirmation message including an RRC reconfiguration message to CN 110, and CN 110 then sends a 609 handover command message (i.e., an NGAP message) including an RRC reconfiguration message to IAB donor 108A. Then, IAB donor 108A sends a 610 handover command message to IAB node 104, and IAB node 104 then attempts to perform a handover based on the handover command message.

[0131] In some implementations, if instructed in an RRC reconfiguration message, IAB node 104 can perform a 612 random access procedure with IAB donor 108B. In response to the RRC reconfiguration message, IAB node 104 sends a 614 RRC reconfiguration complete message to IAB donor 108B during or after the random procedure (if performed). Events 602, 603, 605, 607, 609, 610, 612, and 614 can be collectively referred to as IAB node handover procedure 671.

[0132] In some embodiments, during or after the execution of IAB node handover procedure 671, IAB node 104 releases the first and second F1 connections physically established at events 650 and 661, respectively. Therefore, in order to establish new F1 connections with multiple CUs after switching to IAB donor 108B, IAB node 104 (e.g., IAB-DU174C) can establish a (third) F1 connection with IAB donor 108B and a (fourth) F1 connection with IAB donor 108A via IAB donor 108B and CN 110.

[0133] As described above, in order to establish a third F1 connection with IAB donor 108B, IAB node 104 executes F1 connection establishment procedure 676 to establish a third F1 connection with IAB donor 108B.

[0134] During or after the execution of F1 connection establishment procedure 676, in some embodiments, IAB node 104 executes another (fourth) F1 connection establishment procedure 681, which is similar to F1 connection establishment procedure 680 except that CN 110 establishes another (fourth) F1 connection with IAB donor 108A via IAB donor 108B and CN 110.

[0135] In order to initiate the fourth F1 connection establishment process 681, IAB node 104 and IAB donor 108B perform another (fourth) F1 establishment process to establish a (fourth) F1 connection (e.g., F1-C connection) with IAB donor 108A via IAB donor 108B and CN 110, so that IAB node 104 (e.g., IAB-DU 174C) can exchange F1AP messages with IAB donor 108A (e.g., IAB donor CU 172B) on the fourth F1 interface or connection.

[0136] To perform the fourth F1 establishment procedure, IAB node 104 sends a 630 fourth F1 establishment request message. Upon receiving the fourth F1 establishment request message, IAB donor 108B determines that the message is addressed to IAB donor 108A. Therefore, IAB donor 108B sends a 631 fourth F1 establishment request message to CN 110, which in turn forwards a 633 fourth F1 establishment request message to IAB donor 108A (e.g., IAB donor CU 172A).

[0137] In response to receiving the fourth F1 establishment request message 633, IAB donor 108A can initiate or create a fourth F1-C interface instance for exchanging F1AP messages with IAB node 104, and subsequently send a fourth F1 establishment response message 635 to CN 110. CN 110 then forwards a fourth F1 establishment response message 637 to IAB donor 108B. Subsequently, IAB donor 108B sends a fourth F1 establishment response message 636 to IAB node 104. As a result of completing the fourth F1 establishment process with IAB donor 108A, IAB node 104 (e.g., IAB-DU 174C) establishes a fourth F1 connection 641 with IAB donor 108A via IAB donor 108B and CN 110. Therefore, IAB node 104 can exchange F1AP messages with IAB donor 108A via IAB donor 108B and CN 110 on the fourth F1 connection. Events 630, 631, 633, 635, 637, 636, and 641 can be collectively referred to as F1 connection establishment process 681.

[0138] In some implementations, after switching to IAB donor 108B, IAB node 104 can perform (i.e., establish) a fourth TNLA with IAB donor 108A via CN 110. In some implementations, IAB node 104 and IAB donor 108A can establish the fourth TNLA by associating the TNL address of IAB node 104 (e.g., a first TNL address, a third TNL address, or another TNL address) with the TNL address of IAB donor 108A (e.g., a second TNL address or another TNL address). For example, after switching to IAB donor 108B, IAB node 104 can generate a packet including an F1AP message (e.g., a fourth F1 setup request message), multiple TNL protocol headers, the TNL address of IAB node 104 (i.e., the source address), and the TNL address of IAB donor 108A (i.e., the destination address), and send the packet to IAB donor 108A via CN 110. Similarly, after IAB node 104 switches to IAB donor 108B, IAB donor 108A can generate a packet including an F1AP message (e.g., a fourth F1 setup response message), (multiple) TNL protocol headers, the TNL address of IAB donor 108A (i.e., the source address) and the TNL address of IAB node 104 (i.e., the destination address), and send the packet to IAB node 104 via CN 110.

[0139] In other implementations, after switching to IAB donor 108B, IAB node 104 continues to use the first TNLA instead of performing a TNLA (e.g., a fourth TNLA) with IAB donor 108A. For example, after switching to IAB donor 108B, IAB node 104 is able to generate a packet including an F1AP message (e.g., a fourth F1 setup request message), multiple TNL protocol headers, a first TNL address (i.e., the source address) of IAB node 104, and a second TNL address (i.e., the destination address) of IAB donor 108A, and send the packet to IAB donor 108A via CN 110. Similarly, after IAB node 104 switches to IAB donor 108B, IAB donor 108B can generate a packet including an F1AP message (e.g., a third F1 setup response message), (multiple) TNL protocol headers, the second TNL address (i.e., the source address) of IAB donor 108A, and the first TNL address (i.e., the destination address) of IAB node 104, and send the packet to IAB node 104 via CN 110.

[0140] Now for reference Figure 6C ,although Figure 6AIAB node 104 releases the first and second F1 connections physically established in corresponding events 650 and 660, and establishes a third and fourth F1 connection after IAB node switching procedure 670 as described in F1 connection establishment procedures 676 and 680, but Figure 6C IAB node 104 retains the first and second F1 connections and physically reroutes them, as shown in events 621 and 623. Therefore, IAB node 104 does not need to establish new third and fourth F1 connections. Otherwise, refer to the above... Figure 6A Any of the described implementations can be applied to Figure 6C Scene 600C.

[0141] Specifically, in event 621, IAB node 104 retains the first F1 connection and physically reroutes it, causing the first F1 connection to be re-established between IAB node 104 and IAB donor 108B. The re-routed first F1 connection maintains its logical first transaction identifier. Similarly, in event 623, IAB node 104 retains the second F1 connection and physically reroutes it, causing the second F1 connection to be re-established between IAB node 104 and IAB donor 108A via IAB donor 108B. The re-routes second F1 connection maintains its logical second transaction identifier.

[0142] Now for reference Figure 6D ,although Figure 6B IAB node 104 releases the first and second F1 connections physically established in corresponding events 650 and 661, and establishes a third and fourth F1 connection as described in F1 connection establishment procedures 676 and 681 after IAB node handover procedure 671. Figure 6D IAB node 104 retains the first and second F1 connections and physically reroutes them, as shown in events 621 and 624. Therefore, IAB node 104 does not need to establish new third and fourth F1 connections. Otherwise, refer to the above... Figure 6B Any of the described implementations can be applied to Figure 6D Scene 600D.

[0143] Specifically, in event 621, IAB node 104 retains the first F1 connection and physically reroutes it, so that the first F1 connection is re-established between IAB node 104 and IAB donor 108B. The rerouting of the first F1 connection maintains its logical first transaction identifier. Similarly, in event 624, IAB node 104 retains the second F1 connection and physically reroutes it, so that the second F1 connection is re-established between IAB node 104 and IAB donor 108A via IAB donor 108B and CN 110. The rerouting of the second F1 connection maintains its logical second transaction identifier.

[0144] Now for reference Figure 7A ,although Figure 6A The IAB donor 108A can initiate the IAB node handover process for the immediate handover of IAB node 104, but Figure 7A IAB donor 108A can initiate the IAB node handover process for conditional handover (CHO) of IAB node 104. Otherwise, refer to the above. Figure 6A Any of the described implementations can be applied to Figure 7A Scene 700A.

[0145] Similar to scenario 600A, in Figure 7A In scenario 700A, similar to F1 connection establishment process 650, IAB node 104 executes F1 connection establishment process 750 to establish an F1 connection with IAB donor 108A. During or after executing F1 connection establishment process 750, similar to F1 connection establishment process 660, IAB node 104 executes second F1 connection establishment process 760 to establish a second F1 connection with IAB donor 108B via IAB donor 108A.

[0146] At some point, IAB donor 108A determines at time 702 that it should switch IAB node 104 to IAB donor 108B, similar to event 602, except that if IAB node 104 determines that a condition associated with the conditional configuration is met, then IAB donor 108A determines that IAB node 104 should conditionally switch to IAB donor 108B. As used herein, a condition can refer to a single detectable state or event (e.g., a specific signal quality metric exceeds a threshold) or a logical combination of such states or events (e.g., condition A and condition B, or (condition A or condition B) and condition C, etc.). In response to this determination, IAB donor 108A sends a conditional switch request message 704 (e.g., a switch request message including a CHO information request) to IAB donor 108B.

[0147] In response to receiving a 704 handover request message, IAB donor 108B generates a conditional configuration that includes information enabling IAB node 104 (e.g., IAB-MT 132) to communicate with IAB donor 108B via a candidate cell. IAB donor 108B includes the conditional configuration in a conditional handover request confirmation message (e.g., a handover request confirmation message) from IAB node 104, and subsequently sends a 706 conditional handover request confirmation message to IAB donor 108A in response to the conditional handover request message. In some embodiments, instead of including the conditional configuration in the conditional handover request confirmation message, IAB donor 108B may include a CHO command in the conditional handover request confirmation message. In other cases, IAB donor 108B may include the conditional configuration in the CHO command and the CHO command in the conditional handover request confirmation message.

[0148] IAB donor 108A sends an RRC reconfiguration message 710, including a conditional configuration or CHO command, to IAB node 104. IAB node 104, in turn, optionally sends an RRC reconfiguration complete message 740 to IAB donor 108A in response to receiving the RRC reconfiguration message. In some embodiments, IAB donor 108A includes conditions (or conditions) in the conditional configuration or RRC reconfiguration message for IAB node 104 to detect, such that if the conditions are met, IAB node 104 can communicate with IAB donor 108B. IAB donor 108A can include the conditional configuration in the conditional configuration field or information element (IE) of the RRC reconfiguration message (e.g., CondReconfigToAddMod-r16 IE). IAB donor 108A can also include a configuration identifier / identifier (ID) associated with the conditional configuration in the conditional configuration field / IE, enabling IAB node 104 to recognize and store the conditional configuration. IAB donor 108A can assign configuration IDs or receive configuration IDs from IAB donor 108B.

[0149] According to the RRC reconfiguration message, IAB node 104 performs CH0 upon detecting condition(s) 742 for connecting to a candidate cell associated with IAB donor 108B. In response to the detection of condition(s), IAB node 104 is able to perform random access procedure 712 with IAB donor 108B on the candidate cell. In response to the RRC reconfiguration message, IAB node 104 sends an RRC reconfiguration complete message 714 to IAB donor 108B during or after the random procedure (if performed). In some embodiments, after receiving the RRC reconfiguration complete message 714, IAB donor 108B is able to send a handover success message to IAB donor 108A to instruct IAB node 104 to successfully hand over to IAB donor 108B.

[0150] Events 702, 704, 706, 710, 740, 742, 712, and 714 can be collectively referred to as IAB node condition switching process 770.

[0151] While performing the IAB node condition switching procedure 770 or after completing the IAB node condition switching procedure 770, in some implementations, similar to the F1 connection establishment procedure 676, the IAB node 104 performs the F1 connection establishment procedure 776 to establish a third F1 connection with the IAB donor 108B.

[0152] During or after the execution of the F1 connection establishment process 776, in some embodiments, the IAB node 104 executes an F1 connection establishment process 780 similar to the F1 connection establishment process 680 to establish a fourth F1 connection with the IAB donor 108A via the IAB donor 108B.

[0153] Now for reference Figure 7B ,although Figure 7A IAB donor 108A and IAB donor 108B can communicate directly with each other through the established BS-to-BS interface, but Figure 7B IAB donor 108A and IAB donor 108B do not have a BS-to-BS interface established between them. Thus, CN 110 can coordinate communication between IAB donor 108A and IAB donor 108B. Otherwise, refer to the above... Figure 7A Any of the described implementations can be applied to Figure 7B Scene 700B.

[0154] Similar to scenario 700A, in Figure 7B In scenario 700B, IAB node 104 initially executes F1 connection establishment procedure 750 to establish an F1 connection with IAB donor 108A. During or after executing F1 connection establishment procedure 750, similar to F1 connection establishment procedure 661, IAB node 104 executes a second F1 connection establishment procedure 761 to establish a second F1 connection with IAB donor 108B via IAB donor 108A and CN 110.

[0155] At some point, IAB donor 108A determines that it should configure IAB node 104 to execute a CHO (Confirmation of Ownership) to IAB donor 108B, thereby executing IAB node conditional switching procedure 771, which is similar to IAB node conditional switching procedure 770 except that CN 110 is involved. Specifically, to initiate IAB node conditional switching procedure 771, if IAB node 104 determines that the conditions associated with the conditional configuration are met, IAB donor 108A determines 702 that IAB node 104 should conditionally switch to IAB donor 108B. In response to this determination, IAB donor 108A sends a 703 conditional switching request message (e.g., a switching request message including a CHO information request) to CN 110. CN 110 then sends a 705 conditional switching request message (e.g., a switching request message including a CHO information request) to IAB donor 108B. In response, IAB donor 108B includes the conditional configuration or CHO command as described above in the conditional switch request confirmation message (e.g., switch request confirmation message) of IAB node 104, and then sends the conditional switch request confirmation message 707 to CN 110, which in turn forwards the conditional switch request confirmation message to IAB donor 108A.

[0156] IAB donor 108A sends an RRC reconfiguration message 710, which includes a conditional configuration or CHO command, to IAB node 104. In response to receiving the RRC reconfiguration message, IAB node 104 may optionally send an RRC reconfiguration complete message 740 to IAB donor 108A.

[0157] According to the RRC reconfiguration message, IAB node 104 performs CH0 upon detecting condition(s) 742 for connecting to a candidate cell associated with IAB donor 108B. In response to the detection of condition(s), IAB node 104 can perform random access procedure 712 with IAB donor 108B on the candidate cell. In response to the RRC reconfiguration message, IAB node 104 sends an RRC reconfiguration complete message 714 to IAB donor 108B during or after the random procedure (if performed). Events 702, 703, 705, 707, 709, 710, 740, 742, 712, and 714 can be collectively referred to as IAB node condition handover procedure 771.

[0158] In some implementations, while performing or after completing the IAB node condition switching procedure 771, IAB node 104 performs the F1 connection establishment procedure 776 to establish a third F1 connection with IAB donor 108B.

[0159] During or after the execution of F1 connection establishment process 776, in some embodiments, IAB node 104 executes F1 connection establishment process 781 similar to F1 connection establishment process 681 to establish a fourth F1 connection with IAB donor 108A via IAB donor 108B and CN 110.

[0160] Now for reference Figure 7C ,although Figure 7A IAB node 104 releases the first and second F1 connections physically established in corresponding events 750 and 760, and establishes a third and fourth F1 connection as described in F1 connection establishment processes 776 and 780 after IAB node condition switching process 770. Figure 7C IAB node 104 retains the first and second F1 connections and physically reroutes them, as shown in events 721 and 723. Therefore, IAB node 104 does not need to establish new third and fourth F1 connections. Otherwise, refer to the above... Figure 7A Any of the described implementations can be applied to Figure 7C Scene 700C.

[0161] Specifically, in event 721, IAB node 104 retains the first F1 connection and physically reroutes it, causing the first F1 connection to be re-established between IAB node 104 and IAB donor 108B. The rerouting of the first F1 connection maintains its logical first transaction identifier. Similarly, in event 723, IAB node 104 retains the second F1 connection and physically reroutes it, causing the second F1 connection to be re-established between IAB node 104 and IAB donor 108A via IAB donor 108B. The rerouting of the second F1 connection maintains its logical second transaction identifier.

[0162] Now for reference Figure 7D ,although Figure 7B IAB node 104 releases the first and second F1 connections physically established in corresponding events 750 and 761, and establishes a new third and fourth F1 connection as described in F1 connection establishment procedures 776 and 781 after IAB node condition switching procedure 671. Figure 7D IAB node 104 retains the first and second F1 connections and physically reroutes them, as shown in events 721 and 724. Therefore, IAB node 104 does not need to establish new third and fourth F1 connections. Otherwise, refer to the above... Figure 7B Any of the described implementations can be applied to Figure 7D Scene 700D.

[0163] Specifically, in event 721, IAB node 104 retains the first F1 connection and physically reroutes it, causing the first F1 connection to be re-established between IAB node 104 and IAB donor 108B. The rerouting of the first F1 connection maintains its logical first transaction identifier. Similarly, in event 724, IAB node 104 retains the second F1 connection and physically reroutes it, causing the second F1 connection to be re-established between IAB node 104 and IAB donor 108A via IAB donor 108B and CN 110. The rerouting of the second F1 connection maintains its logical second transaction identifier.

[0164] Now for reference Figure 8A ,although Figure 6A IAB donor 108A determines to switch IAB node 104 after the first F1 connection and the second F1 connection are established, but Figure 8A Before determining to switch IAB node 104, IAB donor 108A determines to switch UE 102 after the first and second F1 connections of the F1 connection are established.

[0165] Similar to scenario 600A, in Figure 8A In scenario 800A, similar to F1 connection establishment process 650, IAB node 104 executes F1 connection establishment process 850 to establish an F1 connection with IAB donor 108A. During or after executing F1 connection establishment process 850, similar to F1 connection establishment process 660, IAB node 104 executes a second F1 connection establishment process 860 to establish a second F1 connection with IAB donor 108B via IAB donor 108A.

[0166] As a result of the F1 connection establishment process 850, IAB donor 108A can serve UE 102 via IAB node 104. UE 102, for example, transmits 802 data (e.g., uplink and / or downlink PDUs) with IAB donor 108A via IAB node 104, depending on the source IAB donor configuration. UE 102 can also transmit 802 data with CN 110 via IAB donor 108A and IAB node 104.

[0167] At a later time, IAB donor 108A is able to determine 804 that UE 102 should be handed over to IAB donor 108B. IAB donor 108A can make this determination based on, for example, one or more measurements received from IAB node 104 and / or UE 102 or another suitable event (e.g., a topology change commanded by a network node such as an O&M node). In response to this determination, IAB donor 108A initiates UE handover procedure 894 by sending a handover request message for UE 102 to IAB donor 108B at 806.

[0168] In response to receiving the 806 handover request message, IAB donor 108B sends a 816 handover request confirmation message, including the RRC reconfiguration message of UE 102, to IAB donor 108A. In some implementations, after receiving the handover request message, IAB donor 108B can send a UE context request message to IAB node 104 via IAB donor 108A through a second F1 connection established by the F1 connection establishment procedure 860. That is, using the second F1 connection, IAB donor 108B can, for example, send an 808 UE context request message to IAB donor 108A via a BS-to-BS interface, and IAB donor 108A then forwards an 810 UE context request message to IAB node 104. In response, IAB node 104 can send a UE context response message to IAB donor 108B via IAB donor 108A through the second F1 connection. In other words, using the second F1 connection, IAB donor 108B can send an 812 UE context response message to IAB donor 108A, and IAB donor 108A can then forward an 814 UE context response message to IAB donor 108B, for example, via a BS-to-BS interface. In some implementations, IAB node 104 can include the DU configuration (e.g., CellGroupConfig IE) in the UE context response message at event 812, and IAB donor 108B can include the DU configuration in the RRC reconfiguration message at event 816. In some implementations, IAB donor 108B sends an 808 BS-to-BS interface message (e.g., an XnAP message or a GTP-U packet) including a UE context request message to IAB donor 108A, and IAB donor 108A sends an 814 BS-to-BS interface message (e.g., an XnAP message or a GTP-U packet) including a UE context response message. In other implementations, IAB node 104 and IAB donor 108B exchange UE context request messages and UE context response messages via IAB donor 108A or CN 110 using a second TNLA as described above.

[0169] In some implementations, the UE context request message and the UE context response message can be respectively a UE context establishment request message and a UE context establishment response message. In other implementations, the UE context request message and the UE context response message can be respectively a UE context modification request message and a UE context modification response message. In some implementations, the UE context request message includes a BH RLC channel list to be established (or modified), which may include BH RLC CH ID, BH RLC CH QoS or E-UTRAN BH RLC CH QoS, control plane service type, RLC mode, BAP control PDU channel, and service mapping information. The UE context request message may also include a DRB list to be established (or modified) and a BAP address as defined in TS 38.473. In other implementations, the UE context request message may not include a BHRLC channel list to be established (or modified), which may include BH RLC CHD, BH RLC CH QoS or E-UTRAN BH RLC CH QoS, control plane service type, RLC mode, BAP control PDU channel, and service mapping information. The UE context request message may also include a list of DRBs to be established (or modified) and BAP addresses as defined in TS38.473.

[0170] After IAB donor 108A receives the 816 RRC reconfiguration message, IAB donor 108A sends the 818 RRC reconfiguration message to IAB node 104, and IAB node 104 then forwards the 820 RRC reconfiguration message to UE 102.

[0171] In some implementations, if indicated by an RRC reconfiguration message, UE 102 is able to perform a random access procedure 822 with IAB node 104. In response to receiving an RRC reconfiguration message 820, UE 102 sends an RRC reconfiguration complete message 832 to IAB node 104, which in turn sends an RRC reconfiguration complete message 834 to IAB donor 108A. IAB donor 108A is then able to forward the RRC reconfiguration complete message 840 to IAB donor 108B, for example, via a BS-to-BS interface. In some implementations, IAB donor 108A sends a BS-to-BS interface message (e.g., an XnAP message or a GTP-U packet) including the RRC reconfiguration complete message to IAB donor 108B. In other implementations, IAB node 104 generates an F1AP message (e.g., a UL RRC message delivery message) including the RRC reconfiguration complete message and sends the F1AP message to IAB donor 108B as described above using a second TNLA.

[0172] In some implementations, after sending an 820RRC reconfiguration message, performing a random access procedure 822 with UE 102, or receiving a second RRC reconfiguration completion message 832, IAB node 104 can send an 824F1-C message or an F1-U frame to IAB donor 108A. IAB donor 108A then forwards the F1-C message or F1-U frame 826 to IAB donor 108B, for example, via a BS-to-BS interface. In some implementations, the F1-C message or F1-U frame can be an access success message as defined in 3GPP specification 38.473 or a DL data delivery status frame as defined in 3GPP specification 38.425. In some implementations, IAB donor 108A sends an 826 BS-to-BS interface message (e.g., an XnAP message or a GTP-U packet) including the F1-C message or F1-U frame to IAB donor 108B. In other embodiments, IAB node 104 sends F1-C messages or F1-U frames to IAB donor 108B via IAB donor 108A or CN 110 using a second TNLA, as described above. Alternatively, IAB node 104 can send F1-U frames to IAB donor 108B using an F1-UTNL protocol (e.g., GTP-U and IP) and a second TNLA. In other embodiments, IAB node 104 sends F1-U frames to the IAB using a TNLA different from the second TNLA (e.g., an F1-U TNLA). IAB node 104 can establish an F1-U TNLA with IAB donor 108B in a similar manner to the second TNLA, and send F1-U frames to IAB donor 108B via IAB donor 108A or CN 110 using the F1-UTNL protocol and F1-U TNLA addresses (e.g., the F1-U TNLA address of IAB node 104 and the F1-U TNLA address of IAB donor 108B).

[0173] In some implementations, after sending an 806 handover request message, receiving an 816 handover request confirmation message, or sending an 818 RRC reconfiguration message, if the DRB(s) are using RLC confirmation mode, IAB donor 108A can send an 828 SN status transmission message to IAB donor 108B to transmit the UL PDCP SN and HFN receiver status and DL PDCP SN and HFN transmitter status of the DRB(s) of UE 102. Alternatively, or in addition to sending the 828 SN status transmission message, IAB donor 108A can perform an 830 DL data forwarding (i.e., sending the DL data for UE 102 received by IAB donor 108A from CN 110 to IAB donor 108B). In some implementations, the DL data can be the DL data packets (e.g., the Internet Protocol (IP) packets) that IAB donor 108A has not yet sent to IAB node 104. In other implementations, DL data can be (e.g., (multiple) IP packets) that IAB donor 108A has sent to IAB node 104 in PDU (e.g., PDCP PDU) format but has not yet been acknowledged by UE 102 or IAB node 104.

[0174] Although not shown, in some embodiments, after receiving the 836RRC reconfiguration complete message, IAB donor 108B can send a handover success message to IAB donor 108A to instruct UE 102 to successfully hand over from IAB donor 108A to IAB donor 108B. In other embodiments, after receiving the RRC reconfiguration complete message, SN status transmission message, or DL ​​data at events 836, 828, or 830 respectively, IAB donor 108B can send a UE context release message to IAB donor 108A to instruct UE 102 to successfully hand over from IAB donor 108A to IAB donor 108B, or to indicate to IAB donor 108A that UE 102's radio and control plane resources and / or UE 102's context are allowed to be released.

[0175] Events 806, 808, 810, 812, 814, 816, 818, 820, 822, 824, 826, 828, 830, 832, 834 and 836 can be collectively referred to as UE handover process 894.

[0176] During or after the UE handover process 894, IAB node 104 performs IAB node handover process 870, which is similar to IAB node handover process 670.

[0177] Now for reference Figure 8B ,although Figure 8AIAB donor 108A and IAB donor 108B can communicate directly with each other through the established BS-to-BS interface, but Figure 8B IAB donor 108A and IAB donor 108B do not have a BS-to-BS interface established between them. Thus, CN 110 can coordinate communication between IAB donor 108A and IAB donor 108B. Otherwise, refer to the above... Figure 8A Any of the described implementations can be applied to Figure 8B Scene 800B.

[0178] Similar to scenario 800A, in Figure 8B In scenario 800B, IAB node 104 initially executes F1 connection establishment procedure 850 to establish an F1 connection with IAB donor 108A. During or after executing F1 connection establishment procedure 850, similar to F1 connection establishment procedure 661, IAB node 104 executes a second F1 connection establishment procedure 861 to establish a second F1 connection with IAB donor 108B via IAB donor 108A and CN 110.

[0179] As a result of the F1 connection establishment process 850, IAB donor 108A can serve UE 102 via IAB node 104. UE 102 transmits 802 data with IAB donor 108A via IAB node 104. UE 102 can also transmit 802 data with CN 110 via IAB donor 108A and IAB node 104.

[0180] At a later time, IAB donor 108A determines at 804 that UE 102 will be handed over to IAB donor 108B. In response to this determination, IAB donor 108A initiates UE handover procedure 895, which is similar to UE handover procedure 894 except that CN 110 is involved. Specifically, UE handover procedure 895 is initiated by sending a handover request message at 803 to prepare for the handover of UE 102 to CN 110. CN 110 then sends a handover request message for UE 102 at 805 to IAB donor 108B.

[0181] In response to receiving the 805 handover request message, IAB donor 108B sends a 815 handover command message, including the RRC reconfiguration message of UE 102, to CN 110. CN 110 then sends a 817 handover request confirmation message, including the RRC reconfiguration message, to IAB donor 108A. In some embodiments, after receiving the handover request message, IAB donor 108B can send a UE context request message to IAB node 104 via CN 110 and IAB donor 108A on the second F1 connection established by the F1 connection establishment procedure 861. That is, using the second F1 connection, IAB donor 108B can send an 807 UE context request message to CN 110, and CN 110 then forwards an 809 UE context request message to IAB donor 108A. Subsequently, IAB donor 108A forwards the UE context request message 810 to IAB node 104. In response, IAB node 104 can send a UE context response message to IAB donor 108B via IAB donor 108A and CN 110 on the second F1 connection. That is, using the second F1 connection, IAB donor 108B can send a UE context response message 812 to IAB donor 108A, and IAB donor 108A then forwards a UE context response message 811 to CN 110. CN 110 then forwards the UE context response message 813 to IAB donor 108B. In some implementations, IAB node 104 can include the DU configuration in the UE context response message at event 812, and IAB donor 108B can include the DU configuration in the RRC reconfiguration message at event 815.

[0182] In some implementations, IAB donor 108B sends a BS-CN interface message (e.g., NGAP message or GTP-U packet) including a UE context request message to CN 110 at step 807. CN 110 then sends a CN-BS interface message (e.g., NGAP message or GTP-U packet) including a UE context request message to IAB donor 108A at step 809. IAB donor 108A sends a BS-CN interface message (e.g., NGAP message or GTP-U packet) including a UE context response message to CN 110 at step 811. CN 110 then sends a CN-BS interface message (e.g., NGAP message or GTP-U packet) including a UE context response message to IAB donor 108A at step 813. In other implementations, IAB node 104 and IAB donor 108B exchange UE context request messages and UE context response messages via IAB donor 108A or CN 110 using a second TNLA as described above.

[0183] After IAB donor 108A receives the 817 RRC reconfiguration message, IAB donor 108A sends the 818 RRC reconfiguration message to IAB node 104, and IAB node 104 then forwards the 820 RRC reconfiguration message to UE 102.

[0184] In some implementations, if indicated by an RRC reconfiguration message, UE 102 can perform a random access procedure 822 with IAB node 104. In response to receiving an RRC reconfiguration message 820, UE 102 sends an RRC reconfiguration complete message 832 to IAB node 104, which in turn sends an RRC reconfiguration complete message 834 to IAB donor 108A. IAB donor 108A can then forward the RRC reconfiguration complete message 839 to CN 110, which in turn forwards the RRC reconfiguration complete message 841 to IAB donor 108B. In some implementations, IAB donor 108A sends a BS-CN interface message (e.g., an NGAP message) including the RRC reconfiguration complete message 839 to CN 110, which in turn sends a CN-BS interface message (e.g., an NGAP message or a GTP-U packet) including the RRC reconfiguration complete message 841 to IAB donor 108A. IAB node 104 generates an F1AP message (e.g., a UL RRC message delivery message) that includes an RRC reconfiguration completion message, and sends the F1AP message to IAB donor 108B as described above using a second TNLA.

[0185] In some implementations, after sending an 820RRC reconfiguration message, performing a random access procedure 822 with UE 102, or receiving a second RRC reconfiguration completion message 832, IAB node 104 can send an 824F1-C message or an F1-U frame to IAB donor 108A, which then forwards the 835F1-C message or F1-U frame to CN 110. CN 110 then forwards the F1-C message or F1-U frame 837 to IAB donor 108B. In some implementations, IAB donor 108A sends an 835 BS-CN interface message (e.g., an NGAP message or a GTP-U packet) including an F1-C message or F1-U frame to CN 110, which then sends an 837 CN-BS interface message (e.g., an NGAP message or a GTP-U packet) including an F1-C message or F1-U frame to IAB donor 108B. In other embodiments, IAB node 104, as described above, sends an F1-C message or an F1-U frame to IAB donor 108B via CN 110 or IAB donor 108A using a second TNLA.

[0186] In some implementations, after sending a handover request message (805), receiving a handover request confirmation message (817), or sending an RRC reconfiguration message (818), the IAB donor 108A can send an 825 SN status transmission message to the CN 110. If the DRB(s) use RLC confirmation mode, the CN 110 then forwards the SN status transmission message (827) to the IAB donor 108B to transmit the UL PDCP SN and HFN receiver status and the DL PDCP SN and HFN transmitter status of the DRB(s) of the UE 102. Alternatively, or in addition to sending the 825 SN status transmission message, the IAB donor 108A can perform a DL data forwarding (829) to the CN 110, and the CN 110 then performs a DL data forwarding (831) to the IAB donor 108B.

[0187] Events 803, 805, 807, 809, 810, 812, 811, 813, 815, 817, 818, 820, 822, 824, 835, 837, 832, 834, 839, 841, 825, 827, 829, and 831 can be collectively referred to as UE handover process 895.

[0188] During or after the UE handover process 895, IAB node 104 performs IAB node handover process 871, which is similar to IAB node handover process 671.

[0189] Now for reference Figure 9 Example method 900 can be implemented in the DU sending interface messages to the corresponding first CU and second CU. In some implementations, the DU is an IAB-DU (e.g., DU 174C), the first CU is a first IAB donor CU (e.g., IAB donor CU 172A), and the second CU is a second IAB donor CU (e.g., IAB donor CU 172B).

[0190] At block 902, the DU sends a first interface message to the first CU, causing the first CU to process the first interface message. In one embodiment, the first interface message (e.g., a first F1 establishment request message in events 508, 550, 650, 750, 850) causes the first CU to process the first interface message, enabling a first connection (e.g., an F1 connection) to be established between the DU and the first CU. In another embodiment, the first interface message is a message (e.g., an F1AP message) sent by the DU over the established first connection. In any of these embodiments, the first interface message can include a first ID associated with the first connection. For example, as described above... Figure 5AAs described, the first ID can identify the DU that initiated the establishment of the first connection, the cell(s) served by the DU, the RRC version supported by the DU, the TLA used by the DU, and / or the BAP address used by the DU. In some implementations, the first interface message can include the TLA of the first CU. As another example, the first ID can indicate that the recipient of the first interface message sent on the established first connection is the first CU.

[0191] At block 904, the DU sends a second interface message to the first CU, causing the first CU to determine that the second interface message is for the second CU (and forward the second interface message to the second CU). In one implementation, the second interface message (e.g., the second F1 establishment request message in events 516, 660, 661, 760, 761, 860, 861) causes the first CU to forward the second interface message to the second CU, enabling the establishment of a second connection (e.g., a second F1 connection) with the DU and the second CU via the first CU. In another implementation, the second interface message is a message sent by the DU over the established second connection (e.g., an F1AP message). In any of these implementations, the second interface message can include a second ID associated with the second connection. For example, similar to the first ID, the second ID can identify the DU that initiated the establishment of the second connection, the cell(s) served by the DU, the RRC version supported by the DU, the TLA used by the DU, and / or the BAP address used by the DU. In some implementations, the first interface message can include the TLA of the second CU. As another example, the second ID can indicate that the recipient of the second interface message sent through the established second connection is the second CU.

[0192] Now for reference Figure 10 Although the DU of method 900 sends an interface message with a specific ID to instruct the first CU to process the interface message or to forward the interface message to the second CU, the DU of method 1000 sends an interface message on a specific interface to instruct the first CU to process the interface message or to forward the interface message to the second CU.

[0193] exist Figure 10 In method 1000, the DU sends a first interface message to the first CU via a first interface at block 1002, causing the first CU to process the first interface message. In one embodiment, the first interface message may be a first F1 establishment request message sent on a first channel for carrying control plane (e.g., F1-C) services for establishing a first connection (e.g., a first F1 connection) with the DU. In another embodiment, the first interface message may be a message (e.g., an F1AP message) sent by the DU on the control plane (e.g., F1-C) portion of the established first connection. In any of these embodiments, as described above... Figure 9As described herein, the first interface message can include a first ID associated with the first connection.

[0194] At block 1004, the DU sends a second interface message to the first CU via the second interface, causing the first CU to determine that the second interface message is for the second CU (and forwards the second interface message to the second CU). In one embodiment, the second interface message may be a second F1 establishment request message sent on a second channel for carrying user plane (e.g., F1-U) services for establishing a second connection (e.g., a second F1 connection) with the DU via the first CU. In another embodiment, the second interface message may be a message (e.g., a UE context establishment request message) sent by the DU on the user plane (e.g., F1-U) portion of the established second connection. In any of these embodiments, as described above... Figure 9 As described herein, the second interface message can include a second ID associated with the second connection.

[0195] Now for reference Figure 11 Although the DU of method 900 sends an interface message with a specific ID to instruct the first CU to process the interface message or to forward the interface message to the second CU, the DU of method 1000 sends an interface message in a packet to instruct the first CU to process the interface message or to forward the interface message to the second CU.

[0196] Similar to method 900, in Figure 11 In method 1100, the DU sends a first interface message from a first packet to the first CU at block 1102, causing the first CU to process the first interface message. In some embodiments, the first packet may include the above-mentioned... Figure 9 The first GPRS packet with the first ID described in the text.

[0197] At box 1104, the DU sends a second interface message to the first CU in the second group, causing the first CU to determine that the second interface message is for the second CU (and forward the second interface message to the second CU). In some implementations, as described above... Figure 9 As described herein, the second packet can be a second GPRS packet that includes a second ID similar to the first ID.

[0198] Now for reference Figure 12 Example method 1200 can be implemented in a first CU to establish a second connection (e.g., a second F1 connection) between a DU and a second CU via the first CU. In some embodiments, the first CU is a first IAB donor CU (e.g., IAB donor CU 172A), the DU is an IAB-DU (e.g., DU 174C), and the second CU is a second IAB donor CU (e.g., IAB donor CU 172B).

[0199] At block 1202, the first CU receives an interface message from the DU (e.g., in events 516, 660, 661, 760, 761, 860, 861), causing the first CU to determine that the interface message is for the second CU. In some implementations, the interface message can be an F1 setup request message. The interface message can indicate or include the address / identifier of the second CU (e.g., IP address, transport network layer address, gNB identifier, gNB-CU identifier, TEID, or gNB-CU name), such that upon receiving the interface message, the first CU can determine that the recipient of the interface message is the second CU based on the address / identifier. In other implementations, the interface message does not need to have the address / identifier of the second CU. Instead, the first CU can generate a container message including the interface message to instruct that the recipient of the interface message is not the first CU, and if the second CU is the only adjacent CU to which the first CU is connected or can be connected, the first CU can determine that the second CU should be the appropriate recipient of the interface message and specify the container message accordingly.

[0200] In block 1204, in embodiments where a BS-to-BS interface exists between the first CU and the second CU, the first CU generates a BS-to-BS interface message that includes the interface message. In other embodiments where no BS-to-BS interface exists between the first CU and the second CU, the first CU omits generating the BS-to-BS interface message.

[0201] At block 1206, in an implementation where a BS-to-BS interface exists, the first CU sends a BS-to-BS interface message (e.g., 518, 660, 760, 860) to the second CU. In an implementation where a BS-to-BS interface does not exist, the first CU sends an interface message (e.g., 517, 661, 761, 861) to the second CU via a CN (e.g., CN 110).

[0202] Now for reference Figure 13 Example method 1300 can be implemented in a first CU to establish multiple corresponding connections (e.g., F1 connections) between the DU and the first CU, and between the DU and the second CU. In some implementations, the DU is an IAB-DU (e.g., DU 174C), the first CU is a first IAB donor CU (e.g., IAB donor CU 172A), and the second CU is a second IAB donor CU (e.g., IAB donor CU 172B).

[0203] At box 1302, similar to box 902, the first CU receives interface messages (e.g., F1 setup request messages) from the DU.

[0204] At box 1304, the first CU determines whether the interface message includes a first ID or a second ID. Typically, if the interface message includes a first ID, the first CU can determine that the interface message is for the first CU, or if the interface message includes a second ID, the first CU can determine that the interface message is for the second CU.

[0205] If, at box 1304, similar to box 902, the first CU determines that the interface message includes a first ID, then the first CU processes the interface message at box 1306 for use in establishing a first connection with the DU.

[0206] If, at box 1304, similar to box 904, the first CU determines that the interface message includes a second ID, then the first CU forwards the interface message to the second CU for establishing a second connection with the DU via the first CU. In some implementations, the first CU can forward the interface message to the second CU via a CN (e.g., CN 110), and the second CU can establish a second connection with the DU via the first CU and the CN.

[0207] Now for reference Figure 14 Although the first CU of method 1300 can determine whether the interface message is for the first CU or the second CU based on the ID included in the interface message, the first CU of method 1400 can determine whether the interface message is for the first CU or the second CU based on the interface through which it receives the interface message from the DU.

[0208] At box 1402, similar to boxes 1002 and 1004, the first CU receives interface messages (e.g., F1 setup request message, UE context setup request message) from the DU.

[0209] At box 1404, the first CU determines whether it receives the interface message through the F1-C interface or the F1-U interface.

[0210] If, at box 1404, similar to box 1002, the first CU determines that it has received an interface message (e.g., an F1 setup request message) through the F1-C interface, then the first CU processes the interface message at box 1406 for establishing a first connection with the DU.

[0211] If the first CU determines at block 1404 that it has received an interface message (e.g., a UE context establishment request message) through the F1-U interface, then the first CU forwards the interface message to the second CU at block 1408 for establishing a second connection with the DU via the first CU. In some implementations, the first CU can forward the interface message to the second CU via a CN (e.g., CN 110), and the second CU can establish a second connection with the DU via the first CU and the CN.

[0212] Now for reference Figure 15 Example method 1500 can be implemented in the first CU (e.g., IAB donor CU 172A) to determine whether to process the interface message received from the DU (e.g., DU 174C).

[0213] At box 1502, the first CU receives an interface message from the DU. In some implementations, the interface message is an F1 establishment request message. In other implementations, the interface message is a message initiated by the DU (e.g., a UE context modification request message, a UE context release request message).

[0214] Instead of responding to receiving an interface message or executing an interface procedure by default after receiving an interface message (e.g., F1 setup procedure, DU-initiated UE context modification procedure, DU-initiated UE context release request procedure), the first CU determines at block 1504 whether it should process the interface message.

[0215] If the first CU determines at block 1504 that it should not process the interface message, then the first CU, in response to receiving the interface message or after receiving the interface message, suppresses the execution of the interface procedure at block 1506. Conversely, similar to blocks 1308 and 1408, the first CU forwards the interface message to the second CU (e.g., IAB donor CU 172B), enabling the second CU to execute the interface procedure. Otherwise, similar to blocks 1306 and 1406, if the first CU determines at block 1504 that it should process the interface message, then the first CU, in response to receiving the interface message or after receiving the interface message, executes the interface procedure at block 1508.

[0216] Now for reference Figure 16 Example method 1600 can be implemented in a second CU to send a second interface message (e.g., a UE context request message) to a DU in response to receiving a first interface message (e.g., a UE context request message) from a DU. In some implementations, the second CU (e.g., IAB donor CU 172B) can receive the first interface message from a first DU (e.g., DU174C of IAB node 104) having a connection with the first CU (e.g., IAB donor CU 172A) and a second CU (e.g., corresponding first F1 connections and second F1 connections established at events 550, 560, 561, 650, 660, 661, 750, 760, 761, 850, 860, 861) or a second DU (e.g., a DU of an IAB node different from IAB node 104) having a connection with the second CU but not with the first CU (e.g., an F1 connection). Depending on how the second CU receives the first interface message, the second CU can appropriately provide the second interface message.

[0217] At frame 1602, the second CU receives the first interface message from the DU.

[0218] At block 1604, the second CU determines whether it received the first interface message via the first CU. If at block 1604, the second CU determines that it received the first interface message via the first CU, then the second CU knows that the DU is the first DU connected to the first CU. Therefore, the second CU sends the second interface message to the first DU at block 1606. Otherwise, if at block 1604, the second CU determines that it received the first interface message directly from the DU (i.e., not via the first CU), then the second CU knows that the DU cannot be the first DU described above; instead, the DU is the second DU not connected to the first CU. Therefore, the second CU sends the second interface message to the second DU at block 1608.

[0219] Now for reference Figure 17 Example method 1700 can be implemented in a second CU to send a second interface message (e.g., a UE context request message) to a DU in response to receiving a first interface message (e.g., a handover request message) from a first CU. In some embodiments, the DU is an IAB-DU (e.g., DU 174C), the first CU is a first IAB donor CU (e.g., IAB donor CU 172A), and the second CU is a second IAB donor CU (e.g., IAB donor CU 172B). The DU has connections with the first CU (e.g., IAB donor CU 172A) and via the first CU to the second CU (e.g., corresponding first and second F1 connections established in events 550, 560, 561, 650, 660, 661, 750, 760, 761, 850, 860, 861).

[0220] At block 1702, the second CU receives from the first CU a first interface message for switching the UE (e.g., UE 102) to a specific cell. In some implementations, the first interface message includes information indicating the specific cell.

[0221] At box 1704, the second CU determines the DU operating in the particular cell, and at box 1706, determines whether it has a UE connection to the DU.

[0222] If, at box 1706, the second CU determines that it has a radio connection with the DU (e.g., a radio connection established during the IAB-MT establishment process in event 502), then the second CU sends the UE's second interface message to the DU via the radio connection at box 1708. Otherwise, if, at box 1706, the second CU determines that it does not have a radio connection with the DU (i.e., a third F1 connection has not yet been established at event 676), then the second CU sends the second interface message to the DU via the BS-to-BS interface (e.g., the Xn interface) at box 1710.

[0223] Now for reference Figure 18 Example method 1800 can be implemented in a DU (e.g., DU174C) operating in a RAN (e.g., RAN 105) for establishing a connection (e.g., F1 connection) with a centralized unit (CU) (e.g., CU 172A, CU 172B) operating in the RAN.

[0224] At block 1802, the DU sends a first interface message (e.g., a first F1 setup request message) to a first CU (e.g., CU 172A) to establish a first connection between the DU and the first CU (e.g., in events 508, 550, 650, 750, 850). In some embodiments, the first interface message includes a first identifier associated with the first connection, such as the identifier of the DU where the first connection terminates. In some embodiments, the first interface message can be included in a first packet (e.g., a first GPRS packet), and the first identifier can be included in the first packet. In other embodiments, the DU sends the first interface message through a first channel used to carry control plane services.

[0225] At block 1804, the DU sends a second interface message (e.g., a second F1 setup request message) via a first CU to a second CU (e.g., CU 172B) to establish a second connection between the DU and the second CU via the first CU, thereby simultaneously maintaining the first and second connections (e.g., in events 516, 660, 661, 760, 761, 860, 861). In some embodiments, the second interface message includes a second identifier associated with the second connection, such as the identifier of the DU where the second connection terminates. In some embodiments, the second interface message can be included in a second packet (e.g., a second GPRS packet), and the second identifier can be included in the second packet. In other embodiments, the DU sends the second interface message via a second channel used for carrying user plane services.

[0226] Now for reference Figure 19Example method 1900 can be implemented in a CU (e.g., CU172A) operating in a RAN (e.g., RAN 105) for establishing a connection (e.g., F1 connection) with a DU (e.g., DU 174C) operating in the RAN.

[0227] At box 1902, similar to box 1802, the CU receives a first interface message from the DU to establish a first connection between the DU and the CU (e.g., in events 508, 550, 650, 750, 850).

[0228] At box 1904, similar to box 1804, the CU receives a second interface message from the DU to establish a second connection between the DU and a second CU (e.g., CU 172B) via the CU, so as to maintain the first connection and the second connection simultaneously (e.g., in events 516, 660, 661, 760, 761, 860, 861).

[0229] In block 1906, the CU determines that the second interface message is addressed to the second CU. In some embodiments, the CU determines that the second interface message is addressed to the second CU by determining that the second interface message includes the identifier of the second CU or otherwise addresses to the second CU. In other embodiments, the CU determines that the identifier of the CU is omitted from the second interface message, and therefore assumes that the second CU is the appropriate recipient of the second interface message. In other embodiments, the CU determines that it receives the second interface message through a channel used to carry user plane services rather than through a channel used to carry control plane services, and therefore assumes that the second CU is the appropriate recipient of the second interface message.

[0230] At box 1908, the CU sends a second interface message to the second CU to establish a second connection (e.g., in events 517, 518, 660, 661, 760, 761, 860, 861).

[0231] Now for reference Figure 20 Example method 2000 can be implemented in a CU (e.g., CU172B) operating in a RAN (e.g., RAN 105) for establishing a connection (e.g., F1 connection) with a DU (e.g., DU 174C) operating in the RAN.

[0232] At block 2002, the CU receives uplink interface messages (e.g., 518, 519, 660, 661, 760, 761, 860, 861) from the DU via a second CU (e.g., CU 172A). In some implementations, the uplink interface message is an F1 setup request message.

[0233] At block 2004, the CU sends a downlink interface message (e.g., an F1 establishment response message) to the DU via the second CU to establish a connection between the DU and the CU via the second CU (e.g., 521, 522, 660, 661, 760, 761, 860, 861). In some embodiments, the downlink interface message is an F1 establishment response message.

[0234] The following additional considerations apply to the foregoing discussion.

[0235] "TLA" and "TNLA" are interchangeable. "Connection", "Interface", and "Interface Connection" are interchangeable.

[0236] User equipment (e.g., UE 102) capable of implementing the technologies of this disclosure can be any suitable device capable of wireless communication, such as a smartphone, tablet computer, laptop computer, mobile game console, point-of-sale (POS) terminal, health monitoring device, drone, camera, media streaming dongle or other human media device, wearable device (such as a smartwatch, Wi-Fi hotspot, femtocell, or broadband router). Furthermore, in some cases, the user equipment can be embedded in electronic systems, such as a head unit in a vehicle or an advanced driver assistance system (ADAS). Additionally, the user equipment can operate as an Internet of Things (IoT) device or a mobile internet device (MID). Depending on the type, the user equipment can include one or more general-purpose processors, computer-readable storage, a user interface, one or more network interfaces, one or more sensors, etc.

[0237] Some embodiments described in this disclosure include logic or a plurality of components or modules. A module can be a software module (e.g., code stored on a non-transitory machine-readable medium) or a hardware module. A hardware module is a tangible unit capable of performing certain operations and can be configured or arranged in a certain manner. A hardware module can include dedicated circuitry or logic permanently configured to perform certain operations (e.g., as a dedicated processor, such as a field-programmable gate array (FPGA) or application-specific integrated circuit (ASIC)). A hardware module can also include programmable logic or circuitry temporarily configured by software to perform certain operations (e.g., contained within a general-purpose processor or other programmable processor). The decision to implement a hardware module in dedicated and permanently configured circuitry or in temporarily configured circuitry (e.g., configured by software) can be driven by cost and time considerations.

[0238] When implemented in software, these technologies can be provided as part of an operating system, as libraries used by multiple applications, or as specific software applications. The software can be executed by one or more general-purpose processors or one or more dedicated processors.

[0239] Upon reading this disclosure, those skilled in the art will understand additional alternative structural and functional designs for managing connections to multiple CUs using the principles disclosed herein. Therefore, while specific embodiments and applications have been shown and described, it will be understood that the disclosed embodiments are not limited to the precise constructions and components disclosed herein. Various modifications, alterations, and variations to the arrangement, operation, and details of the methods and apparatus disclosed herein are possible and will be apparent to those skilled in the art without departing from the spirit and scope defined in the appended claims.

[0240] Example 1. A method for establishing a connection in a distributed unit (DU) operating in a radio access network (RAN) with a centralized unit (CU) operating in the RAN, the method comprising: sending a first interface message from processing hardware to a first CU to establish a first connection between the DU and the first CU; and sending a second interface message from the processing hardware via the first CU to a second CU to establish a second connection between the DU and the second CU via the first CU, thereby simultaneously maintaining the first connection and the second connection.

[0241] Example 2, according to the method of Example 1, wherein: the first interface message includes a first identifier associated with the first connection, and the second interface message includes a second identifier associated with the second connection.

[0242] Example 3, according to the method of Example 1, wherein: sending the first interface message includes sending the first interface message on a first channel used to carry control plane services, and sending the second interface message includes sending the second interface message on a second channel used to carry user plane services.

[0243] Example 4: According to the method of Example 1, wherein: sending the first interface message includes sending the first interface message in the first group, and sending the second interface message includes sending the second interface message in the second group.

[0244] Example 5, according to the method of Example 4, wherein: the first group includes a first identifier associated with the first connection, and the second group includes a second identifier associated with the second connection.

[0245] Example 6, the method according to any one of Examples 1-5, further includes: receiving a third interface message from a first CU or an operation and maintenance (O&M) node operating in the RAN, wherein sending the second interface message includes sending the second interface in response to receiving the third interface message.

[0246] Example 7, the method according to any one of Examples 1-6, further includes: performing a handover from the DU to the second CU; releasing the first connection and the second connection after the handover; and sending a third interface message to the second CU via the radio interface between the network nodes of the DU and the second CU to establish a third connection with the second CU.

[0247] Example 8, according to the method of Example 7, further includes: sending a fourth interface message to the second CU to establish a fourth connection between the DU and the first CU via the second CU, thereby maintaining the third connection and the fourth connection simultaneously.

[0248] Example 9, according to any one of Examples 1-6, further includes: performing a switch from the DU to the second CU; retaining the first connection and the second connection after the switch.

[0249] Example 10, according to the method of Example 9, further includes: rerouting the first connection to be established between the DU and the second CU; and rerouting the second connection to be established between the DU and the first CU via the second CU.

[0250] Example 11: According to any of the methods in Examples 7-10, where switching to the second CU is an immediate switch.

[0251] Example 12: According to any of the methods in Examples 7-10, where switching to the second CU is a conditional switch.

[0252] Example 13, according to any one of Examples 1-6, wherein sending the second interface message includes: sending the second interface message to the second CU via the first CU and the core network (CN) to establish a second connection between the DU and the second CU via the first CU and the CN.

[0253] Example 14: According to the method of Example 8, a fourth interface message is sent to the second CU to establish a fourth connection between the DU and the first CU via the second CU and CN.

[0254] Example 15, according to the method of Example 10, wherein rerouting the second connection includes: rerouting the second connection to be established between the DU and the first CU via the second CU and CN.

[0255] Example 16: According to any of the methods in the preceding examples, where: the first connection is the first F1 connection, and the second connection is the second F1 connection.

[0256] Example 17: According to any of the methods in the preceding examples, wherein: the first interface message is a first F1 establishment request message, and the second interface message is a second F1 establishment request message or a UE context establishment request message.

[0257] Example 18: According to any one of Examples 1-16, wherein: the first interface message is a first UE context modification request message, and the second interface message is a second UE context modification request message.

[0258] Example 19: According to any one of Examples 1-16, wherein: the first interface message is a first UE context release request message, and the second interface message is a second UE context release request message.

[0259] Example 20: A DU including processing hardware and configured to implement any of the preceding examples.

[0260] Example 21: The DU according to Example 20, wherein the DU is in an Integrated Access Backhaul (IAB) node operating in the RAN.

[0261] Example 22. A method for establishing a connection between a CU operating in a RAN and a DU operating in the RAN, the method comprising: receiving a first interface message from the DU by processing hardware to establish a first connection between the DU and the CU; receiving a second interface message from the DU by processing hardware to establish a second connection between the DU and a second CU via the CU, thereby simultaneously maintaining the first connection and the second connection; determining by processing hardware that the second interface message is for the second CU; and sending the second interface message to the second CU by processing hardware to establish the second connection.

[0262] Example 23, according to the method of Example 22, wherein determining that the second interface message is for the second CU includes: determining that the second interface message includes the identifier of the second CU.

[0263] Example 24, according to the method of Example 22, wherein determining that the second interface message is for the second CU includes: determining that the second interface message addresses the second CU.

[0264] Example 25, according to the method of Example 22, wherein determining that the second interface message is for the second CU includes: determining that the second interface message omits the identifier of the CU.

[0265] Example 26, according to the method of Example 22, wherein determining that the second interface message is for the second CU includes: determining that the second interface message is received on a channel used to carry user plane services.

[0266] Example 27. According to any one of Examples 22-26, sending the second interface message includes: sending the second interface message to the second CU via the CU and CN to establish a second connection between the DU and the second CU via the CU and CN.

[0267] Example 28, according to any one of Examples 22-27, further includes: receiving a request for the context of the DU from the second CU via the second connection.

[0268] Example 29, according to the method of Example 27, further includes: configuring the sending of the DU to the second CU via the second connection.

[0269] Example 30: According to any of the methods in the preceding examples, where: the first connection is the first F1 connection, and the second connection is the second F1 connection.

[0270] Example 31: According to the method of any of the preceding examples, wherein: the first interface message is a first F1 establishment request message, and the second interface message is a second F1 establishment request message.

[0271] Example 32: According to any one of Examples 22-30, wherein: the first interface message is a first UE context modification request message, and the second interface message is a second UE context modification request message.

[0272] Example 33: According to any one of Examples 22-30, wherein: the first interface message is a first UE context release request message, and the second interface message is a second UE context release request message.

[0273] Example 34. According to the method of any of the preceding examples, wherein: DU is included in an IAB node operating in the RAN, CU is included in an IAB donor operating in the RAN, and a second CU is included in a second IAB donor operating in the RAN.

[0274] Example 35: A method for establishing a connection between a CU and a DU, the CU and the DU operating in a RAN, the method comprising: receiving an uplink interface message from the DU via a second CU by processing hardware; and sending a downlink interface message to the DU via the second CU by the processing hardware to establish a connection between the DU and the CU via the second CU.

[0275] Example 36, the method according to Example 35, further includes: receiving from the second CU by the processing hardware a handover request for switching the user equipment (UE) to a cell operated by the DU; determining the cell operated by the DU by the processing hardware; and sending a request for the context of the DU to the DU over the second connection by the processing hardware.

[0276] Example 37: A CU including processing hardware and configured to implement the methods of any of Examples 22 to 36.

[0277] Example 38: The CU of Example 37, wherein the CU operates to provide IAB functionality in the RAN.

Claims

1. A method for establishing simultaneous connections with a plurality of centralized units (CUs) operating in a radio access network (RAN) in an integrated access and backhaul (IAB) node, the method comprising: The gNB distributed unit function (IAB-DU) of the IAB node sends a first interface message to the first CU included in the first IAB donor to establish a first connection between the IAB-DU and the first CU; and The IAB-DU sends a second interface message to the second CU included in the second IAB donor via the first CU, so as to establish a second connection between the IAB-DU and the second CU via the first CU, thereby maintaining the first connection and the second connection simultaneously.

2. The method according to claim 1, wherein: The first interface message includes a first identifier associated with the first connection, and The second interface message includes a second identifier associated with the second connection.

3. The method according to any one of claims 1 to 2, wherein: Sending the first interface message includes sending the first interface message on a first channel used to carry control plane services, and Sending the second interface message includes sending the second interface message on the second channel used to carry user plane services.

4. The method according to any one of claims 1 to 2, wherein: Sending the first interface message includes sending the first interface message in the first group, and Sending a second interface message includes sending the second interface message in the second group.

5. The method according to claim 4, wherein: The first group includes a first identifier associated with the first connection, and The second group includes a second identifier associated with the second connection.

6. The method according to any one of claims 1 to 2, further comprising: Perform the switch from IAB-DU to the second CU; Release the first and second connections after the switch; as well as A third interface message is sent to the second CU via the radio interface between the IAB-DU and the network node of the second CU to establish a third connection with the second CU.

7. The method according to any one of claims 1 to 2, further comprising: Perform the switch from IAB-DU to the second CU; as well as The first and second connections are retained after the switch.

8. The method according to any one of claims 1-2, wherein, Sending the second interface message includes: sending the second interface message to the second CU via the CU and the core network CN, so as to establish a second connection between the IAB-DU and the second CU via the CU and CN.

9. The method according to any one of claims 1 to 2, wherein: The first interface message is either the first F1 establishment request message, the first UE context modification request message, or the first UE context release request message, and The second interface message is the second F1 establishment request message, the UE context establishment request message, the second UE context modification request message, or the second UE context release request message.

10. The method according to any one of claims 1 to 2, wherein: The first connection is the first F1 connection, and The second connection is the second F1 connection.

11. A gNB distributed unit integrating access and backhaul IAB nodes, comprising processing hardware and configured to implement the method according to any one of claims 1 to 10.

12. A method for establishing simultaneous connections between a gNB Distributed Unit Function (IAB-DU) of an IAB node and multiple CUs operating in a Radio Access Network (RAN) and an Integrated Access and Backhaul (IAB) donor, the method comprising: The CU receives the first interface message from the IAB-DU to establish the first connection between the IAB-DU and the CU; The CU receives a second interface message from the IAB-DU to establish a second connection between the IAB-DU and the second CU via the CU, thereby maintaining the first connection and the second connection simultaneously. The second CU includes a second IAB donor operating in the RAN. The CU determines that the second interface message is for the second CU; and The CU sends a second interface message to the second CU to establish a second connection.

13. The method according to claim 12, wherein, Determining that the second interface message is for the second CU includes one of the following: The second interface message is confirmed to include the identifier of the second CU; The second interface message is addressed to the second CU; It is confirmed that the CU identifier is omitted in the second interface message; or It is determined that the second interface message was received on a channel used to carry user plane services.

14. The method according to any one of claims 12 to 13, wherein, Sending the second interface message includes: sending the second interface message to the second CU via the CU and the core network CN, so as to establish a second connection between the IAB-DU and the second CU via the CU and CN.

15. The method according to any one of claims 12 to 13, wherein: The first interface message is either the first F1 establishment request message, the first UE context modification request message, or the first UE context release request message, and The second interface message is the second F1 establishment request message, the UE context establishment request message, the second UE context modification request message, or the second UE context release request message.

16. The method according to any one of claims 12 to 13, wherein: The first connection is the first F1 connection, and The second connection is the second F1 connection.

17. A method for establishing a connection with a centralized unit (CU) included in an integrated access and backhaul (IAB) donor operating in a radio access network (RAN) and the method comprising: The CU receives uplink interface messages from the IAB-DU via the second CU, and the second CU is included in the second IAB donor operating in the RAN; The CU sends a downlink interface message to the IAB-DU via the second CU to establish a connection between the IAB-DU and the CU; The CU receives a handover request from the second CU to hand over the user equipment (UE) to a cell operated by the IAB-DU; as well as The CU sends a request for the UE's context to the IAB-DU over the connection.

18. A CU, comprising processing hardware and configured to implement the method according to any one of claims 12 to 17.

Images