Delayed delivery of reconfiguration message in integrated access and backhaul (IAB) network

Abstract

One method of wireless communication using an Integrated Access and Backload Network (IAB) implementer transmits a configuration message to a first IAB node via a first distributed unit of the IAB implementer on a source path. The method also instructs the first IAB node to delay delivering the configuration message to a second node. The method then migrates at least a portion of the communication to the first IAB node from the source path to a destination path via a second distributed unit. Another method of wireless communication is performed by a first Integrated Access and Backload Network (IAB) node. This method receives a first configuration message on a source path to the first IAB implementer via a first distributed unit of the first IAB implementer. The method also delays delivering the first configuration message to a second node until a trigger occurs.

Description

[Technical Field]

[0001] This patent application claims the benefit of U.S. Provisional Patent Application No. 63 / 023,714, filed on May 12, 2020, entitled “DELAYED DELIVERY OF RECONFIGURATION MESSAGE IN INTEGRATED ACCESS AND BACKHAUL (IAB) NETWORK”, which is hereby expressly incorporated in its entirety by reference.

[0002] In general, the contents of this application relate to wireless communication, and more specifically, the contents of this application relate to techniques and apparatus for delayed delivery of reconfiguration information in integrated access and reload (IAB) networks. [Previous Technology]

[0003] Wireless communication systems are widely deployed to provide various telecommunications services such as telephone, video, data, messaging, and broadcasting. Typical wireless communication systems may employ multiplexing access technologies that support communication with multiple users by sharing available system resources (e.g., bandwidth, transmit power). Examples of such multiplexing access technologies include Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiple Access (OFDMA), Single Carrier Frequency Division Multiple Access (SC-FDMA), Time Division Synchronous Code Division Multiple Access (TD-SCDMA), and Long Term Evolution (LTE). LTE / LTE-Enhanced is an enhancement set of the Universal Mobile Telecommunications System (UMTS) mobile service standard released by the 3rd Generation Partnership Project (3GPP).

[0004] A wireless communication network may include multiple base stations (BSs) capable of supporting communication for multiple user equipments (UEs). User equipments (UEs) may communicate with base stations (BSs) via downlinks and uplinks. A downlink (or forward link) represents the communication link from the BS to the UE, while an uplink (or reverse link) represents the communication link from the UE to the BS. As will be described in more detail, a BS may be referred to as a Node B, gNB, Access Point (AP), Radio Headend, Transmit / Receive Point (TRP), New Radio (NR) BS, 5G Node B, etc.

[0005] The above multiplexing access technologies have been adopted in various telecommunications standards to provide a common protocol that enables different user equipment to communicate at the city, country, region, and even global levels. New Radio (NR) (which may also be referred to as 5G) is an enhancement set of the LTE mobile service standard released by the 3rd Generation Partnership Project (3GPP). NR is designed to better integrate with other open standards by improving spectrum efficiency, reducing costs, improving service, utilizing new spectrum, and using Orthogonal Frequency Division Multiplexing (OFDM) with Cyclic Prefix (CP) on the downlink (DL) and CP-OFDM and / or SC-FDM (e.g., also known as Discrete Fourier Transform Spread Spectrum OFDM (DFT-s-OFDM)) on the uplink (UL), thereby better supporting mobile broadband Internet access, and supporting beamforming, multiple-input multiple-output (MIMO) antenna technology and carrier aggregation. [Summary of the Invention]

[0006] The contents of this case are described in the independent claims section. Some aspects of the contents of this case are described in the dependent claims section.

[0007] According to one aspect of the present invention, a method for wireless communication using an Integrated Access and Backhaul (IAB) implementer transmits configuration messages on a source path having a first IAB node via a first distributed unit of the IAB implementer. The method also instructs the first IAB node to delay delivery of the configuration messages to a second node. The method then migrates at least a portion of the communication to the first IAB node from the source path to a destination path via a second distributed unit.

[0008] In another embodiment, a wireless communication method is performed by a first Integrated Access and Backhaul (IAB) network node. The method receives a first configuration message on a source path having the first IAB implement via a first distributed unit of the first IAB implement. The method also delays the delivery of the first configuration message to a second node until a trigger occurs, at which time the message is delivered.

[0009] In another embodiment of this case, an apparatus for wireless communication via an Integrated Access and Backload Network (IAB) implementer includes a processor and memory coupled to the processor. Instructions stored in the memory, when executed by the processor, are operable to cause the apparatus to transmit configuration messages on a source path having a first IAB node via a first distributed unit of the IAB implementer. The apparatus can also instruct the first IAB node to delay delivery of the configuration messages to a second node. The apparatus can also migrate at least a portion of communication to the first IAB node from the source path to a destination path via a second distributed unit.

[0010] In another embodiment of this case, an apparatus for wireless communication by a first Integrated Access and Backload Network (IAB) node includes a processor and memory coupled to the processor. Instructions stored in the memory, when executed by the processor, are operable to cause the apparatus to receive a first configuration message on a source path having the first IAB embodiment via a first distributed unit of the first IAB embodiment. The apparatus may also delay the delivery of the first configuration message to a second node. The apparatus may also respond to a trigger to deliver the first configuration message to the second node.

[0011] In another embodiment of this application, an Integrated Access and Backhaul (IAB) embodiment for wireless communication includes: a unit for transmitting configuration messages on a source path having a first IAB node via a first distributed unit of the IAB embodiment. The IAB embodiment also includes: a unit for instructing the first IAB node to delay delivering the configuration messages to a second node. The IAB embodiment also includes: a unit for migrating at least a portion of communication to the first IAB node from the source path to a destination path via a second distributed unit.

[0012] In another embodiment of this case, a first integrated access and backhaul network (IAB) node for wireless communication includes: a unit for receiving a first configuration message on a source path having the first IAB embodiment via a first distributed unit of the first IAB embodiment. The IAB node also includes: a unit for delaying the delivery of the first configuration message to a second node until a trigger occurs, at which time the message is delivered.

[0013] In another embodiment of the present invention, a non-transitory computer-readable medium having program code recorded thereon is disclosed. This program code is executed by an Integrated Access and Loading Network (IAB) implement and includes code for transmitting configuration messages on a source path having the first IAB node via a first distributed unit of the IAB implement. The IAB implement also includes code for instructing the first IAB node to delay delivery of the configuration messages to a second node. The IAB implement also includes code for migrating at least a portion of communication to the first IAB node from the source path to a destination path via a second distributed unit.

[0014] In another embodiment of the present invention, a non-transitory computer-readable medium having program code recorded thereon is disclosed. This program code is executed by a first Integrated Access and Loading Network (IAB) node and includes program code for receiving a first configuration message on a source path having the first IAB implementation via a first distributed unit of the first IAB implementation. The IAB node also includes program code for delaying the delivery of the first configuration message to a second node until a trigger occurs, at which time the message is delivered.

[0015] In general, the various types include methods, apparatus, systems, computer program products, non-transitory computer-readable media, user equipment, base stations, wireless communication devices and processing systems as fully described with reference to the accompanying drawings and description and shown by way of the accompanying drawings and description.

[0016] The foregoing has provided a fairly broad overview of the features and technical advantages of examples based on the content of this application, in order to better understand the following detailed description. Additional features and advantages will be described below. The disclosed concepts and specific examples can be readily used as the basis for modifying or designing other structures for achieving the same purpose as the content of this application. Such equivalent constructions do not depart from the scope of the appended claims. The characteristics of the disclosed concepts (both their organization and operation) and the associated advantages will be better understood when considered in conjunction with the accompanying drawings, based on the following description. Each of the accompanying drawings is provided for illustrative and descriptive purposes and is not intended to define any limitation on the claims.

Implementation Method

[0017] Various aspects of the present invention are described more fully below with reference to the accompanying drawings. However, the present invention may be embodied in many different forms and should not be construed as limited to any particular structure or function presented throughout the present invention. Rather, these aspects are provided so that the present invention will be thorough and complete, and will fully convey the scope of the present invention to those skilled in the art to which it pertains. Based on the teachings, those skilled in the art to which the present invention pertains should understand that the scope of the present invention is intended to cover any aspect of the present invention, whether implemented independently of any other aspect of the present invention or in combination with any other aspect. For example, an apparatus or a method may be implemented using any number of aspects set forth herein. Furthermore, the scope of the present invention is intended to cover such apparatuses or methods implemented using structures, functions, or structures and functions other than or different from the various aspects of the present invention set forth herein. It should be understood that any aspect of the disclosed present invention may be embodied by one or more elements of the claim.

[0018] Various devices and techniques will now be used to provide several embodiments of a telecommunications system. These devices and techniques will be described in detail below and illustrated in the accompanying drawings, in the form of various blocks, modules, components, circuits, steps, programs, algorithms, etc. (collectively referred to as "elements"). These elements can be implemented using hardware, software, or a combination thereof. Whether such elements are implemented as hardware or software depends on the specific application and the design constraints imposed on the entire system.

[0019] It should be noted that although the various forms may be described using terms commonly associated with 5G and later wireless technologies, the various forms of the content of this case can be applied to communication systems based on other generations (such as and including 3G and / or 4G technologies).

[0020] 5G New Radio (NR) deployments can utilize high frequencies, such as millimeter waves. While high frequencies are promising compared to low frequencies due to their greater bandwidth, they also have shorter ranges compared to lower frequencies. Therefore, denser base station deployments are specified for high frequencies. Fiber optic backhaul links between base stations are expensive, and denser base station deployments will significantly increase costs. Therefore, utilizing radio links to replace backhaul links is an attractive solution to address the economics of denser base station deployments. Integrating Access and Backhaul (IAB) networks provides a solution that includes radio resources for a portion of the backhaul network.

