GB2605960A

GB2605960A - Routing data in an integrated access and backhaul network

Info

Publication number: GB2605960A
Application number: GB2105414.3A
Authority: GB
Inventors: Lagrange Pascal; Visa Pierre
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2021-04-15
Filing date: 2021-04-15
Publication date: 2022-10-26
Also published as: GB2606033A; GB202105414D0

Abstract

A method comprises receiving a data packet at an integrated access and backhaul (IAB) node, the packet including an IAB node destination address and a path identifier. Determining, based on the received packet, whether the routing path of the received packet includes at least one IAB node of a different IAB network. If so determined, using the path identifier of the packet to determine whether there is a next IAB node in the routing path for routing the data packet and, when a next IAB node is determined, routing the packet to the next IAB node. A method at a first IAB network’s donor central unit (CU) comprises determining one or more transit paths corresponding to routing paths for routing data packets over the first IAB network and a second IAB network. Providing, to at least one IAB node of each transit path of the one or more transit paths, routing configuration information relating to the determined one or more transit paths corresponding to routing paths for routing packets over at least one IAB node in the first IAB network and at least one IAB node in the second IAB network.

Description

ROUTING DATA IN AN INTEGRATED ACCESS AND BACKHAUL NETWORK

Field of the Invention

The present invention generally relates to routing data and managing routing of data in an integrated access and backhaul, I AB, network of a wireless communication system.

Background

Wireless communication systems are largely deployed to address a wide range of applications, from mobile broadband, massive machine type communications to Ultra Reliable Low Latency Communications (URLLC). Such systems allow a plurality of user equipment (UE) or mobile terminals to share the wireless medium to exchange several types of data content (e.g. video, voice, messaging...) over a radio access network (RAN) through one or more base stations. The base stations are conventionally wired-connected (e.g. through fiber) to a core network, forming an intermediate network, named backhaul (BH).

Examples of such wireless multiple-access communication systems include systems based on 3rd generation partnership project (3GPP -RTN1) standards, such as fourth-generation (4G) Long Term Evolution (LTE) or recent fifth-generation (5G) New Radio (NR) systems, or systems-based IEEE 802.11 standards, such as WiFi.

The demand for network densification (e.g. denser placement of base stations) increases due to the rising number of users and higher throughput requirement.

Facing the issues of high deployment costs and time of the wired backhaul networks with network densification, 3GPP has proposed, in recent release 16 for 5G NR, a wireless backhaul, also known as Integrated Access and Backhaul, IAB, where part of the wireless (i.e. radio) spectrum is used for the backhaul connection of base stations instead of fiber. The wireless backhaul communications or links (between base stations) may use the same radio resources as access communications or links (between a base station and UEs).

JAB turns out to be a competitive alternative to the fiber-based backhauling in dense areas or areas difficult to cover, as it allows scalable and rapid installations without the burden of cabling the base stations.

LAB is most likely to operate in the millimeter wave (mmWave) band to achieve the required Gbps (gigabits per second) data rate.

However, millimeter waves are known to be subject to strong attenuations of signal strength in some weather conditions (rain, fog), and to blockage in case of obstacles located in the path between the emitter and the receiver.

To cope with these potential radio link failures, a topological redundancy can be provided within the TAB framework, where multiple backhaul paths are set up between the TAB base station directly connected to the core network (also referred to as the "1AB-donor") and the JAB base station serving a UE (also referred to as the "access TAB-node" for the UE). Several intermediate LAB base stations (also referred to as IA B-nodes) may be involved in each of the several backhaul paths between the JAB-donor and the access JAB-node, thus forming alternative data paths within a multi-hop JAB network.

A path through a set of IAB-nodes is defined by default along which the data are preferably transmitted. Also, one or more back-up paths along different sets of JAB-nodes are defined that can be used in case a radio link failure (RLF) occurs on any link of the default path. A link is defined between two successive LAB-nodes in the backhaul network. A back-up path is also useful in case of congestion of a link due to an excessive demand of application traffic compared to the default link capacity. Traffic re-routing to a back-up path or load balancing between the default path and one or more back-up paths may be activated to mitigate the congestion.

In the TAB-network topology, the direction from the JAB-donor toward the access JAB-nodes (and thus the UEs) is referred to as downstream, hence defining a parent IAB-node and a child JAB-node for each link. The direction toward the JAB-donor is referred to as upstream. Each IAB-node coupled directly or indirectly to the IAB-donor comprises an IAB-MT (IAB- Mobile Termination) to communicate in the upstream direction and an IAB-DU (IAB-Distributed Unit) to communicate in the downstream direction.

Like a legacy 5G base station (gNB), the JAB-donor consists of a central unit (CU or gNB-CU functionality) and of one or more distributed unit(s) (DU or gNB-DU functionality). The JAB-donor-CU hosts higher layer protocols for controlling operation of one or more DUs and each of the one or more JAB-donor-DUs include lower layer protocols including the Physical layer and Radio Frequency part. The LAB-donor-CU and the one or more IAB-donorDUs may be located far from each other. Then a wired JP network (typically with fiber connections) exists to interconnect these different devices. The interest of having several DUs connected to a single CU is the centralization and the resource sharing of less time-critical operations in the CU (virtualization), while time-critical operations like scheduling, fast retransmission, segmentation, etc. ...are performed in the DUs. As a consequence, in the downstream direction, there may be several backhaul paths from the JAB-donor-CU to an JAB-node through different JAB-donor-DUs. Similarly in upstream direction, there may be several possible backhaul paths from the source JAB-node to reach the JAB-donor-CU through different IAB-donor-DUs.

To enable routing over multiple backhaul hops, a specific JAB protocol sublayer was introduced, the backhaul adaptation protocol (BAP) sublayer, which is specified in the 3GPP release-16 specifications TS 38.340 (version 16.3.0). There is one BAP entity in an I AB-MT, one BAP entity in an IAB-DU, and one BAP entity in an IAB-donor-DU. A unique BAP address is assigned to each JAB-node and to each JAB-donor-DU by the JAB-donor CU in charge of managing the IAB network. The BAP sublayer encapsulates IP SDUs (Service Data Units) into BAP PDUs (Protocol Data Units), where each BAP PDU consists of a BAP header and a payload section, which includes the JP SDUs, The BAP header includes a BAP Routing ID, which is the concatenation of the destination BAP address and the identifier of the backhaul path to follow (Path ID). The BAP routing ID is set by the BAP sublayer of the initiator JAB-donor-DU (in the downstream direction) or the initiator JAB-node (in the upstream direction). Then, BAP PDUs are routed according to the BAP Routing ID using a backhaul routing table configured by the JAB-donor-CU in each JAB-node and in each JAB-donor-DU. Upon reception of a BAP PDU in a BAP entity, the destination BAP address is compared to the local BAP address. If the local address matches the destination BAP address, the BAP header is removed and the payload is delivered to the upper layers.

For a BAP entity in an IAB-donor-DU, if the destination BAP address does not match the local BAP address, the BAP PDU is discarded. For a BAP entity in the JAB-MT or the JAB-DU of an JAB-node, if the destination BAP address does not match the local BAP address, the BAP PDU is delivered to the collocated BAP entity for routing and transmission to the next hop. The backhaul routing table provides the egress link corresponding to the next hop BAP address, using the BAP routing ID in the BAP PDU header as the entry of the table. In case the indicated egress link is not available, for instance due to radio link failure (RLF), an entry with the same destination BAP address is selected regardless of the Path ID. The BAP PDU is discarded if no entry in the routing table matches the BAP Routing ID or the destination BAP address of the BAP header.

Recently, 3GPP has been considering inter-donor redundancy, where an IAB-node, referred to as a Boundary JAB node, can access two different parent nodes connected to two different JAB-donor CUs. The Boundary JAB-node, even though belonging to a single JAB network, i.e. belonging to a single LAB-donor CU for configuration and management, is thus able to route BAP PDUs from a first IAB network managed by a first IAB-donor CU to a second JAB network managed by a second JAB-donor CU. The advantage of such inter-donor redundancy lies in the ability for the first JAB-donor-CU to perform offloading by routing some of its BAP PDUs through the second IAB network, thus mitigating congestion issues or overcoming radio link failure issues that may arise in the first JAB network.

However, since the assignment of BAP addresses, BAP path IDs and Backhaul Radio Link Control Channel Identifiers (BH RLC CH IDs) is performed independently in each JAB network, the same values may be assigned in each topology, e.g. an JAB-node belonging to the first IAB network may be assigned the same address as an IAB-node belonging to the second JAB network, which may lead to significant routing issues. For instance, if a Boundary JAB-node of a first TAB network has the same address as an JAB-node in the second TAB network, when the Boundary IAB-node receives a BAP PDU with a header that includes a destination BAP address that matches the address of the Boundary IAB-node (and hence the address of the JAB-node in the second JAB network), the Boundary node will not be able to decide whether the BAP PDU is for the Boundary JAB-node and so has to be forwarded to upper layers or is intended for the IAB-node in the second JAB network and so has to forwarded to the next hop.

Similarly, an JAB-node may re-route a BAP PDU to the wrong destination JAB-node. Therefore, some new mechanisms are required to overcome the aforementioned issue, while limiting the complexity of the processing at an JAB-node as well as the latency that would result from such processing.

Summary

In accordance with a first aspect of the present invention, there is provided a method for processing data packets at an integrated access and backhaul, IAB, node of an IAB network comprising a plurality of TAB nodes, the method comprising: receiving a data packet including a destination address of a destination JAB node for the data packet and a path identifier identifying a routing path for the data packet to the destination JAB node; determining, based on the received data packet, whether the routing path of the received data packet includes at least one JAB node of a different IAB network; in response to determining that the routing path of the received data packet includes at least one JAB node of a different JAB network, using the path identifier of the received data packet to determine whether there is a next JAB node in the routing path for routing the data packet, when a next IAB node is determined, routing the data packet to the next IAB node.

In an example, in response to determining that the routing path of the received data packet includes at least one JAB node of a different JAB network, the JAB node uses the path identifier of the received data packet, and does not use the destination address of the received data packet, to determine whether there is a next JAB node in the routing path or to determine the next JAB node.

In an example, the JAB node may only use the path identifier to determine the next JAB node.

In an example, the method may further comprise receiving configuration information including a routing configuration table, each entry of the routing configuration table having a destination address field for an address of an JAB node and a path identifier field for a path identifier of a routing path to the IAB node. In this case, determining whether there is a next I AB node for routing the data packet using the path identifier of the received data packet may comprise comparing the path identifier of the received data packet with the path identifier field of the routing configuration table and when the path identifier of the received data packet matches a path identifier in the path identifier field, determining there is a next JAB node.

When the path identifier of the received data packet does not match a path identifier in the path identifier field, determining there is not a next IAB node. In this case, the method may further comprise comparing the destination address of the received data packet with an address assigned to the IAB node, and when the destination address of the received data packet matches the address assigned to the IAB node, determining the IAB node is the destination IAB node.

In an example, the method may further comprise receiving configuration information including a routing configuration table, each entry of the routing configuration table having a destination address field for an address of an IAB node and a path identifier field for a path identifier of a routing path to the JAB node. In this case, determining whether there is a next JAB node for routing the data packet using the path identifier of the received data packet comprises comparing the path identifier of the received data packet with the path identifier field of the routing configuration table, and when the path identifier of the received data packet matches a path identifier in the path identifier field of an entry in the routing configuration table and when an address assigned to the JAB node does not match the address of the JAB node in the destination address field of the entry, determining there is a next I AB node. When the path identifier of the received data packet matches a path identifier in the path identifier field of an entry in the routing configuration table and when the destination address of the received data packet matches the address of the JAB node and the address in the destination address field of the entry, determining there is not a next JAB node and the JAB node is the destination JAB node.

The JAB node may be capable of routing data packets to one or more 1AB nodes in the JAB network of the JAB node and to one or more JAB nodes in at least one different JAB network.

The JAB node may be assigned a first unique address for use by the JAB network of the JAB node and a second unique address for use by the at least one different JAB network.

The method may further comprise sending a notification to a donor Central Unit, CU, of the JAB network, indicating the JAB node is capable of routing data packets to one or more IAB nodes in the at least one different JAB network.

In accordance with a second aspect, there is provided a method for managing processing of data packets in a first integrated access and backhaul, IAB, network as recited in any one of claims 20 to 28 of the accompanying claims.

In accordance with a third aspect, there is provided an Integrated access and backhaul, 1AB, node, as recited in claim 29.

In accordance with a fourth aspect, there is provided a donor Central Unit, CU, as recited in claim 30.

The present invention provides routing of data packets (such as backhaul adaptation protocol (BAP) protocol data units (PDUs)) over one or more integrated access backhaul (IA B) networks and thus, allows for the re-routing of data packets from a first IAB network to a second (e.g. a transit JAB network) JAB network.

By determining whether the routing path of data packet is a transit routing path or transit path through at least two IAB networks (for example, using the path identifier) and then after determining the routing path is a transit routing path through at least two JAB networks, using the path identifier (e.g. using the path identifier and not the destination address of the data packet routing ID) to route the data packet (e.g. to determine the next node in the transit routing path), alternate routing paths over a plurality of JAB networks can be used and issues with duplicate addresses, path identifiers, etc. due to the independent assignment in each of the JAB networks can be avoided. Also the complexity of the processing at an JAB-node is reduced compared to having to update the destination address and path identifier (e.g. BAP routing ID in the header) of the data packet as well as the latency that would result from such processing. As discussed above, local re-routing of packets on an alternative path which includes at least one JAB node in one different JAB network (e.g. a neighbouring or transit JAB network) reduces service interruption time caused by backhaul Radio Link Failure (BH RLF) and can also facilitate load balancing between several paths to limit the risk of link congestion.

The data packets may be Backhaul Adaptation Protocol (BAP) packets or BAP Packet Data Units (PDUs). For BAP packets, the routing configuration table is a BAP routing configuration table where the destination address field and the path identifier field are part of a BAP routing ID. In such a case, the BAP routing ID comprises the BAP destination address field for the BAP address of an JAB node and path identifier field for identifying the path or routing path to the IAB node. A BAP packet includes a BAP header which includes a BAP routing ID for routing the BAP packet. The BAP routing ID of the BAP header includes a destination address field for the BAP address of an JAB node which corresponds to the destination IAB node of the BAP packet and path identifier field for identifying the path or routing path to the destination IAB node. The destination IAB node may be a donor DU for routing in the upstream direction or an IAB node in the downstream direction or may be an intermediate JAB node.

