Management of Migration including Mobile Integrated Access Backhaul Node

Abstract

A method is provided for use in a process of requesting resources for a target integrated access backhaul (IAB) topology by a source integrated access backhaul (IAB) topology of a communication system, each of the source IAB topology and the target IAB topology including a set of IAB nodes and a donor central unit (CU), the method at a source donor CU of the source IAB topology including transmitting, to a target donor CU of the target IAB topology, a message related to a request for resources associated with an IAB node of the source IAB topology, the message including an indication identifying the IAB node of the source IAB topology as a mobile IAB node. A corresponding method, and device, at the target donor are also disclosed.

Description

【Technical Field】 【0001】 The present invention generally relates to a method used in the process of migrating nodes and traffic between IAB (Integrated Access Backhaul) topologies of a wireless communication system including mobile IAB nodes. 【Background Art】 【0002】 Wireless communication systems have been greatly expanded to support a wide range of applications, from mobile broadband, massive machine-type communication to ultra-reliable low-latency communication (URLLC). In such a system, multiple user devices (UEs) or mobile terminals share a wireless medium and can exchange multiple types of data content (e.g., video, audio, messaging...) via a radio access network (RAN) through one or more base stations. Base stations have conventionally been wired-connected (such as fiber) to a core network, forming an intermediate network called a backhaul (BH). 【0003】 Examples of such wireless multi-access communication systems include systems based on 3rd Generation Partnership Project (3GPP (registered trademark)) standards such as the 4th generation (4G) Long Term Evolution (LTE) and the recent 5th generation (5G) New Radio (NR) systems, or systems based on IEEE802.11 standards such as Wi-Fi. 【0004】 Due to the increasing number of users and high throughput requirements, the demand for network densification is increasing. 【0005】 With the densification of the network, facing the problem that the introduction cost and time of the wired backhaul network are increasing, 3GPP has proposed a wireless backhaul, also known as integrated access backhaul (IAB), since Release 16 of 5G NR. In IAB, a part of the radio (i.e., radio wave) spectrum is used instead of fiber for the backhaul connection of the base station. Wireless backhaul communication (between base stations) can use the same radio resources as access communication (between the base station and the UE). 【0006】 IAB becomes a competitive alternative to fiber-based backhaul in dense areas and areas that are difficult to cover. 【0007】 IAB is most likely to operate in the millimeter wave (mmWave) band to achieve the required Gbps (gigabits per second) data rate. However, it is known that millimeter waves have a strong signal attenuation depending on weather conditions (rain, fog), and are blocked when there are obstacles in the path between the emitter and the receiver. 【0008】 To manage such potential wireless link failures, topological redundancy can be provided within the IAB framework. In this case, multiple data paths are set up between the IAB base station directly connected to the core network (also called the "IAB donor") and the IAB base station that provides services to the UE (also called the "access IAB node" for the UE). Multiple intermediate IAB base stations (also called IAB nodes) may be involved in each of the multiple paths between the IAB donor and the access IAB node, and as a result, alternative data paths are formed within the multi-hop IAB topology. 【0009】 Furthermore, 3GPP is considering inter-donor redundancy where an IAB node, called a border IAB node, can access two different parent nodes connected to two different IAB donors. The border IAB node belongs to a single IAB topology (i.e., also belongs to a single IAB donor for configuration and management), and thus can route packets from a first IAB topology managed by a first IAB donor to a second IAB network managed by a second IAB donor. The advantage of such inter-donor redundancy is that the first IAB donor can perform offloading by routing some of its packets via the second IAB topology, alleviating congestion problems that may occur in the first IAB topology or overcoming problems of radio link failures. 【0010】 There are other situations where an IAB node becomes a border node. This is the case when an IAB node that has experienced a radio link failure recovers via a parent IAB node belonging to another IAB topology. Also, in the case of migration of an IAB node determined by an IAB donor, the IAB node is connected to a single parent IAB node belonging to another IAB topology controlled by another IAB donor. The migrated IAB node and its potential descendant IAB nodes still belong to the first IAB topology, and such a migration is called a partial migration. Traffic migration related to the border node and its descendant IAB nodes needs to follow, where traffic is routed to the border node (i.e., the migrated IAB node) via another IAB topology. 【0011】 Partial migration is suitable for stationary IAB nodes. In fact, the backhaul link (defined between two consecutive IAB nodes of the wireless backhaul) may be disrupted due to fluctuations in the wireless state. Therefore, such stationary IAB nodes do not need to perform a complete migration to the new IAB topology. Thus, when the migration is limited to a partial migration, the transmission and confirmation of many protocol messages can be avoided. 【0012】 Based on the fixed IAB foundation of Releases 16 and 17, 3GPP is currently considering mobile IAB systems and architectures to address scenarios focused on mobile IAB nodes mounted on vehicles as part of the Release 18 framework. In such scenarios, the mobile IAB node is called a vehicle-mounted relay (VMR) and can provide 5G coverage / capacity to in-vehicle UEs and surrounding UEs. 【0013】 Technical advantages of using vehicle relays include, in particular, that due to their superior RF / antenna capabilities, relay vehicles can obtain better macro coverage than nearby UEs and can provide better links to the macro network for UEs. Furthermore, vehicle relays are not expected to have more severe power / battery constraints than UEs. 【0014】 Urban environments are typically characterized by high user density and the presence of a large number of vehicles (public / private passenger transport, goods delivery, food trucks, etc.). Some of these vehicles (e.g., buses, trams, trains) may have predictable routes and a significant number of UEs (e.g., passengers' devices) may be deployed on them. 【0015】 In the case of a mobile IAB node, since the connection to the parent IAB node belonging to the first IAB topology may not occur again as the mobile IAB node moves, it is worthwhile to perform a complete migration from the first IAB topology to the second IAB topology. However, the complete migration needs to be managed step by step, starting with partial node migration and traffic migration to avoid service interruption. The complete migration also includes the handover of UEs served by the mobile IAB node to be migrated. 【0016】 According to Release 17 (Section 8.7.3.1 of TS38.401 v17.0.0), when the source IAB donor requests partial migration of an IAB node, traffic migration, or handover of a UE, the target IAB donor can reject the request for reasons such as load issues. However, in the case of a mobile IAB node, since the mobile IAB node is in motion and there may be no other connection options to continue serving the UE, such failures should be avoided. 【0017】 Therefore, some new mechanisms are needed to avoid the aforementioned problems, namely, the failure of node / traffic migration and the failure of UE handover related to mobile IAB nodes. SUMMARY OF THE INVENTION 【0018】 The present invention generally relates to signaling that a migration, dual connectivity, or handover request includes a mobile base station or relay, and priority can be assigned according to the request. This is particularly relevant to mobile communication networks (e.g., 5G) that utilize mobile IAB nodes. Other applications include other wireless communication networks such as Wi-Fi where mobile base stations, relays, and access points are utilized. 【0019】 In an example of a mobile communication network such as 5G, messages are exchanged between "IAB donors" (specifically, their aggregation units), and IAB nodes, which are wireless (connected by a radio link rather than an optical fiber) are connected to a wired (such as fiber) backhaul and a core network. There are equivalent nodes in other wireless networks, and the present invention can be similarly applied to these. Therefore, the term "IAB donor" can be replaced with "donor". 【0020】 According to one aspect of the present invention, there is provided a method for use in a process of requesting resources from a source donor to a target donor in a communication system, wherein each of the source donor and the target donor controls a set of wireless nodes, and the method at the source donor includes transmitting a message related to a request for resources associated with the wireless nodes to the target donor, the message including an indication for identifying whether the wireless nodes are mobile wireless nodes. 【0021】 In this way, the transfer of resources related to the mobile wireless mode may be prioritized (e.g., over static wireless nodes). 【0022】 Advantageously, this aspect is implemented in an NR environment such as 5G. 【0023】 According to another aspect of the present invention, there is provided a method for use in a process of requesting resources from a source integrated access backhaul (IAB) topology to a target IAB topology in a communication system, wherein each of the source IAB topology and the target IAB topology includes a set of IAB nodes and a donor aggregation unit (CU), and the method at the source donor CU of the source IAB topology includes transmitting a message related to a request for resources associated with the IAB nodes of the source IAB topology to the target donor CU of the target IAB topology, the message including an indication for identifying the IAB nodes of the source IAB topology as mobile IAB nodes. 【0024】 Optionally, for signaling efficiency, the indication that identifies the IAB node as a mobile IAB node may include a boolean value. 【0025】 Optionally, to assist in determining prioritization, the message may include information regarding the number of user devices served by the mobile IAB node. 【0026】 Optionally, the message includes a quality of service level. For example, the quality of service level indicates at least one quality of service parameter among a priority level, a required packet delay budget, a required packet error rate, and a maximum data burst level. 【0027】 To accurately indicate requirements, the quality of service level may include a combination of multiple quality of service parameters. 【0028】 Optionally, the process of requesting resources includes IAB inter-CU topological redundancy procedures. 【0029】 Optionally, the process of requesting resources includes IAB inter-CU backhaul wireless link failure recovery. 【0030】 Optionally, the process of requesting resources includes re-establishment request procedures. 【0031】 Optionally, the process of requesting resources includes inter-CU topology adaptation procedures. 【0032】 Optionally, the process of requesting resources includes a complete migration of the IAB node. This is, for example, a common migration of mobile IAB mounted on a bus or a train. 【0033】 Optionally, the IAB node includes a distributed unit (DU) part, and the full migration includes migration of the DU part of the IAB node from the source donor CU to the target donor CU. 【0034】 Optionally, the process of requesting resources includes a user equipment handover (HO) procedure. 【0035】 Optionally, the process of requesting resources includes a user equipment conditional handover (CHO) procedure. 【0036】 Optionally, the indication for identifying the IAB node as a mobile IAB node includes an indication indicating that a UE during handover is being served by the mobile IAB node. 【0037】 Optionally, the method further includes determining that the IAB node in the source IAB topology is a mobile IAB node before the step of transmitting a message. 【0038】 Optionally, determining that the IAB node is a mobile IAB node includes obtaining a user equipment context. 【0039】 Optionally, the method further includes receiving a request for user equipment context from the target donor CU. 【0040】 According to another aspect of the present invention, there is provided a method for use in a process of requesting resources for a target integrated access backhaul (IAB) topology by a source IAB topology of a communication system, each of the source IAB topology and the target IAB topology including a set of IAB nodes and a donor central unit (CU), the method at the target donor CU of the target IAB topology including receiving a message related to a request for resources associated with an IAB node of the source IAB topology, obtaining from the message an indication identifying whether the associated IAB node of the source IAB topology is a mobile IAB node, and determining whether to accept or reject the request depending on the indication. 【0041】 Thus, resource requests involving mobile IABs can be prioritized by the target donor. 【0042】 Optionally, the method includes prioritizing the request depending on the indication. 【0043】 Optionally, the method includes always accepting the request depending on the indication. 【0044】 Optionally, to manage the load, determining whether to accept or reject the request further depends on the current load of the target IAB topology. 【0045】 Alternatively, or additionally, determining whether to accept or reject the request may further depend on the current load of the backhaul link in the target IAB topology. 【0046】 Optionally, requesting resources is related to a request for partial migration of the IAB nodes of the source IAB topology. 【0047】 Optionally, the IAB node includes a mobile termination (MT) part, and the partial migration includes migration of the MT part of the IAB node from the source donor CU to the target donor CU. 【0048】 Optionally, requesting a resource is related to a request to establish dual connectivity between the IAB node and the source donor CU and the target donor CU. 【0049】 According to another aspect of the present invention, there are provided a source donor device and a target donor device adapted to implement the method described herein. 【0050】 According to one aspect of the present invention, there is provided a source donor central unit (CU) that manages a process of requesting resources from a source integrated access backhaul (IAB) topology to a target IAB topology in a communication system, the source donor CU including means for transmitting, to a target donor CU of the target IAB topology, a message related to a request for resources associated with an IAB node of the source IAB topology, the message including an indication identifying the IAB node of the source IAB topology as a mobile IAB node. 【0051】 According to one aspect of the present invention, there is provided a target donor central unit (CU) that manages a process of requesting resources from a source integrated access backhaul (IAB) topology to a target IAB topology in a communication system, the target donor CU including means for receiving a message related to a request for resources associated with an IAB node of the source IAB topology, means for obtaining, from the message, an indication identifying whether the IAB node of the source IAB topology is a mobile IAB node, and means for determining whether to accept or reject the request depending on the indication. 【0052】 Optionally, the means for determining is configured to prioritize the requests depending on the indication. 【0053】 Optionally, the means for determining is configured to always accept the requests depending on the indication. 【0054】 Another aspect of the invention relates to a computer program comprising instructions which, when executed by a computer, cause the computer to carry out the methods described herein. This computer program may be embodied on a transitory or non-transitory computer-readable medium. 【0055】 Further exemplary features of the invention are described in the other independent and dependent claims. 【0056】 The features in one aspect of the invention can be applied to other aspects of the invention in any suitable combination. In particular, aspects of the method can be applied to aspects of the apparatus / device / unit and vice versa. 【0057】 Furthermore, functions implemented in hardware may sometimes be implemented in software and vice versa. References to software and hardware features herein should be construed accordingly. For example, according to another aspect of the invention, when a program is executed by a processing unit, there is provided a computer program comprising instructions for causing the processing unit to carry out the method of any of the above aspects or embodiments, and a computer-readable storage medium carrying the computer program. 【0058】 It should also be understood that specific combinations of the various features described and defined in any aspect of the invention can be implemented and / or supplied and / or used independently. 【Brief Description of the Drawings】 【0059】 Next, various aspects of the present invention will be described by way of example only, with reference to the following drawings: 【0060】 【Figure 1】 It is a schematic diagram of a communication system capable of implementing the present invention according to one or more exemplary embodiments. 【Figure 2】 It schematically shows a stack of several protocol layers related to the operation of IAB. 【Figure 3】 It is a schematic diagram showing the format of a BAP protocol data unit (PDU) or packet. 【Figure 4】 It is a schematic diagram of an exemplary IAB communication system (or IAB network system) in which embodiments and examples of the present invention can be implemented. 【Figure 5】 It is a schematic diagram of another example of an IAB communication system (or IAB network system) in which embodiments and examples of the present invention can be implemented. 【Figure 6】 It shows an example of an IAB node architecture that enables complete migration from a source IAB topology to a target IAB topology. 【Figure 7】 It is a simplified flowchart of exemplary steps for performing a complete migration of an IAB node, including handover of UEs served by the migrating IAB node. 【Figure 8】 It is a simplified flowchart of exemplary steps for performing a partial migration of a mobile IAB node according to one or more embodiments of the present invention. 【Figure 9】 It is a simplified flowchart of an example of a procedure for performing dual connectivity of a mobile IAB node. 【Figure 10】 It is a simplified flowchart of an example of steps for performing radio link failure (RLF) recovery of a mobile IAB node. 【Figure 11】 It is a flowchart showing an example of a procedure for performing traffic migration from a first IAB topology to a second IAB topology. 【Figure 12】 A simplified flowchart showing exemplary steps for performing a handover of a UE served by a mobile IAB node that fully migrates from a source IAB topology to a target IAB topology. 【Figure 13】 A schematic diagram of wireless communication. 【Figure 14a】 A flowchart of an exemplary method for a source donor CU to manage an indication indicating that a partial migration or dual connectivity setup is associated with a mobile IAB node. 【Figure 14b】 A flowchart of an exemplary method for a target donor CU to manage an indication indicating that a partial migration or dual connectivity setup is associated with a mobile IAB node. 【Figure 15a】 A flowchart of an exemplary method for a source donor CU to manage an indication indicating that a radio link failure (RLF) recovery is associated with a mobile IAB node. 【Figure 15b】 A flowchart of an exemplary method for a target donor CU to manage an indication indicating that a radio link failure (RLF) recovery is associated with a mobile IAB node. 【Figure 16a】 A flowchart of an exemplary method for a source donor CU to manage an indication indicating that traffic migration is associated with a mobile IAB node. 【Figure 16b】 A flowchart of an exemplary method for a target donor CU to manage an indication indicating that traffic migration is associated with a mobile IAB node. 【Figure 17a】 A flowchart for a source donor CU to manage an indication indicating that a UE handover is associated with a mobile IAB node. 【Figure 17b】A flowchart for a target donor CU to manage an indication indicating that a UE handover is related to a mobile IAB node. 【DETAILED DESCRIPTION OF THE INVENTION】 【0061】 FIG. 1 shows an exemplary wireless communication system 100, particularly a mobile wireless communication system such as a 5th generation (5G) New Radio (NR) system including a wireless integrated access backhaul network supporting mobile IAB nodes. In the following description, embodiments and examples of the present invention will be described with respect to the 5G_NR system, but it should be understood that the present invention is not intended to be limited to the 5G_NR system and can be used in any wireless communication system having a mobile base station. In particular, although terms specific to 5G are mainly used in the following description, it should be understood that such terms are also applicable to elements or processes performing equivalent functions in other communication systems. 【0062】 System 100 includes a plurality of UEs (user equipments) 132, 133, 131, 134, a remote core network 110, a main base station 120, two IAB (integrated access backhaul) stations or IAB nodes 121, 122 (hereinafter also referred to as IAB nodes), and a mobile IAB (integrated access backhaul) station 123 mounted on a vehicle 105 (e.g., a bus, train, taxi, car, etc.). 【0063】 The main base station 120, also referred to as the IAB donor 120, is connected to the core network 110 through a wired link 101, preferably an optical fiber or any other wired means. In embodiments and examples of the present invention, the IAB donor 120 is a 5G_NR gNB having additional functions supporting the IAB function as defined in the 3GPP TS38.300 v17.0.0 specification. 【0064】 To extend the network coverage of the IAB donor 120 and reach the remote UEs 132, 133, and 131, the IAB stations 121 and 122, also referred to as IAB nodes 121 and 122, are installed by the operator. The IAB nodes 121 and 122 function as relay nodes between the IAB donor 120 and the UEs 132 and 133, thereby overcoming the reachability problem caused by the presence of the building 108 that obstructs the propagation of radio waves (thus causing an obstacle to the direct connection and further communication between the UE and the IAB donor 120). This is particularly true when the communication between the IAB donor 120 and the UEs 132 and 133 operates at millimeter-wave frequencies that are very sensitive to the shadowing phenomenon. 【0065】 The IAB donor 120 also provides services to the directly connected UE 134. 【0066】 The mobile IAB station 123, also referred to as the mobile IAB node 123 or mIAB node 123, is an IAB node mounted on the vehicle 105, which also provides network coverage and capacity expansion, enabling the IAB donor 120 to reach not only in-vehicle remote UEs such as the remote UE 135 but also UEs or UEs in the vicinity of the IAB node 123 such as the remote UE 136. 【0067】 The IAB donor 120 and the IAB nodes 121 and 122 thus form a backhaul network or IAB network, or IAB topology, that accommodates the UEs 132, 133, 131, 134, 135, and 136. Hereinafter, the terms IAB network and IAB topology are used interchangeably. 【0068】 The specifications of the integrated access backhaul (IAB) span multiple 3GPP standard documents as follows: -TS38.300 RAN Architecture (V17.0.0), -TS38.321 MAC Protocol (V17.0.0), -TS 38.331 Radio Resource Control (RRC) Protocol (V17.0.0), -TS 38.340 Backhaul Adaptation Protocol Layer (V17.0.0), -TS 38.401 RAN Architecture (V17.0.0), -TS 38.473 F1 Application Protocol (V17.0.0). 【0069】 Since IAB donor 120 and IAB nodes 121, 122, 123 are each connected to UEs 134, 131, 132, 133, 135, 136 respectively, they are regarded as access IAB nodes for the UEs to which they are connected. 【0070】 The IAB donor 120 is a logical node that provides an NR-based wireless backhaul and is composed of a centralized unit (CU or gNB-CU function) and a connected donor distributed unit (DU or gNB-DU function). The IAB donor CU or donor CU (hereinafter also referred to as IAB donor CU) hosts upper layer protocols such as the PDCP (Packet Data Convergence Protocol) and RRC (Radio Resource Control) protocols to control the operation of one or more DUs, and each of one or more IAB donor DUs or donor DUs (hereinafter also referred to as IAB donor DUs) includes lower layer protocols such as the RLC, MAC, and physical layer protocols. The IAB donor CU or donor CU and the IAB donor DU or donor DU may be located at separate locations or may be located within the same physical device. The gNB-DU function is defined in 3GPP TS 38.401. The purpose of the gNB-DU function is to terminate the NR access interface for the UE and the next-hop IAB node and to terminate the F1 protocol for the IAB donor gNB-CU function shown in Figures 2(a) and 2(b) described below. 【0071】 The IAB node can provide multiple radio sectors and is wirelessly backhauled to the IAB donor 120 via one-hop or multiple hops through intermediate IAB nodes. These form a directed acyclic graph (DAG) topology rooted at the IAB donor. 【0072】 The IAB node consists of an IAB-DU and an IAB-MT (IAB-mobile terminal). The gNB-DU function on the IAB node is also called the IAB-DU and enables a downstream (UE direction) connection to the next-hop IAB. The IAB-MT function includes, for example, physical layer, layer 2, RRC, and NAS (non-access stratum) functions and connects to the gNB-DU of the upstream IAB node (including the IAB donor 120 when connecting to the gNB-CU of the IAB donor and connecting to the core network 110 in cases such as initialization, registration, and configuration). 【0073】 In this DAG topology, adjacent nodes on the interface of the IAB-DU are called child nodes, and adjacent nodes on the interface of the IAB-MT are called parent nodes. Furthermore, the direction towards the child node is called downstream, and the direction towards the parent node is called upstream. 【0074】 The IAB donor 120 performs centralized resource management, topology management, and route management for the entire IAB topology. This includes, for example, configuring IAB nodes according to the network topology to perform proper routing of data packets. 【0075】 Figures 2(a) and 2(b) schematically show the stacks of some protocol layers related to the operation of IAB. 【0076】 The F1 interface supports the exchange of signaling information between endpoints and the transmission of data to each endpoint. From a logical perspective, the F1 interface is a point-to-point interface between endpoints. 【0077】 In 5G_NR, F1-C is a functional interface between the IAB donor CU and the IAB node DU (e.g., IAB node 2) in the control plane (CP), and between the IAB donor CU and the IAB donor DU. F1-U is a functional interface in the user plane (UP) of the same unit. F1-C and F1-U are indicated by reference number 212 in Figure 2(a). In this example, F1-U and F1-C are transmitted via two backhaul hops (from the IAB donor to IAB node 1, and from IAB node 1 to IAB node 2). 【0078】 In the user plane, box 210 of the IAB donor CU and the IAB node DU refers to the GTP-U layer, and box 211 refers to the UDP layer. GTP-U is the abbreviation of the GPRS tunneling protocol user plane. The GTP-U tunnel is used to transmit encapsulated PDUs and signaling messages between a pair of predetermined GTP-U tunnel endpoint pairs (see 3GPP TS29.281 for details), here referring to box 210 of the IAB donor CU and the IAB node DU. The well-known UDP (User Datagram Protocol) is a transport layer protocol that provides a best-effort datagram service and is suitable for use with the IP protocol. 【0079】 In the control plane, box 210 indicates the F1AP (F1 Application Protocol) layer, and box 211 indicates the SCTP (Stream Control Transmission Protocol) layer. The F1 Application Protocol (defined in 3GPP TS38.473 and TS38.401) provides signaling services or UE-related services between the IAB donor CU and the IAB node DU. These services include, for example, initialization, configuration, etc. The well-known SCTP layer provides reliable in-sequence transfer of messages with congestion control. 【0080】 F1-U and F1-C rely on the IP transport layer between the IAB donor CU and the IAB node DU as defined in 3GPP TS38.401. 【0081】 The transport between the IAB donor DU and the IAB donor CU uses the IP transport layer over various media such as wires or optical fibers when the IAB donor CU is remote from the IAB donor DU, or when the IAB donor CU and the IAB donor DU are local as virtual instances on the same physical machine. The IAB-specific transport between the IAB donor CU and the IAB donor DU is specified in 3GPP TS38.401. 【0082】 L1 and L2 in the figure represent the transport layer and the physical layer suitable for the media used, respectively. 【0083】 The IP layer can also be used for traffic other than F1, such as operation, administration, and maintenance traffic. 【0084】 In the wireless backhaul, the IP layer is transmitted on the backhaul adaptation protocol (BAP) sublayer that enables multi-hop routing. The BAP sublayer is specified in TS38.340. 【0085】 The IP traffic of the IAB-DU is routed over the wireless backhaul via the BAP sublayer. In the downstream direction, the upper-layer packets are encapsulated by the BAP sublayer of the IAB donor DU to form BAP packets or packet data units (PDUs) or data packets. The BAP packets are routed by the BAP layer or entity of the intermediate IAB node (and the corresponding BAP entity of the IAB-DU and the IAB-MT). The BAP packets are finally decapsulated by the BAP sublayer of the destination IAB node (which may be an access IAB node if the upper-layer packet of the BAP packet is for the UE). 【0086】 In the upstream direction, the upper-layer packet is encapsulated by the BAP sublayer at the initiator IAB node (which may also be an access IAB node if the upper-layer packet is from a UE), and a BAP packet or a protocol data unit (PDU) or a data packet is formed. The BAP packet is routed by the BAP layer of the intermediate IAB node (and the corresponding BAP entities of the IAB-DU and IAB-MT) (if any). The BAP packet is finally decapsulated by the BAP sublayer of the IAB donor DU. 【0087】 In the BAP sublayer, the packet is routed based on the BAP routing ID. This BAP routing ID is described in the BAP header of the BAP packet and is set by the BAP sublayer of the transmitting-side IAB donor DU or the initiator IAB node (the network node of the IAB network that generates the BAP packet). 【0088】 Figure 3 shows the format of the protocol data unit (PDU) or packet of the BAP data. This is defined in Section 6.2 of the standardized version of 3GPP TS38.340 Release 17.0.0. 【0089】 The payload part 307 is usually an IP packet. The header 30 includes fields 301 to 306. Field 301, named the D / C field, is a boolean value indicating whether the corresponding BAP packet is a BAP data packet or a BAP control packet. Fields 302 to 304 are 1-bit reserved fields, preferably set to 0 (ignored by the receiver). 【0090】 Fields 305 and 306 together indicate the BAP routing ID of the BAP packet. The BAP address field 305, also called the DESTINATION field, is located in the leftmost 10 bits, and the BAP path ID field 306, also called the PATH field, is located in the rightmost 10 bits. 【0091】 Field 305 carries the BAP address of the destination IAB node or IAB donor DU of the BAP packet (i.e., on the BAP sublayer). For routing purposes, each IAB node and IAB donor DU in the IAB network is configured (by the IAB donor CU of the IAB network) with a specified unique BAP address. Field 306 carries a path ID that identifies the routing path that the BAP packet should follow to this destination in the IAB topology. For routing purposes, the routing path including the path ID is configured (by the IAB donor CU of the IAB network) at the IAB node. 【0092】 The BAP header is added when the packet arrives from the upper layer at the BAP layer and is removed by the BAP layer when the destination node is reached. The selection of the BAP routing ID of the packet is configured by the IAB donor CU. 【0093】 For example, when a BAP packet is generated by a node (i.e., by the IAB donor DU for downlink transmission or by the initiator (which may be an access IAB node if the upper layer packet comes from a UE) for uplink transmission), the BAP header with the BAP routing ID is constructed by this node according to the configuration table defined in 3GPP TS38.340. This table is called the "Downlink Traffic to Routing ID Mapping Configuration" table in the IAB donor DU and the "Uplink Traffic to Routing ID Mapping Configuration" table in the initiator IAB node. At an intermediate IAB node, the BAP header fields are already specified for the BAP packet to be forwarded. 【0094】 As described above, these configuration tables that define the BAP path (and thus the routing strategy and the configuration of IAB nodes given the IAB network topology) are typically defined by the IAB donor CU and sent to the IAB nodes to configure the IAB nodes. 【0095】 To transmit messages over the radio medium of 5G_NR, each IAB node further implements three sublayers (RLC, MAC, PHY) below the BAP sublayer. The RLC (Radio Link Control) sublayer performs packet segmentation and reconstruction. It also plays a role in requesting retransmission of lost packets. Refer to TS38.322 for details of the RLC layer. The MAC (Medium Access Control) protocol sublayer is responsible for selecting the available transmission format for user data and mapping logical channels to transport channels. MAC also handles part of the hybrid automatic repeat request scheme. Details of the MAC layer are described in TS38.321. On the emitter or transmitter side, MAC encapsulates the data packets issued from the RLC. MAC adds a header containing the information necessary for the MAC function. On the receiving side, MAC decapsulates the data packets issued from the PHY, removes the header, and passes the remaining data to the RLC. The PHY sublayer converts the stream of information into a physical modulation signal and modulates the carrier frequency on the emitter side to provide an electrical interface to the transmission medium (air). The PHY layer is described in TS38.201, TS38.211, TS38.212, TS38.213, TS38.214. 【0096】 To send messages towards the user plane or the control plane, two additional sublayers are used in the UE and the IAB donor CU. The PDCP (Packet Data Convergence Protocol) sublayer and the SDAP (Service Data Adaptation Protocol) sublayer for user plane communication or the RRC (Radio Resource Control) sublayer for control plane communication. 【0097】 The PDCP sublayer processes IP header compression / decompression, encryption / decryption, and, if necessary, the integrity of data packets. The PDCP sublayer numbers the packets on the transmitting side and rearranges the packets on the receiving side. The PDCP sublayer is described in 3GPP TS38.323. 【0098】 The SDAP sublayer 220 for the user plane processes the quality of service. It is described in TS38.324. On the UE side, the SDAP sublayer exchanges payload data with the user's application (such as voice, video, not shown in the figure). On the IAB donor CU side, the SDAP sublayer exchanges data with the core network 110 (such as Internet traffic, cloud, etc.). 【0099】 The RRC sublayer 220 of the control plane processes the configuration of the protocol entities of the user plane protocol stack. It is described in TS38.331. In particular, it is responsible for the broadcast of information necessary for the UE to communicate with the cell, the transmission of paging messages, connection management including bearer setup, mobility functions, measurement settings and reports, and the processing of device functions. 【0100】 The interfaces (both CP and UP) between nodes using the PDCP, RLC, MAC, and PHY layers are called NR-Uu. This is mainly related to the interface with the UE. 【0101】 The interfaces (both CP and UP) between nodes using the BAP, RLC, MAC, and PHY layers are named the backhaul RLC channel (BH_RLC channel). This is mainly related to the interface between IAB nodes. 【0102】 NR-Uu is the interface between the UE and the radio access network (i.e., the access IAB node (both CP and UP)). 【0103】 Figure 2b is from 3GPP TS38.300 v17.0.0 and shows the protocol stack for supporting the RRC and NAS connections of the IAB-MT. The non-access stratum (NAS) protocol processes messages between the core network and the user equipment (IAB node). NAS manages the establishment of communication sessions and maintains communication as the IAB node or user equipment moves. 5G NAS is described in 3GPP TS24.501. The access and mobility management function (AMF) of the 5G core is a function within the core network that receives all connection and session-related information from the UEs connected to the IAB node and also receives similar information about the IAB node. The AMF is only responsible for handling connection and mobility management tasks. 【0104】 The IAB-MT establishes signaling radio bearers (SRBs) (bearers that transmit RRC and NAS messages) with the IAB donor CU. These SRBs are transmitted via the NR-Uu interface between the IAB-MT and its parent node. 【0105】 Figure 4 shows an example of an IAB communication system (or IAB network system) 400 in which embodiments and examples of the present invention can be implemented. In one example implementation, the BH radio link operates in a millimeter-wave frequency band (i.e., 30 GHz or higher) that is very sensitive to radio channel interference. Since the IAB network is also called the IAB topology or topology, in this application, the terms IAB network, IAB topology, and topology are used interchangeably. 【0106】 The IAB communication system 400 is composed of two IAB networks or IAB topologies 4001 and 4002. Each IAB topology consists of a set of IAB nodes (for example, the set may be composed of multiple IAB nodes or at least one IAB node), and an IAB donor CU for controlling or managing the multiple IAB nodes. The set of IAB nodes can include an initiator IAB node that generates BAP packets, and one or more IAB nodes such as intermediate IAB nodes or relay IAB nodes. Each of the IAB nodes communicates with at least one other IAB node via a wireless backhaul (BH) link. Although two IAB topologies 4001 and 4002 are shown in FIG. 4, the present invention is not limited to the two IAB topologies 4001 and 4002, and as described above, it can be implemented in an IAB communication system including two or more IAB topologies each consisting of a set of IAB nodes and an IAB donor CU. 【0107】 The IAB topology 4001 includes an IAB donor CU 401 (identified as donor 1-CU in FIG. 4), its associated IAB donor DUs (IAB donor DU 403 (identified as donor 1-DU1 in FIG. 4) and IAB donor DU 404 (identified as donor 1-DU2 in FIG. 4)), as well as a plurality of IAB nodes 410, 420, 430, and 460 similar to IAB nodes 121 and 122, and an IAB node 470 similar to mobile IAB node 123. All IAB nodes can be access nodes that provide services to UEs such as UE 480 served by mobile IAB node 470. The IAB topology 4001 is transparent to UE 480 connected to donor CU 401 via the DU part / unit 472 (mDU) of mobile IAB node 470. 【0108】 The IAB topology 4002 includes an IAB donor CU 402 (identified as donor 2-CU in FIG. 4), an associated IAB donor DU 405 (identified as donor 2-DU1 in FIG. 4), and a plurality of IAB nodes 440 and 450 similar to IAB nodes 121 and 122. 【0109】 As described above, each IAB node includes a mobile terminal (MT) part / unit controlled and configured by the IAB donor using RRC messaging defined in 3GPP TS38.331, and a distributed unit (DU) part controlled and configured by the IAB donor using F1-AP messaging defined in 3GPP TS38.473. For example, the IAB node 410 includes an MT part / unit 411 and a DU part 412. 【0110】 The wired backhaul IP network interconnects IAB donor CUs 401 and 402, and IAB donor DUs 403, 404, and 405 via a wired link 406. For example, this wired link is composed of an optical fiber cable. 【0111】 IAB donor CU 401, IAB donor DUs 403 and 404, IAB nodes 410, 420, 430, 460, 470, and IAB node 470 are part of the same IAB network or IAB topology 4001 configured, managed, or controlled by IAB donor CU 401. 【0112】 IAB donor CU 402, IAB donor DU 405, and IAB nodes 440 and 450 are part of the same IAB network or IAB topology 4002 configured, managed, or controlled by IAB donor CU 402. 【0113】 The IAB node 470 belongs to the IAB network 4001 (with the IAB node 430 as its parent via the BH link 4030), but since it is close to the IAB network 4002, especially the IAB node 450, the IAB node 470 can be connected to the IAB node 450 (functioning as the parent node of the IAB node 470) via the wireless BH link 4050. Such a connection to the IAB node 450 is possible not only in addition to the connection to the IAB node 430 but also instead of the connection to the IAB node 430, and can occur for a stationary IAB node or, as in the case of the IAB node 470, a mobile IAB node moving, for example, in the direction of the IAB topology 4002, with a very high probability. 【0114】 According to the IAB framework release 17, several scenarios are conceivable. 【0115】 As a first scenario, as described in section 8.17.2.1 of TS38.401 v17.0.0, the topology redundancy procedure can be applied. 【0116】 When the IAB node 470 is initially connected to a single IAB topology (e.g., IAB topology 4001), the MT part / unit 471 (mMT) of the IAB node 470 periodically performs cell search procedures and attempts to detect the PSS (Primary Synchronization Signal) and SSS (Secondary Synchronization Signal) as defined in 3GPP TS38.300. The IAB node can report the presence of a new managed cell, such as one cell managed by, for example, the IAB node 450, to the donor CU 401 through a measurement report. Based on the analysis of the measurement report, the donor CU 401 can request the donor CU 402 to establish the dual connectivity of the IAB node 470 by an additional connection via the IAB node 450. The donor CU 402 can accept this request and proceed with the connection of the IAB node 470 according to the procedures described in section 10.2 of TS37.340 v17.0.0. As a result, the IAB node 470 belonging to the IAB topology 4001 is also connected to the IAB node 450 belonging to the IAB topology 4002 and may be called a boundary node between the IAB topology 4001 and the IAB topology 4002. In practice, the IAB node 470 maintains an F1 connection and an RRC connection to the donor CU 401, which can be called an F1-terminated IAB donor CU, and has another RRC connection to the donor CU 402, which can be called a non-F1-terminated IAB donor CU. 【0117】 Since the IAB node or boundary node 470 is part of the IAB topology 4001 from the perspective of the F1 connection, it is controlled (e.g., configured and managed) by the IAB donor CU 401 of the IAB topology 4001. Through the second RRC connection, the donor CU 402 allocates a second BAP address used to route packets through the IAB topology 4002. 【0118】 In fact, the IAB donor CU401 can balance the traffic load of the IAB topology 4001 by offloading or migrating some of the traffic (data / user traffic or control traffic) that was originally scheduled to be routed via the IAB nodes 410, 430 and the BH link 4030, taking advantage of the dual connectivity of the IAB node 470 between the IAB topologies 4001 and 4002. In this case, as described in section 8.17.2.1 of TS38.401 v17.0.0, the donor CU401 triggers the IAB transport migration management procedure defined in section 8.5.2 of TS38.423 v17.0.0 by exchanging the protocol messages shown in Figure 11. The donor CU402 can reject the request for some or all of the traffic to be migrated, for example, due to the load problem in the IAB topology 4002. 【0119】 As a second scenario of FIG. 4, the BH link or BH wireless link 4030 may experience a radio link failure due to some unexpected interference or shadowing phenomenon. For this reason, the IAB node 470 may lose its connection with the IAB node 430 and declare a radio link failure (RLF) of the BH link 4030. Thereafter, the IAB node 470 attempts to re - establish a connection with the same parent IAB node or a different parent IAB node (or donor DU). Thus, the IAB node 470 may attempt to participate in the IAB topology 4002 managed by the IAB donor CU 402 through a new connection via the BH link 4050 and a new parent IAB node 450. In this case, as described in section 8.17.4 of TS38.401 v17.0.0, when the IAB - MT of an IAB node declares a backhaul RLF, the inter - CU backhaul RLF recovery procedure can be applied, which allows the IAB node to recover to another parent node under a different IAB donor CU. In such a procedure, the donor CU 402 sends a request to the donor CU 401 to obtain the context of the IAB node 470. Based on the response from the donor CU 401, the donor CU 402 can accept the connection of the IAB node 470. In fact, the IAB node 470 maintains an F1 connection to the donor CU1, which can be called the F1 - terminated IAB donor CU, and has an RRC connection to the donor CU 402, which can be called the non - F1 - terminated IAB donor CU. 【0120】 Next, the IAB donor CU 401 can request the migration of the traffic related to the IAB node 470 to the IAB topology 4002. In this case, the donor CU 401 triggers the IAB transport migration management procedure defined in section 8.5.2 of TS38.423 v17.0.0 and performs the exchange of protocol messages shown in FIG. 11. The donor CU2 can reject the request for some or all of the traffic to be migrated, for example, due to the load problem in the IAB topology 4002. 【0121】 As a third scenario of FIG. 4, the IAB node 470 is singly connected to the parent IAB node 430 and may be partially migrated towards the IAB topology 4002. That is, its RRC connection is migrated from the old parent node to the new parent node, and the old parent node and the new parent node are served by different IAB donor CUs. In fact, based on the measurement report provided by the IAB node 470, the donor CU 401 can detect that the IAB node 470 has a better connection via the cell managed by the IAB node 450 belonging to the IAB topology 4002. Thereafter, the donor CU 401 can trigger the IAB inter-CU topology adaptation procedure described in section 8.17.3.1 of TS38.401 v17.0.0. In this procedure, the donor CU 401 sends a handover request for the IAB node 470 together with the information for the donor CU 402 to establish an RRC connection to the IAB node 470. Based on this information, the donor CU 402 can accept the handover request and proceed with the admission of the IAB node 470, which remains a border node belonging to the IAB topology 4001 and has an F1 connection to the donor CU 401 and an RRC connection to the donor CU 2. 【0122】 Next, the IAB donor CU 401 can request the migration of the backhaul traffic associated with the IAB node 470 to the IAB topology 4002. In this case, the donor CU 401 also triggers the IAB transport migration management procedure defined in section 8.5.2 of TS38.423 v17.0.0 and performs the exchange of protocol messages shown in FIG. 11. The donor CU 2 can reject the request for some or all of the traffic to be migrated, for example, due to a load problem in the IAB topology 4002. 【0123】 If the IAB node 470 has several child IAB nodes, the same procedure applies as specified in section 8.17.3.2 of TS38.401 v17.0.0, and the donor CU 401 additionally configures the migration node and the child IAB nodes in order to correctly route the BAP packets. 【0124】 In this scenario, the IAB topology 4001 may be referred to as the source IAB network or source IAB topology, and the topology 4002 will be referred to as the target IAB network or target IAB topology. Also, the donor CU 401 is called the source IAB donor CU or source donor CU, and the donor CU 402 is called the target IAB donor CU or target donor CU. 【0125】 In all of the three scenarios described above, the UE 480 is still connected to the donor CU 401 via the DU part / unit 472 (mDU) of the mobile IAB node 470. If the IAB node 470 has several child IAB nodes, such child IAB nodes still belong to the IAB topology 4001 and are fully controlled by the donor CU 401 (via F1 and RRC connections). 【0126】 FIG. 5 shows another example of an IAB communication system (or IAB network system) 500 in which embodiments and examples of the present invention can be implemented. This is similar to the system 400 described in FIG. 4 having two IAB topologies 5001 and 5002. The IAB topology 5001 includes an IAB donor CU 501 (identified as donor 1-CU in FIG. 5), its associated IAB donor DUs, IAB donor DUs 503 (identified as donor 1-DU1 in FIG. 5) and 504 (identified as donor 1-DU2 in FIG. 5), and a plurality of IAB nodes 510, 520, 530, and 560 similar to IAB nodes 121 and 122. The IAB topology 5002 includes an IAB donor CU 502 (identified as donor 2-CU in FIG. 5), and its associated IAB donor DU 505 (identified as donor 2-DU1 in FIG. 5), and a plurality of IAB nodes 540 and 550 similar to IAB nodes 121 and 122, and an IAB node 570 similar to mobile IAB node 123. The IAB topology 5002 is transparent to the UE 580 that connects to the donor CU 402 via the DU part / unit 572 (mDU) of the mobile IAB node 570. 【0127】 In fact, FIG. 5 shows the result of a complete migration of the IAB node 470 of FIG. 4 (i.e., the IAB node 570 of FIG. 5), and it now fully belongs to the IAB topology 4002 of FIG. 4 (i.e., the IAB topology 5002 of FIG. 5). 【0128】 With partial migration (described in FIG. 4), the IAB-MT part / unit (mMT) (471 in FIG. 4) can be quickly migrated to the target IAB donor CU (i.e., donor CU 402 in FIG. 4) and quickly switched back to the source IAB donor CU (i.e., donor CU 401 in FIG. 4). Thus, partial migration can be advantageously used in situations where donor-to-donor migration is required temporarily, such as during traffic peaks or when a temporary RLF is detected on the BH link. 【0129】 In the context of a full migration, both the IAB-MT part / unit 571 (mMT) and the IAB-DU part / unit 572 (mDU) of the IAB node 570 are migrated to the target donor CU502. Full migration is suitable for mobile IAB nodes that move and may cross several IAB topologies during that movement. 【0130】 In the full migration of the IAB node 570, UEs served, such as the UE580, are also migrated from the source donor CU401 to the target donor CU402. UE migration is performed by the procedures described in Section 9.2.3.2 of TS38.300 v17.0.0 and explained with reference to Figures 6, 7, and 12, which are based on the handover procedures. 【0131】 Figure 6 shows an example of an IAB node architecture 600 that enables full migration from a source IAB topology to a target IAB topology, along with a smooth UE handover. The mobile IAB node 601 is composed of an IAB-MT part / unit 610 (mIAB-MT), an IAB-DU1 part / unit 611 (mIAB-DU1), and an IAB-DU2 part / unit 612 (mIAB-DU2), similar to the IAB node 570. In some embodiments, they share the same physical layer (i.e., the same hardware resources), while in other embodiments, they rely on separate physical layers. During the full migration phase, both logical DUs are active, with one logical DU terminating the F1 interface with the source donor CU and the other logical DU terminating the F1 interface with the target donor CU. Otherwise, only one logical DU is sufficient for the operation of the IAB. 【0132】 Before full migration, the UE 602 is connected to the source donor CU via, for example, the logical DU 611 (mIAB-DU1) having the access link 621, while the logical DU 612 (mIAB-DU2) is deactivated. At the time of full migration, the logical DU 612 (mIAB-DU2) is activated and connected to the target donor CU, to which the UE 602 can also be connected via the logical DU 612 (mIAB-DU2) with the link 622. Activation may be triggered by the source donor CU using the message "GNB-CU CONFIGURATION_UPDATE" containing the information element of the list of cells to be activated as defined in TS 38.473 v17.0.0. When the handover of the UE 602 from the cell controlled by the logical DU 611 (mIAB-DU1) to the logical DU 612 (mIAB-DU2) controlled by the cell is completed, the logical DU 611 (mIAB-DU1) may be deactivated. Deactivation may be triggered by the source donor CU 703 using the message "F1 REMOVAL REQUEST" defined in TS 38.473 v17.0.0 after detection of the completed handover of the UE. 【0133】 Figure 7 is a simplified flowchart 700 showing an example of the steps for performing a full migration of an IAB node, including the handover of a UE served by the migrating IAB node. 【0134】 This figure shows a UE 701 such as UE 580, a source donor CU 703 such as donor CU 501, a target donor CU 707 such as donor CU 502, and a core network (5GC) 702 such as core network 110. This figure also shows mobile IAB nodes such as IAB nodes 570 and 601, which are composed of an IAB-MT part / unit 704 (mIAB-MT), an IAB-DU1 part / unit 705 (mIAB-DU1), and an IAB-DU2 part / unit 706 (mIAB-DU2). In some embodiments, they share the same physical layer (i.e., the same hardware resources), while in other embodiments, they rely on separate physical layers. 【0135】 At the beginning of the flowchart, the mobile IAB node fully belongs to the source IAB topology controlled by the source donor CU 703. UE 701 is served by the mobile IAB node via a cell controlled by mIAB-DU1 705, and the logical mIAB-DU2 706 is inactive. Downlink user data is provided by 5GC 702 to the source donor CU 703 via bearer 720, then sent to the logical DU 705 (mIAB-DU1) of the mobile IAB node via the backhaul bearer 721 of the source IAB topology, and finally sent to UE 601 via the data radio bearer 722. Uplink user data (not shown in the figure) is sent through similar bearers in the opposite direction. 【0136】 The first step 711 corresponds to either the partial migration of the IAB node described in FIG. 8, the establishment of the dual connectivity of the mobile IAB node described in FIG. 9, or the RLF recovery of the mobile IAB node described in FIG. 10. After this step, the mobile IAB node becomes a boundary node between the source IAB topology controlled by the IAB donor CU 703 and the target IAB topology controlled by the target donor CU 707. 【0137】 The second step 712 corresponds to the migration of traffic that depends on the protocol messages described in FIG. 11. After this step, the downlink user data is still delivered to the UE 701 via the mIAB-DU1 705, but in the target IAB topology it is delivered via the backhaul bearer 723. The uplink user data (not shown in the figure) is transmitted through a similar bearer in the opposite direction. 【0138】 Step 713 corresponds to the activation of the second logical DU 706 (mIAB-DU2) within the mobile IAB node. This step can be triggered immediately after the completion of the traffic migration step 712 or when an RLF is detected on the link between the mobile IAB node and its parent IAB node in the source IAB topology. 【0139】 After the activation of the second logical DU in the mobile IAB node (step 713), the next step 714 consists of a handover of the UE served by the mobile IAB node from the cell controlled by the first logical DU 705 (mIAB-DU1) to the cell controlled by the second logical DU 706 (mIAB-DU2) (or the DU part of another nearby base station). Details of this step are described in FIG. 11. 【0140】 When the handover of all UEs served by the mobile IAB node is complete, the downlink user data is transmitted by the core network 702 via the bearer 724 to the target donor CU 707, then via the backhaul bearer 725 in the target IAB topology to the logical DU 706 (mIAB-DU2) of the mobile IAB node, and finally via the data radio bearer 726 to the UE 601. The uplink user data (not shown in the figure) is transmitted through a similar bearer in the opposite direction. 【0141】 If the mobile IAB node 470 has several child IAB nodes, the above-described procedures for dual connectivity, partial migration, and RLF recovery can be applied to these child IAB nodes. 【0142】 The complete migration procedure ends by removing the logical DU705 (mIAB-DU1) of the mobile IAB node. 【0143】 An object of the present invention is to provide necessary information to the target donor CU707 in order to avoid cancellation of admission of the mobile IAB node by the target donor CU707 and cancellation of related traffic migration in each scenario (multi-connectivity, partial / complete migration, RLF recovery). Another object of the present invention is to provide necessary information to the target donor CU707 in order to avoid failure of handover of the UE served by the mobile IAN node. 【0144】 FIG. 8 is a simplified flowchart 800 showing an example of steps for performing partial migration of a mobile IAB node according to an embodiment of the present invention. This figure shows a UE801 such as a UE480, a source donor CU803 such as a donor CU401, a target donor CU807 such as a donor CU402, and a core network (5GC) 802 such as a core network 110. This figure also shows a mobile IAB node 810 such as an IAB node 470, a source parent IAB node 808 such as an IAB node 430 belonging to the IAB topology controlled by the source donor CU803, and a target parent IAB node 809 such as an IAB node 450 belonging to the IAB topology controlled by the target donor CU807. 【0145】 At the beginning of the flowchart, the mobile IAB node 810 fully belongs to the source IAB topology controlled by the source donor CU 803. This is connected via a cell controlled by the source parent IAB node 808. The UE 801 is served by the mobile IAB node 810. Downlink user data is provided by the 5GC 802 to the source donor CU 803 via the bearer 820, and then is transmitted to the mobile IAB node 810 via the source parent IAB node 808 through the backhaul bearer 821 in the source IAB topology, and finally is transmitted to the UE 801 via the data radio bearer 823. Uplink user data (not shown in the figure) is transmitted through similar bearers in the opposite direction. 【0146】 The source donor CU 803 has the information that the IAB node 810 is a mobile IAB node because it is notified, for example, in the RRC connection of the IAB node 810, with the message RRC setup complete (which may include an IE indicating that the RRC connection is related to the mobile IAB node) defined in TS38.331 v17.0.0. 【0147】 In step 811, the IAB-MT part of the mobile IAB node 810 periodically performs measurements on signals received at the IAB-MT from the serving cell and one or more target cells, such as signal synchronization blocks (SSBs) transmitted in the serving cell and the target cells. The target cell may be an adjacent cell of the serving cell or the source cell (i.e., the current serving cell). 【0148】 When the IAB-MT detects at least one SSB that meets a predefined criterion (e.g., received power exceeding a predefined threshold), the mobile IAB node 810 can send a measurement report to the source parent IAB node via the RRC message 831, and this measurement report is transferred to the source donor CU 803 via the backhaul message (BAP data PDU) 832. The measurement in step 811 provides radio link quality information of different cells in the vicinity of the mobile IAB node 810. The identification information of each cell is included in the measurement report so that the source donor CU 803 can identify the target CU associated with the cell. 【0149】 Based on the received measurement report, the source donor CU 803 can detect that the mobile IAB node 810 receives a radio signal with better quality in the cell controlled by the target parent IAB node 809 than the current serving cell controlled by the source parent IAB node 808. In this example, since the target parent IAB node belongs to another IAB topology, the source donor CU 803 can determine a partial migration of the mobile IAB node 810 in step 812. 【0150】 To trigger a partial migration, the source donor CU 803 sends a handover request message 833 containing the necessary information related to the device to be handed over to the selected target donor CU 807. The handover request message may be the HANDOVER REQUEST message defined in section 9.1.1.1 of 3GPP document TS38.423 (v17.0.0), and this message includes an information element (IE) "IAB Node Indication", a boolean value, indicating whether the handover is related to an IAB node. When the "IAB Node Indication" is set to true, the target donor CU that receives this IE can understand that the handover request is related to a partial migration of the IAB node. 【0151】 According to one embodiment of the present invention, a new IE "Mobile IAB Node Indication" is added. This IE may be a boolean value (i.e., a variable that can take one of two values) for indicating whether the partial migration is related to a mobile IAB node. This information can be used by the target donor CU 807 in the admission control step 813 to determine whether to accept the request. This decision can be based on criteria such as the current load of the target donor CU (load of processing resources), and / or the current load of the backhaul link in the target IAB topology. The target donor CU 807 can reject the partial migration considering that an overloaded situation may occur. When the handover request is related to a partial migration of a mobile IAB node, the target donor CU may also consider that the presence of the mobile IAB node is temporary and may not stay in the IAB topology controlled by the target donor CU, and may always accept such a request because it may be the only possible option for the mobile IAB node to continue serving its UE. At least, the target donor CU can prioritize the partial migration request of the mobile IAB node or consider canceling such a request only in exceptional situations (e.g., when the service is significantly restricted or becomes impossible considering the current load). 【0152】 The IE "Mobile IAB Node Indication" can include additional information such as, for example, the number of UEs served by the migrating mobile IAB node and / or service quality (QoS) parameters related to the traffic currently processed by the mobile IAB node (e.g., priority level, required latency or packet delay budget, packet error rate, maximum data burst volume). Multiple QoS parameters can be collected and indicated by a QoS level or value. Such information helps the target donor CU to predict the migration of traffic from the source IAB topology to the target IAB topology, and can assist in the decision-making process of accepting or rejecting a migration request or allocating resources accordingly before / after acceptance. 【0153】 When the target donor CU 807 accepts the request, the procedure is completed in step 814 as defined in section 8.17.3.1 of TS38.401 v17.0.0. Finally, the mobile IAB node 810 is partially migrated (with RRC connection) to the IAB topology of the target donor CU 807. Therefore, the measurement report from the MT part of the mobile IAB node 810 is sent to the target parent IAB node 809 via the RRC message 835 and then to the target donor CU 807 via the backhaul message 836. 【0154】 Figure 9 is a simplified flowchart 900 showing an example of the steps for performing dual connectivity of a mobile IAB node according to an embodiment of the present invention. This figure shows a UE 901 such as UE 580, a source donor CU 903 such as donor CU 401, a target donor CU 907 such as donor CU 402, and a core network (5GC) 902 such as core network 110. This figure also shows a mobile IAB node 910 such as IAB node 470, a source parent IAB node 908 such as IAB node 430 belonging to the IAB topology controlled by the source donor CU 903, and a target parent IAB node 909 such as IAB node 450 belonging to the IAB topology controlled by the target donor CU 907. 【0155】 At the beginning of the flowchart, the mobile IAB node 810 fully belongs to the source IAB topology controlled by the source donor CU 903. This is connected via a cell controlled by the source parent IAB node 908. The UE 901 is served by the mobile IAB node 910. Downlink user data is provided from the 5GC 902 to the source donor CU 903 via the bearer 920, and then transmitted to the mobile IAB node 910 via the source parent IAB node 908 via the backhaul bearer 921 in the source IAB topology, and finally transmitted to the UE 901 via the data radio bearer 923. Uplink user data (not shown in the figure) is transmitted through similar bearers in the opposite direction. 【0156】 The source donor CU 903 has information that the IAB node 910 is a mobile IAB node because it is notified, for example, in the RRC connection of the IAB node 910, with a message RRC setup complete (which may include an IE indicating that the RRC connection is related to the mobile IAB node) as defined in TS38.331 v17.0.0. 【0157】 In step 911, the IAB-MT part of the mobile IAB node 910 periodically performs measurements on signals received at the IAB-MT from the serving cell and one or more target cells, such as signal synchronization blocks (SSBs) transmitted in the serving cell and target cells. The target cell may be an adjacent cell of the serving cell or the source cell (i.e., the current serving cell). 【0158】 When the IAB-MT detects at least one SSB that meets a predefined criterion (e.g., received power exceeding a predefined threshold), the mobile IAB node 910 can send a measurement report to the source parent IAB node via the RRC message 931, and this measurement report is transferred to the source donor CU 903 via the backhaul message (BAP data PDU) 932. The measurements in step 911 provide radio link quality information of different cells in the vicinity of the mobile IAB node 910. The identification information of each cell is included in the measurement report so that the source donor CU 903 can identify the target CU associated with the cell. 【0159】 Based on the received measurement report, the source donor CU 903 can detect that the mobile IAB node 910 receives a radio signal with sufficient quality to connect to the second parent IAB node in the cell controlled by the target parent IAB node 909. In this example, since the target parent IAB node belongs to another IAB topology, the source donor CU 903 can determine the dual connectivity (DC) of the mobile IAB node 810 in step 912. 【0160】 To trigger the dual connectivity procedure, the source donor CU903 sends a node addition request message 933 containing the necessary information related to the destination device to the selected target donor CU907. The node addition request message may be the "S-NODE ADDITION REQUEST" message specified in section 9.1.2.1 of 3GPP document TS38.423 (v17.0.0) and includes the information element (IE) "IAB Node Indication", a boolean value indicating whether the dual connectivity request relates to an IAB node. When the "IAB Node Indication" is set to true, the target donor CU that receives this IE can understand that the request relates to an IAB node. 【0161】 According to one embodiment of the present invention, a new IE "Mobile IAB Node Indication" is added. This IE may be a boolean value indicating whether the request relates to a mobile IAB node. This information can be used by the target donor CU907 in the admission control step 913 to determine whether to accept the dual connectivity request. This decision can be made according to criteria such as the current load of the target donor CU (the load on processing resources) or the current load of the backhaul link in the target IAB topology. The target donor CU907 can reject the request considering that the dual connectivity request may cause an overloaded situation. If the request relates to a mobile IAB node, the target donor CU should also consider that the presence of the mobile IAB node may be temporary and may not stay within the IAB topology controlled by the target donor CU, and thus should always be able to accept such requests as it should be the first phase before the complete migration of the mobile IAB node. At least, the target donor CU can prioritize the dual connectivity request related to the mobile IAB node or consider the cancellation of such requests as an exception. 【0162】 According to another embodiment of the present invention, the IE "Mobile IAB Node Indication" can include additional information such as, for example, the number of UEs served by the migrating mobile IAB node and / or service quality (QoS) parameters related to the traffic currently processed by the mobile IAB node (e.g., required latency). Such information helps the target donor CU to predict the migration of traffic from the source IAB topology to the target IAB topology. 【0163】 When the target donor CU 907 accepts the request, the procedure is completed in step 914 as defined in section 8.17.2.1 of TS38.401 v17.0.0. Finally, the mobile IAB node 910 is dual-connected to the two parent IAB nodes, the source parent IAB node 908 and the target parent IAB node 909, belonging to two different IAB topologies. Thus, the mobile IAB node is a boundary node. 【0164】 FIG. 10 is a simplified flowchart 1000 showing an example of steps for performing radio link failure (RLF) recovery of a mobile IAB node according to an embodiment of the present invention. This figure shows a UE 1001 such as UE 480, a source donor CU 1003 such as donor CU 401, a target donor CU 1007 such as donor CU 402, and a core network (5GC) 1002 such as core network 110. This figure also shows a mobile IAB node 1010 such as IAB node 470, a source parent IAB node 1008 such as IAB node 430 belonging to the IAB topology controlled by the source donor CU 1003, and a target parent IAB node 1009 such as IAB node 450 belonging to the IAB topology controlled by the target donor CU 1007. 【0165】 At the beginning of the flowchart, the mobile IAB node 1010 fully belongs to the source IAB topology controlled by the source donor CU 1003. This is connected via a cell controlled by the source parent IAB node 1008. The UE 1001 is served by the mobile IAB node 1010. Downlink user data is provided from the 5GC 1002 to the source donor CU 1003 via the bearer 1020, and then transmitted to the mobile IAB node 1010 via the source parent IAB node 1008 via the backhaul bearer 1021 of the source IAB topology, and finally transmitted to the UE 1001 via the data radio bearer 1023. Uplink user data (not shown in the figure) is transmitted through similar bearers in the opposite direction. 【0166】 The source donor CU 1003 has information that the IAB node 1010 is a mobile IAB node because, for example, in the RRC connection of the IAB node 1010, it is notified by the message RRC setup complete defined in TS 38.331 v17.0.0 (which may include an IE indicating that the RRC connection is related to the mobile IAB node). 【0167】 In step 1011, the IAB-MT part of the mobile IAB node 1010 periodically performs measurements on signals received by the IAB-MT from the serving cell and one or more target cells, such as signal synchronization blocks (SSBs) transmitted in the serving cell and the target cells. The target cell may be an adjacent cell of the serving cell or the source cell (i.e., the current serving cell). 【0168】 During a time sufficient to declare an RLF of the link between the mobile IAB node 1010 and its source parent IAB node 1008, it may happen that the SSB signal in the serving cell meets a predefined criterion (e.g., received power below a predefined threshold). Further, the mobile IAB node 1010 may have detected an SSB signal that meets a predefined criterion (e.g., received power exceeding a predefined threshold) sufficient to attempt a new connection in the corresponding target cell. In this case, the mobile IAB node 1010 triggers the re-establishment request procedure 1032 as described in section 8.17.4 of TS38.401 v17.0.0. This consists of performing a random access procedure to acquire uplink resources and transmitting an RRC re-establishment request message in the target cell. This RRC message is received by the target parent IAB node (1009 in the example of Figure 10), and the message is relayed to the target IAB donor CU (1007 in the example of Figure 10). 【0169】 When the target donor CU1007 receives an RRC reconnection request containing information for identifying the source donor CU1003 of the requesting device, it sends a context request message 1033 to the source donor CU (1003 in the example of FIG. 10) to obtain the context of the requesting device. In response, the source donor CU1003 sends a context response message 1034 containing the requested information to the target donor CU1007. The context request message may be the "RETRIEVE UE CONTEXT REQUEST" message defined in section 9.1.1.8 of 3GPP document TS38.423 (v17.0.0). The context response message may be the "RETRIEVE UE CONTEXT RESPONSE" message defined in section 9.1.9 of 3GPP document TS38.423 (v17.0.0), and this message includes an information element (IE) "IAB Node Indication", a boolean value indicating whether the device is related to an IAB node. When the "IAB Node Indication" is set to true, the target donor CU that receives this IE can understand that the RRC reconnection request is related to an IAB node. According to an embodiment of the present invention, a new IE "Mobile IAB Node Indication" is added. This IE is a boolean value indicating whether the device is a mobile IAB node. This information can be used by the target donor CU1007 in the admission control step 1013 to determine whether to accept the request. This decision can be made according to criteria such as the current load of the target donor CU (load of processing resources) or the current load of the backhaul link in the target IAB topology. The target donor CU1007 can reject the reconnection request considering that the reconnection request may cause an overload situation.When the reconnection request relates to a mobile IAB node, the target donor CU may always accept such a request, taking into account that the presence of the mobile IAB node is temporary and may not remain in the IAB topology controlled by the target donor CU, and that it may be the only possible option for the mobile IAB node to continue serving its UE. At least, the target donor CU may prioritize requests from the mobile IAB node or consider cancellation of such requests as an exception. 【0170】 In another embodiment, the IE "Mobile IAB Node Indication" may include additional information, such as the number of UEs served by the requesting mobile IAB node and / or quality of service (QoS) parameters (e.g., requested latency) related to the traffic currently being processed by the mobile IAB node. Such information helps the target donor CU to predict the migration of traffic from the source IAB topology to the target IAB topology. 【0171】 When the target donor CU 1007 accepts the request, the procedure is completed at step 1014 as defined in section 8.17.4 of TS38.401 v17.0.0. The target donor CU 1007 can send an indication of the reconnection of the mobile IAB node to the source donor CU 1003. This message is the "UE CONTEXT RELEASE" message defined in TS38.423 V17.0.0. Finally, the mobile IAB node 810 is partially migrated (along with the RRC connection) in the IAB topology of the target donor CU 1007. Thus, the measurement report from the MT part of the mobile IAB node 1010 is sent to the target parent IAB node 1009 via the RRC message 1035 and then to the target donor CU 1007 via the backhaul message 1036. 【0172】 FIG. 11 is a flowchart 1100 showing an example of a procedure for performing traffic migration from a first IAB topology to a second IAB topology according to an embodiment of the present invention. 【0173】 This figure shows two donor CUs 1101 (donor CUa) and 1102 (donor CUb), similar to donor CUs 401 or 402. 【0174】 After completion of the procedures described in FIGS. 8, 9, and 10, the source donor CU can request migration of traffic related to the mobile IAB node to the target IAB topology. In this case, the source donor CU corresponding to donor CUa 1101 in FIG. 11 transmits a message IAB transport request 1111 to the target donor CU corresponding to donor CUb 1102 in FIG. 11. Message 1111 contains information necessary for the target donor CU to understand the characteristics of the traffic to be migrated (e.g., maximum throughput, downlink or uplink, QoS level...). The target donor CU analyzes the received information and can accept the entire traffic migration. Also, due to reasons such as potential load problems, the traffic migration can be partially or completely cancelled. The response of the target donor CU is sent in message IAB transport response 1112. 【0175】 The procedure described in FIG. 11 may correspond to the procedure IAB transport migration management specified in section 8.5.2 of TS38.401 v17.0.0. Therefore, the message IAB transport request 1111 can correspond to the message IAB transport migration management request from the F1 terminated donor (i.e., the source donor CU) to the non-F1 terminated donor (i.e., the target donor CU). Moreover, the message IAB transport response 1112 may correspond to the message (IAB TRANSPORT MIGRATION MANAGEMENT RESPONSE) from the non-F1 terminated donor (i.e., the target donor CU) to the F1 terminated donor (i.e., the source donor CU). 【0176】 In the case of traffic migration related to the mobile IAB node, since the target IAB donor CU may cross the IAB topology controlled by the target donor CU and the mobile IAB node may not remain, considering that the existence of the mobile IAB node may be temporary and it may be the only possible option for the mobile IAB node to continue providing services to its UE, the target donor CU should always accept such requests. At least, the target donor CU can prioritize the traffic migration request for the traffic related to the mobile IAB node, or can consider the cancellation of such a request as an exception. 【0177】 Therefore, according to an embodiment of the present invention, a new IE "Mobile IAB Node Indication" is added to the message IAB transport request 1111. This IE can be a boolean value indicating whether the device related to the migrating traffic is a mobile IAB node. This information is used by the target donor CU to determine whether to accept the traffic migration. 【0178】 FIG. 12 is a simplified flowchart 1200 showing an example of steps for performing a handover of a UE served by a mobile IAB node that fully migrates from a source IAB topology to a target IAB topology according to an embodiment of the present invention. 【0179】 This figure shows a UE 1201 such as UE 580, a source donor CU 1203 such as donor CU 501, a target donor CU 1207 such as donor CU 502, and a core network (5GC) 1202 such as core network 110. This figure also shows mobile IAB nodes such as IAB nodes 570 and 601 composed of an IAB-MT part / unit 1204 (mIAB-MT), an IAB-DU1 part / unit 1205 (mIAB-DU1), and an IAB-DU2 part / unit 1206 (mIAB-DU2). In one embodiment, they share the same physical layer (i.e., the same hardware resources), but in another embodiment, they rely on separate physical layers. 【0180】 At the beginning of the flowchart, the mobile IAB node has partially migrated to the target IAB topology controlled by the target donor CU 1207, and both logical DUs of the mobile IAB node are active. mIAB-DU1 1205 provides an F1 termination to the source donor CU 1203, and mIAB-DU2 1206 provides an F1 termination to the target donor CU 1207. UE 1201 is served by the mobile IAB node via a cell controlled by mIAB-DU1 1205. Downstream user data is provided by 5GC 1202 to the source donor CU 1203 via bearer 1220, then transmitted to the logical DU mIAB-DU1 1205 of the mobile IAB node via the backhaul bearer 1221 in the source IAB topology, and finally transmitted to UE 1201 via the data radio bearer 1222. Uplink user data (not shown in the figure) is transmitted through similar bearers in the opposite direction. 【0181】 In step 1211, UE1201 periodically performs measurements on signals received from the serving cell and one or more target cells, such as the signal synchronization block (SSB) transmitted in the serving cell and the target cell. The target cell may be a neighboring cell of the serving cell or the source cell (i.e., the current serving cell). 【0182】 When UE1201 detects at least one SSB that meets a predefined criterion (e.g., received power exceeding a predefined threshold), UE1210 can send a measurement report to the mobile IAB node via the RRC message 1231, and this measurement report is transferred to the source donor CU1203 via the backhaul message (BAP data PDU) 1232. The measurements in step 1211 provide radio link quality information of different cells in the vicinity of UE1201. The identification information of each cell is included in the measurement report so that the source donor CU1203 can identify the target CU associated with the cell. 【0183】 Based on the received measurement report, the source donor CU1203 can detect that UE1201 receives a radio signal in the cell controlled by mIAB-DU2 1206. Next, in step 1212, the source donor CU1203 can determine a handover of UE1201 towards the target donor CU1207 via the cell controlled by mIAB-DU2 1206. 【0184】 To trigger the handover of the UE, the source donor CU1203 sends a handover request message 1233 containing the necessary information related to the UE to be handed over to the target donor CU1207. The handover request message may be the "HANDOVER REQUEST" message defined in section 9.1.1.1 of 3GPP document TS38.423 (v17.0.0). 【0185】 According to one embodiment of the present invention, a new IE "Group Mobility Indication" is added to message 1233. This IE can be a boolean value indicating whether the handover of the UE is related to the UE served by the mobile IAB node that is moving, i.e., whether the UE is part of a group of devices moving with the mobile IAB node. This is the case for an on-board UE within a vehicle where the mobile IAB node is mounted on top of the vehicle. This "Group Mobility Indication" IE can be used by the target donor CU 1207 in the admission control step 1213 to determine whether to accept the handover request. This decision can be made according to criteria such as the current load of the target donor CU (load of processing resources) or the current load of the backhaul link in the target IAB topology. The target donor CU 1207 can reject the handover of the UE considering that it may cause an overloaded situation. If the handover request is related to a UE belonging to the group mobility of the mobile IAB node during migration, the target donor CU should always accept such a request as part of the complete migration of the mobile IAB node serving the UE. Otherwise, the UE may lose its connection with the source donor CU 1203 when the mIAB-DU1 1205 is deactivated, which may cause a service interruption in this UE. 【0186】 When the target donor CU 1207 accepts the handover request, the target donor CU 1207 sends a handover confirmation response message 1234 to the source donor CU 1203. As specified in section 9.2.3.2 of TS38.300 v17.0.0, the handover of the UE is completed in step 1214. 【0187】 The handover procedure may be a conditional handover where the decision to switch to a new serving cell is delegated to the UE according to some conditions provided by the source donor CU 1207. 【0188】 Finally, the UE 1201 is served by the cell controlled by the mIAB-DU2 1206 and is thus connected to the target donor CU 1207. The target donor CU 1207 can execute a path switching procedure 1237 towards the core network 1202 to request the delivery of user data dedicated to the UE 1201. Next, the downlink user data is sent by the core network 1202 to the target donor CU 1207 via the bearer 1223, then to the logical DU mIAB-DU2 1206 of the mobile IAB node via the backhaul bearer 1224 in the target IAB topology, and finally to the UE 1201 via the data radio bearer 1226. The uplink user data (not shown in the figure) is sent through the same bearers in the opposite direction. Also, the traffic related to the UE 1201 that was previously migrated by the IAB donor CU 1203 towards the IAB topology controlled by the target donor CU 1207 may be released because it is no longer handled by the source donor CU 1203. To perform this release, the source donor CU 1203 can apply the IAB transport migration management procedure defined in Section 8.5.2 of TS38.423 v17.0.0, or the target donor CU 1207 can apply the IAB transport migration correction procedure defined in Section 8.5.3 of TS38.423 v17.0.0. 【0189】 Figures 14 to 17 show a simplified method executed by a source donor CU (Figs. 14a, 15a, 16a, and 17a) and a target donor CU (Figs. 14b, 15b, 16b, and 17b) related to resource requests from a source IAB topology to a target IAB topology in four different scenarios. The term "requesting resources" may refer to requesting partial or full migration or establishing dual connectivity. In some cases, full migration may occur following partial or dual connectivity. 【0190】 The steps of the method include message exchange between the source donor CU and the target donor CU. Each example includes features indicating that the process is related to a mobile IAB node. As described above, this enables prioritization of traffic / node migration. Such prioritization may be necessary because the UEs served by the mobile IAB node may not have alternative means of execution. 【0191】 Fig. 14a shows an exemplary method for a source donor CU to manage an indication indicating that a partial migration or dual connectivity setup is related to a mobile IAB node using flowchart 1400. 【0192】 In the case of partial migration of the IAB node, the procedure is as follows: In step 1401, a source donor CU, such as IAB donor CU 401, determines that the IAB node to migrate to the target donor CU is a mobile IAB node. In step 1402, the source donor CU sends a node migration request to the target donor CU indicating that the IAB node to migrate is a mobile IAB node. In step 1403, the source donor CU receives a confirmation response for node migration from the target donor CU. 【0193】 In the case of IAB node dual connectivity setup, the procedure is basically the same but is modified as follows: In step 1401, a source donor CU such as the IAB donor CU 401 determines that the IAB node for dual connection to the target donor CU is a mobile IAB node. In step 1402, the source donor CU sends a node addition request indicating to the target donor CU that the IAB node for dual connection is a mobile IAB node. In step 1403, the source donor CU receives a confirmation response for node addition from the target donor CU. 【0194】 FIG. 14b shows a method corresponding to FIG. 14a executed at the target donor CU to perform partial migration or dual connectivity setup related to the mobile IAB node using the flowchart 1410. 【0195】 In the case of partial migration of the IAB node, the procedure is as follows: In step 1411, a target donor CU such as the IAB donor CU 402 receives a node addition request indicating from the source donor CU that the IAB node to be migrated is a mobile IAB node. In step 1412, the target donor CU admits the mobile IAB node based on the migration request information indicating its association with the mobile IAB node. This admission is related to the RRC connection of the mobile IAB node to the target donor CU. In step 1413, the target donor CU sends a confirmation response for node migration to the source donor CU. 【0196】 In the case of dual connectivity setup for an IAB node, the procedure is changed as follows: In step 1411, a target donor CU, such as IAB donor CU 402, receives from the source donor CU a node addition request indicating that the dual-connected IAB node is a mobile IAB node. In step 1412, the target donor CU approves the mobile IAB node based on additional request information indicating its association with the mobile IAB node. This approval is related to the RRC connection of the mobile IAB node to the target donor CU. In step 1413, the target donor CU sends a confirmation response for the node addition to the source donor CU. 【0197】 FIG. 15a shows an exemplary method for a source donor CU to manage an indication indicating that radio link failure (RLF) recovery is related to a mobile IAB node, using flowchart 1500. 【0198】 In step 1501, a source donor CU, such as IAB donor CU 401, receives from the target donor CU a request to obtain a device context. In step 1502, the source donor CU determines that the provided context is related to the mobile IAB node. In step 1503, the source donor CU sends a response to the target donor CU, including the device context and indicating that the device is a mobile IAB node. 【0199】 FIG. 15b shows a method corresponding to FIG. 15a for a target donor CU to manage an indication indicating that radio link failure (RLF) recovery is related to a mobile IAB node, using flowchart 1510. 【0200】 In step 1511, a target donor CU such as IAB donor CU 402 receives, from a source donor CU, a context indicating that the device for which RLF recovery is in progress at the target donor CU is a mobile IAB node. In step 1512, the target donor CU approves the mobile IAB node based on context information indicating that the device for which RLF recovery is in progress is associated with the mobile IAB node. This approval is related to the RRC connection of the mobile IAB node to the target donor CU. In step 1513, the target donor CU sends an indication of reconnection of the mobile IAB node to the source donor CU. 【0201】 FIG. 16a shows an exemplary method for a source donor CU to manage an indication indicating that traffic migration is related to a mobile IAB node, using flowchart 1600. 【0202】 In step 1601, a source donor CU such as IAB donor CU 401 determines that traffic to be migrated to a target donor CU is associated with a mobile IAB node. In step 1602, the source donor CU sends a traffic migration request to the target donor CU, indicating that the traffic to be migrated is associated with a mobile IAB node. In step 1603, the source donor CU receives an acknowledgement response for the traffic migration from the target donor CU. 【0203】 FIG. 16b shows a method corresponding to FIG. 16a for a target donor CU to manage an indication indicating that traffic migration is related to a mobile IAB node, using flowchart 1610. 【0204】 In step 1611, a target donor CU such as IAB donor CU 402 receives, from a source donor CU, a traffic migration request indicating that the traffic to be migrated is associated with a mobile IAB node. In step 1612, the target donor CU accepts traffic migration based on the traffic migration request indicating that the traffic to be migrated is associated with a mobile IAB node. In step 1613, the target donor CU sends a confirmation response for the traffic migration to the source donor CU. 【0205】 FIG. 17a shows an exemplary method for a source donor CU to manage an indication indicating that a handover of a UE is associated with a mobile IAB node, using flowchart 1700. 【0206】 In step 1701, a source donor CU such as IAB donor CU 401 determines that a UE to be handed over to a target donor CU is associated with a mobile IAB node during migration. In step 1702, the source donor CU sends a UE handover request to the target donor CU, indicating that the UE is served by a mobile IAB node during migration. This message may indicate that the UE belongs to the group mobility of the mobile IAB node during movement. In step 1703, the source donor CU receives a confirmation response for the UE handover from the target donor CU. 【0207】 FIG. 17b shows a method corresponding to FIG. 17a for a target donor CU to manage an indication indicating that a UE handover is associated with a mobile IAB node, using flowchart 1710. 【0208】 In step 1711, a target donor CU, such as IAB donor CU 402, receives from the source donor CU a UE handover request indicating that the UE is being served by a mobile IAB node during migration. In step 1712, the target donor CU approves the UE based on the handover request information indicating that the UE is being served by a mobile IAB node during migration. In step 1713, the target donor CU sends a confirmation response to the source donor CU for the UE handover. 【0209】 FIG. 13 is a schematic diagram of a communication device or station according to one or more exemplary embodiments of the present disclosure. 【0210】 The communication device 1300 can preferably be a device such as a microcomputer, a workstation, or a lightweight portable device. The communication device 1300 includes a communication bus 1313, and preferably the following are connected thereto: - A central processing unit 1311, such as a microprocessor denoted as CPU; - A read-only memory 1307 denoted as ROM for storing a computer program for implementing the present invention; - A random access memory 1312 denoted as RAM for storing executable code of the method according to the embodiment of the present invention, as well as registers adapted to record variables and parameters necessary for implementing the method according to the embodiment of the present invention; and At least one communication interface 1302 connected to a wireless communication network 100 (e.g., a wireless communication network according to Release 16 of 5G_NR) to which digital data packets or frames or control frames are transmitted. The frame is written from the FIFO transmission memory of the RAM 1312 to the network interface for transmission or read from the network interface for reception and written to the FIFO reception memory of the RAM 1312 under the control of a software application executed by the CPU 1311. 【0211】 Optionally, the communication device 1300 can also include the following components: - Data storage means 1304 such as a hard disk for storing a computer program for implementing the method according to one or more embodiments of the present invention; - A disk drive 1305 for the disk 1306, the disk drive being adapted to read data from or write data to the disk 1106; - A screen 1309 for displaying the decoded data and / or for functioning as a graphical interface with the user by means of a keyboard 1310 or other pointing means. 【0212】 Preferably, the communication bus provides communication and interoperability between various elements included in or connected to the communication device 1300. The representation of the bus is not limiting, and in particular, the central processing unit is operable to communicate commands directly to any element of the communication device 1300 or by means of another element of the communication device 1300. 【0213】 The disk 1306 can optionally be replaced by any information medium such as, for example, a compact disc (CD-ROM), ZIP disk, USB key, or memory card, whether rewritable or not, and generally speaking, can be read by a microcomputer or microprocessor, and can be removable in some cases, whether integrated in the device or not, and can be replaced by an information storage means adapted to store one or more programs capable of implementing the method according to an embodiment of the present invention by its execution. 【0214】 The executable code can optionally be stored either in the read-only memory 1307, on the hard disk 1304, or on a removable digital medium such as, for example, the disk 1106 as described above. According to any variant, the executable code of the program can be received by the communication network 1303 via the interface 1302 so as to be stored in one of the storage means of the communication device 1300 such as the hard disk 1304 before being executed. 【0215】 The central processing unit 1311 is preferably adapted to control and direct the execution of a program or a portion of program instructions or software code according to the present invention, and these instructions are stored in one of the aforementioned storage means. At power-on, the program or programs stored on a non-volatile memory, for example, on the hard disk 1304 or in the read-only memory 1307, are transferred to the random access memory 1312, and in this random access memory 1312, there are stored the program or the executable code of the program, as well as registers for storing variables and parameters necessary for implementing the present invention. 【0216】 In a preferred embodiment, the device is a programmable device that uses software to implement the present invention. However, alternatively, the present invention can also be implemented in hardware (for example, in the form of an application-specific integrated circuit (ASIC)). 【0217】 Although the present invention has been described with reference to embodiments, it should be understood that the present invention is not limited to the disclosed embodiments. It will be understood by those skilled in the art that various changes and modifications can be made without departing from the scope of the present invention as defined by the appended claims. All features disclosed in this specification (including the appended claims, abstract and drawings), and / or all steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and / or steps are mutually exclusive. Each feature disclosed in this specification (including the appended claims, abstract and drawings) may be replaced by an alternative feature serving the same, equivalent or similar purpose, unless expressly stated otherwise. Therefore, unless expressly stated otherwise, each feature disclosed is an example of a general series of equivalent or similar features. 【0218】 In the claims, the term "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used. The reference numerals recited in the claims are for illustrative purposes only and do not limit the claims. 【0219】 In the foregoing embodiments, the described functions can be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the functions can be stored on or transmitted via a computer-readable medium as one or more instructions or codes and executed by a hardware-based processing unit.

Claims

[Claim 1] A method in a first IAB donor central unit (CU) for the backhaul radio link failure recovery process of an IAB node in an integrated access backhaul (IAB) topology of a communication system is: A receive control step of receiving a request message from a second IAB donor CU requesting a UE context related to an IAB node managed by the first IAB donor CU, A transmission control step in which, if the IAB node corresponding to the request message is a mobile IAB node, a response message is sent to the second IAB donor CU that includes information elements capable of identifying that the IAB node is a mobile IAB node. A method characterized by having the following: [Claim 2] The method according to claim 1, characterized in that the values ​​that can be stored in the information element are binary, and a value representing either one of the two values ​​is selectively stored in the information element. [Claim 3] The method according to claim 1, wherein the response message further includes information regarding the number of user devices serviced by the mobile IAB node. [Claim 4] The method according to claim 1, characterized in that the response message further includes service quality level information. [Claim 5] The method according to 4, characterized in that the service quality level information indicates at least one service quality parameter among priority level, requested packet delay budget, requested packet error rate, and maximum data burst level. [Claim 6] The method according to claim 1, characterized in that the backhaul radio link failure recovery process is an IAB interCU backhaul radio link failure recovery process. [Claim 7] The method according to 6, characterized in that the backhaul radio link failure recovery process includes a re-establishment request procedure. [Claim 8] The method according to 7, characterized in that the backhaul radio link failer recovery process includes a partial migration process for terminating the mobile termination (MT) of the IAB node to the second IAB donor CU. [Claim 9] The method according to any one of claims 1 to 8, characterized in that the request message is a RETRIEVE UE CONTEXT REQUEST message and the response message is a RETRIEVE UE CONTEXT RESPONSE message. [Claim 10] A method in a second IAB donor central unit (CU) for the backhaul radio link failure recovery process of an IAB node in an integrated access backhaul (IAB) topology of a communication system is: A transmission control step of sending a request message to a first IAB donor CU requesting a UE context related to an IAB node managed by the first IAB donor CU, A receiving control step of receiving a response message corresponding to the request message from the first IAB donor CU, An identification step of identifying that the type of IAB node is a mobile IAB node, in accordance with the fact that the response message contains an information element that can identify that the IAB node corresponding to the UE context is a mobile IAB node, A method characterized by having the following: [Claim 11] The aforementioned method, The method according to 10, further comprising a determination step of determining the priority in admission control for the IAB node depending on the information elements. [Claim 12] The method according to 11, characterized in that, if the determination step includes the information element that can identify the mobile IAB node, it is determined that the priority in admission control for the mobile IAB node is higher than the priority in admission control for static radio nodes. [Claim 13] The method according to any one of claims 10 to 12, characterized in that the request message is a RETRIEVE UE CONTEXT REQUEST message and the response message is a RETRIEVE UE CONTEXT RESPONSE message. [Claim 14] A program for causing a computer to perform the method in a first IAB donor central unit (CU) according to any one of claims 1 to 8. [Claim 15] A program for causing a computer to perform the method in a second IAB donor central unit (CU) according to any one of claims 10 to 12. [Claim 16] A communications device that functions as a first IAB donor central unit (CU) supporting the backhaul radiolink failure recovery process of an IAB node in an integrated access backhaul (IAB) topology of a communications system, A receiving control means that receives a request message from a second IAB donor CU requesting a UE context related to an IAB node managed by the first IAB donor CU, A transmission control means that, when the IAB node corresponding to the request message is a mobile IAB node, transmits a response message to the second IAB donor CU that includes information elements capable of identifying that the IAB node is a mobile IAB node. A communication device characterized by having the following features. [Claim 17] A communications device that functions as a second IAB donor central unit (CU) supporting the backhaul radiolink failure recovery process of an IAB node in an integrated access backhaul (IAB) topology of a communications system, A transmission control means that transmits a request message to a first IAB donor CU requesting a UE context related to an IAB node managed by the first IAB donor CU, A receiving control means for receiving a response message corresponding to the request message from the first IAB donor CU, In accordance with the fact that the response message contains an information element that can identify that the IAB node corresponding to the UE context is a mobile IAB node, an identification means for identifying that the type of the IAB node is a mobile IAB node, A communication device characterized by having the following features.

Images