[0021] In topology adaptation, migrating IAB nodes to different donor distributed units (DUs) triggers a secure handover of descendant nodes. For example, migration may be to address signal quality degradation (e.g., radio link failure), in response to the movement of migrating IAB nodes to a new area, or for load balancing purposes. In general approaches, secure handovers occur sequentially, which slows down the topology adaptation process and leads to dropped packets and reduced performance.

[0022] According to the various forms of the present case, the Central Unit (CU) instructs the IAB node DU to delay the delivery of Radio Resource Control (RRC) reconfiguration messages. This delay allows configuration messages to be sent to the IAB node on the source path rather than the destination path. This delay allows for concurrent secure handshakes on the destination path.

[0023] Figure 1 is a diagram illustrating various forms of network 100 in which the contents of this invention may be implemented. Network 100 may be a 5G or NR network or some other wireless network (such as an LTE network). Wireless network 100 may include multiple BS 110s (shown as BS 110a, BS 110b, BS 110c and BS 110d) and other network entities. A BS is an entity that communicates with a user equipment (UE) and may also be referred to as a base station, NR BS, Node B, gNB, 5G Node B (NB), access point, Transmit / Receive Point (TRP), etc. Each BS can provide communication coverage for a specific geographic area. In 3GPP, the term "cell" may represent the coverage area of ​​a BS and / or the BS subsystem serving that coverage area, depending on the context in which the term is used.

[0024] A BS can provide communication coverage for macrocells, picocells, femtocells, and / or another type of cell. A macrocell can cover a relatively large geographic area (e.g., a radius of several kilometers) and can allow unrestricted access by UEs with service subscriptions. A picocell can cover a relatively small geographic area and can allow unrestricted access by UEs with service subscriptions. A femtocell can cover a relatively small geographic area (e.g., a residential area) and can allow restricted access by UEs associated with that femtocell (e.g., UEs in a closed user group (CSG)). A BS for macrocells can be referred to as a macro BS. A BS for picocells can be referred to as a pico BS. A BS for femtocells can be referred to as a femto BS or a home BS. In the example shown in Figure 1, BS 110a can be a macro BS for macrocell 102a, BS 110b can be a pico BS for picocell 102b, and BS 110c can be a femto BS for femtocell 102c. A BS can support one or more (e.g., three) cells. The terms "eNB", "base station", "NR BS", "gNB", "TRP", "AP", "node B", "5G NB" and "cell" are used interchangeably.

[0025] In some states, the cell may not be stationary, and the geographical area of ​​the cell may move depending on the location of the active BS. In some states, the BS may be interconnected with each other and / or with one or more other BSs or network nodes (not shown) in the wireless network 100 via various types of backhaul interfaces (e.g., direct physical connection, virtual network, and / or similar interfaces using any suitable transport network).

[0026] The wireless network 100 may also include a relay station. A relay station is an entity that can receive data transmissions from an upstream station (e.g., a BS or a UE) and send data transmissions to a downstream station (e.g., a UE or a BS). A relay station may also be a UE capable of relaying transmissions for other UEs. In the example shown in Figure 1, relay station 110d can communicate with macro BS 110a and UE 120d to facilitate communication between BS 110a and UE 120d. A relay station may also be referred to as a relay BS, relay base station, repeater, etc.

[0027] Wireless network 100 can be a heterogeneous network comprising different types of BSs (e.g., macro BS, pico BS, femto BS, repeater BS, etc.). These different types of BSs can have different transmit power levels, different coverage areas, and different effects on interference in wireless network 100. For example, macro BSs can have high transmit power levels (e.g., 5 to 40 watts), while pico BSs, femto BSs, and repeater BSs can have lower transmit power levels (e.g., 0.1 to 2 watts).

[0028] The network controller 130 can be coupled to a group of BSs and can provide coordination and control for these BSs. The network controller 130 can communicate with the BSs via backhaul. The BSs can also communicate with each other directly or indirectly, for example, via wireless or wired backhaul.

[0029] UE 120 (e.g., 120a, 120b, 120c) may be distributed throughout the wireless network 100, and each UE may be stationary or mobile. UE may also be referred to as an access terminal, terminal, mobile station, user unit, station, etc. UE may be a cellular telephone (e.g., a smartphone), personal digital assistant (PDA), wireless modem, wireless communication device, handheld device, laptop, wireless telephone, wireless loop (WLL) station, tablet device, camera, gaming device, laptop, smart computer, ultrabook, medical device or apparatus, biometric sensor / device, wearable device (smartwatch, smart clothing, smart glasses, smart wristband, smart jewelry (e.g., smart ring, smart bracelet, etc.)), entertainment device (e.g., music or video device, or satellite radio unit, etc.), vehicle component or sensor, smart instrument / sensor, industrial manufacturing equipment, GPS device, or any other suitable device configured to communicate via wireless or wired media.

[0030] Some UEs can be considered Machine-Type Communication (MTC) or Evolved or Enhanced Machine-Type Communication (eMTC) UEs. MTC and eMTC UEs include, for example, robots, drones, remote devices, sensors, meters, monitors, location tags, etc., which can communicate with a base station, another device (e.g., a remote device), or some other entity. Wireless nodes can provide connectivity to or to a network (e.g., a wide area network such as the Internet or cellular networks) via wired or wireless communication links, for example. Some UEs can be considered Internet of Things (IoT) devices and / or can be implemented as NB-IoT (Narrowband Internet of Things) devices. Some UEs can be considered Customer Premises Equipment (CPE). UE 120 can be included within a housing that houses the components of UE 120 (such as processor components, memory components, etc.).

[0031] Typically, any number of wireless networks can be deployed in a given geographical area. Each wireless network can support a specific RAT and can operate on one or more frequencies. RAT can also be referred to as radio technology, air interface, etc. Frequency can also be referred to as carrier, channel, etc. Each frequency can support a single RAT in a given geographical area to avoid interference between wireless networks of different RATs. In some cases, NR or 5G RAT networks can be deployed.

[0032] In some configurations, two or more UEs 120 (e.g., shown as UE 120a and UE 120e) may communicate directly using one or more sidelink channels (e.g., without using base station 110 as an intermediary for communication with each other). For example, UE 120 may communicate using peer-to-peer (P2P) communication, device-to-device (D2D) communication, vehicle-to-everything (V2X) protocols (e.g., which may include vehicle-to-vehicle (V2V) protocols, vehicle-to-infrastructure (V2I) protocols, mesh networks, etc.). In this case, UE 120 may perform scheduling operations, resource selection operations, and / or other operations described elsewhere as being performed by base station 110. For example, base station 110 can configure UE 120 via downlink control information (DCI), radio resource control (RRC) signal transmission, media access control-control element (MAC-CE) or via system information (e.g., system information block (SIB)).

[0033] As noted above, Figure 1 is provided as an example. Other examples may differ from those described with respect to Figure 1.

[0034] Figure 2 illustrates a block diagram of the design 200 of base station 110 and UE 120 (which may be one of the base stations in Figure 1 and one of the UEs). Base station 110 may be equipped with T antennas 234a to 234t, and UE 120 may be equipped with R antennas 252a to 252r, wherein generally, T ≧ 1 and R ≧ 1.

[0035] At base station 110, transmitting processor 220 can receive data for one or more UEs from data source 212, select one or more modulation and coding schemes (MCS) for each UE based at least in part on the Channel Quality Indicator (CQI) received from each UE, process (e.g., encode and modulate) the data for each UE based at least in part on the MCS selected for each UE, and provide data symbols for all UEs. Reducing the number of MCSs decreases the throughput but improves the reliability of transmission. Transmitting processor 220 can also process system information (e.g., semi-static resource partitioning information (SRPI) etc.) and control information (e.g., CQI requests, authorizations, upper-layer signaling, etc.), and provide management burden symbols and control symbols. Transmitting processor 220 can also generate reference symbols for reference signals (e.g., cell-specific reference signals (CRS)) and synchronization signals (e.g., primary synchronization signal (PSS) and secondary synchronization signal (SSS)). The transmit (TX) multiple-input multiple-output (MIMO) processor 230 can perform spatial processing (e.g., precoding, if applicable) on data symbols, control symbols, management burden symbols, and / or reference symbols, and can provide T output symbol streams to T modulators (MODs) 232a to 232t. Each modulator 232 can (e.g., for OFDM, etc.) process its corresponding output symbol stream to obtain an output sample stream. Each modulator 232 can further process (e.g., convert to analog, amplify, filter, and upconvert) the output sample stream to obtain a downlink signal. The T downlink signals from modulators 232a to 232t can be transmitted via T antennas 234a to 234t respectively. According to the various states described in more detail below, position coding can be used to generate synchronization signals to transmit additional information.

[0036] At UE 120, antennas 252a to 252r can receive downlink signals from base station 110 and / or other base stations, and can provide the received signals to demodulators (DEMODs) 254a to 254r respectively. Each demodulator 254 can adjust (e.g., filter, amplify, downconvert, and digitize) the received signal to obtain an input sample. Each demodulator 254 can further process the input sample (e.g., for OFDM, etc.) to obtain received symbols. MIMO detector 256 can obtain received symbols from all R demodulators 254a to 254r, perform MIMO detection on the received symbols (if applicable), and provide the detected symbols. Receiver processor 258 can process (e.g., demodulate and decode) the detected symbols, provide decoded data for UE 120 to data slot 260, and provide decoded control information and system information to controller / processor 280. The channel processor can determine the Reference Received Power (RSRP), Received Signal Strength Indicator (RSSI), Reference Received Quality (RSRQ), Channel Quality Indicator (CQI), etc. In some configurations, one or more components of the UE 120 may be included in the housing.

