Managing network connectivity in a wireless communication system

Abstract

A method for managing network connectivity in a wireless communication system including a mobile integrated access and backhaul (mIAB) node is provided. The method includes, in an mIAB node, providing a mobility message to a wireless communication device, the mobility message including at least one of mobility profile information indicating the mobility capabilities of the mIAB node and guaranteed stationary time information indicating a minimum period of time the mIAB node will remain at a given location, the mobility profile information including at least one of speed information indicating the speed capabilities of the mIAB node, range information indicating a mobility area of ​​the mIAB node, stationary information indicating a duration of one or more stationary periods the mIAB node may experience, and journey information indicating a sequence of mobility and stationary periods for a journey the mIAB node may follow.

Description

[Technical Field]

[0001] The present invention relates generally to managing network connectivity in a wireless communication system, and more particularly to managing network connectivity in a wireless communication system including at least one mobile integrated access and backhaul (IAB) node. [Background technology]

[0002] Wireless communication systems are primarily deployed to address a wide range of applications, from mobile broadband, massively scaled machine-type communications, to ultra-reliable and low-latency communications (URLLC). Such systems allow multiple user equipments (UEs) or mobile terminals to share a wireless medium to exchange several types of data content (e.g., video, voice, messaging, etc.) over a radio access network (RAN) through one or more base stations. Base stations are traditionally wired (e.g., via fiber) to a core network, forming an intermediate network called the backhaul (BH).

[0003] Examples of such wireless multiple-access communication systems include systems based on 3rd Generation Partnership Project (3GPP®-RTM) standards, such as Fourth Generation (4G) Long Term Evolution (LTE) or recent Fifth Generation (5G) New Radio (NR) systems, or IEEE 802.11 standard-based systems, such as WiFi.

[0004] The demand for network densification increases due to an increasing number of users and higher throughput requirements.

[0005] Faced with the high deployment costs and time challenges of wired backhaul networks with network densification, 3GPP® has proposed wireless backhaul (also known as Integrated Access and Backhaul, IAB) in its recent Release 16 for 5G NR, where a portion of the radio (i.e., wireless) spectrum is used for base station backhaul connections instead of fiber. Wireless backhaul communication (between base stations) may use the same radio resources as access communication (between base stations and UEs).

[0006] IAB has proven to be a competitive alternative to fiber-based backhaul in dense or hard-to-cover areas, as it allows for scalable and rapid installation without the burden of cabling base stations.

[0007] The IAB will most likely operate in the millimeter wave (mmWave) band to achieve the required Gbps (gigabits per second) data rates.

[0008] Urban environments are typically characterized by a high density of users, along with the presence of a significant number of vehicles (e.g., public / private passenger transport, merchandise delivery, food trucks...). The speed of some of the vehicles may be quite low, or at least similar to pedestrian speeds, and some of these vehicles may even be temporarily stationary. Some of these vehicles (e.g., buses, trains, or trams) may have predictable routes and / or limited areas of movement (e.g., some vehicles, such as food trucks or promotional vehicles, may be located outside a stadium or show venue), while others may have predictable stationary locations (e.g., taxis).

[0009] 3GPP believes that installing vehicular base stations (or base station elements) in vehicles, intended to function as relays, can provide an opportunity to increase network coverage and connectivity to UEs within and near the vehicle. These relays will rely on 5G wireless backhaul (typically IAB, or integrated access and backhaul) to connect to fixed donor devices. Therefore, based on the fixed IAB foundation described in Releases 16 and 17, 3GPP is currently considering mobile IAB systems and architectures as part of the Release 18 framework to address scenarios focused on mobile IAB nodes mounted on vehicles (e.g., buses, trains, and taxis). In such scenarios, the mobile IAB nodes provide 5G coverage / capacity to in-vehicle and / or surrounding UEs, sometimes referred to as vehicular relays (VMRs). The technical advantages of using vehicular relays include, among other things, the relay vehicle's ability to obtain better coverage than nearby UEs due to better RF / antenna capabilities, thus providing the UEs with a better link to the macro network. Furthermore, vehicular relays are expected to have less stringent power / battery constraints than UEs.

[0010] Because a VMR or mobile IAB (mIAB) node may be stationary at some point during its movement (e.g., a taxi in a parking lot or taxi stand, a bus in a parking lot or bus stop, a train in a train station, or a temporary installation in case of an event or emergency / disaster), its connections with mobile IAB (mIAB) nodes or vehicle-mounted relays (VMRs) are likely to fluctuate based on their actual movement. Therefore, to benefit from the additional connectivity resulting from the presence of a mobile IAB node in the topology while mitigating any impact on connectivity that may result from its actual mobility status, the connections of child IAB nodes, either fixed or mobile, to the network via or through such mobile IAB nodes should be carefully managed and require some dedicated signaling to other IAB nodes, including IAB donors, for the purpose of connection setup or dynamic mobility status notification.

[0011] A given IAB topology may at some point consist of both legacy IAB devices (belonging to the earlier Releases 16 and 17) that do not have the ability to distinguish mobile IAB nodes from fixed IAB nodes, and more recent IAB devices (belonging to Release 18 and beyond) that have the ability to handle mobile IAB connectivity, and managing the connections of different types of IAB devices (e.g., legacy and more recent IAB devices) to the network via or through mobile IAB devices also needs to be taken into consideration.

[0012] Also, given the aforementioned variations in connectivity associated with mobile IAB nodes, it may also be desirable to carefully manage the connectivity of both onboard and / or surrounding user equipment (UE) that may be within range of the mobile IAB node.

[0013] Therefore, some new mechanisms are needed to address at least some of the aforementioned problems while limiting the complexity of processing at IAB nodes, as well as the latency resulting from such processing. Summary of the Invention

[0014] According to a first aspect of the present invention, there is provided a method for use in managing network connectivity in a wireless communication system including at least one mobile integrated access and backhaul (mIAB) node, the method comprising: providing, at the mIAB node, a mobility message to a wireless communication device, the mobility message including at least one of mobility profile information indicating mobility capabilities of the mIAB node and guaranteed quiet time information indicating a minimum period of time the mIAB node will remain at a given location.

[0015] In one example, the mobility profile information includes at least one of speed information indicating the speed capabilities of the mIAB node, range information indicating the mobility area of ​​the mIAB node, stationary information indicating the duration of one or more stationary periods that the mIAB node may experience, and journey information (which may alternatively be referred to as movement trajectory information) indicating a sequence or succession of mobility and stationary periods for a journey that the mIAB node may follow.

[0016] By providing the mobility profile information and / or guaranteed rest time information (e.g., after one or more connections to the mobile IAB node have been established), a receiving wireless communication device (e.g., an IAB donor CU, a UE, or another IAB node) can receive information about the mobile IAB node's mobility capabilities and / or current rest state and act accordingly. In other words, the mIAB node can advertise its mobility capabilities and / or rest state to one or more UEs and one or more other IAB nodes in the vicinity of the mIAB node. With the additional information about the mobility capabilities of the mIAB node and / or the guaranteed rest time information, the UE and / or other IAB nodes and / or IAB donor nodes have additional information and can therefore operate more effectively. For example, the UE and / or another IAB node can decide not to connect to the network through the mIAB node due to its mobility, or can decide to connect despite the mIAB node's mobility (e.g., because the information indicates that the mIAB node is moving slowly or is within a limited area). In another example, if the UE and / or another IAB node is already connected, the UE and / or another IAB node may decide to initiate a cell search procedure to seek to connect to or hand over to another IAB node.

[0017] According to a second aspect of the present invention, there is provided a method in a wireless communication device of a wireless communication system as set forth in claim 19 of the accompanying claims.

[0018] According to a third aspect of the present invention, there is provided a method in an Integrated Access and Backhaul (IAB) donor node of a wireless communication system as set forth in claim 32 of the accompanying claims.

[0019] According to a fourth aspect of the present invention there is provided a method in an Integrated Access and Backhaul (IAB) node for use in managing network connectivity in a wireless communication system as set out in claim 49 of the accompanying claims.

[0020] According to a fifth aspect of the present invention, there is provided a method in a wireless communication device of a wireless communication system as set forth in claim 59 of the accompanying claims.

[0021] According to a sixth aspect of the present invention, there is provided an apparatus for an integrated access and backhaul IAB node of a wireless communication system as set out in claim 62 of the accompanying claims.

[0022] According to a seventh aspect of the present invention, there is provided an apparatus for an integrated access and backhaul (IAB) donor node of a wireless communication system as set out in claim 63 of the accompanying claims.

[0023] According to an eighth aspect of the present invention there is provided an apparatus for a wireless communication device as set out in claim 64 of the accompanying claims.

[0024] Further exemplary features of the invention are set out in the other independent and dependent claims.

[0025] Any feature in one aspect of the invention may be applied to other aspects of the invention in any appropriate combination, in particular method aspects may be applied to apparatus / device / unit aspects and vice versa.

[0026] Furthermore, hardware-implemented functionality may be implemented in software and vice versa. Any references herein to software and hardware functionality should be construed accordingly. For example, according to another aspect of the present invention, there is provided a computer program comprising instructions that, when executed by a processing unit, cause the processing unit to perform the method of any of the aspects or examples described above, and a computer-readable storage medium carrying the computer program.

[0027] It should also be understood that particular combinations of the various features described and defined in any embodiment of the present invention may be implemented and / or provided and / or used independently. [Brief explanation of the drawings]

[0028] Different aspects of the present invention will now be described, by way of example only, with reference to the following drawings, in which: [Figure 1] FIG. 1 is a schematic diagram illustrating an exemplary wireless communication system in which the present invention may be implemented in accordance with one or more embodiments. [Figure 2] 2(A) and (B) are schematic diagrams showing the stack of several protocol layers involved in IAB operation. [Figure 3] FIG. 3 is a schematic diagram illustrating the format of a BAP protocol data unit (PDU) or packet. [Figure 4] FIG. 4 is a block schematic diagram illustrating an exemplary wireless communication system (or IAB network) in which the present invention may be implemented in accordance with one or more embodiments. [Figure 5] FIG. 5 is a schematic and simplified diagram illustrating exemplary message flows that may be used to manage the advertising by an IAB node of its mobility capabilities and status along with its ability to support IAB connections with child IAB nodes, for use in managing network connectivity in a wireless communication system including at least one IAB node, in accordance with one or more embodiments of the present invention. [Figure 6] FIG. 6 is a flowchart of an exemplary method for managing connectivity of a mobile IAB node, in accordance with one or more embodiments of the present invention. [Figure 7] FIG. 7 is a schematic and simplified diagram illustrating an exemplary message flow for use in managing a connection of a wireless communication device (or network device) to a network of a wireless communication system via a mobile IAB node, in accordance with one or more embodiments of the present invention. [Figure 8] FIG. 8 is a flowchart of an exemplary method for use in managing a connection of a wireless communication device (or network device) to a network of a wireless communication system via a mobile IAB node, in accordance with one or more embodiments of the present invention. [Figure 9] FIG. 9 is a flowchart of an exemplary method of a wireless communication device (or network device) for use in managing a connection of the wireless communication device (or network device) to a network of a wireless communication system via a mobile IAB node, in accordance with one or more embodiments of the present invention. [Figure 10] FIG. 10 shows a block schematic diagram of a wireless communication device according to an embodiment of the present invention. [Figure 11] FIG. 11 is a flowchart of an exemplary method for use in managing network connectivity in a wireless communication system including at least one mobile IAB node, in accordance with one or more embodiments of the present invention. [Figure 12] FIG. 12 is a flowchart of an exemplary method performed in a wireless communication device, in accordance with one or more embodiments of the present invention. [Figure 13] FIG. 13 is a flowchart of an exemplary method performed in an IAB donor node of a wireless communication system, in accordance with one or more embodiments of the present invention. [Figure 14]FIG. 14 is a flowchart of an exemplary method for use in managing network connectivity in a wireless communication system including at least one mobile IAB node, in accordance with one or more embodiments of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0029] FIG. 1 illustrates an exemplary communication system 100 in which the present invention may be implemented in accordance with one or more embodiments.

[0030] As shown, exemplary system 100 is a wireless communication system, particularly a mobile wireless communication system such as a fifth generation (5G) New Radio (NR) system that includes a wireless integrated access and backhaul (IAB) communication system or network. In the following description, embodiments and examples of the present invention are described with reference to a 5G NR system, but it will be understood that the present invention is not limited to 5G NR systems and may be used in any wireless communication system having an integrated access and backhaul communication system that shares radio resources for wireless access links and wireless backhaul links.

[0031] The system 100 comprises a plurality of UEs (User Equipments) 132, 133, 131 and 134, a remote core network 110, a main base station 120, two fixed integrated access and backhaul (IAB) stations 121 and 122, or IAB nodes 121 and 122 (hereinafter also referred to as IAB nodes), and a mobile integrated access and backhaul (IAB) station or mobile IAB node 123 mounted on a vehicle 105 (e.g., bus, train, taxi, car, etc.).

[0032] The main base station 120, also referred to as IAB donor 120 (or IAB donor), is connected to the core network 110 via a wired link 101, preferably optical fiber or any other wired means. In embodiments and examples of the present invention, the IAB donor 120 is a 5G NR base station (referred to as gNB) with additional features supporting IAB functionality as defined in the 3GPP TS 38.300v17.0.0 specification.

[0033] To extend the network coverage of the IAB donor 120 and reach the remote UEs 132, 133, and 131, IAB stations 121 and 122, also referred to as IAB nodes 121 and 122, are installed by the operator. By operating as relay nodes between the IAB donor 120 and the UEs 132 and 133, the IAB nodes 121 and 122 overcome reachability issues resulting from the presence of buildings 108, which are obstacles that impede radio wave propagation, thus enabling direct connection and further communication between the UEs and the IAB donor 120. This is especially true when communication between the IAB donor 120 and the UEs 132 and 133 is operated at millimeter wave frequencies, which are highly sensitive to shadowing phenomena.

[0034] The IAB donor 120 also serves the UEs 134 that are directly connected to it.

[0035] The mobile IAB station 123, also referred to as the IAB node 123 or mIAB node 123, mounted on the vehicle 105 also provides network coverage and capacity extension, allowing the IAB donor 120 to reach onboard remote UEs, such as remote UE 135, as well as UEs in the vicinity or surrounding the IAB node 123, such as remote UE 136.

[0036] The IAB donor 120 and IAB nodes 121, 122, and 123 thus form a backhaul network or IAB network (also referred to as IAB topology) that accommodates UEs 131, 132, 133, 134, 135, and 136. The terms IAB network and IAB topology are used interchangeably hereinafter. The IAB network forms a Radio Access Network (RAN) or is referred to in relation to 5G, Next Generation (NG) RAN.

[0037] Integrated Access and Backhaul (IAB) specifications are found across several 3GPP® standards documents, including: - TS 38.300 RAN Architecture (V17.0.0) - TS 38.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).

[0038] Because IAB nodes 121, 122, and 123 are connected to UEs 131, 132, 133, 134, 135, and 136, respectively, they are considered access IAB nodes for the connected UEs.

[0039] The IAB donor 120 is a logical node providing NR-based radio backhaul and consists of a central unit (CU or gNB-CU functionality) and connected donor distributed units (DU or gNB-DU functionality). The IAB-donor-CU or donor CU (hereinafter also referred to as IAB-donor CU or IAB donor CU) hosts higher layer protocols, such as PDCP (Packet Data Convergence Protocol) and RRC (Radio Resource Control) protocols, for controlling the operation of one or more DUs and one or more IAB-donor-DUs or donor DUs (hereinafter also referred to as IAB-donor DUs or IAB donor DUs), and includes lower layer protocols, such as RLC, MAC, and physical layer protocols. The IAB donor CU and IAB donor DU may be located remotely from each other or may be located in the same physical device. The gNB-DU functionality is defined in 3GPP TS 38.401. Its purpose is to terminate the NR access interface to the UE and next-hop IAB node, and to terminate the F1 protocol to the IAB donor gNB-CU function.

