CN118020344A

CN118020344A - Routing data in an integrated access and backhaul network

Info

Publication number: CN118020344A
Application number: CN202280064433.6A
Authority: CN
Inventors: P·维萨; P·拉格兰奇
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2021-09-24
Filing date: 2022-09-23
Publication date: 2024-05-10

Abstract

In an IAB communication system including integrated access and backhaul topologies, i.e., an IAB topology including at least two IAB topologies of a plurality of IAB nodes, a method for processing data packets at an IAB node comprising: receiving a data packet, the data packet including a routing identifier; a determination is made as to whether the routing identifier is to be updated prior to transmitting the data packet to another IAB node. In response to determining to update the route identifier, the method further comprises: identifying a new route identifier and an associated IAB topology based on the header overwrite configuration information and the received route identifier of the data packet; 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 an egress backhaul link through which the data packet is to be routed to a next IAB node based on the route configuration information associated with the identified IAB topology and the identified new route identifier; and transmitting the update data packet to the next IAB node through the egress backhaul link.

Description

Routing data in an integrated access and backhaul network

Technical Field

The present invention relates generally to routing data and managing the routing of data in an Integrated Access and Backhaul (IAB) network of a wireless communication system.

Background

Wireless communication systems are deployed in large numbers to cope with a wide range of applications ranging from mobile broadband, large-scale machine type communications to ultra-reliable low-latency communications (Ultra Reliable Low Latency Communication (URLLC)). Such a system allows multiple User Equipments (UEs) or mobile terminals to share a 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. Conventionally, base stations are wired (e.g., through optical fibers) to a core network, forming an intermediate network known as a Backhaul (BH).

Examples of such wireless multiple-access communication systems include third generation partnership project (3 GPP-RTM) standard-based systems such as fourth generation (4G) Long Term Evolution (LTE) or more recently fifth generation (5G) new air interface (NR) systems or IEEE 802.11 standard-based systems such as WiFi.

The demand for network densification increases due to the increasing number of users and higher throughput requirements.

Faced with the problem of high deployment cost and time for wired backhaul networks with network densification, 3GPP has proposed wireless backhaul, also known as Integrated Access and Backhaul (IAB), in recent release 16 for 5G NR, where instead of optical fiber, a portion of the wireless (i.e. radio) spectrum is used for backhaul connection of base stations. The wireless backhaul communication (between the base stations) may use the same radio resources as the access communication (between the base stations and the UE).

IAB has proven to be a competitive alternative to fiber-based backhaul in dense areas or areas that are difficult to cover, as IAB allows for scalable and quick installation without the burden of wiring the base station.

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

However, millimeter waves are known to experience strong attenuation of signal strength under some weather conditions (rain, fog) and to experience obstruction if an obstruction is located in the path between the transmitter and receiver.

To cope with these potential radio link failures, topology redundancy may be provided within an IAB framework, in which multiple data paths are established between an IAB base station (also referred to as "IAB donor") directly connected to the core network and an IAB base station serving the UE (also referred to as "access IAB node" of the UE). Several intermediate IAB base stations (also referred to as IAB nodes) may be involved in each of several backhaul paths between an IAB donor and an access IAB node, thereby forming an alternative data path within the multi-hop IAB network.

By default, a path through the set of IAB nodes is defined along which data is preferably transmitted. Furthermore, one or more backup paths along the different sets of IAB nodes are defined, which may be used in case of Radio Link Failure (RLF) on any link of the default path. Links are defined between two consecutive IAB nodes in the backhaul network. The backup path is also useful in cases where the link is congested due to excessive demand for application traffic compared to the default link capacity. Traffic rerouting to the backup path or load balancing between the default path and one or more backup paths may be activated to alleviate congestion.

Like the gNB, the IAB donor consists of a central unit (CU or gNB-CU function) and one or more distributed units (DU or gNB-DU function). Each IAB node (including an access IAB node) directly or indirectly coupled to an IAB donor includes an IAB-MT (IAB mobile terminal) to communicate in an upstream direction towards the IAB donor and an IAB-DU (IAB distributed unit) to communicate in a downstream direction towards the UE.

To enable routing through multiple backhaul hops, a specific IAB protocol sublayer (backhaul adaptation protocol (BAP) sublayer specified in 3GPP release 16 specification TS 38.340 (release 16.3.0)) was introduced. There is one BAP entity in each IAB-MT, one BAP entity in each IAB-DU, and one BAP entity in each IAB donor DU. Each IAB node and each IAB donor DU is assigned a unique BAP address. The BAP sublayer encapsulates the IP SDUs (service data units) into BAP PDUs (protocol data units), where each BAP PDU consists of a BAP header and a payload portion (which includes the IP SDUs).

The BAP header includes a BAP route ID, which is a concatenation of a destination BAP address and an identifier (path ID) of a backhaul path to be followed. The BAP route ID is set by the BAP sublayer of the initiator IAB donor DU (in the downstream direction) or the initiator IAB node (in the upstream direction). The BAP PDUs are then routed according to the BAP route IDs using a backhaul routing table configured by the IAB donor CUs in each IAB node and in each IAB donor DU. Upon receipt of a BAP PDU in the BAP entity, the destination BAP address is compared with the local BAP address. If the local address matches the destination BAP address, the BAP header is removed and the payload is delivered to the upper layer.

For the BAP entity in the IAB donor DU, if the destination BAP address does not match the local BAP address, the BAP PDU is discarded. For BAP entities in the IAB-MT or IAB-DU of the IAB node, if the destination BAP address does not match the local BAP address, the BAP PDU is delivered to the concatenated BAP entity for routing and transmission to the next hop. The backhaul routing table provides an egress link corresponding to the next hop BAP address using the BAP routing ID in the BAP PDU header as an entry of the table. In case the indicated egress link is not available, e.g. due to Radio Link Failure (RLF), an entry with the same destination BAP address is selected regardless of the path ID. If there is no entry in the routing table that matches the BAP route ID or destination BAP address of the BAP header, the BAP PDU is discarded.

According to the behavior described for IAB, the 3GPP release 16 specification does not allow rerouting BAP PDUs in an upstream direction towards a different IAB donor DU, even if several IAB donor DUs provide connections to the same IAB donor CU. In fact, in the upstream direction, the destination BAP address of the BAP PDU corresponds to one of the available several IAB donor DUs. Since the IAB donor DUs are set with different BAP addresses, it is possible for the IAB node to find an alternative path in its routing table to reach the IAB donor DU for which the destination BAP address is intended, but the IAB node does not have information to identify the alternative IAB donor DUs that can be reached through the alternative path. Furthermore, assuming that the BAP PDU arrives at the alternative IAB donor DU, the latter will discard the BAP PDU because the destination BAP address will not match its own BAP address.

Furthermore, 3GPP has been considering inter-donor redundancy, where an IAB node, called a border IAB node, can access two different parent nodes connected to two different IAB donor CUs. Thus, the border IAB node, while belonging to a single IAB network (i.e. belonging to a single IAB donor CU used for configuration and management), is able to route BAP PDUs from a first IAB network managed by a first IAB donor CU to a second IAB network managed by a second IAB donor CU. An advantage of such inter-donor redundancy is the ability of the first IAB donor CU to offload by routing some of its BAP PDUs via the second IAB network, thereby alleviating congestion problems or overcoming radio link failure problems that may occur in the first IAB network. However, since assignment of BAP address, BAP path ID, and backhaul radio link control channel identifier (BH RLC CH ID) is independently made in each IAB network, the same value may be assigned in each topology, for example, an IAB node belonging to a first IAB network may be assigned the same address as an IAB node belonging to a second IAB network, which may cause a significant routing problem. For example, if a border IAB node of a first IAB network has the same address as an IAB node in a second IAB network, when the border IAB node receives a BAP PDU with a header that includes a destination BAP address that matches the address of the border IAB node (and thus the address of the IAB node in the second IAB network), the border node will not be able to decide whether the BAP PDU is for the border IAB node and thus has to be forwarded to an upper layer or is intended for an IAB node in the second IAB network and thus has to be forwarded to the next hop. Similarly, the IAB node may reroute the BAP PDU to the wrong destination IAB node.

Thus, new mechanisms are needed to overcome the above problems while limiting the complexity of processing at the IAB node and the delay that would be caused by such processing.

Disclosure of Invention

According to a first aspect of the present invention there is provided a method for processing data packets at an IAB node in an integrated access and backhaul communication system, i.e. an IAB communication system, the 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 to update the routing identifier prior to transmitting the data packet to another IAB node;

in response to determining to update the routing identifier:

Identifying a new routing identifier and an associated IAB topology based on the header overwrite configuration information and the received routing identifier of the data packet;

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 an egress backhaul link through which the data packet is to be routed to a next IAB node based on the route configuration information associated with the identified IAB topology and the identified new route identifier; and

And transmitting the update data packet to the next IAB node through the outlet backhaul link.

The present invention provides for routing data packets, such as Backhaul Adaptation Protocol (BAP) Protocol Data Units (PDUs), etc., through one or more Integrated Access Backhaul (IAB) networks or one or more IAB topologies, and thus allows for rerouting 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). In the following description, the term IAB topology is used interchangeably with IAB network.

Processing resources and processing time (which affects latency) may be saved by avoiding that the IAB must unnecessarily parse all information of the route configuration information and/or the route identifier mapping information (e.g., unnecessarily parse all route identifiers in the route identifier mapping information when no match is found for the corresponding route identifier) when processing the data packet for routing in the IAB communication system by first checking whether to update the route identifier of the received data packet before identifying the egress backhaul link through which the data packet is to be routed to another IAB node.

The example arrangement has an update (or overwrite) indication (such as an update field or destination address field for each entry of the routing configuration table, etc.) for each routing identifier in the routing configuration information to indicate whether the routing identifier is to be updated. This enables the IAB node to determine whether to update the route identifier without having to first parse all the information in the route configuration information and check whether there are available egress backhaul links for each possible route option. Furthermore, the IAB node has the flexibility to update the received routing identifier of the data packet based on the current radio conditions and congestion (i.e. optimize the routing of the data packet based on the current conditions). For example, when the IAB node detects that no egress link is available in the second IAB topology after updating the route identifier of the received packet, the IAB node may invalidate the update indication for the route identifier in the route configuration information and thereby save some processing time when routing a next packet with the same route identifier.

In an example, the received packet is a Backhaul Adaptation Protocol (BAP) packet that includes a BAP header that includes a routing identifier.

The header rewrite configuration information (also referred to as route identifier mapping information) may include a header rewrite configuration table including fields for indicating an IAB topology associated with the new route identifier.

In an example, the received packet is a Backhaul Adaptation Protocol (BAP) packet, the BAP data including a BAP header including a routing identifier, and the routing configuration information includes a backhaul routing configuration table including a field for indicating whether to update the BAP routing identifier of the received packet.

The route identifier mapping information may include a route identifier mapping table including fields for indicating an IAB topology associated with the BAP route identifier to be updated and/or fields for indicating an IAB topology associated with the new route identifier.

According to a further aspect, there is provided a method for processing data packets at an Integrated Access and Backhaul (IAB) node in an IAB communication system as claimed in any one of claims 21 to 24.

By providing the IAB node with a backhaul RLC channel mapping configuration table including a field for indicating a topology associated with a previous IAB node and a next IAB node and/or a backhaul RLC channel mapping configuration table including a field for indicating a topology associated with a next IAB node, a backhaul RLC channel matching a desired QoS may be selected and used by the IAB node to route data packets to the next IAB node for the egress backhaul link, whether the next IAB node is in the same IAB topology as the IAB node or a different IAB topology. In other words, using a backhaul RLC channel mapping configuration table including fields for indicating topologies alleviates routing problems in each IAB network (where the same values may be assigned in each topology) due to independent assignment of BAP addresses, BAP path IDs, and backhaul radio link control channel identifiers (bhrlc CH IDs).

According to a further aspect, there is provided a method for managing the processing of data packets in an Integrated Access and Backhaul (IAB) communication system as claimed in any one of claims 25 to 35.

According to a further aspect there is provided a method for processing data packets at an Integrated Access and Backhaul (IAB) node in an IAB communication system as claimed in claim 36 of the accompanying claims.

By determining whether an update packet is to be delivered to an upper layer (i.e., by making a determination of whether the packet is to be delivered to an upper layer after updating or overwriting the received packet with the determined new routing identifier to provide an update packet), a check can be made to determine whether the update packet has arrived at its destination and should be delivered to the upper layer. If no check is made after the received packets are updated or rewritten, they may be discarded even when they reach their correct destination.

According to another aspect, there is provided an apparatus of an Integrated Access and Backhaul (IAB) node according to claim 40.

According to another aspect of the present invention there is provided an Integrated Access and Backhaul (IAB) node according to claim 50.

According to another aspect of the present invention, there is provided a donor Central Unit (CU) according to claim 51.

According to another aspect, there is provided an apparatus of a donor central unit, donor CU, of an integrated access and backhaul communication system, i.e. an IAB communication system, comprising at least two IAB topologies, each comprising a plurality of IAB nodes and a donor central unit, donor CU. The apparatus comprises: a processing unit; and a memory operably connected to the processing unit and for storing instructions that, when executed by the processing unit, configure the processing unit to: providing, for at least one IAB node of the first IAB topology, packet routing configuration information for routing a packet through at least the first IAB topology, wherein the packet routing configuration information comprises a routing configuration table and a header overwrite configuration table, wherein the routing configuration table comprises at least one entry comprising: a route identifier field for a route identifier, the route 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 route 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 the header overwrite configuration table comprises at least one entry comprising: a previous route identifier field for a route identifier; a new route identifier field for the route identifier; and a new topology field for indicating an IAB topology associated with a route identifier in the new route identifier field.

According to another aspect, there is provided an apparatus of a donor central unit, donor CU, of an integrated access and backhaul communication system, i.e. an IAB communication system, comprising at least two IAB topologies, each comprising a plurality of IAB nodes and a donor central unit, donor CU. The apparatus comprises: a processing unit; and a memory operably connected to the processing unit and for storing instructions that, when executed by the processing unit, configure the processing unit to: for at least one IAB node of a first IAB topology, providing packet routing configuration information for routing a packet through at least the first IAB topology, wherein the packet routing configuration information comprises a header overwrite configuration table comprising fields for indicating an IAB topology associated with a new routing identifier.

According to another aspect, there is provided an apparatus of a donor central unit, donor CU, of an integrated access and backhaul communication system, i.e. an IAB communication system, comprising at least two IAB topologies, each comprising a plurality of IAB nodes and a donor central unit, donor CU. The apparatus comprises: a processing unit; and a memory operably connected to the processing unit and for storing instructions that, when executed by the processing unit, configure the processing unit to: providing, for at least one IAB node of a first IAB topology, packet routing configuration information for routing packets through at least the first IAB topology, wherein the packet routing configuration information comprises a backhaul RLC channel mapping configuration table having at least one entry comprising:

For a next hop address field of a next hop address of a next IAB node following the at least one IAB node in the routing path,

An egress topology field for indicating an IAB topology associated with the next IAB node and for indicating an egress backhaul link between the IAB node and the next IAB node using the next-hop address field,

An egress backhaul RLC channel identifier field for a backhaul RLC channel identifier of a backhaul RLC channel used for the egress backhaul link, and/or

For a previous hop address field of a previous hop address of a previous IAB node preceding the IAB node in the routing path,

A ingress topology field for indicating an IAB topology associated with the previous IAB node and for indicating an ingress backhaul link between the IAB node and the previous IAB node using the previous hop address field,

An ingress backhaul RLC channel identifier field for a backhaul RLC channel identifier of a backhaul RLC channel used by the ingress backhaul link.

According to another aspect, there is provided an apparatus of a first donor central unit, i.e. a first donor CU, of an integrated access and backhaul communication system, i.e. an IAB communication system, comprising at least two IAB topologies, each comprising a plurality of IAB nodes and a donor central unit, i.e. a donor CU. The apparatus comprises: a processing unit; and a memory operably connected to the processing unit and for storing instructions that, when executed by the processing unit, configure the processing unit to:

providing a request for establishing a route of a data packet between a first IAB topology and a second IAB topology of the at least two IAB topologies for sending to a second donor CU of the second IAB topology;

Receiving a response from the second donor CU, the response including acknowledgement information indicating whether the request was accepted by the second donor CU, and configuration information in the event that the request was accepted by the second donor CU, the configuration information being related to one or more of the IAB nodes in the second IAB topology for identifying a routing path for routing data packets between at least one IAB node of the first IAB topology and at least one IAB node of the second IAB topology,

Wherein the request includes at least one of the following information elements, IE:

An IE identifying a routing direction for the request, the request involving routing a data packet from the first IAB topology to the second IAB topology if the routing direction is upstream, the request involving routing a data packet from the second IAB topology to the first IAB topology if the routing direction is downstream,

An IE identifying at least one IAB donor distributed unit or at least one IAB donor DU in the second IAB topology for use by the first donor CU to send or receive data packets,

An IE identifying an address of a border IAB node for use in a secondary IAB topology, wherein the border IAB node is an IAB node of the first IAB topology connected to an IAB node of the second IAB topology,

An IE indicating a destination of a data packet in a downstream direction, the destination being a border node of the first IAB topology or another IAB node,

An IE indicating the expected throughput for the data to be routed,

An IE indicating the quality of service or QoS for the data to be routed,

An IE indicating a backhaul RLC channel identifier or backhaul RLC channel ID for use by the first donor CU for a border IAB node on an ingress link in case of routing data in an upstream direction and/or for use by the first donor CU for a border IAB node on an egress link in case of routing data in a downstream direction,

An IE indicating that the contents of at least one previous routing identifier field of the configuration table are overwritten for the header in case of routing data in the upstream direction and/or the contents of at least one new routing identifier field of the configuration table are overwritten for the header in case of routing data in the downstream direction.

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

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

Furthermore, features implemented in hardware may be implemented in software and vice versa. Any reference herein to software features and hardware features should be construed accordingly. For example, according to other aspects of the invention, there is provided a computer program comprising instructions which, when executed by a processing unit, cause the processing unit to perform the method of any of the aspects or examples described above, and a computer-readable storage medium carrying the computer program.

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

Drawings

The various aspects of the present invention will now be described, by way of example only, with reference to the following drawings in which:

FIG. 1 is a schematic diagram illustrating an example wireless communication system in which the present invention may be implemented in accordance with one or more embodiments;

Fig. 2a and 2b are schematic diagrams illustrating stacks of some protocol layers involved in an IAB operation;

fig. 3 is a schematic diagram illustrating a format of a BAP Protocol Data Unit (PDU) or packet;

FIG. 4 is a schematic diagram illustrating route management in an IAB network;

fig. 5 a to 5 d illustrate fields of a routing table in an IAB node according to 3gpp TS 38.300;

FIG. 6 is a schematic diagram illustrating an example arrangement of an IAB network system exhibiting network path diversity in which the present invention may be implemented in accordance with one or more embodiments;

fig. 7 illustrates an example of fields of a routing configuration table at an IAB node according to an embodiment of the present invention;

fig. 8 illustrates an example of fields of a route identifier (route ID) mapping configuration table at an IAB node according to an embodiment of the present invention;

Fig. 9a illustrates an example of fields of a Backhaul (BH) RLC channel mapping configuration table at an IAB node according to an embodiment of the present invention;

Fig. 9b illustrates an example of a field of an uplink traffic-to-BH RLC channel mapping configuration table at an IAB node according to an embodiment of the present invention;

Fig. 10 illustrates an example method for managing BAP PDU routing through multiple IAB networks (or IAB topologies) using a flowchart in accordance with an embodiment of the present invention;

FIG. 11 is a schematic block diagram of an example wireless communication device in accordance with an embodiment of the invention;

Fig. 12 is a schematic simplified diagram illustrating an example message flow for managing BAP PDU routing through multiple IAB networks in accordance with an embodiment of the present invention;

Fig. 13 illustrates an example method for processing data packets at an IAB node in an IAB system comprising a plurality of IAB networks (or IAB topologies) using a flowchart diagram in accordance with a first embodiment of the invention;

Fig. 14 illustrates an example method for processing data packets at an IAB node in an IAB system comprising a plurality of IAB networks (or IAB topologies) using a flowchart diagram in accordance with a second embodiment of the invention;

fig. 15 illustrates an example of fields of a combined configuration table at an IAB node according to an embodiment of the present invention;

FIGS. 16a and 16b illustrate an example method at a donor CU for managing the processing of data packets in an IAB system, according to embodiments of the invention, using flowcharts;

fig. 17 illustrates another example method for managing BAP PDU routing through multiple IAB networks (IAB topologies) using a flowchart in accordance with an embodiment of the present invention;

fig. 18 illustrates another example method for managing BAP PDU routing through multiple IAB networks (IAB topologies) using a flowchart in accordance with an embodiment of the present invention; and

Fig. 19 illustrates 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 using a flowchart.

Detailed Description

Fig. 1 illustrates an example wireless communication system 100, particularly a mobile radio communication system such as a fifth generation (5G) new air interface (NR) system that includes wireless integrated access and backhaul networks. Although in the following description, embodiments of the present invention and examples of embodiments will be described for a 5G NR system, it will be understood that the present invention is not intended to be limited to a 5G NR system and may be used in any wireless communication system having an integrated access and backhaul network sharing radio resources for a wireless access link and a wireless backhaul link.

The system 100 includes a plurality of UEs (user equipments) 132, 133, 131 and 134, a remote core network 110, a master base station 120, and two Integrated Access and Backhaul (IAB) stations or IAB nodes 121 and 122 (hereinafter also referred to as IAB nodes).

The primary base station 120, also referred to as an IAB donor 120 (or IAB donor), is connected to the core network 110 by a wired link 101, preferably an optical fiber or any other wired component. In embodiments of the present invention and examples of embodiments, the IAB donor 120 is a 5G NR gNB with additional functionality to support the IAB feature, as defined in the 3GPP TS 38.300v16.2.0 specification document.

To extend the network coverage of IAB donor 120 and reach remote UEs 132, 133 and 131, operators install IAB stations 121 and 122 (also referred to as IAB nodes 121 and 122). By acting as a relay node between the IAB donor 120 and the UEs 132 and 133, the IAB nodes 121 and 122 allow overcoming the reachability problem due to the presence of the building 108, the building 108 being a barrier to propagation of radio waves and thus to direct attachment and further communication between the UE and the IAB donor 120. This is especially true when the communication between the IAB donor 120 and the UEs 132 and 133 operates at millimeter wave frequencies that are highly susceptible to shadowing phenomena.

The IAB donor 120 also serves the UE 134, and the UE 134 is directly connected to the IAB donor 120.

The IAB donor 120 and IAB stations 121 and 122 thus form a backhaul network or IAB network (also referred to as an IAB topology) housing the UEs 132, 133, 131 and 134.

The Integrated Access and Backhaul (IAB) specifications extend over several 3GPP standard documents, including:

a TS 38.300RAN architecture (V16.4.0),

The TS 38.321MAC protocol (V16.5.0),

The TS 38.331 Radio Resource Control (RRC) protocol (V16.5.0),

The TS 38.340 backhaul adaptation protocol layer V16.3.0,

A TS 38.401RAN architecture (V16.6.0),

-TS 38.473F1 application protocol (V16.4.0).

Since IAB nodes 121 and 122 are connected to UEs 131, 132 and 133, respectively, these IAB nodes are considered as access IAB nodes for the UEs to which they are connected, respectively.

The IAB donor 120 is a logical node providing an NR based wireless backhaul and consists of a central unit (CU or gNB-CU function) and connected donor distributed unit(s) (DU or gNB-DU function). The IAB donor CU or donor CU (hereinafter also referred to as IAB donor CU) hosts higher layer protocols such as PDCP (packet data convergence protocol) and RRC (radio resource control) protocols and the like for controlling the operation of one or more DUs, and each of the one or more IAB donor DUs or donor DUs (hereinafter also referred to as IAB donor DUs) includes lower layer protocols such as RLC, MAC, physical layer protocols and the like. The IAB donor CU or donor CU and the IAB donor DU or donor DU may be located remotely from one another or may be located in the same physical device. gNB-DU functionality is defined in 3GPP TS 38.401. As shown in fig. 2 a and 2b discussed below, the purpose is to terminate the NR access interface to the UE and the next-hop IAB node and to terminate the F1 protocol to the IAB donor gNB-CU function.

The IAB nodes 121, 122, which may serve multiple radio sectors, wirelessly backhaul to the IAB donor 120 through an intermediate IAB node via one or more hops. They form a Directed Acyclic Graph (DAG) topology with IAB donors at the root.

The IAB nodes are each composed of an IAB-DU and an IAB-MT (IAB mobile terminal). The gNB-DU function on the IAB node is also called IAB-DU and allows downstream (towards the UE) connection to the next hop IAB. The IAB-MT functions include, for example, physical layer, layer 2, RRC, and non-access stratum (NAS) functions to connect to the upstream IAB node (including the IAB donor 120, in this case, to the IAB donor gNB-DU, and thus to the core network 110 (e.g., for initialization, registration, and configuration)).

In this DAG topology, the neighbor nodes on the IAB-DU interface are called child nodes and the neighbor nodes on the IAB-MT interface are called parent nodes. The direction toward the child node is also referred to as downstream, while the direction toward the parent node is referred to as upstream.

The IAB donor 120 (e.g., the IAB donor CU) centrally manages resources, topology, and routes for the entire IAB topology. This includes: the IAB nodes are configured according to the network topology, for example, to perform appropriate routing of the data packets.

Fig. 2a and 2b schematically illustrate the stacks of some of the protocol layers involved in the IAB operation.

The F1 interface supports the exchange of signaling information between endpoints, and the transmission of data to the various endpoints. From a logical point of view, the F1 interface is a point-to-point interface between endpoints.

In 5G NR, F1-C is a functional interface in the Control Plane (CP) between an IAB donor CU (e.g., of IAB node 2) and an IAB node DU and between an IAB donor CU and an IAB donor DU. F1-U is a functional interface in the User Plane (UP) for the same unit. F1-C and F1-U are shown by reference numeral 212 in a of FIG. 2. In this example, F1-U and F1-C are carried over two backhaul hops (from IAB donor to IAB node 1, then from IAB node 1 to IAB node 2).