[0037] On the uplink, at UE 120, the transmitting processor 264 can receive and process data from data source 262 and control information from controller / processor 280 (e.g., for reports including RSRP, RSSI, RSRQ, CQI, etc.). The transmitting processor 264 can also generate reference symbols for one or more reference signals. The symbols from the transmitting processor 264 can be pre-encoded (if applicable) by the TX MIMO processor 266, further processed by modulators 254a to 254r (e.g., for DFT-s-OFDM, CP-OFDM, etc.), and transmitted to base station 110. At base station 110, uplink signals from UE 120 and other UEs can be received by antenna 234, processed by demodulator 254, detected by MIMO detector 236 (if applicable), and further processed by receiving processor 238 to obtain decoded data and control information transmitted by UE 120. The receiver processor 238 can provide decoded data to the data slot 239 and decoded control information to the controller / processor 240. The scheduler 246 can schedule data transmissions for the UE on the downlink and / or uplink. The base station 110 may include a communication unit 244 and communicates with the network controller 130 via the communication unit 244. The network controller 130 may include a communication unit 294, a controller / processor 290, and memory 292.

[0038] The controller / processor 240 of base station 110, the controller / processor 280 of UE 120, and / or any other component in FIG. 2 may execute one or more techniques associated with delayed message delivery, as described in more detail elsewhere herein. For example, the controller / processor 240 of base station 110, the controller / processor 280 of UE 120, and / or any other component in FIG. 2 may execute or direct the operation of programs such as those in FIG. 10-12 and / or other programs as described. Memory 242 and 282 may store data and program code for base station 110 and UE 120, respectively.

[0039] In some configurations, the network controller 130 may include units for receiving, transmitting, indicating, migrating, executing, configuring, delaying, delivering, detecting, initiating, and participating. Such units may include one or more components of the network controller 130 described in conjunction with FIG2.

[0040] As noted above, Figure 2 is provided only as an example. Other examples may differ from those described with respect to Figure 2.

[0041] 5G New Radio (NR) deployments can utilize high frequencies, such as millimeter waves. While high frequencies are promising compared to low frequencies due to their greater bandwidth, they also have shorter ranges compared to lower frequencies. Therefore, denser base station deployments are specified for high frequencies. Fiber optic backhaul links between base stations are expensive, and denser base station deployments will significantly increase costs. Therefore, utilizing radio links to replace backhaul links is an attractive solution to address the economics of denser base station deployments. Integrating Access and Backhaul (IAB) networks provides a solution that includes radio resources for a portion of the backhaul network.

[0042] 5G NR technology (such as millimeter wave (mm wave)) can support access networks between access nodes (ANs, e.g., base stations) and UEs, as well as backhaul networks between ANs. Figure 3 is a block diagram illustrating various forms of Integrated Access and Backhaul (IAB) networks 300 according to the present invention. An Integrated Access and Backhaul (IAB) implementer (e.g., 304) is an access node having a wired connection to a core network 302. An IAB node (e.g., 308) is an access node that relays traffic to and from the implementer via one or more hops. A UE (e.g., 306a-f) can communicate with an IAB node via an access link or with an IAB implementer via an access link. The IAB network shares resources between the access network and the backhaul network. In the IAB network, it is desirable to reuse the framework used for the access network as much as possible.

[0043] Figure 4 is a block diagram 400 showing a more detailed view of the Integrated Access and Backhaul (IAB) network shown in Figure 3 according to various embodiments of the present invention. An IAB implementer (e.g., 304) is an enhanced gNB node with the function of controlling the IAB network. A Central Unit (CU) is a central entity that controls the entire IAB network via the configuration of the IAB implementer (e.g., 304) and IAB nodes (e.g., 408a-d). The CU performs Radio Resource Control (RRC) / Packet Data Convergence Protocol (PDCP) layer functions. Distributed Units (DUs) of the IAB implementer (e.g., 304) or IAB nodes (e.g., 408a-d) are scheduling units that schedule the child nodes (e.g., 408a-d) of the IAB implementer (e.g., 304) or IAB nodes (e.g., 408a-d), respectively. DU handles Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY) layer functions.

[0044] An IAB node (e.g., 408a) is a Layer 2 (L2) relay node that includes mobile terminal (MT) and DU functions. An MT unit is a scheduled unit similar to a user equipment (UE) scheduled by its parent IAB node or IAB grant 304. A DU of an IAB node (e.g., 304) is a scheduled unit of a child node of the scheduled IAB node.

[0045] Figure 5 is a timing diagram 500 illustrating various types of user equipment (UE) base station handover according to the content of this case. Figure 5 illustrates a simplified UE base station handover from a source base station (currently serving the UE) to a target base station (as the new serving base station). At time 501, the source base station (e.g., source gNB 515) initiates a handover and sends a handover request to the target gNB 520 on the Xn interface. At time 502, the target gNB 520 performs permission control. For example, the target gNB 520 determines whether there are sufficient resources available to serve the UE 510. If so, at time 503, the target gNB 520 provides the source gNB 515 with a new RRC configuration as part of the handover request confirmation message.

[0046] At time 504, the source gNB 515 provides RRC configuration to the UE 510 by forwarding the RRCReconfiguration message received in the handover request confirmation message. At time 505, the UE 510 moves the RRC connection to the target gNB 520 (e.g., via performing a random access procedure with the target gNB), and at time 506, replies to the target gNB 520 using the RRCReconfigurationComplete message. At time 507, the target gNB 520 sends a UE context release message to the UE 510 to notify the source gNB 515 of the successful handover. Therefore, the source gNB 515 can release the resources allocated to the UE 510.

[0047] Figure 6 is a block diagram 600 illustrating the delay specifications for various forms of Radio Resource Control (RRC) procedures according to the present invention. For an RRC procedure, the UE (e.g., 306c shown in Figure 3) receives an RRC downlink (DL) command at time 601. At time 602, the UE receives an uplink grant for a transmission that will respond to an RRC uplink (UL) response occurring at time 603. According to the 3GPP standard, for RRC reconfiguration, the time from receiving the RRC downlink (DL) command at the UE entity layer to when the UE should be ready to receive an uplink grant for a response to a network message is limited to 10 ms. This delay may also include time for Transmission Time Interval (TTI) alignment.

[0048] When the UE receives an RRC message indicating a handover, the UE will be prepared to begin transmission of a new uplink Entity Random Access Channel (PRACH) within the Dhandover period starting from the end of the last TTI containing the RRC command. The time Dhandover can be defined as: Dhandover = RRC procedure delay + interruption time (Tinterrupt) Tinterrupt = Tsearch + TIU + Tprocessing + T∆ + Tmargin ms, where Tsearch is the time specified for searching for the target cell, Tprocessing is the time for UE processing, Tmargin is the time for post-processing of the Synchronization Signal Block (SSB), T∆ is the time for fine-tuning tracking and acquiring full timing information of the target cell, and TIU is the interruption uncertainty of acquiring the first available PRACH opportunity in the new cell.

[0049] Figure 7 is a block diagram 700 showing the migration within the central unit (CU) via switching according to various states according to the present invention. Figure 8 is a timing diagram 800 showing the migration within the central unit (CU) via switching according to various states according to the present invention.

[0050] In some embodiments of this case, the examples shown in Figures 7 and 8 may refer to topology adaptation, in which an IAB node 706a (more specifically, its MT functional unit) migrates from a source parent node to a target parent node (in a manner similar to the handover procedure for a UE described with reference to Figure 5). In the example shown in Figure 7, the source parent node 704a and the target parent node 704b are the same distributed units D-DU 1 and D-DU 2 of the IAB grant 704 shown in Figure 8. Communication via source D-DU 1 occurs on the source path as shown in Figure 7, while communication via target D-DU 2 occurs on the target path. Figures 7 and 8 illustrate examples of the migration of an IAB node 706a that is directly connected to a distributed unit of the IAB grant 704. In some instances, the migrating IAB node may be a child IAB node of another (parent) IAB node that is then directly or indirectly connected to a distributed unit D-DU 1 of the IAB grant 704. The migration of a child IAB node may then involve migrating (connecting) the MT functional unit of the child IAB node from the source parent IAB node to a target parent IAB node, which is directly or indirectly connected to different distributed units D-DU 2 of the IAB grantor 704. In other words, migrating an IAB node may involve reconnecting / switching the MT functional unit of the IAB node directly or indirectly (i.e., via one or more intermediate IAB nodes) to different DUs of the IAB grantor 704.

[0051] Referring to Figures 7 and 8, as can be seen at time 71, IAB grantor 704 initiates a reconfiguration process by sending an RRC reconfiguration message to the migrating IAB node 706a. The RRC reconfiguration message for the IAB node MT carries the new IP address for the migrating IAB node 706a. The IP information of the IAB node used by the DU of the grantor DU can be deduced from the IP header owned by the grantor DU, making it possible to route traffic to / from the IAB node via the grantor DU. Therefore, if the grantor DU changes, as shown in Figure 7, the IP information used for the IAB node must be changed. Similarly, if the IAB node is connected to multiple grantor DUs, corresponding IP information will be assigned to each grantor DU.

[0052] As shown in Figure 7, IAB node 706a migrates from donor distributed unit (D-DU) 1 704a to D-DU 2 704b. Therefore, in this example, the IP address for D-DU 2 704b is provided via an RRC reconfiguration message from IAB donor CU 704c. The RRC reconfiguration may also include an uplink (UL) mapping, indicating the channel used for communication with D-DU 2 704b. At time 71, the initial communication from the IAB donor (e.g., 704a) to the migrated IAB node (e.g., 706a) is via the source path. After synchronization, a response (e.g., a complete RRC reconfiguration message) traverses the target path (also shown at time 71). Note that the switchover may take some time. Therefore, time 71 refers to this time period.