[0040] IAB nodes capable of serving multiple wireless sectors are wirelessly backhauled to the IAB donor 120 via one or more hops (e.g., via one or more IAB nodes). They form a directed acyclic graph (DAG) topology with the IAB donor at the root.

[0041] Each IAB node consists of an IAB-DU (IAB Distributed Unit) and an IAB-MT (IAB Mobile Terminal). The gNB-DU function on an IAB node, also referred to as the IAB-DU, enables downstream connections to the next-hop IAB or UE (towards the UE). The IAB-MT function includes, e.g., physical layer, Layer 2, RRC, and non-access stratum (NAS) functions for connecting to the gNB-DU of an upstream IAB node (including the IAB donor 120, which in turn connects to the IAB donor gNB-CU and thus to the core network 110, e.g., for initialization, registration, and configuration).

[0042] In this DAG topology, the neighboring nodes on the IAB-DU interface are called child nodes, and the neighboring nodes on the IAB-MT interface are called parent nodes. The direction towards the child nodes is further referred to as downstream, and the direction towards the parent nodes is referred to as upstream.

[0043] The IAB donor 120 (e.g., IAB donor CU) performs centralized resource, topology, and route management for the entire IAB topology, including, for example, configuring IAB nodes according to the network topology to perform proper routing of data packets.

[0044] 2(A) and 2(B) show a schematic diagram of the stack of several protocol layers involved in IAB operation.

[0045] The F1 interface supports the exchange of signaling information between endpoints as well as the transmission of data to each endpoint. From a logical point of view, the F1 interface is a point-to-point interface between the endpoints.

[0046] In 5G NR, F1-C is the functional interface in the control plane (CP) between the IAB donor CU and the IAB node DU. F1-U is the functional interface in the user plane (UP) of the same unit. F1-C and F1-U are indicated by reference numeral 212 in Figure 2(A). In this example, F1-U and F1-C are carried over two backhaul hops (from the IAB donor to IAB node 1, then from IAB node 1 to IAB node 2).

[0047] In the user plane, box 210 in the IAB donor CU and IAB node DU refers to the GTP-U layer, and box 211 refers to the UDP layer. GTP-U stands for GPRS Tunneling Protocol User Plane. GTP-U tunnels are used to carry encapsulated PDUs and signaling messages between a given pair of GTP-U tunnel endpoints (see 3GPP TS 29.281 for details), here box 210 in the IAB donor CU and IAB node DU. The well-known User Datagram Protocol (UDP) provides a best-effort datagram service and is a transport layer protocol adapted for use with the IP protocol.

[0048] In the control plane, box 210 denotes the F1AP (F1 Application Protocol) layer, and box 211 denotes the SCTP (Stream Control Transmission Protocol) layer. The F1 Application Protocol (as defined in 3GPP TS 38.473 and TS 38.401) provides signaling services between the IAB donor CU and the IAB node DU, or UE-related services. These services include initialization, configuration, etc. The well-known SCTP layer provides reliable, in-sequence delivery of messages with congestion control.

[0049] 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 TS 38.401.

[0050] Transport between the IAB donor DU and IAB donor CU may also use the IP transport layer over various media, such as wired or optical fiber if the IAB donor CU is remote from the IAB donor DU, or locally in a virtual instantiation of the IAB donor CU and IAB donor DU on the same physical machine. IAB-specific transport between the IAB donor CU and IAB donor DU is specified in 3GPP TS 38.401.

[0051] L1 and L2 in the diagram represent the transport layer and physical layer, respectively, appropriate to the medium in use.

[0052] The IP layer can also be used for non-F1 traffic, such as operations, management, and maintenance traffic.

[0053] In wireless backhaul, the IP layer is itself carried over a Backhaul Adaptation Protocol (BAP) sublayer, which enables routing over multiple hops. The BAP sublayer is specified in TS 38.340.

[0054] IP traffic in the IAB-DU is routed over the wireless backhaul via the BAP sublayer. In the downstream direction, upper layer packets are encapsulated by the BAP sublayer in the IAB donor DU, thus forming BAP packets or packet data units (PDUs) or data units. BAP packets are routed by the BAP layers of intermediate IAB nodes (and corresponding BAP entities in the IAB-DU and IAB-MT), if any. The BAP packets are finally de-encapsulated by the BAP sublayer at the destination IAB node (which may be the access IAB node for which the upper layer packets in the BAP packet are intended).

[0055] In the upstream direction, upper layer packets are encapsulated by the BAP sublayer in the initiator IAB node (which may be the access IAB node if the upper layer packet comes from the UE), thus forming a BAP packet or PDU or data unit. The BAP packet is routed by the BAP layer (and corresponding BAP entities in the IAB-DU and IAB-MT) of intermediate IAB nodes, if any. The BAP packet is finally de-encapsulated by the BAP sublayer in the IAB donor DU.

[0056] On the BAP sublayer, packets are carried in a BAP header and are routed based on a BAP routing ID set by the BAP sublayer of the network node in the IAB network that generates the BAP packet. Figure 3 shows the format of a BAP data protocol data unit (PDU) or packet, as specified in 3GPP TS38.340 Release 17.0.0 standardization version 6.2.

[0057] The header 30 includes fields 301 to 306. Field 301 is called the D / C field and is a Boolean value that indicates whether the corresponding BAP packet is a BAP data packet or a BAP control packet. Fields 302 to 304 are 1-bit reserved fields that are preferably set to 0 (ignored by the receiver).

[0058] Fields 305 and 306 together indicate the BAP routing ID for a BAP packet. The BAP address field 305, also called the destination field, is located in the leftmost 10 bits, and the BAP path identification field 306, also called the path field, is located in the rightmost 10 bits.

[0059] Field 305 carries the BAP address (i.e., on the BAP sublayer) of the destination IAB node or IAB donor DU for the BAP packet. For routing purposes, each IAB node and IAB donor DU is configured (by the IAB donor CU that controls the IAB network or topology to which the IAB node and IAB donor DU belong) with a designated BAP address. Field 306 carries a path ID that identifies the routing path that the BAP packet should take to this destination in the IAB topology. Routing paths, including their path IDs, are configured in the same way that BAP addresses are configured.

[0060] The BAP header is added to a packet when it arrives at the BAP layer from higher layers and is removed by the BAP layer when it reaches the destination node. The selection of a packet's BAP routing ID is configured by the IAB donor CU.

[0061] For example, when a BAP packet is generated by an IAB node, i.e., by an IAB donor for downstream transmission or by an initiator IAB node for upstream transmission (which may be the access IAB node where the upper layer packet is to come from the UE), a BAP header with a BAP routing ID is constructed by this IAB node according to a configuration table defined in 3GPP TS 38.340. This table is called the Downlink Traffic to Routing ID Mapping Configuration table of the IAB donor or the Uplink Traffic to Routing ID Mapping Configuration table of the initiator IAB node. In intermediate IAB nodes, the BAP header fields are already specified in the BAP packets they forward.

[0062] As mentioned above, these configuration tables that define the BAP paths (and therefore the routing strategy and configuration of the IAB nodes given the IAB network topology) are typically defined by the IAB donor CU that controls the IAB network and sent to the IAB nodes to configure them.

[0063] To handle the transfer of messages over the 5G NR wireless medium, three or more sublayers (RLC, MAC, and PHY) are implemented in each IAB node below the BAP sublayer. The RLC (Radio Link Control) sublayer is responsible for packet segmentation or reassembly. It is also responsible for requesting retransmission of missing packets. The RLC layer is further described in TS 38.322. The MAC (Medium Access Channel) protocol sublayer is responsible for selecting available transmission formats for user data and mapping logical channels to transport channels. The MAC also handles part of the hybrid automatic repeat request scheme. The MAC layer is detailed in TS 38.321. On the emitter or transmitter side, the MAC encapsulates data packets issued by the RLC. It adds a header carrying information required for the MAC function. On the receiver side, the MAC decapsulates data packets issued by the PHY, removes the header, and passes the remaining data to the RLC. The PHY sublayer provides the electrical interface to the transmission medium (air) by converting the information stream into a physical modulated signal and modulating the carrier frequency at the emitter side. At the receiver side, the PHY sublayer converts the physical modulated signal back into an information stream. The PHY layer is described in TS 38.201, TS 38.211, TS 38.212, TS 38.213, and TS 38.214.

[0064] Two other sublayers are used in the UE and IAB donor CU to pass messages towards the user or control plane: the PDCP (Packet Data Convergence Protocol) sublayer, the SDAP (Service Data Adaptation Protocol) sublayer for user plane communication, and the RRC (Radio Resource Control) sublayer for control plane communication.

[0065] The PDCP sublayer handles IP header compression / decompression, encryption / decryption, and data packet integrity as needed. It essentially numbers packets at the emitter and reorders them at the receiver. The PDCP sublayer is described in 3GPP TS 38.323.

[0066] The user plane SDAP sublayer 220 handles quality of service, which is described in TS 38.324. On the UE side, the SDAP sublayer exchanges payload data with user applications (voice, video, etc. (not shown)). On the IAB donor side, the SDAP sublayer exchanges data with the core network 110 (internet traffic, cloud, etc.).

[0067] The RRC sublayer 220 for the control plane handles the configuration of protocol entities in the user plane protocol stack, as described in TS 38.331. It is responsible for, among other things, broadcasting information necessary for UEs to communicate with cells, sending paging messages, managing connections including bearer setup, and handling mobility functions, measurement configuration, and reporting of device capabilities.

[0068] The interface between nodes (for both CP and UP) that uses PDCP, RLC, MAC and PHY layers is called NR-Uu, which primarily relates to the interface with the UE.

[0069] The interface between nodes (for both CP and UP) using the BAP, RLC, MAC and PHY layers is called the backhaul RLC channel (BH RLC channel). This primarily relates to the interface between IAB nodes.

[0070] The NR-Uu is the interface between the UE and the radio access network, i.e., its access IAB node (for both CP and UP).

[0071] Figure 2(B) is from 3GPP® TS 38.300v17.0.0 and shows the protocol stack for IAB-MT RRC and NAS connection support. The Non-Access Stratum (NAS) protocol handles messages between the core network and user equipment, here the IAB node. It manages the establishment of communication sessions and maintains communication with the user equipment as it moves. 5G NAS is described in 3GPP® TS 24.501. The 5G Core Access and Mobility Management Function (AMF) is a function within the core network that receives all connection and session-related information from UEs connected to IAB nodes, as well as similar information for IAB nodes. The AMF is solely responsible for handling connection and mobility management tasks.

[0072] The IAB-MT establishes signaling radio bearers SRBs (bearers carrying RRC and NAS messages) with the IAB-Donor-CU. These SRBs are transferred between the IAB-MT and its parent node over the NR-Uu interface.

[0073] 4 illustrates an example of a wireless communication system 400 including an IAB network or IAB network system, in which embodiments and example embodiments of the present invention may be implemented. In one exemplary implementation, the wireless link between the IAB node and the IAB donor DU node (referred to as a BH wireless link) is operated over the millimeter-wave frequency band (i.e., above 30 GHz), which is highly sensitive to wireless channel disturbances. The IAB network is also referred to as an IAB topology or topology, and therefore the terms IAB network and IAB topology and topology are used interchangeably in this application.

[0074] The IAB network system of FIG. 4 forms part of an NG RAN and is composed of two IAB networks or IAB topologies 4001 and 4002, each of which comprises a set of IAB nodes (e.g., the set may comprise 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 may include one or more IAB nodes, such as an initiator IAB node that generates BAP packets, and intermediate or relay IAB nodes. The set of IAB nodes may also include one or more IAB donor DUs. Each of the IAB nodes communicates with at least one other IAB node via a wireless backhaul (BH) link.

[0075] Although FIG. 4 shows two IAB topologies 4001 and 4002, the present invention is not limited to the two IAB topologies 4001 and 4002, but may be implemented in an IAB communication system with three or more IAB topologies, each topology comprising a set of IAB nodes and an IAB donor CU, as described above.

[0076] IAB topology 4001 includes 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 multiple IAB nodes 410, 420, 430, 460, 480 similar to IAB nodes 121 and 122, and IAB node 470 similar to mobile IAB node 123.

[0077] IAB topology 4002 includes IAB donor CU 402 (identified in FIG. 4 as Donor 2 CU), its associated IAB donor DU 405 (identified in FIG. 4 as Donor 2 DU1), and multiple IAB nodes 440 and 450 similar to IAB nodes 121 and 122. IAB network 400 can provide network path diversity through several IAB donor DUs and different IAB networks or topologies.

[0078] As described above, each IAB node comprises a mobile termination (MT) portion or unit that is controlled and configured by the IAB donor using RRC messaging defined in 3GPP® TS 38.331, and a distributed unit (DU) portion that is controlled and configured by the IAB donor using F1-AP messaging defined in 3GPP® TS 38.473. For example, IAB node 410 comprises MT portion or unit 411 and DU portion 412.

[0079] The wired backhaul IP network interconnects IAB donor CUs 401 and 402 and IAB donor DUs 403, 404, and 405 via wired link 406. For example, this wired link may consist of fiber optic cable(s).

[0080] IAB donor CU 401 , IAB donor DUs 403 and 404 , IAB nodes 410 , 420 , 430 , 460 , 470 , and IAB node 480 are part of the same IAB network or IAB topology 4001 that is controlled (e.g., configured and / or managed) by IAB donor CU 401 .

[0081] 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 that is controlled (eg, configured and / or managed) by IAB donor CU 402.

[0082] IAB node 470 is connected to parent IAB node 430 via BH link 4030. IAB node 470 is also connected to UE 390 via communication or wireless link 4031, with IAB node 470 acting as an access node for UE 390. While FIG. 4 shows only one UE 390, it will be understood that there may be multiple UEs connected to IAB nodes in the wireless communication system. IAB node 470 belongs to IAB network 4001 (IAB node 430 serves as the parent node via BH link 4030), but given its proximity to IAB network 4002, and in particular IAB node 450, IAB node 470 may connect to IAB node 450 (which serves as the parent node to IAB node 470) via wireless BH link 4050. In addition to or instead of a connection to IAB node 430, such a connection to IAB node 450 is possible for stationary IAB nodes and is highly likely when a mobile IAB node such as IAB node 470 moves, for example, in the direction of IAB topology 4002.

[0083] Each IAB node supports wireless communication in a coverage area called a cell. In other words, each IAB node is associated with a cell. A wireless communication device (e.g., a UE or another IAB node) located within a cell may connect to the IAB node serving the cell to communicate with other devices (e.g., other UEs, IAB nodes, servers providing access to the Internet, etc.) via the IAB node. Typically, an IAB node measures signals from IAB nodes of neighboring cells as part of a cell search procedure (e.g., when initially connecting to a network defined in 3GPP TS 38.300) or as part of a subsequent procedure. The measurements are reported to the IAB node's IAB donor CU. For example, referring to FIG. 4, an IAB node 470 can report the existence of a new cell served by IAB node 450 to its IAB donor CU 401 through a measurement report. Based on analysis of the measurement report (e.g., measurements in the report indicating that the signal strength provided by IAB node 450 is above a threshold for supporting communication), IAB donor CU 401 can request IAB donor CU 402, to which IAB node 450 belongs, to establish dual connectivity for IAB node 470 with an additional connection through IAB node 450. IAB donor CU 402 can accept the request and proceed to establish IAB node 470's connection to IAB node 450, according to the procedures described in Section 10.2 of TS 37.340v17.0.0. As a result, IAB node 470, which still belongs to IAB topology 4001, is also connected to IAB node 450, which belongs to IAB topology 4002, and thus may be referred to as a boundary node between IAB topologies 4001 and 4002. In practice, IAB node 470 maintains its F1 connection and its RRC connection to IAB donor CU 401 (which may be referred to as an F1-terminated IAB donor CU), and maintains a second RRC connection with IAB donor CU 402 (which may be referred to as a non-F1-terminated IAB donor CU).

[0084] Because 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 / or managed) by the IAB donor CU 402 of the IAB topology 4001. Through a second RRC connection, the IAB donor CU 402 assigns a second BAP address to be used for routing packets through the IAB topology 4002. Thus, the IAB node 470 functioning as a boundary node is assigned two BAP addresses, i.e., one BAP address for the IAB network 4001 and one BAP address for the IAB network 4002. Such a boundary node can help provide network path diversity by providing alternative routing paths through the IAB topologies 4001 and 4002.