In the user plane, block 210 at the IAB donor CU and the IAB node DU refers to the GTP-U layer and block 211 refers to the UDP layer. GTP-U stands for GPRS tunneling protocol user plane. GTP-U tunneling is used to carry encapsulated PDUs and signaling messages between a given GTP-U tunnel endpoint pair (see 3gpp ts29.281 for more details), here block 210 at the IAB donor CU and the IAB node DU. The well known User Datagram Protocol (UDP) is a transport layer protocol that provides best effort datagram services and is suitable for use with the IP protocol.

In the control plane, block 210 indicates the F1AP (F1 application protocol) layer, and block 211 indicates the SCTP (stream control transmission protocol) layer. The F1 application protocol (as defined in 3gpp TS 38.473 and TS 38.401) provides signaling services, or UE-associated services, between the IAB donor CU and the IAB node DUs. Such as initialization, configuration, etc. The well known SCTP layer utilizes congestion control to provide reliable sequential delivery of messages.

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

When the IAB donor CU is remote from the IAB donor DU, or in a virtual instantiation locally on the same physical machine as the IAB donor CU and the IAB donor DU, the transport between the IAB donor DU and the IAB donor CU also uses the IP transport layer over various media (e.g., wires or optical fibers). An IAB specific transfer between an IAB donor CU and an IAB donor DU is specified in 3gpp TS 38.401.

L1 and L2 on a of fig. 2 represent the transport layer and physical layer, respectively, of a medium suitable for use.

The IP layer may also be used for non-F1 traffic such as operation, management, and maintenance traffic, etc.

On a wireless backhaul, the IP layer itself is carried over a Backhaul Adaptation Protocol (BAP) sublayer, which enables routing over multiple hops. BAP sublayers are specified in TS 38.340.

IP traffic of the IAB-DUs is routed through the wireless backhaul via the BAP sublayer. In the downstream direction, upper layer packets are encapsulated by the BAP sublayer at the IAB donor DU, thereby forming BAP packets or Packet Data Units (PDUs) or data packets. BAP packets are routed by the BAP layer or entity (and the corresponding BAP entities in the IAB-DUs and IAB-MTs) of the intermediate IAB node (also referred to as relay node), if present. The BAP packets are eventually decapsulated by the BAP sub-layer at the destination IAB node (which may be an access IAN-node if the upper layer packets in the BAP packets are intended for the UE).

In the upstream direction, the upper layer packets are encapsulated by the BAP sub-layer at the initiator IAB node (which may be an access IAB node if the upper layer packets are from UEs), thereby forming BAP packets or data units (PDUs) or data packets. BAP packets are routed by the BAP layer (and corresponding BAP entities in the IAB-DUs and IAB-MTs) of the intermediate IAB node (if present). The BAP packets are finally decapsulated by the BAP sublayer at the IAB donor DU.

On the BAP sublayer, packets are routed based on a BAP routing ID that is carried in the BAP header of the BAP packet and set by the BAP sublayer that transmitted the IAB donor DU or the initiator IAB node (e.g., a network node in the IAB network that generated the BAP packet). Fig. 3 illustrates a format of a BAP data Protocol Data Unit (PDU) or packet. This format is specified in paragraph 6.2 of the standardization version of 3gpp ts38.340 version 16.3.0.

The payload portion 307 is typically an IP packet. Header 30 includes fields 301 through 306. The field 301 (referred to as D/C field) is a boolean value indicating whether the corresponding BAP packet is a BAP data packet or a BAP control packet. Fields 302 through 304 are 1-bit reserved fields, preferably set to 0 (to be ignored by the receiver).

Fields 305 and 306 together indicate the BAP route ID of the BAP packet. The BAP address field 305 (also referred to as a destinationfield) is located in the leftmost 10 bits, while the BAP PATH identification field 306 (also referred to as a 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 IAB donor DU of the BAP packet. For routing purposes, each IAB node and IAB donor DU in the IAB network (by the IAB donor CU of the IAB network) is configured with a specified and unique BAP address.

Field 306 carries a path ID that identifies the routing path that the BAP packet should follow in the IAB topology to reach the destination. For routing purposes, the routing paths (including their path IDs) are configured in the IAB node (by the IAB donor CUs of the IAB network).

The BAP header is added to a packet when it arrives at the BAP layer from an upper layer, and stripped by the BAP sub-layer when the packet arrives at its destination node. The selection of the packet's BAP route ID is configured by the IAB donor CU.

For example, when a BAP packet is generated by a node (i.e., by an IAB donor DU for downstream transmissions or by an initiator (which may be an access IAB node in case of an upper layer packet from a UE)) a BAP header with a BAP route ID is constructed by the node according to a configuration table defined in 3gpp TS 38.340. This table is referred to as the downlink traffic-to-route ID mapping configuration table in the IAB donor DU or the uplink traffic-to-route ID mapping configuration table in the initiator IAB node. In the intermediate IAB node, the BAP header field has been specified in the BAP packet for forwarding.

As described above, these configuration tables defining BAP paths (thus taking into account the routing policies of the IAB network topology and the configuration of the IAB nodes) are typically defined by the IAB donor CUs and transmitted to the IAB nodes to configure these IAB nodes.

The use of these tables (and other tables) for routing is described below with reference to fig. 5 a-5 d.

To transmit messages on the 5G NR radio medium, three further sublayers (RLC, MAC and PHY) are implemented at each IAB node below the BAP sublayer. The RLC (radio link control) sublayer is responsible for segmentation or reconstruction of packets. The RLC sublayer is also responsible for requesting retransmission of lost packets. The RLC layer is further described in TS 38.322. The MAC (media access channel) protocol sub-layer is responsible for selecting the available transport formats for the user data and for mapping the logical channels to the transport channels. The MAC also handles part of the hybrid automatic repeat request scheme. The MAC layer is detailed in TS 38.321. On the transmitter or transmitter side, the MAC encapsulates data packets sent from the RLC. The MAC adds a header carrying information required for the MAC function. At the receiver side, the MAC decapsulates the data packet sent from the PHY, deletes its header and passes the remaining data to the RLC. The PHY sub-layer provides an electrical interface with the transmission medium (air) by: converting the information stream into a physical modulation signal, modulating a carrier frequency at the transmitter side; at the receiver side, the physical modulation signal is converted back into an information stream. PHY layers are described in TS 38.201, TS 38.211, TS 38.212, TS 38.213, TS 38.214.

To deliver messages towards the user plane or control plane, two other sublayers are used in the UE and the IAB donor CU: a PDCP (packet data convergence protocol) sublayer, an SDAP (service data adaptation protocol) sublayer for user plane communication or an RRC (radio resource control) sublayer for control plane communication.

The PDCP sublayer processes IP header compression/decompression, ciphering/deciphering, and, if necessary, integrity of the data packet. The packets are, by necessity, numbered on the transmitter side and reordered on the receiver side. PDCP sublayers are described in 3gpp ts 38.323.

The SDAP sublayer 220 of the user plane handles quality of service. The SDAP sub-layer is described in TS 38.324. On the UE side, the SDAP sublayer exchanges payload data with the user's applications (voice, video, etc …, not shown in the figure). On the IAB donor CU side, the SDAP sublayer exchanges data with the core network 110 (internet traffic, cloud, etc …).

The RRC sublayer 220 for the control plane handles the configuration of the protocol entities of the user plane protocol stack. The RRC sublayer is described in TS 38.331. The RRC sublayer is responsible for the processing: broadcasting information required by the communication between the UE and the cell; transmitting paging message, managing connection, including establishing bearing; a mobility function; measurement configuration and reporting; device capabilities; and others.

The interface between the nodes using layer PDCP, RLC, MAC and PHY (for both CP and UP) is referred to as NR-Uu. This mainly involves an interface with the UE.

The interface between the nodes using layer BAP, RLC, MAC and PHY (for both CP and UP) is referred to as the backhaul RLC channel (BH RLC channel). This mainly involves the interface between the IAB nodes.

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

B of fig. 2 comes from 3gpp TS 38.300, v16.4.0 and illustrates the protocol stacks for RRC and NAS connections supporting the IAB-MT. The non-access stratum (NAS) protocol handles messages between the core network and the user equipment or IAB node. The NAS protocol manages the establishment of a communication session and maintains communication with an IAB node or user equipment as the user equipment moves. 5G NAS is described in 3GPP TS 24.501. The 5G core access and mobility management function (AMF) is a function within the core network for receiving all connection and session related information from UEs connected to the IAB node and receiving similar information of the IAB node. The AMF is responsible only for handling connection and mobility management tasks.

The IAB-MT establishes a signaling radio bearer SRB (bearer carrying RRC and NAS messages) with the IAB donor CU. These SRBs are transported between the IAB-MT and its parent node(s) over the NR-Uu interface(s).

Fig. 4 illustrates route management in an IAB network. Route management at an IAB node acting as a relay is based on a BAP route configuration and attempts to determine a BH RLC channel of an egress link or backhaul link (also referred to as an egress backhaul link) for forwarding a received BAP packet from a BH RLC channel of an ingress link or backhaul link (through which the BAP packet is received) (also referred to as an ingress backhaul link).

The BAP routing configuration may be manually set in each IAB node of the IAB network. Preferably, the BAP routing configuration is built and can be updated over time by the IAB donor CU and transmitted to the IAB node by the IAB donor CU via F1AP signaling during its initial configuration and lifetime of the IAB network. As described above, the BAP routing configuration may be constructed by the IAB donor CUs based on the IAB network topology and its evolution over time (e.g., if some radio links disappear or recover or their link quality changes).

The BAP routing configuration of the IAB node includes various routing tables, four of which are shown in fig. 5.

Fig. 5a schematically shows an entry 500 of a backhaul routing configuration table for a BAP sublayer as defined in 3gpp TS 38.300, V16.4.0, section 6.11.3. The IAB node uses the entry to select an egress link to forward or transmit a BAP packet or PDU (protocol data unit) to the next-hop IAB node.

The field 501 defines a BAP route ID (concatenation of PATH field 5012 and destinationfield 5011 corresponding to PATH field 306 and destinationfield 305 as defined in fig. 3), and the field 502 specifies the BAP address of the next hop, i.e., the BAP address of the next IAB node along the PATH corresponding to the route ID 501. The next hop BAP address 502 thus identifies the egress link used to forward or transmit the BAP packet. The next-hop BAP address and the egress link are synonymous in that they each designate the same portion (radio link or backhaul link) of the IAB network between the current IAB node (e.g., intermediate or relay IAB node) and the next IAB node having the next-hop BAP address. As a result, with respect to 3GPP release 16 for 5G NR, the next hop BAP address and egress link may be used interchangeably to designate such an IAB network radio link or backhaul link.

There may be several entries in the backhaul routing configuration table that have the same destination BAP address but different path IDs and next hop BAP addresses in the information element 502. The first entry in the backhaul routing configuration table may provide a default next-hop BAP address corresponding to a default path to the destination, and other entries with the same destination BAP address relate to backup redundant paths to be selected when the default link is not available, e.g., due to Radio Link Failure (RLF).

Fig. 5b schematically shows an entry 510 of a BH RLC channel mapping configuration table for a BAP sublayer as defined in 3gpp TS 38.300, 6.11.3 th and/or 3gpp TS 38.340, V16.3.0, 5.2.1.4.1 th. An IAB node (e.g., an intermediate IAB node) acting as a relay uses the entry to identify a Backhaul (BH) RLC channel where BAP packets or PDUs are to be forwarded over an egress link previously selected using a backhaul routing configuration table.

An Information Element (IE) 511 stores the next hop BAP address as previously defined and typically obtained from the backhaul routing configuration table; IE 512 stores the previous hop BAP address, i.e., the BAP address of the previous IAB node from which the BAP packet arrived; IE 513 specifies the ingress RLC channel ID, i.e., the identifier of the RLC channel on which the BAP packet was received; and IE 514 stores the egress RLC channel ID, which provides the RLC channel that the IAB node will use to forward BAP packets.

The previous hop BAP address of IE 512 is synonymous with the ingress link in that they each specify the same portion of the IAB network (radio link or backhaul link) between the current IAB node (e.g., intermediate or relay IAB node) and the previous IAB node having the previous hop BAP address. As a result, with respect to 3GPP release 16 for 5G NR, the previous hop BAP address and ingress link may be used interchangeably to designate such an IAB network radio link or backhaul link.

Note that for a BH RLC channel in the downstream direction (parent-child direction, e.g., with the IAB node 402 toward the IAB node 403 in fig. 4), the BH RLC channel ID is included in the F1AP configuration of the BH RLC channel. For BH RLC channels in the upstream direction (child-to-parent direction, e.g., with IAB node 402 facing IAB node 401), the BH RLC channel IDs are included in the RRC configuration of the corresponding logical channels.

Fig. 5 c and 5d illustrate the equivalent of a BH RLC channel mapping configuration table for an IAB node that does not act as an intermediate IAB relay entity. These equivalents are defined in section 5.2.1.4.2 and section 5.2.1.4.3 of 3gpp TS 38.340.

The table in c of fig. 5 is referred to as uplink traffic-to-BH RLC channel mapping configuration table 520. The table is used by an initiator IAB node (not an IAB donor DU) that has constructed BAP packets or PDUs from the BAP SDUs (service data units) received from an upper layer to identify a Backhaul (BH) RLC channel for transmitting these packets in the upstream direction by using the previously selected egress link of the backhaul routing configuration table depicted in fig. 5 a.

IE 521 specifies the traffic type identifier of the SDU received from the upper layer, IE 522 indicates the next hop BAP address as previously defined and typically obtained from the backhaul routing configuration table, and IE 523 specifies the egress BH RLC channel Identifier (ID) providing the RLC channel to be used by the IAB node to transmit the BAP packet.

The table in d of fig. 5 is referred to as a downlink traffic-to-BH RLC channel mapping configuration table 530. The table is used by an IAB donor DU that has constructed BAP packets or PDUs from BAP SDUs (service data units) received from an upper layer to identify a Backhaul (BH) RLC channel, so that these BAP packets are transmitted in a downstream direction by using an egress link previously selected by the backhaul routing configuration table.

IE 531 is an IPv6 flow tag for classifying IPv6 flows, IE 532 specifies DSCP (differentiated services code point) as typically indicated in the IPv6 header of the packet, IE 533 indicates the destination IP address, IE 534 indicates the next-hop BAP address as defined above, and IE 535 defines an egress BH RLC channel ID that provides the RLC channel to be used by the IAB node to transmit the BAP packet.

The tables of fig. 5 b, 5 c and 5 d may consist of several rows (entries), each row/entry comprising an IE (or field) shown in the respective figure.

As a result of all tables configured in the IAB node, and more particularly the routing ID of IE 501, multiple BAP paths are defined by multiple IAB nodes.

Returning to fig. 4, typically, the routing of BAP packets using the BAP sublayer of the IAB node 402 would use the BAP route IDs 305+306 of the BAP packets. The BAP address (destinationfield 305) is used for the following purposes:

1) It is determined whether the BAP packet has arrived at a destination node on the BAP sublayer, i.e., an IAB node or an IAB donor DU. If the BAP address 305 in the packet's BAP header matches the BAP address configured via RRC on the IAB node or via F1AP on the IAB donor DU, the BAP packet has arrived at its destination node.

2) The next hop IAB node of the BAP packet that has not arrived at the destination is determined. This applies to BAP packets arriving from the previous-hop IAB node via the BAP sub-layer or received from an upper layer.

The determination of the next-hop IAB node for a packet arriving from a previous hop or previous IAB node or from an upper layer is based on the backhaul route configuration table 500.

The IAB node 402 resolves the next-hop BAP address 502 to a physical backhaul link, which is either link 420 or link 430. To this end, an entry in table 500 is found with field 501 matching BAP route ID 305+306 of the BAP packet. The corresponding field 502 provides the next hop BAP address.

The backhaul route configuration table may have multiple entries 500 with different BAP route IDs but with the same destination BAP address (meaning that the BAP path IDs are different). These entries may correspond to the same or different egress BH links. In the event that a BH link that matches the BAP route ID of a BAP packet experiences a Radio Link Failure (RLF), the IAB node may typically select another egress BH link (next hop BAP address) based on the route entry having the same destination BAP address (i.e., by disregarding the BAP route ID). In this way, BAP packets may be delivered via an alternative path in case the indicated path is not available.

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

The IAB node 402 then derives an egress BH RLC channel for the selected egress BH link upon which the BAP packet is to be transmitted or forwarded. To this end, the IAB node 402 uses a BH RLC channel mapping configuration table or an uplink traffic-to-BH RLC channel mapping configuration table or a downlink traffic-to-BH RLC channel mapping configuration table, depending on its role (intermediate or relay IAB node transmitting in uplink/upstream or downlink/downstream directions, an initiator IAB node, or an IAB donor DU).

For example, for an intermediate or relay IAB node, IEs 511, 512, 513 are inputs to the BH RLC channel lookup process, and IE 514 is an output of the BH RLC channel lookup process: IAB node 402 routes the incoming BAP packet received from ingress BH RLC channel ID 513 to egress BH RLC channel ID 514, where ingress BH RLC channel ID 513 belongs to the ingress BH link identified by previous hop BAP address 512 and egress BH RLC channel ID 514 belongs to the egress BH link previously selected and now identified by next hop BAP address 511.

For an initiator IAB node that wishes to transmit a BAP packet in an upstream direction to an IAB donor, IEs 521, 522 are input to the BH RLC channel lookup process, and IE 523 is output of the BH RLC channel lookup process: the IAB node 402 selects an egress BH RLC channel 523 corresponding to a table entry 520 in which table entry 520 the traffic type identifier 521 matches the traffic type of the original BAP SDU and the next hop BAP address 522 matches the next hop BAP address previously selected using the backhaul routing configuration table. This applies to BAP SDUs in the control plane (non-F1-U packets) and BAP SDUs in the user plane (F1-U packets). Traffic type identifier 521 should correspond to the destination IP address and TEID (tunnel endpoint identifier) of the BAP SDU.

For an IAB donor DU that wishes to transmit a BAP packet in a downstream direction to a destination IAB node or UE, IEs 531, 532, 533, 534 are input to the BH RLC channel lookup process, and IE 535 is output of the BH RLC channel lookup process: the IAB node selects an egress BH RLC channel 535 corresponding to a table entry 530, the table entry 530 matching the destination IP address 533 of the original BAP SDU, the IPv6 flow label 531 (BAP SDU used only to encapsulate IPv6 packets), and a Differentiated Services Code Point (DSCP) 532, and wherein the next hop BAP address 534 matches the next hop BAP address previously selected using the backhaul routing configuration table. This applies to BAP SDUs in the control plane (non-F1-U packets) and BAP SDUs in the user plane (F1-U packets).

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

Such routing processes may be implemented in various IAB 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 application may be implemented to provide network path diversity by the ability to route data packets across one IAB network and at least one other IAB network. In one example of implementation, the BH radio link operates on a millimeter wave band (i.e., above 30 GHz) that is highly susceptible to radio channel interference. The IAB network will also be referred to as an IAB topology or topology, so in the present application the terms IAB network as well as IAB topology and topology will be used interchangeably.

The IAB communication system 600 is comprised of two IAB networks or IAB topologies 691 and 692, each comprising a plurality of IAB nodes or at least one IAB node. The plurality of IAB nodes may include one or more initiator IAB donor DUs and one or more IAB nodes, such as an initiator IAB node generating a BAP packet, an intermediate or relay IAB node, and so on. Each IAB node communicates with at least one other IAB node over a wireless Backhaul (BH) link. IAB topology 691 is controlled by IAB donor CU 610 and IAB topology 692 is controlled by IAB donor CU 620. IAB topology 691 includes an IAB donor CU 610 and its associated IAB donor DUs, IAB donor DUs 601 and IAB donor DUs 602, and a plurality of IAB nodes 612 and 613 (similar to IAB nodes 121 and 122). IAB topology 692 includes an IAB donor CU 620, its associated IAB donor DUs, IAB donor DUs 603, and IAB node 611 (similar to IAB nodes 121 and 122). Although fig. 6 shows that IAB topology 692 includes only one IAB node 611, it will be appreciated that IAB topology 692 may include more than one IAB node (similar to IAB nodes 121 and 122). Furthermore, although fig. 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 that includes more than two IAB topologies (where each topology includes multiple IAB nodes, as discussed above).

The wired backhaul IP network is interconnected with IAB donor CUs 610 and 620 and IAB donor DUs 601, 602 and 603 by routers 640 and 650 and links 641, 642, 643, 651, 652 and 660. For example, these wired links consist of fiber optic cables.

IAB donor CU 610, IAB donor DU 601, IAB donor DU 602, IAB node 612, and IAB node 613 are part of the same IAB network or IAB topology 691 configured and managed by IAB donor CU 610.

The IAB donor CU 620, the IAB donor DU 603, and the IAB node 611 are part of the same IAB network or IAB topology 692 configured and managed by the IAB donor CU 620. The IAB network 692 is different from the IAB network 691. The IAB network 692 may be an IAB network adjacent to or contiguous with the IAB network 691.

The IAB node 611 is connected to the parent IAB donor DU 603 by a wireless BH link 634, while the IAB node 613 is connected to the parent IAB donor DU 601 by a wireless BH link 633.

IAB node 612 is connected to parent IAB donor DU 602 by a wireless BH link 631 and to child IAB node 613 by a wireless BH link 632. Although IAB node 612 belongs to IAB network 691, in view of the proximity of IAB node 612 to IAB network 692 and in particular to IAB node 611, IAB node 612 is also connected to IAB node 611 (which acts as a parent node to IAB node 612) by way of a wireless BH link 635. Since the IAB node 612 (though belonging to the IAB network 691) is also connected to the IAB node 611 belonging to the IAB network 692, the IAB node 612 may be referred to as a border node between the IAB network 691 and the IAB network 692. Since the IAB node or border node 612 is part of the IAB network 691, the IAB node or border node 612 is controlled (e.g., configured and managed) by the IAB donor CUs 610 of the IAB network 691. For example, IAB donor CU 610 configures border node 612 with configuration information during initial configuration and over time to account for any changes/updates in the configuration/topology of IAB network 691 (and IAB network 692 that may affect the configuration of border node 612).

In one or more embodiments of the invention, each IAB donor CU independently assigns a BAP address in the IAB topology it controls. Border nodes such as IAB node 612 are assigned two BAP addresses: one BAP address for topology 691 assigned by IAB donor CU 610 and one BAP address for topology 692 assigned by IAB donor CU 620. Since IAB node 612 is a border node belonging to IAB topology 691, IAB donor CU 610 may transmit both assigned BAP addresses to IAB node 612 in a configuration message as discussed below. Additionally or alternatively, IAB donor CU 610 may transmit the BAP address assigned by IAB donor CU 610 for topology 691 to IAB node 612 in a configuration message as discussed below (e.g., with reference to fig. 12), and IAB donor CU 620 may transmit the BAP address assigned by IAB donor CU 620 for topology 692 to IAB node 612 in a configuration message as discussed below.

Since the IAB donor DUs 601, 602, 603 and IAB nodes 611, 612, 613 serve UEs 627, 621, 622, 624, 623, 625, 626, respectively, they also serve as access IAB nodes for the respective UEs.

Between the pair of IAB nodes, there may be redundant PATHs, for example, with respect to the downstream PATH from IAB donor CU 610 to IAB node 613, the first default BAP PATH (PATH) 1 via IAB donor DU 601, the second BAP PATH (PATH 2) via IAB donor DU 602, and IAB node 612. Symmetrically, there are also two upstream paths involving the same node from the IAB node 613 to the IAB donor CU 610.

The BH radio link 633 between the IAB node 612 and the IAB donor DU 601 may experience radio link defects (e.g., radio Link Failure (RLF)) due to some unexpected interference or shadowing phenomena. In addition, link 633 may be congested with excessive data traffic.

For this reason, if possible, the IAB donor CU 610 may decide to reroute some BAP PDUs originally intended to be routed through PATH 1 by an alternative PATH (e.g., PATH 2) that would not involve BH radio link 633.