[0053] In response to receiving a new IP address in the RRC reconfiguration message, at time 72, a secure handshake (e.g., Internet Key Exchange (IKE) handshake) occurs between the IAB grantor (e.g., via the target DU 704b) and the migrating IAB node (e.g., 706a). More specifically, the IAB node (e.g., 706a) DU establishes a secure association on the target path.

[0054] Instance child IAB nodes (e.g., 706b) may also be affected by migrating IAB nodes (e.g., 706a), and therefore, the new path generated by the migrating IAB node (e.g., 706a) should be known. Therefore, at time 73, the RRC reconfiguration procedure with the child IAB node (e.g., 706b) occurs. More specifically, the reconfiguration procedure with the child IAB node (e.g., 706b) MT on the target path occurs. In general systems and methods, a secure handshake (e.g., IKE handshake) at the parent IAB node (e.g., 706a) DU occurs before the RRC reconfiguration procedure with the child IAB node (e.g., 706b), as shown in Figures 7 and 8. Therefore, the secure handshakes with the migration and child IAB nodes (e.g., 706b) occur sequentially on the jump. As can be seen in Figure 8, the secure handshake with the child IAB node 706b occurs at time 74, which is after the secure handshake with the migrating IAB node 706a at time 72. Therefore, in the general approach, if a migration occurs (e.g., between time 72 and time 73) when a sub-IAB node (e.g., 706b) or UE 708 attempts to communicate with the IAB grant CU (e.g., 704c) via an IP address anchored at target D-DU 2 (e.g., 704b), packets configured for communication via D-DU 1 (e.g., 704a) are discarded for security reasons.

[0055] According to various aspects of this case, the delayed delivery of the RRC reconfiguration message indicates (or may be considered) the availability of the target path to the child IAB node. By delaying the delivery of the reconfiguration message to the child IAB node, the application of the security protocol can be delayed. Therefore, the security handshake occurs concurrently on the hop. Therefore, dropped packets can be reduced. In another aspect, a timer is configured to account for delayed delivery.

[0056] Figure 9 is a block diagram 900 illustrating migration within a central unit (CU) with delayed delivery for various states according to the present invention. Figure 10 is a timing diagram 1000 illustrating migration within a central unit (CU) with delayed delivery for various states according to the present invention. A first IAB grant (e.g., 904) having a first signal transmission connection to a migration IAB node (e.g., first IAB node 906a) (e.g., via source D-DU 1 904a) and a second signal transmission connection to a child IAB node (e.g., second IAB node 906b) (e.g., via source D-DU 1 904a) (and in some states, the first IAB grant CU 904c) sends configuration messages to the child IAB node (e.g., 906b) via the first IAB node (e.g., 906a) on a first path. The first signaling connection can be a connection from IAB grantor CU 904c (via source D-DU 1 904a) to the MT functional unit of the migrating IAB node 906a. The second signaling connection can be a connection from IAB grantor CU 904c (via source D-DU 1 904a) directly (e.g., without passing through intermediate IAB nodes) to the MT functional unit of the child IAB node 906b. To this end, at time 91, the IAB grantor (e.g., 904) sends a configuration message to the migrating IAB node (also referred to as the first IAB node) and instructs the migrating IAB node (e.g., 906a) on the first signaling connection (on the source path) to postpone delivering the configuration message to the child IAB node (e.g., 906b). The first IAB grantor CU (e.g., 904c) may, based on (or in some cases until received) the first Backhaul Adaptation Protocol (BAP) address, BAP route ID, Backhaul (BH) RLC channel ID, or Logical Channel ID (LCID), instruct the migration IAB node (e.g., 906a) to postpone the delivery (or, in the case of a grandchild node or a further removed node) of the configuration message.

[0057] Migrating an IAB node (e.g., 906a) can retain configuration information until a release message is triggered at time 93. The first signaling connection can span either an F1-C or RRC interface. The second signaling connection can also span either an F1-C or RRC interface.

[0058] At time 92, before releasing the configuration message to the child IAB node (e.g., 906b), the IAB provider (904a) begins a reconfiguration procedure to synchronize with the migrating IAB node (e.g., 906a). After releasing the configuration message to the child IAB node (e.g., 906b) at time 93, at time 94, the migrating IAB node (e.g., 906a) completes the reconfiguration procedure with the IAB provider (e.g., 904b) by sending an RRC reconfiguration completion message to the IAB provider CU 904c via the target path (e.g., via D-DU 2 904b). Although not illustrated in Figure 10, it should be noted that the sending of the RRC reconfiguration completion message may occur before time 93. For example, upon successful handover, the reconfiguration message may be forwarded to the child IAB node (e.g., 906b) or UE 908.

[0059] Due to the delay, the IAB grantor (e.g., 904b) and the migrating IAB node (e.g., 906a) can perform a secure handshake at time 95, which can occur concurrently with the secure handshake between the IAB grantor (e.g., 904b) and the child IAB node (e.g., 906b) at time 96. It should be noted that the two handshakes are not time-dependent; therefore, the secure handshakes can occur concurrently. After the secure handshake, at time 97, the child IAB node (e.g., 906b) sends an RRC reconfiguration complete message to the IAB grantor (e.g., 904). Although not illustrated in Figure 10, the RRC reconfiguration complete message can be sent between time 95 and time 96.

[0060] It is worth noting that, as described with reference to FIG10, the reconfiguration message has already been delivered to the parent (migration node) at time 91 using the F1 connection on the source path. Therefore, forwarding the reconfiguration message to the child IAB node (e.g., 906b) at time 93 does not depend on re-establishing F1 on the target path (e.g., the forwarding of the reconfiguration message does not depend on the security handshake between the IAB grantor (e.g., 904b) and the migration IAB node at time 95, which is performed to redirect the F1 to the target path). Furthermore, releasing the configuration message to the child IAB node (e.g., 906b) at time 93 and the security handshake at time 94 are also independent, as they correspond to the configurations of different nodes (e.g., the child IAB node (e.g., 906b) and the migration IAB node (e.g., 906a)). Therefore, according to the various aspects of this case, there is no restriction on the order in which procedures are executed at times 93, 94, or 95.

[0061] In one instance, a secure handshake at time 95 can be initiated before the procedure of releasing configuration messages to the child IAB node (e.g., 906b) at time 93 is executed. However, there is no restriction that the secure handshake between the IAB grantor (e.g., 904b) and the child IAB node (e.g., 906b) at time 96 occurs after the secure handshake between the IAB grantor (e.g., 904b) and the migrating IAB node (e.g., 906a) at time 95. For example, migrating the IAB node (e.g., 906a) could be ten hops from the IAB grantor (e.g., 904b). Therefore, if a secure handshake has already begun at time 95, a two-way secure handshake at time 95 may take some time to complete. Therefore, the procedure of releasing configuration messages to the child IAB node (e.g., 906b) at time 93 can occur and trigger a secure handshake between the IAB grantor (e.g., 904b) and the child IAB node (e.g., 906b) at time 96. The two safety handshakes at time 95 and time 96 can continue independently until completion.

[0062] In contrast, in Figure 8, in order to deliver the reconfiguration message at time 73, F1 must establish and operate towards the parent (migrating node). This also means that the secure handshake between the IAB grant (e.g., via target DU 704b) and the migrating IAB node (e.g., 706a) at time 72 occurs before the procedure at time 73, because F1 performs over Internet Protocol Security (IPSec). Therefore, the reconfiguration procedure at the child IAB node (e.g., 706b) at time 73 depends on the secure handshake between the IAB grant (704b) and the migrating IAB node (706a) at time 72. Therefore, the secure handshake with the child IAB node 706b at time 74 (which uses the new configuration provided at time 73) also depends on the secure handshake at time 72. Therefore, the procedures at time 72 and time 74 are sequential and cannot be executed concurrently.

[0063] Configuration messages destined for child IAB nodes (e.g., 906b) may be RRC reconfiguration messages with or without synchronization. The configuration message may carry IP information and Backhaul Adaptation Protocol (BAP) address information for the second IAB node (e.g., the child IAB node), as well as uplink mapping information and routing information. In the case of inter-CU migration (not shown), the configuration message may carry reconfiguration information for the second donor CU (not shown).

[0064] The delivery of the configuration message can trigger multiple procedures at the sub-IAB node (e.g., 906b). For example, the configuration message can trigger random access procedures, secure handshakes, migration of the second signal transmission connection toward the donor CU (e.g., 904c) to a second path (such as a target path via D-DU 2 904b), and migration of a data tunnel terminating at the sub-IAB node (e.g., 906b) toward the donor CU (e.g., 904c) to a second path. Furthermore, the message can also trigger the establishment of an F1-C connection, including the establishment of an SCTP (Stream Control Transfer Protocol) connection and the addition of a path to an existing SCTP connection. It can also trigger the establishment of an F1-U data tunnel.

[0065] Although this description refers to a "child" IAB node, grandchild nodes or other nodes are also expected. Similarly, this description refers to the MT as the destination, but configuration messages can also be destined for the UE.

[0066] The release of the configuration message can be triggered by the grantor CU (e.g., 904c) on the first signaling connection. The instruction or configuration for triggering can be initiated by the parent of the migration IAB node (e.g., via Media Access Control-Control Element (MAC-CE) or Downlink Control Information (DCI)).

[0067] The instruction or configuration used for triggering can be UE / MT specific or more general. If the trigger or the corresponding trigger information is UE / MT specific, the trigger information releases the configuration information for that specific UE / MT. Alternatively, for general trigger information, the released configuration information is associated with multiple UE / MTs (e.g., all child nodes of the migrated IAB node).