[0085] Because IAB node 470 is a mobile IAB node (e.g., mounted on a vehicle), IAB node 470 is not always stationary but rather moves such that its connection to IAB nodes 430 and 450 may change over time. For example, if IAB node 470's movement is small and IAB node 470 and IAB nodes 430 and 450 are still close enough to each other to meet minimum requirements for supporting communication (e.g., signal strength is above a threshold), then its connection with IAB nodes 430 and 450 may not change. However, if IAB node 470's movement is such that IAB node 470 moves out of the cell associated with IAB node 430 and / or out of the cell associated with IAB node 450, then IAB node 470 may lose its connection with IAB node 430 and / or IAB node 450, respectively. In such cases, connections to the IAB node should be managed to avoid loss of service for wireless devices connected to the IAB node 470 (e.g., IAB node 430 and UE 390 as shown in FIG. 4) as the IAB node moves. For example, to ensure continuity of service, a handover procedure may be initiated such that one or more connections of the IAB node 470 (e.g., to IAB node 430) within the IAB communication system are handed over to a different cell. As discussed in the background, while using mobile IAB nodes helps increase connectivity (e.g., capacity) in a wireless communication system, connections to the mobile IAB node need to be managed to take into account the movement of the mobile IAB node.

[0086] A process for managing one or more network connections in a wireless communication system including one or more mobile IAB nodes will now be described in accordance with some embodiments of the present invention.

[0087] FIG. 11 illustrates steps of an exemplary method 1100 for use in managing network connectivity in a wireless communication system including at least one mobile integrated access and backhaul (mIAB) node, in accordance with an embodiment of the present invention. Method 1100 may be used to manage a connection to a network (e.g., a connection to the IAB network system of FIG. 4 or an NG RAN that provides connectivity to a core network) via or through the mIAB node. Method 1100 of FIG. 11 is performed in the mIAB node. For example, with reference to the wireless communication system shown in and described with reference to FIG. 4, the mIAB node performing method 1100 may be IAB node 470 of IAB topology 4001 controlled by IAB donor CU 401. Method 1100 shown in and described with reference to FIG. 11 may be performed by software and / or hardware elements. The mIAB node may be implemented in a communication device 1000 such as shown in and described with reference to FIG. 10 using the method shown in and described with reference to FIG. 11 executed by one or more processing units, such as a central processing unit 1011.

[0088] Briefly, in step 1101, an mIAB node (e.g., IAB node 470) provides a mobility message to a wireless communication device, the mobility message including at least one of mobility profile information indicating the mobility capabilities of the mIAB node and guaranteed stationary time information indicating a minimum period of time the mIAB node will remain at a location. The wireless communication device may be an IAB donor node (e.g., an IAB donor CU) or a UE or another IAB node. More generally, the mIAB node may be a network node of a mobile communication network, and the wireless communication device may be a control node for managing the control plane and data plane of a wireless communication system (e.g., controlling the network node), or a UE or another network node. The following description also applies to this more general scenario.

[0089] In one example, the mobility profile information may include at least one of speed information indicating the speed capability of the mIAB node, range information indicating the mobility area of ​​the mIAB node, stationary information indicating the duration of one or more stationary periods the mIAB node may experience, and journey information indicating a mobility sequence and stationary periods for a journey the mIAB node may follow. The speed information may include information indicating one or more of the minimum speed capability of the mIAB node, the average speed capability of the mIAB node, and the maximum speed capability of the mIAB node. The range information may include information indicating an area in which the mIAB node may travel or the range of movement of the mIAB node. For example, the range information may include a type or category of mobility area in which the mIAB node may travel, which may be an indication of the size or nature of the geographic area in which the mobile IAB node may travel. For example, the type (or category) of the mobility area may indicate that the geographic area is a bus route, a train route, or a parking lot. Additionally or alternatively, the range information may include the size of the area (i.e., mobility area) in which the mIAB node may move and / or a list of cell identifiers (IDs) of cells that the mIAB node has previously visited or may visit. Additionally or alternatively, the range information may include the distance the mIAB node may travel. The resting information may include resting time information indicating one or more of a minimum duration of a resting period, an average duration of a resting period, or a maximum duration of a resting period. The resting information may also include resting location information indicating where the mIAB is stationary. The journey information may include, for each of the mobility and resting periods, information indicating the duration of the period, the velocity of the mIAB node during one or more of the mobility periods, and the location of the mIAB node during the one or more resting periods.

[0090] Mobility profile information may be configured in the mIAB node during setup or subsequently. For example, the mobility profile information may be stored in a memory, such as the ROM 1007 or data storage means 1004, of the mIAB node. Setup may occur at the factory, if the mIAB node is a vehicle mounted relay (VMR), or as part of the process of installing the mIAB node on a vehicle. Mobility profile information may be configured or updated subsequently based on specific or known changes to the mobility of the mIAB node, which may depend on specific or known changes to the mobility of the vehicle in which the mIAB node is installed. Mobility profile information may be configured or updated based on tracking of previous movements of the mIAB node and / or the vehicle in which the mIAB node is installed or will be installed.

[0091] The guaranteed stationary time information (or minimum stationary time information) indicates the minimum period of time that an mIAB node will remain at a particular location. For example, for a mIAB node that is currently stationary, this information indicates the actual period of time that the mIAB node will remain stationary at a particular location. Thus, the guaranteed stationary time information corresponds to a dynamic parameter. For example, for a mIAB node mounted on a train currently parked at a station, based on train timetable and / or train route information (e.g., provided in mobility profile information), the guaranteed stationary time information may indicate the minimum period of time that the mIAB node will remain stationary. The guaranteed stationary time information may be determined by the mIAB node when the mIAB node is stationary based on the mobility profile information and may be included in a mobility message. Thus, whenever the mIAB node is stationary at a given location and the mIAB node determines the actual period of time that the mIAB node will remain stationary or fixed at that location, it may provide a mobility message including the guaranteed stationary time information.

[0092] The mobility message provided by the mIAB node may further include at least one of a mobile node indication indicating whether the mIAB node is a mobile IAB or a mobility status indication indicating a current status of the mobility of the mIAB node. The current status of mobility may include whether the mIAB node is currently moving or stationary, and may also include additional information regarding the nature of the movement, such as the current speed, whether the mIAB node is accelerating or decelerating.

[0093] In one example, the mIAB node retrieves mobility profile information and / or stationary time information (eg, from a memory) and generates a mobility message based on the retrieved information.

[0094] By providing the mobility profile information and / or guaranteed quiet time information (e.g., at setup time and / or after one or more connections to the mobile IAB node have been established), a receiving wireless communication device (e.g., an IAB donor CU, a UE, or another IAB node) can receive information about the mobile IAB node's mobile capabilities and / or current mobility status and can further act appropriately based on the additional information about the mobile IAB node's mobility. For example, based on the provided information, the UE or another IAB node may decide not to initiate a connection to a network (e.g., the IAB network system or NG RAN of FIG. 4) via or through the mobile IAB node, or the UE or another IAB node may decide to initiate a connection via the mobile IAB node but simultaneously initiate a cell search procedure to find another IAB node to use to connect to the network. In another example, the IAB donor CU may decide not to accept a connection request (attachment request) from a new IAB node (or UE) for a connection via the mobile IAB node due to the mobility of the mobile IAB node. For example, the IAB donor CU may prevent a connection of a new UE / IAB node to the network via a mobile IAB node if the new UE / IAB node is a legacy device (this is described in more detail below with reference to FIG. 8). In another example, when a mobility message is provided after a connection is established and information in the mobility message indicates a change in the mobility of the mobile IAB node (e.g., a change in the mobility status and / or mobility capabilities of the mobile IAB node (e.g., a change in guaranteed quiet time information)), along with additional information about the mobility of the mobile IAB node, the wireless communication device may act accordingly. For example, if the change was significant, the IAB donor CU may decide to release the established connection.

[0095] The mobility message may be a mobility indication message (e.g., mobility indication message 521, described in more detail below) provided or transmitted by the mIAB node to an IAB donor node (e.g., IAB donor CU 401). An IAB donor node that receives a mobility message from an mIAB node (e.g., IAB node 470) may be an IAB donor CU connected to the mIAB node, e.g., an IAB donor CU connected to and controlling the mIAB node (e.g., IAB donor CU 401 controlling IAB node 470), or, when the mIAB node operates as a boundary node, the IAB donor CU may be one or more IAB donor CUs to which the mIAB node is connected (e.g., IAB donor CUs 401 and / or 402 connected to IAB node 470 when the IAB node operates as a boundary node). Additionally or alternatively, the mobility message may be a mobility information message (e.g., mobility information message 531, described in more detail below) provided or transmitted by the mIAB node to one or more other IAB nodes (e.g., IAB nodes 430, 450) or one or more UEs (e.g., UE 390). For example, the mIAB node (e.g., IAB node 470) may transmit a mobility indication message to an IAB donor CU (e.g., IAB donor CU 401) connected to the mIAB node, and may also transmit a mobility information message to one or more other IAB nodes and / or one or more UEs.

[0096] The mobility indication message provided by the mIAB node to the IAB donor node may further include at least one of mobile node indication information indicating whether the mIAB node is a mobile IAB or mobility status indication information indicating a current status of the mobility of the mIAB node. The current status of mobility may include whether the mIAB node is currently moving or stationary, and may also include additional information regarding characteristics of the movement, such as a current speed, whether the mIAB node is accelerating or decelerating.

[0097] The mobility indication message may be provided to the IAB donor node (e.g., IAB donor CU 401 if the mIAB node is an IAB node 470 controlled by IAB donor CU 401) by the mIAB node in response to one of the following events: 1) by the mIAB node during a connection establishment procedure (e.g., as described in 3GPP® TS 38.331 and 3GPP® TS 38.332, as discussed in more detail below with respect to FIGS. 5 and 6). 38.401, or the F1 setup procedure), 2) in response to the mIAB node determining that there is a change in the mobility of the mIAB node (e.g., there is a change in mobility status, such as a change in speed, and / or a change in mobility capability, and / or there is a change in mobility profile information, such as a change in journey, and / or there is a change in guaranteed rest time information, such as when the mIAB stops at a location and determines a new period for the mIAB to be resting at that location), 3) after a specific period has elapsed since the last time a mobility indication message was transmitted, which may be the same or variable between transmissions, resulting in mobility indication messages being provided periodically, or 4) upon request from an IAB donor node (e.g., IAB donor CU401). For example, an IAB donor node may send a request for updated mobility status information, where the mobility indication message includes the updated mobility status information (e.g., updated mobility profile information and / or guaranteed quiet time information), and the mobility status indication information is provided in response to the request, as described in more detail below.

[0098] Mobility information messages provided (e.g., transmitted) by the mIAB node to one or more UEs (e.g., UE 390) and / or one or more other IAB nodes (e.g., IAB nodes 430, 450, 460, 480) may be provided in response to one of the following events: 1) after completion of an IAB node setup procedure (e.g., an RRC connection establishment procedure or an F1 setup procedure, discussed in more detail below with respect to Figures 5 and 6); 2) in response to the mIAB node determining that there is a change in the mobility of the mIAB node (e.g., a change in mobility status and / or mobility capability, such as a change in speed, and / or a change in mobility profile information, such as a change in journey, and / or a change in guaranteed rest time information, such as when the mIAB stops at a location and determines a new period for which the mIAB will be resting at that location); or 3) after a predetermined period has elapsed since the last time a mobility information message was transmitted, which may be the same or variable between transmissions, resulting in mobility indication messages being provided periodically.

[0099] By providing or transmitting a Mobility Information message with mobility profile information and / or guaranteed stillness time information, an mIAB node can advertise its mobility capabilities and / or status to one or more UEs and one or more other IAB nodes in the mIAB node's vicinity. Upon receiving the mobility information provided in the Mobility Information message, the UE and / or other IAB nodes can determine how to operate based on the mIAB node's mobility as indicated by the provided mobility information. With additional information regarding the mIAB node's mobility capabilities and / or guaranteed stillness time information, the UE and / or other IAB nodes have additional information and can therefore operate more effectively. For example, the UE and / or another IAB node can decide not to connect to the network through the mIAB node due to its mobility, or can decide to connect despite the mIAB node's mobility (e.g., because information indicates that the mIAB node is moving slowly or is within a limited area). In another example, if the UE and / or another IAB node is already connected, the UE and / or another IAB node may decide to initiate a cell search procedure to seek to connect to or hand over to another IAB node.

[0100] The mIAB node may provide a mobility information message to one or more UEs (such as UE 390) and / or one or more other IAB nodes (such as IAB nodes 430, 450, 460, 480), for example, by broadcasting it in a SIB1 message.

[0101] The mobility information message provided by the mIAB node to one or more UEs and / or one or more other IAB nodes may further include a connectivity support indicator (also referred to as an IAB support indicator, IAB support information, or connectivity support information) to indicate whether the mIAB node can support network connectivity for a wireless communication device (e.g., a UE or another IAB node). The ability of the mIAB node to support network connectivity for other wireless communication devices (e.g., whether a reliable radio link can be established and maintained between the mIAB node and the other wireless communication device) depends on the mobility of the mIAB node (e.g., the mobility capability and / or current mobility status of the mIAB node). In some cases, movement of the mIAB node may mean that the mIAB node cannot support network connectivity. In one example, when the mIAB node can support network connectivity, the mIAB node sets or enables a connectivity support indicator or IAB or connectivity support information by including the IAB support information or connectivity support information in a mobility information message (e.g., within a field of the mobility information message) to indicate that network connectivity can be supported by the mIAB node. The IAB or connectivity support information may include information indicating that the mIAB node can support network connectivity and / or that a cell associated with the mIAB node can be considered a candidate for cell (re)selection. When the mIAB node cannot support network connectivity, the mIAB node does not set or disable a connectivity support indicator or IAB or connectivity support information by not including the IAB support information or connectivity support information in a mobility information message to indicate that network connectivity cannot be supported by the mIAB node.For example, when an mIAB node can support network connectivity, a field indicating both support by the mIAB node and cell status is included in the mobility information message; when an mIAB node cannot support network connectivity and / or when a cell associated with the mIAB node is barred for wireless communication devices, the field is not included. Thus, the presence or absence of the field in the mobility information message provided by the mIAB node indicates whether network connectivity is supported or not, respectively. In other words, the mIAB node performs conditional IAB support management to determine whether the mIAB node can support network connectivity and, based on the determination, determines whether to include or not include IAB support information in the mobility information message. In an alternative configuration, the mobility information message may include a connectivity support indicator that may be set to one value indicating that the mIAB node cannot support network connectivity and another value indicating that the mIAB node can support network connectivity.

