Network management

Abstract

Aspects of the invention relate to an attach procedure in an IAB network. In one aspect, to assign IP addresses to a collocated-DU of a new IAB node to be attached to an IAB network, an lABOtherlnformation message is sent by the new IAB node (e.g. IAB node#2) to request IP addresses from a Donor-CU for the collocated-DU. In another aspect, to establish Fl communication between the new IAB node and the Donor-CU, a novel BAP control PDU is used to provide an explicit BAP source advertisement from an existing IAB node (e.g. IAB node#l) to the IAB Donor-DU so as to update mapping at the Donor-DU indicating that the existing IAB node is a gateway for a new IAB node.

Description

Network ManagementTechnical Field

[0001] The present invention relates to network management, in particular in the context of an attach procedure for an IAB (Integrated Access and Backhaul) node in a 5G IAB network.Background Art

[0002] Release 16 of the 3GPP 5G NR (New Radio) standards (e.g. ETSI TS 138 331 V16.1.0 Release 16 and ETSI TS 138 401 V16.3.0 Release 16) introduced a specification for IAB (Integrated Access and Backhaul), which enables multi-hop backhauling via IAB Donors and IAB Nodes. IAB uses a decomposed RAN (Radio Access Node) model in which IAB Donors are decoupled into a distributed unit (DU) and a central unit (CU), and IAB Nodes are decoupled into an IAB Mobile Termination (IAB-MT) and a distributed unit (DU). The CU is responsible for IAB network topology and management, while the DU provides radio processing and control functions.

[0003] A Backhaul Adaptation Protocol (BAP) layer enables hop-by-hop routing between IAB nodes. This requires a mapping to be defined between a BAP routing ID and corresponding IP addresses.

[0004] The IAB network may have complex and / or rapidly changing topologies. For example, there may be multiple levels of cascaded IAB Donor-DUs in a tree topology in which IAB Donor-DUs are leaves of another IAB Donor-DU tree. To create such a multi-level tree, an IAB Donor-DU leaf may be collocated to an IAB-MT node. The implementation of a backhaul IP layer transport connection to support such network topologies is not specified by the 5G NR standards.Statements of the Invention

[0005] Aspects of the invention are defined in the accompanying claims.

[0006] One aspect of the invention relates to assigning IP addresses to a collocated-DU of a new IAB node to be attached to an IAB network. An lABOtherlnformation message is sent by the new IAB node (e.g. IAB node#2) to request IP addresses from Donor-CU for the collocated DU.

[0007] Another aspect of the invention relates to establishing Fl communication between the new IAB node and the Donor-CU. The Donor-DU needs to know which existing IAB node is a gateway for the new IAB node. A novel BAP control PDU is used to provide an explicit BAP source advertisement from the gateway IAB node to the IAB Donor-DU so as to update mapping at the Donor-DU indicating that the existing IAB node is a gateway for a new IAB node.

[0008] Each of the aspects of the invention may be used separately, or together.

[0009] Aspects of the invention include an IAB node, a Donor-DU and / or a parent DU arranged to perform their respective functions as required by aspects of the invention.

[0010] Aspects of the invention include a computer-readable storage medium comprising instructions which, when executed by a computer, cause the computer to carry out one or more functions according to aspects of the invention.Brief Description of the Drawings

[0011] Specific embodiments of the present invention will now be described with reference to the accompanying drawings listed below.Fig. 1 is a diagram illustrating the use of IP BH (backhaul) to attach a Donor-DU over an IAB network.Fig. 2 is a diagram of a protocol for allocating IP addresses to a collocated Donor-DU in an embodiment.Figs. 3a and 3b are diagrams of an IP discovery protocol using the novel BAP control PDU in an embodiment.Fig. 4 shows an example of a BAP control PDU format in one option in the embodiment.Fig. 5 shows an example of a BAP control PDU format in another option in the embodiment.Fig. 6 shows an example of a BAP control PDU format in yet another option in the embodiment.Fig. 7 is a diagram of a computer system on which functionalities of embodiments may be performed.Detailed Description

[0012] In the following description, terms and abbreviations are as defined in the relevant 3GPP standards unless otherwise stated. Where reference is made to a particular version of a standards it will be understood that the embodiments are applicable to other versions of the standard which include the relevant functionality.

[0013] Figure 1 illustrates an IP BH (backhaul) function based on 3GPP standard TS 38.401, with modifications as described below. This example shows a 5G IAB (Integrated access and Backhaul) network architecture, in which a 5G Core Network (5CG) is connected via an NG (Next Generation) link to a Donor-CU (Donor - Centralized Unit) that is responsible for IAB network topology and route management. The Donor-CU is connected to a first Donor-DU (Donor - Distributed Unit) via awireline connection. Donor-DU#l is connected to IAB node#l over an NR-Uu radio interface. IAB node#l is connected to IAB node#2 via BH-Uu radio interface.

[0014] Each IAB node includes an IAB-DU that connects to downstream UE (User Equipment) or IAB-MT (IAB Mobile Terminal). All DUs (Donor-DU and IAB-DU) connect to the IAB Donor-CU.

[0015] Both IAB Donors and IAB Nodes may serve one or more mobile UEs. An IAB-MT (IAB Mobile Terminal) function of an IAB node acts as UE (User Equipment) to the IAB Donor, for example for cell search, RACH and RRC signalling for resource management and authentication.

[0016] An IAB-MT uses RLC channels (i.e. BH RLC paths) to connect to a parent DU i.e. a primary network element responsible for managing and providing connectivity to multiple child IAB nodes by establishing RLC channels with the lAB-MTs of these IAB nodes.

[0017] An IAB-DU uses Fl to connect to the Donor-CU; for connection between the Donor-CU and the Donor-DU this is referred to as intra-Fl.

[0018] In this example, as a modification to the standard, IAB node#2 is connected to a collocated Donor-DU#2 via a wireline interface. An IAB IP BH channel is provided between Donor-DU#l and IAB-Node#2 to carry Intra-Donor Fl traffic between Donor-DU#2 and Donor-CU.

[0019] 3GPP standard TS 38.401 section 8.12.1 describes an attach procedure for an IAB node (e.g. IAB node#2), comprising:Phase 1: IAB-MT set-up, in which an IAB node mobile terminal (MT) of IAB node#2 connects to the network as a normal UE;Phase 2-1: BH RLC channel establishment, in which the backhaul Radio Link Control (RLC) channel is established for carrying Control Plane (CP) traffic to and from the IAB node, and the BAP address and default BAP upstream routing ID for the IAB node are configured;Phase 2-2: routing update, in which the BAP sublayer is updated to allow traffic to be routed via intermediate nodes to IAB node#2. This involves defining L2 (Layer 2) mapping rules associating the BAP ID and IP routing headers for IAB node#2; andPhase 3: IAB DU setup, in which the DU for IAB node#2 is configured to handle access and backhaul traffic.

[0020] In a conventional IP BH protocol (e.g. according to the above standards) for attaching a Donor-DU over an IAB network, the IP layer of the IAB Backhaul radio transport network layer (underlay) is managed by the Donor-CU. The IP layer (underlay) is always associated to the last IAB DU of the backhaul path. The IP overlay is associated to the IAB MT if MT's PDU sessions are used.QoS and BH RLC mapping to IP Backhaul traffic (including IAB node QAM) is left to implementation.Conventionally, the IP BH is considered as the IP layer between the IAB MT and the Donor-DU.

[0021] Fl-AP is used in downstream direction to update routing, i.e. BAP sublayer and IP addresses: mapping at Donor-DU and BAP routing IDs along the path. On the other hand, IP address(es) are allocated to the new node by the Donor-CU via RRC.

[0022] IP BH with IAB may be used for 0AM in-band connectivity and / or coverage extension via a Donor-DU wired to the IAB topology, for example for IAB units that cannot be disaggregated into distinct RU / DU components.

[0023] A mobile IAB network may be required to have an IP learning protocol. Problems to be addressed by this protocol may include non-deterministic mobility models for high-velocity nodes and / or system with limited capabilities such as range, number of simultaneous links per node, and / or coverage coupled with mobility. Mobility models inducing many topology changes may need to rely on closed loop procedures, for example for managing protocol capabilities and / or real-time control.

[0024] To enable attachment of a new IAB node (e.g. IAB node#2) to a Donor-DU collocated to an existing IAB node (e.g. IAB-node#l) , the collocated Donor-DU must be set up and integrated with the IAB network, i.e. the lAB-Donor-CU, including assigning IP addresses to the collocated Donor- DU, and modifying the routing policies along the wireless BH path, i.e. at the level of the intermediate IAB nodes.

[0025] In at least some embodiments, an lABOtherlnformation message is sent by the new IAB node (e.g. IAB node#2 in Fig.l) to request IP addresses from the Donor-CU for the collocated DU (e.g. Donor-DU#2 in Fig.l) as well as for one or more collocated Donor-DUs.

[0026] Fig. 2 shows an example of the above procedure, which follows IAB-MT integration (Step Sl.l). At step SI.2, the IAB-MT of IAB node#2 sends the lABOtherlnformation message containing the request for IP addresses to the Parent DU (IAB-node#l), which forwards the message to the Donor-CU through the IAB Donor-DU at step SI.3. At step S1.4, the Donor-CU allocates a set of IP addresses to the collocated Donor-DU of IAB node#2. Each set of IP addresses comprises IP Fl-U, IP Fl-C and optionally IP non-Fl, as defined in the 3GPP 5G NR standards. There may be a plurality of collocated Donor-DUs of IAB node#2 for which IP addresses are requested in the lABOtherlnformation message, in which case a respective set of IP addresses is allocated for each collocated Donor-DU.

[0027] At step SI.5, the Donor-CU sends the allocated IP addresses in an RRC reconfiguration message to the Parent DU (IAB-node#l), which forwards the RRC reconfiguration message to theIAB-MT of IAB Node#2 at step SI.6. At Step 1.7, the IAB-MT of IAB Node#2 advertises the set of IP addresses to the collocated IAB-DU of IAB-node#2 as defined in the standard.

[0028] At step SI.8, the Donor-CU sends a BAP mapping update to the Donor-DU indicating the current IP to L2 mapping for the IP addresses allocated by the Donor-CU. At step SI.9, the Donor-CU sends a BAP mapping update to the Parent DU (IAB-node#l), indicating the BAP and RLC mapping.

[0029] When the collocated IAB Donor-DU(s) are powered on and setup, IABnode#l discovers the corresponding collocated Donor-DU(s) and allocates the IP addresses from the pool of IP address dedicated to the collocated Donor-DUs.

[0030] Phase 2-2 of IAB node integration includes IP to L2 mapping of all IP addresses allocated to the IAB-MT, including IP addresses for the collocated IAB DU and for the collocated IAB Donor-DU. In this way the IAB Donor-DU anchored to the IAB Donor-CU will act as the termination of a BH tunnel with associated BAP / IP rules for all these IP addresses.

[0031] Alternatively or additionally, conventional OAM / manual configuration as defined in the 3GPP NR standards may be used to allocate the IP addresses of the collocated Donor-DU(s) of IAB node#l.

[0032] Some embodiments may use a dedicated IP BH path between the Donor-DU collocated to the IAB node and the Donor-DU physically anchored to the Donor CU. Routing policies are established between the anchor Donor-DU (e.g. Donor DU#1) and the Donor CU to route the traffic originating from and terminating at the Donor DU#2, transiting via the backhaul path between the anchor Donor DU and the collocated IAB node. This is permitted via the IP to L2 mapping configuration with the IP addresses allocated to the collocated Donor-DU.

[0033] Problems may arise when a new IAB node (e.g. IAB node#2) is attached to the collocated Donor-DU of IAB node#l (Donor DU#1), particularly in Phase 2-2 (routing update) and Phase 3 (IAB- DU setup) . Fl communication needs to be established between the new IAB node's DU and the IAB Donor-CU CP. In one scenario, the Fl request originating from the IAB node's DU is backhauled via the IP BH path and routed to the Donor-CU CP. In this scenario, the IAB Donor-DU anchored to the Donor CU needs to know which IAB node of the tree topology is the GW (Gateway) for a newly discovered IP address.

[0034] In an embodiment, a novel BAP Control PDU is used to provide an explicit BAP source advertisement, for example from IAB node#l to the IAB Donor-DU so as to update mapping at the Donor-DU indicating that IAB node#l is a gateway for a new IAB node (e.g. IAB node#2).

[0035] Figs. 3a and 3b show an example IP discovery protocol using the novel BAP control PDU which is exchanged between the two end-points of the tunnel e.g. IAB node#l collocated to the IABDonor-DU and Donor-DU terminating the tunnel on the Donor-CU side. This protocol may be used for each new IAB node attaching to the network via the collocated Donor-DU.

[0036] The BAP Control PDU header includes: the BAP ID of the source of the IP BH, i.e. the end point of the IP BH tunnel, IAB node#l the destination address the IP address of IAB node#2

[0037] In the protocol shown in Figures 3a and 3b, in step S2.1 at IAB node#2 the IAB DU#2 is allocated IP addresses by the CU via IAB MT#2, for example as described above.

[0038] In step S2.2 the Fl request is sent to the collocated Donor-DU to IAB node#l, which request is forwarded to IAB node 1 over the wired interface at step S2.3. In the Fl request, the SRC (source) field is set as the Fl-C IP address of IAB node#2 and the DST (destination) field is set as the IP address of the CU.

[0039] At step S2.4, the IAB-node#l discovers a new IP address, i.e. the Fl-C IP address of IAB- node#2. Upon learning this new IP address sent by the collocated Donor-DU, IAB-node#l builds the BAP control PDU to advertise itself to the Donor-CU as the BAP path GW of the IAB tree for this newly attached lAB-node, i.e. IAB-node#2.

[0040] At step S2.5, IAB node#l sends the novel BAP control PDU to the Donor-DU with the BAP ID of IAB node#l, and the IP address or addresses of IAB node#2.

[0041] At step S2.6, the Donor-DU updates a mapping table so as to identify IAB node#l as the GW (gateway) for IAB node#2. The routing ID is used to identify source BAP as the Gateway.

[0042] At step S2.7, IAB node#l transmits the Fl request (received as step S2.3) with the DST field set as the IP address of Donor-DU. Alternatively, the Fl request may be sent to the Donor-DU before the BAP control PDU is sent at step S2.5 and stored at Donor-DU until the BAP control PDU is sent and processed by the Donor-DU.

[0043] At step S2.8, the Donor-DU sends the Fl request to the Donor-CU with the SRC field set as the IP address of IAB node#2 and the DST field as the IP address of the Donor-CU. Alternatively, the Fl request may be sent by the Donor-DU to the Donor-CU at an earlier stage if received by the Donor-DU at an earlier stage, as in the alternative to step S2.7 as described above. Donor-CU would in this specific case need to wait for the Donor-DU to process the BAP control PDU to send the ARP response.

[0044] At step S2.9, Donor-CU send an ARP request to the Donor-DU, which responds with an ARP proxy response.

[0045] At step S2.10, Donor-CU sends IP to L2 mapping (BAP configuration) information to the collocated Donor-DU to IAB node 1.

[0046] At step S2.ll, the endpoints of the IP BH path / tunnel are configured. Traffic can be exchanged between IAB node#2 and Donor-CU.

[0047] At step S2.12, Donor-CU sends an Fl setup response to Donor-DU, with SRC set as the IP address of CU and DST set at the IP address of IAB node#2.

[0048] At step S2.13, Donor-DU applies IP to L2 mapping policy with DST BAP matching the IP address of IAB node#l.

[0049] At steps S2.14, Donor-DU forwards the Fl response over IAB BH to IAB node#l, which transmits the Fl response to the collocated Donor-DU at step S.15. At steps S2.16 and S2.17, the collocated Donor-DU to IAB node#l uses IP to L2 mapping policy to forward the Fl setup response to IAB node#2 using BAP messaging.

[0050] The BAP Control PDU sent at step S2.5 may include a novel header format as described below.

[0051] The BAP routing ID is defined in 3GPP standard TS 38.340 as comprising BAP Destination Address (10 bits) and BAP Path ID (10 bits). Since both Source and Destination BAP addresses are advertised by the novel BAP control PDU, one of the following options may be used for the BAP routing ID.

[0052] Option A: Create a new routing ID to allow to keep the 10 bits BAP Path ID untouched and thus permit to keep the scale in terms of numbers of BAP paths as defined by the standard.

[0053] Option B.l: Create a new routing ID that leverages the already existing BAP routing ID defined for the BAP control PDU in the standard. This option reuses the routing ID and creates 3 fields out of the 2 fields already defined, i.e. BAP DST, BAP SRC and BAP path ID instead of just BAP DST and BAP Path ID. This solution repurposes the length of the different fields.

[0054] Option B.2: Create a new routing ID while leveraging the already existing BAP routing ID defined for the BAP control PDU in the standard. This option differs from option B.l in that no changes are induced in the protocol format; a subset of all of the reserved bits can be used to serve as the BAP path ID.

[0055] Fig. 4 shows an example of the BAP control PDU format in Option A. This option defines a new format of the BAP control PDU including a new BAP routing ID format, including: a 10 bit source address field and keeping the 10 bits BAP Path ID field, and IP address fields to encapsulate and advertise the IP address newly discovered by the collocated IAB node, end point of the BHtunnel. This solution allows to keep the scale as intended by the standard: 1024 DUs per CU and1024 paths to an IAB MT. However, this solution has an impact on overhead because additional bits are required for the BAP path ID.

[0056] Fig. 5 shows an example of the BAP control PDU format in Option B.l. This option defines a new format of the BAP control PDU including a new BAP routing ID format reusing the 20 bits allocated initially to the BAP DST address and the BAP path ID. In one example, 8 bits are used for the BAP destination address (2 bits are unused), 8 bits are used for the BAP source address and 2 bits are used for the BAP path ID. This option changes the scaling performance of the standard, but is still relevant to most use-cases: 256 DUs per CU and 4 paths to an IAB MT. This option has no impact on overhead.

[0057] Fig. 6 shows an example of the BAP control PDU format in Option B.2. This option defines a new format of the BAP control PDU including a new BAP routing ID format reusing the 20 bits allocated initially to the BAP DST address and the BAP path ID as well as 4 reserved bits R. In one example, the BAP destination address is used as defined in the standard, the BAP path ID is repurposed to be used as a BAP source address, and at least some of the 4 reserved bits R are used as a BAP path ID. This option changes the scaling performance of the standard, but is still relevant to most use cases: 1024 DUs per CU and up to 16 paths to an IAB MT. This option has no impact on overhead.

[0058] As an alternative to the above embodiment using the novel BAP control PDU, 0AM configuration may be used to configure the IP addresses and BAP mapping of the IAB node collocated to the Donor-DU, the collocated Donor-DU, the Donor-DU anchored to the Donor-CU and the IAB nodes on the backhaul path between the Donor-DU and the lAB-node collocated to the Donor-DU.

[0059] A system with an OOB (Out of Band) network and / or with deterministic mobility models of the nodes may rely on 0AM configuration of the network prior to attachment of the new IAB node.Computer System

[0060] The methods of the embodiments described above, in particular the methods as performed by one or more functional entities IAB nodes and / or IAB Donor and their decoupled units, may be implemented by one or more computer systems. For example, each of the above functional entities e.g. IAB nodes and / or IAB Donor may be implemented by one or more computer systems. Figure 7 shows an example of such a computer system 1000. After reading this description, it will become apparent to a person skilled in the relevant art how to implement the invention using other computer systems and / or computer architectures.

[0061] Computer system 1000 includes one or more processors, such as processor 1004. Processor 1004 can be a special purpose or a general-purpose processor. Processor 1004 is connected to a communication infrastructure 1006 (for example, a bus or network). Computer system 1000 may include a user input interface 1003 connected to one or more input device(s) 1005 and an output interface 1007 connected to one or more output devices 1009. Input devices 1005 and output interface 1007 may include local or remote devices or interfaces for user interaction with e.g. manual configuration and / or monitoring of the computer system 1000.

[0062] Computer system 1000 also includes a main memory 1008, preferably random-access memory (RAM), and may also include a secondary memory 1010. Secondary memory 1010 may include, for example, a hard disk drive, a removable storage drive, flash memory, a memory stick, and / or any similar non-volatile storage mechanism. As will be appreciated by persons skilled in the relevant art(s), removable storage may include a non-transitory computer usable storage medium having stored therein computer software and / or data.

[0063] In alternative implementations, secondary memory 1010 may include other similar means for allowing computer programs or other instructions to be loaded into computer system 1000. Such means may include, for example, a removable storage unit and an interface which allow software and data to be transferred from the removable storage unit to computer system 1000.

[0064] Computer system 1000 may also include a communications interface 1024 implemented for example at the operating system level to allow data to be transferred between computer system 1000 and external devices, for example as signals over a communication channel. Communications interface 1024 may include a modem, a network interface (such as an Ethernet card), a communications port, a PCMCIA slot and card, or the like.

[0065] Various embodiments of the present invention may be implemented by software and / or firmware (also called computer programs, instructions or computer control logic) to program programmable hardware, or hardware including special-purpose hardwired circuits such as application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field- programmable gate arrays (FPGAs), etc. of the computer system 1000, or a combination thereof.

[0066] Computer programs for use in implementing the techniques introduced here may be stored on a machine-readable storage medium and may be executed by one or more general-purpose or special-purpose programmable microprocessors. The terms "computer program medium," "non- transitory computer readable medium" and "computer usable medium" introduced herein can refer to media such as removable storage unit, removable storage unit, and a hard disk installed in hard disk drive. Computer program medium, computer readable storage medium, and computer usable medium can also refer to memories, such as main memory 1008 and secondary memory 1010,which can be memory semiconductors (e.g. DRAMs, etc.). These computer program products are means for providing software to computer system 1000.

[0067] Computer programs are stored in main memory 1008 and / or secondary memory 1010. Computer programs may also be received via communications interface 1024. Such computer programs, when executed, enable computer system 1000 to implement the present invention as described herein. In particular, the computer programs, when executed, enable processor 1004 to implement the processes of embodiments of the present invention as described above. Accordingly, such computer programs represent controllers of the computer system 1000. Where the invention is implemented using software, the software may be stored in a computer program product and loaded into computer system 1000 using removable storage or communications interface 1024 .Alternative Embodiments

[0068] Alternative embodiments, which may become apparent on reading the above description, may nevertheless fall within the scope of the invention as defined by the accompanying claims.

Claims

Claims1. In an IAB node attach procedure in an IAB network, a method comprising, at an existing IAB node (IAB node#l) in the IAB network: receiving (S2.2, S2.3), from a new IAB node (IAB node#2), an Fl request; and sending (S2.5), to a Donor-DU, a BAP control PDU having a BAP ID corresponding to the existing IAB node (IAB node#l), and indicating one or more IP address of the new IAB node (IAB node#2), such that the Donor-DU records the existing IAB node (IABnode#l) as a gateway for the new IAB node (IAB node#2).

2. The method of claim 1, including sending (S2.7) the Fl request to the Donor-DU.

3. In an IAB node attach procedure in an IAB network, a method comprising, at a Donor-DU: receiving (S2.5), from an existing IAB node (IAB node#l) in the IAB network, a BAP control PDU having a BAP ID corresponding to the existing IAB node (IAB node#l), and indicating one or more IP addresses of a new IAB node (IAB node#2); and recording (S2.6) the existing IAB node (IABnode#l) as a gateway for the new IAB node (IAB node#2).

4. The method of claim 3, further comprising receiving (S2.7) at the Donor-DU an Fl request forwarded from the new IAB node (IAB node#2) by the existing IAB node (IAB node #1), and forwarding (S2.8) the Fl request to a Donor-CU.

5. The method of claim 4, further comprising receiving (S2.12), from the Donor-CU, an Fl setup response addressed to the new IAB node (IAB node#2), and applying (S2.13) an IP to L2 mapping policy with DST BAP set to the IP address of the existing IAB node (IAB node#l).

6. The method of claim 5, including forwarding (S2.14) the Fl setup response to the existing IAB node (IAB node#l) for forwarding to the new IAB node (IAB node#2).

7. The method of any preceding claim, wherein the BAP control PDU includes a BAP source address, a BAP destination address and a BAP path ID.

8. The method of claim 7, wherein the BAP source address comprises a 10 bit field, the BAP path ID comprises a 10 bit field, and the BAP destination address is encapsulated in one or more additional IP address fields.

9. The method of claim 7, wherein the BAP source address and / or the BAP path ID comprises a respective field of less than 10 bits, such that a total number of bits allocated to the BAP source address, the BAP path ID and the BAP destination address is less than or equal to 20 bits.

10. The method of claim 7, wherein the BAP source address comprises a 10 bit field, the BAP destination address comprises a 10 bit field, and the BAP path ID is allocated to a plurality of reserve bits.

11. A method of allocating IP addresses to a collocated Donor-DU of an IAB node (IAB node#2) in an IAB network, comprising, at the IAB node (IAB node#2): sending (SI.2) an lABOtherlnformation message including a request for IP addresses to a Parent DU; receiving (SI.6) allocated IP addresses in an RRC reconfiguration message from the Parent DU; and sending (SI.7) the allocated IP addresses to the collocated Donor-DU.

12. A method of allocating IP addresses to a collocated Donor-DU of an IAB node (IAB node#2) in an IAB network, comprising, at a Parent DU: receiving (SI.2) an lABOtherlnformation message including a request for IP addresses from the IAB node (IAB node#2); forwarding (SI.3) the lABOtherlnformation message to a Donor-CU; receiving (SI.5) allocated IP addresses in an RRC reconfiguration message from the Donor-CU; and forwarding (SI.6) the RRC reconfiguration message to the IAB node.

13. An IAB node arranged to perform the method of any one of claims 1-2, any one of claims 7 - 10 when dependent on any one of claims 1-2, or claim 11.

14. A Donor-DU arranged to perform the method of any one of claims 3-6, or any one of claims 7 - 10 when dependent thereon.

15. A Parent DU arranged to perform the method of claim 12.

16. A computer-readable storage medium comprising instructions which, when executed by a computer, cause the computer to carry out the method of any one of claims 1 to 12.

Images