Further features of the invention are characterised by the other independent and dependent claims.

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.

Furthermore, features implemented in hardware may be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly. For example, in accordance with another aspect of the invention, there is provided a computer readable storage medium storing at least one computer program comprising instructions that, when executed by a processing unit, causes the processing unit to perform the method according to any aspect or example described above.

It should also be appreciated that particular combinations of the various features described and defined in any aspects of the invention can be implemented and/or supplied and/or used independently.

Brief Description of the Drawings

Different aspects of the invention will now be described, by way of example only, and with reference to the following drawings in which: Figure 1 is a schematic diagram illustrating a wireless communication system including a wireless Integrated Access and Backhaul (IAB) network; Figures 2a and 2b are schematic diagrams illustrating stacks of some protocol layers involved in JAB operations, Figure 3 is a schematic diagram illustrating the format of a BAP Protocol Data Unit (PDU) or packet; Figure 4 is a schematic diagram illustrating the routing management in an IAB network; Figure 5 illustrates fields of routing tables in JAB-nodes according to 3GPP TS 38.300; Figure 6 is a schematic diagram illustrating an example topology of an JAB network arrangement in which the present invention may be implemented according to one or more exemplary embodiments; Figure 7 illustrates fields of an example of configuration table at an JAB-node according to embodiments of the invention; Figure 8 illustrates, using a flowchart, a first exemplary method for managing BAP PDU routing over a plurality of JAB networks according to embodiments of the invention; Figure 9 illustrates, using a flowchart, a second exemplary method for managing BAP 15 PDU routing over a plurality of IAB networks according to embodiments of the invention; Figure 10 is a schematic and simplified diagram illustrating an exemplary message flow for managing BAP PDU routing over a plurality of IAB networks according to embodiments of the invention; Figure 11 is a block schematic diagram of an example wireless communication device for implementing embodiments of the present invention; Figure 12 illustrates fields of an entry for a routing configuration table in JAB nodes according to embodiments of the invention.

Figure 13 illustrates, using a flowchart, an exemplary method, at an IAB node, for processing data packets according to embodiments of the invention; Figure 14 illustrates, using a flowchart, an exemplary method, at a donor CU, for managing processing of data packets in an I AB according to embodiments of the invention; Figure 15 is a schematic and simplified diagram illustrating an exemplary message flow for managing BAP PDU routing over a plurality of JAB networks according to embodiments of the invention; Figure 16 is a schematic diagram illustrating an example format of a BAP Protocol Data Unit (PDU) or data packet according to embodiments of the invention; Figure 17 is a schematic and simplified diagram illustrating routing of data packets over two JAB networks according to embodiments of the invention; and Figure 18 is a schematic and simplified diagram illustrating routing of data packets over two JAB networks according to embodiments of the invention.

Detailed Description of the Drawings

Figure 1 illustrates an exemplary wireless communication system 100, in particular a mobile radio communication system such as a fifth-generation (50) New Radio (NR) system including a wireless Integrated Access and Backhaul network. Although in the following description, embodiments and examples of embodiments of the present invention will be described with respect to a 50 NR system, it will be appreciated that it is not intended that the present invention is limited to 5G NR systems and may be used in any wireless communication systems having an integrated access and backhaul network which shares radio resources for wireless access links and wireless backhaul links.

The system 100 comprises a plurality of LTEs (User Equipment) 132, 133, 131 and 134, a remote core network 110, a main Base Station 120, and two Integrated Access and Backhaul (IAB) stations or IAB nodes 121 and 122 (also referred to in the following as JAB-nodes).

The main Base Station 120, also referred to as the IAB-donor 120, is connected to the core network 110 through a wired link 101, preferably an optical fiber or any other wired means. In embodiments and examples of embodiments of the invention, IAB-donor 120 is a 5G NR gNB with additional functionality to support IAB features, as defined in 3GPP TS

38.300 v16.2.0 specification document.

In order to extend the network coverage of JAB-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, have been installed by the operator. By acting as relaying nodes between the JAB-donor 120 and the UEs 132 and 133, IAB-nodes 121 and 122 allow overcoming the reachability issue resulting from presence of building 108, which is an obstacle to the propagation of radio waves and hence to the direct attachment and further communications between the UEs and the IAB-donor 120. This is particularly true when the communications between the JAB-donor 120 and UEs 132 and 133 are operated at millimeter wave frequencies, which are highly sensitive to shadowing phenomena.

The JAB-donor 120 also serves UE 134, which is directly connected to it.

The LAB-donor 120 and the IAB-stations 121 and 122 are thus forming a backhaul network or JAB network, which accommodates UEs 132, 133, 131 and 134.

The specification of the Integrated Access and Backhaul (JAB) is spread over several 3GPP standard documents, including: - IS 38.300 RAN architecture (V16.2.0), - IS 38.321 MAC protocol (V16.1.0), -IS 38.331 Radio Resource Control (RRC) protocol (V16.1.0), - IS 38.340 Backhaul Adaptation Protocol Layer (V16.1.0), - IS 38.401 RAN architecture (V16.2.0), - IS 38.473 Fl Application Protocol (V16.2.0).

As JAB-nodes 121 and 122 are respectively connected to UEs 131, 132 and 133, they are considered as Access JAB-nodes for their respectively connected UEs.

The 1AB-donor 120 is a logical node that provides the NR-based wireless backhaul and consists of a central unit (CU or gNB-CU functionality) and connected donor distributed unit(s) (DU or gNB-DU functionality). The JAB-donor-CU or donor CU (also referred to in the following as JAB-donor CU) hosts higher layer protocols, such as PDCP (Packet Data Convergence Protocol) and RRC (Radio Resource Control) protocols, for controlling operation of one or more DUs and each of the one or more JAB -donor-DUsor donor DUs (also referred to in the following as IAB-donor DU) includes lower layer protocols, such as the RLC, MAC and physical layer protocols. The IAB-donor CU or donor CU and JAB-donor DU or donor DU may be located far from the other or may be located in the same physical device. The gNB-DU functionality is defined in 3GPP TS 38.401. It aims at terminating the NR access interface to the UEs and next-hop JAB-nodes, and at terminating the Fl protocol to the JAB-donor gNB-CU functionality as shown in Figures 2a and 2b discussed below.

The JAB nodes, which may serve multiple radio sectors, are wireless backhauled to the IAB-donor 120, via one or multiple hops over intermediate IAB nodes. They form a directed acyclic graph (DAG) topology with the 1AB-donor at its root.

The JAB nodes consist of an JAB-DU and an JAB-MT (JAB-Mobile Termination). The gNB-DU functionality on an JAB-node is also referred to as JAB-DU and allows the downstream (toward the LTE) connection to the next-hop TAB. The JAB-MT functionality includes, e.g., physical layer, layer-2, RRC and Non Access Stratum (NAS) functionalities to connect to the gNB-DU of an upstream JAB-node (including the JAB-donor 120 in which case it connects to the JAB-donor gNB-CU, hence to the core network 110, for instance for initialization, registration and configuration).

In this DAG topology, the neighbour node on the IAB-DU's interface is referred to as child node and the neighbour node on the JAB-MT's interface is referred to as parent node. The direction toward the child node is further referred to as downstream while the direction toward the parent node is referred to as upstream.

The IAB-donor 120 performs centralized resource, topology and route management for the whole JAB topology. This includes configuring the JAB-nodes according to the network topology, e.g. in order to perform appropriate routing of data packets.

Figures 2a and 2b schematically illustrate stacks of some protocol layers involved in JAB operations.

Fl interface supports the exchange of signalling information between the endpoints, as well as the data transmission to the respective endpoints. From a logical standpoint, Fl interface is a point-to-point interface between the endpoints.

In 5G NR, Fl-C is the functional interface in the Control Plane (CP) between the IABdonor -CU and an JAB-node -DU (e.g. of IAB-node 2), and between the JAB-donor-CU and an IAB-donor DU. FI-U is the functional interface in the User Plane (UP) for the same units.

Fl-C and F t-U are shown by reference 212 in Figure 2a. In this example, Fl-U and Fl-C are carried over two backhaul hops (from 1AB-donor to IAB-nodel and then from IAB-nodel to IAB-node2).

In the User Plane, boxes 210 at the IAB-donor CU and the IAB-node DU refer to the GTP-U layer and boxes 211 refer to the UDP layer. GTP-U stands for GPRS Tunnelling Protocol User Plane. GTP-U Tunnels are used to carry encapsulated PDUs and signalling messages between a given pair of GTP-U Tunnel Endpoints (refer to 3GPP TS 29.281 for more details), here boxes 210 at the IAB-donor CU and the IAB-node DU. The well-known User Datagram Protocol (UDP) is a transport layer protocol providing a best effort datagram service and fit to use with an IP protocol.

In the Control Plane, boxes 210 indicate the FlAP (F1 Application Protocol) layer and boxes 211 indicate the SCTP (Stream Control Transmission Protocol) layer. The Fl Application Protocol (as defined in 3GPP TS38.473 and TS 38.401) provides signalling services between the JAB-donor CU and the IAB-node DU, or UE associated services. These services are for example initialization, configuration, and so on. The well-known SCTP layer provides reliable, in sequence transport of messages with congestion control.

Fl-U and Fl-C rely on an IP transport layer between the IAB-donor CU and the IABnode DU as defined in 3GPP TS 38.401.

The transport between the JAB-donor DU and the JAB-donor CU also uses an IP transport Layer over various media, like for example wires or optical fiber when the JAB-donor CU is remote from the JAB-donor DU, or locally in a virtual instantiation of the JAB-donor CU and the JAB-donor DU on the same physical machine. JAB-specific transport between IAB-donor-CU and IAB-donor-DU is specified in 3GPP TS 38.401.

Ll and L2 on the Figure stand respectively for the transport and physical layers appropriate to the medium in use.

The IP layer can also be used for non-Fl traffic, such as Operations, Administration and Maintenance traffic.

On the wireless backhaul, the IP layer is itself carried over the backhaul adaptation protocol (BAP) sublayer, which enables routing over multiple hops. The BAP sublayer is specified in TS 38.340.

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

In upstream direction, upper layer packets are encapsulated by the BAP sublayer at an initiator JAB-node (which may be an access JAB-node should the upper layer packets come from a UE), thus forming BAP packets or data units (PDUs) or data packets. The BAP packets are routed by the BAP layer (and corresponding BAP entities in the IAB-DU and IAB-MT) of the intermediate JAB-nodes, if any. The BAP packets are finally de-encapsulated by the BAP sublayer at the JAB-donor DU.

On the BAP sublayer, packets are routed based on the BAP routing ID, which is carried in the BAP header of the BAP packets, and which is set by the BAP sublayer of the emitting JAB-donor-DU or initiator JAB-node (e.g. a network node in the JAB network generating the BAP packets). Figure 3 illustrates the format of a BAP Data Protocol Data Unit (PDU) or packet. It is specified in the standardized version paragraph 6.2 of 3GPP TS38.340 release 16.3.0.

The payload section 307 is usually an IP packet. The header 30 includes fields 301 to 306. Field 301, named D/C field, is a Boolean indicating whether the corresponding BAP packet is a BAP Data packet or a BAP Control packet. Fields 302-304 are 1-bit reserved fields, preferably set to 0 (to be ignored by the receiver).

Fields 305 and 306 indicate together the BAP routing ID for the BAP packet. BAP address field 305, also referred to as DESTINATION field, is located in the leftmost 10 bits while BAP path identity field 306, also referred to as PATH field, is located in the rightmost bits.

Field 305 carries the BAP address (i.e.on the BAP sublayer) of the destination JAB-node or IAB-donor DU for the BAP packet. For the purpose of routing, each IAB-node and TAB-donor DU in an TAB network is configured (by JAB-donor CU of the TAB network) with a designated and unique BAP address. Field 306 carries a path ID identifying the routing path the BAP packet should follow to this destination in the IAB topology. For the purpose of routing, the routing paths, including their path ID, are configured (by IAB-donor-CU of the TAB network) in the JAB-nodes.

The BAP header is added to the packet when it arrives from upper layers to the BAP layer, and it is stripped off by the BAP layer when it has reached its destination node. The selection of the packet's BAP routing ID is configured by the TAB-donor-CU.

For instance, when the BAP packet is generated by a node, i.e, either by the IAB-donorDU for downstream transmission or by an initiator (which may be an access TAB-node should the upper layer packets come from a UE) for upstream transmission, the BAP header with the BAP Routing ID is built by this node according to a configuration table defined in 3GPP TS 38.340. This table is called Downlink Trctffic to Routing ID Mapping Configuration table in the IAB-donor-DU or Uplink Traffic to Routing ID Mapping Configuration table in the initiator IAB-node. In intermediate IAB-nodes, the BAP header fields are already specified in the BAP packet to forward As mentioned above, these configuration tables defining the BAP paths (hence the routing strategy and the configuration of the IAB-nodes given the IAB network topology) are usually defined by the TAB-donor-CU and transmitted to the TAB-nodes to configure them.

A usage of these tables (and other tables) to perform the routing is described below with reference to Figure 5, To transport messages over the 56 NR radio medium, three more sublayers (RLC, MAC and PHY) are implemented at each JAB-node below the BAP sublayer. The RLC (Radio Link Control) sublayer is responsible for the segmentation or reconstruction of packets. It is also responsible for requesting retransmissions of missing packets. The RLC layer is further described in TS38.322. The MAC (Media Access Channel) protocol sublayer is responsible for selecting available transmission formats for the user data and for the mapping of logical channel to the transport channels. The MAC handles also a part of the Hybrid Automated Repetition request scheme. The MAC layer is detailed in IS 38.321. On the emitter or transmitter side, the MAC encapsulates the data packet issued from the RLC. It adds a header carrying information necessary to the MAC function. On the receiver side, the MAC decapsulates the data packet issued from the PHY, deletes its header and passes the remaining data to the RLC. The PHY sublayer provides an electrical interface to the transmission medium (the air) by converting the stream of information into physical modulation signals, modulating a carrier frequency at emitter side; at receiver side it converts the physical modulation signals back to a stream of information. The PHY layer is described in TS 38.201, IS 38.211, TS 38.212, IS 38.213, TS 38.214.