[0102] The mIAB node may determine whether the mIAB node can support network connectivity, and accordingly, whether the mIAB node sets a connectivity support indicator or IAB support information or connectivity support information, based on the mIAB node's mobility (e.g., based on the mIAB node's mobility capability (e.g., as indicated in the mIAB node's mobility profile information)) and / or based on the mIAB node's guaranteed quiet time information and / or current mobility status. As described above, the mobility profile information and / or guaranteed quiet time information, and any subsequent updates, if necessary, may be stored in the IAB node (e.g., at setup or thereafter) and used to determine whether the IAB node can support network connectivity.

[0103] In another configuration, an IAB donor node (e.g., IAB donor CU 401) connected to an IAB node (e.g., IAB node 470 managed by IAB donor CU 401) can determine whether the mIAB node can support network connectivity, and therefore whether the mIAB node sets a connectivity support indicator or IAB support information or connectivity support information (e.g., including a field with IAB or connectivity support information in a mobility information message), based on the mobility of the mIAB node. The IAB donor node can determine the mobility of the mIAB node based on mobility information (e.g., mobility profile information and / or guaranteed quiet time information) received from the mIAB node. The mobility information may be provided by the mIAB node to the IAB donor node at IAB node setup or subsequently in a mobility indication message as described above, and based on the mobility information provided in the mobility indication message, the IAB donor node may determine whether the mIAB node is capable of supporting network connectivity and may send a connectivity or IAB support configuration message (e.g., an RRC reconfiguration message described below with reference to FIG. 5) indicating whether the mIAB node is capable of supporting network connectivity to the mIAB node. The mIAB node may then determine based on the received connectivity or IAB support configuration message whether it is capable of supporting network connectivity and whether it configures a connectivity support indicator or IAB support information or connectivity support information.

[0104] In response to determining that the mIAB node can support network connectivity, the mIAB node may provide a mobility information message including IAB support information to indicate network connectivity for wireless communication devices that can be supported by the IAB node.

[0105] In one example, an mIAB node is determined to be capable of supporting network connectivity when either the mIAB node or the IAB donor node determines that the mIAB node is or will be stationary for a period longer than a predetermined threshold (e.g., the threshold may be as low as tens of seconds) or when the mIAB node is moving with limited mobility. The mobility of the mIAB node is limited when at least one of the following criteria or conditions is met: the speed of the mIAB node is below a certain threshold (e.g., the actual speed of the mIAB node (e.g., as indicated by mobility status indication information or speed-related information in mobility profile information) is below a predefined threshold), the mobility area in which the mIAB node is moving or will move is geographically restricted, or the mobility area is within one topology or one network cell (e.g., information in the mobility profile information indicates that the mIAB node will remain under the same topology or the same network cell). A geographically restricted mobility area may include an area in which an mIAB node is traveling or will travel, and which has a size below a predetermined or predefined threshold, or may include an area having a type or category (i.e., having a size below a certain threshold) that is considered to be geographically restricted. Such a type or category having a limited size may include a parking lot.

[0106] In another example, when the mIAB node is determined to be moving or to be a mobile node (ie, having the ability to move), the mIAB node is determined to be incapable of supporting network connectivity.

[0107] The mobility information message may further include at least one of mobile node indication information indicating whether the mIAB node is a mobile IAB node, mobility status indication information indicating a current status of the mobility of the mIAB node, and mobile IAB cell indication information for indicating a cell associated with the mobile IAB node (e.g., a cell ID may be included in the mobility information message). The current status of mobility may include whether the mIAB node is currently moving or stationary, and may also include additional information regarding the nature of the movement, such as a current speed, and / or whether the mIAB node is accelerating or decelerating, etc.

[0108] Further details regarding mobility indication messages sent to IAB donor nodes and mobility information messages sent to other IAB nodes or UEs are provided below.

[0109] 12 , which illustrates steps of an exemplary method 1200 according to an embodiment of the present invention, the method is performed in a wireless communication device upon receipt of a mobility information message transmitted by an IAB node of a wireless communication system, the IAB node being controlled by an IAB donor node. Method 1200 may be used to manage network connectivity in a wireless communication system including at least one mobile integrated access and backhaul (mIAB) node. The wireless communication device performing method 1200 may be another IAB node or a UE in the wireless communication system, either of which may operate in proximity to the IAB node to receive the mobility information message. 4, the wireless communication device performing method 1200 may be IAB donor CU 401 of IAB topology 4002 controlled by IAB donor CU 402 or IAB node 460 of IAB topology 4001 controlled by IAB node 440, or the UE 390 and the IAB node providing the mobility message may be a mobile IAB node, IAB node 470, controlled by IAB donor CU 401. Method 1200 shown in and described with reference to FIG. 12 may be performed by software and / or hardware elements. A wireless communication device performing method 1200 may be implemented in communications device 1000 as shown in and described with reference to FIG. 10, with the method shown in and described with reference to FIG. 12 executed by one or more processing units, such as central processing unit 1011.

[0110] Briefly, in step 1201, a wireless communication device receives a mobility information message from an IAB node. The wireless communication device then performs an action based at least in part on the information provided by the received mobility information message in step 1202. The IAB node sending the mobility information message may be a mobile IAB node or a fixed IAB node (in the sense that the IAB node is fixed in one location).

[0111] When the IAB node is a mobile IAB node, mIAB node, the mobility information message includes at least one of mobility profile information indicating the mobility capabilities of the IAB node and guaranteed rest time information indicating a minimum period of time the IAB node will remain at a location. The mobility profile information may include at least one of speed information indicating the speed capabilities of the IAB node, range information indicating a mobility area of ​​the IAB node, rest information indicating the duration of one or more rest periods the IAB node may experience, and journey information indicating a sequence of mobility and rest periods for a journey the IAB node may follow. The mobility information message may further include at least one of mobile node indication information indicating whether the IAB node is a mobile IAB node, mobility status indication information indicating a current status of the IAB node's mobility, mobile IAB cell indication information to indicate a cell associated with the mobile IAB node (e.g., a cell ID is included in the mobility information message), and IAB support information or connectivity support information (also referred to as a connectivity indicator) to indicate whether the IAB node can support network connectivity for a wireless communication device (e.g., a UE or another IAB node). Further details of the mobility information provided by an IAB node and included in the mobility information message received at a wireless communication device are provided above in connection with FIG. 11.

[0112] When the IAB node is a fixed IAB node, the mobility information message may include mobile node indication information indicating that the IAB node is not a mobile IAB node.

[0113] Upon receiving the mobility information provided in the mobility information message, the UE and / or other IAB nodes can determine how to operate based on the mobility of the mIAB node as indicated by the provided mobility information. With additional information regarding the mobility capabilities and / or guaranteed quiet time information of the mIAB node, the UE and / or other IAB nodes have additional information and can therefore operate more effectively as described above.

[0114] In one example, performing the action in step 1202 may include determining, based on the mobility information message, whether to initiate a connection establishment or setup procedure to establish a connection to a network (e.g., the IAB network system or NG RAN of FIG. 4) via the IAB node, such as an RRC connection establishment procedure, or via the IAB node. The wireless communication device may determine not to initiate a connection establishment procedure when the information provided by the mobility information message indicates that the IAB node is a mobile IAB node. The wireless communication device may determine to initiate a connection establishment procedure when the information provided by the mobility information message indicates that several criteria are met. The predetermined criteria include: 1) the IAB node is not a mobile IAB node; 2) the IAB node is a mobile IAB node and is stationary or has been stationary for a period longer than a predetermined threshold; and 3) the IAB node is a mobile IAB node and is moving with limited mobility. As described above, the criteria for limited mobility include the velocity of the IAB node being below a predetermined threshold, the mobility area being geographically restricted, and the mobility area being within one topology or one network cell.

[0115] When the wireless communication device determines that a connection establishment procedure should be initiated, performing the actions in step 1202 may further include sending a request to an IAB donor node (e.g., IAB node 470) via the IAB node (e.g., IAB node 470) to request establishment of a connection via the IAB node (IAB node 470). The request is sent as part of a connection establishment procedure, such as an RRC connection establishment procedure. When the wireless communication device is a UE (e.g., UE 390), the requested connection is with an IAB topology of the IAB node (IAB node 470) managed by the IAB donor node (e.g., topology 4001 managed by donor CU 401), and upon completion of the connection procedure, the UE will be connected to the IAB node (IAB node 470) via a communication link or a wireless link. When the wireless communication device is an IAB node (such as IAB node 460), the requested connection involves an IAB topology of the IAB node (IAB node 470) managed by an IAB donor node (e.g., topology 4001 managed by donor CU 401), and upon completion of the connection procedure, the IAB node (such as IAB node 460) or other IAB nodes are connected to the IAB node (IAB node 470) via a backhaul (BH) communication link or BH link. In response to the request, the wireless communication device receives a configuration message from the IAB donor node (e.g., donor CU 401). For example, the configuration message received at the wireless communication device (UE or IAB node) indicating that the connection via the IAB node has been accepted may be an RRC Setup message, or the configuration message indicating that the connection via the IAB node has been rejected may be an RRC Reject message instead of the RRC Setup message specified in 3GPP TS 38.331.If the wireless communication device is an IAB node (such as IAB node 460) and after IAB node 460 is connected to IAB node 470, the configuration message may indicate that the BH link between the IAB node and the mobile IAB node has been rejected or configured, in which case the configuration message may be an RRCReconfiguration message as defined in 3GPP TS 38.331 (such as CONFIGURATION INFORMATION message 732 as illustrated in FIG. 7).

[0116] In one example, when a connection through an IAB node is rejected because the IAB node is a mobile IAB node or the cell associated with the IAB node (or the requested connecting cell) is a mobile cell, the configuration message includes IAB configuration rejection cause information indicating why the connection was rejected (e.g., indicating that the connection was rejected because the IAB node is a mobile IAB node or the cell associated with the IAB node (or the requested connecting cell) is a mobile cell). As described in more detail below with respect to FIG. 7, when a UE sends a request to establish a connection through an IAB node as part of a connection establishment procedure, the rejection cause information may include MobileCellConnectionReject or Mobile Cell connection rejection information, which indicates to the UE that the connection request was rejected because it attempted to connect to the network through a mobile IAB node. As described in more detail below with respect to FIG. 7, when an IAB node sends a request to establish a connection through an IAB node as part of a connection establishment procedure, the rejection cause information may include iab-configRejectCause or IAB configuration Rejection Cause information. The configuration message may further include IAB configuration reject information indicating that the connection has been rejected.

[0117] When a connection through an IAB node is accepted, the configuration message includes IAB configuration acceptance information indicating that the connection has been accepted. When the IAB node is a mobile IAB node, regardless of whether the connection through the IAB node is accepted or rejected, the configuration message may include mobility profile information indicating the mobility capabilities of the IAB node. Details of mobility profile information are provided above. Such cause information, and if provided, mobility profile information, can help the wireless communication device efficiently determine what to do next, for example, select an alternative IAB node to attempt and establish a connection with without using resources, reattempt the connection with the mobile IAB node, or, if the provided information indicates that the mobile IAB node is moving slowly or within a limited area, the wireless communication device can attempt to reestablish the connection through the mobile IAB node.

[0118] When the IAB node is a mobile IAB node and the wireless communication device is another IAB node (e.g., a child IAB node), the configuration message may further include mobile parent IAB node indication information indicating that the parent IAB node is a mobile IAB node and the associated cell is a mobile cell.

[0119] When the wireless communication device is another IAB node (i.e., a child IAB node) connected to an IAB node (i.e., a parent IAB node), for example, the MT portion of IAB node 460 is connected to the DU portion of IAB node 470 after completion of the connection establishment procedure, performing the action may comprise providing a mobility capability message (such as MOBILITY INFORMATION message 541 described below with reference to FIG. 5) including information indicating the mobility capabilities of the IAB node based on information provided by a received mobility information message received from the IAB node. The mobility capability message includes information indicating the mobility capabilities of the IAB node based on information provided by a received mobility information message received from the IAB node. The mobility capability message may be transmitted (e.g., via broadcast) to all nodes (e.g., UEs and IAB nodes) in the vicinity of the child IAB node. As described above, the mobility capability message may include all or part of the information received from the IAB node in the mobility information message, such as mobility profile information and / or guaranteed quiet time information, and / or mobile node indication information and / or mobility status indication information and / or IAB support information. Furthermore, the mobility capability message may further include identifier information for identifying the IAB node, such as a unique BAP address of the IAB node. If the IAB node is a boundary node, the BAP address included in the mobility capability message is a BAP address configured by an IAB donor CU that controls the child IAB node (i.e., a BAP address of the same topology to which the child IAB node belongs).

[0120] When the wireless communication device is another IAB node (i.e., a child IAB node) connected to an IAB node (i.e., a parent IAB node), for example, the MT portion of IAB node 460 is connected to the DU portion of IAB node 470 after completion of a connection establishment procedure, performing the action may comprise determining a radio link failure (RLF) for the radio link with the parent IAB node (i.e., a BH link) based on information provided by the received mobility information message and transmitting an RLF indication message. The RLF indication message includes information indicating that the cause of the RLF is related to the mobility of the parent IAB node. For example, the information provided by the received mobility information message may indicate that the parent IAB node is a mobile IAB node, or has recently become a mobile IAB node, or was previously a mobile IAB node but has recently changed its mobility status or capabilities (e.g., moving out of range), such that an RLF occurs on the BH link between the child IAB node and the parent IAB node. The RLF indication message is received by the child IAB node(s) of the child IAB node (now acting as parent), and the child IAB node(s) can act accordingly.

[0121] Another exemplary method performed in a wireless communication device of a wireless communication system according to an embodiment of the present invention will now be described. The wireless communication system further comprises an IAB node controlled by an IAB donor node. Similar to the above-described method, this method can be used to manage network connectivity in a wireless communication system including at least one mobile integrated access and backhaul (mIAB) node. The wireless communication device may be another IAB node or a UE in the wireless communication system. The wireless communication device determines to initiate a connection establishment procedure to connect to a network (e.g., the IAB network system or NG RAN of FIG. 4) via the IAB node: for example, the wireless communication device is either operating in the vicinity of the IAB node or has previously operated in the vicinity of the IAB node to which it is now moving. For example, with reference to the wireless communication system shown and described in FIG. 4, the wireless communication device may be IAB donor CU 402 or UE 390 controlled IAB donor CU 401 of IAB topology 4002 controlled by IAB donor CU 402 or UE 390 controlled IAB node 460 of IAB topology 4001 controlled by IAB node 440, and the IAB node to which the wireless communication device wishes to connect may be a mobile IAB node, IAB node 470, controlled by IAB donor CU 401. The method may be performed by software and / or hardware elements. A wireless communication device performing the method may be implemented in communication device 1000 as shown in and described with reference to FIG. 10, with the method being performed by one or more processing units, such as central processing unit 1011.