In addition to RLF or congestion degrading link 633, some congestion (or RLF) may also exist on link 631 between IAB node 612 and IAB donor DU 602. Since IAB node 612 is a boundary node related to topology 692, IAB donor CU 610 may decide to offload some BAP PDUs over an alternative path via topology 692. Upon request by the IAB donor CU 610, the IAB donor CU 620 may configure the IAB donor DU 603 and the IAB node 611 to route BAP PDUs for the topology 691 towards the border node 612. In other words, a third BAP PATH (PATH 3) exists between IAB donor CU 610 and IAB node 613 via IAB donor DUs 602, IAB nodes 611 and 612, and through BH radio links 634, 635 and 632 (which may be used to route packets in upstream and downstream directions through multiple IAB topologies (i.e., IAB topology 691 and IAB topology 692). This use case may be referred to as inter-topology routing.

Now considering the upstream transmission from IAB node 613 to IAB donor CU 610, IAB node 613 may be configured by IAB donor CU 610 to route BAP PDUs towards IAB donor DU 601 by default through link 633 (i.e., PATH 1 is the default PATH) and to route BAP PDUs towards IAB donor DU 602 as backup via IAB node 612 through links 632 and 631 as backup PATHs (PATH 2). In the case of RLF (or congestion) on link 633, IAB node 613 may decide to reroute BAP PDUs using the backup PATH (PATH 2). Further, border node 612 may be configured by IAB donor CU 610 to route BAP PDUs towards IAB donor DU 602 by default over link 631 and to route BAP PDUs towards IAB donor DU 603 as backup via IAB node 611 over links 635 and 634 as backup PATH (PATH 3). The latter use case may refer to inter-topology rerouting. Use case may refer to a rerouting between donor DUs in case of a rerouting towards another donor DU within the same topology.

A process for managing such a rerouting or offloading situation is now described in accordance with some embodiments of the present invention. The following description applies to routing packets in either the upstream or downstream directions.

Fig. 13 illustrates steps of an example method 1300 for processing data packets according to a first embodiment of the invention. The method 1300 proceeds at an IAB node in an IAB communication system (or an IAB arrangement) comprising at least two IAB topologies, wherein each IAB topology comprises a plurality of IAB nodes or at least one IAB node. For example, referring to the IAB communication system shown in fig. 6 and described with respect to fig. 6, the IAB node performing method 1300 may be an IAB node of a first IAB topology (or first IAB network) 691 or a second IAB topology (or second IAB network) 692. In other words, the IAB node belongs to the first IAB topology 691 or the second IAB topology 692 or is part of the first IAB topology 691 or the second IAB topology 692. Further, the IAB node may be an IAB donor DU (such as 601, 602, 603, etc.) for a data packet to be routed in a downstream direction, or an initiator IAB node for a data packet to be routed in an upstream direction (e.g., the initiator IAB node may be an IAB node transmitting data from a UE (i.e., serving as an access IAB node), or an IAB node transmitting control data from itself). The method as shown in fig. 13 and described with respect to fig. 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 fig. 11 and described with reference to fig. 11, wherein the method as shown in fig. 13 and described with respect to fig. 13 is performed by one or more processing units, such as a central processing unit 1111 or the like. For example, the program elements executed by the CPU 1111 of fig. 11 for the BAP entity (DU or MT part) of the BAP sub-layer may perform the method shown in fig. 13. The method of fig. 13 may be applied to route data packets in either the upstream or downstream direction.

Briefly, in step 1302, an IAB node receives a data packet (e.g., a BAP packet or a BAP PDU). The data packet includes a route identifier for routing the received data packet to the destination IAB node. The route identifier may include a destination address of the destination IAB node for the packet and a path identifier identifying a route path for the packet to the destination IAB node. In an example, the data packet includes a header that includes a destination address and a path identifier that together indicate a routing identifier (e.g., fields 305 and 306 of the BAP PDU of fig. 3). The IAB node may receive a data packet from a previous 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, etc.), or the IAB node may generate a data packet in a portion of the IAB node (such as in a portion or sub-layer of a BAP entity of the IAB node) and receive the generated data packet at another portion of the IAB node (such as to another portion or sub-layer of the BAP entity of the IAB node, etc.) 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 the 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. For example, the IAB node 612 of fig. 6 is part of the first IAB topology 691 or belongs to the first IAB topology 691, and upon receipt of a data packet for routing, 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 according to the routing identifier.

At step 1304, the IAB node determines an IAB topology associated with the received data packet. For example, when an IAB node receives a data packet from a previous IAB node over an ingress BH link, the IAB node determines an IAB topology associated with the received data packet by determining an IAB topology associated with the previous IAB node (which is also associated with the ingress backhaul link). As discussed below with reference to fig. 10, the BAP sub-layer of an IAB node may establish a relationship between the BAP address, topology, and backhaul links of the parent or child IAB node, which may then be used to determine the IAB topology associated with the received data packet. In examples where the IAB node is an initiator IAB node (e.g., receives data generated by the IAB node itself), the IAB node determines an IAB topology associated with the received data packet based on the IAB node knowing which IAB topology the IAB node belongs to. For example, for the initiator IAB node, the BAP route Identifier (ID) of the generated packet is indicated by a table (not shown) called an uplink traffic-to-route ID mapping configuration as described in section 5.2.1.2.1 of TS 38.340. The indicated BAP route ID will refer to the topology to which the initiator IAB node belongs.

At step 1306, the IAB node determines whether to update the routing identifier prior to routing the data packet to another IAB node based on the routing configuration information associated with the determined IAB topology and the routing identifier of the received data packet. In an example, the routing configuration information is a routing configuration table (or backhaul routing configuration table or BAP routing configuration table, etc.), such as the routing configuration table shown in fig. 7 and described with respect to fig. 7, etc. As described with reference to fig. 7, the routing configuration table 700 includes at least one entry each corresponding to the entry 500 of the backhaul routing configuration table of fig. 5a and an additional field, i.e., an update field 703 (also referred to as a overwrite field or header overwrite configuration field 703), the additional field, i.e., the update field 703, being used to identify the routing identifier of whether the entry is to be updated (or overwritten). In another example, also described below, each entry of the routing configuration table may correspond to entry 500 of the backhaul routing configuration table of fig. 5a, but wherein the routing configuration table is configured such that a next-hop address field having a certain value in at least a portion of the next-hop address field indicates that the routing identifier is to be updated or rewritten. In an example, a particular value in at least a portion of the update field or the next-hop address field of an entry indicates whether the route identifier is to be updated and the priority of the entry compared to another entry having the same route identifier or destination address. In another example, a particular value in at least a portion of the update field or the next-hop address field of the entry indicates whether the routing identifier of the data packet should be updated first (i.e., before attempting to route the data packet), or as a backup option if no egress link is found after attempting to route the data packet, or not at all.

The IAB node may determine whether to update the routing identifier by determining whether a routing option exists for the received data packet. For example, the IAB node determines whether a routing option exists for the received data packet in the routing configuration table by examining 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 the routing identifier in the routing identifier field of the entry or whether the destination address of the routing identifier of the received data packet matches the destination address in the destination address field of the entry. The IAB node determines whether to update the route identifier in response to determining that it matches an entry in the route configuration table and by examining a value in at least a portion of an update field (e.g., field 703) or a next-hop address field of the matching entry. The IAB node may determine to update the routing identifier when the value of the update field 703 indicates to update or rewrite the routing identifier, or when the value of at least a portion of the next hop address field corresponds to a certain value indicating to update or rewrite the routing identifier.

The IAB node may determine whether to update the routing identifier after determining RLF or congestion on the current egress backhaul link based on the routing identifier of the received packet.

When the IAB node determines to update the route identifier, the IAB node identifies a new route identifier and an IAB topology associated with the new route identifier (e.g., an IAB topology (egress backhaul link) associated with a next IAB node determined by the new route identifier) based on the route identifier mapping information and the route identifier of the received data packet at step 1308. In an example, the route identifier mapping information is a route identifier mapping table (or BAP route identifier mapping table) comprising at least one entry, wherein each entry comprises a field for indicating an IAB topology associated with the route identifier to be updated and/or a field for indicating an IAB topology associated with the new route identifier.

For example, the route identifier mapping table may include a previous route identifier field for the route identifier, a previous topology field for indicating an IAB topology associated with the route identifier in the previous route identifier field, a new or next route identifier field for the route identifier, and a new topology field for indicating an IAB topology associated with the route identifier in the new route identifier field, wherein an alternative routing option (e.g., at least one redundant PATH) is available. In an example, the route identifier mapping table is the route identifier mapping table shown in fig. 8 and described with respect to fig. 8. The IAB node may identify the new routing identifier and the IAB topology associated with the new routing identifier (e.g., an egress backhaul link over which the packet is to be routed) by examining the routing identifier mapping table to determine whether the routing identifier of the received packet matches the routing identifier in the previous routing identifier field of the entry or whether the destination address of the routing identifier of the received packet matches the destination address in the destination address field of the entry. When the IAB node determines to match an entry, the IAB node uses the route identifier in the new route identifier field of the matching entry as the identified new route identifier and uses the IAB topology indicated by the new topology field of the matching entry as the identified IAB topology associated with the new route identifier. The information in the topology field about the IAB topology provides an indication as to whether the packet is to be routed to the same or another IAB topology.

As discussed below with reference to fig. 7, 8 and also with reference to fig. 15, the fields of the routing configuration table may be combined with the 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 a first topology (e.g., IAB donor CU 610) and/or an IAB donor control unit CU of a second topology (e.g., IAB donor CU 620) using, for example, F1AP protocol messages (such as BAP mapping configuration messages, etc.). An example of how an IAB node may be configured is described below with reference to fig. 12.

At step 1310, 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. For example, the routing identifier of the received data may be replaced or rewritten with the new routing identifier.

At step 1312, the IAB node determines 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 the next IAB node) based on the identified IAB topology associated with the new route identifier and the route configuration information associated with the identified new route identifier. In other words, the IAB node looks for a routing option for the received data packet based on the routing configuration information associated with the identified IAB topology and the identified new routing identifier.

The IAB node may determine the next IAB node by examining a route configuration table associated with the identified IAB topology (which is associated with the egress backhaul link) to determine whether the identified new route identifier matches a route identifier in the route identifier field of the entry or whether the destination address of the new route identifier matches a destination address in the destination address field of the entry. When the IAB node determines to match an entry, the IAB node uses the next hop address in the next hop address field of the matching entry to determine the next IAB node.

The order of entries in the routing configuration table having the same routing identifier or destination address may indicate a priority order of the entries. In this case, checking the routing configuration table (e.g., when checking the table to determine whether to update the routing identifier of the received packet or when checking the table to determine the next IAB node) includes checking the entries according to their priority order.

At step 1314, the IAB node routes the update data packet to the next IAB node over the egress backhaul link.

The method 1300 may further include: it is determined whether an egress backhaul link is available (e.g., no RLF or congestion is detected) and, if so, the data packet is routed to the next IAB node over the egress backhaul link. If RLF or congestion is detected, the routing identifier of the received data packet is not updated or the new routing identifier in the updated data packet is updated or overwritten with the original routing identifier of the received data packet.

The IAB node need not perform the method 1300 in the order shown in fig. 13. For example, the updating step 1310 may occur before or after the determining step 1312 or substantially simultaneously with the step 1312.

As discussed below with reference to fig. 10, if the IAB node determines that the route identifier is not to be updated, an egress backhaul link is identified and, if the egress backhaul link is available (e.g., no RLF or congestion is present), the data packet is routed to the next IAB node through the egress backhaul link.

The method 1300 may further include: the backhaul RLC channel for the egress backhaul link is selected based on the identified IAB topology associated with the next IAB node (e.g., which is also associated with the egress backhaul link) and the backhaul RLC channel mapping information. In an example, 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 b of fig. 5 or c of fig. 5 or fig. 9a or fig. 9b, or the like. In another example, the BH RLC channel mapping information may provide information such as that shown in b of fig. 5 or c of fig. 5, where fields 511 and 522 indicate identifiers of egress links, and where field 512 indicates an identifier of ingress links. In this case, the ingress link identifier and the egress link identifier indicate both the link and the topology (primary/MCG or secondary/SCG).

In the case where the IAB node receives a packet from the previous IAB node through the ingress backhaul link, the BH RLC channel mapping configuration table corresponds to the table as described for b of fig. 5 or fig. 9 a. For the BH RLC channel mapping configuration table of fig. 9a, selecting the backhaul RLC channel for the egress backhaul link may include: the backhaul RLC channel mapping configuration table is checked to determine whether the backhaul RLC channel ID of the ingress backhaul link, the address of the previous IAB node, the determined IAB topology associated with the previous IAB node (e.g., ingress backhaul link), the 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 the entry in the backhaul RLC channel mapping configuration table. Upon determining to match the entry, the backhaul RLC channel ID of the matching entry is used to select a backhaul RLC channel for the egress backhaul link.

In the event that the IAB node receives a data packet generated by the IAB node (e.g., the IAB node is the initiator node), the BH RLC channel map configuration table corresponds to the table as described for fig. 5c or fig. 9 b. For the BH RLC channel mapping configuration table of fig. 9b, selecting the backhaul RLC channel for the egress backhaul link may include: the backhaul RLC channel mapping configuration table is checked to determine whether the traffic type of the data in the received data packet, the address of the next IAB node, and the identified IAB topology associated with the next IAB node (e.g., the egress backhaul link) match the respective fields of the entry in the backhaul RLC channel mapping configuration table. Upon determining to match the entry, the backhaul RLC channel ID of the matching entry is used to select a backhaul RLC channel for the egress backhaul link.

Processing resources and processing time (which affects latency) may be saved by first checking whether the routing identifier of a received data packet is to be updated before routing the data packet to another IAB node, e.g., 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 updating the routing identifier in response to determining to be updated and determining the next IAB node based on the updated routing identifier (i.e., by first checking the update field 703 or the destination address field to see if the routing identifier of the entry is to be updated). For example, processing resources and processing time may be saved by avoiding the IAB node from unnecessarily parsing all entries in the route identifier mapping table and/or the route configuration table (e.g., when no entries are found for the corresponding route identifier). For example, when a border node receives a data packet with an alias BAP address, unnecessary parsing of the routing configuration table may be avoided, because after determining that the routing identifier of the received data packet is to be updated using the routing configuration table, the IAB node may then directly check the routing identifier mapping table without continuing to parse the routing configuration table. Unnecessary parsing of the routing identifier mapping table may be avoided, e.g., when there is no entry for the routing identifier of the received packet, then there is no need to parse the routing identifier mapping table after determining that there is no available egress BH link through the routing configuration table. Furthermore, the IAB node has the flexibility to update the received routing identifier of the data packet based on the current radio conditions and congestion (i.e. optimize the routing of the data packet based on the current conditions). For example, when the IAB node detects that no egress link is available in the second IAB topology after overwriting the BAP route identifier, the IAB node may invalidate the overwrite indication for that route identifier in the routing configuration table and thereby save some processing time when routing a next BAP packet with the same BAP route identifier.

Fig. 14 illustrates steps of an example method 1400 for processing data packets according to a second embodiment of the invention. Method 1400 is performed at an IAB node in an IAB communication system (or an IAB arrangement) comprising at least two IAB topologies, wherein each IAB topology comprises a plurality of IAB nodes or at least one IAB node. For example, the IAB node performing method 1400 may be an IAB node of a first IAB topology (or first IAB network) 691 or a second IAB topology (or second IAB network) 692, shown in reference to fig. 6 and described with respect to fig. 6. In other words, the IAB node belongs to the first IAB topology 691 or the second IAB topology 692 or is part of the first IAB topology 691 or the second IAB topology 692. Further, the IAB node may be an IAB donor DU (such as 601, 602, 603, etc.) for a data packet to be routed in a downstream direction or an initiator IAB node for a data packet to be routed in an upstream direction (e.g., the initiator IAB node may be an IAB node transmitting data from a UE (i.e., acting as an access IAB node), or an IAB node transmitting control data from itself). The method as shown in fig. 14 and described with respect to fig. 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 fig. 11 and described with reference to fig. 11, wherein the method as shown in fig. 14 and described with respect to fig. 14 is performed by one or more processing units, such as a central processing unit 1111 or the like. For example, the program elements executed by the CPU 1111 of fig. 11 for the BAP entity (DU or MT part) of the BAP sub-layer may perform the method shown in fig. 14. The method of fig. 14 may be applied to route data packets in either the upstream or downstream direction.

Briefly, in step 1402, an IAB node receives a data packet (e.g., a BAP packet or a BAP PDU). The data packet includes a route identifier for routing the received data packet to the destination IAB node. The route identifier may include a destination address of the destination IAB node for the packet and a path identifier for identifying a route path for the packet to the destination IAB node. In an example, the data packet includes a header that includes a destination address and a path identifier that together indicate a routing identifier (e.g., fields 305 and 306 of the BAP PDU of fig. 3). The IAB node may receive a data packet from a previous 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, etc.), or the IAB node may generate a data packet in a portion of the IAB node (such as in a portion or sub-layer of a BAP entity of the IAB node) and receive the generated data packet at another portion of the IAB node (such as to another portion or sub-layer of the BAP entity of the IAB node, etc.) for routing to another IAB node. In the latter case, the IAB node is acting as an initiator IAB node.

In step 1403, the IAB node determines an IAB topology associated with the received data packet. For example, when an IAB node receives a packet from a previous IAB node over an ingress BH link, the IAB node determines an IAB topology associated with the received packet by determining an IAB topology associated with the previous IAB node (which is also associated with the ingress backhaul link). As discussed below with reference to fig. 10, the BAP sub-layer of an IAB node may establish a relationship between the BAP address, topology, and backhaul links of the parent or child IAB node, which may then be used to determine the IAB topology associated with the received data packet. In examples where the IAB node is an initiator IAB node (e.g., receives data generated by the IAB node itself), the IAB node determines an IAB topology associated with the received data packet based on the IAB node knowing to which IAB topology the AB node belongs. For example, for the initiator IAB node, the BAP route Identifier (ID) of the generated packet is indicated by a table (not shown) called an uplink traffic-to-route ID mapping configuration as described in section 5.2.1.2.1 of TS 38.340. The indicated BAP route ID will refer to the topology to which the initiator IAB node belongs. In the case where a data packet is received from an upper layer (e.g., the IAB node is the initiator node that generated the packet) and the IAB node uses a BH RLC channel mapping configuration table corresponding to the table as described with respect to fig. 9b, this step 1403 may be omitted.

In step 1404, the IAB node determines an egress backhaul link (through which the data packet is to be routed to the next IAB node) based on the routing identifier of the received data packet. In other words, the IAB node looks up the routing options for the received data packet based on the routing identifier of the received data packet. The IAB node may determine the egress backhaul link (through which the packet is to be routed to the next IAB node) by examining a backhaul routing configuration table (such as the backhaul routing configuration table of a of fig. 5 or the routing configuration table of fig. 7, etc.) using the routing identifier or the destination address of the routing identifier (e.g., as an input) to determine the address of the next IAB node. The backhaul routing configuration table has at least one entry, wherein each entry of the routing configuration table includes 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 the path identifier of the routing identifier. When there is a match with an entry in the backhaul routing configuration table (i.e., a routing option is found for the received packet), the IAB node determines an egress backhaul link based on the determined address of the next IAB node that matches the entry.

When there is no match with an entry in the backhaul routing configuration table (i.e., no routing option is found for the received data packet), the method may further include: a process is initiated for updating or overwriting the routing identifier (e.g., in the header of the received data packet, provided header update/overwriting is permitted). As part of the overwriting process, the IAB node uses the routing identifier of the received data packet to examine the routing identifier mapping table, 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 matching entry. The route identifier mapping table may include at least a previous route identifier field for the route identifier, and a new route identifier field for the route identifier (where an alternative route option (e.g., at least one redundant PATH) is available). The route identifier mapping table may comprise a table as shown in fig. 8 and described with respect to fig. 8. The IAB node then updates or rewrites the routing identifier of the received packet with the new routing identifier to provide an updated packet including the identified new routing identifier. The IAB node determines an egress backhaul link (through which the data packet is to be routed to the next IAB node) by checking the backhaul route configuration table using the new route identifier or the destination address of the new route identifier to determine an address of the next IAB node and determining an egress backhaul link based on the determined address of the next IAB node of the matching entry when there is a match with an entry in the backhaul route configuration table.

In step 1406, the IAB node determines an IAB topology associated with the next IAB node (e.g., which is also associated with an egress BH link over which the data packet is to be routed to the next IAB node). When the route identifier is not updated at step 1404, the IAB topology of the next IAB node is the same as the IAB topology associated with the received packet. When the route identifier is updated at step 1404, the IAB topology associated with the next IAB node may be determined from a route identifier mapping table, such as the one shown in fig. 8 and described with respect to fig. 8.

In step 1408, 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 the backhaul RLC channel mapping configuration table. In an example, 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 fig. 9a or 9b and described with respect to fig. 9a or 9b, or the like. As an alternative to the BH RLC channel mapping configuration table, as shown in fig. 9a and 9b (having fields 911, 912, and 922 indicating the egress/ingress topology) and described with respect to fig. 9a and 9b, the BH RLC channel mapping information may provide information such as the information shown in b of fig. 5 or c of fig. 5, etc., wherein fields 511 and 522 indicate the identifier of the egress link, and wherein field 512 indicates the identifier of the ingress link. In this case, the ingress link identifier and the egress link identifier indicate both the link and the topology (primary/MCG or secondary/SCG).

In the case where the IAB node receives a packet from the previous IAB node through the ingress backhaul link, the BH RLC channel mapping configuration table corresponds to the table as described with respect to fig. 9 a. Selecting the backhaul RLC channel for the egress backhaul link may include: the backhaul RLC channel mapping configuration table is checked to determine whether the backhaul RLC channel ID of the ingress backhaul link, the address of the previous IAB node, the determined IAB topology associated with the previous IAB node (e.g., ingress backhaul link), the 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 the entry in the backhaul RLC channel mapping configuration table. Upon determining to match the entry, the backhaul RLC channel ID of the matching entry is used to select a backhaul RLC channel for the egress backhaul link.

In the case of a data packet received from an upper layer (e.g., the IAB node is the initiator node that generated the packet), the BH RLC channel map configuration table corresponds to the table as described with respect to fig. 9 b. Selecting the backhaul RLC channel for the egress backhaul link may include: the backhaul RLC channel mapping configuration table is checked to determine whether the traffic type of the data in the received data packet, the address of the next IAB node, and the identified IAB topology associated with the next IAB node (e.g., the egress backhaul link) match the respective fields of the entry in the backhaul RLC channel mapping configuration table. Upon determining to match the entry, the backhaul RLC channel ID of the matching entry is used to select a backhaul RLC channel for the egress backhaul link.

At step 1410, the IAB node routes the update data packet to the next IAB node over the egress backhaul link.

Although not shown in fig. 14, method 1400 may further include: it is determined whether an egress backhaul link is available (e.g., no RLF or congestion is detected) and, if so, the data packet is routed to the next IAB node over the egress backhaul link. 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 another entry in the routing configuration table using the routing identifier or destination address of the routing identifier of the received packet.

Reference is now made to fig. 7. Fig. 7 illustrates an example of an entry of a routing configuration table 700 at an IAB node having at least one entry 710, 711, 712, according to an embodiment of the present invention. The entry 710 of the routing configuration table 700 corresponds to the entry 500 of the backhaul routing configuration table of a of fig. 5 having an additional field, i.e., an update field 703 (also referred to as an overwrite field 703), which is a routing identifier that identifies whether the entry is to be updated (or overwritten). Other fields of the backhaul route configuration table of fig. 5a (route ID field 501 (including destination address field 5011 and path identifier field 5012) and next hop BAP address field 502) are shown in fig. 7 and designated with the same reference numerals as in fig. 5 a.

An IAB node, such as IAB node 612, acting as a border node, may have one routing configuration table for the IAB topology to which the IAB node actually belongs (e.g., topology 691 for IAB node 612) (also referred to as primary or first topology), such as routing configuration table 700, shown in fig. 7 and described with reference to fig. 7, etc., and for each other topology to which the IAB node is connected (e.g., topology 692 for IAB node 612) (also referred to as secondary or second topology).

In one example, the routing configuration table 700 for both the primary topology and the secondary topology is configured by an IAB donor CU that manages the primary topology for the IAB node. For example, the routing configuration table 700 of IAB node 612 is configured by IAB donor CU 610 for both the primary topology (IAB topology 691) and the secondary topology (IAB topology 692).

In another example, the routing configuration table 700 for the primary topology is configured by an IAB donor CU managing the primary topology for the IAB node, while the routing configuration table 700 for the secondary topology is configured by an IAB donor CU managing the secondary topology for the IAB node. For example, for IAB node 612, routing configuration table 700 of IAB topology 691 (which is the primary topology) is configured by IAB donor CU 610, and routing configuration table 700 of IAB topology 692 (which is the secondary topology) is configured by IAB donor CU 620.

The IAB node 612 may have a separate routing configuration table 700 for each topology or a single routing configuration table 700 that is a combination of separate routing configuration tables for each topology. In the case of a single routing configuration table, an indication of which topology each entry is associated with may be provided.

The configuration of the routing configuration table 700 in the IAB node is discussed below with reference to fig. 12.

For a border node (like IAB node 612 in fig. 6), the next-hop BAP address field 502 of an entry of the routing configuration table 700 for a particular IAB topology (primary or secondary) is thus associated with the particular IAB topology (primary or secondary). In the case of a single routing configuration table 700 being a combination of separate routing configuration tables for each topology, the next-hop BAP address field 502 of an entry for a particular IAB topology (primary or secondary) in the single routing configuration table 700 is thus associated with the particular IAB topology (primary or secondary). Thus, the next-hop BAP address field 502 and associated topology define a unique egress link (or egress BH link).

Fig. 7 schematically illustrates a number of entries 711 and 712 (as with entry 710) of a backhaul routing configuration table 700, according to some embodiments of the present invention.

As discussed above, field 703 defines an update or overwrite field in addition to fields 501 and 502 and is used to indicate whether the routing identifier is to be updated.

In the event that an egress BH link identified by the DESTINATION address in the destinatino field 5011 and the PATH identifier in the PATH field 5012 of an entry in the routing configuration table 700 is not available, if the entry in the routing configuration table 700 has the same routing identifier in the routing ID field 501 or the same DESTINATION address in the destinatino field 5011 (i.e., the same DESTINATION address as the DESTINATION address identifying the unavailable egress BH link), and the overwrite field 703 indicates that the routing identifier is to be updated, the overwrite field 703 may indicate an alternate PATH available for the rewritten alternate egress BH link of fields 305 and 306 in the BAP header of the received packet. The alternative egress BH link may be determined using route identifier mapping information, such as route Identifier (ID) mapping table 800 shown in fig. 8 and described with reference to fig. 8, and the like.

In one example, the 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.

In one example, overwrite field 703 carries information indicating whether an alternate egress BH link is available by overwriting the BAP header. For example, the overwrite field 703 may be a one-bit field. In one example, setting the override field to "1" (or "0") may be used to indicate that the route identifier is to be updated (and an alternate path with an alternate egress BH may be available), and setting the override field to "0" (or "1") may be used to indicate that the route identifier is not to be updated (and an alternate path with an alternate egress BH is not available). The overwrite field 703 may also carry some priority information (e.g., the number in the overwrite field 703 of an entry may be used to indicate the priority of that entry compared to another entry in the overwrite field 703 having a different number) indicating whether the IAB node should consider an egress BH link determined using the routing ID mapping table 800 before or after another alternative egress BH link associated with another entry of the routing configuration table 700 for which the DESTINATION field 5011 matches the DESTINATION field 305 of the BAP header of the received packet. The priority indicated by overwrite field 703 may be used to indicate the order in which the egress BH links should be considered (e.g., first replacement in priority order and one or more additional backup replacements). In another example, the overwrite field 703 indicates whether the routing identifier of the packet should be updated first (i.e., before attempting to route the packet), as a backup option if no egress link is found after attempting to route the packet, or not at all.