To pass messages towards the user or control plane, two other sublayers are used in UE and JAB-donor-CU: the PDCP (Packet Data Convergence Protocol) sublayer and either the SDAP (Service Data Adaptation Protocol) sublayer for the User Plane communications or the 15 RRC (Radio Resource Control) sublayer for the Control Plane communications.

The PDCP sublayer handles JP Header compression/decompression, ciphering/deciphering, and handles the integrity on the data packet if necessary. It mandatorily numbers the packets on the emitter side and reorders the packets on the receiver side. The PDCP sublayer is described in 3GPP TS38.323, SDAP sublayer 220 for the User Plane handles the Quality of Service. It is described in 1538.324. On the UE side, the SDAP sublayer exchanges the payload data with the user's application (voice, video, etc... -not shown in the Figure). On the JAB-donor CU side, the SDAP sublayer exchanges the data with the Core Network 110 (Internet traffic, Cloud, etc..).

RRC sublayer 220 for the Control Plane handles the configuration of the protocol entities of the User Plane protocol stack. It is described in 1538.331. It is responsible for the handling of, inter alia, broadcasting information necessary to a UE to communicate with a cell; transmitting paging messages, managing connection, including setting up bearers; mobility functions; measurement configuration and reporting; devices capabilities.

The interface (for both CP and UP) between nodes using the layers PDCP, RLC, MAC and PHY is referenced NR-Uu. This mainly concerns the interface with the UE.

The interface (for both CP and UP) between nodes using the layers BAP, RLC, MAC and PHY is named BackHaul RLC Channel (BH RLC channel). This mainly concerns the interfaces between the JAB-nodes.

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

Figure 2b comes from 3GPP TS 38.300 v16.4.0 and illustrates the protocol stack for the support of JAB-MT's RRC and NAS connections. The Non-Access Stratum (NAS) protocol handles the messages between the core network and a user equipment, or an IAB-node. It manages the establishment of communication sessions and maintains communications with the JAB-node or the user equipment as it moves. The 5G NAS is described in 3GPP TS 24.501. The 56 Core Access and Mobility Management Function (AMF) is a function within the Core Network that receives all connection and session related 10 information from the UEs connected to the JAB node, as well as similar information for the 1AB-node. AMF is only responsible for handling connection and mobility management tasks. The IAB-MT establishes signalling Radio Bearers SRBs (bearers carrying RRC and NAS messages) with the JAB-donor-CU. These SRBs are transported between the JAB-MT and its parent node(s) over NR-Uu interface(s).

Figure 4 illustrates a routing management in an JAB network. The routing management at an JAB-node acting as relay is based on a BAP routing configuration and seeks to determine, from one BH RLC channel of an ingress link or backhaul link over which a BAP packet is received, one BH RLC channel of one egress link or backhaul link for forwarding the received BAP packet.

A BAP routing configuration may be set manually in each IAB-node of the IAB network.

Preferably, the BAP routing configurations are built and can be updated over time by JAB-donor CU and transmitted by the JAB-donor CU via F1AP signaling to the JAB-nodes during their initial configurations and the life of the IAB network. As mentioned above, the BAP routing configurations may be built by JAB-donor-CU based on the JAB network topology and its evolution over time (e.g, should some radio links disappear or recover or their link quality changes).

The BAP routing configuration of the JAB-node comprises various routing tables, four of which are shown in Figure 5.

Figure 5a schematically shows an entry 500 of the Backhaul Routing Configuration table as defined in 3GPP TS 38.300, V16.4.0, section 6.11.3 for the BAP sublayer. It is used by the JAB-node to select the egress link to forward or transmit a BAP packet or PDU (Protocol Data Unit).

Field 501 defines a BAP Routing ID (concatenation of the PATH field 5012 and DESTINATION field 5011, corresponding to PATH field 306 and DESTINATION field 305 as defined in Figure 3) while field 502 specifies the next-hop BAP Address, i.e. the BAP address of the next JAB-node along the path corresponding to the Routing ID 501. The Next Hop BAP address 502 thus identifies an egress link to forward or transmit the BAP packet. There may be several entries in the Backhaul Routing Configuration table with the same destination BAP address but with different Path IDs and next-hop BAP Addresses in the information element 502. The first entry may provide the default next-hop BAP Address corresponding to the default path to reach the destination, and the other entries with the same destination BAP address relate to back-up redundant paths to be selected when the default link is not available, e.g. because of radio link failure (RLF).

Figure 5b schematically shows an entry 510 of the BEI RLC channel mapping configuration table as defined in 3GPP TS 38.300, section 611.3 and/or 3GPP TS 38.340, V16.3.0, section 5,2,1,41, for the BAP sublayer. It is used by the IAB-node acting as a relay (e.g. an intermediate JAB-node) to identify the Backhaul (BH) RLC channel where to forward a BAP packet or PDU over the egress link previously selected using the Backhaul Routing Configuration table.

Information Element (1E) 511 stores a next-hop BAP address as defined previously and usually obtained from the Backhaul Routing Configuration table; IF 512 stores a prior-hop BAP address, i.e. the BAP address of the previous IAB-node from which the BAP packet arrives; IF 513 specifies an ingress RLC channel ID, i.e. the identifier of an RLC channel over which the BAP packet is received; and IF 514 stores an egress RLC channel ID providing the RLC channel the IAB-node will use to forward the BAP packet.

Note that for BH RLC channels in downstream direction (parent to child direction, e.g. IAB-node 402 towards IAB-node 403 in Figure 4), the BH RLC channel ID is included in the FlAP configuration of the BH RLC channel. For BH RLC channels in upstream direction (child to parent direction, e.g. JAB-node 402 towards IAB-node 401), the BH RLC channel ID is included in the RRC configuration of the corresponding logical channel.

Figures Sc and 54 illustrates the equivalents to the BH RTC channel mapping configuration table for the JAB-node that does not act as intermediate JAB relaying entities. They are defined in 3GPP TS 38.340, sections 5.2.1.4.2. and section 5.2.1.4.3.

The table in Figure Sc is called Uplink Traffic to RH RLC Channel Mapping Configuration table, 520. It is used by an initiator JAB-node (not the IAB-donor-DU) having built BAP packets or PDUs from BAP SDUs (Service Data Unit) received from upper layers, to identify the Backhaul (BH) RLC channel to transmit these packets in upstream direction over the egress link previously selected using the Backhaill Routing Configuration table described in Figure 5a.

IF 521 specifies a Traffic Type Identifier for the SDUs received from the upper layers, IE 522 indicates a next-hop BAP address as defined previously and usually obtained from the Rackhaul Routing Configuration table, and IE 523 specifies an egress BH RLC channel providing the RLC channel the JAB-node will use to transmit the BAP packet.

The table in Figure 5d is called Downlink:Ire ic to BH RLC Channel Mapping Configuration table 530. It is used by the IAB-donor-DU having built BAP packets or PDUs from BAP SDUs (Service Data Unit) received from upper layers, to identify the Backhaul (BH) RLC channel to transmit these BAP packets in downstream direction over the egress link previously selected using the Backhaul Routing Configuration table.

IF 531 is an IPv6 flow label used to classify IPv6 flows, IF 532 specifies a DSCP (Differentiated Services Code Point) usually indicated in the IPv6 header of the packets, IF 533 indicates a destination IP Address, IE 534 indicates a next-hop BAP Address as defined above, and LE 535 defines an egress BH RLC channel ID providing the RLC channel the JAB-node will use to transmit the BAP packet.

The tables of Figures 5b, Sc and 5d may be composed of several rows (entries), each row/entry including the IEs (or fields) shown in the respective Figures.

Next-hop BAP address and egress link are synonymous because they designate the same portion (link) of the IAB network between the current IAB-node and the next IAB-node having the next-hop BAP address. Consequently, they can be used interchangeably to designate such JAB network link.

As a result of all the tables configured in the IAB-nodes and more particularly the Routing IDs of IEs 501, multiple BAP paths are defined through multiple JAB-nodes.

Back to Figure 4, typically the routing of a BAP packet by the BAP sublayer of JAB-node 402 uses the BAP routing ID 305+306 of a BAP packet. The BAP address (DESTINATION path 305) is used for the purpose of 1) determining whether the BAP packet has reached the destination node, i.e. JAB-node or JAB-donor DU, on BAP sublayer. The BAP packet has reached its destination node if the BAP address 305 in the packet's BAP header matches the BAP address configured either via RRC on the JAB-node or via ElAP on the JAB-donor DU.

2) determining the next-hop JAB-node for the BAP packet that has not reached its destination. This applies to BAP packets arriving from a prior-hop JAB-node over the BAP sublayer or that have been received from upper layers.

For packets arriving from a prior-hop LAB-node or from upper layers, the determination of the next-hop IBA-node is based on the Backhaul Routing Configuration table 500.

The 1AB-node 402 resolves the next-hop BAP address 502 to a physical backhaul link, being either link 420 or link 430. To that end, it seeks the entry in the table 500 having field 501 matching the BAP Routing ID 305+306 of the BAP packet. Corresponding field 502 provides the next-hop BAP address.

The Backlit-nil Routing Configuration table may have multiple entries 500 with different BAP Routing IDs but with the same destination BAP address (meaning the BAP Path IDs are different). These entries may correspond to the same or different egress BH links. In case, the BH link matching the BAP Routing ID of the BAP packet experiences a radio link failure (RLF), typically the IAB-node may select another egress BH link (next-hop BAP address) based on routing entries with the same destination BAP address, i.e. by disregarding the BAP path ID. In this manner, a BAP packet can be delivered via an alternative path in case the indicated path is not available.

For instance, in case BH link 420 experiences a radio link failure, IAB-node 402 may select another BAP routing ID having the same destination BAP address but involving BH link 430 instead.

Next, the IAB-node 402 derives the egress BH RLC channel of the selected egress BH link, over which the BAP packet is to be transmitted or forwarded. To that end, the IAB-node 20 402 uses the BH RLC channel mapping configuration table or Uplink Traffic to BH RLC Channel Mapping Configuration table orDownlink Traffic to BH RLC Channel Mapping Configuration table depending on its role (intermediate or relay JAB-node, initiator JAB-node or IAB-donor-DU transmitting in uplink/upstream or downlink/downstream direction). For instance, for an intermediate or relay JAB-node, IEs 511, 512, 513 are the inputs and IE 514 is the output of the BH RLC channel look-up process: IAB-node 402 routes the incoming BAP packets received from the ingress BH RLC channel ID 513, belonging to the ingress BH link identified by the prior-hop BAP address 512, to the egress BH RLC channel ID 514, belonging to the egress BH link previously selected and now identified by the next-hop BAP address 511.

For an initiator IAB-node wishing to transmit a BAP packet in the upstream direction to the JAB-donor, Ms 521, 522 are the inputs and IE 523 is the output of the BH RLC channel look-up process: the JAB-node 402 selects the egress BH RLC Channel 523 corresponding to the table entry 520 where the Traffic Type Identifier 521 matches the traffic type of the original BAP SDU, and where the next-hop BAP address 522 matches the next-hop BAP address previously selected with the Backhaul Routing Configuration table. This applies for BAP SDUs in the control plane (non Fl-U packets), as well as for BAP SDUs in the user plane (Fl-U packets). The Traffic Type Identifier 521 shall correspond to the destination IP address and FEID (Tunnel End Point Identifier) of the BAP SDUs, For the IAB-donor-DU wishing to transmit a BAP packet in the downstream direction to a destination IAB-node or an UE, IEs 531, 532, 533, 534 are the inputs and IE 535 is the output of the BH RLC channel look-up process: JAB-node selects the egress BH RLC Channel 535 corresponding to the table entry 530 matching the Destination IP address 533, the IPv6 Flow Label 531 (only for BAP SDU encapsulating an IPv6 packet), and the Differentiated Services Code Point (DSCP) 532 of the original BAP SDU, and where the next-hop BAP address 534 matches the next-hop BAP address previously selected with the Backhaul Routing Configuration table. This applies for BAP SDUs in the control plane (non Fl-U packets), as well as for BAP SDUs in the user plane (F 1-Upackets).

If there is no matching entry, a default BH RLC ID channel may be selected.

Such routing process can be implemented in the various 1AB-nodes of an JAB network.

Figure 6 illustrates an example topology 600 of an IAB network arrangement in which embodiments and examples of embodiments of the present invention may be implemented so as to provide network path diversity through the ability to route data packets across one JAB network and at least one other IAB network. In one example implementation, the BH radio links are operated over the millimeter wave frequency band (i.e. above 30 GHz), which is highly sensitive to radio channel disturbance.

IAB topology 600 includes IAB-donor-CU 610 and JAB-donor CU 620, their associated IAB-donor-DUs, IAB-donor-DU 601 (belonging to IAB-donor-CU 610), IABdonor-DU 602 (belonging to IAB-donor-CU 620), and a plurality of JAB-nodes 611, 612 and 613, similar to IAB-nodes 121 and 122.

A wired backhaul IP network interconnects the IAB-donor-CU 610 and 620, and the JAB-donor-DUs 601 and 602 through a router 640 and the links 641, 642, 650, and 660. For instance, these wired links consist of optical fiber cables.

IAB-Donor-CU 610, IAB-Donor-DU 601, IAB-node 612 and IAB-node 613 are part of 30 the same IAB network 691, which is configured and managed by IAB-Donor-CU 610. IAB-Donor-CU 620, IAB-Donor-DU 602 and IAB-node 611 are part of the same JAB network 692, which is configured and managed by IAB-Donor-CU 620. JAB network 692 is different to the IAB network 691. TAB network 692 may be a neighbouring or adjacent JAB network to IAB network 691.