[0068] According to the contents of this case, various types of triggering are expected. Triggering can be absolute time, elapsed time, relative time to the timing of the RACH detected by the migrating IAB node (e.g., 906a), a function configured by the RACH detected by the first IAB node, or the execution of a synchronous reconfiguration. In other cases, triggering can be the reception of an RRC reconfiguration message. For example, triggering may occur when the migrating IAB node (e.g., 906a) receives a reconfiguration message carrying new IP information, BAP address information, or a synchronous reconfiguration. The migrating IAB node (e.g., 906a) infers that a second path to the first grantor CU (e.g., 904c) (or, in the case of inter-CU migration, to the second grantor CU) is now available. The same applies to the child IAB node (e.g., 906b), thus the migrating IAB node (e.g., 906a) releases the configuration message.

[0069] In other states, the trigger is based on receiving an instruction from the parent of the migrating IAB node (e.g., via MAC-CE or DCI). The trigger can also be a response to detecting a change in a First System Information Block (SIB1) message broadcast by the parent of the migrating IAB node. The SIB1 message carries a cell identifier, such as the NR Cell Global Identity (NCGI). Therefore, the trigger could be detecting a change in the parent's cell ID.

[0070] The condition for measuring the PCI (Physical Cell ID) broadcast by the parent of an IAB node (e.g., a migrated IAB node) can also be a trigger. For example, the parent of an IAB node (e.g., a migrated IAB node) may change the PCI it is broadcasting after migrating to a different CU. In this case, what may trigger the handover at the IAB node (e.g., the migrated IAB node) and the release of any messages it retains is the ability to detect the new PCI. Therefore, the IAB node (e.g., the migrated IAB node) performs measurements on the old PCI and the new PCI on the signal broadcast by the parent node. The triggering condition may be that the IAB node (e.g., the migrated IAB node) measures that the channel quality metric (e.g., RSRP (Reference Signal Received Power)) measured by the IAB node on the new PCI has exceeded a threshold, or that the difference between the measurements corresponding to the new PCI and the old PCI has exceeded a threshold.

[0071] The trigger can be a switch or migration of the migrating IAB node (e.g., 906a) DU, the opposite of the parent DU. In this case, after the migrating IAB node (e.g., 906a) changes its NR Global Cell Identity (NGCI) carried in the SIB1 message broadcast by the migrating IAB node DU, the migrating IAB node (e.g., 906a) releases its configuration message.

[0072] In other forms of this application, the trigger may be the execution of a secure handshake for inter-CU operations. For example, an IAB node (e.g., a migrating IAB node) may release configuration messages only after obtaining a reload connection to the second CU. Other examples of triggers for inter-CU procedures include establishing an F1-C connection or establishing an F1-U data tunnel. For both intra-CU and inter-CU scenarios, the trigger may be an indication on a first signaling connection.

[0073] In various embodiments of this invention, the migrating IAB node (e.g., 906a) can acknowledge the instruction of the grant CU on the first signal transmission connection. In other embodiments, the migrating IAB node (e.g., 906a) can acknowledge the release of the configuration message on the first signal transmission connection to the grant CU (e.g., 904c). In yet another embodiment, the migrating IAB node (e.g., 906a) can instruct the child IAB node (e.g., 906b) to release the second configuration message when delivering the original configuration message.

[0074] Depending on the specifics of this case, the applicant CU (e.g., 904c) (or the parent of the migrated IAB node) can instruct the migrated IAB node (e.g., 906a) to discard configuration messages on the first signaling connection (or via Media Access Control-Control Element (MAC-CE) or Downlink Control Information (DCI)). The instruction to discard can occur in response to a failed handover at the upstream node. For example, if the migration of the migrated IAB node (e.g., 906a) fails, the migration of the child IAB node (e.g., 906b) can be cancelled. In other words, no secure handover occurs on the target path because no target path is established.

[0075] The first or second grant CU (in the case of an inter-CU procedure) may configure a timer extension at the grant CU. The timer extension may be band-dependent, for example, FR1 (frequency range one (below 6 GHz) or FR2 (frequency range two mm wave)). In other cases, the first or second grant CU may configure a timer extension at the sub-IAB node to prevent reconfiguration failure, connection rebuilding, or connection release at the sub-IAB node (or UE 908). In some cases, the first or second grant CU may instruct the sub-IAB node (e.g., 906b) or the destination UE 908 to prevent reconfiguration failure, connection rebuilding, or connection release at the sub-IAB node (or UE 908). For example, the sub-IAB node MT is allowed to send an RRC reconfiguration complete message after performing a secure handshake. Finally, when releasing the configuration message, the migration IAB node (e.g., 906a), child IAB node (e.g., 906b), or any intermediate node on the first path can initiate concurrent procedures (e.g., secure handshake) toward the first grant CU or the second grant CU.

[0076] In some configurations, the child IAB node may send an RRC reconfiguration complete message to the IAB grantor (e.g., 904) at time 97 within the original (general) timer, either before or along with the secure handshake between the IAB grantor (e.g., 904b) and the child IAB node (e.g., 906b) at time 96. Therefore, timer extensions at the child IAB node can be omitted. If the secure handshake between the IAB grantor (e.g., 904b) and the migrating IAB node (e.g., 906a) has not yet been performed at time 95, the response message can be buffered at the parent and forwarded later. However, this does not prevent the secure handshake from being performed concurrently at times 95 and 96.

[0077] As noted above, Figure 3-10 is provided as an example. Other examples may differ from those described with respect to Figure 3-10.

[0078] Figure 11 is a flowchart illustrating various forms of an example program 1100 executed at an Integrated Access and Reload (IAB) facility, according to the contents of this case. Example program 1100 is an example of delayed delivery of reconfiguration messages in an Integrated Access and Reload (IAB) network.

[0079] As shown in FIG11, in some configurations, program 1100 may include: sending configuration messages (block 1102) on a source path having a first IAB node via a first distributed unit of the IAB grant. For example, the IAB grant (e.g., using communication unit 294, controller / processor 290, and / or memory 292) may send configuration messages. Furthermore, as described with reference to FIG9 and 10, at time 91, the IAB grant (e.g., 904c) sends configuration messages to the migrating IAB node (also referred to as the first IAB node).

[0080] As shown in FIG11, in some configurations, program 1100 may include instructing a first IAB node to delay delivering configuration messages to a second node (block 1104). For example, an IAB grant (e.g., using communication unit 294, controller / processor 290, and / or memory 292) may instruct the first IAB node to delay delivery. Additionally, as described with reference to FIG9 and 10, configuration messages to a migrating IAB node (also referred to as the first IAB node) instruct the migrating IAB node (e.g., 906a) on the first signaling connection (on the source path) to postpone delivering configuration messages to a child IAB node (e.g., 906b).

[0081] As shown in FIG11, in some configurations, procedure 1100 may include migrating at least a portion of communication to the first IAB node from the source path to the target path via a second distributed unit (block 1106). For example, an IAB grant (e.g., using communication unit 294, controller / processor 290, and / or memory 292) may migrate at least a portion of the communication. Furthermore, as described with reference to FIG9 and 10, after releasing a configuration message to the child IAB node (e.g., 906b) at time 93, the migrating IAB node (e.g., 906a) completes the reconfiguration procedure with the IAB grant (e.g., 904) by sending an RRC reconfiguration completion message to the IAB grant CU 904c via the target path at time 94. The delivery of configuration messages can trigger random access procedures, secure handshakes, migration of the second signal transmission connection toward the donor CU (e.g., 904c) to the second path, and migration of the data tunnel that will terminate at the child IAB node (e.g., 906b) toward the donor CU (e.g., 904c) to the second path.

[0082] Figure 12 is a flowchart illustrating various states according to the present invention, such as an example of an instance program 1200 executed at a first Integrated Access and Reload (IAB) node. Instance program 1200 is an example of delayed delivery of reconfiguration messages in an Integrated Access and Reload (IAB) network.

[0083] As shown in FIG12, in some configurations, program 1200 may include receiving a first configuration message on a source path to the first IAB grant via a first distributed unit of the first IAB grant (block 1202). For example, an IAB node (e.g., using communication unit 294, controller / processor 290 and / or memory 292) may receive the first configuration message. As described with reference to FIG9 and 10, a migration IAB node (also referred to as an IAB node, e.g., 906a) receives the first configuration message from the first IAB grant (e.g., 904a) at time 91 via a source path (e.g., a first signal transmission connection).

[0084] As shown in FIG12, in some configurations, procedure 1200 may include: delaying the delivery of a first configuration message to a second node (block 1204). For example, the IAB node (e.g., using communication unit 294, controller / processor 290, and / or memory 292) may delay delivery. As described with reference to FIG9 and 10, the migrating IAB node (e.g., 906a) may retain the configuration message until it is triggered as a release message at time 93. In some configurations, the trigger for releasing the configuration message may be configured by the grantor CU (e.g., 904c) on the first signaling connection. The instruction for triggering or the configuration for triggering may be initiated by the parent of the migrating IAB node (e.g., via Media Access Control-Control Element (MAC-CE) or Downlink Control Information (DCI)). In addition, in some cases, the trigger can be an absolute time, an elapsed time, a relative time to the RACH timing detected by the migrating IAB node (e.g., 906a), a RACH configured function detected by the migrating IAB node, or an execution with synchronous reconfiguration.

[0085] In some cases, the trigger may be the reception of an RRC reconfiguration message. For example, as described with reference to FIG9, a trigger may occur when the migrating IAB node (e.g., 906a) receives a reconfiguration message carrying new IP information, BAP address information, or a synchronized reconfiguration. The migrating IAB node (e.g., 906a) infers that a second path to the first grant CU (e.g., 904c) (or, in the case of inter-CU migration, to the second grant CU) is now available. The same applies to the child IAB node (e.g., 906b), thus the migrating IAB node (e.g., 906a) releases the configuration message.