In the example shown in fig. 7, the routing configuration table 700 includes a field or overwrite field 703 for the update, which is an additional field to the routing ID field 501 (including the destination address field 5011 and the path identifier field 5012) and the next hop BAP address field 502 of the backhaul routing configuration table of fig. 5 a. In another example, each entry of the routing configuration table may include the routing ID field 501 (including the destination address field 5011 and the path identifier field 5012) and the next hop BAP address field 502 of the backhaul routing configuration table of fig. 5 a, but where a value in at least a portion of the next hop address field or the next hop BAP address field 502 indicates that the routing identifier is to be updated. For example, the overwrite field may be indicated by a particular or some value (e.g., reserved address value) of the next-hop BAP address field 502 reserved for that use (such as a value of "0" or the like), which may be used to indicate that the route identifier is to be updated (and that an alternate path with an alternate egress BH may be available). In another example, a value in a portion 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, etc.) may be used to indicate that the route identifier is to be updated (and an alternate path with an alternate egress BH is available). As discussed above with respect to the routing configuration table 700 with the additional update or overwrite field 703, certain values in at least a portion of the next hop address field or the next hop BAP address field 502 may be used to provide priority information in addition to indicating whether the routing identifier is to be updated. In another example, some values in at least a portion of the next-hop address field or the next-hop BAP address field 502 may be used to indicate whether the routing identifier of the packet should be updated first (i.e., before attempting to route the packet), or as a backup option if no egress link is found after attempting to route the packet, or not at all.

In one example of an embodiment of the present invention, a BAP MAPPING CONFIGURATION (BAP map configuration) message (F1 AP protocol) as described in 3GPP TS 38.473v16.4.0 is used to transmit a routing configuration table (such as routing configuration table 700, etc.) to an IAB node. In the example discussed above for the routing configuration table 700 with additional update or overwrite fields 703, BAP MAPPING CONFIGURATION messages (F1 AP protocol) are used to transmit the routing configuration table 700 with the overwrite fields 703 introduced in the Information Element (IE) containing the table 700.

In one embodiment of the invention, the BH route information addition list Information Element (IE) defined in section 9.2.9.1 of 3GPP TS 38.473v16.4.0 is modified as follows to allow the IAB donor CU to configure the overwrite field 703.

IE/group name	Presence of
		BH route information addition list
BH route information addition list item
		> BAP route ID	Mandatory by force
> Next hop BAP Address	Mandatory by force
		> Rewriting	Optionally, an optional

The route identifier mapping information may include a route identifier mapping table. Fig. 8 illustrates an example of an entry of a route identifier mapping table or route ID mapping configuration (or header overwrite configuration) table with at least one entry 810 to 813 at an IAB node according to an embodiment of the present invention.

In one example, the routing ID mapping table 800 is configured by an IAB donor CU that manages the master topology for the IAB node. For example, with respect to fig. 6, the routing ID mapping table 800 of IAB node 612 is configured by IAB donor CU 610.

In another example, the routing ID mapping table 800 is configured by an IAB donor CU that manages a secondary topology for an IAB node. For example, with respect to fig. 6, the routing ID mapping table 800 of IAB node 612 is configured by IAB donor CU 620.

The configuration of the routing ID mapping table 800 in the IAB node is discussed below with reference to fig. 12.

Fig. 8 schematically illustrates several entries 811, 812 and 813 (like entry 810) of a routing ID mapping table 800 according to some embodiments of the present invention.

Both fields 821 and 831 define a routing identifier field or BAP routing ID of a routing identifier of a packet corresponding to a concatenation of PATH field 306 and destinationfield 305 as defined in fig. 3. The route identifier field 821 (hereinafter referred to as a previous route identifier field) is a previous route identifier for a packet, and includes a concatenation of a path field 8212 and a destination field 8211. The routing identifier field 831 (hereinafter referred to as a new (or next) routing identifier field) includes a concatenation of a path field 8312 and a destination field 8311 for a new or next routing identifier of a packet.

Topology field 822 (hereinafter referred to as the previous topology field) is used to indicate the IAB topology associated with the route identifier in previous route identifier field 821. Topology field 832 (hereinafter referred to as a new or next topology field) is used to indicate the IAB topology associated with the route identifier in new route identifier field 831. Topology fields 822 and 832 are both n-bit fields. In one example, the topology field (e.g., field 822 and/or field 832) indicates whether the topology is the one to which the IAB node actually belongs (such a topology may be referred to as a primary or first topology) or another topology to which the IAB node is additionally connected (such a topology may be referred to as a secondary or second topology). In another example, the topology field (e.g., field 822 and/or field 832) includes a topology identifier having a value that uniquely identifies a given topology. In the example shown in fig. 6, the primary topology for the border node (IAB node 612) is an IAB topology 691 and the secondary topology is an IAB topology 692. Thus, topology fields 822 and 832 in the route identifier mapping table for IAB node 612 will each have a value indicating either IAB topology 691 or IAB topology 692.

The field 820 formed by fields 821 and 822 is referred to as PREVIOUSBAP ROUTING (previous BAP route) Information Element (IE), and the field 830 formed by fields 831 and 832 is referred to as NEW BAP route Information Element (IE).

With respect to fig. 7, when an IAB node, such as IAB node 612, decides to route a packet through an alternative egress BH link requiring overwriting of fields 305 and 306 in the BAP header of the received packet based on information carried by an entry of the routing configuration table defined in fig. 7 (which corresponds to the routing identifier or destination address of the BAP header of the received packet), the IAB node may examine an entry in the routing ID mapping table 800 to determine whether the routing identifier of the received packet (which corresponds to the routing identifier field 501 associated with the overwrite field 703 considered for the entry of the routing configuration table) matches the routing identifier in the previous routing identifier field 821 of the entry, or whether the destination address of the routing identifier of the received packet matches the destination address in the destination address field 8211 of the entry. Upon determining to match an entry in the route ID mapping table 800, the IAB node then uses the route identifier in the new route identifier field 831 of the matching entry as a new route identifier to update or rewrite the BAP header of the received packet. The IAB topology indicated in the new topology field 832 of the matching entry is used as the identified IAB topology (e.g., the egress backhaul link) associated with the next IAB node.

The IAB node should then update or rewrite the received packet by replacing the DESTINATION address in the destinationfield 305 and the PATH identifier in the PATH field 306 in the BAP header of the received packet with the DESTINATION address in the new DESTINATION field 8311 and the PATH identifier in the new PATH field 8312, respectively, and eventually route the packet topologically as identified by the topology field 832 using the new routing identifier.

There may be several entries in the route ID mapping table 800 with the same destination BAP address in the destination address field 8211 but a different path identifier in the path field 8212 and a different route identifier in the new route identifier field 831. The order of the entries in the routing ID map 800 may indicate a priority order of the entries. For example, a first entry may provide a default new BAP address corresponding to a new default path to a destination, and other entries having the same destination BAP address are associated with backup redundant paths to be selected when a default link (e.g., due to Radio Link Failure (RLF) or congestion) is unavailable.

In one example of an embodiment of the present invention, a BAP MAPPING CONFIGURATION message (F1 AP protocol) as described in 3GPP TS 38.473v16.4.0 is used to transmit a route identifier mapping table, such as route ID mapping table 800, to an IAB node in case of introducing a new Information Element (IE) containing table 800.

The routing configuration table (such as routing configuration table 700 shown in fig. 7 and described with respect to fig. 7, etc.) may be separate from the routing identifier mapping table (such as routing ID mapping table 800 shown in fig. 8 and described with respect to fig. 8, etc.). Alternatively, as shown in fig. 15, the two tables may be combined in a single table, where fig. 15 shows an entry 1510 of an example combined configuration table 1500 according to an embodiment of the invention. Fields identical to those shown in fig. 7 and 8 are denoted by the same reference numerals.

Backhaul (BH) RLC channel mapping information may include a BH RLC channel mapping configuration table. Fig. 9a and 9b illustrate examples of entries of a BH RLC channel mapping configuration table according to an embodiment of the present invention. As an alternative to the BH RLC channel mapping configuration table, as shown in fig. 9a and 9b (having fields 911, 912, and 922 indicating the egress/ingress topology) and described with respect to fig. 9a and 9b, the BH RLC channel mapping information may provide information such as the information shown in b of fig. 5 or c of fig. 5, etc., wherein fields 511 and 522 indicate the identifier of the egress link, and wherein field 512 indicates the identifier of the ingress link. In this case, the ingress link identifier and the egress link identifier indicate both the link and the 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 IAB node according to an embodiment of the present invention. The BH RLC channel mapping configuration table 900 is used by an IAB node (e.g., an intermediate IAB node) acting as a relay to identify a Backhaul (BH) RLC channel for routing data packets (e.g., BAP packets or PDUs) through a backhaul route selected previously using the a backhaul route configuration table of fig. 5 or using an egress link selected previously using the route configuration table described with respect to fig. 7. A data packet is received at an IAB node from a previous IAB node (e.g., a previous hop IAB node) over an ingress BH link. Entry 910 of BH RLC channel mapping configuration table 900 corresponds to entry 510 of the BH RLC channel mapping configuration table of fig. 5b, but with additional fields 911 and 912. The additional field 911 is an egress topology field for indicating an IAB topology associated with the next IAB node and for indicating an egress backhaul link between the IAB node and the next IAB node using the next-hop address field. The additional field 912 is a ingress topology field for indicating an IAB topology associated with a previous IAB node and for indicating an ingress backhaul link between the IAB node and the previous IAB node with a previous hop address field. Other fields in the BH RLC channel mapping configuration table of b of fig. 5 (next hop BAP address field 511 for the next hop address of the next IAB node next to the IAB node in the routing path, previous hop BAP address field 512 for the previous hop address of the previous IAB node preceding the IAB node in the routing path, ingress BH RLC channel ID field 513 for the backhaul RLC channel identifier of the ingress backhaul RLC channel, and egress BH RLC channel ID field 514 for the backhaul RLC channel identifier of the egress backhaul link) are shown in fig. 9a and designated with the same reference numerals as b of fig. 5.

The field 911 (also referred to as an egress topology) or the next topology field 911 identifies the topology associated with the next hop BAP address 511. The association topology identified in the next hop BAP address field 511 and egress topology field 911 define a unique egress link (or egress BH link). A field 912 (also referred to as a ingress topology) or previous topology field 912 identifies the topology associated with the previous hop BAP address 512. The association topology identified in previous hop BAP address field 512 and ingress topology field 912 defines a unique ingress link (or ingress BH link).

Topology fields 911 and 912 are both n-bit fields. In one example, a topology field (e.g., field 911 and/or field 912) indicates that the topology is the topology to which the IAB node actually belongs (such a topology may be referred to as a primary or first topology) or another topology to which the IAB node is additionally connected (such a topology may be referred to as a secondary or second topology). In another example, the topology field (e.g., field 911 and/or field 912) includes a topology identifier having a value that uniquely identifies a given topology. In the example shown in fig. 6, the primary topology for the border node (IAB node 612) is an IAB topology 691 and the secondary topology is an IAB topology 692. Thus, topology fields 911 and 912 in the BH RLC channel mapping configuration table for IAB node 612 would each have a value indicating either IAB topology 691 or IAB topology 692.

In the example of a routing configuration table for selecting an egress BH link described with respect to fig. 7, when an IAB node, such as IAB node 612, decides to route a packet through an alternative egress BH link requiring overwriting of fields 305 and 306 in the BAP header of the received packet based on information carried by the overwrite field 703 of the entry of the routing configuration table defined in fig. 7 (which corresponds to the routing identifier or destination address of the BAP header of the received packet), the IAB node may examine the entry in the routing ID mapping table 800 to determine whether the routing identifier of the received packet (which corresponds to the routing identifier field 501 associated with the considered overwrite field 703 of the entry of the routing configuration table) matches the routing identifier in the previous routing identifier field 821 of the entry, or whether the destination address of the routing identifier of the received packet matches the destination address in the destination address field 8211 of the entry. Upon determining to match an entry in the route ID mapping table 800, the IAB node then uses the route identifier in the new route identifier field 831 of the matching entry as a new route identifier to update or rewrite the BAP header of the received packet. The IAB node may determine from the routing configuration table 700 as follows: the next IAB node (e.g., the address of the next IAB node or the next-hop BAP address) in the next-hop address field 502 associated with the entry (which has a route identifier in the route identifier field 501 that matches the new route identifier in the new route identifier field 831 of the route ID mapping table 800 defined in fig. 8); or the address of the next IAB node in the next hop address field 502 (e.g., the next hop BAP address) associated with the entry having a destination address in the destination address field 5011 that matches the new destination address in the new destination field 8311 of the routing ID map 800.

When an IAB node receives a packet from a previous IAB node over an ingress BH link for routing to another IAB node over an egress BH link, the IAB node may select a backhaul RLC channel for use by the egress BH link based on an IAB topology associated with the egress BH link and a BH RLC channel map table (such as table 900 of fig. 9 a). For example, the IAB node may select a BH RLC channel for use by the egress BH link by examining the BH RLC channel mapping configuration table 900 to determine whether the BH RLC channel ID of the ingress BH link, the address of the previous IAB node, the IAB topology associated with the previous IAB node (e.g., ingress BH link), the address of the next IAB node, and the IAB topology associated with the next IAB node (e.g., egress BH link) match the various fields of the entry in the BH RLC channel mapping configuration table 900. Upon determining to match an entry, the IAB node may use the egress BH RLC channel ID of the matching entry to select a BH RLC channel for the egress BH link.

For example, if an egress BH link indicated by the determined next-IAB node (e.g., next-hop BAP address) and associated topology is available (e.g., no RLF or congestion is detected), the IAB node may examine the BH RLC channel mapping configuration table 900 and, in view of the address of the previous IAB node for the previous-hop BAP address field 512, the associated ingress topology for the ingress topology field 912 or the previous topology field 912, the address of the next-IAB node for the next-hop BAP address field 511, the associated egress topology for the egress topology field 911 or the next topology field 911, and the BH RLC channel ID for the ingress BH RLC channel ID field 513, the IAB node may then route the data packet over the egress BH RLC channel identified by the egress BH RLC channel ID field 514.

In one embodiment of the present invention, the BAP layer BH RLC channel map information list Information Element (IE) defined in section 9.3.1.98 of 3GPP TS 38.473v16.4.0 is modified as follows to allow the IAB donor CU to configure the IAB node's BH RLC channel map configuration table 900 in accordance with some aspects of the present invention.

IE/group name	Presence of
		BAP layer BH RLC channel mapping information item
Mapping information index	Mandatory by force
		Previous hop BAP Address	Optionally, an optional
Ingress BH RLC CH ID	Optionally, an optional
		Entry topology	Optionally, an optional
Next hop BAP address	Optionally, an optional
		Exit BH RLC CH ID	Optionally, an optional
Exit topology	Optionally, an optional

The mapping information index includes an index of one mapping information entry at the IAB donor DU or the IAB-DU. When included in the F1AP signaling associated with the UE for setting or modifying the BH RLC channel, the BAP layer BH RLC channel mapping information list IE contains a previous hop BAP address IE 512, an ingress topology IE 912 and an ingress BH RLC Channel (CH) ID IE 513 to configure mapping in the downlink (or downstream) direction, or a next hop BAP address IE 511, an egress topology IE 911 and an egress BH RLC Channel (CH) ID IE 514 to configure mapping in the uplink direction.

In one example, BH RLC channel map configuration table 900 is configured by an IAB donor CU managing the primary topology for an IAB node. For example, with respect to fig. 6, the BH RLC channel mapping configuration table 900 of IAB node 612 is configured by IAB donor CU 610. In another example, BH RLC channel map configuration table 900 is configured by an IAB donor CU managing a secondary topology for an IAB node. For example, with respect to fig. 6, the BH RLC channel mapping configuration table 900 of IAB node 612 is configured by IAB donor CU 620. In another example, the entry of table 900 relating to the egress BH RLC channel ID 514 in the primary topology is configured by the IAB donor CU managing the primary topology for the border IAB node, and the entry of table 900 relating to the egress BH RLC channel ID 514 in the secondary topology is configured by the IAB donor CU managing the secondary topology for the border IAB node.

The configuration of the BH RLC channel mapping configuration table 900 in the IAB node is discussed below with reference to fig. 12.

In one example of an embodiment of the invention, a BAP MAPPING CONFIGURATION message (F1 AP protocol) as described in 3GPP TS 38.473v16.4.0 is used to transmit table 900 to the IAB node.

Fig. 9b illustrates an example of an entry of a BH RLC channel mapping configuration table 921 (also referred to as an uplink traffic-to-BH RLC channel mapping configuration table) having at least one entry 920 at an IAB node according to an embodiment of the present invention. The BH RLC channel map configuration table 921 serves as the initiator IAB node (rather than the IAB donor DU). The IAB node generates data packets (e.g., BAP packets or PDUs from a BAP SDU (service data Unit) received from an upper layer) in a portion of the IAB node (e.g., a sublayer of the BAP entity) and provides the generated data packets to another portion of the IAB node (e.g., another sublayer of the BAP entity) for processing prior to routing to another IAB node. The IAB node uses a BH RLC channel map configuration table 921 to identify BH RLC channels for transmission in an upstream direction over an egress link previously selected using a backhaul route configuration table as described in FIG. 5 or a routing configuration table as described for FIG. 7. Entry 920 of BH RLC channel map configuration table 921 corresponds to entry 520 of the BH channel map configuration table for uplink traffic of FIG. 5c, but has an additional field 922. The additional field 922 is an egress topology field for indicating an IAB associated with a next IAB node and for indicating an IAB topology and for indicating a type of an IAB between the IAB node and the next IAB node using a downlink address field for indicating a type of the IAB node and an identifier of the same in a backhaul link as in a backhaul RLC channel map for the downlink of FIG. 5b, and an egress link type of the same type of the packet map as that of the downlink RLC channel in the downlink RLC map table for the downlink map field of fig. 9 b.

A field 922 (also referred to as an egress topology) or a next topology field 922 identifies the topology associated with the next hop BAP address 522. The associated topology identified in the next-hop BAP address field 522 and egress topology field 922 defines a unique egress link (or egress BH link).

Topology field 922 is an n-bit field. In one example, topology field 922 indicates that the topology is the topology to which the IAB node actually belongs (such a topology may be referred to as a primary or first topology) or another topology to which the IAB node is additionally connected (such a topology may be referred to as a secondary or second topology). In another example, topology field 922 includes a topology identifier having a value that uniquely identifies a given topology. In the example shown in fig. 6, the primary topology for the border node (IAB node 612) is an IAB topology 691 and the secondary topology is an IAB topology 692. Thus, topology field 922 in BH RLC channel map configuration table 920 for IAB node 612 will have a value indicating 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 identifier 521, which is indicated by a UL UP TNL information IE for F1-U packets or a non-UP traffic type IE for non-F1-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.473v16.4.0, which is modified according to one embodiment of the invention as follows.

IE/group name	Presence of
		BAP route ID	Optionally, an optional
Egress BH RLC CH list
		Exit BH RLC CH list item
> Next hop BAP Address	Mandatory by force
		Exit topology	Optionally, an optional
Exit BH RLC CH ID	Mandatory by force

In one example, BH RLC channel map configuration table 921 is configured by an IAB donor CU that manages the primary topology for the IAB node. For example, with respect to fig. 6, the BH RLC channel map configuration table 921 of IAB node 612 is configured by IAB donor CU 610. In another example, the BH RLC channel map configuration table 921 is configured by an IAB donor CU that manages the secondary topology for the IAB node. For example, with respect to fig. 6, the BH RLC channel map configuration table 921 of IAB node 612 is configured by IAB donor CU 620. In another example, an entry of table 921 relating to the primary topology as the egress topology 922 is configured by an IAB donor CU managing the primary topology for the border IAB node, and an entry of table 921 relating to the secondary topology as the egress topology 922 is configured by an IAB donor CU managing the secondary topology for the border IAB node.

The configuration of the BH RLC channel mapping configuration table 921 in the IAB node is discussed below with reference to fig. 12.

In one example of an embodiment of the present invention, a BAP MAPPING CONFIGURATION message (F1 AP protocol) as described in 3GPP TS 38.473v16.4.0 is used to transmit table 921 to the IAB node.

In another example, the IAB node is configured with multiple tables 520 (such as the uplink traffic to BH RLC channel mapping configuration table of fig. 5c, etc.), each table associated with one IAB topology. In this example, in the case of one table per topology, the egress topology field 922 may be omitted.

Fig. 10 illustrates an example method for processing data packets (e.g., for managing BAP PDU (or data packet) routing through one or more IAB networks (one or more IAB topologies)) in accordance with embodiments and examples of this invention using a flowchart 1000. For example, the example method shown in fig. 10 may be performed by the CPU 1111 of fig. 11 for a program element executed by a BAP entity (DU or MT part) of the BAP sub-layer. The method of fig. 10 may be applied to route data packets in either the upstream or downstream direction. The method of fig. 10 uses configuration tables 7 and 8 and is similar to the method described above with reference to fig. 13.

Processing begins at step 1001, where an IAB node, such as IAB node 612, receives a BAP packet or BAP PDU that it should route.

At step 1004, the IAB node identifies an IAB topology associated with a BAP packet to be routed (e.g., a received BAP packet).

For example, when an IAB node receives a data packet from a previous IAB node over an ingress BH link, the IAB node determines an IAB topology associated with the received data packet by determining an IAB topology associated with the previous IAB node (which is also associated with the ingress backhaul link). In one example of the invention, the ingress backhaul link (on which the BAP PDU is received) is indicated to the BAP sub-layer by a lower layer (e.g., a MAC sub-layer including a scheduler). When an IAB node first connects to an IAB node DU, the IAB node receives the BAP address of its parent IAB node(s) through an information element CellGroupConfig contained in the RRC message and defined in the 3gpp TS 38.331 specification. Thus, the IAB node may associate the BAP address of the parent IAB node with the link. Further, in the case of connection to the second parent, the IAB node may detect whether the second parent IAB node DU is connected to the same IAB donor CU as the first parent IAB node DU. The IAB node may then associate the BAP address of each parent IAB node with an IAB topology (e.g., primary or secondary). Thus, the BAP sub-layer of an IAB node may establish a relationship between the BAP address, IAB topology, and links of each parent IAB node. When a non-boundary IAB node DU serves a new sub-IAB node, the sub-IAB node belongs to the same IAB topology as the IAB node DU. When a border IAB node serves a new sub-IAB node, the border IAB node may decide on the IAB topology to which the sub-IAB node will belong (by default, the sub-IAB node belongs to the main IAB topology of the border IAB node). Further, the IAB donor CU sends an F1AP message UE CONTEXT SETUP MESSAGE (UE context setup message) including the BAP address of the information element configuration (which is the BAP address configured for the corresponding sub-IAB node) to the IAB node DU. The message and the information element are described in the 3gpp TS 38.473 specification. Thus, the BAP sub-layer of the IAB node may establish a relationship between the BAP address, IAB topology, and links of the sub-IAB node. In an example where the IAB node is an initiator IAB node, the IAB node determines an IAB topology associated with the received data packet based on the IAB node knowing which IAB topology the IAB node belongs to. For example, for the initiator IAB node, the BAP route Identifier (ID) of the generated packet is indicated by a table (not shown) called an uplink traffic-to-route ID mapping configuration as described in section 5.2.1.2.1 of TS 38.340. The indicated BAP route ID will refer to the topology to which the initiator IAB node belongs.

In another example, a flag (or identifier) in the BAP header of one or more of the reserved bits 302, 303, or 304 is used to indicate the topology associated with the received packet, for example. The flag may be set to "0" (or "1") for packets generated and transmitted first in the primary IAB topology of the border IAB node. The flag may be set to "1" (or "0") for packets generated and transmitted first in the secondary IAB topology of the border IAB node. If there are two or more topologies for inter-topology routing/rerouting, additional values (i.e., values other than "0" and "1") will be used so that each topology can be identified from the value of the flag. The non-boundary nodes may ignore the flag. The border node may use the flag to associate the link with the topology. Furthermore, as previously described, the border node associates the link with the BAP address of the parent or child.

The IAB node may parse the header of the BAP packet and retrieve the DESTINATION address information or DESTINATION address in the destinationfield 305 (as described with reference to fig. 3). Although not shown in fig. 10, when a BAP packet is received from another IAB node, the IAB node checks whether the DESTINATION address information or DESTINATION address in the destinationfield 305 matches its own BAP address. If it is determined that the DESTINATION address in the destinationfield 305 actually matches the IAB node's own BAP address, the IAB node removes the BAP header from the BAP PDU and delivers it to the upper layer. When the IAB node is a border node, the border node compares the DESTINATION field 305 with only one of its BAP addresses (the BAP address associated with the same topology as the received BAP packet to be routed).

Then, at step 1005, the IAB node examines the routing configuration table or backhaul routing configuration table 700 associated with the IAB topology identified at step 1004 to find routing options for the received BAP PDU.

The routing options may include: an entry associated with the IAB topology is found in the backhaul ROUTING configuration table 700 that includes a ROUTING identifier in the ROUTING identifier (BAP ROUTING ID) field 501 that matches a ROUTING identifier in the BAP ROUTING ID (BAP ROUTING ID) field 30 (i.e., concatenation of the destinion field 305 and PATH field 306) in the BAP header of the received packet.

The routing options may include: an entry associated with the IAB topology is found in the backhaul routing configuration table 700 that includes a DESTINATION address in the destinatino field 5011 that matches the DESTINATION address in the destinatino field 305 in the BAP header of the received BAP PDU.

If no routing option is found at step 1006, the IAB node may discard the BAP PDU or store the BAP PDU for a new routing attempt (step 1007).

If a routing option is found at step 1006, the IAB node may check at step 1008 the information in the update or rewrite field 703 (or the information in the describe field 5011) associated with the entry of the routing configuration table identified at step 1005, wherein the backhaul routing configuration table does not include the update or rewrite field 703, but instead retains a certain value for at least a portion of the information in the describe field 5011 to indicate whether the routing identifier is to be updated.