IAB-node 611 is connected to the parent IAB-donor-DU 602 through wireless BH link 633 IAB-node 612 is connected to the parent 1AB-donor-DU 601 through wireless BH link 631, and to the child IAB-node 613 through wireless BH link 632. Although IAB-node 612 belongs to IAB network 691, in view of its proximity to IAB network 692 and in particular to IAB-node 611, IAB-node 612 is also connected to IAB-node 611 (which acts as a parent node to IAB-node 612) through wireless BH link 636. As IAB-node 612, even though belonging to IAB network 691, is also connected to IAB-node 611, which belongs to IAB network 692, it may be referred to as a Boundary node between JAB network 691 and JAB network 692. As IAB-node 612 or Boundary node 612 is part of the JAB network 691, it is configured and managed by the IAB-Donor-CU 610 of IAB network 691. For example, the IAB-Donor-CU 610 configures the Boundary node 612 with configuration information during initial configurations and overtime to account for any changes/updates in the configurations/topologies of the JAB network 691 (and also JAB network 692 which impact the configuration of Boundary node 612). In one embodiment of the invention, 1AB-node 612 is assigned two BAP addresses by IAB-donor-CU 610: one BAP address for JAB network 691 and one for IAB network 692. The IAB-donor-CU 610 will transmit the assigned BAP addresses to the Boundary node 612 in configuration messages as discussed below.

As IAB-donor-DUs 601, 602 and IAB-nodes 611, 612, 613 are respectively serving UEs 621, 622, 623, 624, 625 and 626, they also act as access JAB-nodes for the respective UEs Redundant paths may exist between pairs of IAB-nodes, for instance, regarding downstream paths from IAB-donor-CU 610 to IAB-node 613, a first default BAP path via an IAB-donor-DU 601 and TAB-node 612, a second BAP path via an IAB-donor-DU 602, IAB-nodes 611, and 612. Symmetrically, there are also two upstream paths involving the same nodes from IAB-node 613 to JAB-donor-CU 610.

For the exemplary description below, we consider the following downstream BAP paths: -PATH 1, associated with BAP Routing ID 2, from IAB-donor-CU 610 to IAB-node 613 via an IAB-donor-DU 601, IAB-node 612, and going through BH radio links 633, 636, and 632; -PATH 2, associated with BAP Routing ID 1, from TAB-donor-CU 620 to IAB-node 613 via an IAB-donor-DU 602 IAB-node 611 and 612, and going through BH radio links 633, 636 and 632. As PATH 2 is used to route BAP PDUs through a plurality of networks, i.e. IAB network 691 and IAB network 692, it is referred to as a Transit path.

BH radio link 631 between IAB-node 612 and IAB-donor-DU 601 may experience radio link deficiency due to some unexpected interference or shadowing phenomena, for example radio link failure, RLF. BH radio link 631 may also experience congestion at IABnode 612.

For such reasons, the TAB-donor-CU 610 may decide, if possible, to re-route some BAP PDUs, initially planned to be routed through PATH 1, over an alternative path that would not involve BH radio link 631, e.g. PATH 2.

Also, the link 631 may be congested due to an excessive data traffic, and the TABdonor-CU 610 may decide to offload some BAP PDUs, initially planned to be routed through PATH 1, over an alternative path, e.g. PATH 2, in order to mitigate such congestion.

The processes for managing such re-routing or offloading, are now described according to some embodiments of the present invention. The following description applies to routing data packets in the upstream or downstream direction.

Figure 13 shows steps of a method 1300 for processing data packets in accordance with an embodiment of the present invention. Method 1300 is performed at an IAB node of an IAB network comprising a plurality of JAB nodes. For example, the JAB node may be node 612 of IAB network 691. The JAB node may be implemented in a communication device 1100 as shown in Figure 11 below with the method as shown in Figure 13 being performed by the central processing unit 1111.

Briefly, in step 1301, the TAB node 612 receives a data packet (for example, a BAP packet or BAP PDU) including a destination address of a destination JAB node for the data packet and a path identifier identifying a routing path for the data packet to the destination IAB node. In an example, the data packet includes a header comprising the destination address and the path identifier which together indicate a routing identifier (e.g. fields 305 and 306 of the BAP PDU of Figure 3). At step 1302, the IAB node 612 determines, based on the the received data packet, whether the routing path of the received data packet includes at least one JAB node of a different JAB network (e.g. IAB network 692). In other words, the JAB node 612 determines, based on the received data packet, whether the routing path of the received data packet is a transit path, where a transit path is a routing path including at least one JAB node of a different JAB network (e.g. a transit JAB network). In response to determining that the routing path of the received data packet includes at least one JAB node of a different 1AB network (YES branch from step 1302), the IAB node 612 uses the path identifier of the received data packet to determine, at step 1303, whether there is a next JAB node in the routing path for routing the data packet. In an example, in order to determine whether there is a next IAB node in the routing path for the data packet (e.g. to determine the next LAB node), the JAB node 612 uses the path identifier and not the destination address of the received data packet. The 1AB node 612 may only use the path identifier to determine that there is a next JAB node in the routing path for routing the data packet. When a next IAB node is determined (Yes branch from step 1303), the IAB node 612 routes the data packet to the next IAB node, step 1304. The next 1AB node may be in the IAB network 691 (e.g. IAB node 613 or IAB-donor-DU 601) or may be an IAB node in IAB network 692 (e.g. JAB node 611). If at step 1302, the JAB node 612 determines that the routing path of the received data packet does not include at least one JAB node of a different JAB network (NO branch from step 1302), the 1AB node 612 uses the destination address and path identifier (e.g. the routing ID) to perform packet routing, step 1305.

When a next IAB node is not determined at step 1303 (NO branch from step 1303), the JAB node 612 determines, at step 1306, whether the JAB node 612 is the destination JAB node for the data packet. If at step 1306, the IAB node 612 determines that the IAB node is the destination IAB node (YES branch from step 1306), the 1AB node 612 accepts the data packet for further processing, step 1307. For example, the JAB node 612 forwards the data packet to higher layers for further processing. If at step 1306, the JAB node 612 determines that the IAB node is not the destination IAB node (NO branch from step 1306), the IAB node 612 discards the data packet, step 1308.

More details regarding the processing of the data packets for routing are given below with respect to the example methods shown in Figures 8 and 9.

As discussed above, the JAB node 612 determines whether the routing path of the received data packet includes at least one JAB node of a different JAB network using the received data packet. In other words, the JAB node 612 determines, based on the received data packet, whether the routing path of the received data packet is a transit path, where a transit path is a routing path including at least one JAB node of a different JAB network. When a data packet is routed over a transit path, the data packet is routed over a plurality of JAB networks. If a routing path of a data packet is not a transit path, the data packet is routed only within one IAB network.

In an example of an embodiment of the invention, the JAB node 612 determines whether the routing path of the received data packet includes at least one TAB node of a different JAB network using the path identifier of the received data packet. In other words, the JAB node 612 determines, based on the path identifier of the received data packet, whether the routing path of the received data packet is a transit path, where a transit path is a routing path including at least one JAB node of a different JAB network.