[0122] A wireless communication device transmits a request to an IAB donor node (e.g., IAB donor CU 401) via an IAB node (e.g., IAB node 470) to request establishment of a connection via the IAB node (IAB node 470). The request is transmitted as part of a connection establishment procedure, such as an RRC connection establishment procedure. In response to the request, the wireless communication device receives a configuration message from the IAB donor node (e.g., donor CU 401). As described below, the configuration message may be an RRC Setup message, an RRC Reject message, or an RRC Reconfiguration message. In one example, when a connection to an IAB node is rejected, the configuration message includes IAB configuration reject cause information indicating why the connection was rejected (e.g., indicating that the IAB node is a mobile IAB node or that the connection was rejected because the cell associated with the IAB node (or the requested connecting cell) is a mobile cell). As described in more detail below with respect to Figure 7, when a UE sends a request to establish a connection through an IAB node as part of a connection establishment procedure, the rejection cause information may include MobileCellConnectionReject or Mobile Cell connection rejection information, which indicates to the UE that the connection request was rejected because it attempted to connect to the network through a mobile IAB node. As described in more detail below with respect to Figure 7, when an IAB node sends a request to establish a connection through an IAB node as part of a connection establishment procedure, the rejection cause information may include iab-configRejectCause, or IAB configuration Rejection Cause information. The configuration message may further include IAB configuration rejection information, which indicates that the connection was rejected.

[0123] When a connection to an IAB node is accepted, the configuration message includes IAB configuration acceptance information (e.g., a configured BH link) indicating that the connection has been accepted. When the IAB node is a mobile IAB node, regardless of whether a connection to the IAB node is accepted or rejected, the configuration message may include mobility profile information indicating the mobility capabilities of the IAB node. Details of mobility profile information are described above. The advantages of providing such cause information, and the mobility profile information, if provided, are described above.

[0124] When the IAB node is a mobile IAB node and the wireless communication device is another IAB node (e.g., a child IAB node), the configuration message may further include mobile parent IAB node indication information indicating that the parent IAB node is a mobile IAB node and the associated cell is a mobile cell.

[0125] Referring now also to FIG. 13 , which illustrates steps of an exemplary method 1300 according to an embodiment of the present invention, performed in an IAB donor node of a wireless communication system upon receipt of a mobility indication message transmitted by an IAB node connected to the IAB donor node. The IAB donor node may be an IAB donor CU connected to and controlling the IAB node (e.g., IAB donor CU 401 controlling IAB node 470), or, if the IAB node operates as a boundary node, the IAB donor CU may be one or more IAB donor CUs to which the IAB node is connected (e.g., IAB donor CUs 401 and / or 402 both connected to IAB node 470 when IAB node 470 operates as a boundary node). Method 1300 may be used to manage network connectivity in a wireless communication system including at least one mobile integrated access and backhaul (mIAB) node. The IAB donor node may be an IAB donor CU. For example, with reference to the wireless communication system shown in and described with reference to FIG. 4, the IAB donor node may be the IAB donor CU 401, and the IAB node may be the IAB node 470 controlled by the IAB donor CU 401. The method 1300 shown in and described with reference to FIG. 13 may be performed by software and / or hardware elements. The IAB donor node performing the method 1300 may be implemented in the communications device 1000 as shown in and described with reference to FIG. 10, with the method shown in and described with reference to FIG. 13 being executed by one or more processing units, such as the central processing unit 1011.

[0126] Briefly, in step 1301, an IAB donor node receives a mobility indication message from an IAB node. The IAB donor node then performs an action based at least in part on information provided by the received mobility indication message in step 1302. The mobility indication message is received at a CU portion of the IAB donor node (i.e., IAB donor CU), and the IAB donor CU performs the action. For example, IAB donor CU 401 receives a mobility indication message from IAB node 470.

[0127] The mobility indication message includes at least one of mobility profile information specifying the mobility capabilities of the IAB node and guaranteed rest time information indicating a minimum period of time the IAB node will remain in a given location. The mobility profile information may include at least one of speed information indicating the speed capability of the IAB node, range information indicating a mobility area of ​​the IAB node, rest information indicating the duration of one or more rest periods the IAB node may experience, and journey information indicating a sequence of mobility and rest periods for a journey the IAB node may follow.

[0128] The mobility indication message may further include at least one of mobile node indication information indicating whether the IAB node is a mobile IAB node and mobility status indication information indicating a current status of the IAB node's mobility. More details of the information (e.g., mobility profile information, guaranteed quiet time information, etc.) included in the mobility indication message provided by the IAB node and received at the IAB donor node are provided above in connection with FIG. 11.

[0129] Upon receiving the mobility information provided in the mobility indication message, the IAB donor node or IAB donor CU can determine how to operate based on the mobility of the IAB node as indicated by the provided mobility information. With additional information regarding the mobility capabilities and / or guaranteed quiet time information of the IAB node, the IAB donor node has additional information and can therefore operate more effectively as described above.

[0130] In one example, performing the action in step 1302 may include, based on the information provided in the mobility indication message, sending a notification message by the IAB donor node to one or more of another IAB node (e.g., IAB node 430), a UE (e.g., UE 390), or a CU of an IAB donor node of another IAB topology different from the topology controlled by the IAB donor node (e.g., IAB donor CU 401 sending a notification to IAB donor CU 402 of IAB topology 4002) to indicate that the IAB node is a mobile IAB node. By sending the notification, the IAB donor node can provide information regarding the mobility of the IAB node to other wireless communication devices in the wireless communication system, which can help the other devices act accordingly. When an IAB node moves into the coverage of another IAB topology (e.g., when IAB node 470 moves into the coverage of IAB topology 4002), by providing a notification message to the CU of an IAB donor node (e.g., IAB donor CU 402) of another IAB topology indicating the mobility of the IAB node, the mobility information can be used by the IAB donor CU of the other topology to manage the migration of the IAB node to the other topology.

[0131] An IAB donor node may receive a mobility indication message as part of an IAB node setup procedure with an IAB node (e.g., an RRC connection establishment procedure specified in 3GPP TS 38.331 or an F1 setup procedure, as described in more detail below with respect to FIGS. 5 and 6). Alternatively or additionally, the IAB donor node may receive the mobility indication message in response to a message sent by the donor IAB node. For example, the IAB donor node may send a request for latest mobility status information, where the mobility indication message includes latest mobility status information (e.g., latest mobility profile information and / or guaranteed rest time information), where the mobility status indication information is provided in response to the request, as described in more detail below. Alternatively or additionally, the IAB donor node may receive the mobility indication message in response to the IAB node determining a mobility change (e.g., there is a mobility status change, such as a speed change, and / or there is a mobility profile information change, such as a journey change, and / or there is a guaranteed rest time information change). Alternatively or additionally, the IAB donor node may periodically receive mobility indication messages from the IAB node, with the time between receipt of the mobility indication messages being the same or variable.

[0132] In one example, upon receiving the mobility indication message as part of the IAB node setup procedure, the IAB donor node completes the IAB node setup procedure with the IAB node. Information provided in the mobility indication message is stored by the IAB donor node for the IAB node. Subsequently, upon receiving a request from a wireless communication device, which may be a UE or another IAB node, to establish a connection via the IAB node as part of a connection establishment procedure (e.g., an RRC connection establishment procedure), performing action 1302 may comprise determining whether to accept or reject (i.e., accept or not accept) the connection via the IAB node based at least in part on the mobility of the IAB node. In response to determining whether to accept or reject the connection request, the IAB donor node then transmits a configuration message to the wireless communication device (e.g., the UE or another IAB node) indicating whether the connection with the IAB node was accepted or rejected. For example, the configuration message indicating that the connection via the IAB node has been accepted may be an RRCSetup message, or the configuration message indicating that the connection via the IAB node has been rejected may be an RRCReject message instead of an RRCSetup message, as defined in 3GPP TS 38.331. If the wireless communication device is an IAB node (e.g., IAB node 460), after IAB node 460 connects to IAB node 470, the configuration message may indicate that the BH link between the IAB node and the mobile IAB node has been rejected or configured, in which case the configuration message may be an RRCReconfiguration message as defined in 3GPP TS 38.331 (e.g., CONFIGURATION INFORMATION message 732 as illustrated in FIG. 7).