If the overwrite field 703 (or information in the destinationfield 5011) indicates that no BAP header overwrite is to be performed to route a BAP PDU, the IAB node identifies an egress Backhaul (BH) link to route the BAP PDU by checking the next hop BAP address field 502 associated with the entry of the backhaul routing configuration table identified at steps 1005 and 1006 at step 1009.

The IAB node then determines at step 1010 whether the egress BH link identified at step 1009 is available. If it is determined that the egress BH link is not available, the IAB node may move back to step 1005 and again examine the backhaul routing configuration table 700 associated with the IAB topology identified at step 1004 to find new routing options for the received BAP PDU.

If it is determined that an egress BH link is available, the IAB node determines a BH RLC channel (over which to route BAP PDUs) based on information from the BH RLC channel mapping configuration table as discussed in fig. 5 b, 5c, 9a, and 9b, and finally routes BAP PDUs over the determined BH RLC channel at step 1011.

If at step 1008 the overwrite field 703 indicates that some BAP header overwrite is to be performed to route a BAP PDU, the IAB node checks an entry in a route ID mapping table (such as the route ID mapping table 800 shown in fig. 8 and described with respect to fig. 8, etc.), for which the previous route identifier field 821 or ROUTING ID field 821 of the PREVIOUSBAP ROUTING field 820 (i.e., the destinion field 8211 and PATH field 8212) matches the route identifier of the received packet (i.e., the ROUTING ID field (i.e., the destinion field 305 and PATH field 306) in the BAP header of the BAP PDU to be routed), and the IAB topology in the previous topology field or topology field 822 matches the ingress IAB topology identified at step 1004.

Then, at step 1012, the IAB node replaces (updates or rewrites) the ROUTING identifier in the received packet with the NEW ROUTING identifier of the matching entry by replacing (updating or overwriting) the DESTINATION address in the DESTINATION field 305 and the PATH identifier in the PATH field 306 in the BAP header of the BAP PDU to be routed with the DESTINATION address in the NEW DESTINATION field or the NEW PATH identifier field in the DESTINATION field 8311 or the PATH identifier in the PATH field 8312, respectively, associated with the PREVIOUSBAP ROUTING field 820 considered for the matching entry as discussed in fig. 8.

Then, at step 1013, the IAB node also examines the NEW topology field 832 associated with the NEW BAP ROUTING field 830 considered at step 1012 and identifies the IAB topology associated with the egress BH link (through which the BAP PDU is to be routed).

The IAB node may then move back to step 1005 and again examine the backhaul routing configuration table 700 associated with the IAB topology identified at step 1013 to find new routing options for the received BAP PDU.

Since during processing, the IAB node may return to step 1006 several times to find a new routing option for the same BH routing configuration table 700, in an example, the IAB node remembers or tracks the checked entries of the BH routing configuration table 700 (to avoid infinite loops).

The order of entries in the BH routing configuration table may reflect priority levels between routing options. For example, a first entry in the BH routing configuration table that matches the BAP routing ID of the received packet may indicate that no rewrite operation is requested. If the egress BH link corresponding to the first entry is not available, the IAB node may find a second entry (i.e., a routing option) for which an overwrite operation is requested. After header overwriting using the route ID mapping configuration table 800, the IAB node will attempt to route packets with the new BAP route ID. If no available egress BH link is found with the new BAP route ID, the IAB node may look in the BH route configuration table for an entry requesting to write the BAP route ID in the header back to the original BAP route ID. A third entry may then be found in BH routing configuration table 700 that matches the initial BAP route ID (or at least the destination BAP address) and results in an attempt at another egress BH link.

In an example, when a packet must cross a border node (as in IAB node 612 in fig. 6), the packet should first be routed towards the border node in a first topology. When the packet is received, the border node should not hold the packet and deliver the packet to the upper layer, since the packet is not actually intended for the border node itself. This means that the destination BAP address of the packet cannot be the BAP address of the border node in the first topology. Therefore, another BAP address should be used as the destination BAP address. For the same reason, the BAP address cannot be the address of any one of the IAB nodes or the IAB donor DUs in the first IAB topology. The other BAP address used to route packets up to the border node may be referred to as an alias BAP address. Thus, the IAB donor CU controlling the first IAB topology configures an alias BAP address of the real destination used in the routing identifier, which is used in the first topology only before the BAP header is overwritten and is not aware of the real destination.

In examples of the invention, the following limitations may be considered to reduce configuration complexity and processing time at the border nodes: the number of parent IAB nodes may be limited to two parents and all child IAB nodes of a border node may be controlled by the same IAB donor CU as the border node in the master topology. This means that the border node has a unique link to transmit data packets towards and receive data packets from the secondary topology. In this case, BH routing configuration tables for the secondary topology are not required for the border nodes:

For routing in the upstream direction, if the border node detects an overwrite with NEW BAP ROUTING ID 831 associated with the secondary topology (as shown in field 832), the border node can directly select the unique egress link associated with the secondary topology.

For routes in the downstream direction, when a packet received on an ingress BH link corresponding to the secondary topology contains a destination BAP address that is not the BAP address of the border node, the border node may directly examine the route ID mapping configuration table 800 to find an entry for header overwriting.

As an illustration of the processing of data packets according to the present invention (e.g., according to the example method described above) and using the example of fig. 6 for PATH 2 and PATH 3 identified above, two routing configuration tables (e.g., based on routing configuration table 700 of fig. 7) may be provided or configured to a border node (IAB node 612) (which belongs to IAB topology 691): one for a first IAB topology 691 (primary) and one for a second IAB topology 692 (secondary).

The routing configuration table for the first IAB topology 691 has at least the following entries:

Destination BAP address	Path ID	Next hop BAP address	Overwriting
				BAP addition donor DU 602	PATH 2	BAP addition donor DU 602	Whether or not
BAP addition donor DU 602	-	-	Is that

The routing configuration table for the second IAB topology 692 has at least the following entries:

Destination BAP address	Path ID	Next hop BAP address	Overwriting
				BAP addition donor DU 603	PATH3	BAP added IAB node 611	Whether or not
BAP addition donor DU 603	-	-	Is that

As described below, a route ID mapping table (e.g., based on the route identifier mapping table 800 of fig. 8) may be provided or configured to a border node (IAB node 612):

When IAB node 612 receives BAP add donor DU 602 with the route identifier: upon packet of PATH2, the IAB node 612 checks the routing configuration table for the first IAB topology 691 for an entry with a matching routing identifier or destination address. The first entry indicates that the next hop address is BAP add donor DU 602 and the overwrite field has a value indicating "no" (which indicates that the routing identifier is not to be updated). A check is then made to see if an egress backhaul link 631 is available for the next IAB node (IAB donor DU 602) to add donor DU 602 to the address BAP. If an egress backhaul link 631 (e.g., PATH 2) for the first matching entry is not available, a 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. The second entry indicates (by overwriting the value in field 703 indicating "yes") that the routing identifier of the received packet is to be updated. IAB node 612 then adds donor DU 602 with BAP: PATH2 examines the route ID mapping table as input to determine that the new route identifier for the matching entry is a BAP add donor DU 603 (associated with the second IAB topology): PATH3. The IAB node 612 updates the header of the received packet to overwrite the routing identifier with the new routing identifier and then adds the donor DU 603 with the new routing identifier: PATH3 as input checks the routing configuration table for the second IAB topology 692 for an entry with a matching routing identifier or destination address. If an egress BH link (link 635) is available to the next-hop IAB node 611, the IAB node 612 routes the update packet to the IAB node 611.

Fig. 11 shows a schematic representation of an example communication apparatus (device) or station according to one or more example embodiments of the disclosure.

The communication device 1100 may preferably be a device such as a microcomputer, a workstation, or a lightweight portable device. The communication device 1100 includes a communication bus 1113, the communication bus 1913 preferably being connected with:

A central processing unit 1111, such as a microprocessor or the like, denoted CPU;

A memory for storing data and a computer program containing instructions for operation of the communication device 1100. A computer program may contain many different program elements (modules) or subroutines, which contain instructions for various operations and for implementing the invention. For example, the program elements include elements to implement a BAP entity for routing data packets to nodes in the IAB topology, as discussed above; and

At least one communication interface 1102 for communicating with other devices or nodes in a wireless communication system, such as wireless communication system 100 according to release 16 of 5G NR, etc. At least one communication interface 1102 may be connected to a communication network 1103 (such as a radio access network of system 100, etc.) through which digital data packets or frames or control frames are transmitted over the communication network 1103. Under the control of a software application running in the CPU 1111, a frame is written from the FIFO transmission memory in the RAM 1112 to the communication interface for transmission, or is read from the communication interface for reception and written to the FIFO reception memory in the RAM 1112.

The donor CU, donor DU, and IAB node may each include such a communication device 1100.

The central processing unit 1111 may be a single processing unit or processor, or may include two or more processing units or processors that perform the processing required for the operation of the communication apparatus 1100. The number of processors and the allocation of processing functions to the central processing unit 1111 are matters of design choice for the skilled person.

The memory may include:

A read-only memory 1107, denoted ROM, for storing a computer program for implementing the invention;

Random access memory 1112, denoted RAM, for storing executable code of the method according to one or more embodiments of the invention, and registers adapted to record variables and parameters required for implementing the method according to one or more embodiments of the invention.

Optionally, the communication device 1100 may further include the following components:

a data storage component 1104 (such as a hard disk or the like) for storing a computer program for implementing a method according to one or more embodiments of the invention;

a disk drive 1105 for a disk 1106, the disk drive being adapted to read data from the disk 1106 or write data onto said disk;

a screen 1109 for displaying the decoded data and/or for use as a graphical interface with the user with a keyboard 1110 or any other pointing device.

Preferably, the communication bus provides communication and interoperability between various elements included in the communication device 1100 or connected to the communication device 1100. 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, either directly or through other elements of the communication device 1100.

The disk 1106 may alternatively be replaced by any information medium, such as a rewritable or non-rewritable compact disk (CD-ROM), ZIP disk, USB key, memory card, or the like, and in general, by an information storage unit readable by a microcomputer or microprocessor, integrated or not integrated into the device, possibly removable, and adapted to store one or more programs (execution of which enables the method according to an embodiment of the present invention).

Executable code may optionally be stored in read only memory 1107, on hard disk 1104, or on removable digital media (e.g., disk 1106, etc. as previously described). According to an alternative variant, the executable code of the program may be received via the interface 1102 through the communication network 1103 for storage in one of the storage means of the communication device 1100 (such as the hard disk 1104, etc.) before being executed.

The central processing unit 1111 is preferably adapted to control and direct the execution of instructions or parts of software code of one or more programs according to the present invention, which instructions are stored in one of the above mentioned storage means. At power-up, one or more programs stored in non-volatile memory (e.g., in hard disk 1104 or read-only memory 1107) are transferred to random access memory 1112, and then random access memory 1112 contains executable code of the one or more programs and registers for storing variables and parameters necessary to implement the present invention.

In a preferred embodiment, the device is a programmable device that implements the invention using software. However, the invention may alternatively be implemented in hardware (e.g., in the form of an application specific integrated circuit or ASIC).

Fig. 16a and 16b illustrate steps of example methods 1600 and 1604 for managing processing of data packets according to embodiments of the invention. Methods 1600 and 1604 are performed at a first donor CU of a first IAB topology in an IAB communication system (or an IAB arrangement) comprising at least two IAB topologies, wherein each IAB topology comprises a plurality of IAB nodes or at least one IAB node. For example, the first donor CU may be the IAB donor CU 610 of the IAB topology 691 of the IAB communication system shown in fig. 6 or the IAB donor CU 620 of the IAB topology 692, or the IAB donor CU 1210 or the IAB donor CU 1220 of the IAB communication system shown in fig. 12. The method as shown in fig. 16a and 16b and described with respect to fig. 16a and 16b may be performed by software elements and/or hardware elements. The first IAB donor CU may be implemented in a communication device 1100 as shown in fig. 11 below, wherein the method as shown in fig. 16a and 16b is performed by a central processing unit 1111.

Fig. 12 illustrates an example message flow 1200 for managing processing of data packets (e.g., configuring and managing BAP PDU routing over multiple IAB networks or IAB topologies) in accordance with embodiments and examples of this invention. Fig. 12 illustrates an example message flow comprising example messages for providing data packet routing configuration information as set forth in the method shown and described with respect to fig. 16a, and further comprising example messages for performing steps as set forth in the method shown and described with respect to fig. 16 b.

An IAB node 1211 (such as IAB node 612, etc.) belonging to a first IAB network (such as IAB network 691, etc.), also referred to as a first topology, managed by a first IAB donor CU 1210 (such as IAB donor CU 610, etc.), is acting as a border node with a second IAB network (such as IAB network 692, etc.), also referred to as a second topology, managed by a second IAB donor CU 1220 (such as IAB donor CU 620, etc.). The second IAB topology includes at least one IAB donor Distributed Unit (DU) (such as the IAB donor DU 603 in the example shown in fig. 6, etc.).

As discussed above, in an example, the first IAB donor CU 1210 may provide packet routing configuration information for routing packets through at least the first IAB topology to at least one IAB node (e.g., IAB nodes 612, 613) of the first IAB topology (step 1602 of fig. 16 a). The packet routing configuration information includes a routing configuration table and a routing identifier mapping table. The routing configuration table includes at least one entry comprising: a route identifier field for a route identifier, the route identifier field comprising a destination address field for an address of the IAB node and a path identifier field for a path identifier of a route 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 the received data packet that matches the routing identifier in the routing identifier field is to be updated. The route identifier mapping information includes a route identifier mapping table having at least one entry including: a previous route identifier field for a route identifier; a previous topology field for indicating an IAB topology associated with a route identifier in the previous route identifier field; a new route identifier field for the route identifier; and a new topology field for indicating an IAB topology associated with the route identifier in the new route identifier field. The field for indicating whether the routing identifier of the received data packet matching the routing identifier in the routing identifier field is to be updated comprises: an update field (e.g., an overwrite field 703), wherein a value in the update field indicates that the route identifier is to be updated; or at least a portion of a next hop address field, wherein a value in the at least a portion of the next hop address field indicates that the routing identifier is to be updated.

The step of providing the packet routing configuration information for routing the packet through the at least first IAB topology to the at least one IAB node (e.g., IAB nodes 612, 613) of the first IAB topology comprises: the routing configuration table is provided in a routing configuration Information Element (IE) for a configuration message transmitted to the at least one IAB node, and the routing identifier mapping table is provided in a routing identifier mapping Information Element (IE) for a configuration message transmitted to the at least one IAB node. As discussed above with respect to fig. 7, in an example implementation, the BH routing information addition list Information Element (IE) defined in section 9.2.9.1 of 3GPP TS 38.473v16.4.0 is modified to allow the IAB donor CU to configure the overwrite 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 a different message. As described in 3GPP TS 38.473v16.4.0, the configuration message may be a BAP MAPPING CONFIGURATION message (F1 AP protocol).

The packet routing configuration information may also include information for configuring a backhaul RLC channel mapping configuration table (e.g., a bhrlc channel mapping configuration table as described above with reference to fig. 9 a). As discussed above with respect to fig. 9a, in an example implementation, the BAP layer BH RLC channel map information list Information Element (IE) defined in section 9.3.1.98 of 3GPP TS 38.473v16.4.0 may be modified to allow the IAB donor CU to configure the BH RLC channel map configuration table 900 of the IAB node in accordance with some aspects of the invention. The data packet routing configuration information may additionally or alternatively include information for configuring an uplink traffic to backhaul RLC channel mapping configuration table as discussed above with reference to fig. 9 b. As discussed above with respect to fig. 9b, in an example implementation, each entry of the uplink traffic-to-BH RLC channel mapping configuration table 921 contains a traffic type identifier 521, the traffic type identifier 521 being indicated by either a UL UP TNL information IE for F1-U packets or a non-UP traffic type IE for non-F1-U packets as defined in TS 38.473. The other fields 522, 922, and 523 of table 921 may be indicated by a BH information IE defined in section 9.3.1.114 of 3GPP TS 38.473v16.4.0 that is modified to allow the IAB donor CU to configure the IAB node's BH RLC channel map configuration table 921 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 (e.g., including the same message as the IEs for the routing configuration table and the routing identifier mapping table) or in different messages.

As described in 3GPP TS 38.473v16.4.0, the configuration message (which may be included in the configuration requests 1241, 1251 shown in fig. 12) may be a BAP MAPPING CONFIGURATION message (F1 AP protocol).

The packet routing configuration information (in addition to at least one IAB node that may be provided to a first one of the at least two IAB topologies) may be provided to at least one IAB node of a second one of the at least two IAB topologies. Responsive to detecting and connecting with a second IAB node (such as IAB node 611, etc.) belonging to a second IAB network (such as IAB network 691, etc.) managed by a second IAB donor CU 1220 (such as IAB donor CU 620, etc.), an IAB node 1211 (such as IAB node 612, etc.) acts as a border node, as discussed above with reference to fig. 6. When the MT part of the IAB node 1211 is initially connected to the network, as defined in 3gpp TS 38.300, the MT part will perform a cell search procedure in order to try to detect PSS (primary synchronization signal) and SSS (secondary synchronization signal). The MT unit of the IAB node 1211 will determine whether it can connect to a new cell (i.e., a new IAB node, such as IAB node 611, etc.) based on the system information it will get. If the MT part successfully establishes a connection with the IAB node 611, the IAB node 1211 may inform its IAB donor CU 1210 (e.g., by sending DUAL CU CONNECTION NOTIFICATION (dual CU connection notification) message) that it has established a dual connection with an IAB node belonging to a neighbor IAB network. In other words, the IAB node 1211 may transmit a notification to the donor central unit CU 1210 of the first IAB network indicating that the IAB node 1211 is capable of routing the data packet to one or more IAB nodes in the second IAB network.

When the IAB donor CU 1210 wishes to establish an inter-topology route (i.e., route or offload a data packet from a first IAB network to a second IAB network or from a second IAB network to a first IAB network), the IAB donor CU 1210 sends a request or notification (such as OFFLOAD NEGOCIATION REQUEST (offload negotiation request) message 1231, etc.) to the IAB donor CU 1220 for establishing a route for a data packet between the first IAB network or topology and the second IAB network or topology (step 1606 of fig. 16 b).

At step 1608 of fig. 16b, the IAB donor CU 1210 receives a response from the IAB donor CU 1220, such as OFFLOAD NEGOCIATION RESPONSE (offload negotiation response) message 1232, or the like. The response includes an acknowledgement message indicating whether the IAB donor CU 1220 accepted the request, and when the IAB donor CU 1220 accepted the request, the response includes configuration information regarding one or more of the IAB nodes in the second IAB topology for identifying a routing path for routing the data packet between the at least one IAB node of the first IAB topology and the at least one IAB node of the second IAB topology. More details of configuration information and OFFLOAD NEGOCIATION RESPONSE messages 1232 are set forth below. In one example of an embodiment of the invention, message 1231 may be a new Xn application protocol (XnAP) message. The XnAP protocol is defined in the 3gpp TS 38.423 specification.

The IAB donor CU 1220 may then send a response to the IAB donor CU 1210, e.g., using OFFLOAD NEGOCIATION RESPONSE message 1232. The response may indicate whether the IAB donor CU 1220 may accommodate the request and accept the offload request. When the IAB donor CU 1220 accepts the offload request, the response may include configuration information regarding one or more of the IAB nodes in the second IAB topology for identifying a routing path for routing the data packet between the at least one IAB node of the first IAB topology and the at least one IAB node of the second IAB topology. The IAB donor CU 1210 may provide packet routing configuration information to 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 IAB donor CU 1220. More details of configuration information and OFFLOAD NEGOCIATION RESPONSE messages 1232 are set forth below.

The offload notification or message 1231 may include all or a portion of the following IEs:

-an Information Element (IE) related to the requested direction: upstream or downstream of the flow of the fluid,

An IE identifying an IAB donor DU (such as IAB donor DU 603 in fig. 6, etc.) in a secondary topology (e.g., IP address, BAP address) that the IAB donor CU 1210 intends to use to send or receive data packets over a wired backhaul,

An IE identifying the boundary node 1211 involved in the routing through the different topology, such as the IP address or BAP address of the boundary node in the secondary topology,

An IE indicating the destination of the offloaded packet in the downstream direction (the border node 1211 itself or another IAB node belonging to the first IAB topology or the first IAB topology (i.e. a child IAB node of the border node)). The indication may be limited to 1 bit, where, for example, a value of "1" means that the destination is a border node and a value of "0" means that the destination is another IAB node. In other words, the IE may include 1 bit, wherein the value of the 1 bit is used to indicate whether the destination of an offloaded data packet in the downstream direction is a border node of the first IAB topology or another IAB node. With such an indication, IAB donor CU 1220 may adapt the configuration of the IAB donor DU generating the BAP header of the offloaded packet. In the case where the destination is border node 1211, the IAB donor DU may be indicated by the IAB donor CU 1220 to set the BAP address of the border node in the second IAB topology to the destination BAP address field of the header. In the case where the destination is not a border node, the IAB donor DU may be instructed to set the alias BAP address of the real destination in the first IAB topology (i.e., the alias BAP address of another IAB node of the first IAB topology as the real destination) to the destination BAP address field of the header. This alias BAP address is used in the second IAB topology just prior to the BAP header overwriting at the border node 1211, to avoid route ID or BAP address collision,

-IEs related to expected throughput and/or expected quality of service (QoS) for the data flows to be routed. For example, the IE may include an index indicating the level of QoS. In order to properly manage the mapping of bearers to BH RLC channels corresponding to the desired QoS level, IAB donor CU 1210 may also indicate on the ingress link or on the egress link in case of upstream transmission, the BH RLC channel ID it intends to use for the border node in the primary topology. Based on this latter information, IAB donor CU 1220 may determine whether the BH RLC channel ID to be used by IAB donor CU 1210 is a new BH RLC channel ID or a BH RLC channel ID that has been used for the set offload transmission. In the case of a new BH RLC channel ID for downstream transmission (i.e., a 1:1 mapping of one bearer per RLC channel), the IAB donor CU 1220 may understand that it cannot reuse the same BH RLC channel ID used by the previous downstream offload (e.g., an N:1 mapping, where several bearers with similar QoS requirements are multiplexed on the same RLC channel) because this would result in two identical entries in the BH RLC channel map configuration table 900 with two different egress BH RLC channel IDs 514 as outputs. Similarly, for upstream transmissions, if the IAB donor CU 1210 indicates a BH RLC channel ID that has been used, the IAB donor CU 1220 may understand that it should also reuse the BH RLC channel ID that has been used for the previous upstream offload.

In the case where the IAB donor CU 1220 is responsible for configuring all or part of the routing ID configuration mapping table 800 shown in fig. 8 and described for fig. 8, in the border node 1211, the IAB donor CU 1210 may also include in the further 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).

In the case where the IAB donor CU 1220 is responsible for configuring all or part of the BH RLC channel mapping configuration table 900 shown in fig. 9a and described with respect to fig. 9a, in the border node 1211, the IAB donor CU 1210 may also include in another IE in the message 1231 information related to the contents of the fields for the primary topology (i.e., fields 511 and 514 for the entry to be added in the case of downstream transmission, or fields 512 and 513 for the entry to be added in the case of upstream transmission).

The IAB donor CU 1210 may concatenate several offload requests for different BAP route IDs in the master topology. In this case, message 1231 contains a list of items, each including some or all of the foregoing information elements.

Upon receiving OFFLOAD NEGOCIATION REQUEST message 1231, IAB donor CU 1220 may determine whether it can fulfill the request for offloading based on the conditions of its IAB network (e.g., load or RLF of links on the path towards the border node through the secondary topology). In other words, IAB donor CU 1220 may determine whether it may accommodate routing or offloading of data packets from the first IAB network to the second IAB network or from the second IAB network to the first IAB network.

In the case where the IAB donor CU 1220 may accommodate the requested traffic offload, the IAB donor CU 1220 may determine one or more alias BAP addresses to be used to route downstream data packets via the second topology up to the border node 1211. One or more alias BAP addresses are used in the second topology just prior to BAP header overwriting at the border node 1211 to avoid route ID or BAP address collision.

The IAB donor CU 1220 may then send a response to the IAB donor CU 1210 using OFFLOAD NEGOCIATION RESPONSE message 1232. In one example of an embodiment of the invention, message 1232 may be a new Xn application protocol (XnAP) message.

Offload notifications or messages 1232 (e.g., configuration information included in a response from IAB donor CU 1220) may include:

An Information Element (IE) indicating an acknowledgement or negative acknowledgement of the offload request,

An IE identifying an IAB donor CU 1210 that can use an IAB donor DU (such as IAB donor DU 603 in fig. 6, etc.) in a secondary topology (e.g., IP address, BAP address) to send or receive data packets over a wired backhaul,

An IE identifying the border node 1211 involved in the routing through the different topology, e.g. the IP address or BAP address of the border node in the secondary topology,

An IE indicating an alias BAP address for or to be used by the IAB donor CU 1220 (i.e., the IAB donor CU 1220 is intended to use) to route the data packet in the downstream direction up to the border node 1211,

An IE indicating the BH RLC channel ID on the ingress link in the case of downstream transmission or on the egress link in the secondary topology to be used by or to be used by the IAB donor CU 1220 (i.e., the IAB donor CU 1220 is intended for) the border node 1211. Based on the latter information, IAB donor CU 1210 can understand whether the BH RLC channel ID to be used by IAB donor CU 1220 is a new BH RLC channel ID (1:1 bearer map) or a BH RLC channel ID (n:1 bearer map) that has been used for the set offload transmission.

In the case where the IAB donor CU 1210 is responsible for configuring all or part of the routing configuration table 700 shown in fig. 7 for the secondary topology in the border node 1211 and described for fig. 7, the IAB donor CU 1220 may also include information related to the content of the fields for the secondary topology (i.e. fields 5011, 5012, 502, 703 for the one or more entries to be added) in another IE in message 1232.