Figure 12 shows an entry 1200 of a routing configuration table in accordance with an example of an embodiment of the invention. Routing configuration table 1200 corresponds to the entry 500 of Baa-haul routing configuration table of Figure 5a with an additional field, transit field 1203. The other fields, Routing ID field 501 (comprising destination address field 5011 and path identifier field 5012, and the next hop BAP address field 502 of the Backhaul routing configuration table of Figure 5a are shown in Figure 12 and designated with the same reference numerals as Figure 5a. The transit field 1203 of the routing configuration table 1200 is for Transit path information for indicating whether the routing path identified by PATH 5012 is a Transit path or not. The transit field 1203 may be a one bit field. In one example, setting the Transit path information bit to '1' can be used to indicate the routing path indicated by the path identifier in the PATH field 5012 is a Transit path, i.e. a path or routing path that is over or extends over at least two TAB networks, and setting the Transit path information bit to '0' can be used to indicate the routing path indicated by the path identifier in the PATH field 5012 is not a Transit path.

With the routing configuration table 1200 configured at the JAB node 612 (e.g. by the JAB-donor-CU 610 of JAB node 612), the JAB node 612 can determine whether the routing path of the received data packet is a transit path by comparing the path identifier of the received data packet with the path identifier field 5012 of the routing configuration table 1200, arid when the path identifier of the received packet matches a path identifier in the path identifier field 5012 of an entry with a value in the transit field 1203 indicating the path identifier is a transit path identifier (i.e. a path identifier for a routing path which is a transit path), the JAB node 612 can determine that the routing path of the received data packet is a transit path.

In another example of an embodiment of the invention, the data packet comprises a header including the path identifier and at least one bit configured to indicate whether the path identifier of the data packet is a transit path identifier identifying a transit path. The at least one bit may be at least one bit of the path identifier field or may be at least one reserved bit of the header, for example, as discussed below with reference to Figure 16.

Figure 16 shows the format of a BAP Data Protocol Data Unit (PDU) or packet in accordance with an example of an embodiment of the invention. It is specified in the standardized version paragraph 6.2 of 3GPP 1S38.340 release 16.3.0. BAP Data Protocol Data Unit (PDU) format 1600 corresponds to the BAP Data Protocol Data Unit (PDU) format 300 of Figure 3 with an additional field, transit field 1601. This field may be set by the IAB-donor DU for data packets to be communicated in the downstream direction or by an access JAB node for data packets to be communicated in the upstream direction.

The other fields 301, 302, 303, 304, 305, 306 and 307 are shown in Figure 16 and are designated with the same reference numerals as Figure 3. The transit field 1601 is for Transit path information for indicating whether the routing path identified by the path identifier in PATH field 306 (i.e. the path identifier in the data packet) is a Transit path or not. The transit field 1601 is a one bit field. In one example, setting the Transit path information bit to '1' can be used to indicate the routing path indicated by the path identifier in the PATH field 306 is a Transit path, i.e. a path or routing path that is over or extends over at least two 1AB networks, and setting the Transit path information bit to '0' can be used to indicate the routing path indicated by the path identifier in the PATH field 306 is not a Transit path.

In one example of an embodiment of the invention, the transit field 1601 is one bit from the PATH field 306, e.g. the most significant bit (MSB).

In another example of an embodiment of the invention, the transit field 1601 is one out of the 4 reserved bits 301, 302, 303 and 304.

Examples of how the routing configuration table 1200 is configured by the JAB-donorCU are described below with reference to Figure 10 and Figure 15. More details regarding the processing of the data packets for routing are given below with respect to the example 25 methods shown in Figures 8 and 9.

In another example, one or more path identifier values of a plurality of path identifier values can be assigned to represent one or more transit path identifiers, each one of the one or more path identifier values representing a respective transit path identifier identifying a transit path. Which values are assigned to represent one or more transit path identifiers may be defined in a standard by a standards organisation (e.g. 3GPP) or may be assigned and configured by an JAB-donor-CU or may be assigned by a network operator or may be configured as a factory setting. For example, the IAB node 612 may receive routing configuration information from the IAB-donor-CU 610 with the routing configuration information indicating the one or more path identifier values assigned to the one or more transit path identifiers. Examples of how the JAB node is configured by the JAB-donor-CU are described below with reference to Figure 10 and Figure 15. The routing configuration information may include a transit configuration table with each entry in the transit configuration table including a transit path identifier field for one of the one or more path identifier values assigned to represent the one or more transit path identifiers.

Figure 7 illustrates an example of a transit configuration table at an JAB-node according to an example of an embodiment of the invention As an alternative to using at least one bit in the header of the received data packet as described above with reference to Figure 16 or to using a transit field 1203 in each entry 1200 of the Backhauf Routing Configuration table, as described in Figure 12, a transit configuration table or Transit Path Information Table may be used to gather the identifiers of the PATH to be used as Transit paths by an IAB-node when routing a BAP PDU, as further discussed above and in Figure 8 and Figure 9.

In one example, the lransit Path Information Table is configured by the JAB-donor-CU, as described in Figure 10 or Figure 15.

In another example, the:transit Path Information Table is configured by a network operator, as part of the Operations, Administration and Maintenance (OAM) of the network, or is a factory setting of an IAB-node.

Figure 7 schematically shows an entry 700 of the Transit Path Information table according to some embodiments of the present invention.

Field 701 (also referred to as transit path identifier field 701) defines a TRANSIT PATH information, similar to the PATH information 5012 discussed in Figure 5. In other words, the transit path identifier field 701 is for a path identifier as per field 5012 and in particular is for a path identifier value assigned to represent a transit path identifier for a transit path. The number of entries in the Transit Path Information table will depend on the number of path identifier values assigned to represent transit path identifiers for transit paths. When the value of a PATH information or path identifier in a BAP PDU header matches a TRANSIT PATH information value, the JAB node determines that the routing path for the data packet is a transit routing path. Thus, when the Transit Path Information table is configured at the JAB node 612 (e.g. by the IAB-donor-CU 610 of IAB node 612), the IAB node 612 can determine whether the routing path of the received data packet is a transit path by comparing the path identifier of the received data packet with the one or more path identifier values in the Transit Path Information table. When the path identifier matches one of the one or more path identifier values, the JAB node 612 determines that the routing path of the received data packet is a transit path The routing of the BAP PDU is processed according to the methods defined in Figure 8 or Figure 9 discussed below.

The Transit Path Information table of Figure 7 also includes a field 702 (also referred to as target JAB information field) for indicating if the destination JAB-node of a BAP PDU, routed using TRANSIT PATH 701, is in the JAB network the JAB-node belongs to or if the destination IAB-node is part of another IAB network.

In one example of the invention, an entry 700 of the Transit Path InfOrmation table is made of field 701 only. In another example of the present invention, an entry 700 of the Transit Path Information table is made of both field 701 and field 702.

Examples of how the Transit Path Information table is configured by the IAB-donorCU are described below with reference to Figure 10 and Figure 15.

Figure 8 illustrates, using a flowchart 800, a first exemplary method for processing data packets (e.g. for managing BAP PDU (or data packet) routing over a plurality of JAB networks) according to embodiments and examples of the invention. For instance, a program element executed by the CPU 1111 of Figure 11 for a BAP entity (DU or MT part) of the BAP sublayer may perform the exemplary method shown in Figure 8. The method of Figure 8 may be applied for routing data packets in the upstream or downstream direction.

The process starts at step 801 where an IAB-node, such as IAB node 612, receives a BAP packet, or BAP PDU.

At step 802, the JAB-node parses the header of the BAP packet and retrieves the PATH information 306 or path identifier 306.

Then, at step 803, the JAB-node determines whether the PATH information or path identifier retrieved at step 802 relates to a Transit Path. Different examples of embodiments of the invention for identifying whether the retrieved path identifier relates to a transit path have been described above. Some of these examples are mentioned briefly below.

In one example where the JAB-node is configured with aRockhold Routing Configuration table 1200 such as that shown in Figure 12, the JAB-node parses its Backhaul Routing Configuration table, finds an entry which PATH information matches the one retrieved from the BAP packet header and checks the Transit Path Information field 1203, as discussed with reference to Figure 12.

In another example, the JAB-node parses its Transit Path Information Table 700 looking for an entry which PATH information matches the one retrieved from the BAP packet header, as discussed with reference to Figure 7.

In another embodiment of the invention, the JAB-node parses the BAP PDU header, looking for the transit field 1601, as discussed with reference to Figure 16.

If it is determined at step 803 that the BAP packet is to be routed over a non-Transit Path, the JAB-node gets the whole Routing ID information 30 from the BAP packet header (step 804) and parses its 13ackhaul Routing Configuration table (also referred to as routing configuration table), looking for an entry that matches this Routing ID (step 805), and performs packet routing accordingly (step 806), as discussed above with reference to Figure 4 and to Figure 5. An entry of the routing configuration table may correspond to entry 500 of Figure 5a or entry 1200 of Figure 12, If, at step 805, the DESTINATION information 305 in the BAP packet header matches the JAB-node's local BAP address, the BAP packet is sent to IAB-node's upper layers and step 806 is skipped, as the JAB-node understands that it is the actual destination of the BAP packet.

If it is determined at step 803 that the BAP packet is to be routed over a Transit Path, the IAB-node parses its Backhaul Routing Configuration table, looking for an entry 500 that matches the PATH information retrieved from the BAP packet header (step 807).

If an entry is found (step 808), the IAB-node checks the Next Hop BAP Address field 502 in the found entry and routes the BAP Packet accordingly, without considering both the value of the DESTINATION information 305 in the BAP packet header and the DESTINATION information 501 in the found entry (step 809). In other words, the JAB node determines whether there is a next IAB node for routing the data packet using the path identifier of the received data packet and by comparing the path identifier of the received data packet with the path identifier field of the routing configuration table. When the path identifier of the received data packet matches a path identifier in the path identifier field, the IAB node determines there is a next JAB node and routes the data packet to the next JAB node without using the destination address included in the data packet.

If no entry is found (step 808), the JAB-node checks the DESTINATION information 305 in the BAP packet header and compares it to its own local BAP address (step 811).

If the DESTINATION information 305 in the BAP packet header matches the JAB-node's local BAP address, the BAP packet is sent to JAB-node's upper layers (step 812), as the IAB-node understands that it is the actual destination of the BAP packet. Otherwise the BAP packet is discarded (step 813). In other words, if no entry is found at step 808, the IAB-node determines there is not a next JAB-node and depending on the comparison at step 811, either the JAB-node is the destination of the BAP packet (step 812) or the BAP packet is discarded (step 813) The flowchart 800 ends at step 814.

Figure 9 illustrates, using a flowchart 900, a second exemplary method for processing data packets (e.g. for managing BAP PDU (or data packets) routing over a plurality of JAB networks) according to embodiments and examples of the invention. For instance, a program element executed by the CPU 1111 of Figure 11 for a BAP entity (DU or MT part) of the BAP sublayer may perform the exemplary method shown in Figure 9. The method of Figure 9 may be applied for routing data packets in the upstream or downstream direction.

The process starts at step 901 where an IAB-node, such as IAB node 612, receives a BAP packet, or BAP PDU.

At step 902, the JAB-node parses the header of the BAP packet and retrieves the PATH information 306 or path identifier 306.

Then, at step 903, the 1AB-node determines whether the PATH information or path identifier retrieved at step 902 relates to a Transit Path. Different examples in accordance with embodiments of the invention for identifying whether the retrieved path identifier relates to a transit path have been described above. Some of these examples are mentioned briefly below.

In one example where the IAB-node is configured with a Rockhold Routing Configuration table 1200 such as that shown in Figure 12, the JAB-node parses its Backhaul Routing Configuration table, finds an entry which PATH information matches the one retrieved from the BAP packet header and checks the Transit Path Information field 1203, as discussed with reference to Figure 12.

In another example, the TAB-node parses its:transit Path Information Table 700 looking for an entry which PATH information matches the one retrieved from the BAP packet header, as discussed with reference to Figure 7.

If it is determined at step 903 that the BAP packet is to be routed over a non-Transit Path, the JAB-node gets the whole Routing ID information 30 from the BAP packet header (step 904) and parses its Backhawl Routing Configuration table (also referred to as routing configuration table), looking for an entry that matches this Routing ID (step 905), and performs packet routing accordingly (step 906), as discussed above with reference to Figure 4 and to Figure 5. An entry of the routing configuration table may correspond to entry 500 of Figure 5a or entry 1200 of Figure 12. It at step 905, the DESTINATION information 305 in the BAP packet header matches the lAB-node's local BAP address, the BAP packet is sent to JAB-node's upper layers and step 906 is skipped, as the JAB-node understands that it is the actual destination of the BAP packet.

If it is determined at step 903 that the BAP packet is to be routed over a Transit Path, the JAB-node retrieves the DESTINATION information 305 from the BAP header (step 907) and compares it to its own local BAP address (step 908).

If the DESTINATION information 305 in the BAP packet header does not match the IAB-node's local BAP address, the JAB-node parses its Rockhold Routing Configuration table, looking for an entry 500 that matches the PATH information retrieved from the BAP packet header (step 909). In one preferred embodiment of the invention, an IAB-node has an entry configured in its Backhaul Routing Configuration table for each Transit path to be used to route BAP packets in the IAB network it belongs to Once an entry is found (step 910), the lAB-node checks the Next Hop BAP Address field 502 in the found entry and routes the BAP Packet accordingly, without considering both the value of the DESTINATION information 305 in the BAP packet header and the DESTINATION information 501 in the found entry.

If it is determined at step 908 that the DESTINATION information 305 in the BAP packet header matches the IAB-node's local BAP address, the 1AB-node now considers the whole BAP Routing ID (i.e. DESTINATION 305 and PATH 306) in the BAP packet header (step 911) and parses its Rockhold Routing Configuration table, looking for an entry 500 that matches this Routing ID information (step 912).

In one preferred embodiment of the invention, an IAB-node has an entry configured in 25 its Backhaul Routing Configuration table for each Transit path to be used to route BAP packets in the IAB network it belongs to.

Once an entry is found (step 913), the IAB-node gets the DESTINATION BAP address 501 associated to the Transit Path ID in the BAP Backhaul Routing Configuration Table. Then, at step 914, the JAB-node compares this DESTINATION BAP address 501 to its own local BAP address.

In one embodiment of the invention, the DESTINATION BAP address 501 associated to the Transit Path ID in the BAP Backhaul Routing Configuration Table of an IAB-node is set either 1) to the BAP address of the actual Destination JAB-node when said JAB-node and the actual Destination IAB-node belong to the same IAB network, or 2) to the address of a Boundary JAB-node in case said JAB-node and the actual Destination JAB-node do not belong to the same JAB network.

If the DESTINATION information 501 matches the 1AB-node's local BAP address, and thus the DESTINATION information 305 in the BAP packet header, the BAP packet is sent to IAB-node's upper layers (step 915), as the IAB-node understands that it is the actual destination of the BAP packet.

If the DESTINATION information 501 does not match the JAB-node's local BAP address, and thus the DESTINATION information 305 in the BAP packet header, the IABnode understands that it is not the actual destination of the BAP packet. Therefore, the BAP Packet is routed based on the Next Hop BAP Address field 502 in the entry found at step 912, without considering both the value of the DESTINATION information 305 in the BAP packet header and the DESTINATION information 501 in the found entry.

Thus, the IAB node may determine whether there is a next JAB node for routing the data packet using the path identifier of the received data packet by comparing the path identifier of the received data packet with the path identifier field of the routing configuration table. When the path identifier of the received data packet matches a path identifier in the path identifier field of an entry in the routing configuration table and when an address assigned to the JAB node does not match the address of the TAB node in the destination address field of the entry (e.g. No branch at steps 908 and 914 of Figure 9), the IAB node determines there is a next IAB node. When the path identifier of the received data packet matches a path identifier in the path identifier field of an entry in the routing configuration table and when the destination address of the received data packet matches the address of the IAB node and the address in the destination address field of the entry (e.g. YES branch at steps 908 and 914 of Figure 9), the IAB node determines there is not a next JAB node and the JAB node is the destination JAB node.The flowchart 900 ends at step 916.

As an illustration of the process of routing data packets over a transit path in accordance with the present invention (e.g. according to the first and second exemplary methods described above) and using the example of Figure 6 for PATH 2 identified above, the routing configuration table (e.g. the Backhaul routing configuration table) of JAB-node 611 may include at least the following entry for the transit path identified by the path identifier PATH 2: BAP Routing ID Next hop BAP address ID 4 (BAP Address IAB-node 613 + PATH 2) 2nd BAP Address IAB-node 612 As discussed above, the path identifier PATH 2 in the header of the received data packet (or at least one bit in the header of the data packet) will be used to determine that the routing path for the data packet is a transit routing path. For example, by identifying that the path identifier PATH 2 is a transit path identifier. As discussed above, the IAB node 612 node may be assigned two unique addresses: one by the JAB-donor CU 610, which manages the JAB node 612 and one by the LAB-donor CU 620 of the neighbouring TAB network 692. In this example, the JAB node 612 has been assigned a unique address Pt BAP Address JAB-node 612 by the 1AB-donor CU 610 and has been assigned a unique address 2nd BAP Address of IAB-node 612 by the IAB-donor CU 620. The unique address 2ild BAP Address of IAB-node 612 is assigned by the JAB-donor CU 620 to the IAB-node 612 as a Boundary IAB node and notified to the JAB-donor CU 610 during inter-CU negotiations which are discussed in more detail below with reference to Figure 10 and Figure 15. The JAB-node 611 thus has the information that BAP PDUs with path identifier PATH 2 are routed toward the IAB node 612.

The routing configuration table of IAB-node 612 may include at least the following entry for the transit path identified by the path identifier PATH 2: BAP Routing ID Next hop BAP address ID 4 (BAP Address IAB-node 613 + PATH 2) BAP Address IAB-node 613 As discussed above, the path identifier PATH 2 in the header of the received data packet (or at least one bit in the header of the data packet) will be used to determine that the routing path for the data packet is a transit routing path. For example, by identifying that the path identifier PATH 2 is a transit path identifier. The IAB-node 612 thus has the information that BAP PDUs with path identifier PATH 2 are routed toward the TAB node 613.

For the method of routing according to the exemplary method of Figure 8 routing configuration table of JAB-node 613 will not include an entry for PATH 2. The JAB-node 613 thus has the information that it is the destination JAB node for BAP PDUs with path identifier PATH 2 For the method of routing according to the exemplary method of Figure 9 routing configuration table of JAB-node 613 may include at least the following entry: BAP Routing ID Next hop BAP address ID 4 (BAP Address IAB-node 613 + PATH 2) The JAB-node 613 thus has the information that it is the destination JAB node for BAP PDUs with path identifier PATH 2 since the destination address of the received data packet matches the address of the lAB node 613.

Figure 14 shows steps of a method 1400 for managing processing of data packets in accordance with an embodiment of the present invention. Method 1400 is performed at a donor CU of a first JAB network comprising a plurality of JAB nodes. For example, the donor CU may be JAB-donor CU 610 of JAB network 691 or JAB-donor CU 620 of JAB network 692 of Figure 6 or IAB-donor CU A 1010 or IAB-donor CU B 1020 of Figure 10 or IAB-donor CU A 1510 or JAB-donor CU B 1521 of Figure 15. The JAB-donor CU may be implemented in a communication device 1100 as shown in Figure 11 below with the method as shown in Figure 14 being performed by the central processing unit 1111.

Briefly, at step 1401, the JAB-donor CU of a first JAB network determines one or more transit paths corresponding to routing paths for routing data packets over the first TAB network and a second JAB network. Then at step 1402, the JAB-donor CU provides to at least one JAB node of each transit path of the one or more transit paths (e.g. provides to at least one IAB node of the first JAB network which JAB node is in one of the transit paths), routing configuration information relating to the determined one or more transit paths corresponding to routing paths for routing data packets over at least the at least one JAB node of the first JAB network and at least one JAB node in the second JAB network. The routing configuration information may include values of path identifiers assigned to represent transit path identifiers identifying transit paths.

In an example where the second IAB network (or could be the first IAB network) is the transit network (i.e. data packets are re-routed from the first JAB network (or could be the second JAB network) through the transit network), all of the TAB nodes in the second JAB network of a determined first transit path are configured with routing configuration information relating to the determined first transit path. And similarly for each transit path of the other determined one or more transit paths. All of the IAB nodes in the first (non-transit) IAB network of the determined first transit path may be configured with routing configuration information relating to the determined first transit path. And similarly for each transit path of the other determined one or more transit paths. In an alternative example, not all of the JAB nodes in the first (non-transit) JAB network of the determined first transit path are configured with routing configuration information relating to the determined first transit path. For this alternative example, the data packets may be routed for some of the JAB nodes of the first JAB network in the determined first transit path based on routing configuration information for routing paths only within the first IAB network (e.g. routing configuration information provided for non-transit routing paths within the first 1AB network in accordance with normal procedures).

In an example, once a first JAB node, such as LAB node 612, in a first JAB network 691 establishes a connection with one or more IAB nodes, such as 1AB node 611, in a different neighbouring JAB network (such as JAB network 692, hereafter referred to as the second IAB network), the IAB-donor CU 610 may receive a notification from the IAB node 612 indicating the JAB node 612 is capable of routing data packets to one or more JAB nodes in the second 1AB network 692. That is, the IAB node 612 notifies the IAB-donor CU 610 that it has dual connectivity.