[0086] In another instance, the trigger is based on receiving an instruction from the parent of the migrating IAB node (e.g., via MAC-CE or DCI). The trigger can also be in response to detecting a change in a First System Information Block (SIB1) message broadcast by the parent of the migrating IAB node. The SIB1 message carries a cell identifier, such as the NR Cell Global Identity (NCGI). Therefore, the trigger could be detecting a change in the parent's cell ID.

[0087] As shown in FIG12, in some configurations, program 1200 may include delivering a first configuration message to a second node (block 1206) in response to a trigger. For example, an IAB node (e.g., using communication unit 294, controller / processor 290, and / or memory 292) may deliver the first configuration message. Furthermore, as described with reference to FIG9 and 10, migrating IAB node 906a releases the configuration message to a child IAB node (e.g., 906b) at time 93.

[0088] Implementation examples are provided in the following numbered clauses. 1. A method for migrating an IAB node at an Integrated Access and Backhaul (IAB) facility, comprising: sending a configuration message to a first IAB node via a first distributed unit of the IAB facility on a source path; and instructing the first IAB node to delay delivery of the configuration message to a second node. 2. The method of clause 1, wherein the configuration message includes a Radio Resource Control (RRC) message providing an uplink (UL) mapping or Internet Protocol (IP) address for the first IAB node to communicate with a target facility. 3. The method of any one of clauses 1-2, further comprising: migrating at least a portion of communication to the first IAB node from the source path to a target path for the first IAB node via a second distributed unit. 4. The method of any one of clauses 1-3, further comprising: performing a first secure handshake with the first IAB node; and performing a second secure handshake with the second node, wherein the second distributed unit is part of the IAB facility. 5. The method of any one of Clauses 1-4, wherein the second secure handshake is performed concurrently with the first secure handshake. 6. The method of any one of Clauses 1-5, wherein the configuration message originates from the first grantor central unit (CU) and carries a reconfiguration message for the second grantor central unit. 7. The method of any one of Clauses 1-6, wherein indicating the first IAB node to delay delivery includes: indicating the delay of the configuration message based on a Load Adaptation Protocol (BAP) address, a BAP routing ID, a Load Radio Link Control (RLC) channel ID, or a logical channel ID. 8. The method of any one of Clauses 1-7, further comprising: configuring a trigger to release the configuration message. 9. The method of any one of Clauses 1-8, wherein configuring the trigger includes: configuring for a specific child node. 10. The method of any one of Clauses 1-8, wherein configuring the trigger includes: configuring for all child nodes. 11. The method according to any one of Clauses 1-10, wherein the triggering comprises an absolute time, a duration, a relative time to the timing of the Random Access Channel (RACH) detected by the first IAB node, or a function of the RACH configuration detected by the first IAB node. 12. The method according to any one of Clauses 1-11, further comprising: receiving an acknowledgment of the indication. 13. The method according to any one of Clauses 1-12, further comprising: upon receiving the acknowledgment, sending the configuration message to the first IAB node or an upstream node of the source path. 14. The method according to any one of Clauses 1-13, further comprising: receiving an acknowledgment of the release of the configuration message.15. The method according to any one of Clauses 1-14 further includes: instructing the first IAB node to discard the configuration message in response to a failure to migrate the first IAB node or an upstream IAB node of the source path. 16. The method according to any one of Clauses 1-15 further includes: instructing the second node to prevent reconfiguration failure, connection reconstruction, or connection release. 17. A method for IAB node migration performed at a first Integrated Access and Backhaul (IAB) node, comprising: receiving a first configuration message on a source path having the first IAB grant via a first distributed unit of the first IAB grant; delaying delivery of the first configuration message to a second node; and delivering the first configuration message to the second node in response to a trigger. 18. The method according to Clause 17, wherein the trigger includes: receiving a reconfiguration message carrying Internet Protocol (IP) information or an uplink (UL) mapping. 19. The method according to Clause 17, wherein the trigger includes: receiving an instruction from the parent of the first IAB node to release the first configuration message. 20. The method of any one of Clauses 17-19, wherein the triggering comprises: detecting a change in the cell ID of the parent of the first IAB node. 21. The method of any one of Clauses 17-20, wherein the detection occurs based on a condition of a measurement of a System Information Block (SIB) message broadcast by the parent of the first IAB node or a cell ID broadcast by the parent of the first IAB node. 22. The method of Clause 17, wherein the triggering comprises a migration of a Distributed Unit (DU) of the first IAB node, the migration comprising a change in a System Information Block (SIB) message broadcast by the DU of the first IAB node. 23. The method of Clause 17, wherein the triggering comprises: performing a secure handshake on a target path via a second Distributed Unit of the first IAB node. 24. The method of Clause 23, wherein the execution of the secure handshake comprises: establishing an F1-C connection or establishing an F1-U data tunnel. 25. The method of Clause 17, wherein the triggering includes performing a synchronous reconfiguration based on the first configuration message from or forwarded by the first IAB implementer. 26. The method of any one of Clauses 23-25, wherein performing the synchronous reconfiguration includes a switching procedure. 27. The method of any one of Clauses 17-26, further comprising receiving the trigger on the source path. 28. The method of any one of Clauses 17-27, further comprising instructing the child IAB node to release a second configuration message in response to the delivery of the first configuration message.29. The method according to any one of Clauses 17-28 further includes: instructing a child IAB node to discard a second configuration message held at the child node; and in response to delivering the first configuration message to the second node, initiating a concurrent procedure toward the first IAB grantor, the concurrent procedure including a secure handshake. 30. The method according to any one of Clauses 17-29 further includes: in response to delivering the first configuration message to the second node, participating in a concurrent procedure toward the first IAB grantor or the second IAB grantor node with the second node or another node in a path including the first IAB node and the second node. 31. An apparatus for wireless communication via an Integrated Access and Backload Network (IAB) implementer, comprising: a processor; memory coupled to the processor; and instructions stored in the memory and operable, when executed by the processor, to cause the apparatus to: transmit a configuration message on a source path having a first IAB node via a first distributed unit of the IAB implementer; instruct the first IAB node to delay delivery of the configuration message to a second node; and migrate at least a portion of communication to the first IAB node from the source path to a destination path via a second distributed unit. 32. The apparatus of claim 31, wherein the processor causes the apparatus to: perform a first secure handshake with the first IAB node; and perform a second secure handshake with the second node, wherein the second distributed unit is part of the IAB implementer. 33. The apparatus of any one of claims 31-32, wherein the processor causes the second secure handshake to be performed concurrently with the first secure handshake. 34. The apparatus according to any one of clauses 31-33, wherein the configuration message originates from a first grantor central unit (CU) and carries a reconfiguration message for a second grantor central unit. 35. The apparatus according to any one of clauses 31-34, wherein the processor causes the apparatus to indicate a delay in the configuration message based on a Load Adaptation Protocol (BAP) address, a BAP route ID, a Load Radio Link Control (RLC) channel ID, or a logical channel ID. 36. The apparatus according to any one of clauses 31-35, wherein the processor causes the apparatus to configure a trigger to release the configuration message. 37. The apparatus according to any one of clauses 31-36, wherein the processor causes the apparatus to configure the trigger for a specific child node. 38. The apparatus according to any one of clauses 31-37, wherein the processor causes the apparatus to configure the trigger for all child nodes. 39. The apparatus according to any one of clauses 31-38, wherein the triggering comprises an absolute time, a duration, a relative time to the timing of the random access channel (RACH) detected by the first IAB node, or a function of the RACH configuration detected by the first IAB node.40. The apparatus according to any one of clauses 31-39, wherein the processor causes the apparatus to: receive a reconfiguration message carrying IP (Internet Protocol) information or a preset uplink (UL) mapping. 41. The apparatus according to any one of clauses 31-40, wherein the processor causes the apparatus to: configure the trigger via the source path. 42. The apparatus according to any one of clauses 31-41, wherein the processor causes the apparatus to: receive an acknowledgment of the instruction. 43. The apparatus according to any one of clauses 31-42, wherein the processor causes the apparatus to: upon receiving the acknowledgment, send the configuration message to the first IAB node or another node in a path including the first IAB node and the second node. 44. The apparatus according to any one of clauses 31-43, wherein the processor causes the apparatus to: receive an acknowledgment of the release of the configuration message. 45. The apparatus according to any one of clauses 31-44, wherein the processor causes the apparatus to: instruct the first IAB node to discard the configuration message in response to a migration failure at the first IAB node or an upstream node of the source path. 46. The apparatus according to any one of clauses 31-45, wherein the processor causes the apparatus to: instruct the second node to prevent reconfiguration failure, connection reconstruction, or connection release. 47. The apparatus according to any one of clauses 31-46, wherein the first IAB node includes a first IAB node, and the second node includes a second IAB node. 48. An apparatus for wireless communication using an Integrated Access and Backhaul (IAB) facility, comprising: a processor; memory coupled to the processor; and instructions stored in the memory and operable, when executed by the processor, to cause the apparatus to: receive a first configuration message on a source path having the first IAB facility via a first distributed unit of the first IAB facility; delay delivery of the first configuration message to a second node; and deliver the first configuration message to the second node in response to a trigger. 49. An apparatus according to claim 48, wherein the processor causes the apparatus to: configure the trigger via downlink control information (DCI) or a media access control-control element (MAC-CE). 50. An apparatus according to any one of claims 48-49, wherein the processor causes the apparatus to: receive an instruction from a parent of the first IAB node via downlink control information (DCI) or a media access control-control element (MAC-CE). 51. The apparatus according to any one of clauses 48-50, wherein the processor causes the apparatus to perform the following operation: detect a change in the cell ID of the parent of the first IAB node.52. The apparatus according to any one of claims 48-51, wherein detection occurs based on a condition of a measurement of a System Information Block (SIB) message broadcast by the parent of the first IAB node or a cell ID broadcast by the parent of the first IAB node. 53. The apparatus according to any one of claims 48-52, wherein the trigger includes a handover of a Distributed Unit (DU) of the first IAB node, the handover including a change in a System Information Block (SIB) message broadcast by the DU of the first IAB node. 54. The apparatus according to any one of claims 48-52, wherein the trigger includes performing a secure handover on a target path via a second Distributed Unit of the first IAB node. 55. The apparatus according to any one of claims 48-54, wherein the execution of the secure handover includes establishing an F1-C connection or establishing an F1-U data tunnel. 56. The apparatus according to any one of clauses 48-55, wherein the processor causes the apparatus to perform a synchronous reconfiguration based on the first configuration message from or forwarded by the first IAB grantor. 57. The apparatus according to any one of clauses 48-56, wherein the processor causes the apparatus to perform the synchronous reconfiguration including a switching procedure. 58. The apparatus according to any one of clauses 48-57, wherein the processor causes the apparatus to receive the trigger on the source path. 59. The apparatus according to any one of clauses 48-58, wherein the processor causes the apparatus to instruct a child IAB node to release a second configuration message in response to the delivery of the first configuration message. 60. The apparatus according to any one of clauses 48-59, wherein the processor causes the apparatus to instruct a child IAB node to discard the second configuration message held at the child node. 61. The apparatus according to any one of claims 48-60, wherein the processor causes the apparatus to initiate a concurrent procedure toward the first IAB grant in response to delivering the first configuration message to the second node. 62. The apparatus according to any one of claims 48-61, wherein the concurrent procedure includes a secure handshake. 63. The apparatus according to any one of claims 48-62, wherein the processor causes the apparatus to participate in a concurrent procedure with the second node or another node in a path including the first IAB grant or the second IAB grant node in response to delivering the first configuration message to the second node.