In the case where the IAB donor CU 1210 is responsible for configuring all or part of the routing ID configuration mapping table 800 shown in fig. 8 and described for fig. 8 in the border node 1211, the IAB donor CU 1220 may also include in the further IE in the message 1232 information about the content of the fields related to the master topology, i.e. the fields 8211 and 8212 for the entry to be added in case of a downstream transmission or the fields 8311 and 8312 for the entry to be added in case of an upstream transmission.

In the case where the IAB donor CU 1210 is responsible for configuring all or part of the BH RLC channel mapping configuration table 900 shown in fig. 9a and described for fig. 9a in the border node 1211, the IAB donor CU 1220 may also include in the other IE in the message 1232 information related to the content of the fields for the primary topology (i.e. fields 511 and 514 for the entry added in case of upstream transmission, or fields 512 and 513 for the entry added in case of downstream transmission).

The IAB donor CU 1220 may concatenate several offload responses. In this case, message 1232 contains a list of items, each including some or all of the foregoing information elements.

In the event that the IAB donor CU 1220 replies or responds with OFFLOAD NEGOCIATION RESPONSE a message 1232 without acknowledging the request for offloading, the IAB donor CU 1220 may use the IE in the message 1232 to propose a new proposal (e.g., by indicating another IAB donor DU to be used to send or receive packets, another bearer mapping on the BH RLC channel, another border IAB node, etc.). Upon receiving such a response with the new proposal, the IAB donor CU 1210 may formulate a new OFFLOAD NEGOCIATION REQUEST 1231 by adapting the content of the IE accordingly based on the new proposal.

The IAB donor CU 1210 may also determine one or more upstream alias BAP addresses for further use by the IAB nodes belonging to the first topology in routing upstream data packets via the first topology managed by the IAB donor CU 1210 to the border node 1211. One or more alias BAP addresses are used in the first topology just prior to BAP header overwriting at the border node 1211 to avoid route ID or BAP address collision.

In the event that IAB donor CU 1220 acknowledges the request for offloading using OFFLOAD NEGOCIATION RESPONSE message 1232, IAB donor CU 1210 can then configure the IAB node it controls. In particular, IAB donor CU 1210 may send message CONFIGURATION REQUEST (configuration request) 1241 to border node 1211.

The IAB donor CU 1220 may then also configure the IAB node it controls. In particular, IAB donor CU 1220 may send message CONFIGURATION REQUEST 1251 to border node 1211.

In one example of an embodiment of the present invention, CONFIGURATION REQUEST messages 1241 and 1251 may be BAP MAPPING CONFIGURATION messages (F1 AP protocol) as described in 3GPP TS 38.473v16.4.0.

Fig. 19 illustrates steps of an example method 1900 for processing data packets according to a third embodiment of the invention. Method 1900 is performed at an IAB node in an IAB communication system (or an IAB arrangement) comprising at least two IAB topologies, wherein each IAB topology comprises a plurality of IAB nodes or at least one IAB node. For example, referring to the IAB communication system shown in fig. 6 and described with respect to fig. 6, the IAB node performing method 1900 may be an IAB node of a first IAB topology (or first IAB network) 691 or a second IAB topology (or second IAB network) 692. In other words, the IAB node belongs to the first IAB topology 691 or the second IAB topology 692, or is part of the first IAB topology 691 or the second IAB topology 692. Further, the IAB node may be an IAB donor DU (such as 601, 602, 603, etc.) for a data packet to be routed in a downstream direction, or an initiator IAB node for a data packet to be routed in an upstream direction (e.g., the initiator IAB node may be an IAB node transmitting data from a UE (i.e., serving as an access IAB node), or an IAB node transmitting control data from itself). The method as shown in fig. 19 and described with respect to fig. 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 fig. 11 and described with reference to fig. 11, wherein the method as shown in fig. 19 and described with respect to fig. 19 is performed by one or more processing units, such as a central processing unit 1111 or the like. For example, the program elements executed by the CPU 1111 of fig. 11 for the BAP entity (DU or MT part) of the BAP sub-layer may perform the method shown in fig. 19. The method of fig. 19 may be applied to route data packets in either the upstream or downstream direction.

Briefly, in step 1902, an IAB node receives a data packet (e.g., a BAP packet or a BAP PDU). The data packet includes a route identifier for routing the received data packet to the destination IAB node. The route identifier may include a destination address of the destination IAB node for the packet and a path identifier identifying a route path for the packet to the destination IAB node. In an example, the data packet includes a header that includes a destination address and a path identifier that together indicate a routing identifier (e.g., fields 305 and 306 of the BAP PDU of fig. 3). The IAB node may receive a packet from a previous 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, etc.), or the IAB node may generate a packet in a portion of the IAB node (such as in a portion or sub-layer of a BAP entity of the IAB node, etc.) and receive the generated packet at another portion of the IAB node (such as to another portion or sub-layer of the BAP entity of the IAB node, etc.) for routing to another IAB node. In the latter case, the IAB node is acting as an initiator IAB node.

At step 1904, the IAB node determines an IAB topology associated with the data packet. For example, when an IAB node receives a packet from a previous IAB node over an ingress BH link, the IAB node determines an IAB topology associated with the received packet by determining an IAB topology associated with the previous IAB node (which is also associated with the ingress backhaul link). As discussed above with reference to fig. 10, the BAP sub-layer of an IAB node may establish a relationship between the BAP address, topology, and backhaul links of the parent or child IAB node, which may then be used to determine the IAB topology associated with the received data packet. In examples where the IAB node is an initiator IAB node (e.g., receives data generated by the IAB node itself), the IAB node determines an IAB topology associated with the received data packet based on the IAB node knowing to which IAB topology the AB node belongs. For example, for the initiator IAB node, the BAP route Identifier (ID) of the generated packet is indicated by a table (not shown) called an uplink traffic-to-route ID mapping configuration as described in section 5.2.1.2.1 of TS 38.340. The indicated BAP route ID will refer to the topology to which the initiator IAB node belongs.

At step 1906, the IAB node determines whether the received data packet is to be delivered to an upper layer of the IAB node. For example, determining whether a received data packet is to be delivered to an upper layer of an IAB node includes: the destination address of the received packet's routing identifier is compared to the address of the IAB node previously associated with the respective determined IAB topology. In other words, when the IAB is a non-border node with a single BAP address associated with the IAB topology to which it belongs, this means that the IAB node checks whether the DESTINATION address information of the route identifier or the DESTINATION address in the destinationfield 305 matches the IAB node's own single BAP address. When the IAB node is a border node, the border node compares the DESTINATION field 305 of the route identifier with only one of its BAP addresses (BAP addresses associated with the same topology as the BAP packet to be routed).

If the packet is not delivered to the upper layer (i.e., in response to determining that the received packet is not to be delivered to the upper layer), the IAB node determines whether there is an available egress backhaul link for routing data (e.g., the received packet) based on the routing configuration information associated with the determined IAB topology and the routing identifier of the received packet at step 1908. In other words, the IAB node checks 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 checks whether an egress backhaul link of the routing option is available.

In an example, the routing configuration information is a routing configuration table (or backhaul routing configuration table or BAP routing configuration table), such as routing configuration table 500 shown in fig. 5a and described with respect to fig. 5a, or alternatively routing configuration table 700 shown in fig. 7 and described with respect to fig. 7 (or alternatively routing configuration table 1500 shown in fig. 15), or the like. The IAB node may determine whether an egress backhaul link exists by examining an entry in the backhaul ROUTING configuration table 500 (alternatively, 700 or 1500) associated with the determined IAB topology, the entry including a route identifier in the route identifier (BAP ROUTING ID) field 501 that matches a route identifier in the BAP route ID field 30 (i.e., concatenation of the destinion field 305 and PATH field 306) in the BAP header of the BAP packet. The operation may include checking an entry in the backhaul routing configuration table 500 described above for a of fig. 5 (alternatively, the backhaul routing configuration table 700 described above for fig. 7 (or table 1500 of fig. 15)) associated with the determined IAB topology that includes a DESTINATION address in the destinion field 5011 that matches a DESTINATION address in the destinion field 305 in the BAP header of the BAP packet. When an entry is found, the IAB node identifies an egress Backhaul (BH) link to route the BAP PDU, for example, by checking a next-hop BAP address field 502 associated with the found entry of the backhaul routing configuration table. The IAB node then determines whether the identified egress BH link is available.

If it is determined that no egress BH link is available (e.g., no egress BH link is identified, or an egress BH link is identified but not available (e.g., due to RLF/congestion)), the IAB node determines at step 1910 if the routing identifier of the received packet can be updated. For example, the IAB node may check the information in the update or rewrite field 703 of the backhaul ROUTING configuration table 700 (or a value in at least a portion of the next-hop address field 502 when a particular value in at least a portion of the next-hop address field is used to indicate whether header rewriting is to be performed as discussed above) for an entry matching the ROUTING identifier in the BAP ROUTING ID field 30 (i.e., concatenation of the destinationfield 305 and PATH field 306) in the BAP header of the received packet. Alternatively, the IAB node checks if an entry in the BAP route ID mapping table (or header overwrite configuration) 800 matches the route identifier in the BAP ROUTING ID field 30 in the BAP header of the packet.

When the IAB node determines to update the route identifier, at step 1912, the IAB node determines a new route identifier and an IAB topology associated with the new route identifier (e.g., an IAB topology (egress backhaul link) associated with a next IAB node determined by the new route identifier) based on, for example, the route identifier mapping information and the route identifier of the received data packet. In an example, the route identifier mapping information is a route identifier mapping table (or BAP route identifier mapping table) comprising at least one entry, wherein each entry comprises a field for indicating an IAB topology associated with the route identifier to be updated and/or a field for indicating an IAB topology associated with the new route identifier.

For example, the route identifier mapping table may include a previous route identifier field for the route identifier, a previous topology field for indicating an IAB topology associated with the route identifier in the previous route identifier field, a new or next route identifier field for the route identifier, and a new topology field for indicating an IAB topology associated with the route identifier in the new route identifier field, wherein an alternative routing option (e.g., at least one redundant PATH) is available. In an example, the route identifier mapping table is the route identifier mapping table shown in fig. 8 and described with respect to fig. 8. The IAB node may identify the new route identifier and the IAB topology associated with the new route identifier (e.g., an egress backhaul link over which the data packet is to be routed) by examining the route identifier mapping table to determine whether the route identifier of the data packet matches a route identifier in a previous route identifier field of the entry or whether the destination address of the received route identifier of the data packet matches a destination address in a destination address field of the entry. When the IAB node determines to match an entry, the IAB node uses the route identifier in the new route identifier field of the matching entry as the identified new route identifier and uses the IAB topology indicated by the new topology field of the matching entry as the identified or determined IAB topology associated with the new route identifier. The information in the topology field about the IAB topology provides an indication as to whether the packet is to be routed to the same or another IAB topology. For example, if the overwrite field 703 (or a value in at least a portion of the next hop address field 502) indicates that some BAP header overwrite may be performed for routing BAP PDUs, or if an entry is found in the BAP route ID mapping table 800, the IAB node identifies a new route identifier and an IAB topology associated with the new route identifier based on the route identifier mapping information and the route identifier of the received packet. The IAB node may determine the new route identifier and the IAB topology associated with the new route identifier by examining an entry in a route ID mapping table, such as the route ID mapping table 800 shown in fig. 8 and described with respect to fig. 8, wherein for the route ID mapping table, the previous route identifier field 821 or ROUTING ID field 821 of PREVIOUSBAP ROUTING field 820 (i.e., the destinion field 8211 and PATH field 8212) matches the route identifier of the received packet (i.e., the ROUTING ID field in the BAP header of the BAP PDU to be routed (i.e., the destinion field 305 and PATH field 306)) and the IAB topology in the previous topology field or topology field 822 matches the previously identified IAB topology.

Continuing at step 1912, 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 comprising the identified new routing identifier. For example, the routing identifier of the received data may be replaced or overwritten with a new routing identifier. The IAB node then moves back to step 1906 and repeats at least step 1906 to first check if the update packet is to be delivered to the upper layer. The IAB node may repeat steps 1906 to 1912 for the update packet for at least one period until it is determined that the update packet is to be delivered to an upper layer, or that there is an available egress backhaul link for routing data, or that the route identifier is not to be updated.

For example, in response to determining that the update packet is not to be delivered to an upper layer, the IAB node determines whether an egress backhaul link exists for routing the data to a next IAB node based on the routing configuration information associated with the determined IAB topology associated with the new routing identifier of the update packet and the new routing identifier (according to step 1908). The IAB node may determine the next IAB node (and the egress backhaul link associated with the next IAB node) by examining the route configuration table associated with the identified IAB topology (which is associated with the egress backhaul link) to determine whether the identified new route identifier matches the route identifier in the route identifier field of the entry or whether the destination address of the new route identifier matches the destination address in the destination address field of the entry. When the IAB node determines to match an entry, the IAB node uses the next hop address in the next hop address field of the matching entry to determine a next IAB node and routes the update data packet to the next IAB node over the associated egress backhaul link.

Responsive to determining that there is no available egress backhaul link for routing the update packet (e.g., no egress backhaul link is identified, or an egress backhaul link is identified but is not available due to RLF/congestion), the IAB node may then determine whether a new routing identifier for the update packet may be updated (according to step 1910). When the new route identifier can be updated, the IAB node determines another new route identifier and an IAB topology associated with the other new route identifier and then updates the update packet by updating the new route identifier with the determined other new route identifier to provide a new update packet (according to step 1912). The flow then returns again to step 1906.

In response to determining that there is an available egress backhaul link, method 1900 may further include: the data packet is routed to the next IAB node through the available egress backhaul link.

Method 1900 may further include: if an egress backhaul link is identified or is available for routing the data packet, a backhaul RLC channel is selected. 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. In an example, 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 b of fig. 5 or c of fig. 5 or fig. 9a or fig. 9b, or the like. In another example, the BH RLC channel mapping information may provide information such as that shown in b of fig. 5 or c of fig. 5, where fields 511 and 522 indicate identifiers of egress links, and where field 512 indicates an identifier of ingress links. In this case, the ingress link identifier and the egress link identifier indicate both the link and the topology (primary/MCG or secondary/SCG).

By determining whether an update packet is to be delivered to an upper layer (i.e., repeating step 1906 after updating or overwriting the received packet with the determined new routing identifier to provide an update packet), a check can be made to determine whether the update packet has reached its destination and should be delivered to the upper layer. If no check is made after the received packets are updated or rewritten, they may be discarded even when they reach 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 border node 612 in the second topology 692. Without checking whether the update packet should be delivered to an upper layer (in step 1906) after the received packet is updated to the address of the border node 612 in the second topology, the update packet will likely be discarded at the border node. Repeating the determination made at step 1906 means: additional checks after updating or overwriting the data packets can be easily integrated into the existing stream without requiring significant changes. Further, as the determination step 1906 is repeated, it is not necessary in the border node to first identify whether the 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.

Fig. 18 illustrates another example method for processing data packets (e.g., for managing BAP PDU (or data packet) routing through one or more IAB networks (one or more IAB topologies)) in accordance with embodiments and examples of this invention using flowchart 1800. For example, the example method shown in fig. 18 may be performed by the CPU 1111 of fig. 11 for a program element executed by a BAP entity (DU or MT part) of the BAP sub-layer. The method of fig. 18 may be applied to route data packets in either the upstream or downstream direction. The method of fig. 18 may use the configuration table of fig. 5a (or alternatively map 7 or fig. 15) and fig. 8.

The process begins at step 1801, where an IAB node, such as IAB node 612, receives a BAP packet or BAP PDU that it should route at step 1801.

At step 1802, the IAB node identifies an IAB topology associated with a BAP packet to be routed (e.g., a received BAP packet). For example, the IAB node may determine an IAB topology associated with the received data packet from one or more of the examples as described above for step 1004 of fig. 10.

In step 1803, the IAB node checks whether the DESTINATION address information of the header of the received BAP packet or the DESTINATION address in the destinationfield 305 (e.g., as described above with reference to fig. 3) matches its own BAP address. If it is determined that the DESTINATION address in the destinationfield 305 actually matches the IAB node's own BAP address, the IAB node removes the BAP header from the BAP PDU and delivers the BAP header to the upper layer (step 1808). When the IAB node is a border node, the border node compares the DESTINATION address in the DESTINATION field 305 with only one of its BAP addresses (the BAP address associated with the same topology as the BAP packet to be routed).

If the packet is not delivered to an upper layer (i.e., the destination address in the header of the received BAP packet does not match the address of the IAB node), then at step 1811 the IAB node checks, based on the routing identifier of the data packet, routing configuration information associated with the IAB topology identified at step 1802, such as a routing configuration table or backhaul routing configuration table 500 (or alternatively 700), etc., to find a routing option for the BAP packet to be routed. In other words, the IAB node determines whether there is an egress backhaul link for routing data (e.g., received data packets).

The routing options may include: an entry is found in the backhaul route configuration table 500 (or alternatively 700) associated with the identified IAB topology that includes a route identifier (BAP route ID) in the route identifier (BAP route ID) field 501 that matches a route identifier in the BAP route ID field 30 (i.e., concatenation of the destinion field 305 and PATH field 306) in the BAP header of the BAP packet.

The routing options may include: an entry is found in the backhaul routing configuration table 500 described above for a of fig. 5 (alternatively, the backhaul routing configuration table 700 described above for fig. 7) associated with the identified IAB topology that includes a DESTINATION address in the DESTINATION field 5011 that matches the DESTINATION address in the DESTINATION field 305 in the BAP header of the BAP packet.

If a routing option is found at step 1812, the IAB node identifies an egress Backhaul (BH) link to route the BAP PDU at step 1813, for example, by examining the next hop BAP address field 502 associated with the entry of the backhaul routing configuration table identified at steps 1811 and 1812.

The IAB node then determines at step 1814 whether the egress BH link identified at step 1813 is available. If it is determined that the egress BH link is not available, the IAB node may move back to step 1811 and check the backhaul routing table again for new routing options.

If it is determined that an egress BH link is available, the IAB node determines a BH RLC channel (over which to route BAP PDUs) based on information from the BH RLC channel mapping configuration table as discussed with reference to b of fig. 5, c of fig. 5, 9a and 9b, and finally routes BAP PDUs over the determined BH RLC channel at step 1815. As discussed above, the BH RLC channel mapping information may provide information such as that shown in b of fig. 5 or c of fig. 5, where fields 511 and 522 indicate identifiers of egress links, and where field 512 indicates an identifier of ingress links. In this case, the ingress link identifier and the egress link identifier indicate both the link and the topology (primary/MCG or secondary/SCG).

If no routing option or available routing option is found at step 1812 (e.g., no routing option is found or a routing option is found but the egress backhaul link of the routing option is not available), the IAB node may check whether rerouting through header overwriting is possible. For example, at step 1816, the IAB node may check the information in the update or rewrite field 703 of the backhaul ROUTING configuration table 700 (or the value in at least a portion of the next-hop address field 502 when the particular value in at least a portion of the next-hop address field is used to indicate whether header rewriting is to be performed as discussed above) for an entry matching the ROUTING identifier in the BAP ROUTING ID field 30 (i.e., concatenation of the destinationfield 305 and PATH field 306) in the BAP header of the BAP packet. Alternatively, the IAB node checks if an entry in the BAP route ID mapping table (or header overwrite configuration) 800 matches the route identifier in the BAP ROUTING ID field 30 in the BAP header of the BAP packet.

If the overwrite field 703 (or a value in at least a portion of the next hop address field 502) indicates that BAP header overwrite cannot be performed for routing BAP PDUs, or if no entry is found in the BAP route ID mapping table 800, the IAB node may discard the BAP PDUs or store the BAP PDUs for new routing attempts (step 1819).

If the overwrite field 703 (or a value in at least a portion of the next hop address field 502) indicates that some BAP header overwrite may be performed for ROUTING BAP PDUs, or if an entry is found in the BAP route ID mapping table 800, the IAB node identifies the new route identifier and associated IAB topology based on the route identifier mapping information and the route identifier of the BAP packet, e.g., by checking an entry in a route ID mapping table (such as that shown in fig. 8 and described with respect to fig. 8, ROUTING ID mapping table 800, etc.), for which the previous route identifier field 821 or ROUTING ID field 821 (i.e., destinion field 8211 and PATH field 8212) of PREVIOUSBAP ROUTING field 820 matches the route identifier of the received data packet (i.e., ROUTING ID fields (i.e., destinion field 305 and PATH field 306) in the BAP header of the BAP PDU to be routed), and the topology in the previous topology field or topology 822 matches the entry of step IAB.

At step 1817, after determining that BAP header overwriting is to be performed, the IAB node replaces (updates or overwrites) the ROUTING identifier in the BAP packet with the NEW ROUTING identifier, for example by replacing (updating or overwriting) the DESTINATION address in the destinatino field 305 and the ROUTING identifier in the PATH field 306 in the BAP header of the BAP PDU to be routed with the DESTINATION address in the NEW ROUTING field or the DESTINATION address field 8311 and the PATH identifier in the NEW PATH identifier field 8312, respectively, associated with the PREVIOUSBAP ROUTING field 820 considered for the matching entry as discussed in fig. 8.

At step 1818, the IAB node determines the IAB topology associated with the NEW ROUTING identifier, for example, by examining the NEW topology field 832 associated with 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 packet updated with the NEW ROUTING identifier) is to be routed.

The IAB node then moves back to step 1803 and checks whether the DESTINATION address information of the update header of the update BAP packet or the DESTINATION address in the destinationfield 305 matches its own BAP address. As discussed above, if it is determined that the DESTINATION address in the destinationfield 305 of the update BAP packet actually matches the IAB node's own BAP address, the IAB node removes the BAP header from the BAP PDU and delivers it to the upper layer (step 1808). When the IAB node is a border node, the border node compares the DESTINATION address in the destinatiion field 305 with only one of its BAP addresses (the BAP address associated with the determined IAB topology associated with the new route identifier of the update BAP packet to be routed).

The IAB node then attempts 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 the routing configuration information associated with the determined IAB topology associated with the new routing identifier and the identified new routing identifier (e.g., by checking the backhaul routing configuration table 500 (alternatively 700) associated with the new IAB topology identified at step 1818 at step 1811), thereby looking up the new routing option for the received BAP PDU and following steps 1812 to 1819 as before).

With respect to fig. 18 and 19, it may be noted that BAP packets that have to be transferred from one topology to another are directed to a border node that has a different destination BAP address than the BAP address of the border node in the ingress topology (i.e., it is an alias of the real destination in the other topology). Furthermore, BAP operations may be summarized in a unified manner for non-boundary nodes and boundary nodes with the following steps.

An IAB node that receives a BAP packet to be routed first determines an IAB topology associated with the packet. The IAB topology is a ingress topology for BAP packets, which is also associated with the ingress backhaul link.

The IAB node then determines whether the packet must be delivered to an upper layer by comparing the destination BAP address with the BAP address of the IAB node. When the IAB node is a border node, the border node compares the destination BAP address with its BAP address associated with the ingress topology.

When a packet is not to be delivered to an upper layer, the IAB node examines a routing configuration associated with the ingress topology to identify available egress links. If no available egress link is identified with the routing configuration, the IAB node additionally checks the BAP routing ID map (or header overwrite configuration) to find a new routing option by header overwrite. If an entry is found that matches the ingress topology and the BAP route ID in the packet header, the IAB node rewrites the header with the new BAP route ID and identifies the egress topology associated with the new BAP route ID.

The IAB node then again determines whether the packet has to be delivered to the upper layer by comparing the new destination BAP address with the BAP address of the IAB node associated with the egress topology. When a packet is not to be delivered to an upper layer, the IAB node again checks the routing configuration associated with the egress topology of the data packet. For rerouting without changing the topology, the egress topology is thus equal to the ingress topology.

If an available egress link has not yet been found, the IAB node again checks the BAP route ID map (or header overwrite configuration) to find a new route option through another header overwrite.

Finally, when an available egress link is identified, mapping to the BH RLC channel is performed. The BH RLC channel mapping considers the ingress topology for the previous hop BAP address (ingress backhaul link) and the egress topology for the next hop BAP address (egress backhaul link).

Fig. 17 illustrates another example method for processing data packets (e.g., for managing BAP PDU (or data packet) routing through one or more IAB networks (one or more IAB topologies)) in accordance with embodiments and examples of this invention using a flowchart 1700. For example, the example method shown in fig. 17 may be performed by the CPU 1111 of fig. 11 for a program element executed by a BAP entity (DU or MT part) of the BAP sub-layer. The method of fig. 17 may be applied to route data packets in either the upstream or downstream direction. The method of fig. 17 may use a (or alternatively map 7) of fig. 5 and the configuration table of fig. 8.

The process begins at step 1701, where an IAB node, such as IAB node 612, receives a BAP packet or BAP PDU that it should route at step 1701.

At step 1702, the IAB node identifies an IAB topology associated with a BAP packet to be routed (e.g., a received BAP packet). For example, the IAB node may determine an IAB topology associated with the received data packet from one or more of the examples as described above for step 1004 of fig. 10.

At step 1703, the IAB node identifies a type of traffic associated with the received BAP packet. Two types of traffic can be distinguished:

One traffic type for traffic intended to cross border nodes and to be routed through different topologies (i.e. inter-topology routing). This type of traffic may be referred to as transit traffic, or span traffic or tandem traffic. This is the case, for example, where data from the donor CU 620 topology is to be delivered to an upper layer in the border node 612 (i.e., the donor CU 610 sends the data to the border node),

-One traffic type for traffic to be routed through a single topology. This type of traffic may be referred to as non-transit traffic, or normal traffic, or non-tandem traffic. For example, this is the case where data from the donor CU 620 topology is to be delivered to an upper layer in the border node 612 (i.e., the donor CU 620 sends data to the border node), or where data from the donor CU 610 topology is to be delivered to an upper layer in the border node 612 (i.e., the donor CU 610 sends data to the border node).