The JAB-donor CU 610 may then send or transmit to the JAB-donor CU 620 of the second JAB network 692 an offload notification to establish one or more transit paths. The notification may include information relating to the one or more IAB nodes of the second network to which the JAB node 612 has established a connection. The information relating to the one or more JAB nodes uniquely identifies each of the one or more nodes in the second 1AB network. For each of the one or more nodes, this could be, for instance, an IP address (e.g. the IP address of the JAB-donor CU of the JAB node or the IP address of the JAB node) or a combination of a BAP address and a unique JAB network identifier. The information may also include information identifying routing paths currently in use for data packets over the first IAB network and/or information identifying possible one or more transit paths.

The JAB-donor CU 610 may then receive from the JAB-donor-CU 620 information identifying one or more transit paths corresponding to routing paths for routing data packets over at least the JAB node 612 of the first JAB network and at least one JAB node in the second 1AB network. The at least one 1AB node in the second 1AB network may be at least one of the one or more JAB nodes to which the JAB node 612 has established a connection. The JAB-donor CU 610 may then determine one or more transit paths corresponding to routing paths for routing data packets over the first TAB network and a second TAB network using the received information identifying one or more transit paths.

In another example, once a first IAB node, such as IAB node 611, in a first IAB network 692 establishes a connection with one or more JAB nodes, such as JAB node 612, in a different neighbouring TAB network (such as JAB network 691, hereafter referred to as the second IAB network), the IAB-donor CU 620 may receive a notification from the IAB node 611 indicating the JAB node 611 is capable of routing data packets to one or more JAB nodes in the second JAB network 691. That is, the JAB node 611 notifies the JAB-donor CU 620 that it has dual connectivity.

The IAB-donor CU 620 may then send or transmit to the IAB-donor CU 610 of the second JAB network 691 an offload notification to notify the JAB-donor CU 610 of the possibility to perform offloading and to thus, establish one or more transit paths. The notification may include information identifying possible one or more transit paths.

The JAB-donor CU 620 may then receive from the JAB-donor CU 610 information relating to one or more possible transit paths corresponding to possible routing paths for routing data packets over at least the TAB node 611 of the first JAB network and at least one TAB node in the second IAB network 691. The information from the IAB-donor CU 610 relating to one or more possible transit paths may include information identifying possible one or more transit paths (e.g. if no such information is sent from the TAB-donor CU 620 in the offload notification) or may include information confirming that the possible one or more transit paths identified by information in the offload notification can be considered. The IAB-donor CU 620 may then determine one or more transit paths corresponding to routing paths for routing data packets over the first JAB network and a second JAB network using the received information relating to one or more possible transit paths. Once the IAB-donor CU 620 has determined the one or more transit paths, the LAB-donor CU 620 may send to the JAB-donor CU 610 information identifying the determined one or more transit paths corresponding to routing paths for routing data packets over at least the JAB node of the first JAB network and at least one JAB node in the second IAB network. The at least one IAB node in the second IAB network may be at least one of the one or more JAB nodes to which the JAB node 612 has established a connection. With the offload notification from the JAB-donor CU (610 or 620), the JAB-donor CUs negotiate or share information to identify (e.g, to both LAB-donor CUs 610 and 620) routing paths that are transit paths which can be considered for routing data packets from one (i.e. 691 or 692) of the JAB networks to another (i.e. 692 or 691) of the IAB networks and the associated Boundary JAB-node(s) (e.g. JAB node 612). In one example, the unique address assigned to the Boundary 1AB-node 612 by the LAB-donor-CU 610 is identified and the unique address assigned to the Boundary IAB-node 612 by the JAB-donor-CU 620 may also be identified. Based on information exchanged with the IAB-donor-CU 620, the IAB-donor CU 610 determines one or more transit paths corresponding to routing paths for data packets over at least one JAB node of the first JAB network and at least one JAB node in the second IAB network, step 1404. The the IAB-donor CU 610 also determines one or more routing paths for data packets over one or more JAB nodes within the first JAB network only (i.e. non-transit paths) as normal and JAB nodes of the first JAB network will be configured with routing configuration information for the non-transit paths as normal.

IAB-donor-CU 610 may provide to all of the IAB nodes within the IAB network 691 (e.g. via the IAB-donor-DU 601 and an intermediate JAB nodes) and which are in the one or more transit paths routing configuration information indicating (e.g. in addition to the normal routing configuration information provided to the respective 1AB nodes for routing paths only within the first JAB network 691 (i.e. non-transit routing paths)) the determined one or more transit paths corresponding to routing paths for data packets over at least the LAB node 612 of the JAB network 691 and at least one JAB node in the second JAB network 692. The JAB-donor CU 620 will also transmit and send to the IAB nodes within the IAB network 692 and which are in the one or more transit paths similar routing configuration information.

In an example, one or more path identifier values of a plurality of path identifier values are assigned to represent one or more transit path identifiers, each one of the one or more path identifier values representing a respective transit path identifier identifying a transit path. The routing configuration information may comprise a routing configuration table with each entry of the routing configuration table having a destination address field for an address of an JAB node and a path identifier field for a path identifier of a routing path to the IAB node (e.g. corresponding to entry 500 of Figure 5a) and path identifier information indicating the one or more path identifier values assigned to the one or more transit path identifiers. The path identifier information may include a transit configuration table with each entry in the transit configuration table including a transit path identifier field for one of the one or more path identifier values assigned to represent the one or more transit path identifiers (e.g. corresponding to the transit table of Figure 7).

In another example, the routing configuration information may includes a routing configuration table with each entry of the routing configuration table having a destination address field for an address of an JAB node, a path identifier field for a path identifier of a routing path to the JAB node and a transit path field for indicating whether the path identifier in the path identifier field is a transit path identifier identifying a transit path (e.g. corresponding to entry 1200 of Figure 12).

Figure 10 illustrates a first exemplary message flow 1000 for managing processing of data packets (e.g. configuring and managing BAP PDU routing over a plurality of JAB networks) according to embodiments and examples of the invention. The first exemplary message flow 1000 described below with reference to Figure 10 is a first example in accordance with the method shown in Figure 14.

An IAB-node 1011 (such as TAB node 612), belonging to a first JAB network (such as 1AB network 691), managed by a first IAB-donor CU 1010 (such as IAB-donor CU 610), may detect a second IAB-node 1021 (such as IAB node 611), belonging to a second IAB network (such as IAB network 692), managed by a second JAB-donor CU 1020 (such as JAB-donor CU 620). When the MT part of JAB-node 1011 is initially connecting to the network, it will perform a cell search procedure, as defined in 3GPP TS 38.300, trying to detect PSS (Primary Synchronization Signal) and SSS (Secondary Synchronization Signal). Based on the System information it will get, the MT unit of 1AB-node 1011 will determine if it can connect to a new cell, i.e. a new JAB-node, such as IAB-node 1021.

If it succeeds to establish connectivity with IAB-node 1021, IAB-node 1011 may notify its IAB-donor CU 1010 that it has established dual connectivity with an IAB-node that belongs to a neighbor JAB network by sending a DUAL CU CONNECTION NOTIFICATION message 1001. In other words, the TAB-node 1011 may transmit a notification to the donor Central Unit, CU, of the first 1AB network, indicating the IAB node 1011 is capable of routing data packets to one or more JAB nodes in the second JAB network (e.g. a transit JAB network). TAB-node 1011 can thus be considered as a Boundary JAB-node, as discussed above with reference to Figure 6, Message 1001 from IAB-node 1011 may embed information that uniquely identifies IAB-node 1021 in the second IAB network. This could be, for instance, an IP address (the one of JAB-donor CU 1020 or the one of TAB-node 1021) or a combination of a BAP address and a unique IAB network identifier.

Upon reception of a DUAL CU CONNECTION NOTIFICATION message 1001, IABdonor CU 1010 may initiate the establishment of transit paths, for example PATH 2 as defined above with reference to Figure 6, by sending an offload notification, such as the OFFLOAD PATH NEGOCIAT1ON REQUEST message 1031, to the IAB-Donor CU 1020.

In one example of an embodiment of the invention, message 1031 is the Measurement report message, as defined in 3GPP TS 38.331 V16.3.1 specification.

The offload notification or message 1031 may include information relating to the one or more TAB nodes in the second JAB network to which the TAB-node 1011 is capable of routing data packets. For example, the message 1031 embeds JAB-node information that identifies IAB-node 1021 as an JAB-node being connected to Boundary node 1011. Such information includes, for instance, the IP address of IAB-node 1021, the IP address of IABnode 1011, the BAP address of IAB-node 1021, the BAP address of IAB-node 1011, or any combination thereof In one example of an embodiment of the invention, message 1031 may include Transit path Information, which may include a list of all the PATH or routing paths currently in use in the first IAB network, or a list of potential Transit paths, which may be used for routing BAP PDUs from the first (resp. second) JAB network to the second (resp. first) IAB network. For example, such as transit path PATH 2 as defined above with reference to Figure 6. It may also include a QoS level associated to the BAP packets to be routed using the Transit paths. It may also include some information related to the nature of the communication, i.e. downstream or upstream.

In one example of an embodiment of the invention, message 1031 may include, in addition to the Transit path Information discussed above, the DESTINATION BAP address of the Destination IAB-node to be reached through a Transit path (for downstream communication).

Upon reception of an OFFLOAD PATH NEGOCIATION REQUEST message 1031, IAB-donor CU 1020 may determine a set of BAP routing paths that allow conveying BAP PDUs through the first JAB network managed by JAB-donor CU 1010 and the second JAB network managed by JAB-donor CU 1020. To do so, IAB-donor CU 1020 selects one or more Transit Paths, for example PATH 2 as defined above with reference to Figure 6. In other words, the IAB-donor CU 1020 may determine one or more transit paths corresponding to routing paths for routing data packets over the first JAB network (such as 691) and the second JAB network (such as 692) by selecting one or more of the transit paths out of the possible transit paths identified (e.g. in the Transit paths proposal).

Then, the IAB-donor CU 1020 sends an OFFLOAD PATH NEGOCIATION RESPONSE message 1032 to the JAB-donor CU 1010.

Message 1032 embeds:transit Routing Infortnation that identifies the determined Transit path(s) that can be considered for routing BAP PDUs from first (resp. second) IAB network to second (resp. first) JAB network along with the associated Boundary JAB-node(s). Such information includes, for instance, a list of Transit Path value(s) (i.e. the values of the path identifiers that assigned to represent transit path identifiers, which identify routing paths as transit paths) associated to Boundary JAB-node 1011.

In one embodiment of the invention, message 1032 may also include a BAP address for JAB-node 1011, to be used by the JAB-nodes of the second JAB network, like JAB-node 1021, to route BAP PDUs to/from the first JAB network. Thus, Boundary JAB node 1011 (such as IAB node 612) may have a first unique address assigned to it by IAB-donor-CU 1010 (such as JAB-donor-CU 610) for use by the first JAB network (such as JAB network 691) and a second unique address assigned to it by IAB-donor-CU 1020 (such as JAB-donor-CU 620) for use by the second IAB network (such as IAB network 692). It may also include ingress and egress BH RLC Channel ID to be used by IAB-node 1011 (to fill in table 510, or 520 as described above with reference to Figure 5).

In one example of an embodiment of the invention, message 1032 may include, in addition to the Transit Routing Information discussed above, the DESTINATION BAP address of the Destination IAB-node to be reached through a Transit path (for upstream communication).

Upon reception of an OFFLOAD PATH NEGOCIATION RESPONSE message 1032, the IAB-donor CU 1010 may determine one or more transit paths using the information received from the IAB-donor CU 1020 in the OFFLOAD PATH NEGOCIATION RESPONSE message 1032 and may configure new entries of the Backhctul Routing Configuration table of the JAB-nodes in the first JAB network, like JAB-node 1011, to configure the transit path(s) negotiated with IAB-donor CU 1020, by sending a CONFIGURATION REQUEST message 1041. For example, the JAB-donor CU 1010 may configure, for example in a transit configuration table such as that described above with reference to Figure 7, routing configuration information indicating the one or more path identifier values assigned to the one or more transit path identifiers, and new entries of the routing configuration table corresponding to entry 500 of Figure 5a or may configure new entries of the routing configuration table corresponding to entry 1200 of Figure 12, Once having transmitted an OFFLOAD PATH NEGOCIATION RESPONSE message 1032, the JAB-donor CU 1020 may configure new entries of the Backhaul Routing Configuration table of the JAB-nodes in the second JAB network, like JAB-node 1021, to configure the transit path(s) negotiated with JAB-donor CU 1010, by sending a CONFIGURATION REQUEST message 1042. For example, the IAB-donor CU 1020 may configure, for example in a transit configuration table such as that described above with reference to Figure 7, routing configuration information indicating the one or more path identifier values assigned to the one or more transit path identifiers, new entries of the routing configuration table corresponding to entry 500 of Figure 5a or to entry 1200 of Figure 12).

Figure 15 illustrates a second exemplary message flow 1500 for managing processing of data packets (e.g. configuring and managing BAP PDU routing over a plurality of JAB networks) according to embodiments and examples of the invention. The second exemplary message flow 1000 is a second example in accordance with the method shown in Figure 14, An IAB-node 1521 (such as JAB node 611), belonging to a first JAB network (such as 10 IAB network 692), managed by a first IAB-donor CU 1520 (such as JAB-donor CU 620), may detect a second IAB-node 1511 (such as IAB node 612), belonging to a second IAB network (such as IAB network 691), managed by a second IAB-donor CU 1020 (such as JAB-donor CU 620). When the MT part of IAB-node 1521 is initially connecting to the network, it will perform a cell search procedure, as defined in 3GPP TS 38.300, trying to detect PSS (Primary Synchronization Signal) and SSS (Secondary Synchronization Signal).

Based on the System information it will get, the MT unit of IAB-node 1521 will determine if it can connect to a new cell, i.e. a new IAB-node, such as IAB-node 1511.