[0089] The foregoing disclosure provides explanation and description, but is not intended to be exhaustive or to limit the various forms to the precise forms disclosed. Modifications and variations can be made in accordance with the foregoing disclosure, or modifications and variations can be derived from practice with the various forms.

[0090] As used herein, the term "component" is intended to be interpreted broadly as hardware, firmware, and / or a combination of hardware and software. As used herein, a processor is implemented using hardware, firmware, and / or a combination of hardware and software.

[0091] The threshold is used to describe some states. As used, depending on the context, satisfying the threshold can mean that the value is greater than the threshold, greater than or equal to the threshold, less than the threshold, less than or equal to the threshold, equal to the threshold, not equal to the threshold, etc.

[0092] It will be apparent that the described systems and / or methods can be implemented in various forms of hardware, firmware, and / or combinations of hardware and software. The actual, specialized control hardware or software code used to implement these systems and / or methods is not a limitation on the variety. Therefore, while the operation and behavior of the systems and / or methods are described without reference to specific software code, it is to be understood that the software and hardware can be designed to implement the systems and / or methods at least in part based on the description.

[0093] Even if a specific combination of features is described in the claims and / or disclosed in the specification, such combinations are not intended to limit the disclosure of each variant. In fact, many features among these features can be combined in a manner not specifically described in the claims and / or disclosed in the specification. Although each dependent claim listed below may depend directly on only one claim, the disclosure of each variant includes the combination of each dependent claim with the other claims in each of the claim sets. The phrase referring to "at least one of" in the list of items means any combination of those items, including a single member. For example, "at least one of a, b, or c" is intended to cover a, b, c, ab, ac, bc, and abc, as well as any combination of multiples of the same element (e.g., aa, aaa, aab, aac, abb, acc, bb, bbb, bbc, cc, and ccc, or any other ordering of a, b, and c).

[0094] None of the elements, actions, or instructions used should be construed as essential or necessary unless explicitly stated otherwise. Furthermore, as used, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more." Furthermore, as used, the terms "collection" and "group" are intended to include one or more items (e.g., related items, unrelated items, combinations of related and unrelated items, etc.) and may be used interchangeably with "one or more." Where only one item is anticipated, the phrase "only one" or similar language is used. Furthermore, as used, the terms "has," "have," "having," and / or similar terms are intended to be open-ended terms. Furthermore, unless otherwise explicitly stated, the phrase "based on" is intended to mean "at least partially based on." 71: Time 72: Time 73: Time 74: Time 91: Time 92: Time 93: Time 94: Time 95: Time 96: Time 97: Time 98: Time 100: Wireless Network 102a: Macro Cell 102b: Pico Cell 102c: Femto Cell 110: BS 110a: BS 110b: BS 110c: BS 110d: BS 120: UE 120a: UE 120b: UE 120c: UE 120d: UE 130: Network Controller 200: Design 212: Source of Information 220: Transmit Processor 230: Transmit (TX) Multiple-Input Multiple-Output (MIMO) Processor 232a: Modulator (MOD) 232t: Modulator (MOD) 234a: Antenna 234t: Antenna 236: MIMO Detector 238: Receiver Processor 239: Data Slot 240: Controller / Processor 242: Memory 244: Communication Unit 246: Scheduler 252a: Antenna 252r: Antenna 254a: Demodulator (DEMOD) 254r: Demodulator (DEMOD) 256: MIMO Detector 258: Receiver Processor 260: Data Slot 262: Data Source 264: Transmitter Processor 266: TX MIMO Processor 280: Controller / Processor 282: Memory 290: Controller / Processor 292: Memory 294: Communication Unit 300: Integrated Access and Backload (IAB) Network 302: Core Network 304: Integrated Access and Backload (IAB) Applicator 306a: UE 306b: UE 306c: UE 306d: UE 306e:UE 306f:UE 308a:IAB Node 308b:IAB Node 400: Block Diagram 408a:IAB Node 408b:IAB Node 408c:IAB Node 408d:IAB Node 500: Timing Diagram501: Time 502: Time 503: Time 504: Time 505: Time 506: Time 507: Time 510: UE 515: Source gNB 520: Target gNB 600: Block Graph 601: Time 602: Time 603: Time 700: Block Graph 704a: Source Parent Node 704b: Target Parent Node 704c: IAB Granter CU 706a: Migrating IAB Node 706b: Child IAB Node 708: UE 800: Timing Graph 802: IAB Granter 804: Migrating IAB Node 806: Child IAB Node 900: Block Graph 904a: Source D-DU 904b: D-DU 904c: First IAB Granter CU 906a: Migrate IAB Node 906b: Sub-IAB Node 1000: Timing Diagram 1002: IAB Actor 1004: Migrate IAB Node 1006: Sub-IAB Node 1100: Procedure 1102: Block 1104: Block 1106: Block 1200: Procedure 1202: Block 1204: Block 1206: Block UE: User Equipment BS: Base Station MOD: Modulator DEMOD: Demodulator IAB: Integrated Access and Reload CU: Central Unit DU: Distributed Unit MT: Mobile Terminal [Simplified Explanation of the Diagram]

[0096] In order to fully understand the features of this application, a specific description can be obtained by referring to various embodiments (some of which are shown in the accompanying drawings). However, it should be noted that the accompanying drawings only illustrate certain embodiments of this application and are therefore not considered as limiting the scope of this application, as the description may allow for other equally valid embodiments. The same element symbols in different drawings may identify the same or similar elements.

[0097] Figure 1 is a block diagram conceptually illustrating examples of various types of wireless communication networks according to the contents of this case.

[0098] Figure 2 is a block diagram conceptually illustrating an example of communication between a base station and a user equipment (UE) in a wireless communication network of various forms according to the contents of this case.

[0099] Figure 3 is a block diagram illustrating the various integrated access and reload (IAB) networks according to the content of this case.

[0100] Figure 4 is a block diagram showing a more detailed view of the Integrated Access and Backload (IAB) network shown in Figure 3 according to various forms of the present case.

[0101] Figure 5 is a timing diagram showing the handover between user equipment (UE) base stations in various forms according to the contents of this case.

[0102] Figure 6 is a block diagram showing various delay specifications for Radio Resource Control (RRC) procedures according to the contents of this case.

[0103] Figure 7 is a block diagram showing the migration within the central unit (CU) via switching according to the various states of the present case.

[0104] Figure 8 is a timing diagram showing the migration within the central unit (CU) via switching according to the various states of the present case.

[0105] Figure 9 is a block diagram showing the migration within a central unit (CU) via a switch with delayed delivery according to various states of the present case.

[0106] Figure 10 is a timing diagram showing the migration within a central unit (CU) via a switch with delayed delivery according to various states of the present case.

[0107] Figure 11 is a flowchart illustrating an example program executed by an Integration Access and Reload (IAB) implementer, for example, according to various states of the content of this case.

[0108] Figure 12 is a flowchart illustrating various states according to the content of this case, such as an example program executed by an Integrated Access and Reload (IAB) node. [Biomaterial Storage]

[0109] Domestic storage information (please note in order of storage institution, date, and number): None. International storage information (please note in order of storage country, institution, date, and number): None.

Claims

1. A method for migrating an IAB node at an Integrated Access and Backhaul (IAB) facility, comprising the steps of: sending a configuration message to a first IAB node via a first distributed unit of the IAB facility on a source path, the configuration message including a Radio Resource Control (RRC) message providing an uplink (UL) mapping or an Internet Protocol (IP) address for communicating with a target facility; and instructing the first IAB node to delay delivering the configuration message to a second node.

2. The method according to claim 1 also includes the following steps: migrating at least a portion of the communication to the first IAB node from the source path to a target path for the first IAB node via a second distributed unit.

3. The method according to claim 2 also includes the following steps: performing a first security handshake with the first IAB node; and performing a second security handshake with the second node, wherein the second distributed unit is part of the IAB implement.

4. The method according to claim 3, wherein the second security handshake is performed concurrently with the first security handshake.

5. The method according to request item 1, wherein the configuration message originates from a first grant central unit (CU) and carries a reconfiguration message of a second grant central unit.