In one example, the determination of the type of traffic (i.e., transit/concatenated or non-transit/non-concatenated) may be obtained by a flag (or traffic type identifier) in the BAP header using, for example, one of the reserved bits 302, 303, and 304. For example, a flag is set to "1" (or "0") for BAP packets associated with transit (or concatenated) traffic and to "0" (or "1") for BAP packets associated with non-transit (or non-concatenated) traffic. The non-boundary nodes may ignore the flag. The border node may use the flag to associate traffic with the BAP packet to be routed. In another example, the determination may be obtained by parsing the header of the BAP packet and checking the value of PATH field 306. In practice, the set of path identifier values may be reserved by the IAB donor CU controlling the routing (i.e., IAB donor CU 610 in fig. 6) and will only be used for transit (or concatenation) of traffic. When such a particular PATH identifier is identified in PATH field 306, the border node may detect transit traffic. The dedicated path identifier for transit traffic may be referred to as a transit path identifier that identifies a transit path.

In one example, the BH routing information addition list Information Element (IE) defined in section 9.2.9.1 of 3GPP TS 38.473v16.4.0 is modified to allow the IAB donor CU to configure a transit field associated with 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.

In step 1704, the IAB node checks the type of traffic. This step may be skipped in non-border nodes (and step 1703). For example, if the IAB node is configured with only one BAP address, the IAB node is a non-boundary node and steps 1703 and 1704 may be skipped. If the type of traffic is transit traffic, the IAB node identifies a new route identifier based on route identifier mapping information (such as the BAP route ID mapping table 800, etc.) and the route identifier of the received packet and updates or rewrites the BAP header of the received packet with the identified new route identifier at step 1705. For example, if the traffic type is transit traffic, the IAB node rewrites the BAP header of the packet if an entry is found in the BAP route ID mapping table (or header rewrite configuration) 800 described with respect to fig. 8. In this case, the IAB node replaces (updates or rewrites) the ROUTING identifier in the received packet with the NEW ROUTING identifier of the matching entry by replacing (updating or overwriting), respectively, the DESTINATION address in the DESTINATION field 305 and the PATH identifier in the PATH field 306 in the BAP header of the BAP PDU to be routed with the DESTINATION address in the NEW BAP ROUTING field 830 or the DESTINATION address in the DESTINATION field 8311 and the PATH identifier in the PATH field 8312 associated with the PREVIOUSBAP ROUTING field 820 considered for the matching entry as discussed in fig. 8. Then, at step 1706, the IAB node identifies the IAB topology associated with the NEW route identifier, e.g., by examining the NEW topology field 832 associated with 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.

In the event that the traffic at step 1704 is not transit traffic, the IAB node proceeds directly to step 1707 without performing steps 1705 and 1706. For example, for non-transit BAP packets, the header is not overwritten and the egress topology is equal to the ingress topology.

In step 1707, the IAB node checks if the DESTINATION address information or DESTINATION address in the destinationfield 305 matches its own BAP address. If it is determined that the DESTINATION address in the destinationfield 305 actually matches the IAB node's own BAP address, the IAB node removes the BAP header from the BAP PDU and delivers it to the upper layer (step 1708). When the IAB node is a border node, the border node compares the DESTINATION field 305 with only one of its BAP addresses (the BAP address associated with the same topology as the received BAP packet to be routed).

If the packet is not to be delivered to an upper layer, at step 1711, the IAB node checks routing configuration information, such as a routing configuration table or backhaul routing configuration table 500 (or alternatively 700), associated with the IAB topology identified at step 1702 or step 1706, based on the routing identifier of the received data packet, looking for routing options for the BAP PDU to be routed.

The routing options may include: an entry is found in the backhaul route configuration table 500 (or alternatively 700) associated with the IAB topology that includes a route identifier in the route identifier (BAP route ID) field 501 that matches a route identifier in the BAP route ID field 30 (i.e., concatenation of the destinion field 305 and PATH field 306) in the BAP header of the received packet.

The routing options may include: an entry is found in the backhaul routing configuration table 500 described above for fig. 5a (alternatively, the backhaul routing configuration table 700 described above for fig. 7) associated with the IAB topology that includes a DESTINATION address in the destinion field 5011 that matches the DESTINATION address in the destinion field 305 in the BAP header of the received BAP PDU.

If a routing option is found at step 1712, the IAB node identifies an egress Backhaul (BH) link to route the BAP PDU at step 1713, for example, by checking the next hop BAP address field 502 associated with the entry of the backhaul routing configuration table identified at steps 1711 and 1712.

The IAB node then determines at step 1714 whether the egress BH link identified at step 1713 is available. If it is determined that the egress BH link is not available, the IAB node may move back to step 1711 and check the backhaul routing table again for new routing options.

If it is determined that an egress BH link is available, the IAB node determines a BH RLC channel (over which to route BAP PDUs) based on information from the BH RLC channel mapping configuration tables as discussed in fig. 5 b, 5c, 9a, and 9b, and finally routes BAP PDUs over the determined BH RLC channel at step 1715.

If no routing option is found at step 1712, the IAB node may check whether rerouting through header overwriting is possible. For example, at step 1716, the IAB node may check the information in the update or rewrite field 703 of the backhaul ROUTING configuration table 700 (or a value in at least a portion of the next-hop address field 502 when a particular value in at least a portion of the next-hop address field is used to indicate whether header rewriting is to be performed) for an entry matching the ROUTING identifier in the BAP ROUTING ID field 30 (i.e., concatenation of the destinationfield 305 and PATH field 306) in the BAP header of the received packet. Alternatively, the IAB node checks if an entry in the BAP route ID mapping table (or header overwrite configuration) 800 matches the route identifier in the BAP ROUTING ID field 30 in the BAP header of the received packet.

If the overwrite field 703 (or a value in at least a portion of the next hop address field 502) indicates that no BAP header overwrite is to be performed for routing BAP PDUs, or if no entry is found in the BAP route ID mapping table 800, the IAB node may discard the BAP PDUs or store the BAP PDUs for new routing attempts (step 1719).

If the overwrite field 703 (or a value in at least a portion of the next hop address field 502) indicates that some BAP header overwrite is to be performed for ROUTING a BAP PDU, the IAB node identifies a new route identifier and associated IAB topology based on the route identifier mapping information and the route identifier of the received data packet, for example by checking an entry in a route ID mapping table (such as the route ID mapping table 800 shown in fig. 8 and described with respect to fig. 8, etc.), wherein for this route ID mapping table the previous route identifier field 821 or ROUTING ID field 821 (i.e., the destinion field 8211 and PATH field 8212) of the PREVIOUSBAP ROUTING field 820 matches the route identifier of the received data packet (i.e., the ROUTING ID field (i.e., the destinion field 305 and PATH field 306) in the BAP header of the BAP PDU to be routed), and the IAB in the previous topology field or topology field 822 matches the entry topology identified at step or step IAB 1706.

At step 1717, after determining that BAP header overwriting is to be performed, the IAB node replaces (updates or overwrites) the DESTINATION address in the destinatino field 305 and the PATH identifier in the PATH field 306 in the BAP header of the BAP PDU to be routed, respectively, with the NEW DESTINATION address in the NEW BAP ROUTING field 830 or the DESTINATION address in the destinatino field 8311 and the PATH identifier in the NEW PATH identifier field or PATH field 8312, respectively, e.g., by replacing (updating or overwriting) the DESTINATION address in the destinatino field 305 and the PATH identifier in the PATH field 306 in the BAP header of the BAP PDU to be routed with the NEW ROUTING identifier, as discussed in fig. 8 in association with the PREVIOUSBAP ROUTING field 820 considered for the matching entry.

At step 1718, the IAB node determines the IAB topology associated with the new routing identifier, for example, by examining the new topology field 832 associated with 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 IAB node may then move back to step 1711 and determine a new routing option for the received BAP PDU based on the routing configuration information associated with the identified IAB topology and the identified new routing identifier, e.g. by again checking the backhaul routing configuration table 500 (alternatively 700) associated with the IAB topology identified in step 1718, thereby looking up the new routing option for the received BAP PDU.

Based on fig. 17, the following statements may be made.

A boundary IAB node is an IAB node whose IAB-DUs terminate in an IAB donor CU different from the parent DU.

For IAB nodes (including border nodes), the IAB topology controlled by the terminal IAB donor CUs refers to the master topology (or Master Cell Group (MCG) topology). For border nodes, the IAB topology controlled by the non-terminal IAB donor CUs refers to a secondary topology (or Secondary Cell Group (SCG) topology).

For any IAB node, the IAB topology associated with the ingress backhaul link on which the BAP packets are received refers to the ingress topology and the IAB topology associated with the egress backhaul link on which the BAP packets are transmitted refers to the ingress topology.

BAP packets that should traverse border nodes from one ingress topology to a different egress topology represent traffic in transit, or simply transit traffic. The term "transit traffic" is equivalent to the term "cascade traffic". Due to the rerouting in the border nodes, it may happen that BAP packets identified as transit traffic are eventually routed to the same egress topology as the ingress topology. For the same reason, it may happen that BAP packets that are not identified as transit traffic are eventually routed to an egress topology that is different from the ingress topology in the border node.

Assume that the border node has one BAP address for each topology and that each IAB donor CU independently assigns the BAP address, BAP route ID, and BH RLC channel ID of the IAB node. Thus, the same BAP address, BAP route ID, or BH RLC channel ID may be assigned in both topologies.

The BAP address should be intended to uniquely identify only the IAB node. Thus, the destination BAP address of the BAP packet is not a different alias than the BAP address of the border node in the ingress topology. Thus, BAP packets for transit traffic are received by a border node having a destination BAP address equal to the BAP address of the border node in the ingress topology.

The identification of transit traffic in the border nodes relies on a dedicated path identifier (called transit path ID) to be dedicated to routing BAP packets across two topologies. The criteria may reserve a series of dedicated path ID values for the transit path ID, or the IAB donor CUs may allocate and define a set of transit path ID values in the border nodes. Alternatively, a flag (e.g., one of the reserved bits) within the BAP header may be used to identify transit traffic.

In the border nodes, the identification of the ingress link that received the BAP packet should also enable the identification of the ingress topology (primary/MCG or secondary/SCG).

For border nodes, the BAP route ID map (or header overwrite configuration) indicates the topology of the previous route ID reference (MCG/SCG) and indicates the topology of the new route ID reference (MCG/SCG). The configuration table may be used for both: the case of overwriting the BAP header for transit traffic in the border node, and the BAP header for rerouting (towards a different donor DU) in any IAB node needs to be overwritten. The configuration table may be used for both upstream and downstream routing as well as rerouting.

The border nodes are configured with separate routing configurations for the primary/MCG topology and for the secondary/SCG topology. Alternatively, a unique routing configuration indicates for each entry the topology to which the BAP route ID and the next hop BAP address (i.e., egress link) refer.

For ingress to egress BH RLC channel mapping at the border node, it is necessary to indicate the egress topology associated with the next hop BAP address and the ingress topology associated with the previous hop BAP address. Alternatively, the BH RLC channel mapping configuration provides a mapping between (ingress link + ingress BH RLC channel ID) and (egress link + egress BH RLC channel ID), where each link is associated with a topology (primary/MCG or secondary/SCG).

For BAP packets that cross border nodes from an ingress topology that is different from an egress topology, if an N:1 bearer mapping is applied on the ingress link, then an N:1 bearer mapping should also be applied on the egress link. Coordination between the IAB donor CUs is required to ensure consistent configuration of the IAB nodes in both topologies.

The BAP operation to process the BAP packet may be as follows.

The non-border IAB node first behaves as a Rel-16 specification: is determined to be delivered to the upper layer, thereby checking the routing configuration. However, if the available egress link is not marked with a routing configuration, the IAB node additionally checks the BAP routing ID mapping (or header overwrite configuration) to find a new routing option by header overwrite. If an entry is found with the previous BAP route ID that matches the BAP route ID in the packet header, the IAB node rewrites the header with the new BAP route ID and again checks the route configuration. Finally, if an available egress link is identified, mapping to the BH RLC channel is performed.

In contrast, the border nodes behave like non-border IAB nodes except that the border nodes have to take into account the topology and additional steps have to be performed in advance.

The border node should first identify the ingress topology associated with the BAP packet to be processed. This identification may be performed simultaneously with the identification of the ingress link for the BAP packet received from the lower layer.

The border node should then determine whether the BAP packet is transit traffic, e.g., based on the identity of the transit path in the BAP header. If transit traffic is identified, the border node examines the BAP route ID map (or header overwrite configuration) to overwrite the BAP header. To this end, the border node looks up an entry in the packet header that matches the ingress topology and BAP route ID. Furthermore, with the BAP route ID mapping configuration, the border node should identify the egress topology associated with the new BAP route ID.

For non-transit BAP packets, the header is not overwritten and the egress topology is equal to the ingress topology.

The border node then checks for delivery to the upper layer. To this end, the border node compares the destination BAP address with only one of its BAP addresses (the BAP address associated with the exit topology of the BAP packet).

If the packet is not to be delivered to the upper layer, the border node checks the routing configuration for the egress topology associated with the BAP packet. For non-border nodes, if no available egress links are identified with the routing configuration, the border node additionally examines the BAP routing ID map (or header overwrite configuration) to find new routing options through header overwrite. If an entry is found with a pair (previous BAP route ID and topology) that matches the BAP route ID in the header and the topology of the BAP packet, the border node rewrites the header with the new BAP route ID, identifies the associated egress topology, and again checks the routing configuration for the identified egress topology.

Finally, considering the ingress topology for the previous hop BAP address and the egress topology for the next hop BAP address, if an available egress link is identified, mapping to the BH RLC channel is performed.

It may be noted that first overwriting the header in the border node avoids using alias BAP addresses for transit traffic and avoids useless parsing of the routing configuration prior to overwriting.

It may also be noted that BAP operations may be illustrated in a unified manner for non-border nodes and border nodes, considering that the egress topology is always equal to the ingress topology for the non-border nodes.

In practice, the flow chart of FIG. 17 can be summarized with the following steps:

1. determining tandem or non-tandem traffic based on the dedicated path identifier (i.e., distinguishing between tandem and non-tandem traffic using a particular value of the path ID);

2. the header is rewritten in the border node for the concatenated traffic. Here, the gateway topology needs to be identified;

3. As in the release 16 specification, checking whether traffic should be delivered to upper layers;

4. Checking a routing table for routing;

5. If a topology or donor inter-DU reroute is triggered, then header re-writing for the reroute is performed and the next hop is selected by looking up the routing table with the new route ID;

6. Mapped to the BH RLC channel. For ingress to egress BH RLC channel mapping at a border node, it is necessary to indicate the IAB topology associated with the next IAB node and the IAB topology associated with the previous IAB node.

Furthermore, it can be noted that:

The header overwrite based solution should avoid BAP address collision,

As a first step, the border node checks if the traffic is cascaded. In this regard, the solution proposes to rely on a dedicated path identifier to be dedicated to identifying tandem traffic (even if the flag in the BAP header requires the use of reserved bits within the BAP header, this further option is acceptable for tandem traffic identification, while not being able to distinguish between tandem traffic and non-tandem traffic based on the ingress link).

It is not necessary to indicate in the routing table configuration 500 or 700 whether it is for tandem traffic or non-tandem traffic,

It is not necessary to indicate in the routing table configuration 500 or 700 whether it is for upstream or downstream,

However, it is desirable to be able to associate a topology with a BAP address in the routing table 500 or 700,

It is not necessary to indicate in the header overwrite configuration 800 whether it is for upstream or downstream,

However, it is desirable to be able to associate a topology with the BAP address in the header overwrite configuration 800,

The BAP header re-write configuration for inter-topology routing and the BAP header re-write configuration for re-routing at the border node can be avoided to be two separate re-write tables.

While the invention has been described with reference to embodiments, it is to be understood that the invention is not limited to the disclosed embodiments. Those skilled in the art will appreciate that various changes and modifications may be made without departing from the scope of the invention as defined in the appended claims. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings), may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.

In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Reference signs appearing in the claims are only for illustration and do not limit the scope of the claims.

In the foregoing embodiments, the described functions 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 on a computer-readable medium, and executed by a hardware-based processing unit.

The computer-readable medium may include a computer-readable storage medium corresponding to a tangible medium, such as a data storage medium, or a communication medium, including any medium that facilitates transfer of a computer program from one location to another, for example, according to a communication protocol. In this manner, the computer-readable medium may generally correspond to (1) a non-transitory tangible computer-readable storage medium 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 to implement the techniques described in this disclosure. The computer program product may include a computer-readable medium.

By way of example, and not limitation, 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. Further, any connection is properly termed a computer-readable medium. For example, if the 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. However, it should be understood that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transitory media, but are directed to non-transitory tangible storage media. As used herein, discs (disks and disks) include Compact Discs (CDs), laser discs, optical discs, digital Versatile Discs (DVDs), floppy disks, and blu-ray discs where disks (disks) usually reproduce data magnetically, while discs (disks) reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

The instructions may be executed by one or more processors, such as one or more Digital Signal Processors (DSPs), general purpose microprocessors, application Specific Integrated Circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Thus, the term "processor" as used herein may refer to any one of the foregoing structures or any other structure suitable for implementation of the techniques described herein. Additionally, in some aspects, the functionality described herein may be provided within dedicated hardware and/or software modules configured for encoding and decoding, or incorporated into a combined codec. Furthermore, the techniques may be fully implemented in one or more circuits or logic elements.

Clauses describing further aspects and embodiments

1. A method for processing data packets at an IAB node in an integrated access and backhaul communication system, i.e., an IAB communication system, the 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 an IAB topology associated with the received data packet;

determining whether to update a routing identifier of a received data packet prior to routing the data packet to another IAB node based on routing configuration information associated with the determined IAB topology and the routing identifier;

in response to determining to update the routing identifier:

identifying a new route identifier and an associated IAB topology based on the route identifier mapping information and the route identifier of the received data packet;

The update data packet is routed to the next IAB node through the egress backhaul link.

2. The method of clause 1, wherein the received packet is a backhaul adaptation protocol packet, BAP, packet comprising a BAP header including the routing identifier, wherein the routing configuration information comprises a backhaul routing configuration table comprising a field for indicating whether to update the BAP routing identifier of the received packet.

3. The method of clause 2, wherein the route identifier mapping information comprises a route identifier mapping table comprising a field for indicating an IAB topology associated with the BAP route identifier to be updated and/or a field for indicating an IAB topology associated with the new route identifier.

4. The method of clause 1, wherein the routing configuration information comprises a routing configuration table having at least one entry, each entry of the routing configuration table comprising: a route identifier field for a route identifier, the route 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 route 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 route identifier is to be updated.

5. The method of clause 1, wherein the routing configuration information comprises a routing configuration table having at least one entry, each entry of the routing configuration table comprising: a route identifier field for a route identifier, the route 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 route 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 value in at least a portion of the next hop address field indicates that the routing identifier is to be updated.

6. The method of clause 4 or clause 5, wherein the specific value in the update field or at least a portion of the next hop address field for an entry indicates whether the route identifier is to be updated and the priority of the entry compared to another entry having the same route identifier or destination address.

7. The method of any one of the preceding clauses, further comprising: a backhaul RLC channel for the egress backhaul link is selected based on backhaul RLC channel mapping information and the identified IAB topology associated with the egress backhaul link.

8. The method of clause 7, wherein the backhaul RLC channel mapping information comprises a backhaul RLC channel mapping configuration table having at least one entry, each entry comprising: a next hop address field for a next hop address of a next IAB node following the IAB node in a routing path, an egress topology field for indicating an IAB topology associated with the next IAB node and for indicating an egress backhaul link between the IAB node and the next IAB node with the next hop address field, a previous hop address field for a previous hop address of a previous IAB node in the routing path preceding the IAB node, an ingress topology field for indicating an IAB topology associated with the previous IAB node and for indicating an ingress backhaul link between the IAB node and the previous IAB node with the previous hop address field, an ingress backhaul RLC channel identifier field for a backhaul RLC channel used by the ingress backhaul link, and an egress RLC channel identifier field for a backhaul RLC channel used by the egress backhaul link.

9. The method of clause 8, wherein receiving the data packet comprises: receiving the data packet from a previous IAB node over an ingress BH link, wherein determining an IAB topology associated with the received data packet comprises: determining an IAB topology associated with the ingress backhaul link,

Wherein selecting the 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 previous IAB node, the determined IAB topology associated with the previous IAB node, an address of the next IAB node, and an IAB topology associated with the next IAB node match respective fields of an entry in the backhaul RLC channel mapping configuration table; and

Upon determining to match an entry, the backhaul RLC channel ID of the matching entry is used to select a backhaul RLC channel for the egress backhaul link.

10. The method of clause 7, wherein the backhaul RLC channel mapping information comprises a backhaul RLC channel mapping configuration table having at least one entry, each entry comprising: 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 following the IAB node in a routing path, an egress topology field for indicating an IAB topology associated with the next IAB node and for indicating an egress backhaul link between the IAB node and the next IAB node with the next hop address field, and an egress backhaul RLC channel identifier field for a backhaul RLC channel identifier of a backhaul RLC channel used by the egress backhaul link.

11. The method of clause 10, wherein receiving the data packet comprises: generating the data packet in a portion of the IAB node and receiving the data packet at another portion of the IAB node 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 an IAB topology associated with the next IAB node match respective fields of an entry in the backhaul RLC channel mapping configuration table; and when it is determined to match an entry, selecting a backhaul RLC channel for the egress backhaul link using an egress backhaul RLC channel ID of the matching entry.

12. The method of any of clauses 4 to 11, wherein the route identifier mapping information comprises a route identifier mapping table having at least one entry, each entry of the route identifier mapping table comprising: a previous route identifier field for a route identifier; a previous topology field for indicating an IAB topology associated with a route identifier in the previous route identifier field; a new route identifier field for the route identifier; and a new topology field for indicating an IAB topology associated with a route identifier in the new route identifier field.

13. The method of clause 12, wherein the routing identifier of the received data packet comprises a destination address for a destination IAB node of the data packet, wherein identifying the new routing identifier and an IAB topology associated with a next IAB node to which 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 a previous routing identifier field of the entry or whether the destination address of the routing identifier of the received data packet matches a destination address in a destination address field of the entry; and upon determining to match an entry, using the routing identifier in the new routing identifier field of the matching entry as the identified new routing identifier and using the IAB topology indicated by the new topology field of the matching entry as the identified IAB topology associated with the next IAB node.

14. The method of any of clauses 8-13, wherein each topology field in the table includes a topology identifier that uniquely identifies one of the at least two IAB topologies.

15. The method of any of clauses 4 to 14, wherein the route identifier of the received data packet comprises a destination address for a destination IAB node of the data packet, wherein determining whether to update the route identifier comprises: determining whether a routing option exists for the received data packet by examining a 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 a routing identifier field of the entry or whether the destination address of the routing identifier of the received data packet matches a destination address in a destination address field of the entry; and wherein determining whether to update the routing identifier comprises: in response to determining to match an entry, and by examining the value in the update field or the next hop address field of the matching entry, it is determined whether to update the routing identifier.

16. The method of any of clauses 4-15, wherein the new route identifier comprises a destination address of a destination IAB node for the data packet, wherein determining an egress backhaul link comprises: checking a routing configuration table associated with the identified IAB topology to determine whether the identified new routing identifier matches a routing identifier in a routing identifier field of the entry or whether a destination address of the new routing identifier matches a destination address in a destination address field of the entry; and upon determining to match an entry, determining the next IAB node using a next hop address in a next hop address field of the matching entry.

17. The method of any of clauses 15 to 16, wherein the order of entries in the routing configuration table having the same routing identifier or destination address indicates a priority order of the entries.

18. The method of clause 17, wherein checking the routing configuration table comprises: the entries are checked according to their priority order.

19. A method for processing data packets at an IAB node in an integrated access and backhaul communication system, i.e., an IAB communication system, the IAB communication system comprising at least two IAB topologies, and each IAB topology comprising a plurality of IAB nodes, the method comprising:

(a) Receiving a data packet, the data packet including a routing identifier;

(b) Determining an IAB topology associated with the received data packet;

(c) Determining whether the received data packet is to be delivered to an upper layer of the IAB node;

(d) Responsive to determining that the received data packet is not to be delivered to an upper layer, determining whether there is an available egress backhaul link for routing the data to a next IAB node based on routing configuration information associated with the determined IAB topology and a routing identifier of the received data packet;

(e) Responsive to determining that there is no available egress backhaul link for routing the data, determining whether to update a routing identifier of the received data packet;

(f) In response to determining to update the route identifier, determining a new route identifier and an IAB topology associated with the new route identifier, and updating the received data packet by updating the route identifier of the received data packet with the determined new route identifier to provide an updated data packet comprising the determined new route identifier; and

(G) Repeating at least step (c) for the update data packet.

20. The method of clause 19, wherein the repeating comprises: repeating steps (c) through (f) for at least one cycle for an update packet until it is determined that the update packet is to be delivered to an upper layer, or that there is an egress backhaul link for routing data, or that the routing identifier is not to be updated.

21. The method of clause 19 or clause 20, wherein each of the routing identifiers of the received data packet and the update data packet includes a destination address of a destination IAB node, wherein determining whether the received data packet is to be delivered to an upper layer of the IAB node and determining whether the update data packet is to be delivered to an upper layer of the IAB node each include: the destination address of the route identifier is compared with the address of the IAB node associated with the respective IAB topology determined.

22. The method of clause 21, wherein the IAB node is a border node such that the IAB node is part of a first IAB topology of the at least two IAB topologies and is further 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 packet is to be delivered to an upper layer of the IAB node and determining whether an update packet is to be delivered to an upper layer of the IAB node each comprises: comparing the destination address of the route identifier with one of the first address and the second address of the IAB node, wherein the one address is the first address of the IAB node if the determined IAB topology is the first topology and the one address is the second address of the IAB node if the determined IAB topology is the second topology.

23. The method of any of clauses 19-22, wherein determining a new route identifier and an IAB topology associated with the new route identifier comprises: the new route identifier and associated IAB topology are determined based on the route identifier mapping information and the route identifier of the received data packet.