If it succeeds to establish connectivity with IAB-node 1511, IAB-node 1521 may notify its IAB-donor CU 1520 that it has established dual connectivity with an IAB-node that belongs to a neighbor IAB network by sending a DUAL CU CONNECTION NOTIFICATION message 1502. In other words, the IAB-node 1521 may transmit a notification to the donor Central Unit, CU, of the first JAB network, indicating the JAB node 1521 is capable of routing data packets to one or more IAB nodes in the second IAB network. IAB-node 1521 can thus be considered as a Boundary IAB-node, as discussed above with reference to Figure 6.

Message 1502 from IAB-node 1521 may embed information that uniquely identifies IAB-node 1511 in the second JAB network. This could be, for instance, an IP address (the one of JAB-donor CU 1510 or the one of IAB-node 1511) or a combination of a BAP address and a unique JAB network identifier.

Upon reception of a DUAL CU CONNECTION NOTIFICATION message 1502, IAB-donor CU 1520 may initiate the establishment of transit paths, for example PATH 2 as defined above with reference to Figure 6, by sending an offload notification, such as the OFFLOAD PATH NEGOCIATION INFORMATION message 1530, to the JAB-Donor CU 1510. This message is used to notify IAB-donor CU 1510 of the possibility to perform offloading. The offload notification or message 1530 may include information which is similar to the information carried by message 1032 discussed above in Figure 10 except that instead of the Transit Routing Information that is included in message 1032, the offload notification or message 1530 may include a Transit Paths proposal made to JAB-donor CU 1510. For example, the offload notification or message 1530 may include a Transit Paths proposal comprising information identifying possible one or more transit paths. For example, such as transit path PATH 2 as defined above with reference to Figure 6. Alternatively, the offload notification or message 1530 may not include a Transit Paths proposal. The offload notification or message 1530 may include a list of all the PATH or routing paths currently in use in the first JAB network.

Upon reception of an OFFLOAD PATH NEGOCIATION INFORMATION message 1530, IAB-donor CU 1510 responds by sending an OFFLOAD PATH NEGOCIAT1ON REQUEST message 1531, to the JAB-Donor CU 1520.

In one example of an embodiment of the invention, message 1531 is the Measurement report message, as defined in 3GPP TS 38.331 V16.3.1 specification.

The OFFLOAD PATH NEGOCIATION REQUEST message 1531 may include information relating to the one or more possible transit paths corresponding to possible routing paths for routing data packets over at least the JAB node 1521 of the first JAB network and at least one 1AB node (e.g. 1511) in the second IAB network. The information in the OFFLOAD PATH NEGOCIAT1ON REQUEST message 1531 from the IAB-donor CU 1510 relating to one or more possible transit paths may include information identifying possible one or more transit paths (e.g. if no such information is sent from the JAB-donor CU 1520 in the offload notification or message 1530) or may include information confirming that the possible one or more transit paths identified by information in the offload notification can be considered. The OFFLOAD PATH NEGOCIATION REQUEST message 1531 is similar to message 1031 of Figure 10. In such case, the information in the OFFLOAD PATH NEGOCIATION REQUEST message 1531 corresponds to the Transit Path Infarmation which is sent in the message 1031 and as discussed above, the Transit Path Information is either 1) a confirmation of the transit paths proposed in message 1530 or 2) a proposal of Transit paths (as for 1031).

The OFFLOAD PATH NEGOCIATION REQUEST message 1531 may include information relating to the one or more JAB nodes in the second JAB network to which the JAB-node 1521 is capable of routing data packets. For example, the message 1531 embeds JAB-node information that identifies IAB-node 1511 as an IAB-node being connected to Boundary node 1521. Such information includes, for instance, the IP address of JAB-node 1511, the IP address of IAB-node 1521, the BAP address of IAB-node 1511, the BAP address of IAB-node 1521, or any combination thereof In one example of an embodiment of the invention, message 1531 may include, in addition to the Transit path Information discussed above, the DESTINATION BAP address of the Destination JAB-node to be reached through a Transit path (for downstream communication).

Upon reception of an OFFLOAD PATH NEGOCIATION REQUEST message 1531, JAB-donor CU 1520 may determine a set of BAP routing paths that allow conveying BAP PDUs through the first JAB network managed by JAB-donor CU 1520 and the second JAB network managed by IAB-donor CU 1510. To do so, IAB-donor CU 1520 selects one or more Transit Paths, for example PATH 2 as defined above with reference to Figure 6. In other words, the JAB-donor CU 1520 may determine one or more transit paths corresponding to routing paths for routing data packets over the first TAB network (such as 692) and the second JAB network (such as 691) by selecting one or more of the transit paths out of the possible transit paths identified (e.g. in the Transit paths proposal).

Then, the IAB-donor CU 1020 sends an OFFLOAD PATH NEGOCIATION RESPONSE message 1532 to the JAB-donor CU 1510. This message 1532 is similar to the message 1032 of Figure 10.

Message 1532 embeds Transit Routing Information that identifies the determined Transit path(s) that can be considered for routing BAP PDUs from first (resp. second) JAB network to second (resp. first) JAB network along with the associated Boundary JAB-node(s). Such information includes, for instance, a list of Transit Path value(s) (i.e. the values of the path identifiers that assigned to represent transit path identifiers, which identify routing paths as transit paths) associated to Boundary JAB-node 1011.

In one embodiment of the invention, message 1532 may also include a BAP address for JAB-node 1521, to be used by the JAB-nodes of the second JAB network, like JAB-node 1511, to route BAP PDUs to/from the first JAB network. Thus, Boundary JAB node 1521 (such as TAB node 611) may have a first unique address assigned to it by TAB-donor-CU 1020 (such as IAB-donor-CU 620) for use by the first IAB network (such as IAB network 692) and a second unique address assigned to it by JAB-donor-CU 1510 (such as JAB-donorCU 610) for use by the second JAB network (such as JAB network 691). It may also include ingress and egress BH RLC Channel ID to be used by IAB-node 1521 (to fill in table 510, or 520 as described above with reference to Figure 5).

In one example of an embodiment of the invention, message 1532 may include, in addition to the Transit Raiding Information discussed above, the DESTINATION BAP address of the Destination 1AB-node to be reached through a Transit path (for upstream communication).

Upon reception of an OFFLOAD PATH NEGOCIAT1ON RESPONSE message 1532, the JAB-donor CU 1510 may determine one or more transit paths using the information received from the IAB-donor CU 1520 in the OFFLOAD PATH NEGOCIATION RESPONSE message 1532 and may configure new entries of the Backhaul Routing Configuration table of the JAB-nodes in the second JAB network, like IAB-node 1511, to configure the transit path(s) negotiated with JAB-donor CU 1520, by sending a CONFIGURATION REQUEST message 1541. For example, the IAB-donor CU 1510 may configure, for example in a transit configuration table such as that described above with reference to Figure 7, routing configuration information indicating the one or more path identifier values assigned to the one or more transit path identifiers, and new entries of the routing configuration table corresponding to entry 500 of Figure 5a or may configure new entries of the routing configuration table corresponding to entry 1200 of Figure 12.

Once having transmitted an OFFLOAD PATH NEGOCIATION RESPONSE message 1532, the IAB-donor CU 1520 may configure new entries of the Backhaul Routing Configuration table of the IAB-nodes in the first IAB network, like 1AB-node 1521, to configure the transit path(s) negotiated with 1AB-donor CU 1510, by sending a CONFIGURATION REQUEST message 1542. For example, the IAB-donor CU 1520 may configure, for example in a transit configuration table such as that described above with reference to Figure 7, routing configuration information indicating the one or more path identifier values assigned to the one or more transit path identifiers, new entries of the routing configuration table corresponding to entry 500 of Figure 5a or to entry 1200 of Figure 12).

The second exemplary message flow shown in Figure 15 may be used when a transit JAB network initiates inter-CU negotiations to establish transit paths between two JAB networks. In such a case, the transit network is the first IAB network and the other JAB network (non-transit network) is the second JAB network such that data packets are re-routed from the second IAB network (non-transit network) through the first IAB network (transit network).

In one example of an embodiment of the invention, the CONFIGURATION REQUEST message 1041 (resp. 1042) and 1541 (resp. 1542) is a BAP MAPPING CONFIGURATION message, as described in 3GPP TS 38.473 v16.4.0.

In one example of an embodiment of the invention, messages 1001, 1041 and 1042 and messages 1502, 1541 and 1542 are RRC messages, as defined in 3GPP TS 38 331 V16.3.1 specification.

In one example of an embodiment of the invention, messages 1031 and 1032 and messages 1530, 1531, and 1532 are Xn-C messages, as defined in 3GPP TS 38.420

specification.

In the context of inter-topology BAP routing (e.g. inter-JAB network BAP routing), one may observe that, since assignment of BAP addresses, BAP path IDs and BH RLC CH IDs is managed independently in each topology (e.g. each JAB network), the same values may be reused. This may lead to collisions among BAP addresses, BAP path IDs and BH RLC CH IDs when performing BAP routing across two topologies.

For instance, if a Boundary IAB-node of a first IAB network has the same address as an JAB-node in the second JAB network, when the Boundary JAB-node receives a BAP PDU with a header that includes a destination BAP address that matches the address of the Boundary 1AB-node (and hence the address of the 1AB-node in the second 1AB network), the Boundary node will not be able to decide whether the BAP PDU is for the Boundary JAB-node and so has to be forwarded to upper layers or is intended for the IAB-node in the second JAB network and so has to forwarded to the next hop.

Therefore, one may observe that the BAP address cannot be used to differentiate between any two destination nodes.

BAP address space may be split into different partitions through a CU identifier, or separate sets of BH RLC channels may be introduced to prevent any routing ambiguity. However, such solutions require the coordination of the different donor-CUs through a standardized signalling, as well as the need of JAB-nodes reconfiguration when a conflict is detected in the allocation of addresses or IDs. Besides, extending the BAP header (e.g. for CU-related identifier addition purpose) to allow topology differentiation would create BAP packet overhead.

To overcome the aforementioned drawbacks, a solution is to let the BAP addresses, BAP path IDs and BH RLC CH IDs be assigned independently in each topology while the boundary node holds a mapping table, which maps the BAP routing ID from one topology to the BAP routing ID in the other topology. Then, the BAP routing LD carried on the BAP header is rewritten by the boundary node when a BAP PDU crosses the boundary node from one topology to the other. The disadvantage of this approach is that it requires the boundary IAB node to perform significant processing to re-write the BAP headers.

More generally speaking, one may observe that BAP header re-writing would require extra processing and complexity at boundary node To solve the above issues, it is proposed to rely on dedicated path identifiers, referred to as Transit path identifiers, to be specifically used for routing BAP packets across two topologies.

When determining that the routing path in a BAP packet header is a Transit path, i.e. is to be routed through two JAB networks, an JAB-node would route this BAP packet regardless of the Destination address in the BAP packet header.

In order to prevent inappropriate re-routing that would result from an address collision (e.g. a relay JAB-node in a first topology has the same address as the actual destination JAB-node in a second topology), an IAB-node would parse its BAP routing configuration table, based on the Path ID in the BAP packet header, to determine whether a received BAP packet is to be relayed or sent to the upper layers.

Two options are proposed hereafter which illustrate how the use of Transit paths could allow BAP routing across two topologies, without having the need for any BAP header re-writing.

Option 1 As illustrated in Figure 17, the JAB-donor 1, in charge of JAB topology 1, wishes to offload some BAP packets, destined to IAB-node 4, by routing them through the IAB-donor 2, in charge of IAB topology 2. To do so, the BAP packet header has its Destination field value set to -A4", which is the address of JAB-node 4, and its Path field value set to "Transit Path ID 1" value by JAB-donor 2. Thus, no additional field is required in the BAP header format to notify a transit path.

In the following, JAB-node 2, belonging to JAB topology 2, has been assigned the same address "A4" as JAB-node-4, which belongs to JAB topology J. IAB-node 2, upon reception of the BAP packet, identifies that a Transit Path, i.e. Transit Path ID 1, is used to route the packet. Therefore, it does not consider the Destination field in the BAP header, but rather checks for the entry in the BAP routing configuration table which Path 1D field matches "Transit Path ID 1". This entry indicates that the packet should be forwarded to IAB-node 3, which BAP address "A5" (in IAB topology 2) matches

the Next hop BAP address field in the table.

Boundary JAB-node 3, upon reception of the BAP packet, identifies that a Transit Path, i.e. Transit Path ID I, is used to route the packet. Therefore, it performs the same operation as IAB-node 2 did previously and forwards the BAP packet to IAB-node 4, which BAP address "A4-matches the Next hop BAP address field in its BAP routing configuration table JAB-node 4, upon reception of the BAP packet, identifies that a Transit Path, i.e. Transit Path ID 1, is used to route the packet. Therefore, IAB-node 4 checks for the entry in the BAP routing configuration table which Path ID field matches "Transit Path ID 1". As it finds no entry, IAB-node 4 checks the Destination field in the BAP header and, as it matches its own BAP address value, deduces that it should send the BAP packet to its upper layers.

According to Option 1, no header rewriting is needed at boundary node.

According to Option 1, no configuration is specific to the boundary node.

The method described above with reference to Figure 8 is an example of Option 1, Option 2 As illustrated in Figure 18, the IAB-donor 1, in charge of IAB topology 1, wishes to offload some BAP packets, destined to IAB-node 4, by routing them through the JAB-donor 2, in charge of JAB topology 2. To do so, the BAP packet header has its Destination field value set to "A4", which is the address of 1AB-node 4, and its Path field value set to "Transit Path ID 1" by IAB-donor 2.

In the following, IAB-node 2, belonging to IAB topology 2, has been assigned the same address "A4" as JAB-node-4, which belongs to JAB topology 1.

IAB-node 2, upon reception of the BAP packet, identifies that a Transit Path, i.e. Transit Path ID 1, is used to route the packet. It also detects that its own BAP address "A4" matches the Destination field value in the BAP header.

JAB-node 2 checks for the entry in the BAP routing configuration table which Path ID field matches "Transit Path ID I". As the Destination field in this entry (i.e. "A5") does not match its own BAP address, JAB-node 2 understands that the packet should be forwarded to IAB-node 3, which BAP address "A.5" (in TAB topology 2) matches the Next hop BAP address field in the table.