6. The method according to request item 1, wherein instructing the first IAB node to delay delivery includes: The delay of the configuration message is indicated by a Load Adaptation Protocol (BAP) address, a BAP route ID, a Load Radio Link Control (RLC) channel ID, or a logical channel ID.

7. According to the method of request item 1, the following steps are also included: configuring a trigger to release the configuration message.

8. According to the method in request item 7, the configuration of the trigger includes: Configure a specific child node.

9. According to the method in request item 7, the configuration of the trigger includes: Configure all child nodes.

10. The method according to request item 7, wherein the trigger includes an absolute time, a duration, a relative time to the timing of a random access channel (RACH) detected by the first IAB node, or a function of a RACH configuration detected by the first IAB node.

11. The method according to request item 1 also includes the following steps: receiving an acknowledgment of the instruction.

12. The method according to request item 11 also includes the following steps: upon receiving the confirmation, sending the configuration message to the first IAB node or an upstream node of the source path.

13. The method according to request item 1 also includes the following steps: receiving an acknowledgment of the release of the configuration message.

14. The method according to request item 1 also includes the following steps: instructing the first IAB node to discard the configuration message in response to a failure to migrate the first IAB node or an upstream IAB node of the source path.

15. The method according to request item 1 also includes the following steps: instructing the second node to configure a timer to prevent a reconfiguration failure, a connection reconstruction, or a connection release.

16. A method for performing an IAB node migration at a first Integrated Access and Backload Network (IAB) node, comprising the steps of: receiving a first configuration message on a source path having the first IAB grant via a first distributed unit of a first IAB grant; delaying delivery of the first configuration message to a second node; delivering the first configuration message to the second node in response to a trigger; and, in response to delivering the first configuration message to the second node, participating in at least one concurrent procedure with the second node or another node in a path including the first IAB grant and the second grant node toward the first IAB grant or a second IAB grant node.

17. According to the method of request item 16, the trigger includes: Receive a reconfiguration message carrying Internet Protocol (IP) information or an uplink (UL) mapping.

18. According to the method of request item 16, the trigger includes: Receive an instruction from a parent of the first IAB node to release the first configuration message.

19. According to the method of request item 16, wherein the trigger includes: Detect a change in the cell ID of a parent of the first IAB node.

20. The method according to claim 19, wherein the detection occurs based on a condition of a measurement of a System Information Block (SIB) message broadcast by the parent of the first IAB node or a cell ID broadcast by the parent of the first IAB node.

21. The method of request item 16, wherein the triggering includes a migration of a distributed unit (DU) of the first IAB node, the migration including a change of a System Information Block (SIB) message broadcast by the DU of the first IAB node.

22. According to the method of request item 16, the trigger includes: A secure handshake is performed on a target path via a second distributed unit of the first IAB node.

23. The method according to request 22, wherein the execution of the secure handshake includes: Establish an F1-C connection or an F1-U data tunnel.

24. According to the method of request item 16, the trigger includes: A synchronous reconfiguration is performed based on the first configuration message from or forwarded by the first IAB grant.

25. The method according to request item 24, wherein the execution of the synchronous reconfiguration includes a switching procedure.

26. The method according to request item 16 also includes the following steps: receiving the trigger on the source path.

27. The method according to request item 16 also includes the following steps: responding to the delivery of the first configuration message to instruct a child IAB node to release a second configuration message.

28. The method according to claim 16 also includes the steps of: instructing a child IAB node to discard a second configuration message held at a child node; and responding to the delivery of the first configuration message to the second node to initiate the at least one concurrent procedure toward the first IAB grant, the at least one concurrent procedure including at least one secure handshake.

29. An apparatus for wireless communication via an Integrated Access and Backhaul (IAB) provider, comprising: At least one processor, and at least one memory unit coupled to the at least one processor; The device contains instructions stored in the at least one memory unit and operable, when executed by the at least one processor, to cause the device to: transmit a configuration message via a first distributed unit of the IAB grant on a source path having a first IAB node, the configuration message including a Radio Resource Control (RRC) message providing an uplink (UL) mapping or an Internet Protocol (IP) address for communicating with a target grant; and instruct the first IAB node to delay delivering the configuration message to a second node.

30. The apparatus according to claim 29, wherein the at least one processor causes the apparatus to perform the following operation: migrating at least a portion of the communication to the first IAB node from the source path to a destination path via a second distributed unit.

31. The apparatus according to claim 30, wherein the at least one processor causes the apparatus to perform: a first secure handshake with the first IAB node; and a second secure handshake with the second node, wherein the second distributed unit is part of the IAB implement.

32. The apparatus according to claim 29, wherein the at least one processor causes the second security handshake to be performed at least partially concurrently with the first security handshake.

33. The apparatus according to claim 29, wherein the configuration message originates from a first applicant central unit (CU) and carries a reconfiguration message for a second applicant central unit.

34. The apparatus according to claim 29, wherein the at least one processor causes the apparatus to perform the following operation: indicating the delay of the configuration message based on a Load Adaptation Protocol (BAP) address, a BAP route ID, a Load Radio Link Control (RLC) channel ID, or a logical channel ID.

35. The apparatus according to request 29, wherein the at least one processor causes the apparatus to perform the following operation: configure a trigger to release the configuration message.

36. The apparatus according to request 35, wherein the at least one processor causes the apparatus to perform the following operation: configure the trigger for a specific child node.

37. The apparatus according to request 36, wherein the at least one processor causes the apparatus to perform the following operation: configure the trigger for all child nodes.

38. The apparatus according to claim 36, wherein the trigger includes an absolute time, a duration, a relative time to a random access channel (RACH) timing detected by the first IAB node, or a function of a RACH configuration detected by the first IAB node.

39. The apparatus according to claim 36, wherein the at least one processor causes the apparatus to perform the following operation: receiving a reconfiguration message carrying IP (Internet Protocol) information or a preset uplink (UL) mapping.

40. The apparatus according to request 36, wherein the at least one processor causes the apparatus to configure the trigger via the source path.

41. The apparatus according to claim 29, wherein the at least one processor causes the apparatus to perform the following operation: receive an acknowledgment of the instruction.

42. The apparatus according to request 41, wherein the at least one processor causes the apparatus to perform the following operation: upon receiving the confirmation, sending the configuration message to the first IAB node or another node in a path including the first IAB node and the second node.

43. The apparatus according to claim 29, wherein the at least one processor causes the apparatus to perform the following operation: receive an acknowledgment of the release of the configuration message.

44. The apparatus according to claim 29, wherein the at least one processor causes the apparatus to: instruct the first IAB node to discard the configuration message in response to a failure of the migration at the first IAB node or at an upstream node in the source path.

45. The apparatus according to claim 29, wherein the at least one processor causes the apparatus to perform the following operation: instruct the second node to prevent a reconfiguration failure, a connection reconstruction, or a connection release.

46. ​​The apparatus according to claim 29, wherein the second node includes a second IAB node.

47. An apparatus for wireless communication via an Integrated Access and Backhaul (IAB) facility, comprising: At least one processor, and at least one memory unit coupled to the at least one processor; The device contains instructions stored in the at least one memory unit and operable, when executed by the at least one processor, to cause the device to perform the following operations: receiving a first configuration message on a source path having the first IAB embodiment via a first distributed unit of a first IAB embodiment; delaying the delivery of the first configuration message to a second node; delivering the first configuration message to the second node in response to a trigger; and participating in at least one concurrent procedure with the second node or another node in a path including the first IAB node and the second node in response to the delivery of the first configuration message to the second node.

48. The apparatus according to request 47, wherein the at least one processor causes the apparatus to configure the trigger via downlink control information (DCI) or a media access control-control element (MAC-CE).

49. The apparatus according to claim 48, wherein the at least one processor causes the apparatus to perform the following operation: receive an instruction from a parent of the first IAB node via downlink control information (DCI) or a media access control-control element (MAC-CE).

50. The apparatus according to claim 47, wherein the at least one processor causes the apparatus to perform the following operation: detect a change in a cell ID of a parent of the first IAB node.

51. The apparatus according to claim 50, wherein detection occurs based on a measurement of a System Information Block (SIB) message broadcast by the parent of the first IAB node or a cell ID broadcast by the parent of the first IAB node.

52. The apparatus according to request 47, wherein the triggering includes all switching of a distributed unit (DU) of the first IAB node, the switching including a change in a System Information Block (SIB) message broadcast by the DU of the first IAB node.

53. The device according to request item 47, wherein the trigger includes: A secure handshake is performed on a target path via a second distributed unit of the first IAB node.

54. The apparatus according to claim 53, wherein the execution of the secure handshake includes: Establish an F1-C connection or an F1-U data tunnel.

55. The apparatus according to claim 47, wherein the at least one processor causes the apparatus to perform a synchronous reconfiguration based on the first configuration message from or forwarded by the first IAB implementer.

56. The apparatus according to claim 55, wherein the at least one processor causes the apparatus to perform the following operation: executing the synchronous reconfiguration including a switching procedure.

57. The apparatus according to claim 47, wherein the at least one processor causes the apparatus to perform the following operation: receive the trigger on the source path.

58. The apparatus according to claim 47, wherein the at least one processor causes the apparatus to perform the following operation: in response to delivering the first configuration message, instructing a sub-IAB node to release a second configuration message.

59. The apparatus according to claim 47, wherein the at least one processor causes the apparatus to perform the following operation: instruct a child IAB node to discard a second configuration message held at a child node.

60. The apparatus according to claim 47, wherein the at least one processor causes the apparatus to perform the following operation: in response to delivering the first configuration message to the second node to initiate a concurrent procedure toward the first IAB grant.

61. The apparatus according to claim 60, wherein the at least one concurrent program includes at least one secure handshake.

Images