[0133] An IAB donor node can determine whether to accept or reject a connection via the IAB node based on information provided by a mobility indication message received at the IAB donor node (e.g., received as part of a setup procedure or subsequently). As described above, the mobility indication message includes mobility profile information and / or guaranteed quiet time information, which can be used to determine whether a connection should be accepted or rejected. For example, the IAB donor node can make its determination based on the mobility profile information. The mobility indication message (e.g., received as part of a setup procedure, such as periodically received from the IAB node when the IAB node detects a change in the IAB node's mobility, such as a change in mobility status and / or mobility capabilities, received in response to a request from the IAB donor CU, or received subsequently) can further include mobility status information indicating a current status of the IAB node's mobility. In this case, the IAB donor node can determine whether to accept or reject a connection via the IAB node based on the current status of the IAB node's mobility. In one example, an IAB donor node may decide to accept or reject a connection through an IAB node based on the current status of the IAB node's mobility and the mobility capabilities of the IAB node, as indicated by the mobility profile information. The IAB donor node may decide to reject a connection request when the IAB node is a mobile IAB node or when the IAB node is a mobile IAB node with mobility capabilities and / or current mobility status that are likely to cause problems for the connection (e.g., the IAB node's area of ​​mobility is large, the average speed is above a threshold, the current speed is above a threshold, etc.).

[0134] In one example, if a connection through an IAB node is rejected based on the mobility of the IAB node (e.g., because the IAB node is a mobile IAB node or the cell associated with the IAB node is a mobile cell), the configuration message includes IAB configuration rejection cause information indicating why the connection was rejected (e.g., indicating that the connection was rejected because the IAB node is a mobile IAB node or the cell associated with the IAB node is a mobile cell). As described in more detail below with respect to FIG. 7, when a UE sent a request to establish a connection through an IAB node as part of a connection establishment procedure, the rejection cause information may include MobileCellConnectionReject or Mobile Cell connection rejection information, which indicates to the UE that the connection request was rejected because it attempted to connect to the network through a mobile IAB node. As described in more detail below with respect to FIG. 7, when an IAB node sent a request to establish a connection through an IAB node as part of a connection establishment procedure, the rejection cause information may include iab-configRejectCause or IAB configuration Rejection Cause information. The configuration message may further include IAB configuration reject information indicating that the connection has been rejected.

[0135] When a connection through an IAB node is accepted, the configuration message includes IAB configuration acceptance information indicating that the connection has been accepted. When the IAB node is a mobile IAB node, regardless of whether a connection through the IAB node is accepted or rejected, the configuration message may include mobility profile information indicating the mobility capabilities of the IAB node. Details of mobility profile information are described above. The benefits of providing such cause information, and, if provided, mobility profile information, are described above.

[0136] When the IAB node is a mobile IAB node and the wireless communication device is another IAB node (e.g., a child IAB node), the configuration message may further include mobile parent IAB node indication information indicating that the IAB node is a mobile parent IAB node and the associated cell is a mobile cell.

[0137] In one example, performing action 1302 by the IAB donor node may comprise determining whether to enable or disable network connectivity support by the IAB node based at least in part on the mobility of the IAB node, and, based on the determination, transmitting a connectivity or IAB support configuration message (e.g., an RRC reconfiguration message described below with reference to FIG. 5) to the IAB node to indicate whether the IAB node can support network connectivity for the wireless communication device. The wireless communication device may be a UE or another IAB node. The IAB donor node may make the determination based on information provided by the mobility indication message. In one example, the IAB donor node may make the determination based on the current status of the IAB node's mobility (if the information is included in the mobility indication message) and / or the mobility capabilities of the IAB node, as indicated by mobility profile information and / or guaranteed quiet time information. Further details of the connectivity or IAB support configuration message are discussed above with reference to FIG. 11.

[0138] An IAB donor node may determine to disable network connectivity support when an IAB node is a mobile IAB node or when the IAB node is a mobile IAB node with mobility capabilities and / or current mobility status that are likely to cause connectivity issues (e.g., the IAB node's area of ​​mobility is large, the average speed is above a threshold, the current speed is above a threshold, etc.). The IAB donor node may determine to enable network connectivity support when the IAB node is stationary or has been stationary for a period longer than a predetermined threshold, or when the IAB node is moving with limited mobility. In one example, the mobility of an IAB node is limited when at least one of the following criteria or conditions is met: the IAB node's speed is below a predetermined threshold; the mobility area is geographically limited; or the mobility area is within one topology or one network cell. For more information about limited mobility criteria, see above (e.g., the description of FIG. 11).

[0139] In an example where the IAB donor node receives a new mobility indication message that includes updated information compared to a previously received mobility indication message (e.g., updated mobility profile information and / or mobility status information indicating a current status of the IAB node's mobility), performing the action may comprise determining whether one or more wireless communication devices (e.g., one or more UEs and / or one or more other IAB nodes) connected to the IAB node should be released based on the information provided by the new mobility indication message, and in response to determining that the one or more wireless communication devices should be released, sending a release notification to the one or more wireless communication devices.

[0140] FIG. 14 illustrates steps of an exemplary method 1400 for use in managing network connectivity in a wireless communication system including at least one integrated access and backhaul (IAB) node of the wireless communication system, according to an embodiment of the present invention. The method 1400 of FIG. 14 is performed in an IAB node. For example, with reference to the wireless communication system shown in and described with reference to FIG. 4, the IAB node performing the method 1400 may be the IAB node 470 of the IAB topology 4001 controlled by the IAB donor CU 401. The method 1400 shown in and described with reference to FIG. 14 may be performed by software and / or hardware elements. The IAB node may be implemented in the communication device 1000 shown in and described with reference to FIG. 10, such that the method shown in and described with reference to FIG. 14 is performed by one or more processing units, such as the central processing unit 1011.

[0141] Briefly, in step 1401, an IAB node (e.g., IAB node 470) determines whether the IAB node can support network connectivity for a wireless communication device (e.g., another IAB node or a UE) based on the mobility of the IAB node. In response to determining that the IAB node can support network connectivity, in step 1402, the IAB node provides a mobility information message including IAB support information or connectivity support information (also referred to as an IAB support indicator) to indicate network connectivity for a wireless communication device (e.g., a UE or another IAB node) that can be supported by the IAB node. As discussed above with reference to FIG. 11 , the ability of the IAB node to support network connectivity for other wireless communication devices (e.g., whether a reliable wireless link can be established and maintained between the IAB node and the other wireless communication device) depends on the mobility of the IAB node (e.g., the mobility capability and / or current mobility status of the IAB node). The mobility information message may be provided to or transmitted to one or more wireless communication devices, such as one or more other IAB nodes or one or more UEs. For example, the mobility information message may be broadcast in an SIB1 message.

[0142] The mobility information message may further include at least one of: mobility profile information indicating the mobility capabilities of the IAB node; guaranteed stationary time information indicating a minimum period of time the IAB node will remain at a given location; mobile node indication information indicating whether the IAB node is a mobile IAB node; mobility status indication information indicating a current status of the IAB node's mobility; and mobile IAB cell indication information to indicate a cell associated with the mobile IAB node (e.g., a cell ID may be included in the mobility information message). In one example, the mobility profile information may include at least one of speed information indicating the speed capabilities of the mIAB node; range information indicating the mobility area of ​​the mIAB node; stationary information indicating the duration of one or more stationary periods the mIAB node may experience; and journey information indicating mobility sequences and stationary periods for journeys the mIAB node may follow. Further details regarding the mobility information message transmitted to other IAB nodes or UEs are provided above with respect to FIG. 11.

[0143] In one example, when an IAB node can support network connectivity, the IAB node sets or enables an IAB support information or connectivity support information or connectivity support indicator by including the IAB support information or connectivity support information in a mobility information message (e.g., within a field of the mobility information message) to indicate that network connectivity can be supported by the IAB node. The IAB support information or connectivity support information may include information indicating that the IAB node can support network connectivity and / or that a cell associated with the IAB node can be considered a candidate for cell (re)selection. When an IAB node cannot support network connectivity, the IAB node does not set or disables the IAB support information or connectivity support information or connectivity support indicator in the Mobility Information message by not including the IAB support information or connectivity support information in the Mobility Information message to indicate that the IAB node cannot support network connectivity. For example, when an IAB node can support network connectivity, a field indicating both support by the IAB node and cell status is included in the Mobility Information message, and when the IAB node cannot support network connectivity and / or the cell associated with the IAB node is barred for wireless communication devices, the field is not included. Thus, the presence or absence of the field in the Mobility Information message provided by the IAB node indicates whether network connectivity is supported, respectively.In an alternative configuration, the mobility information message may include a connectivity support indicator that may be set to one value indicating that the mIAB node is not capable of supporting network connectivity and to another value indicating that the mIAB node is capable of supporting network connectivity.

[0144] An IAB node may determine whether it can support network connectivity based on the IAB node's mobility (e.g., based on the IAB node's mobility capabilities (e.g., as indicated in the IAB node's mobility profile information)) and / or based on the IAB node's guaranteed quiet time information and / or current mobility status. As described above, the mobility profile information and / or guaranteed quiet time information, and any subsequent updates, if necessary, may be stored in the IAB node (e.g., at setup or thereafter) and used to determine whether the IAB node can support network connectivity.

[0145] In another example, an IAB node (e.g., IAB node 470) may receive a connectivity or IAB support configuration message (e.g., in an RRC reconfiguration message described below with reference to FIG. 5) from a donor CU node (e.g., IAB donor CU 401) connected to the IAB node (e.g., an IAB donor CU controlling the IAB node) indicating whether the IAB node can support network connectivity. The IAB node determines whether the IAB node can support network connectivity based on the received connectivity or IAB support configuration message. In this example, the IAB donor node (e.g., IAB donor CU 401) connected to the IAB node (e.g., IAB node 470 managed by IAB donor CU 401) may determine whether the IAB node can support network connectivity and, therefore, whether the IAB node should include connectivity support information in a mobility information message (e.g., include or not include a field in the mobility information message) based on the mobility of the IAB node. 11 and / or 13, an IAB donor node (e.g., IAB donor CU 401) can determine the mobility of an IAB node based on mobility information received from the IAB node (e.g., mobility profile information and / or guaranteed quiet time information, etc.). The mobility information may be provided by the IAB node to the IAB donor node at IAB node setup or subsequently in a mobility indication message sent by the IAB node to the IAB donor node as described above, and based on the mobility information provided in the mobility indication message, the IAB donor node can determine whether the IAB node can support network connectivity.

[0146] In one example, an IAB node determines that an IAB node can support network connectivity when the IAB node has been or will be stationary for a period longer than a predetermined threshold, or when the IAB node is moving with limited mobility. The mobility of an IAB node is limited when at least one of the following criteria or conditions is met: the IAB node's speed is below a predetermined threshold; the mobility area is geographically restricted; or the mobility area is within one topology or one network cell. For more details about limited mobility criteria, see above (e.g., the description of Figure 11 and / or Figure 13).

[0147] In another example, when the mIAB node is determined to be moving or to be a mobile node (ie, having the ability to move), the mIAB node is determined to be incapable of supporting network connectivity.

[0148] When it is determined that the mIAB node cannot support network connectivity, the IAB support information may be disabled or not set in the mobility information message (e.g., the IAB support information is not included in the mobility information message), but the mobility information message may still include at least one of mobility profile information, guaranteed quiet time information, mobile node indication information, mobility status indication information, and mobile IAB cell indication information.

[0149] Reference is now also made to Figure 5, which is a schematic and simplified diagram illustrating some exemplary message flows for use in managing network connectivity in a wireless communication system including at least one IAB node in accordance with one or more embodiments of the present invention, and which may be used to manage the advertising by an IAB node of its mobility capabilities and state, as well as its ability to support IAB connections with child IAB nodes.

[0150] According to one example, a mobile IAB node 501 (which may correspond to IAB node 123 of FIG. 1 and IAB node 470 of FIG. 4, as discussed above) may share some mobility information with its IAB donor 502 (which may correspond to IAB donor node 120 of FIG. 1 and IAB donor CU 401 of FIG. 4) by sending a MOBILITY INDICATION message 521. The MOBILITY INDICATION message 521 is an example of a mobility indication message as discussed above with reference to FIGS. 11-14.

[0151] According to one example, this mobility information sharing may be performed at setup time of the mobile IAB node 501. According to another example, mobility information sharing may be performed on an ad-hoc basis. In this regard, it may be triggered by a change in the mobility status of the mobile IAB node 501, may be performed periodically, or may be performed in response to a request from the IAB donor 502 (e.g., IAB donor CU 401).

[0152] If mobility information sharing is performed on a mobile IAB node setup, according to one example, such mobility information sharing is performed at the time of RRC connection establishment, and the MOBILITY INDICATION message 521 is an RRCSetupComplete message used to complete the RRC connection establishment process, as specified in 3GPP TS 38.331.

[0153] According to another example, when mobility information sharing is performed on a mobile IAB node setup, said mobility information sharing is performed as part of the F1 setup procedure, and the MOBILITY INDICATION message 521 is an F1 SETUP REQUEST message, as specified in 3GPP TS 38.473.

[0154] If mobility information sharing is performed intentionally, according to one example, the MOBILITY INDICATION message 521 is one of the Measurement Report, Failure Information, IAB Other Information or UE Information Response messages specified in 3GPP TS 38.331, or the GNB-DU CONFIGURATION UPDATE message specified in 3GPP TS 38.473.

[0155] According to one example, the MOBILITY INDICATION message 521 includes all or part of the following IAB node mobility information (e.g., information indicating the mobility of the IAB node): -mobileiab-NodeIndication, or Mobile IAB Node Indication Information (also called Mobile Node Indication Information). This information is used to indicate that the device sending the MOBILITY INDICATION message 521 is a mobile IAB node (i.e., an IAB node with mobility capabilities) and, in the case of connection establishment, that the connection is established by a mobile IAB node. -mobility-StatusIndication, or mobility status indication information. This information is used to indicate the current status of the mobility of the mobile IAB node, such as whether the mobile IAB node is currently moving. This information may also include additional information related to the nature of the movement, e.g., the speed of the mobile IAB node. -guaranteedStaticTime, or guaranteed stationary time information. This information indicates the minimum guaranteed period that a mobile IAB node will remain at a fixed location. For example, a bus that previously stopped at a bus stop can indicate the remaining time before moving to the next bus stop. -mobility-Profile, or mobility profile information. This information provides an indication of the mobility capabilities of the mobile IAB node. The mobility profile information may include at least one of the following information: Speed-related information or speed information indicating the speed capability of the mobile IAB node such as minimum speed, average speed, maximum speed, etc. Information about the mobility area or mobility range of the mobile IAB node (e.g., range information indicating the mobility area of ​​the mobile IAB node), such as the mobility area type, the mobility area size, or a list collecting cell IDs of several cells that the mobile IAB node has previously visited or may visit. The mobility area type (or category) may be an indication of the size or nature of the geographical area in which the mobile IAB node may move. For example, the mobility area type (or category) may indicate that the geographical area is a bus route, a train route, or a parking lot. Information indicating the duration of stationary periods that the mobile IAB node may experience (e.g., stationary information), such as a minimum stationary period duration, an average stationary period duration, or a maximum stationary period duration. The stationary information may also include stationary location information indicating the location at which the mIAB is stationary. Journey information to be made up of a sequence of mobility and rest periods (e.g., indicating a sequence of mobility and rest periods for a journey that the mIAB node may follow). The journey information may include, for each mobility and rest period, the duration of the period and the velocity of the mobile IAB node during this period.

[0156] According to one example, once a mobile IAB node 501 (e.g., IAB node 470) completes a connection setup process with an IAB donor 502 (e.g., IAB donor CU 401), the mobile IAB node 501 may provide or transmit (e.g., via broadcast) a MOBILITY INFORMATION message 531 for advertising purposes to other wireless communication devices (referred to as network devices in FIG. 5) in its vicinity, such as network device 503. MOBILITY INFORMATION message 531 is an example of the MOBILITY INFORMATION message described above with reference to FIGS. 11-14.

[0157] According to one example, network device 503 is an IAB node, such as IAB node 121 or 123 of FIG. 1 and IAB nodes 430, 450, 460, 480 of FIG.

[0158] According to another example, the network device 503 is a UE such as the UE 135 or 136 of FIG. 1 and the UE 390 of FIG.

[0159] This MOBILITY INFORMATION message 531 may be sent periodically.

[0160] In one aspect, the MOBILITY INFORMATION message 531 is a SIB1 message as defined in 3GPP TS 38.331.

[0161] According to an example embodiment of the present invention, the MOBILITY INFORMATION message 531 includes all or part of the following IAB node mobility information: - iab-support, or IAB support information. For example, IAB support information (or connectivity support information) may indicate whether an IAB node can support network connectivity for a wireless communication device. As defined in 3GPP TS 38.331, this information combines both IAB support and cell status for IAB. If this information is present in the MOBILITY INFORMATION message 531, the cell supports IAB and is also considered a candidate for cell (re)selection for an IAB node; if the field is not present, the cell does not support IAB and / or the cell is barred for IAB nodes. - mobileiab-NodeIndication, or mobile IAB node indication information (also called mobile node indication information), which is used to indicate that the device sending the MOBILITY INFORMATION message 531 is a mobile IAB node (i.e., an IAB node with mobility capabilities) and that the associated cell is a mobile cell. - mobility-StatusIndication, or mobility status indication information. This information is used to indicate the current status of the mobility of the mobile IAB node, such as whether the mobile IAB node is currently moving. This information may also include additional information related to the nature of the movement, e.g., the speed of the mobile IAB node. - guaranteedStaticTime or guaranteed static time information. This information indicates the minimum guaranteed period that a mobile IAB node will remain in a static position. For example, a bus that previously stopped at a bus stop can indicate the remaining time before moving to the next bus stop. - mobility-profile, or mobility profile information. This information provides an indication of the mobility capabilities of the mobile IAB node. The mobility profile information may include at least one of the following information: Speed-related information or speed information indicating the speed capability of the mobile IAB node such as minimum speed, average speed, maximum speed, etc. Information about the mobility area or mobility range of the mobile IAB node (e.g., range information indicating the mobility area of ​​the mobile IAB node), such as the mobility area type, the mobility area size, or a list collecting cell IDs of several cells that the mobile IAB node has previously visited or may visit. The mobility area type (or category) may be an indication of the size or nature of the geographical area in which the mobile IAB node may move. For example, the mobility area type (or category) may indicate that the geographical area is a bus route, a train route, or a parking lot. Information indicating the duration of stationary periods that the mobile IAB node may experience (e.g., stationary information), such as a minimum stationary period duration, an average stationary period duration, or a maximum stationary period duration. The stationary information may also include stationary location information indicating the location at which the mIAB will be stationary. Journey information to be made up of a sequence of mobility and rest periods (e.g., indicating a sequence of mobility and rest periods for a journey that the mIAB node can follow). The journey information may include, for each mobility and rest period, the duration of the period and the velocity of the mobile IAB node during this period.

[0162] Based on the IAB node mobility information in the previously received MOBILITY INFORMATION message 521, the IAB donor 502 can decide to enable or disable the presence of iab-support information in the MOBILITY INFORMATION message 531 by sending an IAB SUPPORT CONFIGURATION message 522 to the mobile IAB node 501. The IAB SUPPORT CONFIGURATION message 522 is an example of the connectivity or IAB support configuration message described above with reference to Figures 11-14.

[0163] According to one example, the IAB SUPPORT CONFIGURATION message 522 is an RRCReconfiguration message defined in 3GPP TS 38.331.

[0164] According to one example, if the network device 503 is an IAB node connected to the mobile IAB node 501 as a child IAB node, the IAB node 503 may also provide or transmit (e.g., via broadcast) a MOBILITY INFORMATION message 541 to several potential IAB nodes (and / or UEs) in its vicinity for advertising purposes. The MOBILITY INFORMATION message 541 may include all or part of the IAB node mobility information carried by the MOBILITY INFORMATION message 531 previously received from the mobile IAB node 501. Furthermore, the MOBILITY INFORMATION message 541 may include some information indicating the identifier of the mobile IAB node 501 or identifier information for identifying the IAB node 501, such as a BAP address (defined in 3GPP TS 38.340). The MOBILITY INFORMATION message 541 is an example of the mobility capability message described above with reference to FIG. 12.

[0165] According to another example, if network device 503 is an IAB node connected to mobile IAB node 501 as a child IAB node, IAB node 503 may experience some backhaul (BH) radio link failure (RLF), for example, when mobile IAB node 501 has moved too far and is out of range. IAB node 503 may then send an RLF INDICATION message 542 to each of its child IAB nodes and add some information in this message to notify the child IAB nodes that the radio link failure results from the mobility of its parent IAB node 501. For example, RLF INDICATION message 542 may include information indicating that the cause of the RLF is related to the mobility of the parent IAB node.

[0166] Figure 6 illustrates, using a flowchart 600, an exemplary method for managing connectivity of a mobile IAB node according to some embodiments of the present invention. Flowchart 600 illustrates steps performed in a mobile IAB node and an IAB donor node, and is an example of steps performed in a mobile IAB node and an IAB donor node as described above with reference to Figures 11-14. The method as illustrated in and described with respect to Figure 6 may be performed by software and / or hardware elements.

[0167] The process begins in step 601, where a mobile IAB node, such as mobile IAB node 501 in FIG. 5 and IAB node 470 in FIG. 4, initiates connection setup (e.g., initiates an IAB node setup procedure) with an IAB donor CU (such as IAB donor 502 in FIG. 5 and IAB donor CU 401 in FIG. 4) or detects a change in mobility status and / or capabilities.

[0168] According to one example, in step 601, the mobile IAB node 470 may initiate the connection setup process by sending an RRC Setup Request message to the IAB donor CU 401 as part of the RRC connection establishment procedure specified in 3GPP TS 38.331. According to another example, in step 601, the mobile IAB node 470 may initiate the connection setup process by sending an F1 SETUP REQUEST message to the IAB donor CU 401 as part of the F1 setup procedure specified in 3GPP TS 38.473, which is used to exchange application-level data required for the gNB-DU and gNB-CU to properly interoperate over the F1 interface. According to another example, in step 601, the mobile IAB node 470 may detect a change in its mobility, such as a change in mobility status and / or capabilities. This change may include, for example, a change in velocity, a change in its guaranteed stationary duration, or an update to its mobility profile, as described above in connection with FIG. 5.

[0169] In step 601, the mobile IAB node 470 may further transmit some IAB node mobility information to the IAB donor (e.g., IAB donor CU 401) via, for example, a MOBILITY INDICATION message 521, as described with reference to FIG. 5 .

[0170] If, in step 601, the mobile IAB node sent any IAB node mobility information to the IAB donor via the MOBILITY INDICATION message 521, the IAB donor may, in step 602, determine whether IAB support or connectivity support by the mobile IAB node should be enabled (e.g., when the IAB node can support network connectivity for wireless communication devices) or disabled (e.g., when the IAB node cannot support network connectivity for wireless communication devices) and further notify the mobile IAB node thereof, for example, by sending an IAB SUPPORT CONFIGURATION message 522, as described with reference to FIG. 5. As described above, if the mobile IAB node indication information (mobileiab-NodeIndication) in the MOBILITY INDICATION message 521 sent by the IAB node indicates that the node is a mobile IAB node, the IAB donor may determine that IAB support for the IAB node is disabled. The IAB donor may decide in step 601 to enable IAB support for the mobile IAB node as long as the mobile IAB node is stationary or remains stationary for a significant period of time (i.e., a duration above a threshold that may be as low as tens of seconds) as determined based on information provided in the MOBILITY INDICATION message 521 (such as mobility status indication information and / or guaranteed stationary time information).

[0171] In one example, the IAB donor may decide in step 601 to enable IAB support for a mobile IAB node regardless of its actual movement, as long as its mobility is restricted, as determined based on the information provided in the MOBILITY INDICATION message 521. See above (e.g., the description of Figure 11 and / or Figures 13 and 14) for details on restricted mobility criteria / conditions.

[0172] In step 603, the mobile IAB node 470 performs conditional IAB support management by providing (e.g., broadcasting) a MOBILITY INFORMATION message 531 to potential child IAB nodes (and / or UEs) along with associated mobility information, e.g., as described with reference to FIG. 5. The mobile IAB node 470 can disable sending of IAB support information in the MOBILITY INFORMATION message 531 (e.g., by not including the IAB support information in the MOBILITY INFORMATION message 531) as long as the mobile IAB node is actually moving. The mobile IAB node 470 can enable advertising of IAB support information in the MOBILITY INFORMATION message 531 if it is currently moving but its mobility remains restricted (e.g., by including the IAB support information in the MOBILITY INFORMATION message 531). For more details on restricted mobility criteria / conditions that a mobile IAB node 470 may consider when determining whether its mobility is restricted, see above (e.g., the description of Figure 11 and / or Figures 13 and 14).

[0173] According to another example, the mobile IAB node 470 may decide in step 602 to enable or disable advertising of IAB support information in the MOBILITY INFORMATION message 531 based on information embedded in an IAB SUPPORT CONFIGURATION message 522 received from an IAB donor (e.g., IAB donor CU 401), for example, as described with reference to FIG. 5 .

[0174] In an example embodiment, the mobile IAB node 470 may advertise its mobility profile in the MOBILITY INFORMATION message 531 when advertising IAB support is enabled (i.e., when it sends IAB support information in the MOBILITY INFORMATION message 531) in step 603. For example, when the IAB node 470 can support network connectivity for a wireless communication device (e.g., an IAB node / UE), the MOBILITY INFORMATION message 531 may include mobility profile information and IAB support information. In another example implementation, the mobile IAB node 470 may advertise its mobility profile in the MOBILITY INFORMATION message 531 when IAB support is disabled (i.e., when it does not send IAB support information in the MOBILITY INFORMATION message 531) in step 603. For example, when an IAB node 470 cannot support network connectivity for a wireless communication device (e.g., an IAB node / UE), the MOBILITY INFORMATION message 531 sent by the mobile IAB node 470 may still include mobility profile information even though the IAB support information is configured (e.g., not included in the MOBILITY INFORMATION message 531).

[0175] Reference is now also made to Figure 7, which is a schematic and simplified diagram illustrating some exemplary message flows for use in managing a connection of a wireless communication device (referred to as a network device in Figure 7) to a mobile IAB node, in accordance with some embodiments of the present invention. The network device or wireless communication device may be an IAB node for which the mobile IAB node is a parent mobile IAB node, or an IAB node for which the mobile IAB node is an access node (such as UE 135 or 136 in Figure 1 and UE 390 in Figure 4, as described above).

[0176] According to one example, mobile IAB node 701 (which may correspond to IAB node 123 of FIG. 1 and IAB node 470 of FIG. 4, as discussed above) may share IAB node mobility information with IAB donor 702 (which may correspond to IAB donor node 120 of FIG. 1 and IAB donor CU 401 of FIG. 4, as discussed above) by sending MOBILITY INDICATION message 521. MOBILITY INDICATION message 521 is an example of a mobility indication message, as discussed above with reference to FIGS. 5, 11-14.

[0177] A new network device 703 may wish to join a topology managed by an IAB donor 702 (e.g., an IAB topology or network 4001 managed by an IAB donor 401). According to one example, the network device 703 is an IAB node similar to IAB node 121 or 123. According to another example, the network device 703 is a UE similar to UE 135 or 136.

[0178] To join a topology managed by an IAB donor 702, a network device 703 may attempt to connect to the topology via the mobile IAB node 701 (which, if the network device 703 is an IAB node, acts as a parent IAB node for the network device 703) by performing an RRC connection establishment procedure 731 with the IAB donor 702 via the mobile IAB node 701, as specified in 3GPP® TS 38.331 and 3GPP® TS 38.401. During this procedure, the network device 703 exchanges RRCSetupRequest, RRCSetup, and RRCSetupComplete messages with the DU portion of the mobile IAB node 701 over the Uu interface, while the DU portion of the mobile IAB node 701 conveys these messages to the CU portion of the IAB donor 702 using the F1 AP protocol.

[0179] The IAB donor 702 can reject the connection of the network device 703 by sending an RRCReject message instead of an RRCSetup message, as specified in 3GPP TS 38.331.

[0180] Once a connection between the IAB node 703 and the network is established, if the network device 703 is an IAB node, the IAB donor 702 may decide to configure or reject the configuration of a BH link between the IAB node 703 and the mobile IAB node 701 by sending a CONFIGURATION INFORMATION message 732 to the IAB node 703.

[0181] According to one example, the CONFIGURATION INFORMATION message 732 is an RRCReconfiguration message as defined in 3GPP TS 38.331.

[0182] The CONFIGURATION INFORMATION message 732 and the RRCReject message / RRCSetup message are examples of configuration messages described above with reference to FIGS.

[0183] The CONFIGURATION INFORMATION message 732 (or RRCReject message / RRCSetup message) sent to the network device 703 may include at least one of the following information (which information is included depends on whether the network device 703 is an IAB node or a UE): - iab-configReject, or IAB configuration Reject information, which, when present in the CONFIGURATION INFORMATION message 732, indicates to the IAB node 703 that the IAB donor 702 does not allow the IAB node 703 to be a child IAB node of the mobile IAB node 701. - MobileCellConnectionReject, or Mobile Cell connection rejection information, which, if present in the CONFIGURATION INFORMATION message 732, indicates to the UE 703 that the connection request has been rejected because the UE attempted to connect to the network via a mobile IAB node. - iab-configRejectCause, or IAB configuration Rejection Cause information. When present in the CONFIGURATION INFORMATION message 732, this information indicates to the IAB node 703 why the iab-configReject information is present in the CONFIGURATION INFORMATION message 732, i.e., why the IAB donor 702 does not allow the IAB node 703 to be a child IAB node of the mobile IAB node 701. In one example, the IAB configuration Rejection Cause information may inform the IAB node 703 that the IAB donor CU 702 does not allow the IAB node 703 to be a child IAB node of the mobile IAB node 701 because the IAB node 701 is a mobile IAB node. - mobility-profile, or mobility profile information. This information provides an indication of the mobility capabilities of the mobile IAB node 701. The mobility profile information may include at least one of the following information: Speed-related information or speed information indicating the speed capabilities of the mobile IAB node, such as minimum speed, average speed, and maximum speed. Information about the mobility area or mobility range of a mobile IAB node (e.g., range information indicating the mobility area of ​​the mobile IAB node), such as the type of mobility area, the size of the mobility area, or a list collecting cell IDs of several cells that the mobile IAB node has previously visited or can visit. The type (or category) of a mobility area may be an indication of the size or nature of the geographical area in which the mobile IAB node may move. For example, the type (or category) of a mobility area may indicate that the geographical area is a bus route, a train route, or a parking lot. Information indicating the duration of quiet periods that the mobile IAB node may experience (e.g., quietness information), e.g., minimum quiet period duration, average quiet period duration, or maximum quiet period duration. Itinerary information to be made up of a sequence of mobility and rest periods (e.g., indicating the sequence of mobility and rest periods for a journey that the mIAB node can follow). The itinerary information may include, for each mobility and rest period, the duration of the period and the speed of the mobile IAB node during this period. - mobileParentiab-NodeIndication, or mobile Parent IAB node indication information, which is used to indicate that the parent IAB node (i.e., IAB node 701) is a mobile IAB node (i.e., an IAB node with mobility capabilities) and the associated cell is a mobile cell.

[0184] FIG. 8 illustrates, using a flowchart 800, an exemplary method for managing a connection of a wireless communication device (referred to as a network device with respect to FIG. 8) to a network (e.g., an IAB network or topology) of a wireless communication system via a mobile IAB node, in accordance with some embodiments of the present invention. Flowchart 800 illustrates steps performed in a wireless communication device (or network device) and an IAB donor node, examples of steps performed in a wireless communication device and an IAB donor node as described above with reference to FIGS. 11-14. The mobile IAB node is an access node, and the network device or wireless communication device may be an IAB node or a UE (such as UE 135 or 136 of FIG. 1 and UE 390 of FIG. 4, as described above). The method as illustrated in and described with respect to FIG. 8 may be performed by software and / or hardware elements.

[0185] The process begins in step 801, where a new network device similar to network device 703 (e.g., IAB node 460 or UE 390 in FIG. 4 ) requests, via a mobile IAB node 701 (e.g., mobile IAB node 470 in FIG. 4 ), also referred to as connecting IAB node 701, to join a topology managed by IAB donor 702, such as the CU portion or CU of IAB donor 702 (e.g., topology or network 4001 managed by IAB donor 401 in FIG. 4 ).

[0186] According to one example, new network device 703 is an IAB node similar to IAB node 121 or 123 or IAB node 460.

[0187] According to another example, the new network device 703 is a UE similar to UE 135 or 136 or UE 390.

[0188] To join a topology or network managed by a CU of an IAB donor 702, a new network device 703 may attempt to connect to the network via a connecting IAB node 701 (which acts as a parent IAB node for the network device 703 if the network device 703 is an IAB node) by performing an RRC connection establishment procedure with the IAB donor 702 as specified in 3GPP TS 38.331 and by sending a request to the IAB donor 702.

[0189] In step 802, the CU of the IAB donor 702 (e.g., IAB donor CU 401) performs a connection procedure with the new network device 703 and checks the mobility capability and status information associated with the connecting IAB node 701 to determine whether to allow the network device 703 to connect to the network via the connecting IAB node 701. If the network device 703 is an IAB node, the CU portion of the IAB donor 702 determines whether to allow the configuration of a BH link between the new network device 703 and the connecting IAB node 701 (which then acts as the parent IAB node of the new network device 703).

[0190] In one example, the CU of the IAB donor 702 (e.g., IAB donor CU 401) checks the IAB node mobility information embedded in the MOBILITY INDICATION message 521 previously received from the connecting IAB node 701 to decide whether to allow or reject the connection, and if the new network device 703 is an IAB node, determines whether to allow the configuration of a BH link between the new network device 703 and the connecting IAB node 701 (then acting as the parent IAB node of the new network device 703).

[0191] To obtain the latest IAB node mobility information, the CU of the IAB donor 702 can request transmission of a MOBILITY INDICATION message 521 to the serving IAB node 701. In one example, the MOBILITY INDICATION message 521 is a UEInformationResponse message sent by the serving IAB node 701 to the CU of the IAB donor node 702 in response to a UEInformationRequest message, defined in 3GPP TS 38.331, sent by the IAB donor 702 to the serving IAB node 701.

[0192] In one example, the CU of the IAB donor 702 may not allow a new network device 703 to connect to the topology or network it manages if the mobile IAB node indication information (mobileiab-NodeIndication) previously received from the connecting IAB node 701 indicates that the connecting IAB node 701 is a mobile IAB node. In another example where the new network device 703 is an IAB node, the CU of the IAB donor 702 may not allow configuration of a BH link between the new network device 703 and the connecting IAB node if the mobile IAB node indication information (mobileiab-NodeIndication) previously received from the connecting IAB node indicates that the requested parent IAB node 701 is a mobile IAB node.

[0193] In another example, the CU of the IAB donor 702 may allow a connection of a new device 703 to the network via the connecting IAB node 701, or if the network device 703 is an IAB node, even if the connecting IAB node 701 is a mobile IAB node, the CU of the IAB donor 702 may allow the configuration of a BH link between the new IAB node 703 and the connecting IAB node 701 (in this case acting as a parent IAB node) as long as the mobile IAB node 701 is stationary or remains stationary for a period longer than a predetermined threshold (which may be a low threshold, for example, on the order of tens of seconds), where the predetermined threshold is determined based on the mobility status indication information and / or guaranteed static time information in the MOBILITY INDICATION message 521 previously received from the connecting IAB node 701.

[0194] According to another example, the CU of the IAB donor 702 may enable connection of a new device 703 to the network via the connecting IAB node 701, or if the network device 703 is an IAB node, the CU of the IAB donor 702 may enable configuration of a BH link between the new IAB node 703 and the connecting IAB node 701 (in this case acting as a parent IAB node), even if the connecting IAB node 701 is a mobile IAB node, as long as the mobile IAB node 701 has limited mobility. In other words, as long as the connecting IAB node 701 is moving with limited mobility.

[0195] The mobility of a mobile IAB node may be considered restricted if one of the restricted mobility criteria / conditions described above (e.g., in the description of Figure 11 and / or Figures 13 and 14), or any combination thereof, is met.

[0196] In the example where the CU of the IAB donor 702 decides in step 803 not to allow the configuration of a BH link between the new IAB node 703 and the connecting IAB node 701, the CU of the IAB donor 702 sends a CONFIGURATION INFORMATION message 732 to the new IAB node 703, as defined above with reference to FIG. 7, containing all or part of the following information: - iab-configReject or IAB configuration Reject information to indicate that the connection or configuration was rejected - iab-configRejectCause, or IAB configuration Rejection Cause information, to indicate why the connection was rejected (e.g., because the connecting IAB node 701 is a mobile IAB node). - mobility-Profile, or mobility profile information, to indicate the mobility capabilities of the connecting IAB node 701.

[0197] In the example where the CU of the IAB donor 702 decides in step 803 to allow the configuration of a BH link between the new IAB node and the requested parent IAB node, the CU of the IAB donor 702 sends a configuration information message 732 to the new IAB node 703, as defined in FIG. 7, which does not include the following information: - iab-configReject, or IAB configuration reject information - iab-configRejectCause, or IAB configuration Reject Cause information Nevertheless, in this latter case, the CONFIGURATION INFORMATION message 732 sent to the new IAB node 703 may contain the following information, as defined above with reference to FIG. 7: - mobility-Profile, or mobility profile information, to indicate the mobility capabilities of the connecting IAB node 701.

[0198] In the example where the CU of the IAB donor 702 decides in step 803 not to allow the new network device 703 to connect to the network, the CU of the IAB donor 702 may send an RRCReject message to the network device 703, and may add all or part of the following information to this message: - RRCRejectCause, or RRC Rejection Cause information. When present in an RRCReject message, this information indicates to the network device 703 the reason why its connection to the network was rejected. According to one example, the RRC Rejection Cause indicates that the network device 703 attempted to connect to the network via a mobile node, such as a mobile IAB node or a mobile IAB donor DU. MobileCellConnectionReject, or Mobile Cell connection rejection information, is an example of RRCRejectCause, or RRC Rejection Cause information, and may be included in the RRCReject message sent to the UE 703 when the connection request is rejected because the UE attempted to connect to the network via a mobile IAB node.

[0199] - mobility-Profile, or mobility profile information, to indicate the mobility capabilities of the connecting IAB node 701, as defined above with reference to Figure 7.

[0200] 9 illustrates, using a flowchart 900, an exemplary method for a wireless communication device (referred to as a network device with respect to FIG. 9) to manage a connection to a network (e.g., an IAB network or topology) of a wireless communication system via a mobile IAB node based on the mobility capabilities and status of the mobile IAB node, in accordance with some embodiments of the present invention. The method as illustrated in and described with respect to FIG. 9 may be performed by software and / or hardware elements.

[0201] The process begins at step 901, in which a new network device similar to network device 703 (e.g., IAB node 460 or UE 390 in FIG. 4) receives some mobility information from a nearby mobile IAB node, such as mobile IAB node 701 (e.g., mobile IAB node 470 in FIG. 4), also referred to as connecting IAB node 701.

[0202] According to one example, new network device 703 is an IAB node similar to IAB node 121 or 123 or IAB node 460.

[0203] According to another example, the new network device 703 is a UE similar to UE 135 or 136 or UE 390.

[0204] In an exemplary embodiment, the mobility information relates to all or part of the IAB node mobility information carried in a MOBILITY INFORMATION message 531, as described above with reference to Figure 5. The MOBILITY INFORMATION message 531 is an example of a mobility information message as described above with reference to Figures 11-14. In step 902, based on the mobility information received in step 901, the new network device 703 determines whether to attempt to connect to the network via the mobile IAB 701 node by initiating an RRC connection establishment procedure 731, as described above with reference to Figure 7.

[0205] According to one example, a new network device 703 may not attempt to connect to the network through a connecting IAB node 701 if the mobile IAB node indication information (mobileiab-NodeIndication) in the MOBILITY INFORMATION message 531 indicates that the IAB node 701 is a mobile IAB node.

[0206] According to another example, even though the connecting IAB node 701 is a mobile IAB node, the new network device 703 may attempt to connect to the network through the connecting IAB node 701 as long as the mobile IAB node 701 is stationary or has been stationary for a period longer than a predetermined threshold (e.g., the threshold may be as low as tens of seconds) determined based on the mobility status indication information and / or guaranteed stationary time information in a MOBILITY INFORMATION message 531 previously received from the connecting IAB node 701.

[0207] According to another example, a new network device 703 may attempt to connect to the network through a connecting IAB node 701, even if the connecting IAB node 701 is a mobile IAB node, as long as the mobility of the mobile IAB node 701 is limited. In other words, as long as the connecting IAB node 701 is moving with limited mobility. The mobility of a mobile IAB node 701 may be considered limited if one or any combination of the limited mobility criteria / conditions described above (e.g., in the description of FIG. 11 and / or FIG. 13 and FIG. 14) is met.

[0208] For purposes of clarity, certain aspects of the invention are exemplified below.

[0209] During recent discussions in 3GPP (RAN3 #117e meeting), it was agreed that the IAB donor CU should be aware of the "mobile" capability of the IAB node. Meanwhile, RAN2 has initiated a discussion on whether the mobile IAB-MT should send mobile IAB indications (capabilities or mobility) to the IAB donor CU.

[0210] Therefore, some specific mobility signaling to the IAB donor CU may be considered at the mobile IAB node level to enable efficient network connectivity management at the IAB donor CU.

[0211] 3GPP proposes that mobile IAB nodes report mobility-related information to the network, allowing the CU to include such information in UE handover decisions, simplifying some RRC procedures, and allowing the network to create a mobile IAB mobility history and reject connection requests for IAB nodes with the mobile IAB node as a parent node. Having knowledge of the mobile characteristics of an IAB node may also allow an IAB donor CU to decide on a full transition instead of a partial transition in the context of topology adaptation.

[0212] Mobility-related information that should be shared with IAB Donor CUs: - speed (minimum, average or maximum), - Mobility area (mobility area type, distance, etc.), - Movement trajectory (including a series of moving and stationary periods) Thus, in addition to informing the IAB donor CU about its mobility capabilities, a mobile IAB node may share certain mobility profiles with the IAB donor CU. Such mobility profiles may include information related to IAB node mobility characteristics, such as speed, mobility range, or movement trajectory.

[0213] The RRC setup procedure already allows the IAB-MT to indicate to its IAB donor CU that a connection has been established by the IAB node. Similarly, mobile capability signaling may be performed as part of the mobile IAB node RRC setup procedure, after which the mobile capability signaling is performed by the IAB-MT. In other words, the IAB node indication has already been sent by the IAB-MT to the IAB donor CU using RRC (iab-NodeIndication information in the RRCSetupComplete message).

[0214] Therefore, the IAB-MT should use RRC to send the mobile IAB node indication to the IAB donor CU along with the existing iab-NodeIndication and some mobility capability information.

[0215] Because some of the mobility parameters (e.g., speed) of an IAB node are likely to evolve, it may be beneficial for the IAB donor CU to be informed of such evolutions. Therefore, signaling of some mobility capabilities may be issued by the mobile IAB node upon detection of a change in IAB node mobility status or periodically.

[0216] Thus, mobile capability signaling may be performed as part of the mobile IAB node setup procedure, yet some mobility signaling may also be performed periodically or upon detection of a change in IAB node mobility status.

[0217] Because Release 18 introduces the concept of mobile IAB cells, it may be beneficial for the UE to have some knowledge of the fixed or mobile characteristics of its surrounding cells if the UE wishes to connect to one of them. This does not apply to legacy UEs (i.e., UEs that do not support the Rel. 18 standard). For example, a UE may have some preference for connecting to a fixed cell rather than a mobile cell when connecting to a new cell. Knowledge of the characteristics of mobile IAB cells may make it possible to mitigate the need for cell reselection or measurement reporting for handover. In other words, a UE can benefit from knowledge of the mobile characteristics of IAB nodes in its vicinity (so that the UE can decide whether to connect to a mobile cell or try to find some other fixed cell).

[0218] Therefore, a mobile IAB node can use SIB signaling to broadcast some mobile capability signaling towards its nearby UEs, which may include a mobility profile similar to that shared with the IAB donor CU and thus may include some information such as speed, mobility range, or movement trajectory.

[0219] Since some UEs may prefer to connect to a fixed cell (e.g., to avoid the need for any handover if the UE is stationary while the mobile IAB node is away), a mobile IAB node that is not currently moving (e.g., a parked taxi, a bus, or a subway train waiting at a station) may advertise its stationary state to nearby UEs, along with the duration for which it will remain stationary.

[0220] Therefore, a mobile IAB node can use SIB signaling to broadcast some mobile capability signaling to its nearby UEs, which may include a mobility profile similar to the one shared with the IAB donor CU.

[0221] Additionally, if a mobile IAB node is stationary, it may inform UEs in its vicinity of its stationary state as well as the duration for which it will remain stationary.

[0222] Considering the scope of the Release 18 Mobile IAB Framework, a Mobile IAB node must not have descendant IAB nodes, i.e., it serves only UEs. In this regard, 3GPP has agreed that not broadcasting the "IAB-Support" indication is sufficient to prevent other IAB nodes from accessing the Mobile IAB (without further specification impact).

[0223] However, mobile IAB nodes may become stationary at some point and remain stationary for a period of time, the duration of which may even be predictable: for example, a bus may stop at a bus station for a duration of 30 seconds to 1 minute, and a train may remain idle for up to 5 minutes at an intermediate station, or 30 minutes to an hour or more at a terminal station.

[0224] A mobile IAB node may also have its movement limited to a very restricted geographic area, such as, for example, a promotional vehicle circling an Olympic stadium.

[0225] In summary, a mobile IAB node may become stationary at some point and remain stationary for a period of time, the duration of which may be predictable. A mobile IAB node may also have its movement restricted to a very restricted geographic area.

[0226] In both cases, the impact of the mobile characteristics of an IAB node on its potential connectivity with other surrounding IAB nodes is null or very limited. Therefore, a mobile IAB node that is stationary or has a very limited range of movement can be considered a fixed IAB node and, therefore, has transient descendant IAB nodes as long as they are stationary or within a limited geographic area.

[0227] Thus, a stationary mobile IAB node can be considered a fixed IAB node and, therefore, can have transient descendant IAB nodes as long as it remains stationary.

[0228] Similarly, a mobile IAB node whose movement is restricted to a small geographic area can be considered a fixed IAB node and therefore can have transient descendant IAB nodes as long as it remains stationary.

[0229] FIG. 10 illustrates a schematic diagram of an exemplary communications device or station, in accordance with one or more exemplary embodiments of the present disclosure.

[0230] The communication device 1000 may be a device such as a microcomputer, a workstation, or a light portable device. The communication device 1000 may have a communication bus 1013 connected thereto: - A central processing unit 1111, such as a microprocessor referred to as a CPU. The central processing unit 1111 may be a single processing unit or processor, or may comprise two or more processing units or processors that perform the processing necessary for the operation of the communications device 1100. The number of processors and the allocation of processing functions to the central processing unit 1111 are a matter of design choice for those skilled in the art. - a memory for storing data and a computer program containing instructions for operation of the communications device 1000. The computer program may include several different program elements (modules) or subroutines containing instructions for various operations to implement methods according to one or more embodiments of the present invention. and at least one communication interface 1002 for communicating with other devices or nodes in a wireless communication system, such as the wireless communication system of Figure 1 or 4. The at least one communication interface 1002 may be connected to a wireless communication network 1003, such as a wireless communication network for 5G NR (e.g., with Release 16 and / or a subsequent release), over which digital data packets or frames or control frames are transmitted. Frames are written to the communication interface for transmission from a FIFO transmit memory in RAM 1012, or read from the communication interface for reception and writing to a FIFO receive memory in RAM 1012 under the control of a software application executing in CPU 1011.

[0231] Each of the donor CU, donor DU, IAB node, and UE may comprise such a communications device 1100.

[0232] The memory may include: - a read-only memory 1007, denoted ROM, for storing a computer program for implementing the method according to one or more embodiments of the present invention; a random access memory 1012, denoted RAM, that stores the executable code of the methods according to one or more embodiments of the present invention, as well as registers adapted to record variables and parameters necessary for carrying out the methods according to one or more embodiments of the present invention;

[0233] Optionally (and according to the functionality of the communication device), the communication device 1000 may also include the following components: - a data storage means 1004, such as a hard disk, for storing a computer program for implementing the method according to one or more embodiments; a hard disk drive 1005 for a hard disk 1006, the hard disk drive being adapted to read data from or write data to the hard disk 1006; - A screen 1009 for displaying the decoded data and / or serving as a graphical interface with the user by means of a keyboard 1010 or any other input / output means.

[0234] In the exemplary configuration, a communication bus provides communication and interoperability between the various elements included in or connected to the communication device 1000. The representation of a bus is not limiting, and in particular, a central processing unit is operable to communicate instructions to any element of the communication device 1000 directly or by another element of the communication device 1000.

[0235] Disk 1006 may optionally be replaced by any information carrier, such as a compact disk (CD-ROM), a rewritable or non-rewritable compact disk, a ZIP disk, a USB key or a memory card, and generally by an information storage means readable by a microcomputer or microprocessor, possibly removable, and adapted to store one or more programs whose execution can implement the method according to the present embodiment.

[0236] The executable code may optionally be stored either in a read-only memory 1007, on the hard disk 1004 or on a removable digital medium as previously mentioned, such as for example the disk 1006. According to an optional variant, the executable code of the program may be received by the communication network 1003, via the interface 1002, to be stored on one of the storage means of the communication device 1000, such as the hard disk 1004, before being executed.

[0237] The central processing unit 1011 may be adapted to control and direct the execution of instructions of a program or part of the software code according to an embodiment of the present invention, the instructions of which are stored in one of the aforementioned storage means. On power-up, a program stored in a non-volatile memory, for example the hard disk 1004 or the read-only memory 1007, is transferred to the random access memory 1012, which memory contains the executable code of the program as well as registers for storing variables and parameters necessary to implement the present invention.

[0238] In an exemplary embodiment, the communications device (apparatus) is a programmable device / apparatus that uses software to implement the present invention. The instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable logic arrays (FPGAs), or other equivalent integrated or dedicated logic circuitry. Thus, the term "central processing unit" as used herein may refer to any of the foregoing structures, or any other structure suitable for implementing the techniques described herein. However, the present invention may alternatively be implemented in hardware (e.g., in the form of an application-specific integrated circuit or ASIC or other logic element).

[0239] Although the present invention has been described above using exemplary embodiments, the present invention is not limited to these 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 the specification (including any accompanying claims, abstract, and drawings) and / or all steps of any method or process so disclosed may be combined in any combination, except combinations in which at least some of such features and / or steps are mutually exclusive. Each feature disclosed in the specification (including any accompanying claims, abstract, and drawings) may be replaced by an alternative feature serving the same, equivalent, or similar purpose, unless expressly stated otherwise. Thus, unless otherwise specified, each disclosed feature is merely an example of a generic series of equivalent or similar functions.

[0240] In the claims, the word "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 used to advantage.

[0241] In the foregoing embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over a computer-readable medium as one or more instructions or code and executed by a hardware-based processing unit.

[0242] Computer-readable media may include computer-readable storage media, which correspond to tangible media such as data storage media, or communication media, including any medium that facilitates transfer of a computer program from one place to another, for example, according to a communications protocol. Thus, computer-readable media may generally correspond to (1) tangible computer-readable storage media that is non-transitory, or (2) a communication medium such as a signal or carrier wave. Data storage media may be any available medium that can be accessed by one or more computers or one or more processors to retrieve instructions, code, and / or data structures for implementing the techniques described in this disclosure. A computer program product may include a computer-readable medium.

[0243] By way of example, and not limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included within the definition of medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transitory media, but instead cover non-transitory tangible storage media. As used herein, disk and disc include compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), floppy disks, and Blu-ray discs, where disks typically reproduce data magnetically and disks reproduce data optically with a laser. Combinations of the above should also be included within the scope of computer-readable media.

Claims

1. A method in an integrated access and backhaul (IAB) node of a wireless communication system, The aforementioned IAB node is controlled by an IAB donor node. The aforementioned method, As part of the RRC connection establishment procedure, it includes sending an RRCSetupComplete message to the IAB donor node, A method wherein the RRCSetupComplete message includes information to indicate whether the IAB node is a mobile IAB, and information to indicate that if the IAB node is a mobile IAB node, there are steps that the IAB node may follow.

2. The method according to Claim 1, The RRCSetupComplete message includes mobile IAB node instruction information to indicate that the connection established by the RRC connection establishment procedure is established by a mobile IAB node. method.

3. The method according to Claim 2, The RRCSetupComplete message further states: Information indicating the mobility status of the IAB node when the IAB node is a mobile IAB node, and A method comprising, if the IAB node is a mobile IAB node, at least one of the following pieces of information indicating a mobility area or mobility range to which the IAB node has previously moved or may move.

4. The method according to Claim 1, further, As part of the RRC connection establishment procedure, a request to establish a connection is sent to the IAB donor node, After sending the aforementioned request, if the request is accepted, the RRCSetup message is received from the IAB donor node, Methods that include...

5. The method according to Claim 1, further, As part of the RRC connection establishment procedure, a request to establish a connection is sent to the IAB donor node, If the request is rejected after the aforementioned request has been sent, an RRCReject message will be received from the IAB donor node. Methods that include...

6. The method according to claim 5, A method wherein, when the connection is refused, the RRCReject message includes information indicating that the connection was refused.

7. A computer program that, when executed by a computer, includes instructions causing the computer to perform the method described in Claim 1.

8. A computer-readable medium storing the computer program described in Claim 7.

9. A device for an integrated access and backhaul (IAB) node, A processing apparatus comprising one or more apparatuses configured to perform the method described in claim 1, Device.

Images