24. The method of clause 23, wherein the route identifier mapping information comprises a route identifier mapping table having at least one entry, each entry of the route identifier mapping table comprising: a previous route identifier field for a route identifier; a previous topology field for indicating an IAB topology associated with a route identifier in the previous route identifier field; a new route identifier field for the route identifier; and a new topology field for indicating an IAB topology associated with a route identifier in the new route identifier field.

25. The method of any of clauses 19-23, wherein the received data packet is a backhaul adaptation protocol data packet, BAP, data packet comprising a BAP header comprising the route identifier, wherein the route configuration information comprises a backhaul route configuration table comprising a field for indicating whether the BAP route identifier of the received data packet is to be updated.

26. The method of clauses 23 and 25, wherein the route identifier mapping information comprises a route identifier mapping table comprising fields for indicating an IAB topology associated with the BAP route identifier to be updated and/or fields for indicating an IAB topology associated with the new route identifier.

27. The method of any of clauses 19 to 24, wherein the routing configuration information comprises a routing configuration table having at least one entry, each entry of the routing configuration table comprising: a route identifier field for a route identifier, the route 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 route 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 route identifier is to be updated.

28. The method of any of clauses 19 to 24, wherein the routing configuration information comprises a routing configuration table having at least one entry, each entry of the routing configuration table comprising: a route identifier field for a route identifier, the route 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 route 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 value in at least a portion of the next hop address field indicates that the routing identifier is to be updated.

29. The method of clause 27 or 28, wherein the specific value in the update field or at least a portion of the next hop address field for an entry indicates whether the route identifier is to be updated and the priority of the entry compared to another entry having the same route identifier or destination address.

30. The method of any one of clauses 19 to 29, further comprising: responsive to determining that there is an available egress backhaul link, selecting a backhaul RLC channel for the egress backhaul link based on an IAB topology associated with the egress backhaul link and backhaul RLC channel mapping information; the data packet is routed to the next IAB node through the selected backhaul RLC channel of the egress backhaul link.

31. The method of clause 3 or clause 12 or clause 25 or clause 26, wherein the fields of the routing configuration table are combined with the fields of the routing identifier mapping table in a single table.

32. The method of any one of the preceding clauses, wherein receiving the data packet comprises: receiving a data packet from a previous IAB node over an ingress backhaul link, wherein determining an IAB topology associated with the received data packet comprises: an IAB topology associated with the ingress backhaul link is determined.

33. The method of any one of clauses 1 to 31, further comprising: generating the data packet in a portion of the IAB node, and wherein receiving the data packet comprises: receiving the generated data packet at another portion of the IAB node for routing to another IAB node, wherein determining an IAB topology associated with the received data packet comprises: an IAB topology associated with the IAB node is determined.

34. The method of any of the preceding clauses, wherein the IAB topology associated with the received data packet is one of the at least two IAB topologies and the IAB topology associated with the next IAB node to which the data packet is to be routed is the same or another of the at least two IAB topologies.

35. The method of any one of the preceding clauses, further comprising: the routing configuration information and the routing identifier mapping information are received from a donor control unit, donor CU, of at least one of the at least two IAB topologies.

36. The method of any of the preceding clauses, wherein, in case the IAB node is a border 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 to update the routing identifier is based on the first routing configuration information in case the determined IAB topology is the first IAB topology or on the second routing configuration information in case the determined IAB topology is the second IAB topology.

37. A method for processing data packets at an IAB node in an integrated access and backhaul communication system, i.e., an IAB communication system, the 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 from a previous IAB node over an ingress backhaul link, the data packet including a route identifier;

Determining an IAB topology associated with the received data packet;

determining an egress backhaul link through which a received data packet is to be routed to a next IAB node based on a routing identifier of the data packet;

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;

The data packet is routed to the next IAB node over the selected backhaul RLC channel,

Wherein the backhaul RLC channel mapping configuration table includes at least one entry, each entry including:

for the next hop address field of the next hop address of the next IAB node following the IAB node in the routing path,

A ingress topology field for indicating an IAB topology associated with the previous IAB node and for indicating an ingress backhaul link between the IAB node and the previous IAB node with the previous hop address field,

An ingress backhaul RLC channel identifier field for a backhaul RLC channel identifier of a backhaul RLC channel used for the ingress backhaul link, and

An egress backhaul RLC channel identifier field for a backhaul RLC channel identifier of a backhaul RLC channel used for the egress backhaul link.

38. The method of clause 37, further comprising: determining an IAB topology associated with the previous IAB node,

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 previous IAB node, the determined IAB topology associated with the previous IAB node, an address of the next IAB node, and the determined IAB topology associated with the next IAB node match respective fields of an entry in the backhaul RLC channel mapping configuration table; and

39. A method for processing data packets at an IAB node in an integrated access and backhaul communication system, i.e., an IAB communication system, the 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 an IAB topology associated with the next IAB node;

a traffic type identifier field for indicating a traffic type of a data packet to be routed,

An egress topology field for indicating an IAB topology associated with the next IAB node and for indicating an egress backhaul link between the IAB node and the next IAB node using the next-hop address field, an

40. The method of clause 39, wherein selecting the 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 an identified IAB topology associated with the next IAB node match respective fields of an entry in the backhaul RLC channel mapping configuration table; and when it is determined to match an entry, selecting a backhaul RLC channel for the egress backhaul link using an egress backhaul RLC channel ID of the matching entry.

41. The method of any of clauses 37-40, wherein the routing identifier of the received data packet comprises a destination address for a destination IAB node of the data packet, wherein determining an egress backhaul link through which the data packet is to be routed to a next IAB node comprises: determining an address of the next IAB node by examining a backhaul route configuration table using the route identifier or a destination address of the route identifier, and determining an egress backhaul link based on the determined address of the next IAB node of the matching entry when there is a match with an entry in the backhaul route configuration table, wherein the backhaul route configuration table has at least one entry, each entry of the route configuration table including at least a route identifier field for the route identifier and a next hop address field for indicating the address of the next IAB node in the route path identified by the route identifier.

42. The method of clause 41, wherein when there is no match with an entry in the backhaul routing configuration table, the method further comprises: checking a routing identifier mapping table using the routing identifiers of the received data packets 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 matching entry; updating a route identifier of a received data packet with the new route identifier to provide an updated data packet including the identified new route identifier, wherein the new route identifier includes a destination address for a destination IAB node of the data packet, wherein determining an egress backhaul link through which the data packet is to be routed to a next IAB node includes: the address of the next IAB node is determined by examining the backhaul route configuration table using the new route identifier or a destination address of the new route identifier, and when there is a match with an entry in the backhaul route configuration table, an egress backhaul link is determined based on the determined address of the next IAB node of the matching entry.

43. A method for managing processing of data packets in an integrated access and backhaul communication system, i.e., an IAB communication system, comprising at least two IAB topologies, each IAB topology comprising a plurality of IAB nodes and a donor central unit, i.e., a donor CU, the method comprising: at a first donor CU of a first IAB topology of the at least two IAB topologies, providing, to at least one IAB node of the first IAB topology, packet routing configuration information for routing a packet through at least the first IAB topology, wherein the 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 comprising: a route identifier field for a route identifier, the route 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 route 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 the received data packet that matches a routing identifier in the routing identifier field is to be updated, wherein the routing identifier mapping information includes a routing identifier mapping table having at least one entry including: a previous route identifier field for a route identifier; a previous topology field for indicating an IAB topology associated with a route identifier in the previous route identifier field; a new route identifier field for the route identifier; and a new topology field for indicating an IAB topology associated with a route identifier in the new route identifier field.

44. The method of clause 43, wherein the field for indicating whether the routing identifier of the 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 that the route identifier is to be updated; or at least a portion of the next hop address field, wherein a value in the at least a portion of the next hop address field indicates that the routing identifier is to be updated.

45. The method of clause 43 or clause 44, wherein providing comprises: the routing configuration table is provided in a routing configuration information element, i.e. a routing configuration IE, for configuration messages transmitted to the at least one IAB node, and the routing identifier mapping table is provided in a routing identifier mapping information element, i.e. a routing identifier mapping IE, for configuration messages transmitted to the at least one IAB node.

46. The method of any of clauses 43-45, wherein the data packet routing configuration information further comprises a backhaul RLC channel mapping configuration table having at least one entry comprising: a next hop address field for a next hop address of a next IAB node following the at least one IAB node in the routing path; an egress topology field for indicating an IAB topology associated with the next IAB node and for indicating an egress backhaul link between the IAB node and the next IAB node using the next-hop address field; an egress backhaul RLC channel identifier field for a backhaul RLC channel identifier of a backhaul RLC channel used for the egress backhaul link; and/or a previous hop address field for a previous hop address of a previous IAB node preceding the IAB node in the routing path; a ingress topology field for indicating an IAB topology associated with the previous IAB node and for indicating an ingress backhaul link between the IAB node and the previous IAB node using the previous hop address field; an ingress backhaul RLC channel identifier field for a backhaul RLC channel identifier of a backhaul RLC channel used by the ingress backhaul link.

47. The method of any of clauses 43-46, wherein the data packet routing configuration information further comprises an uplink traffic to backhaul RLC channel mapping configuration table having at least one entry comprising: 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 following the IAB node in a routing path; an egress topology field for indicating an IAB topology associated with the next IAB node and for indicating an egress backhaul link between the IAB node and the next IAB node using the next-hop address field; and an egress backhaul RLC channel identifier field for a backhaul RLC channel identifier of a backhaul RLC channel used for the egress backhaul link.

48. The method of clause 46 or clause 47, wherein the providing comprises: the backhaul RLC channel mapping configuration table is provided in a routing configuration information element, i.e., a routing configuration IE, for a configuration message transmitted to the at least one IAB node.

49. The method of any of clauses 43-48, wherein providing further comprises: the data packet routing configuration information is provided to at least one IAB node of a second IAB topology of the at least two IAB topologies, the second IAB topology being different from the first IAB topology and managed by a second donor CU.

50. The method of any one of clauses 43 to 49, further comprising: sending a request to a second donor CU of a second IAB topology of the at least two IAB topologies to establish a route of a data packet 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 request was accepted by the second donor CU, and configuration information relating to one or more of the IAB nodes in the second IAB topology, in case the request was accepted by the second donor CU, the configuration information identifying a routing path for routing data packets between at least one IAB node of the first IAB topology and at least one IAB node of the second IAB topology, wherein providing the data packet routing configuration information comprises: the packet routing configuration information is provided based on configuration information received from the second donor CU.

51. A method for managing processing of data packets in an integrated access and backhaul communication system, i.e., an IAB communication system, comprising at least two IAB topologies, each IAB topology comprising a plurality of IAB nodes and a donor central unit, i.e., a donor CU, the method comprising: at a first donor CU of a first IAB topology of the at least two IAB topologies,

Sending a request to a second donor CU of a second IAB topology of the at least two IAB topologies to establish a route of a data packet between the first IAB topology and the second IAB topology;

Receiving a response from the second donor CU, the response comprising acknowledgement information indicating whether the request was accepted by the second donor CU, and configuration information in case the request was accepted by the second donor CU, the configuration information being related to one or more of the IAB nodes in the second IAB topology, the configuration information being used to identify a routing path for routing data packets between at least one IAB node of the first IAB topology and at least one IAB node of the second IAB topology,

Wherein the request sent to the second donor CU includes at least one of the following information elements, IE:

An IE indicating the expected throughput for the data to be routed,

An IE indicating the quality of service or QoS for the data to be routed,

An IE indicating the content of at least one previous routing identifier field for a routing identifier mapping table in case of routing data in an upstream direction and/or the content of at least one new routing identifier field for said routing identifier mapping table in case of routing data in a downstream direction.

52. The method of clause 51, wherein the configuration information received from the second donor CU includes 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 a border 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 border IAB node; an IE indicating a backhaul RLC channel identifier for an RLC channel used by the second donor CU to route data packets on an ingress backhaul link or on an egress backhaul link for the border IAB node in the secondary topology.

53. A computer program comprising instructions which, when executed by a processing unit, cause the processing unit to perform the method according to any of the preceding clauses.

54. A computer readable medium carrying a computer program according to clause 53.

55. An IAB node of an integrated access and backhaul communication system, i.e. an IAB communication system, the 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 according to any one of clauses 1-42.

56. A donor central unit, or donor CU, for managing processing of data packets in an integrated access and backhaul communication system, or IAB communication system, comprising at least two IAB topologies, each IAB topology comprising a plurality of IAB nodes and a donor central unit, or donor 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 according to any of clauses 43-52.

Claims

1. A method for processing data packets at an IAB node in an integrated access and backhaul communication system, i.e., an IAB communication system, the 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;

in response to determining to update the routing identifier:

2. The method of claim 1, wherein the received packet is a backhaul adaptation protocol packet, BAP, packet comprising a BAP header including the routing identifier.

3. The method of claim 1 or 2, wherein the header rewrite configuration information comprises a header rewrite configuration table including a field to indicate an IAB topology associated with the new route identifier.

4. The method according to any of the preceding claims, wherein determining whether to update the routing identifier before transmitting the data packet to another IAB node is based on routing configuration information and a received routing identifier of the data packet.

5. The method of any preceding claim, wherein the routing configuration information comprises a routing configuration table having at least one entry, each entry of the routing configuration table comprising:

a route identifier field for a route identifier, the route 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 route 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.

6. The method of any of claims 1-4, wherein the routing configuration information comprises a routing configuration table comprising: a route identifier field defining a route identifier, the route 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 route 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 additional field for use in determining whether to update the routing identifier of the received data packet.

7. The method of any of the preceding claims, further comprising: a backhaul RLC channel for the egress backhaul link is selected based on backhaul RLC channel mapping information and the identified IAB topology associated with the egress backhaul link.

8. The method of claim 7, wherein the backhaul RLC channel mapping information comprises a backhaul RLC channel mapping configuration table having at least one entry, each entry comprising:

9. The method of claim 8, wherein receiving a data packet comprises: the packet is received from the previous IAB node over the ingress BH link,

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 previous IAB node, an IAB topology associated with the previous IAB node, an address of the next IAB node, and an IAB topology associated with the next IAB node match respective fields of an entry in the backhaul RLC channel mapping configuration table; and

10. The method of claim 7, wherein the backhaul RLC channel mapping information comprises a backhaul RLC channel mapping configuration table having at least one entry, each entry comprising:

a traffic type identifier field for indicating a traffic type of a data packet to be routed;

11. The method of claim 10, wherein receiving a data packet comprises: generating the data packet in a portion of the IAB node and receiving the data packet at another portion of the IAB node 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 an IAB topology associated with the next IAB node match respective fields of an entry in the backhaul RLC channel mapping configuration table; and

12. The method of any preceding claim, wherein the header overwrite configuration information comprises a header overwrite configuration table having at least one entry, each entry of the header overwrite configuration table comprising:

A previous route identifier field for a route identifier;

a new route identifier field for the route identifier; and

A new topology field for indicating an IAB topology associated with a route identifier in the new route identifier field.

13. The method of claim 12, wherein each entry of the header overwrite configuration table further comprises a previous topology field for indicating an IAB topology associated with a route identifier in the previous route identifier field.

14. The method of claim 12 or 13, wherein the routing identifier of the received data packet comprises a destination address for a destination IAB node of the data packet, wherein identifying the new routing identifier and an IAB topology associated with a next IAB node to which the data packet is to be routed comprises:

Checking the header overwrite configuration table to determine whether the routing identifier of the received data packet matches the routing identifier in the previous routing identifier field of the entry or whether the destination address of the routing identifier of the received data packet matches the destination address in the destination address field of the entry; and

Upon determining to match an entry, the route identifier in the new route identifier field of the matching entry is used as the identified new route identifier and the IAB topology indicated by the new topology field of the matching entry is used as the identified IAB topology associated with the next IAB node.

15. The method of any of claims 8 to 14, wherein each topology field in the table includes a topology identifier that uniquely identifies one of the at least two IAB topologies.

16. The method of any of claims 4 to 15, wherein the new route identifier comprises a destination address of a destination IAB node for the data packet, wherein determining an egress backhaul link comprises:

checking a routing configuration table associated with the identified IAB topology to determine whether the identified new routing identifier matches a routing identifier in a routing identifier field of the entry or whether a destination address of the new routing identifier matches a destination address in a destination address field of the entry; and

When it is determined to match an entry, the next IAB node is determined using the next hop address in the next hop address field of the matching entry.

17. The method of any of the preceding claims, wherein the IAB node is a border node such that the IAB node is part of a first IAB topology of the at least two IAB topologies and is further 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, the method comprising:

identifying an IAB topology associated with the received data packet;

Determining whether the received data packet is to be delivered to an upper layer of the IAB node by comparing a destination address of the route identifier with one of the first address and the second address of the IAB node to check whether the destination address of the route identifier matches the one of the first address and the second address of the IAB node, wherein the one of the first address and the second address of the IAB node used in the comparing is an address associated with a topology identical to a topology associated with the received data packet.

18. The method of any of the preceding claims, wherein receiving a data packet comprises: the data packet is received from a previous IAB node over an ingress backhaul link,

The method further comprises the steps of: an IAB topology associated with the received data packet is determined by determining an IAB topology associated with the ingress backhaul link.

19. The method according to any of the preceding claims, wherein the IAB topology associated with the received data packet is one of the at least two IAB topologies and the IAB topology associated with the next IAB node to which the data packet is to be routed is the same or another of the at least two IAB topologies.

20. The method of any of the preceding claims, further comprising: the routing configuration information and the header overwrite configuration information are received from a donor control unit, donor CU, of at least one of the at least two IAB topologies.

21. A method for processing data packets at an IAB node in an integrated access and backhaul communication system, i.e., an IAB communication system, the IAB communication system comprising at least two IAB topologies, each IAB topology comprising a plurality of IAB nodes, the method comprising:

selecting a backhaul RLC channel for the egress backhaul link based on a backhaul RLC channel mapping configuration table;

22. The method of claim 21, wherein selecting the backhaul RLC channel for the egress backhaul link comprises:

23. A method for processing data packets at an IAB node in an integrated access and backhaul communication system, i.e., an IAB communication system, the IAB communication system comprising at least two IAB topologies, each IAB topology comprising a plurality of IAB nodes, the method comprising:

24. The method of claim 23, wherein selecting the backhaul RLC channel for the egress backhaul link comprises:

25. A method for managing processing of data packets in an integrated access and backhaul communication system, i.e., an IAB communication system, comprising at least two IAB topologies, each IAB topology comprising a plurality of IAB nodes and a donor central unit, i.e., a donor CU, the method comprising: at a first donor CU of a first IAB topology of the at least two IAB topologies,

Providing at least one IAB node of said first IAB topology with packet routing configuration information for routing packets through at least said first IAB topology, wherein said packet routing configuration information comprises a routing configuration table and a header overwrite configuration table,

Wherein the routing configuration table comprises at least one entry comprising: a route identifier field for a route identifier, the route 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 route path to the IAB node; a next hop address field for indicating the address of the next IAB node in the routing path identified by the path identifier,

Wherein the header overwrite configuration table comprises at least one entry comprising: a previous route identifier field for a route identifier; a new route identifier field for the route identifier; and a new topology field for indicating an IAB topology associated with a route identifier in the new route identifier field.

26. The method of claim 25, wherein the providing comprises: the routing configuration table is provided in a routing configuration information element, i.e. a routing configuration IE, for configuration messages transmitted to the at least one IAB node, and the header overwrite configuration table is provided in a header overwrite configuration information element, i.e. a header overwrite configuration IE, for configuration messages transmitted to the at least one IAB node.

27. A method for managing processing of data packets in an integrated access and backhaul communication system, i.e., an IAB communication system, comprising at least two IAB topologies, each IAB topology comprising a plurality of IAB nodes and a donor central unit, i.e., a donor CU, the method comprising: at a first donor CU of a first IAB topology of the at least two IAB topologies,

Providing, to at least one IAB node of the first IAB topology, packet routing configuration information for routing a packet through at least the first IAB topology, wherein the packet routing configuration information comprises a header overwrite configuration table comprising fields for indicating an IAB topology associated with a new routing identifier.

28. The method of any of claims 25-27, wherein the data packet routing configuration information further comprises a backhaul RLC channel mapping configuration table having at least one entry comprising:

29. A method for managing processing of data packets in an integrated access and backhaul communication system, i.e., an IAB communication system, comprising at least two IAB topologies, each IAB topology comprising a plurality of IAB nodes and a donor central unit, i.e., a donor CU, the method comprising: at a first donor CU of a first IAB topology of the at least two IAB topologies,

Providing, to at least one IAB node of the first IAB topology, packet routing configuration information for routing packets through at least the first IAB topology, wherein the packet routing configuration information comprises a backhaul RLC channel mapping configuration table having at least one entry comprising:

30. The method of any of claims 25-29, wherein the data packet routing configuration information further comprises an uplink traffic to backhaul RLC channel mapping configuration table having at least one entry comprising:

31. A method for managing processing of data packets in an integrated access and backhaul communication system, i.e., an IAB communication system, comprising at least two IAB topologies, each IAB topology comprising a plurality of IAB nodes and a donor central unit, i.e., a donor CU, the method comprising: at a first donor CU of a first IAB topology of the at least two IAB topologies,

32. The method of any of claims 28 to 31, wherein the providing comprises: the backhaul RLC channel mapping configuration table is provided in a routing configuration information element, i.e., a routing configuration IE, for a configuration message transmitted to the at least one IAB node.

33. The method of any of claims 25 to 32, further comprising:

Wherein providing the packet routing configuration information includes: the packet routing configuration information is provided based on configuration information received from the second donor CU.

34. A method for managing processing of data packets in an integrated access and backhaul communication system, i.e., an IAB communication system, comprising at least two IAB topologies, each IAB topology comprising a plurality of IAB nodes and a donor central unit, i.e., a donor CU, the method comprising: at a first donor CU of a first IAB topology of the at least two IAB topologies,

An IE indicating the expected throughput for the data to be routed,

An IE indicating the quality of service or QoS for the data to be routed,

35. The method of claim 34, wherein the configuration information received from the second donor CU includes at least one of the following information elements, IEs:

an IE identifying the at least one IAB donor DU in the second IAB topology;

An IE identifying an address of a border 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 border IAB node;

An IE indicating a backhaul RLC channel identifier for an RLC channel used by the second donor CU to route data packets on an ingress backhaul link or on an egress backhaul link for the border IAB node in the secondary topology.

36. A method for processing data packets at an IAB node in an integrated access and backhaul communication system, i.e., an IAB communication system, the IAB communication system comprising at least two IAB topologies, and each IAB topology comprising a plurality of IAB nodes, the method comprising:

(a) Receiving a data packet, the data packet including a routing identifier;

(b) Determining an IAB topology associated with the received data packet;

(G) Repeating at least step (c) for the update data packet.

37. The method of claim 36, wherein the repeating comprises: repeating steps (c) through (f) for at least one cycle for an update packet until it is determined that the update packet is to be delivered to an upper layer, or that there is an egress backhaul link for routing data, or that the routing identifier is not to be updated.

38. A computer program comprising instructions which, when executed by a processing unit, cause the processing unit to perform the method according to any of the preceding claims.

39. A computer readable medium carrying a computer program according to claim 38.

40. An apparatus of an IAB node of an integrated access and backhaul communication system, i.e. an IAB communication system, the IAB communication system comprising at least two IAB topologies, and each IAB topology comprising a plurality of IAB nodes, the apparatus comprising:

A processing unit; and

A memory operably connected to the processing unit and for storing instructions that, when executed by the processing unit, configure the processing unit to:

Before transmitting a data packet to another IAB node, determining whether to update a routing identifier of the received data packet,

In response to determining to update the routing identifier:

The update data packet is provided for transmission to the next IAB node over the egress backhaul link.

41. The device of claim 40, wherein the received packet is a backhaul adaptation protocol packet, BAP, packet comprising a BAP header including the routing identifier.

42. The apparatus of claim 40 or 41, wherein the header override configuration information comprises a header override configuration table including a field for indicating an IAB topology associated with the new route identifier.

43. The apparatus of any one of claims 40 to 42, wherein the routing configuration information comprises a routing configuration table having at least one entry, each entry of the routing configuration table comprising:

44. The apparatus of any one of claims 40 to 42, wherein the routing configuration information comprises a routing configuration table comprising: a route identifier field defining a route identifier, the route 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 route 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 additional field for use in determining whether to update the routing identifier of the received data packet.

45. The device of any of claims 40-44, wherein the instructions, when executed by the processing unit, configure the processing unit to: a backhaul RLC channel for the egress backhaul link is selected based on backhaul RLC channel mapping information and the identified IAB topology associated with the egress backhaul link.

46. The apparatus of claim 45, wherein the backhaul RLC channel mapping information comprises a backhaul RLC channel mapping configuration table having at least one entry, each entry comprising:

47. The apparatus of claim 46 wherein the data packet is received at the IAB node from a previous IAB node over an ingress BH link,

Wherein the processing unit is configured to select a backhaul RLC channel for the egress backhaul link by:

48. The apparatus of claim 45, wherein the backhaul RLC channel mapping information comprises a backhaul RLC channel mapping configuration table having at least one entry, each entry comprising:

49. The apparatus of claim 48, wherein the data packet is generated in one portion of the IAB node and received at another portion of the IAB node for transmission to another IAB node, wherein the processing unit is configured to select a backhaul RLC channel for the egress backhaul link by:

50. An IAB node of an integrated access and backhaul communication system, i.e. an IAB communication system, the IAB node comprising:

At least one communication interface for communicating with at least one IAB node;

a processing unit coupled to the at least one communication interface and configured to perform the method of any one of claims 1 to 24, 36 or 37.

51. A donor central unit, or donor CU, for managing processing of data packets in an integrated access and backhaul communication system, or IAB communication system, comprising at least two IAB topologies, each IAB topology comprising a plurality of IAB nodes and a donor central unit, or donor CU, the donor CU comprising:

At least one communication interface;

A processing unit coupled to the at least one communication interface and configured to perform the method of any one of claims 25 to 35.