WO2023046878A1 - Routage de données dans un réseau d'accès et de liaison terrestre intégrés - Google Patents

Routage de données dans un réseau d'accès et de liaison terrestre intégrés Download PDF

Info

Publication number
WO2023046878A1
WO2023046878A1 PCT/EP2022/076469 EP2022076469W WO2023046878A1 WO 2023046878 A1 WO2023046878 A1 WO 2023046878A1 EP 2022076469 W EP2022076469 W EP 2022076469W WO 2023046878 A1 WO2023046878 A1 WO 2023046878A1
Authority
WO
WIPO (PCT)
Prior art keywords
iab
routing
topology
node
identifier
Prior art date
Application number
PCT/EP2022/076469
Other languages
English (en)
Inventor
Pierre Visa
Pascal Lagrange
Original Assignee
Canon Kabushiki Kaisha
Canon Europe Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from GB2113679.1A external-priority patent/GB2611068A/en
Priority claimed from GB2118319.9A external-priority patent/GB2611120B/en
Application filed by Canon Kabushiki Kaisha, Canon Europe Limited filed Critical Canon Kabushiki Kaisha
Priority to KR1020247012356A priority Critical patent/KR20240068689A/ko
Priority to CN202280064433.6A priority patent/CN118020344A/zh
Publication of WO2023046878A1 publication Critical patent/WO2023046878A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/22—Alternate routing