Boundary IAB-node 3, upon reception of the BAP packet, identifies that a Transit Path, i.e. Transit Path ID 1, is used to route the packet. As the Destination field "A4" in the BAP header does not match its own BAP address "AS", JAB-node 3 checks for the entry in its BAP routing configuration table which Path ID field matches "Transit Path ID I". This entry indicates that the packet should be forwarded to JAB-node 4, which BAP address "A4" matches the Next hop BAP address field in the table.

IAB-node 4, upon reception of the BAP packet, identifies that a Transit Path, i.e Transit Path ID 1, is used to route the packet It also detects that its own BAP address "A4" matches the Destination field value in the BAP header.

IAB-node 4 checks for the entry in the BAP routing configuration table which Path ID field matches "Transit Path ID 1". As the Destination field in this entry (i.e. "A4") matches its own BAP address (and thus the Destination field value in the BAP header), IAB-node 4 deduces that it should send the BAP packet to its upper layers.

According to Option 2, no header rewriting is needed at boundary node According to Option 2, no specific configuration is needed at boundary node The method described above with reference to Figure 9 is an example of Option 2 Figure 11 shows a schematic representation of an example communication device or station, in accordance with one or more embodiments and examples of the present disclosure.

The communication device 1100 may preferably be a device such as a micro-computer, a workstation or a light portable device The communication device 1100 comprises a communication bus 1113 to which there are preferably connected: -a central processing unit 1111, such as a microprocessor, denoted CPU; -memory for storing data and computer programs containing instructions for the operation of the communication device 1100. The computer programs may contain a number of different program elements or sub-routines containing instructions for a variety of operations and for implementing the invention. For example, the program elements include an element to implement a BAP entity which as discussed above is for routing of data packets between different network nodes in the LAB network; and -at least one communication interface 1102 connected to the radio communication network 100 over which digital data packets or frames or control frames are transmitted, for example a wireless communication network according to the release 16 for 5G NR. The frames are written from a FIFO sending memory in RAM 1112 to the network interface for transmission or are read from the network interface for reception and writing into a FIFO receiving memory in RAM 1112 under the control of a software application running in the CPU 1111, Each of a donor CU, an IAB network node and a donor DU may comprise such a communication device 1100.

The central processing unit 1111 may be a single processor or may comprise two or more processors carrying out the processing required for the operation of the communication device 1100. The number of processors and the allocation of processing functions to the central processing unit 1111 is a matter of design choice for a skilled person.

The memory may include: -a read only memory 1107, denoted ROM, for storing computer programs for implementing the invention; -a random-access memory 1112, denoted RAM, for storing the executable code of methods according to one or more embodiments of the invention as well as the registers adapted to record variables and parameters necessary for implementing methods according to one or more embodiments of the invention.

Optionally, the communication device 1100 may also include the following components: - a data storage means 1104 such as a hard disk, for storing computer programs for implementing methods according to one or more embodiments of the invention; - a disk drive 1105 for a disk 1106, the disk drive being adapted to read data from the disk 1106 or to write data onto said disk; - a screen 1109 for displaying decoded data and/or serving as a graphical interface with the user, by means of a keyboard 1110 or any other pointing means. Preferably the communication bus provides communication and interoperability between the various elements included in the communication device 1100 or connected to it.

The representation of the bus is not limiting and in particular, the central processing unit is operable to communicate instructions to any element of the communication device 1100 directly or by means of another element of the communication device 1100.

The disk 1106 may optionally be replaced by any information medium such as for example a compact disk (CD-ROM), rewritable or not, a ZIP disk, a USB key or a memory card and, in general terms, by an information storage means that can be read by a microcomputer or by a microprocessor, integrated or not into the apparatus, possibly removable and adapted to store one or more programs whose execution enables a method according to embodiments of the invention to be implemented.

The executable code may optionally be stored either in read only memory 1107, on the hard disk 1104 or on a removable digital medium such as for example a disk 1106 as described previously. According to an optional variant, the executable code of the programs can be received by means of the communication network 1103, via the interface 1102, in order to be stored in one of the storage means of the communication device 1100, such as the hard disk 1104, before being executed.

The central processing unit 1111 is preferably adapted to control and direct the execution of the instructions or portions of software code of the program or programs according to the invention, which instructions are stored in one of the aforementioned storage means. On powering up, the program or programs that are stored in a non-volatile memory, for example on the hard disk 1104 or in the read only memory 1107, are transferred into the random-access memory 1112, which then contains the executable code of the program or programs, as well as registers for storing the variables and parameters necessary for implementing the invention.

In an embodiment, the apparatus is a programmable apparatus which uses software to implement the invention. However, alternatively, the present invention may be implemented in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC).

Claims

Claims 1. A method for processing data packets at an integrated access and backhaul, TAB, node of an TAB network comprising a plurality of TAB nodes, the method comprising: receiving a data packet including a destination address of a destination IAB node for the data packet and a path identifier identifying a routing path for the data packet to the destination TAB node; determining, based on the received data packet, whether the routing path of the received data packet includes at least one TAB node of a different TAB network; in response to determining that the routing path of the received data packet includes at least one IAB node of a different IAB network, using the path identifier of the received data packet to determine whether there is a next IAB node in the routing path for routing the data packet, when a next TAB node is determined, routing the data packet to the next TAB node.
2 The method of claim 1, wherein the destination address of the received data packet is not used to determine whether there is a next IAB node for routing the data packet.
3. The method of claim 1 or claim 2, further comprising receiving configuration information including a routing configuration table, each entry of the routing configuration table having a destination address field for an address of an TAB node and a path identifier field for a path identifier of a routing path to the TAB node, wherein determining whether there is a next IAB node for routing the data packet using the path identifier of the received data packet comprises comparing the path identifier of the received data packet with the path identifier field of the routing configuration table, when the path identifier of the received data packet matches a path identifier in the path identifier field, determining there is a next TAB node 4.
The method of claim 3, wherein when the path identifier of the received data packet does not match a path identifier in the path identifier field, determining there is not a next IAB node, wherein the method further comprises comparing the destination address of the received data packet with an address assigned to the TAB node, and when the destination address of the received data packet matches the address assigned to the TAB node, determining the JAB node is the destination IAB node.
The method of claim 1 or claim 2, further comprising receiving configuration information including a routing configuration table, each entry of the routing configuration table having a destination address field for an address of an JAB node and a path identifier field for a path identifier of a routing path to the I AB node, wherein determining whether there is a next JAB node for routing the data packet using the path identifier of the received data packet comprises comparing the path identifier of the received data packet with the path identifier field of the routing configuration table, when the path identifier of the received data packet matches a path identifier in the path identifier field of an entry in the routing configuration table and when an address assigned to the IAB node does not match the address of the IAB node in the destination address field of the entry, determining there is a next LAB node.
6 The method of claim 5, wherein when the path identifier of the received data packet matches a path identifier in the path identifier field of an entry in the routing configuration table and when the destination address of the received data packet matches the address of the IAB node and the address in the destination address field of the entry, determining there is not a next JAB node and the JAB node is the destination TAB node.
7. The method of any one of the preceding claims, wherein determining whether the routing path of the received data packet includes at least one JAB node of a different JAB network comprises determining, based on the path identifier of the received data packet, whether the routing path of the received data packet includes at least one IAB node of a different IAB network.
8. The method of claim 7, wherein one or more path identifier values of a plurality of path identifier values are assigned to represent one or more transit path identifiers, each one of the one or more path identifier values representing a respective transit path identifier identifying a transit path, wherein a transit path is a routing path including at least one JAB node of a different IAB network.
9. The method of claim 8, further comprising: receiving, from a donor Central Unit of the JAB network, routing configuration information indicating the one or more path identifier values assigned to the one or more transit path identifiers.
The method of claim 9, wherein the routing configuration information includes a transit configuration table, each entry in the transit configuration table including a transit path identifier field for one of the one or more path identifier values assigned to represent the one or more transit path identifiers.
11. The method of claim 10, wherein each entry of the transit table further includes a target IAB information field for indicating whether the destination IAB node for a data packet routed using the transit path identified by the transit path identifier in the transit path identifier field of the entry is in the IAB network of the JAB node or if the destination JAB node is part of a different IAB network.
12. The method of any one of claims 8 to 11, wherein determining whether the routing path of the received data packet is a transit path comprises comparing the path identifier of the received data packet with the one or more path identifier values and when the path identifier matches one of the one or more path identifier values, determining that the routing path of the received data packet is a transit path.
13. The method of any one of claims 3 to 7, wherein each entry of the routing configuration table further includes a transit path field for indicating whether the path identifier in the path identifier field is a transit path identifier identifying a transit path, wherein a transit path is a routing path including at least one TAB node of a different JAB network.
14. The method of claim 13, wherein determining whether the routing path of the received data packet is a transit path comprises comparing the path identifier of the received data packet with the path identifier field of the routing configuration table, and when the path identifier of the received packet matches a path identifier in the path identifier field of an entry with a value in the transit path field indicating the path identifier is a transit path identifier, determining that the routing path of the received data packet is a transit path.
15. The method of any one of claim 1 to 6, wherein the data packet comprises a header including the path identifier and at least one bit configured to indicate whether the path identifier of the data packet is a transit path identifier identifying a transit path, wherein a transit path is a routing path including at least one IAB node of a different IAB network.
16 The method of claim 15, wherein the header includes a path identifier field for the path identifier of the data packet, wherein the at least one bit is at least one bit of the path identifier field or wherein the at least one bit is at least one reserved bit of the header.
17. The method of any one of the preceding claims, wherein the JAB node is capable of routing data packets to one or more JAB nodes in the JAB network of the JAB node and to one or more IAB nodes in at least one different IAB network.
18. The method of claim 17, wherein the JAB node is assigned a first unique address for use by the IAB network of the IAB node and a second unique address for use by the at least one different IAB network.
19 The method of claim 17 or claim 18, further comprising sending a notification to a donor Central Unit, CU, of the 1AB network, indicating the 1AB node is capable of routing data packets to one or more IAB nodes in the at least one different JAB network.
20. A method for managing processing of data packets in a first integrated access and backhaul, IAB, network comprising a donor Central Unit, CU and a plurality of IAB nodes, each IAB node being assigned a unique address, the method at the donor CU comprising: determining one or more transit paths corresponding to routing paths for routing data packets over the first TAB network and a second JAB network; providing, to at least one I AB node of each transit path of the one or more transit paths, routing configuration information relating to the determined one or more transit paths corresponding to routing paths for routing data packets over at least the at least one JAB node of the first IAB network and at least one IAB node in the second IAB network.
21 The method of claim 20, further comprising: receiving, from one JAB node of the plurality of JAB nodes, a notification indicating the IAB node is capable of routing data packets to one or more IAB nodes in the second IAB network; sending, to a second donor CU of the second JAB network, an offload notification to establish the one or more transit paths, the notification including information relating to the one or more IAB nodes in the second IAB network; receiving, from the second donor CU, information identifying one or more transit paths corresponding to routing paths for routing data packets over at least the JAB node of the first 1AB network and at least one 1AB node in the second 1AB network, wherein determining one or more transit paths corresponding to routing paths for routing data packets over the first IAB network and a second IAB network comprises determining one or more transit paths using the received information identifying one or more transit paths
22. The method of claim 20, further comprising: receiving, from one JAB node of the plurality of JAB nodes, a notification indicating the 10 IAB node is capable of routing data packets to one or more JAB nodes in the second JAB network; sending, to a second donor CU of the second IAB network, an offload notification to establish the one or more transit paths receiving, from the second donor CU, information relating to one or more possible transit paths corresponding to possible routing paths for routing data packets over at least the 1AB node of the first JAB network and at least one JAB node in the second JAB network; wherein determining one or more transit paths corresponding to routing paths for routing data packets over the first JAB network and a second JAB network comprises determining one or more transit paths using the received information relating to one or more possible transit paths, the method further comprising: sending, to the second donor CU, information identifying the determined one or more transit paths corresponding to routing paths for routing data packets over at least the JAB node of the first IAB network and at least one IAB node in the second IAB network.
23. The method of claim 21 or claim 22, wherein the offload notification further includes information identifying routing paths currently in use for data packets over the first IAB network and/or information identifying possible one or more transit paths
24. The method of any one of claims 20 to 23, wherein one or more path identifier values of a plurality of path identifier values are assigned to represent one or more transit path identifiers, each one of the one or more path identifier values representing a respective transit path identifier identifying a transit path, wherein the routing configuration information includes: a routing configuration table, each entry of the routing configuration table having a destination address field for an address of an JAB node and a path identifier field for a path identifier of a routing path to the 1AB node; path identifier information indicating the one or more path identifier values assigned to the one or more transit path identifiers.
25. The method of claim 24, wherein the path identifier information includes a transit configuration table, each entry in the transit configuration table including a transit path identifier field for one of the one or more path identifier values assigned to represent the one or more transit path identifiers.
26. The method of claim 25, wherein each entry of the transit table further includes a target JAB information field for indicating whether the destination JAB node for a data packet routed using the transit path identified by the transit path identifier in the transit path identifier field of the entry is in the 1AB network of the 1AB node or if the destination JAB node is part of a different JAB network.
27. The method of any one of claims 20 to 23, wherein the routing configuration information includes: a routing configuration table, each entry of the routing configuration table having a destination address field for an address of an JAB node, a path identifier field for a path identifier of a routing path to the TAB node and a transit path field for indicating whether the path identifier in the path identifier field is a transit path identifier identifying a transit path.
28. The method of any one of claims 3-6, 13, 14, 24-27, wherein each entry of the routing configuration table further includes a next-hop address field for the unique address of a node in the TAB network that is a next node in the routing path
29. An Integrated access and backhaul, JAB, node for an JAB network, the JAB node comprising: at least one communication interface for communicating with at least one JAB node; a central processing unit coupled to the at least one communication interface and configured to perform the method as recited in any one of claims I to 19.
30. A donor Central Unit, CU, for managing processing of data packets in an integrated access and backhaul, JAB, network comprising a plurality of JAB nodes, the donor CU comprising: at least one communication interface; a central processing unit coupled to the at least one communication interface and configured to perform the method as recited in any one of claims 20 to 28.