Definitions

  • the present invention generally relates to routing data and managing routing of data in an integrated access and backhaul, IAB, network of a wireless communication system.
  • 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).
  • BH backhaul
  • wireless multiple-access communication systems examples include systems based on 3rd generation partnership project (3GPP - RTM) standards, such as fourthgeneration (4G) Long Term Evolution (LTE) or recent fifth-generation (5G) New Radio (NR) systems, or systems-based IEEE 802.11 standards, such as WiFi.
  • 3GPP - RTM 3rd generation partnership project
  • 4G fourthgeneration
  • LTE Long Term Evolution
  • 5G New Radio
  • IEEE 802.11 such as WiFi.
  • 3GPP has proposed, in recent release 16 for 5GNR, 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 (between base stations) may use the same radio resources as access communications (between a base station and UEs).
  • IAB 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.
  • IAB is most likely to operate in the millimeter wave (mmWave) band to achieve the required Gbps (gigabits per second) data rate.
  • a topological redundancy can be provided within the IAB framework, where multiple data paths are set up between the IAB base station directly connected to the core network (also referred to as the “IAB-donor”) and the IAB base station serving a UE (also referred to as the “access lAB-node” for the UE).
  • intermediate IAB base stations also referred to as lAB-nodes
  • IAB-donor Several intermediate IAB base stations (also referred to as lAB-nodes) may be involved in each of the several paths between the IAB-donor and the access lAB-node, thus forming alternative data paths within a multi-hop IAB network.
  • a path through a set of lAB-nodes is defined by default along which the data are preferably transmitted. Also, one or more back-up paths along different sets of lAB-nodes are defined that can be used in case a radio link failure (RLF) occurs on any link of the default path.
  • RLF radio link failure
  • a link is defined between two successive lAB-nodes in the backhaul network.
  • a backup 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.
  • the IAB-donor consists of a central unit (CU or gNB-CU functionality) and of one or more distributed unit(s) (DU or gNB-DU functionality).
  • Each lAB-node (including an access lAB-node) coupled directly or indirectly to the IAB-donor comprises an IAB-MT (lAB-Mobile Termination) to communicate in the upstream direction toward the IAB-donor and an IAB-DU (IAB -Distributed Unit) to communicate in the downstream direction toward the UEs.
  • IAB-MT lAB-Mobile Termination
  • IAB-DU IAB -Distributed Unit
  • BAP backhaul adaptation protocol
  • 3GPP release 16 specification TS 38.340 version 16.3.0
  • 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 IP 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 lAB-donor-DU (in the downstream direction) or the initiator lAB-node (in the upstream direction).
  • BAP PDUs are routed according to the BAP Routing ID using a backhaul routing table configured by the IAB- donor-CU in each lAB-node and in each lAB-donor-DU.
  • the destination BAP address is compared to the local BAP address. If the local address matches with the destination BAP address, the BAP header is removed and the payload is delivered to the upper layers.
  • the BAP PDU is discarded.
  • 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.
  • the 3 GPP release 16 specifications do not allow to re-route BAP PDUs in upstream direction towards a different lAB-donor-DU, even though several lAB-donor-DUs provide a connection to the same lAB-donor-CU.
  • the destination BAP address of BAP PDUs corresponds to one of the several lAB-donor-DUs available.
  • an lAB-node may find an alternative path in its routing table to reach the lAB-donor-DU targeted by the destination BAP address, but it has no information to identify an alternative lAB-donor-DU that could be reached through an alternative path.
  • this latter would discard the BAP PDU as the destination BAP address would not match its own BAP address.
  • 3 GPP has been considering inter-donor redundancy, where an lAB-node, referred to as a Boundary IAB node, can access two different parent nodes connected to two different lAB-donor CUs.
  • the Boundary lAB-node even though belonging to a single IAB 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 lAB-donor CU to a second IAB network managed by a second lAB-donor CU.
  • interdonor redundancy lies in the ability for the first lAB-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 IAB network.
  • BAP addresses, BAP path IDs and Backhaul Radio Link Control Channel Identifiers (BH RLC CH IDs) is performed independently in each IAB network, the same values may be assigned in each topology, e.g. an lAB-node belonging to the first IAB network may be assigned the same address as an lAB-node belonging to the second IAB network, which may lead to significant routing issues.
  • Boundary lAB-node of a first IAB network has the same address as an lAB-node in the second IAB network
  • the Boundary lAB-node receives a BAP PDU with a header that includes a destination BAP address that matches the address of the Boundary lAB-node (and hence the address of the lAB-node in the second IAB network)
  • the Boundary node will not be able to decide whether the BAP PDU is for the Boundary lAB-node and so has to be forwarded to upper layers or is intended for the lAB-node in the second IAB network and so has to forwarded to the next hop.
  • an lAB-node may re-route a BAP PDU to the wrong destination lAB-node.
  • a method for processing data packets at an integrated access and backhaul, IAB, node in an IAB communication system comprising at least two IAB topologies and each IAB topology comprising a plurality of IAB nodes, the method comprising: receiving a data packet, the data packet including a routing identifier; determining whether the routing identifier is to be updated before transmitting the data packet to another IAB node, in response to determining that the routing identifier is to be updated: identifying, based on header rewriting configuration information and the routing identifier of the received data packet, a new routing identifier and an associated IAB topology; updating the received data packet by updating the routing identifier of the received data packet with the identified new routing identifier to provide an updated data packet including the identified new routing identifier; determining, based on routing configuration information associated with the identified IAB topology and the identified new routing identifier, an egress backhaul link over which the data packet is to
  • 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 (IAB) networks or one or more IAB topologies and thus, allows for the re-routing of data packets from a first IAB network (also referred to as a first IAB topology) to a second IAB network (also referred to as a second IAB topology).
  • BAP backhaul adaptation protocol
  • PDUs protocol data units
  • processing resources and processing time can be saved at the IAB node when processing data packets for routing in the IAB communication system by avoiding the IAB node having to parse unnecessarily all of the information of the routing configuration information and/or routing identifier mapping information (e.g. parsing unnecessarily all of the routing identifiers in the routing identifier mapping information and/or the routing configuration information when no match will be found for the corresponding routing identifier).
  • An example arrangement has an update (or rewrite) indication (such as an update field or destination address field for each entry of a routing configuration table) for each routing identifier in the routing configuration information to indicate whether the routing identifier is to be updated or not.
  • update or rewrite
  • This enables the IAB node to determine whether the routing identifier is to be updated or not without first having to parse all the information in the routing configuration information and checking whether there is an available egress backhaul link for each possible routing option.
  • the IAB node has flexibility to update the routing identifier of received data packets based on current radio conditions and congestion (i.e. to optimise the routing of data packets based on current conditions).
  • the IAB node may disable an update indication for this routing identifier in the routing configuration information, and thus save some processing time when routing the next data packets with the same routing identifier.
  • the received data packet is a Backhaul Adaptation Protocol, BAP, data packet comprising a BAP header including the routing identifier.
  • the header rewriting configuration information (also referred to as routing identifier mapping information) may comprise a header rewriting configuration table including a field for indicating the IAB topology associated with the new routing identifier.
  • the received data packet is a Backhaul Adaptation Protocol, BAP
  • data packet comprising a BAP header including the routing identifier and the routing configuration information comprises a backhaul routing configuration table including a field for indicating whether the BAP routing identifier of the received data packet is to be updated.
  • BAP Backhaul Adaptation Protocol
  • the routing identifier mapping information may comprise a routing identifier mapping table including a field for indicating the IAB topology associated with the BAP routing identifier to be updated and/or a field for indicating the IAB topology associated with the new routing identifier.
  • the backhaul RLC channel matching the required QoS can be selected and used by the IAB node to route the data packet to the next IAB node for the egress backhaul link irrespective of whether the next IAB node is in the same IAB topology as the IAB node or a different IAB topology.
  • backhaul RLC channel mapping configuration table including fields for indicating the topology, mitigates routing issues arising due to the independent assignment of BAP addresses, BAP path IDs and Backhaul Radio Link Control Channel Identifiers (BH RLC CH IDs) in each IAB network where the same values may be assigned in each topology.
  • BAP addresses BAP path IDs
  • BH RLC CH IDs Backhaul Radio Link Control Channel Identifiers
  • determining whether the updated data packet is to be delivered to upper layers i.e. by performing a determination whether the data packet is to be delivered to upper layers after the received data packet is updated or rewritten by updating the routing identifier of the received data packet with the determined new routing identifier to provide the updated data packet
  • a check can be made to determine whether the updated data packet has reached its destination and should be delivered to the upper layers. If no check is made after the received data packet is updated or rewritten, then data packets may be discarded even when they have reached their correct destination.
  • an apparatus of an integrated access and backhaul, IAB, node as recited in claim 40.
  • an Integrated access and backhaul, IAB, node as recited in claim 50.
  • a donor Central Unit, CU as recited in claim 51.
  • an apparatus of a donor Central Unit, CU of an integrated access and backhaul, IAB, communication system comprising at least two IAB topologies, each IAB topology comprising a plurality of IAB nodes and a donor Central Unit, CU.
  • the apparatus comprises a processing unit and a memory operably connectable to the processing unit and for storing instructions which, when executed by the processing unit, configure the processing unit to: provide, for at least one IAB node of the first IAB topology, data packet routing configuration information for routing data packets over at least the first IAB topology, wherein the data packet routing configuration information comprises a routing configuration table and a header rewriting configuration table, wherein the routing configuration table comprises at least one entry including: a routing identifier field for a routing identifier, the routing identifier field comprising 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 IAB node; a next hop address field for indicating an address of a next IAB node in the routing path identified by the path identifier, wherein header rewriting configuration table comprises at least one entry including: a previous routing identifier field for a routing identifier; a new routing identifier field for a routing
  • an apparatus of a donor Central Unit, CU of an integrated access and backhaul, IAB, communication system comprising at least two IAB topologies, each IAB topology comprising a plurality of IAB nodes and a donor Central Unit, CU.
  • the apparatus comprises a processing unit and a memory operably connectable to the processing unit and for storing instructions which, when executed by the processing unit, configure the processing unit to: provide, for at least one IAB node of the first IAB topology, data packet routing configuration information for routing data packets over at least the first IAB topology, wherein the data packet routing configuration information comprises a header rewriting configuration table, the header rewriting configuration table including a field for indicating the IAB topology associated with the new routing identifier.
  • an apparatus of a donor Central Unit, CU of an integrated access and backhaul, IAB, communication system comprising at least two IAB topologies, each IAB topology comprising a plurality of IAB nodes and a donor Central Unit, CU.
  • the apparatus comprises a processing unit and a memory operably connectable to the processing unit and for storing instructions which, when executed by the processing unit, configure the processing unit to: provide, for at least one IAB node of the first IAB topology, data packet routing configuration information for routing data packets over at least the first IAB topology, wherein the data packet routing configuration information comprises a backhaul RLC channel mapping configuration table having at least one entry including: a next hop address field for a next hop address of a next IAB node that is next to the at least one IAB node in a routing path, an egress topology field for indicating the IAB topology associated with the next IAB node, and for indicating with the next hop address field an egress backhaul link between the IAB node and the next IAB node, an egress backhaul RLC channel identifier field for a backhaul RLC channel identifier of a backhaul RLC channel for the egress backhaul link; and/or a prior hop address field for
  • an apparatus of a first donor Central Unit, CU of an integrated access and backhaul, IAB, communication system comprising at least two IAB topologies, each IAB topology comprising a plurality of IAB nodes and a donor Central Unit, CU.
  • the apparatus comprises a processing unit and a memory operably connectable to the processing unit and for storing instructions which, when executed by the processing unit, configure the processing unit to: provide, for sending to a second donor CU of a second IAB topology of the at least two IAB topologies, a request for establishing routing of data packets between the first IAB topology and the second IAB topology; receiving a response, from the second donor CU, the response including acknowledgement information indicating whether the second donor CU has accepted the request and when the second donor CU has accepted the request, configuration information relating to one or more IAB nodes in the second IAB topology for identifying routing paths for routing data packets between at least one IAB node of the first IAB topology and at least one IAB node in the second IAB topology, wherein the request comprises at least one of the following Information Elements, IE: an IE identifying a routing direction for the request, when the routing direction is upstream, the request relates to routing data packets from the first IAB topology to the
  • Figure l is a schematic diagram illustrating an example wireless communication system in which the present invention may be implemented according to one or more embodiments;
  • Figures 2a and 2b are schematic diagrams illustrating stacks of some protocol layers involved in IAB operations
  • FIG. 3 is a schematic diagram illustrating the format of a BAP Protocol Data Unit (PDU) or packet;
  • PDU Protocol Data Unit
  • Figure 4 is a schematic diagram illustrating the routing management in an IAB network
  • Figures 5a-d illustrate fields of routing tables in lAB-nodes according to 3GPP TS 38.300;
  • Figure 6 is a schematic diagram illustrating an example arrangement of an IAB network system presenting network path diversity in which the present invention may be implemented according to one or more embodiments;
  • Figure 7 illustrates an example of fields of a routing configuration table at an lAB-node according to embodiments of the invention
  • Figure 8 illustrates an example of fields of a routing identifier (Routing ID) mapping configuration table at an lAB-node according to embodiments of the invention
  • Figure 9a illustrates an example of fields of a backhaul (BH) RLC Channel mapping configuration table at an lAB-node according to embodiments of the invention
  • Figure 9b illustrates an example of fields of an Uplink Traffic to BH RLC Channel mapping configuration table at an lAB-node according to embodiments of the invention
  • Figure 10 illustrates, using a flowchart, an example method for managing BAP PDU routing over a plurality of IAB networks (or IAB topologies) according to embodiments of the invention
  • FIG. 11 is a block schematic diagram of an example wireless communication device in accordance with embodiments of the present invention.
  • Figure 12 is a schematic and simplified diagram illustrating an example message flow for managing BAP PDU routing over a plurality of IAB networks according to embodiments of the invention
  • Figure 13 illustrates, using a flowchart, an example method for processing data packets at an IAB node in an IAB system comprising a plurality of IAB networks (or IAB topologies) according to a first embodiment of the invention
  • Figure 14 illustrates, using a flowchart, an example method for processing data packets at an IAB node in an IAB system comprising a plurality of IAB networks (or IAB topologies) according to a second embodiment of the invention
  • Figure 15 illustrates an example of fields of a combined configuration table at an IAB- node according to embodiments of the invention
  • Figures 16a and 16b illustrate, using flowcharts, example methods for managing processing of data packets in an IAB system performed at a donor CU in accordance with embodiments of the invention
  • Figure 17 illustrates, using a flowchart, another example method for managing BAP PDU routing over a plurality of IAB networks (IAB topologies) according to embodiments of this invention
  • Figure 18 illustrates, using a flowchart, another example method for managing BAP PDU routing over a plurality of IAB networks (IAB topologies) according to embodiments of this invention.
  • Figure 19 illustrates, using a flowchart, an example method for processing data packets at an IAB node in an IAB system comprising a plurality of IAB networks (or IAB topologies) according to a third embodiment of the invention.
  • Figure 1 illustrates an example wireless communication system 100, in particular a mobile radio communication system such as a fifth-generation (5G) New Radio (NR) system including a wireless Integrated Access and Backhaul network.
  • 5G fifth-generation
  • NR New Radio
  • FIG. 1 illustrates an example wireless communication system 100, in particular a mobile radio communication system such as a fifth-generation (5G) New Radio (NR) system including a wireless Integrated Access and Backhaul network.
  • 5G fifth-generation
  • NR New Radio
  • the system 100 comprises a plurality of UEs (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 IAB- nodes).
  • UEs User Equipment
  • IAB Integrated Access and Backhaul
  • the main Base Station 120 also referred to as the lAB-donor 120 (or IAB donor), is connected to the core network 110 through a wired link 101, preferably an optical fiber or any other wired means.
  • lAB-donor 120 is a 5G NR gNB with additional functionality to support IAB features, as defined in 3GPP TS 38.300 vl6.2.0 specification document.
  • IAB stations 121 and 122 also referred to as lAB-nodes 121 and 122
  • IAB stations 121 and 122 also referred to as lAB-nodes 121 and 122
  • lAB-nodes 121 and 122 By acting as relaying nodes between the lAB-donor 120 and the UEs 132 and 133, lAB-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 lAB-donor 120. This is particularly true when the communications between the IAB- donor 120 and UEs 132 and 133 are operated at millimeter wave frequencies, which are highly sensitive to shadowing phenomena.
  • the lAB-donor 120 also serves UE 134, which is directly connected to it.
  • the lAB-donor 120 and the lAB-stations 121 and 122 are thus forming a backhaul network or IAB network (also referred to as IAB topology), which accommodates UEs 132,
  • IAB Integrated Access and Backhaul
  • RRC Radio Resource Control
  • lAB-nodes 121 and 122 are respectively connected to UEs 131, 132 and 133, they are considered as Access lAB-nodes for their respectively connected UEs.
  • the lAB-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 lAB-donor-CU or 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 lAB-donor-DUs or donor DUs (also referred to in the following as lAB-donor DU) includes lower layer protocols, such as the RLC, MAC and physical layer protocols.
  • PDCP Packet Data Convergence Protocol
  • RRC Radio Resource Control
  • the lAB-donor CU or donor CU and IAB- 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 lAB-nodes, and at terminating the Fl protocol to the lAB-donor gNB-CU functionality as shown in Figures 2a and 2b discussed below.
  • the IAB nodes 121, 122 which may serve multiple radio sectors, are wireless backhauled to the lAB-donor 120, via one or multiple hops over intermediate IAB nodes. They form a directed acyclic graph (DAG) topology with the lAB-donor at its root.
  • DAG directed acyclic graph
  • the IAB nodes each consist of an IAB-DU and an IAB-MT (lAB-Mobile Termination).
  • the gNB-DU functionality on an lAB-node is also referred to as IAB-DU and allows the downstream (toward the UE) connection to the next-hop IAB.
  • the IAB-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 lAB-node (including the lAB-donor 120 in which case it connects to the lAB-donor gNB-CU, hence to the core network 110, for instance for initialization, registration and configuration).
  • NAS Non Access Stratum
  • the neighbour node on the IAB-DU’ s interface is referred to as child node and the neighbour node on the IAB-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 lAB-donor 120 (e.g. the lAB-donor CU) performs centralized resource, topology and route management for the whole IAB topology. This includes configuring the lAB-nodes according to the network topology, e.g. in order to perform appropriate routing of data packets.
  • FIGS 2a and 2b schematically illustrate stacks of some protocol layers involved in IAB 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.
  • Fl-C is the functional interface in the Control Plane (CP) between the IAB- donor -CU and an IAB -node -DU (e.g. of IAB -node 2), and between the lAB-donor-CU and an lAB-donor DU.
  • Fl-U is the functional interface in the User Plane (UP) for the same units.
  • Fl-C and Fl-U are shown by reference 212 in Figure 2a. In this example, Fl-U and Fl-C are carried over two backhaul hops (from lAB-donor to IAB -node 1 and then from IAB -node 1 to IAB-node2).
  • boxes 210 at the lAB-donor CU and the lAB-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 lAB-donor CU and the lAB-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.
  • boxes 210 indicate the F1AP (Fl 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 lAB-donor CU and the lAB-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 lAB-donor CU and the IAB- node DU as defined in 3 GPP TS 38.401.
  • the transport between the lAB-donor DU and the lAB-donor CU also uses an IP transport Layer over various media, like for example wires or optical fiber when the IAB- donor CU is remote from the lAB-donor DU, or locally in a virtual instantiation of the IAB- donor CU and the lAB-donor DU on the same physical machine.
  • IP transport Layer over various media, like for example wires or optical fiber when the IAB- donor CU is remote from the lAB-donor DU, or locally in a virtual instantiation of the IAB- donor CU and the lAB-donor DU on the same physical machine.
  • lAB-specific transport between lAB-donor-CU and lAB-donor-DU is specified in 3GPP TS 38.401.
  • LI and L2 on the Figure 2a 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.
  • the IP layer On the wireless backhaul, the IP layer is itself carried over the backhaul adaptation protocol (BAP) sublayer, which enables routing over multiple hops.
  • BAP backhaul adaptation protocol
  • the BAP sublayer is specified in TS 38.340.
  • the lAB-DU’s IP traffic is routed over the wireless backhaul via the BAP sublayer.
  • upper layer packets are encapsulated by the BAP sublayer at the lAB-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 lAB-nodes (also referred to as relay nodes), if any.
  • the BAP packets are finally de-encapsulated by the BAP sublayer at the destination lAB-node (which may be an access lAB-node should the upper layer packets in the BAP packets be intended for a UE).
  • upper layer packets are encapsulated by the BAP sublayer at an initiator lAB-node (which may be an access lAB-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 lAB-nodes, if any.
  • the BAP packets are finally deencapsulated by the BAP sublayer at the lAB-donor DU.
  • FIG. 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.
  • PDU BAP Data Protocol Data Unit
  • the payload section 307 is usually an IP packet.
  • the header 30 includes fields 301 to 306.
  • Field 301 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 10 bits.
  • Field 305 carries the BAP address (i.e. on the BAP sublayer) of the destination IAB- node or lAB-donor DU for the BAP packet.
  • BAP address i.e. on the BAP sublayer
  • each lAB-node and lAB-donor DU in an IAB network is configured (by lAB-donor CU of the IAB 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.
  • the routing paths including their path ID, are configured (by lAB-donor-CU of the IAB network) in the lAB-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 lAB-donor-CU.
  • 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 Traffic to Routing ID Mapping Configuration table in the lAB-donor-DU or Uplink Traffic to Routing ID Mapping Configuration table in the initiator lAB-node.
  • the BAP header fields are already specified in the BAP packet to forward.
  • these configuration tables defining the BAP paths are usually defined by the lAB-donor-CU and transmitted to the lAB-nodes to configure them.
  • the RLC Radio Link Control
  • 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 TS 38.321. On the emitter or transmitter side, the MAC encapsulates the data packet issued from 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, TS 38.211, TS 38.212, TS 38.213, TS 38.214.
  • PDCP Packet Data Convergence Protocol
  • SDAP Service Data Adaptation Protocol
  • RRC Radio Resource Control
  • the PDCP sublayer handles IP 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 TS38.324.
  • the SDAP sublayer exchanges the payload data with the user’s application (voice, video, etc. . . - not shown in the Figure).
  • 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 TS38.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 lAB-nodes.
  • NR-Uu is the interface between the UE and the radio access network, i.e. its access I AB -node (for both CP and UP).
  • Figure 2b comes from 3GPP TS 38.300 vl6.4.0 and illustrates the protocol stack for the support of lAB-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 lAB-node. It manages the establishment of communication sessions and maintains communications with the lAB-node or the user equipment as it moves.
  • the 5G NAS is described in 3GPP TS 24.501.
  • the 5G Core Access and Mobility Management Function is a function within the Core Network that receives all connection and session related information from the UEs connected to the IAB node, as well as similar information for the lAB-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 lAB-donor-CU. These SRBs are transported between the IAB-MT and its parent node(s) over NR-Uu interface(s).
  • SRBs Radio Bearers
  • Figure 4 illustrates a routing management in an IAB network.
  • the routing management at an lAB-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 (also referred to as ingress backhaul link) over which a BAP packet is received, one BH RLC channel of one egress link or backhaul link (also referred to as egress backhaul link) for forwarding the received BAP packet.
  • one BH RLC channel of an ingress link or backhaul link also referred to as ingress backhaul link
  • egress backhaul link also referred to as egress backhaul link
  • a BAP routing configuration may be set manually in each lAB-node of the IAB network.
  • the BAP routing configurations are built and can be updated over time by lAB-donor CU and transmitted by the lAB-donor CU via F1AP signaling to the IAB- nodes during their initial configurations and the life of the IAB network.
  • the BAP routing configurations may be built by lAB-donor-CU based on the IAB 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 lAB-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 lAB-node to select the egress link to forward or transmit a BAP packet or PDU (Protocol Data Unit) to a next hop lAB-node.
  • 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 lAB-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.
  • Next-hop BAP address and egress link are synonymous because they each designate the same portion (radio link or backhaul link) of the IAB network between the current lAB-node (e.g.
  • the intermediate or relay lAB-node and the next lAB-node having the next-hop BAP address. Consequently, with respect to 3GPP release 16 for 5GNR, they can be used interchangeably to designate such IAB network radio link or backhaul link.
  • the first entry in the Backhaul Routing Configuration table 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).
  • RLF radio link failure
  • Figure 5b schematically shows an entry 510 of the BH RLC channel mapping configuration table as defined in 3GPP TS 38.300, section 6.11.3 and/or 3GPP TS 38.340, V16.3.0, section 5.2.1.4.1, for the BAP sublayer. It is used by the lAB-node acting as a relay (e.g. an intermediate lAB-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.
  • a relay e.g. an intermediate lAB-node
  • IE 511 stores a next-hop BAP address as defined previously and usually obtained from the Backhaul Routing Configuration table; IE 512 stores a prior-hop BAP address, i.e. the BAP address of the previous lAB-node from which the BAP packet arrives; IE 513 specifies an ingress RLC channel ID, i.e. the identifier of an RLC channel over which the BAP packet is received; and IE 514 stores an egress RLC channel ID providing the RLC channel the lAB-node will use to forward the BAP packet.
  • Prior-hop BAP address of IE 512 and ingress link are synonymous because they each designate the same portion (radio link or backhaul link) of the IAB network between the current lAB-node (e.g. the intermediate or relay lAB-node) and the prior lAB-node having the priorhop BAP address. Consequently, with respect to 3GPP release 16 for 5G NR, they can be used interchangeably to designate such IAB network radio link or backhaul link.
  • the BH RLC channel ID is included in the F1AP configuration of the BH RLC channel.
  • the BH RLC channel ID is included in the RRC configuration of the corresponding logical channel.
  • Figures 5c and 5d illustrates the equivalents to the BH RLC channel mapping configuration table for the lAB-node that does not act as intermediate IAB 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 5c is called Uplink Traffic to BH RLC Channel Mapping Configuration table, 520. It is used by an initiator lAB-node (not the lAB-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 Backhaul Routing Configuration table described in Figure 5a.
  • lAB-node not the lAB-donor-DU
  • BAP SDUs Service Data Unit
  • IE 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 Backhaul Routing Configuration table
  • IE 523 specifies an egress BH RLC channel identifier (ID) providing the RLC channel the lAB-node will use to transmit the BAP packet.
  • ID egress BH RLC channel identifier
  • the table in Figure 5d is called Downlink Traffic to BH RLC Channel Mapping Configuration table 530. It is used by the lAB-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.
  • BAP SDUs Service Data Unit
  • IE 531 is an IPv6 flow label used to classify IPv6 flows
  • IE 532 specifies a DSCP (Differentiated Services Code Point) usually indicated in the IPv6 header of the packets
  • IE 533 indicates a destination IP Address
  • IE 534 indicates a next-hop BAP Address as defined above
  • IE 535 defines an egress BH RLC channel ID providing the RLC channel the lAB-node will use to transmit the BAP packet.
  • the tables of Figures 5b, 5c and 5d may be composed of several rows (entries), each row/entry including the IES (or fields) shown in the respective Figures.
  • BAP routing ID 305+306 of a BAP packet typically the routing of a BAP packet by the BAP sublayer of IAB- 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
  • BAP packet determines whether the BAP packet has reached the destination node, i.e. lAB-node or lAB-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 lAB-node or via F1AP on the lAB-donor DU.
  • the determination of the next-hop lAB-node is based on the Backhaul Routing Configuration table 500.
  • the lAB-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 Backhaul 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.
  • the BH link matching the BAP Routing ID of the BAP packet experiences a radio link failure (RLF), typically the lAB-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.
  • RLF radio link failure
  • lAB-node 402 may select another BAP routing ID having the same destination BAP address but involving BH link 430 instead.
  • the lAB-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 lAB-node 402 uses the BH RLC channel mapping configuration table or Uplink Traffic to BH RLC Channel Mapping Configuration table or Downlink Traffic to BH RLC Channel Mapping Configuration table depending on its role (intermediate or relay lAB-node, initiator lAB-node or lAB-donor-DU transmitting in uplink/upstream or downlink/downstream direction).
  • IES 511, 512, 513 are the inputs and IE 514 is the output of the BH RLC channel look-up process: lAB-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 nexthop BAP address 511.
  • IES 521, 522 are the inputs and IE 523 is the output of the BH RLC channel look-up process: the lAB-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.
  • the Traffic Type Identifier 521 shall correspond to the destination IP address and TEID (Tunnel End Point Identifier) of the BAP SDUs.
  • IEs 531, 532, 533, 534 are the inputs and IE 535 is the output of the BH RLC channel look-up process: lAB-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.
  • DSCP Differentiated Services Code Point
  • a default BH RLC ID channel may be selected.
  • Such routing process can be implemented in the various lAB-nodes of an IAB network.
  • FIG. 6 illustrates an example of an IAB communication system (or arrangement) 600 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 IAB network and at least one other IAB network.
  • 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.
  • An IAB network will also be referred to as an IAB topology or topology and so in this application, the terms IAB network and IAB topology and topology will be used interchangeably.
  • IAB communication system 600 is composed of two IAB networks or IAB topologies 691 and 692 each IAB topology comprising a plurality of IAB nodes or at least one IAB node.
  • the plurality of IAB nodes may include one or more initiator lAB-donor-DUs and one or more lAB-nodes, such as initiator lAB-nodes which generate BAP packets and also intermediate or relay lAB-nodes.
  • Each of the IAB nodes communicate with at least one other IAB node over a wireless backhaul (BH) link.
  • IAB topology 691 is controlled by lAB-donor- CU 610 and IAB topology 692 is controlled by lAB-donor-CU 620.
  • IAB topology 691 includes lAB-donor-CU 610 and its associated lAB-donor-DUs, lAB-donor-DU 601 and lAB-donor-DU 602, and a plurality of lAB-nodes 612 and 613, similar to lAB-nodes 121 and 122.
  • IAB topology 692 includes lAB-donor-CU 620 its associated lAB-donor-DU, IAB- donor-DU 603, and lAB-node 611, similar to lAB-nodes 121 and 122.
  • Figure 6 shows IAB topology 692 including only one lAB-node 611, it will be appreciated that IAB topology 692 may include more than one lAB-node, similar to lAB-nodes 121 and 122.
  • Figure 6 shows two IAB topologies 691 and 692
  • the present invention is not limited to two IAB topologies 691 and 692 and may be implemented in an IAB communication system comprising more than two IAB topologies with each topology comprising a plurality of IAB nodes as discussed above.
  • a wired backhaul IP network interconnects the lAB-donor-CUs 610 and 620, and the lAB-donor-DUs 601, 602 and 603 through routers 640 and 650, and the links 641, 642, 643, 651, 652 and 660.
  • these wired links consist of optical fiber cables.
  • lAB-Donor-CU 610, lAB-Donor-DU 601, lAB-Donor-DU 602, lAB-node 612 and lAB-node 613 are part of the same IAB network or IAB topology 691, which is configured and managed by lAB-Donor-CU 610.
  • lAB-Donor-CU 620, lAB-Donor-DU 603 and lAB-node 611 are part of the same IAB network or IAB topology 692, which is configured and managed by lAB-Donor-CU 620.
  • IAB network 692 is different to the IAB network 691.
  • IAB network 692 may be a neighboring or adjacent IAB network to IAB network 691.
  • lAB-node 611 is connected to the parent lAB-donor-DU 603 through wireless BH link 634, while lAB-node 613 is connected to the parent lAB-donor-DU 601 through wireless BH link 633.
  • lAB-node 612 is connected to the parent lAB-donor-DU 602 through wireless BH link 631, and to the child lAB-node 613 through wireless BH link 632.
  • lAB-node 612 belongs to IAB network 691, in view of its proximity to IAB network 692 and in particular to lAB-node 611, lAB-node 612 is also connected to lAB-node 611 (which acts as a parent node to lAB-node 612) through wireless BH link 635.
  • lAB-node 612 even though belonging to IAB network 691, is also connected to lAB-node 611, which belongs to IAB network 692, it may be referred to as a boundary node between IAB network 691 and IAB network 692.
  • lAB-node or boundary node 612 is part of the IAB network 691, it is controlled (e.g. configured and managed) by the lAB-Donor-CU 610 of IAB network 691.
  • the lAB-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/topol ogies of the IAB network 691 (and also IAB network 692 which may impact the configuration of boundary node 612).
  • each lAB-donor-CU independently assigns BAP addresses in the IAB topology it controls.
  • the boundary node such as IAB- node 612
  • the boundary node is assigned two BAP addresses: one BAP address for the topology 691 assigned by the lAB-donor-CU 610, and one BAP address for the topology 692 assigned by the IAB- donor-CU 620.
  • the lAB-node 612 is a boundary node belonging to the IAB topology 691
  • the lAB-donor-CU 610 may transmit both the assigned BAP addresses to the lAB-node 612 in configuration messages as discussed below.
  • the lAB-donor- CU 610 may transmit the BAP address for the topology 691 assigned by the lAB-donor-CU 610 to the lAB-node 612 in configuration messages as discussed below (for example with reference to Figure 12), and the lAB-donor-CU 620 may transmit the BAP address for the topology 692 assigned by the lAB-donor-CU 620 to the lAB-node 612 in configuration messages as discussed below.
  • lAB-donor-DUs 601, 602, 603, and lAB-nodes 611, 612, 613 are respectively serving UEs 627, 621, 622, 624, 623, 625, 626, they also act as access lAB-nodes for the respective UEs.
  • Redundant paths may exist between pairs of lAB-nodes, for instance, regarding downstream paths from lAB-donor-CU 610 to lAB-node 613, a first default BAP path (PATH 1) via an lAB-donor-DU 601, a second BAP path (PATH 2) via an lAB-donor-DU 602, and lAB-node 612. Symmetrically, there are also two upstream paths involving the same nodes from lAB-node 613 to lAB-donor-CU 610.
  • PATH 1 via an lAB-donor-DU 601
  • PATH 2 via an lAB-donor-DU 602
  • lAB-node 612 Symmetrically, there are also two upstream paths involving the same nodes from lAB-node 613 to lAB-donor-CU 610.
  • BH radio link 633 between lAB-node 612 and lAB-donor-DU 601 may experience radio link deficiency due to some unexpected interference or shadowing phenomena, for example radio link failure, RLF. Also, the link 633 may be congested due to an excessive data traffic.
  • the lAB-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 633, e.g. PATH 2.
  • the lAB-donor-CU 610 may decide to offload some BAP PDUs over an alternative path via the topology 692.
  • the lAB-donor-CU 620 may configure the IAB- donor-DU 603 and lAB-node 611 to route the BAP PDUs for the topology 691 toward the boundary node 612.
  • the lAB-node 613 may be configured by the lAB-donor-CU 610 to route by default the BAP PDUs toward the lAB-donor-DU 601 through the link 633 (i.e. PATH 1 is the default path), and to route, as a back-up, the BAP PDUs towards the lAB-donor-DU 602 via the lAB-node 612 through the links 632 and 631 as a back-up path (PATH 2).
  • PATH 1 is the default path
  • the lAB-node 613 may decide to re-route the BAP PDUs using the back-up path, PATH 2.
  • the boundary node 612 may be configured by the lAB-donor-CU 610 to route by default the BAP PDUs toward the lAB-donor-DU 602 through the link 631, and to route, as a back-up, the BAP PDUs towards the lAB-donor-DU 603 via the lAB-node 611 through the links 635 and 634 as a back-up path (PATH 3).
  • This latter use case may refer to inter-topology re-routing.
  • the use case may refer to inter-donor-DU rerouting.
  • Figure 13 shows steps of an example method 1300 for processing data packets in accordance with a first embodiment of the present invention.
  • Method 1300 is performed at an IAB node in an IAB communication system (or IAB arrangement) comprising at least two IAB topologies with each IAB topology comprising a plurality of IAB nodes or at least one IAB node.
  • the IAB node performing the method 1300 may be an IAB node of either a first IAB topology (or first IAB network) 691 or a second IAB topology (or second IAB network) 692.
  • the IAB node belongs to or is part of either the first IAB topology 691 or the second IAB topology 692.
  • the IAB node may be an lAB-donor DU (such as 601, 602, 603) for data packets to be routed in the downstream direction or an initiator IAB node (e.g. an initiator IAB node may be an IAB node sending data from an UE (i.e. acting as an access lAB-node), or an lAB-node sending control data from itself) for data packets to be routed in the upstream direction.
  • the method as shown in and described with respect to Figure 13 may be performed by software elements and/or hardware elements.
  • the IAB node may be implemented in a communication device 1100 as shown in and described with reference to Figure 11 with the method as shown in and described with respect to Figure 13 being performed by one or more processing units, such as the central processing unit 1111.
  • 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 method shown in Figure 13.
  • the method of Figure 13 may be applied for routing data packets in the upstream or downstream direction.
  • the IAB node receives a data packet (for example, a BAP packet or BAP PDU).
  • the data packet includes a routing identifier for routing the received data packet to a destination IAB node.
  • the routing identifier may include a destination address of the destination IAB node for the data packet and a path identifier identifying a routing path for the data packet to the destination IAB node.
  • 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).
  • the IAB node may receive the data packet from a prior IAB node over an ingress BH link (i.e.
  • the IAB node is a relay or intermediate IAB node such as IAB node 612 or IAB node 611) or the IAB node may generate the data packet in one part of the IAB node (such as in one part or sublayer of a BAP entity of the IAB node) and receive the generated data packet at another part of the IAB node (such as to another part or sublayer of a BAP entity of the IAB node) for routing to another IAB node. In the latter case, the IAB node is acting as an initiator IAB node.
  • the IAB topology associated with the received data packet is one of the at least two IAB topologies and the IAB topology associated with a next IAB node to which the data packet is to be routed is the same IAB topology or another one of the at least two IAB topologies.
  • the IAB node 612 of Figure 6 is part of or belongs to the first IAB topology 691 and on receipt of a data packet for routing, depending on the routing identifier, the IAB node 612 may route the data packet to a next IAB node in the first IAB topology 691 or the second IAB topology 692.
  • the IAB node determines an IAB topology associated with the received data packet. For example, when the IAB node receives the data packet from a prior IAB node over an ingress BH link, the IAB node determines the IAB topology associated with the received data packet by determining the IAB topology associated with the prior IAB node (which is also associated with the ingress backhaul link). As discussed below with reference to Figure 10, a BAP sublayer of the IAB node can establish a relationship between the BAP address of a parent or child IAB node, a topology and backhaul link which can then be used to determine the IAB topology associated with the received data packet. In an example when the IAB node is an initiator IAB node (e.g.
  • the IAB node determines the IAB topology associated with the received data packet based on the IAB node knowing to which IAB topology the IAB node belongs. For example, for an initiator lAB-node, the BAP routing identifier (ID) of the generated packet is indicated by a table (not shown) called Uplink Traffic to Routing ID Mapping Configuration as described in TS 38.340 section 5.2.1.2.1. The indicated BAP routing ID will refer to the topology to which the initiator lAB-node belongs.
  • the IAB node determines, based on routing configuration information associated with the determined IAB topology and the routing identifier of the received data packet, whether the routing identifier is to be updated before routing the data packet to another IAB node.
  • the routing configuration information is a routing configuration table (or backhaul routing configuration table or BAP routing configuration table) such as the routing configuration table shown in and described with respect to Figure 7.
  • the routing configuration table 700 comprises at least one entry with each entry corresponding to the entry 500 of Backhaul routing configuration table of Figure 5a with an additional field, update field 703 (also referred to as rewriting field or header rewriting configuration field 703) for identifying whether the routing identifier for the entry is to be updated (or rewritten).
  • each entry of the routing configuration table may correspond to the entry 500 of Backhaul routing configuration table of Figure 5a but where the routing configuration table is configured such that the next hop address field having a certain value in at least part of the next hop address field indicates the routing identifier is to be updated or rewritten.
  • a specific value in the update field or at least part of the next hop address field for an entry indicates whether the routing identifier is to be updated and a priority of that entry compared to another entry with the same routing identifier or destination address.
  • a specific value in the update field or at least part of the next hop address field for an entry indicates whether the routing identifier of a data packet shall be updated first (i.e. before trying to route the data packet), or updated as a back-up option if no egress link is found after having tried to route the data packet, or not updated at all.
  • the IAB node may determine whether the routing identifier is to be updated by determining whether there is a routing option for the received data packet. For example, the IAB node determines whether there is a routing option for the received data packet in the routing configuration table by checking the routing configuration table associated with the determined IAB topology associated with the received data packet to determine whether the routing identifier of the received data packet matches a routing identifier in the routing identifier field of an entry or whether a destination address of the routing identifier of the received data packet matches a destination address in the destination address field of an entry. The IAB node determines whether the routing identifier is to be updated in response to determining a match with an entry in the routing configuration table and by checking a value in the update field (e.g.
  • the IAB node may determine that the routing identifier is to be updated when a value of the update field 703 indicates the routing identifier is to be updated or rewritten or when a value of at least part of the next hop address field corresponds to a certain value that indicates the routing identifier is to be updated or rewritten.
  • the IAB node may determine whether the routing identifier is to be updated following determining RLF or congestion on a current egress backhaul link based on the routing identifier of the received data packet.
  • the IAB node determines that the routing identifier is to be updated, at step 1308, the IAB node identifies, based on routing identifier mapping information and the routing identifier of the received data packet, a new routing identifier and an IAB topology associated with the new routing identifier (e.g. the IAB topology associated with a next IAB node (egress backhaul link) as determined by the new routing identifier).
  • a new routing identifier and an IAB topology associated with the new routing identifier e.g. the IAB topology associated with a next IAB node (egress backhaul link) as determined by the new routing identifier.
  • the routing identifier mapping information is a routing identifier mapping table (or BAP routing identifier mapping table) comprising at least one entry, with each entry including a field for indicating the IAB topology associated with the routing identifier to be updated and/or a field for indicating the IAB topology associated with the new routing identifier.
  • the routing identifier mapping table may include a previous routing identifier field for a routing identifier, a previous topology field for indicating the IAB topology associated with the routing identifier in the previous routing identifier field, a new or next routing identifier field for a routing identifier, and a new topology field for indicating the IAB topology associated with the routing identifier in the new routing identifier field, where an alternative routing option (e.g. at least one redundant PATH) is available.
  • the routing identifier mapping table is the routing identifier mapping table shown in and described with respect to Figure 8.
  • the IAB node may identify a new routing identifier and the IAB topology associated with the new routing identifier (e.g.
  • the IAB node determines a match with an entry, the IAB node uses the routing identifier in the new routing identifier field of the matched entry as the identified new routing identifier and uses the IAB topology indicated by the new topology field of the matched entry as the identified IAB topology associated with the new routing identifier.
  • the information on the IAB topology in the topology fields provides an indication as to whether the data packet is to be routed to the same or to another IAB topology.
  • the fields of the routing configuration table may be combined with fields of the routing identifier mapping table in a single table.
  • the routing configuration table and the routing identifier mapping table may be configured by an IAB donor control unit CU of the first topology (e.g. IAB- donor-CU 610) and/or an IAB donor control unit CU of the second topology (e.g. lAB-donor- CU 620), using for example, an F1AP protocol message (such as a BAP mapping configuration message).
  • an F1AP protocol message such as a BAP mapping configuration message
  • the IAB node updates the received data packet by updating the routing identifier of the received data packet with the identified new routing identifier to provide an updated data packet including the identified new routing identifier.
  • the routing identifier of the received data may be replaced or rewritten with the new routing identifier.
  • the IAB node determines, based on routing configuration information associated with the identified IAB topology associated with the new routing identifier and the identified new routing identifier, a next IAB node to which the data packet is to be routed (e.g. an egress backhaul link over which the data packet is to be routed to a next IAB node).
  • a next IAB node to which the data packet is to be routed e.g. an egress backhaul link over which the data packet is to be routed to a next IAB node.
  • the IAB node looks for a routing option for the received data packet based on routing configuration information associated with the identified IAB topology and the identified new routing identifier.
  • the IAB node may determine a next IAB node by checking the routing configuration table associated with the identified IAB topology (which is associated with the egress backhaul link) to determine whether the identified new routing identifier matches a routing identifier in the routing identifier field of an entry or whether a destination address of the new routing identifier matches a destination address in the destination address field of an entry.
  • the IAB node uses the next hop address in the next hop address field of the matched entry to determine the next IAB node.
  • An order of entries in the routing configuration table having the same routing identifier or destination address may indicate a priority order of the entries.
  • checking the routing configuration table comprises checking the entries according to the priority order of the entries.
  • the method 1300 may further comprise determining whether the egress backhaul link is available (e.g. there is no RLF or congestion detected), and provided the egress backhaul link is available, the data packet is routed over the egress backhaul link to the next lAB-node. If RLF or congestion is detected, either the routing identifier of the received data packet is not updated or the new routing identifier in the updated data packet is updated or rewritten with the original routing identifier of the received data packet.
  • the IAB node does not necessarily perform the method 1300 in the order shown in Figure 13.
  • the updating step 1310 may be performed before or after or substantially simultaneously with the determining step 1312.
  • the method 1300 may further comprise selecting a backhaul RLC channel for the egress backhaul link based on the identified IAB topology associated with the next IAB node (e.g. which is also associated with the egress backhaul link) and backhaul RLC channel mapping information.
  • the backhaul RLC channel mapping information is a backhaul (BH) RLC channel mapping configuration table (or BAP BH RLC channel mapping configuration table) such as the BH RLC channel mapping configuration table shown in and described with respect to Figures 5b or 5c or Figures 9a or 9b.
  • the BH RLC channel mapping information may provide information such as that shown in Figure 5(b) or Figure 5(c) where the fields 511 and 522 indicate an identifier of an egress link, and where the field 512 indicates an identifier of an ingress link.
  • an ingress link identifier and an egress link identifier indicate both a link and a topology (primary /MCG or secondary/SCG).
  • the BH RLC channel mapping configuration table corresponds to the table as described with respect to Figure 5b or Figure 9a.
  • selecting a backhaul RLC channel for the egress backhaul link may comprise checking the backhaul RLC channel mapping configuration table to determine whether a backhaul RLC channel ID of the ingress backhaul link, an address of the prior IAB node, the determined IAB topology associated with the prior IAB node (e.g. ingress backhaul link), an address of the next IAB node and the identified IAB topology associated with the next IAB node (e.g.
  • egress backhaul link match the respective fields of an entry in the backhaul RLC channel mapping configuration table.
  • a match with an entry is determined, using the egress backhaul RLC channel ID of the matched entry to select the backhaul RLC channel for the egress backhaul link.
  • the BH RLC channel mapping configuration table corresponds to the table as described with respect to Figure 5c or Figure 9b.
  • selecting a backhaul RLC channel for the egress backhaul link may comprise checking the backhaul RLC channel mapping configuration table to determine whether a traffic type of data in the received data packet, an address of the next IAB node and the identified IAB topology associated with the next IAB node (e.g. egress backhaul link) match the respective fields of an entry in the backhaul RLC channel mapping configuration table. When a match with an entry is determined, using the egress backhaul RLC channel ID of the matched entry to select the backhaul RLC channel for the egress backhaul link.
  • routing identifier of the received data packet By first checking whether the routing identifier of the received data packet is to be updated before routing the data packet to another IAB node, for example, by having an update/rewrite identifier for each entry in the routing configuration table and by determining whether the routing identifier is to be updated and in response to determining that the routing identifier is to be updated, updating the routing identifier and determining the next IAB node based on the updated routing identifier (i.e. by first checking the update field 703 or destination address field to see whether the routing identifier of the entry is to be updated), processing resources and processing time (which impacts latency) can be saved.
  • processing resources and processing time can be saved by avoiding the IAB node parsing unnecessarily all of the entries in the routing identifier mapping table and/or the routing configuration table (e.g. when no entry will be found for the corresponding routing identifier).
  • Unnecessary parsing of the routing configuration table can be avoided, for example, when a boundary node receives a data packet with an alias BAP address since following a determination that the routing identifier of the received data packet is to be updated using the routing configuration table, the IAB node can then go directly to check the routing identifier mapping table without continuing to parse the routing configuration table.
  • Unnecessary parsing of the routing identifier mapping table can be avoided, for example, when there is no entry for the routing identifier of the received data packet, then there is no need to parse the routing identifier mapping table after determining there is no egress BH link available through the routing configuration table. Furthermore, the IAB node has flexibility to update the routing identifier of received data packets based on current radio conditions and congestion (i.e. to optimise the routing of data packets based on current conditions).
  • the IAB node may disable the rewriting indication for this routing identifier in the routing configuration table, and thus save some processing time when routing the next BAP data packets with the same BAP routing identifier.
  • Figure 14 shows steps of an example method 1400 for processing data packets in accordance with a second embodiment of the present invention.
  • Method 1400 is performed at an IAB node in an IAB communication system (or IAB arrangement) comprising at least two IAB topologies with each IAB topology comprising a plurality of IAB nodes or at least one IAB node.
  • the IAB node performing the method 1400 may be an IAB node of either a first IAB topology (or first IAB network) 691 or a second IAB topology (or second IAB network) 692.
  • the IAB node belongs to or is part of either the first IAB topology 691 or the second IAB topology 692.
  • the IAB node may be an lAB-donor DU (such as 601, 602, 603) for data packets to be routed in the downstream direction or an initiator IAB node for data packets to be routed in the upstream direction (e.g. an initiator IAB node may be an IAB node sending data from an UE (i.e. acting as an access lAB-node), or an lAB-node sending control data from itself).
  • the method as shown in and described with respect to Figure 14 may be performed by software elements and/or hardware elements.
  • the IAB node may be implemented in a communication device 1100 as shown in and described with reference to Figure 11 with the method as shown in and described with respect to Figure 14 being performed by one or more processing units, such as the central processing unit 1111.
  • 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 method shown in Figure 14.
  • the method of Figure 14 may be applied for routing data packets in the upstream or downstream direction.
  • the IAB node receives a data packet (for example, a BAP packet or BAP PDU).
  • the data packet includes a routing identifier for routing the received data packet to a destination IAB node.
  • the routing identifier may include 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 IAB node.
  • 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).
  • the IAB node may receive the data packet from a prior IAB node over an ingress BH link (i.e.
  • the IAB node is a relay or intermediate IAB node such as IAB node 612 or IAB node 611) or the IAB node may generate the data packet in one part of the IAB node (such as in one part or sublayer of a BAP entity of the IAB node) and receive the generated data packet at another part of the IAB node (such as to another part or sublayer of a BAP entity of the IAB node) for routing to another IAB node. In the latter case, the IAB node is acting as an initiator IAB node.
  • the IAB node determines an IAB topology associated with the received data packet. For example, when the IAB node receives the data packet from a prior IAB node over an ingress BH link, the IAB node determines the IAB topology associated with the received data packet by determining the IAB topology associated with the prior IAB node (which is also associated with the ingress backhaul link). As discussed below with reference to Figure 10, a BAP sublayer of the IAB node can establish a relationship between the BAP address of a parent or child IAB node, a topology and backhaul link which can then be used to determine the IAB topology associated with the received data packet.
  • the IAB node determines the IAB topology associated with the received data packet based on the IAB node knowing to which IAB topology the IAB node belongs. For example, for an initiator lAB-node, the BAP routing identifier (ID) of the generated packet is indicated by a table (not shown) called Uplink Traffic to Routing ID Mapping Configuration as described in TS 38.340 section 5.2.1.2.1. The indicated BAP routing ID will refer to the topology to which the initiator lAB-node belongs.
  • ID the BAP routing identifier of the generated packet is indicated by a table (not shown) called Uplink Traffic to Routing ID Mapping Configuration as described in TS 38.340 section 5.2.1.2.1.
  • the indicated BAP routing ID will refer to the topology to which the initiator lAB-node belongs.
  • This step 1403 may be omitted in the case where the data packet is received from the upper layers (e.g. the IAB node is an initiator node that has generated the packet) and IAB node uses the BH RLC channel mapping configuration table corresponding to the table as described with respect to Figure 9b.
  • the data packet is received from the upper layers (e.g. the IAB node is an initiator node that has generated the packet) and IAB node uses the BH RLC channel mapping configuration table corresponding to the table as described with respect to Figure 9b.
  • the IAB node determines, based on the routing identifier of the received data packet, an egress backhaul link over which the data packet is to be routed to a next IAB node. In other words, the IAB node looks for a routing option for the received data packet based on the routing identifier of the received data packet.
  • the IAB node may determine the egress backhaul link over which the data packet is to be routed to a next IAB node by determining an address of the next IAB node by checking a backhaul routing configuration table, such as the Backhaul routing configuration table of Figure 5a or the routing configuration table of Figure 7, using the routing identifier or the destination address of the routing identifier (e.g. as the input).
  • the backhaul routing configuration table has at least one entry, with each entry of the routing configuration table including at least a routing identifier field for a routing identifier and a next hop address field for indicating an address of a next IAB node in the routing path identified by the path identifier of the routing identifier.
  • the IAB node determines an egress backhaul link based on the address of the determined next IAB node of the matched entry.
  • the method may further comprise initiating a process for updating or rewriting the routing identifier (e.g. in the header of the received data packet provided header updating/rewriting is permitted).
  • the IAB node checks a routing identifier mapping table using the routing identifier of the received data packet and when there is a match with an entry in the routing identifier mapping table, the IAB node determines a new routing identifier for the received data packet based on the new routing identifier of the matched entry.
  • the routing identifier mapping table may include at least a previous routing identifier field for a routing identifier, and a new routing identifier field for a routing identifier where an alternative routing option (e.g. at least one redundant PATH) is available.
  • the routing identifier mapping table may comprise the table as shown in and described with respect to Figure 8. The IAB node then updates or rewrites the routing identifier of the received data packet with the new routing identifier to provide an updated data packet including the identified new routing identifier.
  • the IAB node determines an egress backhaul link over which the data packet is to be routed to a next IAB node by determining an address of the next IAB node by checking the backhaul routing configuration table using the new routing identifier or the destination address of the new routing identifier and when there is a match with an entry in the backhaul routing configuration table, determining an egress backhaul link based on the address of the determined next IAB node of the matched entry.
  • the IAB node determines an IAB topology associated with the next IAB node (e.g. which is also associated with the egress BH link over which the data packet is to be routed to the next IAB node).
  • the IAB topology of the next IAB node is the same as the IAB topology associated to the received data packet.
  • the IAB topology associated with the next IAB node may be determined from a routing identifier mapping table such as that shown in and described with respect to Figure 8.
  • the IAB node selects a backhaul RLC channel for the egress backhaul link based on the determined IAB topology associated with the next IAB node and a backhaul RLC channel mapping configuration table.
  • the backhaul RLC channel mapping information is a backhaul (BH) RLC channel mapping configuration table (or BAP BH RLC channel mapping configuration table) such as the BH RLC channel mapping configuration table shown in and described with respect to Figures 9a or 9b.
  • BH backhaul
  • BAP BH RLC channel mapping configuration table such as the BH RLC channel mapping configuration table shown in and described with respect to Figures 9a or 9b.
  • the BH RLC channel mapping information may provide information such as that shown in Figure 5(b) or Figure 5(c) where the fields 511 and 522 indicate an identifier of an egress link, and where the field 512 indicates an identifier of an ingress link.
  • an ingress link identifier and an egress link identifier indicate both a link and a topology (primary /MCG or secondary/SCG).
  • the BH RLC channel mapping configuration table corresponds to the table as described with respect Figure 9a.
  • Selecting a backhaul RLC channel for the egress backhaul link may comprise checking the backhaul RLC channel mapping configuration table to determine whether a backhaul RLC channel ID of the ingress backhaul link, an address of the prior IAB node, the determined IAB topology associated with the prior IAB node (e.g. ingress backhaul link), an address of the next IAB node and the identified IAB topology associated with the next IAB node (e.g.
  • egress backhaul link match the respective fields of an entry in the backhaul RLC channel mapping configuration table.
  • a match with an entry is determined, using the egress backhaul RLC channel ID of the matched entry to select the backhaul RLC channel for the egress backhaul link.
  • the BH RLC channel mapping configuration table corresponds to the table as described with respect to Figure 9b.
  • Selecting a backhaul RLC channel for the egress backhaul link may comprise checking the backhaul RLC channel mapping configuration table to determine whether a traffic type of data in the received data packet, an address of the next IAB node and the identified IAB topology associated with the next IAB node (e.g. egress backhaul link) match the respective fields of an entry in the backhaul RLC channel mapping configuration table. When a match with an entry is determined, using the egress backhaul RLC channel ID of the matched entry to select the backhaul RLC channel for the egress backhaul link
  • the IAB node routes the updated data packet over the egress backhaul link to the next lAB-node.
  • the method 1400 may further comprise determining whether the egress backhaul link is available (e.g. there is no RLF or congestion detected), and provided the egress backhaul link is available, the data packet is routed over the egress backhaul link to the next lAB-node. If RLF or congestion is detected such that the egress backhaul link is not available, the method may return to step 1404 to determine an egress BH link based on checking the routing configuration table for another entry using the routing identifier of the received data packet or the destination address of the routing identifier.
  • Figure 7 illustrates an example of entries of a routing configuration table 700 at an lAB-node according to embodiments of the invention having at least one entry 710, 711, 712.
  • Entry 710 of routing configuration table 700 corresponds to the entry 500 of Backhaul routing configuration table of Figure 5a with an additional field, update field 703 (also referred to as rewriting field 703) for identifying whether the routing identifier for the entry is to be updated (or rewritten).
  • 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 7 and designated with the same reference numerals as Figure 5a.
  • An lAB-node acting as a boundary node may have a routing configuration table, such as the routing configuration table 700 as shown in and described with reference to Figure 7, for the IAB topology the lAB-node actually belongs to (e.g. topology 691 for lAB-node 612), also referred to as a primary or first topology, and one routing configuration table for each other topology the lAB-node is connected to (e.g. topology 692 for lAB-node 612), also referred to a secondary or second topology.
  • a routing configuration table such as the routing configuration table 700 as shown in and described with reference to Figure 7, for the IAB topology the lAB-node actually belongs to (e.g. topology 691 for lAB-node 612), also referred to as a primary or first topology, and one routing configuration table for each other topology the lAB-node is connected to (e.g. topology 692 for lAB-no
  • the routing configuration tables 700 for both primary and secondary topologies are configured by the lAB-donor-CU that manages the primary topology for the lAB-node.
  • the routing configuration tables 700 of lAB-node 612 are configured by lAB-donor-CU 610 for both primary (IAB topology 691) and secondary (IAB topology 692) topologies.
  • the routing configuration table 700 for the primary topology is configured by the lAB-donor-CU that manages the primary topology for the lAB-node
  • the routing configuration table 700 for a secondary topology is configured by the lAB-donor- CU that manages the secondary topology for the lAB-node.
  • the routing configuration table 700 of IAB topology 691 (which is the primary topology) is configured by lAB-donor-CU 610
  • the routing configuration table 700 of IAB topology 692 (which is the secondary topology) is configured by lAB-donor-CU 620.
  • the lAB-node 612 may have separate routing configuration tables 700 for each topology or a single routing configuration table 700 which is a combination of the separate routing configuration tables for each topology.
  • a single routing configuration table 700 which is a combination of the separate routing configuration tables for each topology.
  • an indication of with which topology each entry is associated may be provided.
  • the Next Hop BAP Address field 502 of the entries of a routing configuration table 700 for a particular IAB topology (primary or secondary) is therefore associated to the particular IAB topology (primary or secondary).
  • the Next Hop BAP Address field 502 of the entries for a particular IAB topology (primary or secondary) in the single routing configuration table 700 is therefore associated to the particular IAB topology (primary or secondary).
  • the Next Hop BAP Address field 502 and the associated topology defines a unique egress link (or egress BH link).
  • Figure 7 schematically shows several entries 711 and 712, like entry 710, of the Backhaul Routing Configuration table 700 according to some embodiments of the present invention.
  • field 703 defines an update or rewriting field, in addition to fields 501 and 502 and is for indicating whether the routing identifier is to be updated.
  • the rewriting field 703 can indicate an alternative path with an alternative egress BH link that requires the rewriting of fields 305 and 306 in the BAP header of a received data packet is available.
  • the alternative egress BH link can be determined using routing identifier mapping information, such as the routing identifier (ID) mapping table 800 as shown in and described with reference to Figure 8.
  • an egress BH link may not be available due to some RLF occurring on the link. In another example, an egress BH link may not be available due to some congestion phenomenon.
  • rewriting field 703 carries information that indicates whether an alternative egress BH link is available or not by rewriting the BAP header.
  • rewriting field 703 may be a one-bit field.
  • setting the rewriting field to ‘ 1’ (or ‘0’) can be used to indicate the routing identifier is to be updated (and an alternative path with an alternative egress BH may be available) and setting the rewriting field to ‘0’ (or ‘ 1’) can be used to indicate the routing identifier is not to be updated (and an alternative path with an alternative egress BH is not available).
  • Rewriting field 703 may also carry some priority information (e.g.
  • a number in the rewriting field 703 of an entry can be used to indicate the priority of the entry compared to another entry with a different number in the rewriting field 703), which indicates if the lAB-node should consider the egress BH link determined using the routing ID mapping table 800 prior to or after another alternate egress BH link related to another entry of the routing configuration table 700, for which a DESTINATION field 5011 matches the DESTINATION field 305 of the BAP header of a received data packet.
  • the priority indicated by the rewriting field 703 can be used to indicate an order in which alternate egress BH links should be considered (e.g. first alternative and one or more additional back-up alternatives in a priority order).
  • the rewriting field 703 indicates whether the routing identifier of a data packet shall be updated first (i.e. before trying to route the data packet), or updated as a back-up option if no egress link is found after having tried to route the data packet, or not updated at all.
  • the routing configuration table 700 comprises a field 703 for the update or rewriting field which is an additional field to the 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.
  • each entry of the routing configuration table may comprise the 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 but where a certain value in at least part of the next hop address field or Next Hop BAP address field 502 indicates the routing identifier is to be updated.
  • the rewriting field may be indicated by a specific or certain value of Next Hop BAP address field 502 reserved for this usage (e.g. a reserved address value), such as the value ‘O’, can be used to indicate the routing identifier is to be updated (and an alternative path with an alternative egress BH may be available).
  • a certain value in part of the Next Hop BAP address field 502, such as one or more of the Most Significant Bits of the Next Hop BAP address field 502 can be used to indicate the routing identifier is to be updated (and an alternative path with an alternative egress BH is available).
  • certain values in the at least part of the next hop address field or Next Hop BAP address field 502 can be used to provide priority information in addition to indicating whether the routing identifier is to be updated.
  • certain values in the at least part of the next hop address field or Next Hop BAP address field 502 can be used to indicate whether the routing identifier of a data packet shall be updated first (i.e. before trying to route the data packet), or updated as a back-up option if no egress link is found after having tried to route the data packet, or not updated at all.
  • the BAP MAPPING CONFIGURATION message (F1AP protocol), as described in 3GPP TS 38.473 vl6.4.0, is used to transmit the routing configuration table, such as the routing configuration table 700, to an lAB-node.
  • the BAP MAPPING CONFIGURATION message (F1AP protocol) is used to transmit the routing configuration table 700 with the introduction of the rewriting field 703 in the Information Element (IE) that contains the table 700.
  • IE Information Element
  • the BH Routing Information Added List Information Element (IE), defined in section 9.2.9.1 of 3GPP TS 38.473 vl6.4.0, is modified as follows to allow the lAB-donor-CU to configure the rewriting field 703.
  • the routing identifier mapping information may comprise a routing identifier mapping table.
  • Figure 8 illustrates an example of entries of a routing identifier mapping table or Routing ID mapping configuration (or Header rewriting configuration) table having at least one entry 810-813 at an lAB-node according to embodiments of the invention.
  • the Routing ID mapping table 800 is configured by the lAB-donor-CU that manages the primary topology for the lAB-node.
  • the Routing ID mapping table 800 of lAB-node 612 is configured by lAB-donor-CU 610.
  • the Routing ID mapping table 800 is configured by the lAB-donor- CU that manages the secondary topology for the lAB-node.
  • the Routing ID mapping table 800 of lAB-node 612 is configured by lAB-donor- CU 620.
  • Figure 8 schematically shows several entries 811, 812, and 813, like entry 810, of the Routing ID mapping table 800 according to some embodiments of the present invention.
  • Fields 821 and 831 both define a routing identifier field or BAP Routing ID for a routing identifier for a data packet corresponding to a concatenation of PATH field 306 and DESTINATION field 305 as defined in Figure 3.
  • Routing identifier field 821 (hereinafter referred to as previous routing identifier field) is for a previous routing identifier for a data packet and comprises a concatenation of the path field 8212 and destination field 8211.
  • Routing identifier field 831 (hereinafter referred to as new (or next) routing identifier field) comprises a concatenation of the path field 8312 and destination field 8311 for a new or next routing identifier for a data packet.
  • Topology field 822 (hereinafter referred to as previous topology field) is for indicating the IAB topology associated with the routing identifier in the previous routing identifier field 821.
  • Topology field 832 (hereinafter referred to as new or next topology field) is for indicating the IAB topology associated with the routing identifier in the new routing identifier field 831.
  • the topology fields 822 and 832 are both n-bit fields. In one example, the topology field (e.g.
  • the topology field 822 and/or field 832 indicates that the topology is either the one the lAB-node actually belongs to (such topology may be referred to as a primary or first topology) or another topology to which the lAB-node is additionally connected (such topology may be referred to as a secondary or second topology).
  • the topology field (e.g. field 822 and/or field 832) includes a topology identifier having a value that uniquely identifies a given topology.
  • the primary topology for the boundary node, lAB-node 612 is IAB topology 691 and the secondary topology is IAB topology 692.
  • each of the topology fields 822 and 832 in the routing identifier mapping table for the lAB-node 612 will have a value that indicates either IAB topology 691 or IAB topology 692.
  • Field 820 made of fields 821 and 822, is referred to as a PREVIOUS BAP ROUTING Information Element (IE), while field 830, made of fields 831 and 832, is referred to as a NEW BAP ROUTING Information Element (IE).
  • IE PREVIOUS BAP ROUTING Information Element
  • an lAB-node such as lAB-node 612, decides to route a data packet through an alternative egress BH link that requires the rewriting of fields 305 and 306 in the BAP header of a received data packet, in accordance with the information carried by rewriting field 703 of an entry of the routing configuration table defined in Figure 7, which entry corresponds to either the routing identifier or the destination address of the BAP header of the received packet, the lAB-node may check for an entry in the Routing ID mapping table 800 to determine whether the routing identifier of the received data packet (which corresponds to the routing identifier field 501 associated to the considered rewriting field 703 of the entry of the routing configuration table) matches a routing identifier in the previous routing identifier field 821 of an entry or whether a destination address of the routing identifier of the received data packet matches a destination address in the destination address field 8211 of an entry.
  • the lAB-node uses the routing identifier in the new routing identifier field 831 of the matched entry as the new routing identifier to update or rewrite the BAP header of the received data packet.
  • the IAB topology indicated in the new topology field 832 of the matched entry is used as the identified IAB topology associated with the next IAB node (e.g. the egress backhaul link).
  • the IAB node should update or rewrite the received data packet by replacing the destination address in the DESTINATION field 305 and path identifier in the PATH field 306 in the BAP header of the received data packet respectively by the destination address in the new destination field 8311 and the path identifier in the new path field 8312, and eventually route this data packet over the topology identified by topology field 832 using the new routing identifier.
  • Routing ID mapping table 800 There may be several entries in the Routing ID mapping table 800 with the same destination BAP address in the destination address field 8211 but with different path identifiers in path field 8212 and different routing identifiers in the new routing identifier field 831.
  • the order of the entries in the Routing ID mapping table 800 may indicate a priority order of the entries. For example, the first entry may provide the default new BAP Address corresponding to the new 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) or congestion.
  • RLF radio link failure
  • the BAP MAPPING CONFIGURATION message (F1AP protocol), as described in 3GPP TS 38.473 vl6.4.0, is used to transmit the routing identifier mapping table, such as the Routing ID mapping table 800, to an lAB-node, with the introduction of a new Information Element (IE) that contains the table 800.
  • IE Information Element
  • the routing configuration table such as the routing configuration table 700 shown in and described with respect to Figure 7, may be separate to the routing identifier mapping table, such as the Routing ID mapping table 800 shown in and described with respect to Figure 8.
  • both tables may be combined in a single table as shown in Figure 15, which shows an entry 1510 of a combined configuration table 1500 in accordance with an example of an embodiment of the invention.
  • Like fields to those shown in Figures 7 and 8 are referenced by the same reference number.
  • the backhaul (BH) RLC channel mapping information may comprise a BH RLC channel mapping configuration table.
  • Figures 9a and 9b illustrate examples of an entry of a BH RLC channel mapping configuration table according to embodiments of the invention.
  • the BH RLC channel mapping information may provide information such as that shown in Figure 5(b) or Figure 5(c) where the fields 511 and 522 indicate an identifier of an egress link, and where the field 512 indicates an identifier of an ingress link.
  • an ingress link identifier and an egress link identifier indicates both a link and a topology (primary /MCG or secondary/SCG).
  • FIG. 9a illustrates an example of an entry of a BH RLC channel mapping configuration table 900 having at least one entry 910 at an lAB-node according to embodiments of the invention.
  • BH RLC channel mapping configuration table 900 is used by a lAB-node acting as a relay (e.g. an intermediate lAB-node) to identify the Backhaul (BH) RLC channel for routing a data packet (e.g. BAP packet or PDU) over the egress link previously selected using the Backhaul Routing Configuration table of Figure 5a or previously selected using the routing configuration table described with respect to Figure 7.
  • a data packet is received at the lAB-node from a prior lAB-node (e.g.
  • Entry 910 of BH RLC channel mapping configuration table 900 corresponds to the entry 510 of BH RLC channel mapping configuration table of Figure 5b with additional fields 911 and 912.
  • Additional field 911 is an egress topology field for indicating the IAB topology associated with a next IAB node, and for indicating with the next hop address field an egress backhaul link between the IAB node and the next IAB node.
  • Additional field 912 is an ingress topology field for indicating the IAB topology associated with a prior IAB node, and for indicating with the prior hop address field an ingress backhaul link between the IAB node and the prior IAB node.
  • next hop BAP address field 511 for a next hop address of a next IAB node that is next to the IAB node in a routing path
  • prior hop BAP address field 512 for a prior hop address of a prior IAB node that is prior to the IAB node in the routing path
  • Ingress BH RLC channel ID field 513 for a backhaul RLC channel identifier of a backhaul RLC channel of the ingress backhaul link
  • egress BH RLC channel ID field 514 for a backhaul RLC channel identifier of a backhaul RLC channel for the egress backhaul link of the BH RLC channel mapping configuration table of Figure 5b are shown in Figure 9a and designated with the same reference numerals as Figure 5b.
  • Field 911 also referred to as egress-topology, or next-topology field 911, identifies the topology associated to next-hop BAP address 511.
  • the next hop BAP address field 511 and the associated topology identified in the egress topology field 911 define a unique egress link (or egress BH link).
  • Field 912 also referred to as ingress-topology, or prior-topology field 912, identifies the topology associated to prior-hop BAP address 512.
  • the prior hop BAP address field 512 and the associated topology identified in the ingress topology field 912 defines a unique ingress link (or ingress BH link).
  • topology fields 911 and 912 are both n-bit fields.
  • topology field e.g. field 911 and/or field 912 indicates that the topology is either the one the lAB-node actually belongs to (such topology may be referred to as a primary or first topology) or another topology to which the lAB-node is additionally connected (such topology may be referred to as a secondary or second topology).
  • topology field (e.g. field 911 and/or field 912) includes a topology identifier having a value that uniquely identifies a given topology.
  • the primary topology for the boundary node, lAB-node 612 is IAB topology 691 and the secondary topology is IAB topology 692.
  • each of the topology fields 911 and 912 in the BH RLC channel mapping configuration table for the lAB-node 612 will have a value that indicates either IAB topology 691 or IAB topology 692.
  • the IAB node may check for an entry in the Routing ID mapping table 800 to determine whether the routing identifier of the received data packet (which corresponds to the routing identifier field 501 associated to the considered rewriting field 703 of the entry of the routing configuration table) matches a routing identifier in the previous routing identifier field 821 of an entry or whether a destination address of the routing identifier of the received data packet matches a destination address in the destination address field 8211 of an
  • the lAB-node uses the routing identifier in the new routing identifier field 831 of the matched entry as the new routing identifier to update or rewrite the BAP header of the received data packet.
  • the lAB-node may determine, from the routing configuration table 700, the next IAB node (e.g. the address of the next IAB node or next-hop BAP address) in the next-hop address field 502 associated to the entry which has a routing identifier in the routing identifier field 501 matching the new routing identifier in the new routing identifier field 831 of the Routing ID mapping table 800 defined in Figure 8, or the address of the next IAB node (e.g. the next-hop BAP address) in the next-hop address field 502 associated to the entry which has a destination address in the destination address field 5011 matching the new destination address in the new destination field 8311 of the Routing ID mapping table 800.
  • the next IAB node e.g. the address of the next IAB node or next
  • the lAB-node When the lAB-node receives a data packet from a prior IAB node over an ingress BH link for routing to another lAB-node over an egress BH link, the lAB-node may select a backhaul RLC channel for the egress BH link based on the IAB topology associated with the egress BH link and the BH RLC channel mapping table, such as the table 900 of Figure 9a.
  • the lAB-node may select a BH RLC channel for the egress BH link by checking the BH RLC channel mapping configuration table 900 to determine whether a BH RLC channel ID of the ingress BH link, an address of the prior IAB node, the IAB topology associated with the prior IAB node (e.g. the ingress BH link), an address of the next IAB node and the IAB topology associated with the next IAB node (e.g. the egress BH link) match the respective fields of an entry in the BH RLC channel mapping configuration table 900.
  • the lAB-node can use the egress BH RLC channel ID of the matched entry to select the BH RLC channel for the egress BH link.
  • the lAB-node may check the BH RLC channel mapping configuration table 900 and, considering the address of the prior IAB node with respect to the prior hop BAP address field 512, the associated ingress-topology with respect to the ingress topology field 912, or prior-topology field 912, the address of the next IAB node with respect to the nexthop BAP address field 511, the associated egress-topology with respect to the egress topology field 911, or next-topology field 911, and the BH RLC channel ID with respect to the ingress BH RLC channel ID field 513, the lAB-node can then route the data packet through the egress BH RLC channel identified by the egress BH RLC channel ID field 514.
  • the BAP layer BH RLC channel mapping Information List Information Element (IE), defined in section 9.3.1.98 of 3GPP TS 38.473 V16.4.0, is modified as follows to allow the lAB-donor-CU to configure the BH RLC channel mapping configuration table 900 of an lAB-node according to some aspects of the invention.
  • the Mapping Information Index includes an index of one mapping information entry at the lAB-donor-DU or an IAB-DU.
  • the BAP layer BH RLC channel mapping Information List IE is included in the UE-associated F1AP signaling for setting up or modifying a BH RLC channel, it contains either the Prior-Hop BAP Address IE 512, the Ingress Topology IE 912 and the Ingress BH RLC channel (CH) ID IE 513 to configure a mapping in downlink (or downstream) direction, or the Next-Hop BAP address IE 511, the Egress Topology IE 911 and the Egress BH RLC channel (CH) ID IE 514 to configure a mapping in uplink direction.
  • the BH RLC channel mapping configuration table 900 is configured by the lAB-donor-CU that manages the primary topology for the lAB-node.
  • the BH RLC channel mapping configuration table 900 of lAB-node 612 is configured by lAB-donor-CU 610.
  • the BH RLC channel mapping configuration table 900 is configured by the lAB-donor-CU that manages the secondary topology for the lAB-node.
  • the BH RLC channel mapping configuration table 900 of lAB-node 612 is configured by lAB-donor-CU 620.
  • the entries of the table 900 concerning an egress BH RLC channel ID 514 in the primary topology are configured by the lAB-donor-CU that manages the primary topology for a boundary lAB-node
  • the entries of the table 900 concerning an egress BH RLC channel ID 514 in the secondary topology are configured by the lAB-donor-CU that manages the secondary topology for the boundary lAB-node.
  • the BAP MAPPING CONFIGURATION message (F1AP protocol), as described in 3GPP TS 38.473 vl6.4.0, is used to transmit the table 900 to an lAB-node.
  • Figure 9b illustrates an example of an entry of a BH RLC channel mapping configuration table 921 (also referred to as a uplink traffic to BH RLC channel mapping configuration table) having at least one entry 920 at an lAB-node according to embodiments of the invention.
  • the BH RLC channel mapping configuration table 921 is used an initiator lAB-node (not the lAB-donor-DU).
  • the lAB-node generates data packets (e.g. BAP packets or PDUs from BAP SDUs (Service Data Unit) received from upper layers), in one part of the lAB-node (e.g.
  • BH RLC channel mapping configuration table 921 to identify the BH RLC channel to transmit these data packets in upstream direction over the egress link previously selected using the Backhaul Routing Configuration table described in Figure 5a or the routing configuration table described with respect to Figure 7.
  • Entry 920 of BH RLC channel mapping configuration table 921 corresponds to the entry 520 of Uplink Traffic to BH RLC channel mapping configuration table of Figure 5c with an additional field 922.
  • Additional field 922 is an egress topology field for indicating the IAB topology associated with the next IAB node, and for indicating with the next hop address field an egress backhaul link between the IAB node and the next IAB node.
  • traffic type identifier field 521 for indicating a traffic type of a data packet to be routed
  • next hop BAP address field 522 for a next hop address of a next IAB node that is next to the IAB node in a routing path
  • egress BH RLC channel ID field 514 for a backhaul RLC channel identifier of a backhaul RLC channel for the egress backhaul link of the Uplink Traffic to BH RLC channel mapping configuration table of Figure 5c are shown in Figure 9b and designated with the same reference numerals as Figure 5b.
  • Field 922 also referred to as egress-topology, or next-topology field 922, identifies the topology associated to next-hop BAP address 522.
  • the next hop BAP address field 522 and the associated topology identified in the egress topology field 922 define a unique egress link (or egress BH link).
  • Topology field 922 is a n-bit field.
  • topology field 922 indicates that the topology is either the one the lAB-node actually belongs to (such topology may be referred to as a primary or first topology) or another topology to which the lAB-node is additionally connected (such topology may be referred to as a secondary or second topology).
  • topology field 922 includes a topology identifier having a value that uniquely identifies a given topology.
  • the primary topology for the boundary node, lAB-node 612 is IAB topology 691 and the secondary topology is IAB topology 692.
  • the topology field 922 in the BH RLC channel mapping configuration table 920 for the lAB-node 612 will have a value that indicates either IAB topology 691 or IAB topology 692.
  • Each entry of the Uplink Traffic to BH RLC Channel Mapping Configuration table 921 contains a traffic type specifier 521, which is indicated by UL UP TNL Information IE for Fl-U packets or Non-UP Traffic Type IE for non-Fl-U packets as defined in TS 38.473.
  • the other fields 522, 922, and 523 are indicated by the BH Information IE defined in section 9.3.1.114 of 3GPP TS 38.473 vl6.4.0, modified as follow according to one embodiment of the invention:
  • the BH RLC Channel Mapping Configuration table 921 is configured by the lAB-donor-CU that manages the primary topology for the lAB-node.
  • the BH RLC channel mapping configuration table 921 of lAB-node 612 is configured by lAB-donor-CU 610.
  • it is configured by the lAB- donor-CU that manages the secondary topology for the lAB-node.
  • the BH RLC channel mapping configuration table 921 of lAB-node 612 is configured by lAB-donor-CU 620.
  • the entries of the table 921 concerning the primary topology as egress topology 922 are configured by the lAB-donor- CU that manages the primary topology for a boundary lAB-node
  • the entries of the table 921 concerning the secondary topology as egress topology 922 are configured by the lAB- donor-CU that manages the secondary topology for the boundary lAB-node.
  • Configuration of the BH RLC channel mapping configuration table 921 in an lAB-node is discussed below with reference to Figure 12.
  • the BAP MAPPING CONFIGURATION message (F1AP protocol), as described in 3GPP TS 38.473 vl6.4.0, is used to transmit the table 921 to an lAB-node.
  • an lAB-node is configured with multiple tables 520 (such as the Uplink Traffic to BH RLC channel mapping configuration table of Figure 5c), each table being associated to one IAB topology.
  • the egress topology field 922 can be omitted.
  • Figure 10 illustrates, using a flowchart 1000, an example method for processing data packets (e.g. for managing BAP PDU (or data packet) routing over one or more IAB networks (one or more IAB topologies)) according to embodiments and examples of the invention.
  • 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 example method shown in Figure 10.
  • the method of Figure 10 may be applied for routing data packets in the upstream or downstream direction.
  • the method of Figure 10 uses the configuration tables 7 and 8 and is similar to the method described above with reference to Figure 13.
  • the process starts at step 1001 where an lAB-node, such as IAB node 612, receives a BAP packet, or BAP PDU, it should route.
  • an lAB-node such as IAB node 612
  • the lAB-node identifies the IAB topology associated with the BAP packet to be routed (e.g. the received BAP packet).
  • the IAB node determines the IAB topology associated with the received data packet by determining the IAB topology associated with the prior IAB node (which is also associated with the ingress backhaul link).
  • the ingress backhaul link on which the BAP PDU is received can be indicated to the BAP sublayer by the lower layers, e.g. the MAC sublayer that includes the scheduler.
  • an lAB-node When an lAB-node first connects to an lAB-node-DU, it receives the BAP address of its parent lAB-node(s) through the Information Element CellGroupConfig contained in a RRC message and defined in 3 GPP TS 38.331 specifications. Therefore, an lAB-node can associate a BAP address of a parent lAB-node with a link. Besides, in case of connection to a second parent, the lAB-node can detect if the second parent lAB-node-DU connects or not to the same lAB-Donor-CU as the first parent lAB-node-DU.
  • the lAB-node can associate the BAP address of each parent lAB-node with an IAB topology (e.g. primary or secondary). Therefore, the BAP sublayer of an lAB-node can establish a relation between the BAP address of each parent lAB-node, an IAB topology, and a link.
  • an IAB topology e.g. primary or secondary
  • the BAP sublayer of an lAB-node can establish a relation between the BAP address of each parent lAB-node, an IAB topology, and a link.
  • the child lAB-node belongs to the same IAB topology as the lAB-node-DU.
  • lAB-Donor-CU sends to the lAB-node- DU the F1AP message UE CONTEXT SETUP MESSAGE including the Information Element Configured BAP address, which is the BAP address configured for the corresponding child lAB-node.
  • This message and this Information Element are described in 3GPP TS 38.473 specification.
  • the BAP sublayer of an lAB-node can establish a relation between the BAP address of a child lAB-node, an IAB topology, and a link.
  • the IAB node determines the IAB topology associated with the received data packet based on the IAB node knowing to which IAB topology the IAB node belongs.
  • the BAP routing identifier (ID) of the generated packet is indicated by a table (not shown) called Uplink Traffic to Routing ID Mapping Configuration as described in TS 38.340 section 5.2.1.2.1.
  • the indicated BAP routing ID will refer to the topology to which the initiator IAB- node belongs.
  • a flag (or identifier) in the BAP header indicates the topology associated with the received packet.
  • the flag For a packet generated and first transmitted in the primary IAB topology of the boundary lAB-node, the flag may be set to ‘0’ (or ‘ 1’).
  • the flag For a packet generated and first transmitted in the secondary IAB topology of the boundary lAB-node, the flag may be set to ‘ 1’ (or ‘0’). If there are more than two topologies for inter-topology routing/re-routing, additional values (i.e. additional to ‘0’ and ‘ 1’) will be used so that each of the topologies can be identified from the value of the flag. A non-boundary node can ignore this flag.
  • a boundary node can use it to associate a link with a topology. Still, the boundary node associates the link with the BAP address of a parent or of a child as previously described.
  • the lAB-node may parse the header of the BAP packet and retrieve the destination address information or destination address in the DESTINATION field 305 (as described with reference to Figure 3).
  • the lAB-node checks whether the destination address information or destination address in the DESTINATION field 305 matches its own BAP address or not. If it is determined that the destination address in the DESTINATION field 305 actually matches the lAB-node’s own BAP address, the lAB-node removes the BAP header from the BAP PDU and delivers it to the upper layers.
  • the boundary node compares the DESTINATION field 305 with only one of its BAP addresses: the one associated with the same topology as the received BAP packet to be routed.
  • the lAB-node checks the routing configuration table or Backhaul routing configuration table 700 associated to the IAB topology identified at step 1004, looking for a routing option for the received BAP PDU.
  • a routing option may consist in finding an entry in the Backhaul routing configuration table 700 associated to the IAB topology which includes a routing identifier in the routing identifier (BAP ROUTING ID) field 501 matching the routing identifier in the BAP ROUTING ID field 30, (i.e. concatenation of the DESTINATION Field 305 and PATH field 306), in the BAP header of the received data packet.
  • BAP ROUTING ID routing identifier in the routing identifier
  • PATH field 306 i.e. concatenation of the DESTINATION Field 305 and PATH field 306
  • a routing option may consist in finding an entry in the Backhaul routing configuration table 700 associated to the IAB topology which includes a destination address in the DESTINATION field 5011 matching the destination address in the DESTINATION Field 305 in the BAP header of the received BAP PDU.
  • the lAB-node may discard the BAP PDU or store it for a new routing attempt (step 1007).
  • the lAB-node may check, at step 1008, the information in the update or rewriting field 703 (or information in the DESTINATION field 5011 where the Backhaul routing configuration table does not include the update or rewriting field 703 but instead reserves a certain value for at least part of the information in the DESTINATION field 5011 to indicate whether the routing identifier is to be updated) associated to the entry of routing configuration table identified at step 1005.
  • rewriting field 703 (or information in the DESTINATION field 5011) indicates that no BAP header rewriting is to be performed for routing the BAP PDU
  • the lAB-node identifies at step 1009 the egress backhaul (BH) link where the BAP PDU is to be routed by checking the Next Hop BAP Address field 502 associated to the entry of Backhaul routing configuration table identified at steps 1005 and 1006.
  • BH egress backhaul
  • the lAB-node determines at step 1010 if the egress BH link identified at step 1009 is available. If it is determined that the egress BH link is not available, the lAB-node may move back to step 1005 and check again the Backhaul routing configuration table 700 associated to the IAB topology identified at step 1004, looking for a new routing option for the received BAP PDU.
  • the lAB-node determines at step 1011 the BH RLC channel over which the BAP PDU is to be routed based on the information from the BH RLC Channel Mapping Configuration table, as discussed in Figure 5b, Figure 5c, Figure 9b and Figure 9c, and eventually routes the BAP PDU over the determined BH RLC channel.
  • Routing ID mapping table 800 shown in and described with respect to Figure 8, for which the previous routing identifier field 821 or ROUTING ID Field 821, i.e. DESTINATION field 8211 and PATH field 8212, of the PREVIOUS BAP ROUTING field 820 matches the routing identifier of the received data packet (i.e. the ROUTING ID field, i.e. DESTINATION Field 305 and PATH field 306, in the BAP header of the BAP PDU to be routed), and which the IAB topology in the previous topology field or Topology field 822 matches the ingress IAB topology identified at step 1004.
  • Routing ID mapping table 800 shown in and described with respect to Figure 8
  • the lAB-node replaces (updates or rewrites) the routing identifier in the received data packet with the new routing identifier for the matched entry by replacing (updating or rewriting) the destination address in the DESTINATION field 305 and path identifier in the PATH field 306 in the BAP header of the BAP PDU to be routed respectively by the destination address in the new destination field or DESTINATION field 8311 and path identifier in the new path identifier field or PATH field 8312, of the NEW BAP ROUTING field 830, associated to the considered PREVIOUS BAP ROUTING field 820 of the matched entry, as discussed in Figure 8.
  • the lAB-node also checks the new topology field 832 associated to the NEW BAP ROUTING field 830 considered at step 1012 and identifies the IAB topology associated with the egress BH link over which the BAP PDU is to be routed.
  • the lAB-node may move back to step 1005 and check again the Backhaul routing configuration table 700 associated to the IAB topology identified at step 1013, looking for a new routing option for the received BAP PDU.
  • an lAB-node may return several times to the step 1006 to find a new routing option for the same BH routing configuration table 700, in an example, the IAB- node memorizes or tracks each entry of the BH routing configuration table 700 that has been already checked (to avoid infinite loop).
  • the order of entries in a BH routing configuration table may reflect a priority level between routing options. For instance, the first entry in the BH routing configuration table matching the BAP Routing ID of a received data packet may indicate that a rewriting operation is not requested. If the egress BH link corresponding to this first entry is not available, the lAB-node may find a second entry (i.e. routing option) for which a rewriting operation is requested.
  • the lAB-node After header rewriting using the Routing ID mapping configuration table 800, the lAB-node will try to route the packet with the new BAP routing ID. If no available egress BH link is found with the new BAP Routing ID, the lAB-node may find an entry in the BH routing configuration table requesting to write back the BAP Routing ID in the header to the initial BAP Routing ID. Then, a third entry may be found in the BH routing configuration table 700 matching the initial BAP Routing ID (or at last least the destination BAP Address) and leading to try another egress BH link.
  • the data packet when a data packet has to cross a boundary node (like the lAB-node 612 in the figure 6), the data packet shall first be routed in a first topology toward the boundary node.
  • the boundary node When receiving this packet, the boundary node shall not keep the packet and deliver it to the upper layers, as this packet is actually not intended for the boundary node itself.
  • the destination BAP address of the data packet cannot be the BAP address of the boundary node in the first topology. Therefore, another BAP address shall be used as the destination BAP address.
  • this BAP address cannot be an address of any one of the lAB-nodes or an lAB-donor-DU in the first IAB topology.
  • This another BAP address to be used to route the packet up to the boundary node may be referred to as an alias BAP address.
  • the lAB-donor-CU controlling the first IAB topology therefore configures an alias BAP address of the real destination used in the routing identifier which is only used in the first topology before BAP header rewriting and is oblivious to the real destination.
  • the following limitations may be considered so as to reduce the configuration complexity and the processing time at a boundary node: the number of parent lAB-nodes may be limited to two parents, and all the child IAB nodes of a boundary node may be controlled by the same lAB-donor-CU as the boundary node in the primary topology. It means that the boundary node has a unique link to transmit data packets toward the secondary topology and to receive data packets from the secondary topology. In such case, a BH routing configuration table for the secondary topology is not necessary for the boundary node:
  • the boundary node For routing in the upstream direction, if the boundary node detects a rewriting with a NEW BAP ROUTING ID 831 associated to the secondary topology (as indicated by the field 832), then the boundary node can directly select the unique egress link associated to the secondary topology,
  • the boundary node can directly check the Routing ID mapping configuration table 800 to find an entry for header rewriting.
  • boundary node, lAB-node 612 (which belongs to the IAB topology 691), may be provided with or configured with two routing configuration tables (e.g. based on the routing configuration table 700 of Figure 7): one for the first IAB topology 691 (primary) and one for the second IAB topology 692 (secondary).
  • the routing configuration table for the first IAB topology 691 has at least the following entries:
  • the routing configuration table for the second IAB topology 692 has at least the following entries:
  • the boundary node, lAB-node 612 may be provided with or configured with a routing ID mapping table (e.g. based on the routing identifier mapping table 800 of Figure 8): as indicated below:
  • the IAB node 612 When the IAB node 612 receives a data packet having a routing identifier BAP Add Donor-DU 602: PATH2, the IAB node 612 checks the routing configuration table for the first IAB topology 691 for an entry having a matching routing identifier or destination address. The first entry indicates the next hop address is BAP Add Donor-DU 602 and the rewriting field has a value indicating ‘No’ which indicates that the routing identifier is not to be updated. A check is then made to see whether the egress backhaul link 631 to the next IAB node (lAB-donor-DU 602) with the address BAP Add Donor-DU 602 is available. If the egress backhaul link 631 (e.g.
  • the second entry in the routing configuration table for the first IAB topology 691 with the same destination address BAP Add Donor-DU 602 is identified. This second entry indicates (by the value indicating ‘Yes’ in the rewriting field 703) that the routing identifier of the received data packet is to be updated.
  • the IAB node 612 then checks the routing ID mapping table with BAP Add Donor-DU 602: PATH2 as the input to determine that the new routing identifier for the matched entry is BAP Add Donor-DU 603: PATH3 (associated with the second IAB topology).
  • the IAB node 612 updates the header of the received data packet to rewrite the routing identifier with the new routing identifier and then checks the routing configuration table for the second IAB topology 692 for an entry having a matching routing identifier or destination address with the new routing identifier Add Donor-DU 603 : PATH3 as the input.
  • the IAB node 612 Provided the egress BH link (link 635) to the next hop IAB node 611 is available, the IAB node 612 routes the updated data packet to the IAB node 611.
  • Figure 11 shows a schematic representation of an example communication device (apparatus) or station, in accordance with one or more example embodiments 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 (modules) or sub-routines containing instructions for a variety of operations and for implementing the invention.
  • the program elements include an element to implement a BAP entity which as discussed above is for routing data packets to a node in the IAB topology; and
  • the at least one communication interface 1102 may be connected to a communication network 1103, such as a radio access network of the system 100, over which digital data packets or frames or control frames are transmitted.
  • the frames are written from a FIFO sending memory in RAM 1112 to the communication interface for transmission or are read from the communication 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, a donor DU and an IAB node may comprise such a communication device 1100.
  • the central processing unit 1111 may be a single processing unit or processor or may comprise two or more processing units or 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:
  • ROM read only memory
  • RAM 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.
  • 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
  • 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.
  • CD-ROM compact disk
  • ZIP disk a digital versatile disk
  • USB key or a memory card
  • 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.
  • 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.
  • 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.
  • the apparatus is a programmable apparatus which uses software to implement the invention.
  • the present invention may be implemented in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC).
  • Figures 16a and 16b shows steps of example methods 1600 and 1604 for managing processing of data packets in accordance with embodiments of the present invention.
  • Methods 1600 and 1604 are performed at a first donor CU of a first IAB topology in an IAB communication system (or IAB arrangement) comprising at least two IAB topologies with each IAB topology comprising a plurality of IAB nodes or at least one IAB node.
  • the first donor CU may be IAB donor CU 610 of IAB topology 691 or IAB donor CU 620 of IAB topology 692 of the IAB communication system shown in Figure 6 or IAB- donor CU 1210 or lAB-donor CU 1220 of the IAB communication system shown in Figure 12.
  • the methods as shown in and described with respect to Figures 16a and 16b may be performed by software elements and/or hardware elements.
  • the first lAB-donor CU may be implemented in a communication device 1100 as shown in Figure 11 below with the methods as shown in Figures 16a and 16b being performed by the central processing unit 1111.
  • Figure 12 illustrates an example message flow 1200 for managing processing of data packets (e.g. configuring and managing BAP PDU routing over a plurality of IAB networks or IAB topologies) according to embodiments and examples of the invention.
  • Figure 12 illustrates an example message flow which includes an example message for providing the data packet routing configuration information as set in the method shown and described with respect to Figure 16a and also includes example messages for carrying out the steps as set in the method shown and described with respect to Figure 16b.
  • An lAB-node 1211 (such as IAB node 612), belonging to a first IAB network, also referred to as first topology, (such as IAB network 691), managed by a first lAB-donor CU 1210 (such as lAB-donor CU 610), is acting as a boundary node with a second IAB network, also referred to as second topology, (such as IAB network 692), managed by a second IAB- donor CU 1220 (such as lAB-donor CU 620).
  • the second IAB topology includes at least one IAB donor Distributed Unit (DU) (such as lAB-donor-DU 603 in the example shown in Figure 6).
  • DU IAB donor Distributed Unit
  • the first lAB-donor CU 1210 may provide, to at least one IAB node of the first IAB topology (e.g. IAB nodes 612, 613), data packet routing configuration information for routing data packets over at least the first IAB topology (step 1602 of Figure 16a).
  • the data packet routing configuration information comprises a routing configuration table and a routing identifier mapping table.
  • the routing configuration table comprises at least one entry including: a routing identifier field for a routing identifier, the routing identifier field comprising 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 IAB node; a next hop address field for indicating an address of a next IAB node in the routing path identified by the path identifier; and a field for indicating whether a routing identifier of a received data packet matching the routing identifier in the routing identifier field is to be updated.
  • the routing identifier mapping information comprises a routing identifier mapping table having at least one entry including: a previous routing identifier field for a routing identifier; a previous topology field for indicating the IAB topology associated with the routing identifier in the previous routing identifier field; a new routing identifier field for a routing identifier; and a new topology field for indicating the IAB topology associated with the routing identifier in the new routing identifier field.
  • the field for indicating whether a routing identifier of a received data packet matching the routing identifier in the routing identifier field is to be updated comprises an update field (e.g.
  • rewriting field 703 wherein a value in the update field indicates the routing identifier is to be updated; or at least part of the next hop address field, wherein a certain value in at least part of the next hop address field indicates the routing identifier is to be updated.
  • the step of providing, to at least one IAB node of the first IAB topology comprises providing the routing configuration table in a routing configuration Information Element, IE, of a configuration message for transmission to the at least one IAB node and providing the routing identifier mapping table in a routing identifier mapping Information Element, IE, of a configuration message for transmission to the at least one IAB node.
  • the BH Routing Information Added List Information Element (IE), defined in section 9.2.9.1 of 3GPP TS 38.473 vl6.4.0, is modified to allow the lAB-donor-CU to configure the rewriting field 703.
  • the IE for the routing configuration table may be included in the same message as the IE for the routing identifier mapping table or in different messages.
  • the configuration message may be the BAP MAPPING CONFIGURATION message (F1AP protocol), as described in 3GPP TS 38.473 vl6.4.0.
  • the data packet routing configuration information may further comprise information for configuring a backhaul RLC channel mapping configuration table (for example a BH RLC channel mapping configuration table as described above with reference to Figure 9a).
  • a backhaul RLC channel mapping configuration table for example a BH RLC channel mapping configuration table as described above with reference to Figure 9a.
  • the BAP layer BH RLC channel mapping Information List Information Element (IE), defined in section 9.3.1.98 of 3GPP TS 38.473 vl6.4.0, may be modified to allow the lAB-donor-CU to configure the BH RLC channel mapping configuration table 900 of an lAB-node according to some aspects of the invention.
  • the data packet routing configuration information may additionally or alternatively comprise information for configuring an uplink traffic to backhaul RLC channel mapping configuration table as discussed above with reference to Figure 9b.
  • each entry of the Uplink Traffic to BH RLC Channel Mapping Configuration table 921 contains a traffic type specifier 521, which is indicated by UL UP TNL Information IE for Fl -U packets or Non-UP Traffic Type IE for non-Fl-U packets as defined in TS 38.473.
  • the other fields 522, 922, and 523 of table 921 may be indicated by the BH Information IE defined in section 9.3.1.114 of 3GPP TS 38.473 vl 6.4.0 modified to allow the lAB-donor-CU to configure the BH RLC channel mapping configuration table 921 of an lAB-node according to some aspects of the invention.
  • the IES for the BH RLC channel mapping configuration table and the uplink traffic to BH RLC channel mapping configuration table may be included in the same message (for example, including the same message as the IEs for the routing configuration table and the routing identifier mapping table) or in different messages.
  • the configuration messages (which may be included in the Configuration request 1241, 1251 shown in Figure 12) may be BAP MAPPING CONFIGURATION messages (F1AP protocol), as described in 3GPP TS 38.473 vl6.4.0.
  • the data packet routing configuration information may be provided to at least one IAB node of a second IAB topology of the at least two IAB topologies (in addition to the at least one IAB node of the first IAB topology).
  • the lAB-node 1211 (such as IAB node 612) acts as a boundary node, as discussed above with reference to Figure 6, in response to detecting and connecting with a second lAB-node (such as IAB node 611), belonging to the second IAB network (such as IAB network 691), managed by the second lAB-donor CU 1220 (such as lAB-donor CU 620).
  • the MT part of lAB-node 1211 When the MT part of lAB-node 1211 is initially connecting to the network, it will perform a cell search procedure, as defined in 3 GPP 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 lAB-node 1211 will determine if it can connect to a new cell, i.e. a new lAB-node, such as lAB-node 611.
  • a new lAB-node such as lAB-node 611.
  • lAB-node 1211 may notify its lAB-donor CU 1210 that it has established dual connectivity with an lAB-node that belongs to a neighbor IAB network (for example, by sending a DUAL CU CONNECTION NOTIFICATION message). In other words, the lAB-node 1211 may transmit a notification to the donor Central Unit, CU, 1210 of the first IAB network, indicating the IAB node 1211 is capable of routing data packets to one or more IAB nodes in the second IAB network.
  • the lAB-donor CU 1210 wishes to establish inter-topology routing, i.e.
  • the lAB-donor CU 1210 sends a request or notification, such as the OFFLOAD NEGOCIATION REQUEST message 1231, to the IAB- Donor CU 1220 for establishing routing of data packets between the first IAB network or topology and the second IAB network topology (step 1606 of Figure 16b).
  • a request or notification such as the OFFLOAD NEGOCIATION REQUEST message 1231
  • the lAB-Donor CU 1210 receives, from the lAB-Donor CU 1220, a response, such as the OFFLOAD NEGOCIATION RESPONSE message 1232.
  • the response includes acknowledgement information indicating whether the lAB-Donor CU 1220 has accepted the request and when the lAB-Donor CU 1220 has accepted the request, configuration information relating to one or more IAB nodes in the second IAB topology for identifying routing paths for routing data packets between at least one IAB node of the first IAB topology and at least one IAB node in the second IAB topology. More details of the configuration information and the OFFLOAD NEGOCIATION RESPONSE message 1232 are set out below.
  • message 1231 may be a new Xn application protocol (XnAP) message.
  • XnAP protocol is defined in the 3GPP TS 38.423 specification.
  • lAB-donor CU 1220 may send a response to the lAB-donor CU 1210, for example, using the OFFLOAD NEGOCIATION RESPONSE message 1232.
  • the response may indicate whether the lAB-donor CU 1220 can accommodate the request and has accepted the offload request.
  • the response may include configuration information relating to one or more IAB nodes in the second IAB topology for identifying routing paths for routing data packets between at least one IAB node of the first IAB topology and at least one IAB node in the second IAB topology.
  • the lAB-donor CU 1210 can provide the data packet routing configuration information to the at least one IAB node (in the first IAB topology and in some cases also to at least one IAB node in the second IAB topology) based on the configuration information received from the lAB-donor CU 1220. More details of the configuration information and the OFFLOAD NEGOCIATION RESPONSE message 1232 are set out below.
  • the offload notification or message 1231 may include all or part of the following IES:
  • IE Information Element
  • an IE identifying the lAB-Donor-DU (such as lAB-donor-DU 603 in Figure 6) in the secondary topology (e.g. IP address, BAP address) that the lAB-Donor CU 1210 intends to use to send or to receive the data packets on the wired backhaul
  • an IE identifying the boundary node 1211 involved in the routing through the different topologies for instance the IP address or the BAP address of the boundary node in the secondary topology
  • an IE indicating the destination of the offloaded data packets in the downstream direction, either the boundary node 1211 itself or another lAB-node belonging to or of the first IAB topology (i.e. a child lAB-node for the boundary node).
  • This indication may be limited to one bit where, for instance, the value ‘ 1’ means the destination is the boundary node, and the value ‘0’ means the destination is another lAB-node.
  • the IE may comprise one bit where the value of the one bit is used to indicate whether the destination of the offloaded data packets in the downstream direction is either the boundary node or another lAB-node of the first IAB topology.
  • the lAB-Donor- CU 1220 may adapt the configuration of the lAB-Donor-DU generating the BAP header of the offloaded data packets.
  • the lAB-Donor-DU may be instructed by the lAB-Donor-CU 1220 to set the destination BAP address field of the header with the BAP address of the boundary node in the second IAB topology IAB topology.
  • the IAB- Donor-DU may be instructed to set the destination BAP address field of the header with an alias BAP address of the real destination in the first IAB topology (i.e.
  • the lAB-Donor CU 1210 may also indicate the BH RLC Channel ID it intends to use for the boundary node in the primary topology on the ingress link in case of upstream transmission, or on the egress link in case of downstream transmission.
  • the lAB-Donor CU 1220 can determine if the BH RLC Channel ID to be used by the lAB-Donor CU 1210 is a new one or one already used for an offload transmission already set-up. In case of a new one (i.e. 1 : 1 mapping with one bearer per RLC channel) for downstream transmission, the lAB-Donor CU 1220 can understand it cannot reuse the same BH RLC channel ID used for a previous downstream offload (e.g. N: 1 mapping where several bearers having similar QoS requirements are multiplexed over the same RLC channel), as this would lead to two identical entries in the BH RLC channel mapping configuration table 900 with two different egress BH RLC Channel ID 514 as output.
  • N 1 mapping where several bearers having similar QoS requirements are multiplexed over the same RLC channel
  • the lAB-Donor CU 1210 indicates a BH RLC channel ID already used, the lAB-Donor CU 1220 can understand it shall also reuse a BH RLC channel ID already used for a previous upstream offload.
  • the lAB-donor CU 1220 may also include in another IE in the message 1231 information related to the content of the fields for the primary topology (i.e. the fields 8211 and 8212 for the entry to be added in case of upstream transmission, or the fields 8311 and 8312 for the entry to be added in case of downstream transmission).
  • the lAB-donor CU 1220 may also include in another IE in the message 1231 information related to the content of the fields for the primary topology (i.e. the fields 511 and 514 for the entry to be added in case of downstream transmission, or the fields 512 and 513 for the entry to be added in case of upstream transmission).
  • the lAB-donor-CU 1210 may concatenate several offload requests for different BAP Routing ID in the primary topology.
  • the message 1231 contains a list of items, each item including part of or all the aforementioned information elements.
  • lAB- donor CU 1220 may determine if it can fulfill the request for offload according to the status of its IAB network (e.g. the load or REF of the links on the paths toward the boundary node over the secondary topology). In other words, the lAB-donor CU 1220 may determine whether it can accommodate the routing or offloading data packets from the first IAB network to the second IAB network or from the second IAB network to the first IAB network.
  • the lAB-donor CU 1220 may determine one or more alias BAP addresses, to be used for routing downstream data packets via the second topology up to the boundary node 1211.
  • the one or more alias BAP addresses are only used in the second topology before BAP header rewriting at the boundary node 1211 to avoid routing ID or BAP address collision.
  • lAB-donor CU 1220 may send a response to the lAB-donor CU 1210 using the OFFLOAD NEGOCIATION RESPONSE message 1232.
  • message 1232 may be a new Xn application protocol (XnAP) message.
  • the offload notification or message 1232 (for example, the configuration information included in the response from the lAB-donor CU 1220) may include:
  • lAB-Donor-DU such as lAB-donor-DU 603 in Figure 6
  • secondary topology e.g. IP address, BAP address
  • the lAB-Donor CU 1210 can understand if the BH RLC Channel ID to be used by the lAB-Donor CU 1220 is a new one (1 : 1 bearer mapping) or one already used for an offload transmission already set-up (N: 1 bearer mapping).
  • the lAB-donor CU 1210 may also include in another IE in the message 1232 information related to the content of the fields for the secondary topology (i.e. the fields 5011, 5012, 502, 703 for the one or more entries entry to be added).
  • the lAB-donor CU 1210 may also include in another IE in the message 1232 information related to the content of the fields related to the primary topology (i.e. the fields 8211 and 8212 for the entry to be added in case of downstream transmission, or the fields 8311 and 8312 for the entry to be added in case of upstream transmission).
  • the lAB-donor CU 1210 may also include another IE in the message 1232 information related to the content of the fields for the primary topology (i.e. the fields 511 and 514 for the entry to be added in case of upstream transmission, or the fields 512 and 513 for the entry to be added in case of downstream transmission).
  • the lAB-donor-CU 1220 may concatenate several offload responses.
  • the message 1232 contains a list of items, each item including part of or all the aforementioned information elements.
  • the lAB-Donor CU 1220 may use the IES in the message 1232 to make a new proposal, for instance by indicating another lAB-Donor-DU to be used to send or to receive packets, another bearer mapping on the BH RLC channel, another boundary lAB-node, etc.
  • the lAB-Donor CU 1210 may formulate a new OFFLOAD NEGOCIATION REQUEST 1231 by adapting the content of IEs accordingly based on the new proposal.
  • lAB-donor CU 1210 may also determine one or more upstream alias BAP addresses, to be further used by the lAB-nodes belonging to the first topology when routing upstream data packets via the first topology managed by lAB-donor CU 1210, up to the boundary node 1211.
  • the one or more alias BAP addresses are only used in the first topology before BAP header rewriting at the boundary node 1211 to avoid routing ID or BAP address collision.
  • lAB-Donor CU 1220 may then configure the lAB-nodes it controls. In particular it may send the message CONFIGURATION REQUEST 1241 to the boundary node 1211. lAB-Donor CU 1220 may then also configure the lAB-nodes it controls. In particular it may send the message CONFIGURATION REQUEST 1251 to the boundary node 1211.
  • the CONFIGURATION REQUEST messages 1241 and 1251 may be a BAP MAPPING CONFIGURATION message (F1AP protocol), as described in 3GPP TS 38.473 vl6.4.0.
  • Figure 19 shows steps of an example method 1900 for processing data packets in accordance with a third embodiment of the present invention.
  • Method 1900 is performed at an IAB node in an IAB communication system (or IAB arrangement) comprising at least two IAB topologies with each IAB topology comprising a plurality of IAB nodes or at least one IAB node.
  • the IAB node performing the method 1900 may be an IAB node of either a first IAB topology (or first IAB network) 691 or a second IAB topology (or second IAB network) 692.
  • the IAB node belongs to or is part of either the first IAB topology 691 or the second IAB topology 692.
  • the IAB node may be an lAB-donor DU (such as 601, 602, 603) for data packets to be routed in the downstream direction or an initiator IAB node (e.g. an initiator IAB node may be an IAB node sending data from an UE (i.e.
  • the method as shown in and described with respect to Figure 19 may be performed by software elements and/or hardware elements.
  • the IAB node may be implemented in a communication device 1100 as shown in and described with reference to Figure 11 with the method as shown in and described with respect to Figure 19 being performed by one or more processing units, such as the central processing unit 1111.
  • 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 method shown in Figure 19.
  • the method of Figure 19 may be applied for routing data packets in the upstream or downstream direction.
  • the IAB node receives a data packet (for example, a BAP packet or BAP PDU).
  • the data packet includes a routing identifier for routing the received data packet to a destination IAB node.
  • the routing identifier may include a destination address of the destination IAB node for the data packet and a path identifier identifying a routing path for the data packet to the destination IAB node.
  • 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).
  • the IAB node may receive the data packet from a prior IAB node over an ingress BH link (i.e.
  • the IAB node is a relay or intermediate IAB node such as IAB node 612 or IAB node 611) or the IAB node may generate the data packet in one part of the IAB node (such as in one part or sublayer of a BAP entity of the IAB node) and receive the generated data packet at another part of the IAB node (such as to another part or sublayer of a BAP entity of the IAB node) for routing to another IAB node. In the latter case, the IAB node is acting as an initiator IAB node.
  • the IAB topology associated with the received data packet is one of the at least two IAB topologies and the IAB topology associated with a next IAB node to which the data packet is to be routed is the same IAB topology or another one of the at least two IAB topologies.
  • the IAB node 612 of Figure 6 is part of or belongs to the first IAB topology 691 and on receipt of a data packet for routing, depending on the routing identifier, the IAB node 612 may route the data packet to a next IAB node in the first IAB topology 691 or the second IAB topology 692.
  • the IAB node determines an IAB topology associated with the data packet. For example, when the IAB node receives the data packet from a prior IAB node over an ingress BH link, the IAB node determines the IAB topology associated with the received data packet by determining the IAB topology associated with the prior IAB node (which is also associated with the ingress backhaul link). As discussed above with reference to Figure 10, a BAP sublayer of the IAB node can establish a relationship between the BAP address of a parent or child IAB node, a topology and backhaul link which can then be used to determine the IAB topology associated with the received data packet. In an example when the IAB node is an initiator IAB node (e.g.
  • the IAB node determines the IAB topology associated with the received data packet based on the IAB node knowing to which IAB topology the IAB node belongs. For example, for an initiator lAB-node, the BAP routing identifier (ID) of the generated packet is indicated by a table (not shown) called Uplink Traffic to Routing ID Mapping Configuration as described in TS 38.340 section 5.2.1.2.1. The indicated BAP routing ID will refer to the topology to which the initiator lAB-node belongs.
  • the IAB node determines whether the received data packet is to be delivered to the upper layers of the IAB node. For example, determining whether a received data packet is to be delivered to upper layers of the IAB node comprises comparing the destination address of the routing identifier of the received data packet with an address of the IAB node associated with the respective determined IAB topology previously. In other words, when the IAB is a non-boundary node having a single BAP address associated with IAB topology to which it belongs, it means the IAB node checks whether the destination address information or destination address in the DESTINATION field 305 of the routing identifier matches the IAB node’s own single BAP address or not.
  • the boundary node compares the DESTINATION field 305 of the routing identifier with only one of its BAP addresses: the one associated with the same topology as the BAP packet to be routed. If the packet is not delivered to the upper layers (i.e. in response to determining that the received data packet is not to be delivered to upper layers), then, at step 1908, the IAB node determines, based on routing configuration information associated with the determined IAB topology and the routing identifier of the received data packet, whether there is an available egress backhaul link for routing the data (e.g. the received data packet).
  • the IAB node checks for a routing option for the received data packet based on the routing configuration information associated with the determined IAB topology and the routing identifier of the received data packet and if there is a routing option, the IAB node then checks whether the egress backhaul link of the routing option is available.
  • the routing configuration information is a routing configuration table (or backhaul routing configuration table or BAP routing configuration table) such as the routing configuration table 500 shown in and described with respect to Figure 5a or alternatively, the routing configuration table 700 shown in and described with respect to Figure 7 (or alternatively the routing configuration table 1500 shown in Figure 15).
  • the IAB node may determine whether there is an egress backhaul link by checking for an entry in the Backhaul routing configuration table 500 (alternately 700 or 1500) associated to the determined IAB topology which includes a routing identifier in the routing identifier (BAP ROUTING ID) field 501 matching the routing identifier in the BAP ROUTING ID field 30, (i.e.
  • the lAB-node When an entry is found, the lAB-node identifies the egress backhaul (BH) link where the BAP PDU is to be routed, for example, by checking the Next Hop BAP Address field 502 associated to the found entry of Backhaul routing configuration table. The IAB node then determines if the identified egress BH link is available.
  • BH egress backhaul
  • the lAB-node determines at step 1910 whether the routing identifier of the received data packet can be updated. For example, the lAB-node may check the information in the update or rewriting field 703 of the Backhaul routing configuration table 700 (or the value in at least part of the next hop address field 502 when a specific value in at least part of the next hop address field is used to indicate whether header rewriting is to be performed as discussed above) for the entry matching the routing identifier in the BAP ROUTING ID field 30, (i.e.
  • the IAB nodes checks if an entry in the BAP Routing ID mapping table (or Header rewriting configuration) 800 matches the routing identifier in the BAP ROUTING ID field 30 in the BAP header of the data packet.
  • the IAB node determines, for example based on routing identifier mapping information and the routing identifier of the received data packet, a new routing identifier and an IAB topology associated with the new routing identifier (e.g. the IAB topology associated with a next IAB node (egress backhaul link) as determined by the new routing identifier).
  • a new routing identifier and an IAB topology associated with the new routing identifier e.g. the IAB topology associated with a next IAB node (egress backhaul link) as determined by the new routing identifier.
  • the routing identifier mapping information is a routing identifier mapping table (or BAP routing identifier mapping table) comprising at least one entry, with each entry including a field for indicating the IAB topology associated with the routing identifier to be updated and/or a field for indicating the IAB topology associated with the new routing identifier.
  • the routing identifier mapping table may include a previous routing identifier field for a routing identifier, a previous topology field for indicating the IAB topology associated with the routing identifier in the previous routing identifier field, a new or next routing identifier field for a routing identifier, and a new topology field for indicating the IAB topology associated with the routing identifier in the new routing identifier field, where an alternative routing option (e.g. at least one redundant PATH) is available.
  • the routing identifier mapping table is the routing identifier mapping table shown in and described with respect to Figure 8.
  • the IAB node may identify a new routing identifier and the IAB topology associated with the new routing identifier (e.g.
  • the IAB node determines a match with an entry, the IAB node uses the routing identifier in the new routing identifier field of the matched entry as the identified new routing identifier and uses the IAB topology indicated by the new topology field of the matched entry as the identified or determined IAB topology associated with the new routing identifier.
  • the information on the IAB topology in the topology fields provides an indication as to whether the data packet is to be routed to the same or to another IAB topology.
  • the lAB-node identifies, based on routing identifier mapping information and the routing identifier of the received data packet, a new routing identifier and an IAB topology associated with the new routing identifier.
  • the lAB-node may determine a new routing identifier and IAB topology associated with the new routing identifier by checking for an entry in the Routing ID mapping table, such as Routing ID mapping table 800 shown in and described with respect to Figure 8, for which the previous routing identifier field 821 or ROUTING ID Field 821, i.e. DESTINATION field 8211 and PATH field 8212, of the PREVIOUS BAP ROUTING field 820 matches the routing identifier of the received data packet (i.e. the ROUTING ID field, i.e. DESTINATION Field 305 and PATH field 306, in the BAP header of the BAP PDU to be routed), and which the IAB topology in the previous topology field or Topology field 822 matches the IAB topology identified previously.
  • Routing ID mapping table 800 shown in and described with respect to Figure 8
  • the previous routing identifier field 821 or ROUTING ID Field 821 i.e. DESTINATION field 8211 and PATH field 8212
  • the IAB node updates the received data packet by updating the routing identifier of the received data packet with the identified or determined new routing identifier to provide an updated data packet including the identified new routing identifier.
  • the routing identifier of the received data may be replaced or rewritten with the new routing identifier.
  • the lAB-node moves back to step 1906 and repeats at least step 1906 so as to check first whether the updated data packet is to be delivered to the upper layers.
  • the lAB-node may repeat, for at least one cycle, steps 1906 to 1912 for an updated data packet until it is determined that an updated data packet is to be delivered to the upper layers, or it is determined there is an available egress backhaul link for routing data or it is determined that the routing identifier is not to be updated.
  • the lAB-node determines, based on the routing configuration information associated with the determined IAB topology associated with the new routing identifier of the updated data packet and the new routing identifier, whether there is an egress backhaul link for routing data to a next IAB node (as per step 1908).
  • the IAB node may determine a next IAB node (and the egress backhaul link associated with the next IAB node) by checking the routing configuration table associated with the identified IAB topology (which is associated with the egress backhaul link) to determine whether the identified new routing identifier matches a routing identifier in the routing identifier field of an entry or whether a destination address of the new routing identifier matches a destination address in the destination address field of an entry.
  • the IAB node uses the next hop address in the next hop address field of the matched entry to determine the next IAB node and routes the updated data packet to the next IAB node over the associated egress backhaul link.
  • the IAB- node may then determine whether the new routing identifier of the updated data packet can be updated (as per step 1910). When the new routing identifier can be updated, the lAB-node determines another new routing identifier and an IAB topology associated with the another new routing identifier and then updates the updated data packet by updating the new routing identifier with the determined another new routing identifier to provide a new updated data packet (as per step 1912). The flow then returns again to step 1906.
  • the method 1900 may further comprise routing the data packet over the available egress backhaul link to the next lAB-node.
  • the method 1900 may further comprise selecting a backhaul RLC channel if an egress backhaul link to route the data packet is identified and available. The selection is based on the identified IAB topology associated with the next IAB node (e.g. which is also associated with the egress backhaul link) and backhaul RLC channel mapping information.
  • the backhaul RLC channel mapping information is a backhaul (BH) RLC channel mapping configuration table (or BAP BH RLC channel mapping configuration table) such as the BH RLC channel mapping configuration table shown in and described with respect to Figures 5b or 5c or Figures 9a or 9b.
  • BH backhaul
  • BAP BH RLC channel mapping configuration table such as the BH RLC channel mapping configuration table shown in and described with respect to Figures 5b or 5c or Figures 9a or 9b.
  • the BH RLC channel mapping information may provide information such as that shown in Figure 5(b) or Figure 5(c) where the fields 511 and 522 indicate an identifier of an egress link, and where the field 512 indicates an identifier of an ingress link.
  • an ingress link identifier and an egress link identifier indicates both a link and a topology (primary /MCG or secondary/SCG).
  • the BH RLC channel mapping configuration table corresponds to the table as described with respect to Figure 5b or Figure 9a.
  • selecting a backhaul RLC channel for the egress backhaul link may comprise checking the backhaul RLC channel mapping configuration table to determine whether a backhaul RLC channel ID of the ingress backhaul link, an address of the prior IAB node, the determined IAB topology associated with the prior IAB node (e.g. ingress backhaul link), an address of the next IAB node and the identified IAB topology associated with the next IAB node (e.g.
  • egress backhaul link match the respective fields of an entry in the backhaul RLC channel mapping configuration table.
  • a match with an entry is determined, using the egress backhaul RLC channel ID of the matched entry to select the backhaul RLC channel for the egress backhaul link.
  • the BH RLC channel mapping configuration table corresponds to the table as described with respect to Figure 5c or Figure 9b.
  • selecting a backhaul RLC channel for the egress backhaul link may comprise checking the backhaul RLC channel mapping configuration table to determine whether a traffic type of data in the received data packet, an address of the next IAB node and the identified IAB topology associated with the next IAB node (e.g. egress backhaul link) match the respective fields of an entry in the backhaul RLC channel mapping configuration table. When a match with an entry is determined, using the egress backhaul RLC channel ID of the matched entry to select the backhaul RLC channel for the egress backhaul link.
  • step 1906 By determining whether the updated data packet is to be delivered to upper layers (i.e. step 1906 is repeated after the received data packet is updated or rewritten by updating the routing identifier of the received data packet with the determined new routing identifier to provide the updated data packet), a check can be made to determine whether the updated data packet has reached its destination and should be delivered to the upper layers. If no check is made after the received data packet is updated or rewritten, then data packets may be discarded even when they have reached their correct destination. For example, a data packet may be routed from the first topology 691 to the second topology 692 and the destination IAB node may be the boundary node 612 in the second topology 692.
  • step 1906 Without checking whether the updated data packet should be delivered to the upper layers (in step 1906) after the received data packet has been updated to the address of the boundary node 612 in the second topology), the updated data packet will likely be discarded at the boundary node. Repeating the determination made at step 1906 means that the additional check after the data packet has been updated or rewritten can be easily integrated into the existing flows without requiring significant changes. Furthermore, due to repeating the determination step 1906, it is not required in a boundary node to first identify if a received packet has to be transferred to a different IAB topology. This will be detected when checking if the routing identifier of the packet has to be updated or not.
  • Figure 18 illustrates, using a flowchart 1800, another example method for processing data packets (e.g. for managing BAP PDU (or data packet) routing over one or more IAB networks (one or more IAB topologies)) according to embodiments and examples of the invention.
  • 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 example method shown in Figure 18.
  • the method of Figure 18 may be applied for routing data packets in the upstream or downstream direction.
  • the method of Figure 18 may use the configuration tables of Figure 5a (or Figure 7 alternately or Figure 15) and Figure 8.
  • the process starts at step 1801 where an lAB-node, such as IAB node 612, receives a BAP packet, or BAP PDU, it should route.
  • an lAB-node such as IAB node 612
  • the lAB-node identifies the IAB topology associated with the BAP packet to be routed (e.g. the received BAP packet). For example, the IAB node may determine the IAB topology associated with the received data packet according to one or more of the examples as described above with respect to step 1004 of figure 10.
  • the lAB-node checks whether the destination address information or destination address in the DESTINATION field 305 of the header of the received BAP packet (for example, as described above with reference to Figure 3) matches its own BAP address or not. If it is determined that the destination address in the DESTINATION field 305 actually matches the lAB-node’ s own BAP address, the lAB-node removes the BAP header from the BAP PDU and delivers it to the upper layers (step 1808). When the lAB-node is a boundary node, the boundary node compares the destination address in the DESTINATION field 305 with only one of its BAP addresses: the one associated with the same topology as the BAP packet to be routed.
  • the lAB-node checks, based on the routing identifier of the data packet, routing configuration information, such as the routing configuration table or Backhaul routing configuration table 500 (or 700 alternately), associated to the IAB topology identified at step 1802, looking for a routing option for the BAP packet to be routed.
  • routing configuration information such as the routing configuration table or Backhaul routing configuration table 500 (or 700 alternately)
  • the IAB- node determines whether there is an egress backhaul link for routing the data (e.g. the received data packet).
  • a routing option may consist in finding an entry in the Backhaul routing configuration table 500 (alternately 700) associated to the identified IAB topology which includes a routing identifier in the routing identifier (BAP ROUTING ID) field 501 matching the routing identifier in the BAP ROUTING ID field 30, (i.e. concatenation of the DESTINATION Field 305 and PATH field 306), in the BAP header of the BAP packet.
  • BAP ROUTING ID routing identifier in the routing identifier
  • PATH field 306 i.e. concatenation of the DESTINATION Field 305 and PATH field 306
  • a routing option may consist in finding an entry in the Backhaul routing configuration table 500 described above with respect to Figure 5(a) (alternately Backhaul routing configuration table 700 described above with respect to Figure 7) associated to the identified IAB topology which includes a destination address in the DESTINATION field 5011 matching the destination address in the DESTINATION Field 305 in the BAP header of the BAP packet.
  • the lAB-node identifies at step 1813 the egress backhaul (BH) link where the BAP PDU is to be routed, for example, by checking the Next Hop BAP Address field 502 associated to the entry of Backhaul routing configuration table identified at steps 1811 and 1812.
  • BH egress backhaul
  • the lAB-node determines at step 1814 if the egress BH link identified at step 1813 is available. If it is determined that the egress BH link is not available, the lAB-node may move back to step 1811 and check again the Backhaul routing configuration table for a new routing option.
  • the lAB-node determines at step 1815 the BH RLC channel over which the BAP PDU is to be routed based on the information from the BH RLC Channel Mapping Configuration table, as discussed with reference to Figure 5b, Figure 5c, Figure 9b and Figure 9c, and eventually routes the BAP PDU over the determined BH RLC channel.
  • the BH RLC channel mapping information may provide information such as that shown in Figure 5(b) or Figure 5(c) where the fields 511 and 522 indicate an identifier of an egress link, and where the field 512 indicates an identifier of an ingress link.
  • an ingress link identifier and an egress link identifier indicate both a link and a topology (primary /MCG or secondary/SCG).
  • the lAB-node may check if re-routing through header rewriting is possible. For example, at step 1816, the lAB-node may check the information in the update or rewriting field 703 of the Backhaul routing configuration table 700 (or the value in at least part of the next hop address field 502 when a specific value in at least part of the next hop address field is used to indicate whether header rewriting is to be performed as discussed above) for the entry matching the routing identifier in the BAP ROUTING ID field 30, (i.e.
  • the IAB nodes checks if an entry in the BAP Routing ID mapping table (or Header rewriting configuration) 800 matches the routing identifier in the BAP ROUTING ID field 30 in the BAP header of the BAP packet.
  • rewriting field 703 (or the value in at least part of the next hop address field 502) indicates that no BAP header rewriting can be performed for routing the BAP PDU, or if no entry is found in the BAP Routing ID mapping table 800, the lAB-node may discard the BAP PDU or store it for a new routing attempt (step 1819).
  • rewriting field 703 indicates that some BAP header rewriting can be performed for routing the BAP PDU, or if an entry is found in the BAP Routing ID mapping table 800
  • the lAB-node identifies, based on routing identifier mapping information and the routing identifier of the BAP packet, a new routing identifier and an associated IAB topology, for example, by checking for an entry in the Routing ID mapping table, such as Routing ID mapping table 800 shown in and described with respect to Figure 8, for which the previous routing identifier field 821 or ROUTING ID Field 821, i.e.
  • DESTINATION field 8211 and PATH field 8212, of the PREVIOUS BAP ROUTING field 820 matches the routing identifier of the received data packet (i.e. the ROUTING ID field, i.e. DESTINATION Field 305 and PATH field 306, in the BAP header of the BAP PDU to be routed), and which the IAB topology in the previous topology field or Topology field 822 matches the ingress IAB topology identified at step 1802.
  • the lAB-node replaces (updates or rewrites) the routing identifier in the BAP packet with the new routing identifier, for example, by replacing (updating or rewriting) the destination address in the DESTINATION field 305 and path identifier in the PATH field 306 in the BAP header of the BAP PDU to be routed respectively by the destination address in the new destination field or DESTINATION field 8311 and path identifier in the new path identifier field or PATH field 8312, of the NEW BAP ROUTING field 830, associated to the considered PREVIOUS BAP ROUTING field 820 of the matched entry, as discussed in Figure 8.
  • the lAB-node determines the IAB topology associated with the new routing identifier, for example, by checking the new topology field 832 associated to the NEW BAP ROUTING field 830 considered at step 1817 and identifying the IAB topology associated with the egress BH link over which the BAP PDU (e.g. the received BAP data packet which has been updated with the new routing identifier) is to be routed.
  • the BAP PDU e.g. the received BAP data packet which has been updated with the new routing identifier
  • the lAB-node moves back to step 1803 and checks whether the destination address information or destination address in the DESTINATION field 305 of the updated header of the updated BAP packet matches its own BAP address or not. As discussed above, if it is determined that the destination address in the DESTINATION field 305 of the updated BAP packet actually matches the IAB-node’ s own BAP address, the lAB-node removes the BAP header from the BAP PDU and delivers it to the upper layers (step 1808).
  • the boundary node compares the destination address in the DESTINATION field 305 with only one of its BAP addresses: the one associated with the determined IAB topology associated with the new routing identifier of the updated BAP packet to be routed.
  • the IAB-node tries to route the BAP packet with the new routing identifier if the destination address information does not match its own BAP address by determining a new routing option for the received BAP PDU, based on routing configuration information associated with the determined IAB topology associated with the new routing identifier and the identified new routing identifier, for example, by checking again, at step 1811, the Backhaul routing configuration table 500 (alternately 700) associated to the new IAB topology identified at step 1818, looking for a new routing option for the received BAP PDU and following the steps 1812-1819 as before.
  • a BAP packet having to transit from one topology to another should arrive at the boundary node with a destination BAP address different from the boundary node’s BAP address in the ingress topology (i.e. it is an alias of the real destination in the other topology).
  • the BAP operations may be summarized in a unified manner for non-boundary nodes and boundary nodes with the following steps:
  • An IAB node receiving a BAP data packet to be routed first determines the IAB topology associated with the data packet. This IAB topology is the ingress topology for the BAP packet, which is also associated with the ingress backhaul link.
  • the IAB node determines whether the packet has to be delivered to the upper layers by comparing the destination BAP address with the IAB-node’ s BAP address.
  • the boundary node compares the destination BAP address with its BAP address associated with the ingress topology.
  • the lAB-node checks the routing configuration associated to the ingress topology to identify an available egress link. If no available egress link is identified with the routing configuration, then the lAB-node additionally checks the BAP Routing ID mapping (or header rewriting configuration) to find a new routing option through header rewriting.
  • the lAB-node rewrites the header with the new BAP Routing ID and identifies the egress topology associated to the new BAP Routing ID.
  • the IAB node determines again whether the packet has to be delivered to the upper layers by comparing the new destination BAP address with the lAB-node’ s BAP address associated to the egress topology.
  • the lAB-node checks again the routing configuration associated to the egress topology of the data packet. For re-routing without change of topology, the egress topology is therefore equal to the ingress topology.
  • the lAB-node checks again the BAP Routing ID mapping (or header rewriting configuration) to find a new routing option through another header rewriting.
  • mapping to BH RLC channel is performed when an available egress link is identified.
  • BH RLC channel mapping takes into account the ingress topology for the prior hop BAP address (ingress backhaul link), and the egress topology for the next hop BAP address (egress backhaul link).
  • Figure 17 illustrates, using a flowchart 1700, another example method for processing data packets (e.g. for managing BAP PDU (or data packet) routing over one or more IAB networks (one or more IAB topologies)) according to embodiments and examples of the invention.
  • 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 example method shown in Figure 17.
  • the method of Figure 17 may be applied for routing data packets in the upstream or downstream direction.
  • the method of Figure 17 may use the configuration tables of Figure 5 a (or Figure 7 alternately) and Figure 8.
  • the process starts at step 1701 where an lAB-node, such as IAB node 612, receives a BAP packet, or BAP PDU, it should route.
  • an lAB-node such as IAB node 612
  • the lAB-node identifies the IAB topology associated with the BAP packet to be routed (e.g. the received BAP packet). For example, the IAB node may determine the IAB topology associated with the received data packet according to one or more of the examples as described above with respect to step 1004 of figure 10.
  • the lAB-node identifies the type of traffic associated with the received BAP packet.
  • Two types of traffic may be differentiated:
  • One traffic type for the traffic intended to cross a boundary node and to be routed through different topologies i.e. inter-topology routing.
  • This type of traffic may be called transit traffic, or cross-traffic or concatenated traffic.
  • transit traffic or cross-traffic or concatenated traffic.
  • this is the case of data from Donor-CU 620 topology to be delivered to upper layer in the boundary node 612 (i.e. Donor-CU 610 sending data to the boundary node),
  • One traffic type for the traffic to be routed through a single topology may be called non-transit traffic, or normal traffic, or non-concatenated traffic.
  • this is the case of data from Donor-CU 620 topology to be delivered to upper layer in the boundary node 612 (i.e. Donor-CU 620 sending data to the boundary node), or the case of data from Donor-CU 610 topology to be delivered to upper layer in the boundary node 612 (i.e. Donor-CU 610 sending data to the boundary node).
  • the determination of the type of traffic may be obtained through a flag (or traffic type identifier) in the BAP header, using for instance one of the reserved bits 302, 303, or 304.
  • the flag is set to ‘ 1’ (or ‘0’) for a BAP packet associated to transit (or concatenated) traffic, and the flag is set to ‘0’ (or ‘ 1’) for a BAP packet associated to non-transit (or non-concatenated) traffic.
  • a non-boundary node can ignore this flag.
  • a boundary node can use it to associate the traffic to a BAP packet to be routed.
  • the determination may be obtained by parsing the header of the BAP packet and checking the value of the PATH field 306.
  • a set of path identifier values may be reserved by the lAB-donor-CU controlling the routing (i.e. lAB-Donor-CU 610 in the figure 6), and to be used for transit (or concatenated) traffic only.
  • the boundary node can detect transit traffic.
  • a dedicated path identifier for transit traffic may be called a transit path identifier identifying a transit path.
  • the BH Routing Information Added List Information Element (IE), defined in section 9.2.9.1 of 3GPP TS 38.473 vl6.4.0, is modified to allow the lAB-donor- CU to configure a transit field associated to the Path ID field 5012 where the transit field indicates that the path identifier in the Path ID field 5012 identifies a transit path for transit traffic.
  • the lAB-node checks the type of traffic. This step (and step 1703) may be skipped in a non-boundary node. For example, if the lAB-node is only configured with one BAP address, it is a non-boundary node and may skip steps 1703 and 1704.
  • the lAB-node identifies a new routing identifier based on routing identifier mapping information, such as the BAP Routing ID mapping table 800, and the routing identifier of the received data packet and updates or rewrites the BAP header of the received data packet with the identified new routing identifier. For example, if the type of traffic is a transit traffic, then, the lAB-node rewrites the BAP header of the packet if an entry is found in the BAP Routing ID mapping table (or Header rewriting configuration) 800 described with respect to figure 8.
  • routing identifier mapping information such as the BAP Routing ID mapping table 800
  • the lAB-node replaces (updates or rewrites) the routing identifier in the received data packet with the new routing identifier for the matched entry by replacing (updating or rewriting) the destination address in the DESTINATION field 305 and path identifier in the PATH field 306 in the BAP header of the BAP PDU to be routed respectively by the destination address in the new destination field or DESTINATION field 8311 and path identifier in the new path identifier field or PATH field 8312, of the NEW BAP ROUTING field 830, associated to the considered PREVIOUS BAP ROUTING field 820 of the matched entry, as discussed in Figure 8.
  • the lAB-node identifies the IAB topology associated with the new routing identifier, for example, by checking the new topology field 832 associated to the NEW BAP ROUTING field 830 considered at step 1705 and identifies the IAB topology associated with the egress BH link over which the BAP PDU is to be routed.
  • the IAB node goes directly to the step 1707 without executing the steps 1705 and 1706.
  • the header is not rewritten and the egress topology is equal to the ingress topology.
  • the lAB-node checks whether the destination address information or destination address in the DESTINATION field 305 matches its own BAP address or not. If it is determined that the destination address in the DESTINATION field 305 actually matches the lAB-node’ s own BAP address, the lAB-node removes the BAP header from the BAP PDU and delivers it to the upper layers (step 1708). When the lAB-node is a boundary node, the boundary node compares the DESTINATION field 305 with only one of its BAP addresses: the one associated with the same topology as the received BAP packet to be routed.
  • the lAB-node checks, based on the routing identifier of the received data packet, routing configuration information, such as the routing configuration table or Backhaul routing configuration table 500 (or 700 alternately), associated to the IAB topology identified at step 1702 or step 1706, looking for a routing option for the BAP PDU to be routed.
  • routing configuration information such as the routing configuration table or Backhaul routing configuration table 500 (or 700 alternately), associated to the IAB topology identified at step 1702 or step 1706, looking for a routing option for the BAP PDU to be routed.
  • a routing option may consist in finding an entry in the Backhaul routing configuration table 500 (alternately 700) associated to the IAB topology which includes a routing identifier in the routing identifier (BAP ROUTING ID) field 501 matching the routing identifier in the BAP ROUTING ID field 30, (i.e. concatenation of the DESTINATION Field 305 and PATH field 306), in the BAP header of the received data packet.
  • BAP ROUTING ID routing identifier in the routing identifier
  • PATH field 306 i.e. concatenation of the DESTINATION Field 305 and PATH field 306
  • a routing option may consist in finding an entry in the Backhaul routing configuration table 500 described above with respect to Figure 5(a) (alternately Backhaul routing configuration table 700 described above with respect to Figure 7) associated to the IAB topology which includes a destination address in the DESTINATION field 5011 matching the destination address in the DESTINATION Field 305 in the BAP header of the received BAP PDU.
  • the lAB-node identifies at step 1713 the egress backhaul (BH) link where the BAP PDU is to be routed, for example, by checking the Next Hop BAP Address field 502 associated to the entry of Backhaul routing configuration table identified at steps 1711 and 1712.
  • BH egress backhaul
  • the lAB-node determines at step 1714 if the egress BH link identified at step 1713 is available. If it is determined that the egress BH link is not available, the lAB-node may move back to step 1711 and check again the Backhaul routing configuration table for a new routing option.
  • the lAB-node determines at step 1715 the BH RLC channel over which the BAP PDU is to be routed based on the information from the BH RLC Channel Mapping Configuration table, as discussed in Figure 5b, Figure 5c, Figure 9b and Figure 9c, and eventually routes the BAP PDU over the determined BH RLC channel.
  • the lAB-node may check if re-routing through header rewriting is possible. For example, at step 1716, the lAB-node may check the information in the update or rewriting field 703 of the Backhaul routing configuration table 700 (or the value in at least part of the next hop address field 502 when a specific value in at least part of the next hop address field is used to indicate whether header rewriting is to be performed) for the entry matching the routing identifier in the BAP ROUTING ID field 30, (i.e. concatenation of the DESTINATION Field 305 and PATH field 306), in the BAP header of the received data packet.
  • the IAB nodes checks if an entry in the BAP Routing ID mapping table (or Header rewriting configuration) 800 matches the routing identifier in the BAP ROUTING ID field 30 in the BAP header of the received data packet.
  • rewriting field 703 (or the value in at least part of the next hop address field 502) indicates that no BAP header rewriting is to be performed for routing the BAP PDU, or if no entry is found in the BAP Routing ID mapping table 800, the lAB-node may discard the BAP PDU or store it for a new routing attempt (step 1719).
  • the lAB-node identifies, based on routing identifier mapping information and the routing identifier of the received data packet, a new routing identifier and an associated IAB topology, for example, by checking for an entry in the Routing ID mapping table, such as Routing ID mapping table 800 shown in and described with respect to Figure 8, for which the previous routing identifier field 821 or ROUTING ID Field 821, i.e.
  • DESTINATION field 8211 and PATH field 8212, of the PREVIOUS BAP ROUTING field 820 matches the routing identifier of the received data packet (i.e. the ROUTING ID field, i.e. DESTINATION Field 305 and PATH field 306, in the BAP header of the BAP PDU to be routed), and which the IAB topology in the previous topology field or Topology field 822 matches the ingress IAB topology identified at step 1702 or step 1706.
  • the lAB-node replaces (updates or rewrites) the routing identifier in the received data packet with the new routing identifier, for example, by replacing (updating or rewriting) the destination address in the DESTINATION field 305 and path identifier in the PATH field 306 in the BAP header of the BAP PDU to be routed respectively by the destination address in the new destination field or DESTINATION field 8311 and path identifier in the new path identifier field or PATH field 8312, of the NEW BAP ROUTING field 830, associated to the considered PREVIOUS BAP ROUTING field 820 of the matched entry, as discussed in Figure 8.
  • the lAB-node determines the IAB topology associated with the new routing identifier, for example, by checking the new topology field 832 associated to the NEW BAP ROUTING field 830 considered at step 1717 and identifying the IAB topology associated with the egress BH link over which the BAP PDU is to be routed.
  • the lAB-node may move back to step 1711 and determine a new routing option for the received BAP PDU, based on routing configuration information associated with the identified IAB topology and the identified new routing identifier, for example, by checking again the Backhaul routing configuration table 500 (alternately 700) associated to the IAB topology identified at step 1718, looking for a new routing option for the received BAP PDU.
  • routing configuration information associated with the identified IAB topology and the identified new routing identifier, for example, by checking again the Backhaul routing configuration table 500 (alternately 700) associated to the IAB topology identified at step 1718, looking for a new routing option for the received BAP PDU.
  • a boundary lAB-node is an lAB-node, whose IAB-DU is terminated to a different lAB-donor-CU than a parent DU.
  • the IAB topology controlled by the terminating lAB-donor-CU refers to the primary topology (or Master Cell Group (MCG) topology).
  • MCG Master Cell Group
  • the IAB topology controlled by the non-terminating IAB- donor-CU refers to the secondary topology (or Secondary Cell Group (SCG) topology).
  • the IAB topology associated to the ingress backhaul link on which a BAP data packet is received refers to the ingress topology
  • the IAB topology associated to the egress backhaul link on which a BAP data packet is transmitted refers to the egress topology
  • the BAP data packets that shall traverse a boundary node from one ingress topology to a different egress topology represent a traffic in transit, or in short, transit traffic.
  • the term transit traffic is equivalent to the term concatenated traffic. Because of re-routing in a boundary node, it may happen that a BAP packet identified as transit traffic is finally routed to the same egress topology as the ingress topology. For the same reason, it may happen that a BAP packet not identified as transit traffic is finally routed to an egress topology different from the ingress topology in a boundary node.
  • a boundary node has one BAP address for each topology, and that each lAB-donor-CU assigns IAB-nodes’ BAP address, BAP Routing IDs, and BH RLC channel IDs independently.
  • BAP address, BAP Routing ID, or BH RLC channel ID may be assigned in the two topologies.
  • a BAP address should be intended to uniquely identify an lAB-node only.
  • the destination BAP address of the BAP packet is not an alias different from the boundary node’s BAP address in the ingress topology. Therefore, a BAP packet for a transit traffic is received by a boundary node with a destination BAP address equal to the boundary node’s BAP address in the ingress topology.
  • the identification of transit traffic in a boundary node relies on dedicated path identifiers, referred to as transit path IDs, to be specifically used for routing BAP packets across two topologies.
  • the standard may reserve a range of dedicated path IDs values for transit path IDs, or an lAB-donor-CU may allocate and define in a boundary node a set of transit path IDs values.
  • a flag within the BAP header e.g. one of the reserved bit
  • the identification of the ingress link on which a BAP data packet is received should also enable the identification of the ingress topology (primary /MCG or secondary/SCG).
  • the BAP Routing ID mapping (or header rewriting configuration) indicates the topology (MCG/SCG) the previous Routing ID refers to, and indicates the topology (MCG/SCG) the new Routing ID refers to.
  • This configuration table can be used both to rewrite the BAP headers for a transit traffic in a boundary node, and when it is required to rewrite the BAP headers for re-routing (towards a different Donor-DU) in any lAB-node.
  • This configuration table can be used both for upstream and downstream routing and re-routing.
  • a boundary node is configured with separated routing configurations for the primary /MCG topology and for the secondary/SCG topology.
  • the unique routing configuration indicates for each entry the topology that the BAP Routing ID and the next hop BAP address (i.e. the egress link) refer to.
  • the BH RLC channel mapping configuration provides the mapping between (ingress link + ingress BH RLC channel ID) and (egress link + egress BH RLC channel ID), where each link is associated to a topology (primary /MCG or secondary/SCG).
  • N 1 bearer mapping shall also be applied on the egress link.
  • a coordination between the IAB- donor-CUs is required to guarantee a consistent configuration of lAB-nodes in both topologies.
  • the BAP operations to handle a BAP data packet may be the following:
  • a non-boundary lAB-node first behaves as the Rel-16 specifications: determination of delivery to upper layers, checking the routing configuration. However, if no available egress link is identified with the routing configuration, then the lAB-node additionally checks the BAP Routing ID mapping (or header rewriting configuration) to find a new routing option through header rewriting. If one entry is found with the previous BAP routing ID matching the BAP routing ID in the packet header, then the lAB-node rewrites the header with the new BAP Routing ID and checks again the routing configuration. Finally, mapping to BH RLC channel is performed if an available egress link is identified.
  • a boundary node behaves like non-boundary IAB nodes except that the boundary node has to take into account the topology and has to perform additional steps beforehand.
  • a boundary node shall determine if the BAP packet is a transit traffic or not, based for instance on the identification of a transit path in the BAP header. If a transit traffic is identified, then the boundary node checks the BAP Routing ID mapping (or header rewriting configuration) to rewrite the BAP header. For that, the boundary nodes looks for an entry matching the ingress topology and the BAP Routing ID in the packet header. Also, with the BAP Routing ID mapping configuration, the boundary node shall identify the egress topology associated to the new BAP Routing ID.
  • the header is not rewritten and the egress topology is equal to the ingress topology.
  • the boundary node checks the routing configuration for the egress topology associated to the BAP packet. As for a nonboundary node, if no available egress link is identified with the routing configuration, then the boundary node additionally checks the BAP Routing ID mapping (or header rewriting configuration) to find a new routing option through header rewriting. If one entry is found with the couple (previous BAP routing ID and topology) matching the BAP routing ID in the header and the topology of the BAP packet, then the boundary node rewrites the header with the new BAP Routing ID, identifies the associated egress topology, and checks again the routing configuration for the identified egress topology.
  • BAP Routing ID mapping or header rewriting configuration
  • mapping to BH RLC channel is performed if an available egress link is identified, taking into account the ingress topology for the prior hop BAP address, and the egress topology for the next hop BAP address. It can be noted that rewriting first the header in a boundary node avoids the use of alias BAP addresses for transit traffic, and it avoids a useless parsing of the routing configuration before rewriting.
  • the BAP operations may be described in a unified manner for non-boundary nodes and boundary nodes, considering that for non-boundary nodes, the egress topology is always equal to the ingress topology.
  • the header is rewritten in a boundary node for concatenated traffic. Here it is required to have identified the ingress topology
  • inter-topology or inter-donor-DU re-routing If inter-topology or inter-donor-DU re-routing is triggered, perform header rewriting for re-routing and select the next hop by looking-up the routing table with the new routing ID;
  • a boundary node checks if the traffic is concatenated or not.
  • the solution proposes to rely on dedicated path identifiers, to be specifically used for identifying concatenated traffic (even though a flag in BAP header requires the use of a reserved bit within the BAP header, this other option is acceptable for concatenated traffic identification, while it is not possible to differentiate the concatenated traffic and non-concatenated traffic based on the ingress link).
  • the BAP header rewriting configuration for inter-topology routing and the BAP header rewriting configuration for re-routing at the boundary node are two separated rewriting tables.
  • the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over, as one or more instructions or code, a computer-readable medium and executed by a hardware-based processing unit.
  • Computer-readable media may include computer-readable storage media, which corresponds to a tangible medium such as data storage media, or communication media including any medium that facilitates transfer of a computer program from one place to another, e.g., according to a communication protocol.
  • computer-readable media generally may correspond to (1) tangible computer-readable storage media which is non-transitory or (2) a communication medium such as a signal or carrier wave.
  • Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and/or data structures for implementation of the techniques described in this disclosure.
  • a computer program product may include a computer-readable medium.
  • such computer-readable storage media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer.
  • any connection is properly termed a computer-readable medium.
  • a computer-readable medium For example, if instructions are transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium.
  • DSL digital subscriber line
  • Disk and disc includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.
  • processors such as one or more digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry.
  • DSPs digital signal processors
  • ASICs application specific integrated circuits
  • FPGAs field programmable logic arrays
  • processors may refer to any of the foregoing structure or any other structure suitable for implementation of the techniques described herein.
  • the functionality described herein may be provided within dedicated hardware and/or software modules configured for encoding and decoding, or incorporated in a combined codec. Also, the techniques could be fully implemented in one or more circuits or logic elements.
  • the received data packet is a Backhaul Adaptation Protocol, BAP, data packet comprising a BAP header including the routing identifier
  • the routing configuration information comprises a backhaul routing configuration table including a field for indicating whether the BAP routing identifier of the received data packet is to be updated.
  • routing identifier mapping information comprises a routing identifier mapping table including a field for indicating the IAB topology associated with the BAP routing identifier to be updated and/or a field for indicating the IAB topology associated with the new routing identifier.
  • routing configuration information comprises a routing configuration table having at least one entry, each entry of the routing configuration table including; a routing identifier field for a routing identifier, the routing identifier field comprising 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 IAB node; a next hop address field for indicating an address of a next IAB node in the routing path identified by the path identifier; and an update field for indicating whether the routing identifier is to be updated.
  • routing configuration information comprises a routing configuration table having at least one entry, each entry of the routing configuration table including: a routing identifier field for a routing identifier, the routing identifier field comprising 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 IAB node; a next hop address field for indicating an address of a next IAB node in the routing path identified by the path identifier, wherein a certain value in at least part of the next hop address field indicates the routing identifier is to be updated.
  • the backhaul RLC channel mapping information comprises a backhaul RLC channel mapping configuration table having at least one entry, each entry including: a next hop address field for a next hop address of a next IAB node that is next to the IAB node in a routing path, an egress topology field for indicating the IAB topology associated with the next IAB node, and for indicating with the next hop address field an egress backhaul link between the IAB node and the next IAB node, a prior hop address field for a prior hop address of a prior IAB node that is prior to the IAB node in the routing path, an ingress topology field for indicating the IAB topology associated with the prior IAB node, and for indicating with the prior hop address field an ingress backhaul link between the IAB node and the prior IAB node, an ingress backhaul RLC channel identifier field for a backhaul RLC channel identifier of a backhaul RLC channel of the in
  • receiving a data packet comprises receiving the data packet from a prior IAB node over an ingress BH link
  • determining the IAB topology associated with the received data packet comprises determining the IAB topology associated with the ingress backhaul link
  • selecting a backhaul RLC channel for the egress backhaul link comprises: checking the backhaul RLC channel mapping configuration table to determine whether a backhaul RLC channel ID of the ingress backhaul link, an address of the prior IAB node, the determined IAB topology associated with the prior IAB node, an address of the next IAB node and the IAB topology associated with the next IAB node match the respective fields of an entry in the backhaul RLC channel mapping configuration table; and when a match with an entry is determined, using the egress backhaul RLC channel ID of the matched entry to select the backhaul RLC channel for the egress backhaul link.
  • the backhaul RLC channel mapping information comprises a backhaul RLC channel mapping configuration table having at least one entry, each entry including: a traffic type identifier field for indicating a traffic type of a data packet to be routed, a next hop address field for a next hop address of a next IAB node that is next to the IAB node in a routing path, an egress topology field for indicating the IAB topology associated with the next IAB node, and for indicating with the next hop address field an egress backhaul link between the IAB node and the next IAB node, and an egress backhaul RLC channel identifier field for a backhaul RLC channel identifier of a backhaul RLC channel for the egress backhaul link.
  • a traffic type identifier field for indicating a traffic type of a data packet to be routed
  • a next hop address field for a next hop address of a next IAB node that is next to the IAB node in a routing
  • receiving a data packet comprises generating the data packet in one part of the IAB node and receiving, at another part of the IAB node, the data packet for routing to another IAB node, wherein selecting a backhaul RLC channel for the egress backhaul link comprises: checking the backhaul RLC channel mapping configuration table to determine whether a traffic type of data in the received data packet, an address of the next IAB node and the IAB topology associated with the next IAB node match the respective fields of an entry in the backhaul RLC channel mapping configuration table; and when a match with an entry is determined, using the egress backhaul RLC channel ID of the matched entry to select the backhaul RLC channel for the egress backhaul link.
  • routing identifier mapping information comprises a routing identifier mapping table having at least one entry, each entry of the routing identifier mapping table including: a previous routing identifier field for a routing identifier; a previous topology field for indicating the IAB topology associated with the routing identifier in the previous routing identifier field; a new routing identifier field for a routing identifier; and a new topology field for indicating the IAB topology associated with the routing identifier in the new routing identifier field. 13.
  • routing identifier of the received data packet includes a destination address of a destination IAB node for the data packet, wherein identifying a new routing identifier and the IAB topology associated with the next IAB node the data packet is to be routed comprises: checking the routing identifier mapping table to determine whether the routing identifier of the received data packet matches a routing identifier in the previous routing identifier field of an entry or whether a destination address of the routing identifier of the received data packet matches a destination address in the destination address field of an entry; and when a match with an entry is determined, using the routing identifier in the new routing identifier field of the matched entry as the identified new routing identifier and using the IAB topology indicated by the new topology field of the matched entry as the identified IAB topology associated with the next IAB node.
  • each topology field in a table includes a topology identifier that uniquely identifies one of the at least two IAB topologies.
  • routing identifier of the received data packet includes a destination address of a destination IAB node for the data packet
  • determining whether the routing identifier is to be updated comprises: determining whether there is a routing option for the received data packet by checking the routing configuration table associated with the determined IAB topology associated with the received data packet to determine whether the routing identifier of the received data packet matches a routing identifier in the routing identifier field of an entry or whether a destination address of the routing identifier of the received data packet matches a destination address in the destination address field of an entry; and wherein determining whether the routing identifier is to be updated comprises determining whether the routing identifier is to be updated in response to determining a match with an entry and by checking a value in the update field or the next hop address field of the matched entry.
  • the new routing identifier includes a destination address of a destination IAB node for the data packet
  • determining an egress backhaul link comprises: checking the routing configuration table associated with the identified IAB topology to determine whether the identified new routing identifier matches a routing identifier in the routing identifier field of an entry or whether a destination address of the new routing identifier matches a destination address in the destination address field of an entry; and when a match with an entry is determined, using the next hop address in the next hop address field of the matched entry to determine the next IAB node.
  • checking the routing configuration table comprises checking the entries according to the priority order of the entries.
  • a method for processing data packets at an integrated access and backhaul, IAB, node in an IAB communication system comprising at least two IAB topologies and each IAB topology comprising a plurality of IAB nodes, the method comprising:
  • repeating comprises repeating, for at least one cycle, steps (c) to (f) for an updated data packet until it is determined that an updated data packet is to be delivered to the upper layers, or it is determined there is an egress backhaul link for routing data or it is determined that the routing identifier is not to be updated.
  • each routing identifier of the received data packet and the updated data packet includes a destination address of a destination IAB node
  • determining whether a received data packet is to be delivered to upper layers of the IAB node and determining whether an updated data packet is to be delivered to upper layers of the IAB node each comprises comparing the destination address of the routing identifier with an address of the IAB node associated with the respective determined IAB topology.
  • the IAB node is a boundary node such that the IAB node is part of a first IAB topology of the at least two IAB topologies and is also connected to an IAB node of a second IAB topology of the at least two IAB topologies, wherein the IAB node has a first address associated with the first IAB topology and a second address associated with the second IAB topology, wherein determining whether a received data packet is to be delivered to upper layers of the IAB node and determining whether an updated data packet is to be delivered to upper layers of the IAB node each comprises comparing the destination address of the routing identifier with one of the first or second addresses of the IAB node, wherein when the determined IAB topology is the first topology, the one address is the first address of the IAB node, when the determined IAB topology is the second topology, the one address is the second address of the IAB node.
  • determining a new routing identifier and an IAB topology associated with the new routing identifier comprises determining, based on routing identifier mapping information and the routing identifier of the received data packet, a new routing identifier and an associated IAB topology.
  • routing identifier mapping information comprises a routing identifier mapping table having at least one entry, each entry of the routing identifier mapping table including: a previous routing identifier field for a routing identifier; a previous topology field for indicating the IAB topology associated with the routing identifier in the previous routing identifier field; a new routing identifier field for a routing identifier; and a new topology field for indicating the IAB topology associated with the routing identifier in the new routing identifier field.
  • the received data packet is a Backhaul Adaptation Protocol, BAP
  • data packet comprising a BAP header including the routing identifier
  • the routing configuration information comprises a backhaul routing configuration table including a field for indicating whether the BAP routing identifier of the received data packet is to be updated.
  • routing identifier mapping information comprises a routing identifier mapping table including a field for indicating the IAB topology associated with the BAP routing identifier to be updated and/or a field for indicating the IAB topology associated with the new routing identifier.
  • routing configuration information comprises a routing configuration table having at least one entry, each entry of the routing configuration table including; a routing identifier field for a routing identifier, the routing identifier field comprising 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 IAB node; a next hop address field for indicating an address of a next IAB node in the routing path identified by the path identifier; and an update field for indicating whether the routing identifier is to be updated.
  • routing configuration information comprises a routing configuration table having at least one entry, each entry of the routing configuration table including: a routing identifier field for a routing identifier, the routing identifier field comprising 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 IAB node; a next hop address field for indicating an address of a next IAB node in the routing path identified by the path identifier, wherein a certain value in at least part of the next hop address field indicates the routing identifier is to be updated.
  • receiving a data packet comprises receiving the data packet from a prior IAB node over an ingress backhaul link, wherein determining the IAB topology associated with the received data packet comprises determining the IAB topology associated with the ingress backhaul link.
  • receiving a data packet comprises receiving the data packet from a prior IAB node over an ingress backhaul link, wherein determining the IAB topology associated with the received data packet comprises determining the IAB topology associated with the ingress backhaul link.
  • 33 further comprising generating the data packet in one part of the IAB node and wherein receiving a data packet comprises receiving, at another part of the IAB node, the generated data packet for routing to another IAB node, wherein determining the IAB topology associated with the received data packet comprises determining the IAB topology associated with the IAB node.
  • the IAB node is a boundary IAB node such that the IAB node is part of a first IAB topology of the at least two IAB topologies and is also connected to an IAB node of a second IAB topology of the at least two IAB topologies, the IAB node is provided with first routing configuration information associated with the first IAB topology and second routing configuration information associated with the second IAB topology, wherein determining whether the routing identifier is to be updated is based on the first routing configuration information when the determined IAB topology is the first IAB topology or is based on the second routing configuration information when the determined IAB topology is the second IAB topology.
  • a method for processing data packets at an integrated access and backhaul, IAB, node in an IAB communication system comprising at least two IAB topologies, each IAB topology comprising a plurality of IAB nodes, the method comprising: receiving a data packet over an ingress backhaul link from a prior IAB node, the data packet including a routing identifier; determining an IAB topology associated with the received data packet; determining, based on the routing identifier of the received data packet, an egress backhaul link over which the data packet is to be routed to a next IAB node; determining an IAB topology associated with the next IAB node; selecting a backhaul RLC channel for the egress backhaul link based on the determined IAB topology associated with the next IAB node and a backhaul RLC channel mapping configuration table; routing the data packet over the selected backhaul RLC channel to the next lAB-node, wherein the backhaul RLC channel mapping configuration table comprises at
  • a method for processing data packets at an integrated access and backhaul, IAB, node in an IAB communication system comprising at least two IAB topologies, each IAB topology comprising a plurality of IAB nodes, the method comprising: receiving a data packet, generated in the IAB node, for routing to another IAB node, the data packet including a routing identifier; determining, based on the routing identifier of the received data packet, an egress backhaul link over which the data packet is to be routed to a next IAB node; determining an IAB topology associated with the next IAB node; selecting a backhaul RLC channel for the egress backhaul link based on the determined IAB topology associated with the next IAB node and a backhaul RLC channel mapping configuration table; routing the data packet over the selected backhaul RLC channel to the next lAB-node, wherein the backhaul RLC channel mapping configuration table comprises at least one entry, each entry including: a traffic type
  • selecting a backhaul RLC channel for the egress backhaul link comprises: checking the backhaul RLC channel mapping configuration table to determine whether a traffic type of data in the received data packet, an address of the next IAB node and the identified IAB topology associated with the next IAB node match the respective fields of an entry in the backhaul RLC channel mapping configuration table; and when a match with an entry is determined, using the egress backhaul RLC channel ID of the matched entry to select the backhaul RLC channel for the egress backhaul link.
  • the routing identifier of the received data packet includes a destination address of a destination IAB node for the data packet
  • determining an egress backhaul link over which the data packet is to be routed to a next IAB node comprises determining an address of the next IAB node by checking a backhaul routing configuration table using the routing identifier or the destination address of the routing identifier and when there is a match with an entry in the backhaul routing configuration table, determining an egress backhaul link based on the address of the determined next IAB node of the matched entry, wherein the backhaul routing configuration table has at least one entry, with each entry of the routing configuration table including at least a routing identifier field for a routing identifier and a next hop address field for indicating an address of a next IAB node in a routing path identified by a path identifier of the routing identifier.
  • the method further comprises: checking a routing identifier mapping table using the routing identifier of the received data packet and when there is a match with an entry in the routing identifier mapping table, determining a new routing identifier for the received data packet based on the new routing identifier of the matched entry; updating the routing identifier of the received data packet with the new routing identifier to provide an updated data packet including the identified new routing identifier, wherein the new routing identifier includes a destination address of a destination IAB node for the data packet, wherein determining an egress backhaul link over which the data packet is to be routed to a next IAB node comprises determining an address of the next IAB node by checking the backhaul routing configuration table using the new routing identifier or the destination address of the new routing identifier and when there is a match with an entry in the backhaul routing configuration table, determining an egress
  • a method for managing processing of data packets in an integrated access and backhaul, IAB, communication system comprising at least two IAB topologies, each IAB topology comprising a plurality of IAB nodes and a donor Central Unit, CU, the method at a first donor CU of a first IAB topology of the at least two IAB topologies comprising: providing, to at least one IAB node of the first IAB topology, data packet routing configuration information for routing data packets over at least the first IAB topology, wherein the data packet routing configuration information comprises a routing configuration table and a routing identifier mapping table, wherein the routing configuration table comprises at least one entry including: a routing identifier field for a routing identifier, the routing identifier field comprising 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 IAB node; a next hop address field for indicating an address of a next IAB node in the routing path
  • the field for indicating whether a routing identifier of a received data packet matching the routing identifier in the routing identifier field is to be updated comprises: an update field wherein a value in the update field indicates the routing identifier is to be updated; or at least part of the next hop address field, wherein a certain value in at least part of the next hop address field indicates the routing identifier is to be updated.
  • providing comprises providing the routing configuration table in a routing configuration Information Element, IE, of a configuration message for transmission to the at least one IAB node and providing the routing identifier mapping table in a routing identifier mapping Information Element, IE, of a configuration message for transmission to the at least one IAB node.
  • the data packet routing configuration information further comprises, a backhaul RLC channel mapping configuration table having at least one entry including: a next hop address field for a next hop address of a next IAB node that is next to the at least one IAB node in a routing path, an egress topology field for indicating the IAB topology associated with the next IAB node, and for indicating with the next hop address field an egress backhaul link between the IAB node and the next IAB node, an egress backhaul RLC channel identifier field for a backhaul RLC channel identifier of a backhaul RLC channel for the egress backhaul link; and/or a prior hop address field for a prior hop address of a prior IAB node that is prior to the IAB node in the routing path, an ingress topology field for indicating the IAB topology associated with the prior IAB node, and for indicating with the prior hop address field an in
  • the data packet routing configuration information further comprises, an uplink traffic to backhaul RLC channel mapping configuration table having at least one entry including: a traffic type identifier field for indicating a traffic type of a data packet to be routed, a next hop address field for a next hop address of a next IAB node that is next to the IAB node in a routing path, an egress topology field for indicating the IAB topology associated with the next IAB node, and for indicating with the next hop address field an egress backhaul link between the IAB node and the next IAB node, and an egress backhaul RLC channel identifier field for a backhaul RLC channel identifier of a backhaul RLC channel for the egress backhaul link.
  • an uplink traffic to backhaul RLC channel mapping configuration table having at least one entry including: a traffic type identifier field for indicating a traffic type of a data packet to be routed, a next hop address field for a next hop address of
  • providing further comprises providing the data packet routing configuration information to at least one IAB node of a second IAB topology of the at least two IAB topologies, the second IAB topology being different to the first IAB topology and being managed by a second donor CU.
  • any one of clauses 43 to 49 further comprising: sending, to a second donor CU of a second IAB topology of the at least two IAB topologies, a request for establishing routing of data packets between the first IAB topology and the second IAB topology; receiving, from the second donor CU, a response, the response including acknowledgement information indicating whether the second donor CU has accepted the request and when the second donor CU has accepted the request, configuration information relating to one or more IAB nodes in the second IAB topology for identifying routing paths for routing data packets between at least one IAB node of the first IAB topology and at least one IAB node in the second IAB topology, wherein providing the data packet routing configuration information comprises providing the data packet routing configuration information based on the configuration information received from the second donor CU.
  • a method for managing processing of data packets in an integrated access and backhaul, IAB, communication system comprising at least two IAB topologies, each IAB topology comprising a plurality of IAB nodes and a donor Central Unit, CU, the method at a first donor CU of a first IAB topology of the at least two IAB topologies comprising: sending, to a second donor CU of a second IAB topology of the at least two IAB topologies, a request for establishing routing of data packets between the first IAB topology and the second IAB topology; receiving, from the second donor CU, a response, the response including acknowledgement information indicating whether the second donor CU has accepted the request and when the second donor CU has accepted the request, configuration information relating to one or more IAB nodes in the second IAB topology for identifying routing paths for routing data packets between at least one IAB node of the first IAB topology and at least one IAB node in the second IAB topology, wherein the request sent to
  • the configuration information received from the second donor CU comprises at least one of the following Information Elements, IE: an IE identifying the at least one IAB donor DU in the second IAB topology; an IE identifying an address of the boundary IAB node for use in the secondary IAB topology; an IE indicating an alias address for use by the second donor CU to route data packets in a downstream direction to the boundary IAB node; an IE indicating a backhaul RLC channel identifier for a RLC channel for use by the second donor CU to route data packets for the boundary IAB node in the secondary topology on the ingress backhaul link or on the egress backhaul link.
  • a computer program comprising instructions which, when the program is executed by a processing unit, cause the processing unit to carry out the method of any one of the preceding clauses.
  • An Integrated access and backhaul, IAB, node for an IAB communication system comprising a plurality of IAB nodes, the IAB node comprising: at least one communication interface for communicating with at least one IAB 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 clauses 1 to 42.
  • a donor Central Unit, CU for managing processing of data packets in an integrated access and backhaul, IAB, communication system comprising at least two IAB topologies, each IAB topology comprising a plurality of IAB nodes and a donor Central Unit, CU, 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 clauses 43 to 52.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Dans un système de communication à accès et liaison terrestre intégrés (IAB) comprenant au moins deux topologies IAB, chaque topologie IAB comprenant une pluralité de nœuds IAB, un procédé de traitement de paquets de données au niveau d'un nœud IAB consiste à recevoir un paquet de données, le paquet de données comprenant un identifiant de routage ; à déterminer si l'identifiant de routage doit être mis à jour avant de transmettre le paquet de données à un autre nœud IAB. En réponse à la détermination selon laquelle l'identifiant de routage doit être mis à jour, le procédé consiste en outre à : identifier, sur la base d'informations de configuration de réécriture d'en-tête et de l'identifiant de routage du paquet de données reçu, un nouvel identifiant de routage et une topologie IAB associée ; mettre à jour le paquet de données reçu par mise à jour de l'identifiant de routage du paquet de données reçu avec le nouvel identifiant de routage identifié pour fournir un paquet de données mis à jour comprenant le nouvel identifiant de routage identifié ; déterminer, sur la base d'informations de configuration de routage associées à la topologie IAB identifiée et du nouvel identifiant de routage identifié, une liaison terrestre de sortie sur laquelle le paquet de données doit être acheminé vers un nœud IAB suivant ; et transmettre le paquet de données mis à jour sur la liaison terrestre de sortie au nœud lAB suivant.
PCT/EP2022/076469 2021-09-24 2022-09-23 Routage de données dans un réseau d'accès et de liaison terrestre intégrés WO2023046878A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
KR1020247012356A KR20240068689A (ko) 2021-09-24 2022-09-23 통합 액세스 및 백홀 네트워크에서의 데이터 라우팅
CN202280064433.6A CN118020344A (zh) 2021-09-24 2022-09-23 在集成接入和回程网络中路由数据

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
GB2113679.1 2021-09-24
GB2113679.1A GB2611068A (en) 2021-09-24 2021-09-24 Routing data in an integrated access and backhaul network
GB2114405.0 2021-10-08
GB2114405.0A GB2611109A (en) 2021-09-24 2021-10-08 Routing data in an integrated access and backhaul network
GB2115114.7A GB2611111A (en) 2021-09-24 2021-10-21 Routing data in an integrated access and backhaul network
GB2115114.7 2021-10-21
GB2118319.9 2021-12-16
GB2118319.9A GB2611120B (en) 2021-09-24 2021-12-16 Routing data in an integrated access and backhaul network

Publications (1)

Publication Number Publication Date
WO2023046878A1 true WO2023046878A1 (fr) 2023-03-30

Family

ID=83508463

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2022/076469 WO2023046878A1 (fr) 2021-09-24 2022-09-23 Routage de données dans un réseau d'accès et de liaison terrestre intégrés

Country Status (1)

Country Link
WO (1) WO2023046878A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4150892A4 (fr) * 2021-07-29 2023-11-01 LG Electronics Inc. Procédé et appareil de traitement d'une unité de données par un noeud iab dans un système de communication sans fil

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020039346A1 (fr) * 2018-08-23 2020-02-27 Telefonaktiebolaget Lm Ericsson (Publ) Gestion de plan de commande(cp) d'adaptation de topologie de liaison terrestre d'accès intégré (iab)
EP3860183A1 (fr) * 2018-09-26 2021-08-04 Kyocera Corporation Dispositif de relais

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020039346A1 (fr) * 2018-08-23 2020-02-27 Telefonaktiebolaget Lm Ericsson (Publ) Gestion de plan de commande(cp) d'adaptation de topologie de liaison terrestre d'accès intégré (iab)
EP3860183A1 (fr) * 2018-09-26 2021-08-04 Kyocera Corporation Dispositif de relais

Non-Patent Citations (15)

* Cited by examiner, † Cited by third party
Title
3GPP TS 24.501
3GPP TS 29.281
3GPP TS 38.300
3GPP TS 38.340
3GPP TS 38.401
3GPP TS 38.423
3GPP TS 38.473
3GPP TS38.323
3GPP TS38.340
3GPP TS38.473
HUAWEI: "Inter-CU topology redundancy", vol. RAN WG3, no. E-meeting; 20210816 - 20210826, 6 August 2021 (2021-08-06), XP052035600, Retrieved from the Internet <URL:https://ftp.3gpp.org/tsg_ran/WG3_Iu/TSGR3_113-e/Docs/R3-213934.zip R3-213934 Inter-CU topology redundancy.docx> [retrieved on 20210806] *
QUALCOMM INCORPORATED: "Backhaul transport for inter-donor redundancy", vol. RAN WG3, no. E-meeting; 20210517 - 20210528, 6 May 2021 (2021-05-06), XP052001442, Retrieved from the Internet <URL:https://ftp.3gpp.org/tsg_ran/WG3_Iu/TSGR3_112-e/Docs/R3-211741.zip R3-211741 Backhaul transport for inter-donor redundancy.docx> [retrieved on 20210506] *
SAMSUNG: "Discussion on CP-UP separation and inter-donor topology redundancy", vol. RAN WG3, no. Online; 20210125 - 20210204, 15 January 2021 (2021-01-15), XP051974951, Retrieved from the Internet <URL:https://ftp.3gpp.org/tsg_ran/WG3_Iu/TSGR3_111-e/Docs/R3-210218.zip R3-210218_TopoRed_v0.0.doc> [retrieved on 20210115] *
SAMSUNG: "Topology adaptation enhancements", vol. RAN WG2, no. E-meeting; 20210519 - 20210527, 10 May 2021 (2021-05-10), XP052003954, Retrieved from the Internet <URL:https://ftp.3gpp.org/tsg_ran/WG2_RL2/TSGR2_114-e/Docs/R2-2105782.zip R2-2105782_TopoAda_final.doc> [retrieved on 20210510] *
TS 38.401

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4150892A4 (fr) * 2021-07-29 2023-11-01 LG Electronics Inc. Procédé et appareil de traitement d'une unité de données par un noeud iab dans un système de communication sans fil

Similar Documents

Publication Publication Date Title
WO2019214747A1 (fr) Procédé de configuration, procédé et appareil de transmission de données
WO2023046878A1 (fr) Routage de données dans un réseau d&#39;accès et de liaison terrestre intégrés
GB2602802A (en) Management of radio link failure and deficiencies in integrated access backhauled networks
WO2023110927A1 (fr) Procédés destinés à être utilisés dans un processus de migration de ressources entre des topologies de liaison terrestre et d&#39;accès intégré
KR20230091908A (ko) 패킷 리라우팅을 위한 방법 및 장치
US20230403067A1 (en) Control of simultaneous use of wireless links in integrated access backhauled networks
GB2605960A (en) Routing data in an integrated access and backhaul network
GB2611111A (en) Routing data in an integrated access and backhaul network
GB2611120A (en) Routing data in an integrated access and backhaul network
GB2625931A (en) Routing data in an integrated access and backhaul network
US20240048486A1 (en) Routing data in an integrated access and backhaul network
US20240196304A1 (en) Routing data in an integrated access and backhaul network
US20240236003A1 (en) Flow control feedback in an integrated access and backhaul network
US20240236761A1 (en) Backhaul link issues in an integrated access and backhaul network
US20240056940A1 (en) Management of radio link failure and deficiencies in integrated access backhauled networks
EP4349072A1 (fr) Rétroaction de commande de flux dans un réseau d&#39;accès et de raccordement intégrés
CN118020344A (zh) 在集成接入和回程网络中路由数据
WO2022248657A1 (fr) Problèmes de liaison de raccordement dans un réseau d&#39;accès et de raccordement intégrés
WO2024094687A2 (fr) Migration de nœuds dans un système de communication iab
WO2024017909A1 (fr) La gestion de la migration d&#39;un nœud d&#39;accès et de liaison mobile intégré
GB2624001A (en) Migration of nodes in an IAB communication system
WO2024094547A1 (fr) Migration de nœuds dans un système de communication iab
TW202420788A (zh) Ｉａｂ通訊系統中節點的遷移

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22782884

Country of ref document: EP

Kind code of ref document: A1

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112024003716

Country of ref document: BR

ENP Entry into the national phase

Ref document number: 20247012356

Country of ref document: KR

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2022782884

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2022782884

Country of ref document: EP

Effective date: 20240424

ENP Entry into the national phase

Ref document number: 112024003716

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20240226