Data routing in Integrated Access and Backhaul networks

Abstract

Routing of data in an Integrated Access and Backhaul network. In an Integrated Access and Backhaul (IAB) communication system including at least two IAB topologies, each IAB topology consisting of a plurality of IAB nodes, a method for processing a data packet at an IAB node includes receiving a data packet including a routing identifier, and determining whether the routing identifier should be updated before transmitting the data packet to another IAB node. In response to determining that the routing identifier should be updated, the method further includes: identifying a new routing identifier and an associated IAB topology based on the header rewrite configuration information of the received data packet and the routing identifier, 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 for routing the data packet to a next IAB node based on the identified IAB topology and the routing configuration information associated with the identified new routing identifier, and transmitting the updated data packet to the next IAB node via the egress backhaul link.

Description

Technical Field

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

Background Art

[0002] Wireless communication systems have been widely deployed to support a wide range of applications, from mobile broadband, massive machine-type communication to ultra-reliable low-latency communication (URLLC). Such systems allow multiple user equipment (UE) or mobile terminals to share a wireless medium and exchange multiple types of data content (e.g., video, audio, messaging, etc.) via a radio access network (RAN) through one or more base stations. Base stations have conventionally been wired-connected to a core network (through, e.g., fiber) to form an intermediate network called a backhaul (BH).

[0003] Such wireless multi-connectivity communication systems include, for example, systems based on 3rd Generation Partnership Project (3GPP (registered trademark)) standards such as the 4th generation (4G) Long-Term Evolution (LTE) or the recent 5th generation (5G) New Radio (NR) system, or systems based on IEEE802.11 standards such as WiFi.

[0004] Due to the increasing number of users and high throughput requirements, the demand for network densification is increasing.

[0005] As network density increases, the cost and time required to deploy wired backhaul networks become a problem. In response, 3GPP recently proposed wireless backhaul, also known as Integrated Access and Backhaul (IAB), in its 5G NR Release 16, where a portion of the wireless (i.e., radio) spectrum is used for backhaul connections of base station equipment instead of fiber. Wireless backhaul communication (between base stations) can use the same radio resources as access communication (between base stations and UEs).

[0006] IAB is a competitive alternative to fiber-based backhauling in densely populated or hard-to-cover areas.

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

[0008] However, millimeter waves are known to be susceptible to significant signal attenuation under certain weather conditions (rain, fog) and to blockage when there are obstacles in the path between the radiator and receiver.

[0009] To address these potential radio link failures, topology redundancy can be provided within the IAB framework, in which case multiple data paths are established between IAB base stations directly connected to the core network (also called "IAB donors") and IAB base stations providing services to UEs (also called "access IAB nodes" for UEs). Several intermediate IAB base stations (also called IAB nodes) may be involved in each of the multiple paths between the IAB donors and access IAB nodes, resulting in the formation of alternative data paths within the multi-hop IAB network.

[0010] A default path is defined through a set of IAB nodes, and it is desirable that data be transmitted along this path. Additionally, one or more backup paths are defined along different sets of IAB nodes that can be used in the event of a Radio Link Failure (RLF) on any of the links in the default path. The links are defined between two consecutive IAB nodes within the backhaul network. Backup paths are also useful when a link becomes congested due to excessive application traffic demands compared to the default link capacity. To mitigate congestion, traffic can be rerouted to the backup paths, or load balancing between the default path and one or more backup paths can be enabled.

[0011] Similar to gNBs, an 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 access IAB nodes) directly or indirectly connected to an IAB donor consists of an IAB-MT (IAB-Mobile Termination) that communicates in the uplink direction toward the IAB donor and an IAB-DU (IAB-Distributed Unit) that communicates in the downlink direction toward the UE.

[0012] To enable routing through multiple backhaul hops, a specific IAB protocol sublayer has been introduced, the backhaul adaptation protocol (BAP) sublayer, which is defined in TS38.340 (version 16.3.0) of the 3GPP Release 16 specification. There is one BAP entity for each IAB-MT, one BAP entity for each IAB-DU, and one BAP entity for each IAB donor DU. Each IAB node and each IAB donor DU is assigned a unique BAP address. The BAP sublayer encapsulates IP SDUs (Service Data Units) into BAP PDUs (Protocol Data Units), and each BAP PDU consists of a BAP header and a payload section containing the IP SDU.

[0013] The BAP header contains a BAP routing ID, which is a concatenation of the destination BAP address and the identifier (Path ID) of the backhaul route to be followed. The BAP routing ID is set by the BAP sublayer of the initiator's IAB donor DU (downstream) or the initiator's IAB node (upstream). Subsequently, BAP PDUs are routed according to the BAP routing ID at each IAB node and each IAB donor DU using the backhaul routing table set by the IAB donor CU. When a BAP entity receives a BAP PDU, the destination BAP address is compared to the local BAP address. If the local address matches the destination BAP address, the BAP header is removed and the payload is delivered to the upper layer.

[0014] For BAP entities within an IAB donor DU, if the destination BAP address does not match the local BAP address, the BAP PDU is discarded. For BAP entities in an IAB-MT or IAB-DU on an IAB node, if the destination BAP address does not match the local BAP address, the BAP PDU is delivered to a collated BAP entity for routing and transmission to the next hop. The backhaul routing table uses the BAP routing ID in the BAP PDU header as an entry in the table to provide the exit link corresponding to the next hop's BAP address. For example, if a specified exit link is unavailable due to a 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 routing ID or the destination BAP address in the BAP header, the BAP PDU is discarded.

[0015] According to the operation described for IAB, the 3GPP Release 16 specification does not allow rerouting a BAP PDU to a different IAB donor DU in the uplink direction, even if multiple IAB donor DUs provide connectivity to the same IAB donor CU. In fact, in the uplink direction, the destination BAP address of a BAP PDU corresponds to one of several available IAB donor DUs. Since IAB donor DUs have different BAP addresses, an IAB node can find alternative paths in its routing table to reach the targeted IAB donor DU by the destination BAP address, but it does not have the information to identify alternative IAB donor DUs that might be reachable through those alternative paths. Furthermore, if a BAP PDU were to reach an alternative IAB donor DU, this alternative IAB donor DU would discard the BAP PDU because its destination BAP address does not match its own BAP address.

[0016] Furthermore, 3GPP is considering donor-to-donor redundancy, where an IAB node, called a boundary IAB node, can access two different parent nodes connected to two different IAB donor CUs. A boundary IAB node can 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, even though it belongs to a single IAB network, i.e., a single IAB donor CU for configuration and management. The advantage of such donor-to-donor redundancy is that the first IAB donor CU can perform offloading by routing some of its BAP PDUs through the second IAB network, thereby mitigating congestion problems that may occur in the first IAB network or overcoming radio link failure problems.

[0017] However, because the assignment of BAP addresses, BAP path IDs, and backhaul radio link control channel identifiers (BH RLC CH IDs) is performed independently in each IAB network, the same values ​​may be assigned in each topology. For example, an IAB node belonging to the first IAB network may be assigned the same address as an IAB node belonging to the second IAB network, which can cause serious routing problems. For instance, if a boundary IAB node in the first IAB network has the same address as an IAB node in the second IAB network, when the boundary IAB node receives a BAP PDU with a header containing a destination BAP address matching its own address (and therefore the address of the IAB node in the second IAB network), it cannot determine whether the BAP PDU is for its own boundary IAB node and must be forwarded to the upper layer, or whether it is intended for an IAB node in the second IAB network and must be forwarded to the next hop. Similarly, an IAB node may reroute a BAP PDU to the wrong destination IAB node.

[0018] Therefore, a new mechanism is needed to overcome the aforementioned problems while limiting the complexity of processing at IAB nodes and the resulting latency. [Overview of the project]

[0019] According to a first aspect of the present invention, a method for processing data packets in an IAB node of an IAB communication system comprising at least two Integrated Access and Backhaul (IAB) topologies, each IAB topology comprising a plurality of IAB nodes, Receiving a data packet containing a routing identifier, Before sending a data packet to another IAB node, determine whether to update the routing identifier, In response to the determination that the routing identifier should be updated: Based on the header rewrite configuration information and the routing identifier of the received data packet, a new routing identifier and associated IAB topology are identified. To provide an updated data packet containing the identified new routing identifier, the received data packet is updated by updating the routing identifier of the received data packet with the identified new routing identifier, and Based on the identified IAB topology and the routing configuration information associated with the identified new routing identifier, the system determines the exit backhaul link to which data packets should be routed to the next IAB node. A method is provided that includes sending the updated data packet to the next IAB node via the exit backhaul link.

[0020] The present invention provides routing for data packets (such as Backhaul Adaptation Protocol (BAP) Protocol Data Units (PDUs)) over one or more Integrated Access Backhaul (IAB) networks or one or more IAB topologies, and thus enables the rerouting of data packets from a first IAB network (also called the first IAB topology) to a second IAB network (also called the second IAB topology). In the following description, the term IAB topology is used interchangeably with IAB network.

[0021] By first checking whether the routing identifier of an incoming data packet should be updated before identifying the exit backhaul link to which the data packet is routed to another IAB node, IAB nodes can avoid unnecessarily parsing all the routing configuration information and / or routing identifier mapping information (for example, unnecessarily parsing all routing identifiers in the routing identifier mapping information and / or routing configuration information if no matching routing identifier is found), thereby saving processing resources and processing time (which affects latency) when processing data packets for routing in an IAB communication system.

[0022] The example configuration includes an update (or rewrite) indication in the routing configuration information for each routing identifier (such as the update field or destination address field for each entry in the routing configuration table) to indicate whether the routing identifier should be updated. This allows the IAB node to decide whether to update the routing identifier without first having to parse all the information in the routing configuration information and without having to check whether there is an available exit backhaul link for each possible routing option. Furthermore, the IAB node has the flexibility to update the routing identifier of received data packets based on the current radio conditions and congestion (i.e., optimize the routing of data packets based on the current conditions). For example, if the IAB node updates the routing identifier of a received data packet and then detects that an exit link is unavailable in a second IAB topology, it can disable the update indication for this routing identifier in the routing configuration information, saving processing time when routing the next data packet with the same routing identifier.

[0023] In one example, the received data packet is a BAP data packet that has a Backhaul Adaptation Protocol (BAP) header containing a routing identifier.

[0024] Header rewrite configuration information (also known as routing identifier mapping information) may include a header rewrite configuration table containing fields for indicating the IAB topology associated with the new routing identifier.

[0025] In one example, the received data packet is a BAP data packet having a Backhaul Adaptation Protocol (BAP) header including a routing identifier, and the routing configuration information includes a backhaul routing configuration table including a field for indicating whether the BAP routing identifier of the received data packet is updated.

[0026] The routing identifier mapping information includes a routing identifier mapping table including a field indicating an IAB topology associated with the updated BAP routing identifier and / or a field indicating an IAB topology associated with the new routing identifier.

[0027] According to another aspect, in an Integrated Access and Backhaul (IAB) node of the IAB communication system according to any one of claims 21 to 24 of the appended claims, a method for processing a data packet is provided.

[0028] By providing the IAB node with a backhaul RLC channel mapping configuration table including a field for indicating a topology associated with the previous IAB node and the next IAB and / or a backhaul RLC channel mapping configuration table including a field for indicating a topology associated with the next IAB node, the IAB node can select and use a backhaul RLC channel that matches the required QoS to route the data packet to the next IAB node of the egress backhaul link, regardless of whether the next IAB node is in the same IAB topology as the IAB node or in a different IAB topology. In other words, by using the backhaul RLC channel mapping configuration table including a field indicating a topology, routing problems caused by independent allocation of BAP addresses, BAP path IDs, and backhaul radio link control channel identifiers (BH RLC CH IDs) in each IAB network where the same value can be assigned in each topology are alleviated.

[0029] In another embodiment, a method for managing the processing of data packets in an Integrated Access and Backhaul (IAB) communication system is provided, as described in claims 25 to 35 of the appended claims.

[0030] In another embodiment, a method is provided for processing data packets on an IAB node in an Integrated Access and Backhaul (IAB) communication system, as described in claim 36 of the appended claims.

[0031] Confirmation can be made to determine whether an updated data packet should be transported to a higher layer by determining whether the updated data packet should be transported to a higher layer (i.e., by updating the routing identifier of the received data packet with the determined new routing identifier and providing the updated data packet, thereby performing a determination on whether the data packet should be transported to a higher layer after the received data packet has been updated or rewritten). If no confirmation is made after the received data packet has been updated or rewritten, the data packet may be discarded even if it has reached the correct destination.

[0032] In another embodiment, an Integrated Access and Backhaul (IAB) node device according to claim 40 is provided.

[0033] According to another aspect of the present invention, an Integrated Access and Backhaul (IAB) node is provided as described in claim 50.

[0034] According to another aspect of the present invention, the donor central unit (CU) described in claim 51 is provided.

[0035] In another embodiment, an apparatus for an Integrated Access and Backhaul (IAB) communication system is provided, comprising at least two IAB topologies, each IAB topology comprising a plurality of IAB nodes and a donor central unit (CU). The device includes a processing unit and a memory for storing instructions that constitute the processing unit, which are operably connectable to the processing unit and, when executed by the processing unit, provide data packet routing configuration information for routing data packets through at least one IAB node of the first IAB topology, wherein the data packet routing configuration information includes a routing configuration table and a header rewrite configuration table, the routing configuration table having at least one entry including a routing identifier field for a routing identifier that includes a destination address field indicating the address of an IAB node and a path identifier field indicating the path identifier of a routing path to the IAB node, and a next hop address field indicating the address of the next IAB node in the routing path identified by the path identifier, the header rewrite configuration table having at least one entry including a preceding routing identifier field for a routing identifier, a new routing identifier field for a routing identifier, and a new topology field indicating the IAB topology associated with the routing identifier in the new routing identifier field.

[0036] In another embodiment, a donor central unit (CU) device for an IAB communication system is provided, comprising at least two Integrated Access and Backhaul (IAB) topologies, each IAB topology comprising a plurality of IAB nodes and a donor central unit (CU). The device comprises a processing unit and a memory for storing instructions that are operably connectable to the processing unit and, when executed by the processing unit, provide data packet routing configuration information for routing data packets through at least one IAB node of the first IAB topology, the first IAB topology, wherein the data packet routing configuration information comprises a header rewrite configuration table including a field for indicating the IAB topology associated with the new routing identifier.

[0037] In another embodiment, a device for a donor central unit (CU) of an IAB communication system is provided, comprising at least two Integrated Access and Backhaul (IAB) topologies, each IAB topology comprising a plurality of IAB nodes and a donor central unit (CU). The device comprises a processing unit and a memory for storing instructions constituting the processing unit, which are operably connectable to the processing unit and, when executed by the processing unit, provide data packet routing configuration information for routing data packets through at least one IAB node of the first IAB topology, via the first IAB topology, wherein the data packet routing configuration information is The next-hop address field for the next-hop address of the next IAB node following the at least one IAB node in the routing path, An exit topology field for indicating the IAB topology associated with the next IAB node, and for indicating the exit backhaul link between the IAB node and the next IAB node using the next hop address, The exit backhaul RLC channel identifier field for the backhaul RLC channel identifier for the exit backhaul link, and / or In the routing path, the preceding hop address field for the preceding IAB node's preceding IAB node, An inlet topology field for indicating the IAB topology associated with the preceding IAB node, and for indicating the inlet backhaul link between the IAB node and the preceding IAB node using the preceding hop address field, The inlet backhaul RLC channel identifier field for the backhaul RLC channel identifier of the inlet backhaul link, Includes a backhaul RLC channel mapping configuration table having at least one entry containing [the specified element].

[0038] In another embodiment, a first donor central unit (CU) device is provided for an IAB communication system comprising at least two Integrated Access and Backhaul (IAB) topologies, each IAB topology comprising a plurality of IAB nodes and a donor central unit (CU). The device comprises a processing unit and a device operably connectable to the processing unit and which, when executed by the processing unit, To establish routing of data packets between the first IAB topology and the second IAB topology for transmission to the second donor CU of the second IAB topology among the at least two IAB topologies, The second donor CU receives a response from the second donor CU that includes acknowledgment information indicating whether the second donor CU has accepted the request and when the second donor CU accepted the request, and configuration information relating to one or more IAB nodes in the second IAB topology for identifying routing paths for routing data packets between at least one IAB node in the first IAB topology and at least one IAB node in the second IAB topology. Thus, it has a memory for storing instructions that constitute the processing unit, The aforementioned requirement is, An IE that identifies the routing direction of the request, wherein if the routing direction is uplink, the request relates to the routing of data packets from the first IAB topology to the second IAB topology, and if the routing direction is downlink, the request relates to the routing of data packets from the second IAB topology to the first IAB topology. An IE that identifies at least one IAB donor distributed unit (DU) in the second IAB topology used by the first donor CU to transmit or receive data packets, A boundary IAB node for use in the second IAB topology, comprising an IE that identifies the address of the boundary IAB node, which is an IAB node in the first IAB topology connected to an IAB node in the second IAB topology, An IE indicating the destination of the data packet in the downstream direction, which is either a boundary node or another IAB node in the first IAB topology, IE, which shows the expected throughput of the data to be routed, IE, which indicates the quality of service (QoS) of the data to be routed, An IE indicating a backhaul RLC channel identifier ID for use by the first donor CU for the boundary IAB node in the inlet link when routing data in the upstream direction, and / or an IE indicating a backhaul RLC channel identifier ID for use by the first donor CU for the boundary IAB node in the exit link when routing data in the downstream direction, An IE showing the contents of at least one preceding routing identifier field for the header rewrite setting table when routing data in the upstream direction, and / or the contents of at least one new routing identifier field for the header rewrite setting table when routing data in the downstream direction, This includes at least one IE.

[0039] Further features of the present invention are characterized by other independent and dependent claims.

[0040] Features of one aspect of the present invention may be applied to other aspects of the present invention in any suitable combination. In particular, aspects of a method may be applied to aspects of an apparatus / device / unit, and vice versa.

[0041] Furthermore, functions implemented in hardware may also be implemented in software, and vice versa. References to software and hardware features in this specification should be interpreted accordingly. For example, according to another aspect of the present invention, a computer program is provided which, when executed by a processing unit, includes instructions causing the processing unit to perform the method described in any of the above aspects or examples, and a computer-readable storage medium for carrying the computer program.

[0042] Furthermore, it should be understood that specific combinations of the various features described and defined in any embodiment of the present invention may be independently implemented and / or supplied and / or used. [Brief explanation of the drawing]

[0043] Next, different aspects of the present invention will be described, only illustratively, with reference to the following drawings: [Figure 1] Figure 1 is a schematic diagram showing an exemplary wireless communication system in which the present invention may be implemented according to one or more embodiments. [Figure 2] Figures 2(a) and 2(b) are schematic diagrams showing the stack of several protocol layers related to the operation of the IAB. [Figure 3] Figure 3 is a schematic diagram showing the format of a BAP protocol data unit (PDU) or packet. [Figure 4] Figure 4 is a schematic diagram illustrating routing management in an IAB network. [Figure 5] Figures 5(a) to (d) show the fields of the routing table in an IAB node according to 3GPP TS38.300. [Figure 6] Figure 6 is a schematic diagram showing an example configuration of an IAB network system that presents network path diversity, in which the present invention may be implemented according to one or more embodiments. [Figure 7] This figure shows an example of fields in a routing configuration table in an IAB node according to an embodiment of the present invention. [Figure 8] This figure shows an example of fields in a routing identifier (Routing ID) mapping configuration table in an IAB node according to an embodiment of the present invention. [Figure 9a] Figure 9a shows an example of a field in the backhaul (BH) RLC channel mapping configuration table in an IAB node according to an embodiment of the present invention. [Figure 9b]Figure 9b shows an example of a field in the uplink traffic versus BH RLC channel mapping configuration table at an IAB node according to an embodiment of the present invention. [Figure 10] Figure 10 is a flowchart illustrating an exemplary method for managing BAP PDU routing across multiple IAB networks (or IAB topologies) according to an embodiment of the present invention. [Figure 11] Figure 11 is a schematic block diagram of an exemplary wireless communication device according to an embodiment of the present invention. [Figure 12] Figure 12 is a schematic and simplified diagram illustrating an exemplary message flow for managing BAP PDU routing across multiple IAB networks according to an embodiment of the present invention. [Figure 13] Figure 13 is a flowchart illustrating an exemplary method for processing data packets in an IAB node within an IAB system including multiple IAB networks (or IAB topologies) according to a first embodiment of the present invention. [Figure 14] Figure 14 is a flowchart illustrating an exemplary method for processing data packets in an IAB node within an IAB system including multiple IAB networks (or IAB topologies), according to a second embodiment of the present invention. [Figure 15] Figure 15 shows an example of fields in a synthesized configuration table in an IAB node according to an embodiment of the present invention. [Figure 16a] Figure 16a is a flowchart illustrating an exemplary method for managing the processing of data packets in an IAB system executed in a donor CU, according to an embodiment of the present invention. [Figure 16b] Figure 16b is a flowchart illustrating an exemplary method for managing the processing of data packets in an IAB system executed in a donor CU, according to an embodiment of the present invention. [Figure 17]Figure 17 is a flowchart illustrating another exemplary method for managing BAP PDU routing across multiple IAB networks (IAB topologies) according to an embodiment of the present invention. [Figure 18] Figure 18 is a flowchart illustrating another exemplary method for managing BAP PDU routing across multiple IAB networks (IAB topologies) according to an embodiment of the present invention. [Figure 19] Figure 19 is a flowchart illustrating an exemplary method for processing data packets in an IAB node within an IAB system including multiple IAB networks (or IAB topologies), according to a third embodiment of the present invention. [Modes for carrying out the invention]

[0044] Figure 1 shows an exemplary wireless communication system 100, in particular a mobile wireless communication system such as a fifth-generation (5G) New Radio (NR) system including a wireless Integrated Access and Backhaul network. While embodiments and examples of the present invention will be described in relation to a 5G NR system in the following description, it will be understood that the present invention is not intended to be limited to a 5G NR system and can be used in any wireless communication system having an integrated access and backhaul network that shares wireless resources for wireless access links and wireless backhaul links.

[0045] System 100 includes multiple User Equipment (UEs) 132, 133, 131, and 134, a remote core network 110, a main base station 120, and two Integrated Access and Backhaul (IAB) stations or IAB nodes 121 and 122 (hereinafter also referred to as IAB nodes).

[0046] The main base station 120, also called IAB donor 120 (or IAB-donor), is connected to the core network 110 via a wired link 101, which is preferably optical fiber or any other wired means. In embodiments and examples of the present invention, the IAB donor 120 is a 5G NR gNB with additional capabilities to support IAB functionality, as defined in the 3GPP TS38.300 v16.2.0 specification.

[0047] To extend the network coverage of IAB donor 120 and reach the remote UEs 132, 133, and 131, IAB stations 121 and 122, also known as IAB nodes 121 and 122, have been installed by the operator. IAB nodes 121 and 122 function as relay nodes between IAB donor 120 and UEs 132 and 133, overcoming reachability issues caused by the presence of building 108, which obstructs radio wave propagation, and enabling direct connections and further communication between the UEs and IAB donor 120. This is especially true when communication between IAB donor 120 and UEs 132 and 133 operates at millimeter-wave frequencies, which are highly sensitive to shadowing phenomena.

[0048] IAB Donor 120 also provides services to UE134, which is directly connected to IAB Donor 120.

[0049] Thus, IAB donor 120 and IAB stations 121 and 122 form a backhaul network or IAB network (also called an IAB topology) that accommodates UEs 132, 133, 131, and 134.

[0050] The Integrated Access and Backhaul (IAB) specification is: -TS38.300 RAN architecture (V16.4.0), -TS38.321 MAC protocol (V16.5.0), -TS38.331 Wireless Resource Control (RRC) Protocol (V16.5.0) -TS38.340 Backhaul Adaptive Protocol Layer (V16.3.0), -TS38.401 RAN architecture (V16.6.0), -TS38.473 F1 Application Protocol (V16.4.0) It spans multiple 3GPP standard documents, including [the relevant document].

[0051] Since IAB nodes 121 and 122 are connected to UEs 131, 132, and 133, respectively, they are considered access IAB nodes to the UEs they are connected to.

[0052] An IAB donor 120 is a logical node that provides NR-based radio backhaul and consists of a Central Unit (CU or gNB-CU function) and connected donor distributed units (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 to control 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, and physical layer protocols. The IAB donor CU or donor CU and the IAB donor DU or donor DU may be located in separate locations or may be located within the same physical device. The gNB-DU function is defined in 3GPP TS38.401. The gNB-DU function aims 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, as shown in Figures 2(a) and (b) below.

[0053] IAB nodes 121 and 122, which can provide multiple wireless sectors, are wireless backhauls to IAB donor 120 via one-hop or multi-hop through intermediate IAB nodes. These form a directed acyclic graph (DAG) topology with the IAB donor in their own routes.

[0054] Each IAB node consists of an IAB-DU and an IAB-MT (IAB-Mobile Termination). The gNB-DU function on an IAB node, also called IAB-DU, enables downlink connections (towards the UE) to the next-hop IAB. The IAB-MT function includes, for example, physical layer, Layer 2, RRC and NAS (Non-Access Stratum) functions to connect to the gNB-DU of an upstream IAB node (including IAB-donor 120, in which case it connects to the IAB donor gNB-CU, and therefore to the core network 110, for initialization, registration and configuration, for example).

[0055] In this DAG topology, adjacent nodes on the IAB-DU interface are called child nodes, and adjacent nodes on the IAB-MT interface are called parent nodes. Furthermore, the direction toward a child node is called downlink, and the direction toward a parent node is called uplink.

[0056] IAB Donor 120 (e.g., IAB Donor CU) centrally manages resources, topology, and routing across the entire IAB topology. This includes configuring IAB nodes according to the network topology, for example, to perform proper routing of data packets.

[0057] Figures 2(a) and (b) schematically show the stack of several protocol layers related to the operation of the IAB.

[0058] The F1 interface supports the exchange of signaling information between endpoints and the transmission of data to each endpoint. From a logical standpoint, the F1 interface is a point-to-point interface between endpoints.

[0059] In 5G NR, F1-C is the functional interface in the control plane (CP) between the IAB donor CU and the IAB node DU (such as IAB node 2), and between the IAB donor CU and the IAB donor DU. F1-U is the functional interface in the user plane (UP) for similar units. F1-C and F1-U are indicated by reference numeral 212 in Figure 2(a). In this example, F1-U and F1-C are transmitted via two backhaul hops (from the IAB donor to IAB node 1, and from IAB node 1 to IAB node 2).

[0060] In the user plane, box 210 of the IAB donor CU and IAB node DU refers to the GTP-U layer, and box 211 refers to the UDP layer. GTP-U stands for GPRS Tunneling Protocol User Plane. A GTP-U tunnel is used to transmit encapsulated PDUs and signaling messages between a given GTP-U tunnel endpoint pair (see 3GPP TS29.281 for details), which here is box 210 in the IAB donor CU and 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.

[0061] In the control plane, box 210 represents the F1AP (F1 Application Protocol) layer, and box 211 represents the SCTP (Stream Control Transmission Protocol) layer. The F1 Application Protocol (as defined in 3GPP TS38.473 and TS38.401) provides signaling services, or UE-related services, between IAB donor CUs and IAB node DUs. These services include, for example, initialization and configuration. The well-known SCTP layer provides reliable in-sequence transmission of messages with congestion control.

[0062] 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 TS38.401.

[0063] Transfers between IAB donor DUs and IAB donor CUs also use the IP transport layer over various media, such as wires or fiber optics, whether the IAB donor CU is far from the IAB donor DU or if the IAB donor CU and IAB donor DU are local in virtual instances on the same physical machine. IAB-specific transfers between IAB donor CUs and IAB donor DUs are specified in 3GPP TS38.401.

[0064] In Figure 2(a), L1 and L2 represent the transport layer and physical layer, respectively, that are suitable for the medium being used.

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

[0066] In wireless backhaul, the IP layer is transmitted over the Backhaul Adaptation Protocol (BAP) sublayer, which enables multi-hop routing. The BAP sublayer is defined in TS 38.340.

[0067] IAB-DU IP traffic is routed over the radio backhaul via the BAP sublayer. Downlink, upper-layer packets are encapsulated by the BAP sublayer of the IAB donor DU, forming a BAP packet or packet data unit (PDU) or data packet. BAP packets are routed by the BAP layer or entities (and corresponding BAP entities in IAB-DU and IAB-MT) of intermediate IAB nodes (also called transit nodes), if present. BAP packets are finally decapsulated by the BAP sublayer of the destination IAB node (which may be the access IAB node if the upper-layer packets of the BAP packet are destined for the UE).

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

[0069] In the BAP sublayer, packets are routed based on the BAP routing ID, which is included in the BAP header of the BAP packet and is set by the BAP sublayer of the sending IAB donor DU or initiator IAB node (e.g., the network node in the IAB network that generates the BAP packet). Figure 3 shows the format of the protocol data unit (PDU) or packet of BAP data. This is specified in paragraph 6.2 of the standardization version of 3GPP TS38.340 Release 16.3.0.

[0070] The payload section 307 is typically an IP packet. The header 30 includes fields 301 through 306. Field 301, named the 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 (ignored by the receiver).

[0071] Fields 305 and 306 both indicate the BAP routing ID for the BAP packet. The BAP address field 305, also called the DESTINATION field, is located in the leftmost 10 bits, while the BAP path identity field 306, also called the PATH field, is located in the rightmost 10 bits.

[0072] Field 305 carries the BAP address (i.e., on the BAP sublayer) of the destination IAB node or IAB donor DU for the BAP packet. For routing, each IAB node and IAB donor DU in the IAB network is configured (by the IAB donor CU of the IAB network) with the specified unique BAP address.

[0073] Field 306 carries a path ID that identifies the routing path that the BAP packet should follow to its destination in the IAB topology. For routing, the routing path, including the path ID, is configured at the IAB node (by the IAB donor CU of the IAB network).

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

[0075] For example, when a BAP packet is generated by a node, i.e., an IAB donor DU for downlink transmission or an initiator for uplink transmission (which could be an access IAB node if the upper-layer packet is coming from a UE), a BAP header with the BAP routing ID is constructed by this node according to a configuration table defined in 3GPP TS38.340. This table is called the "Downlink Traffic to Routing ID Mapping Configuration table" in the IAB donor DU and the "Uplink Traffic to Routing ID Mapping Configuration table" in the initiator IAB node. At the intermediate IAB node, the BAP header fields are already specified in the BAP packet to be forwarded.

[0076] As described above, these configuration tables that define BAP paths (and therefore routing strategies and IAB node configurations based on the IAB network topology) are typically defined by the IAB donor CU and sent to the IAB nodes for configuration.

[0077] The use of these tables (and other tables) for performing routing is described below with reference to Figures 5(a) to 5(d).

[0078] To transmit messages over the 5G NR wireless medium, each IAB node implements three additional sublayers (RLC, MAC, and PHY) beneath the BAP sublayer. The RLC (Radio Link Control) sublayer is responsible for packet segmentation and reconstruction, and also for requesting retransmission of missing packets. The RLC layer is further described in TS38.322. The MAC (Media Access Channel) protocol sublayer is responsible for selecting available transmission formats for user data and mapping logical channels to transport channels. MAC also handles part of the hybrid automatic retransmission request scheme. The MAC layer is further described in TS38.321. On the radiating or transmitting side, MAC encapsulates data packets issued from the RLC. MAC adds a header that carries the information necessary for MAC functionality. On the receiving side, MAC decapsulates data packets issued from the PHY, removes the header, and passes the remaining data to the RLC. The PHY sublayer provides an electrical interface to the transmission medium (air) by converting the information stream into a physically modulated signal on the radiating side and modulating the carrier frequency, and converts that physically modulated signal back into an information stream on the receiving side. The PHY layer is described in TS38.201, TS38.211, TS38.212, TS38.213, and TS38.214.

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

[0080] The PDCP sublayer handles IP header compression / decompression, encryption / decryption, and, if necessary, data packet integrity. The PDCP sublayer is obligatory to number packets on the radiating side and sort packets on the receiving side. The PDCP sublayer is described in 3GPP TS38.323.

[0081] The SDAP sublayer 220 for the user plane handles quality of service, as described in TS38.324. On the UE side, the SDAP sublayer exchanges payload data with the user's applications (voice, video, etc. - not shown). On the IAB donor CU side, the SDAP sublayer exchanges data with the core network 110 (internet traffic, cloud, etc.).

[0082] The control plane's RRC sublayer 220 handles the configuration of protocol entities in the user plane protocol stack, as described in TS38.331. The RRC sublayer 220 is responsible, among other things, for broadcasting information necessary for the UE to communicate with the cell, sending paging messages, connection management including bearer setup, mobility functions, measurement configuration and reporting, and device capability processing.

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

[0084] The interface between nodes (for both CP and UP) that uses the BAP, RLC, MAC, and PHY layers is called a BackHaul RLC channel (BH RLC channel). This is primarily related to interfaces between IAB nodes.

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

[0086] Figure 2(b), from 3GPP TS38.300 v16.4.0, shows the protocol stack for supporting IAB-MT RRC and NAS connectivity. The Non-Access Stratum (NAS) protocol handles messages between the core network and user equipment or IAB nodes. The NAS manages the establishment of communication sessions and maintains communication as IAB nodes or user equipment move. For 5G NAS, see 3GPP TS24.501. The 5G core Access and Mobility Management Function (AMF) is a function within the core network that receives all connectivity and session-related information from UEs connected to IAB nodes, and similar information from the IAB nodes. The AMF is solely responsible for handling connectivity and mobility management tasks.

[0087] The IAB-MT establishes an IAB donor CU and a signaling radio bearer SRB (a bearer that transmits RRC and NAS messages). These SRBs are transmitted between the IAB-MT and its parent node over the NR-Uu interface.

[0088] Figure 4 illustrates routing management in an IAB network. Routing management in an IAB node acting as a relay station attempts to determine, based on the BAP routing configuration, which BAP packet to forward from one BH RLC channel on one egress link or backhaul link (also called an egress backhaul link) to one BH RLC channel on a backhaul link to one BAP packet to one BAP packet to one BAP RLC channel on an egress link or backhaul link to one BAP RLC channel on an egress link to one BAP RLC channel on an egress link to one BAP RLC channel on an egress link to one BAP RLC channel on an egress backhaul ingress link or backhaul link to one BAP RLC channel on an ingress link or backha

[0089] BAP routing settings can be manually configured at each IAB node in the IAB network. Preferably, BAP routing settings are constructed by the IAB donor CU, updated over time, and transmitted by the IAB donor CU to the IAB nodes via F1AP signaling for their initial configuration and throughout the lifespan of the IAB network. As described above, BAP routing settings can be constructed by the IAB donor CU based on the topology of the IAB network and its changes over time (e.g., if some radio links are lost or recovered, or if link quality changes).

[0090] The BAP routing configuration of an IAB node includes various routing tables, four of which are shown in Figure 5.

[0091] Figure 5(a) schematically shows entry 500 of the backhaul routing configuration table, as defined in section 6.11.3 of 3GPP TS38.300, V16.4.0, for the BAP sublayer. This is used by the IAB node to select the exit link for forwarding or sending BAP packets or PDUs (Protocol Data Units) to the next-hop IAB node.

[0092] Field 501 defines the BAP routing ID (a concatenation of path field 5012 and destination field 5011, corresponding to path field 306 and destination field 305 as defined in Figure 3), and field 502 specifies the next-hop BAP address, i.e., the BAP address of the next IAB node along the path corresponding to routing ID 501. Thus, the next-hop BAP address 502 identifies the exit link for forwarding or transmitting BAP packets. The next-hop BAP address and exit link are synonymous, as they specify the same portion of the IAB network (radio link or backhaul link), respectively, between the current IAB node (e.g., an intermediate IAB node or relay IAB node) and the next IAB node having the next-hop BAP address. Therefore, for 3GPP Release 16 for 5G NR, they can be used interchangeably to specify the radio link or backhaul link of such an IAB network.

[0093] In the backhaul routing configuration table, there may be multiple entries in information element 502 that have the same destination BAP address but different path IDs and next-hop BAP addresses. The first entry in the backhaul routing configuration table may provide the default next-hop BAP address corresponding to the default path that reaches the destination, while other entries with the same destination BAP address relate to a backup redundant path that is selected when the default link becomes unavailable, for example, due to a radio link failure (RLF).

[0094] Figure 5(b) schematically shows entry 510 of the BH RLC channel mapping configuration table for the BAP sublayer, as defined in section 6.11.3 of 3GPP TS38.300 and / or section 5.2.1.4.1 of 3GPP TS 38.340, V16.3.0. This is used by an IAB node acting as a relay station (e.g., an intermediate IAB node) to identify a backhaul (BH) RLC channel for forwarding BAP packets or PDUs on an exit link pre-selected using the backhaul routing configuration table.

[0095] Information element (IE) 511 stores the next-hop BAP address, which is previously defined and usually obtained from the backhaul routing configuration table; IE512 stores the prior-hop BAP address, i.e., the BAP address of the IAB node to which the BAP packet originated; IE513 identifies the ingress RLC channel ID, i.e., the identifier of the RLC channel from which the BAP packet was received; and IE514 stores the outgress RLC channel ID that provides the RLC channel that the IAB node uses to forward the BAP packet.

[0096] The preceding hop BAP address and ingress link in IE512 are synonymous, as they respectively specify the same portion of the IAB network (radio link or backhaul link) between the current IAB node (e.g., an intermediate or relay IAB node) and the preceding IAB node having the preceding hop BAP address. Therefore, for 3GPP Release 16 of 5G NR, these can be used interchangeably to specify the radio link or backhaul link of such an IAB network.

[0097] For BH RLC channels in the downstream direction (from parent to child, for example, from IAB node 402 to IAB node 403 in Figure 4), the BH RLC channel ID is included in the F1AP settings of the BH RLC channel. For BH RLC channels in the upstream direction (from child to parent, for example, from IAB node 402 to IAB node 401), the BH RLC channel ID is included in the RRC settings of the corresponding logical channel.

[0098] Figures 5(c) and 5(d) show the equivalent BH RLC channel mapping configuration tables for IAB nodes that do not act as intermediate IAB relay entities. These are defined in sections 5.2.1.4.2 and 5.2.1.4.3 of 3GPP TS38.340.

[0099] The table in Figure 5(c) is called the Uplink Traffic vs. BH RLC Channel Mapping Configuration Table (520). This is used by an initiator IAB node (not an IAB donor DU) that has constructed BAP packets or PDUs from BAP SDUs (Service Data Units) received from a higher layer to identify a backhaul (BH) RLC channel for sending these packets uplink over the exit link previously selected using the backhaul routing configuration table described in Figure 5(a).

[0100] IE521 specifies the traffic type identifier of the SDU received from the upper layer, IE522 indicates the next-hop BAP address which is previously defined and usually obtained from the backhaul routing configuration table, and IE523 specifies the exit BH RLC channel identifier (ID) which provides the RLC channel that the IAB node uses to send BAP packets.

[0101] The table in Figure 5(d) is called the Downlink Traffic vs. BH RLC Channel Mapping Configuration Table 530. This is used by IAB donor DUs that have constructed BAP packets or PDUs from BAP SDUs (Service Data Units) received from higher layers to identify the backhaul (BH) RLC channel for sending these BAP packets downlink over the previously selected exit link using the backhaul routing configuration table.

[0102] IE531 is the IPv6 flow label used to classify IPv6 flows, IE532 specifies the DSCP (Differentiated Services Code Point) shown in the IPv6 header of a packet, IE533 indicates the destination IP address, IE534 indicates the next-hop BAP address defined above, and IE535 defines the exit BH RLC channel ID that provides the RLC channel used by the IAB node to send BAP packets.

[0103] The tables in Figures 5(b), 5(c), and 5(d) may consist of multiple rows (entries), each row / entry containing the IE (or field) shown in the respective figure.

[0104] All tables configured on the IAB node, particularly the routing ID of IE501, define multiple BAP paths that pass through multiple IAB nodes.

[0105] Returning to Figure 4, typically, the BAP sublayer of IAB node 402 routes BAP packets using the BAP routing IDs 305+306 of the BAP packets. The BAP address (DESTINATION path 305) is used for the following purposes: 1) In the BAP sublayer, it is determined whether the BAP packet has reached its destination node (IAB node or IAB donor DU). If the BAP address 305 in the packet's BAP header matches the BAP address configured via RRC at the IAB node or via F1AP at the IAB donor DU, then the BAP packet has reached its destination node. 2) Determine the next-hop IAB node for BAP packets that have not reached their destination. This applies to BAP packets that have arrived from a previous-hop IAB node via the BAP sublayer, or that have been received from a higher layer.

[0106] For packets arriving from a preceding hop or preceding IAB node, or from a higher layer, the determination of the next hop IAB node is based on the backhaul routing configuration table 500.

[0107] IAB node 402 resolves the next-hop BAP address 502 to either link 420 or link 430, which is a physical backhaul link. To do this, it searches for an entry in table 500 that has a field 501 that matches the BAP routing IDs 305+306 of the BAP packet. The corresponding field 502 provides the next-hop BAP address.

[0108] The backhaul routing configuration table may have multiple entries 500 that have the same destination BAP address but different BAP routing IDs (meaning different BAP path IDs). These entries may correspond to the same or different exit BH links. If the BH link matching the BAP routing ID of a BAP packet experiences a radio link failure (RLF), the IAB node can typically select a different exit BH link (next-hop BAP address) based on the routing entry with the same destination BAP address, i.e., by ignoring the BAP path ID. In this way, BAP packets can be delivered via an alternative path when the designated path is unavailable.

[0109] For example, if a wireless link failure occurs on BH link 420, IAB node 402 may select a different BAP routing ID that has the same destination BAP address but instead involves BH link 430.

[0110] Next, IAB node 402 derives the exit BH RLC channel of the selected exit BH link to which the BAP packet should be sent or forwarded. To do this, 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, or initiator IAB node or IAB donor DU sending in the uplink / upbound or downlink / downbound direction).

[0111] For example, in the case of an intermediate or relay IAB node, IE511, 512, and 513 are inputs, and IE514 is the output of the BH RLC channel lookup process: IAB node 402 routes an incoming BAP packet received from inlet BH RLC channel ID 513, which belongs to the inlet BH link identified by the preceding hop BAP address 512, to exit BH RLC channel ID 514, which belongs to the exit BH link that was previously selected and is now identified by the next hop BAP address 511.

[0112] For an initiator IAB node that wishes to send BAP packets uplink to an IAB donor, IE521 and 522 are inputs and IE523 is the output of the BH RLC channel lookup process: IAB node 402 selects an exit BH RLC channel 523 corresponding to table entry 520 where the traffic type identifier 521 matches the traffic type of the original BAP SDU and the next-hop BAP address 522 matches a previously selected next-hop BAP address using the backhaul routing configuration table. This applies to both control plane BAP SDUs (non-F1-U packets) and user plane BAP SDUs (F1-U packets). The traffic type identifier 521 must correspond to the destination IP address and TEID (Tunnel Endpoint Identifier) ​​of the BAP SDU.

[0113] For an IAB donor DU that wants to send a BAP packet downstream to a destination IAB node or UE, IE531, 532, 533, and 534 are inputs and IE535 is the output of the BH RLC channel lookup process: The IAB node selects an exit BH RLC channel 535 corresponding to table entry 530 that matches the destination IP address 533 of the original BAP SDU, the IPv6 flow label 531 (only for BAP SDUs that encapsulate IPv6 packets), and the Differential Services Code Point (DSCP) 532, and the next-hop BAP address 534 matches a previously selected next-hop BAP address using the backhaul routing configuration table. This applies to both control plane BAP SDUs (non-F1-U packets) and user plane BAP SDUs (F1-U packets).

[0114] If no matching entry is found, the default BH RLC ID channel may be selected.

[0115] Such routing processes can be performed at various IAB nodes in the IAB network.

[0116] Figure 6 shows an example of an IAB communication system (or configuration) 600 in which embodiments and examples of the present invention may be implemented to provide network path diversity through 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 in the millimeter-wave frequency band (i.e., above 30 GHz), which is highly sensitive to radio channel interference. Since an IAB network is also called an IAB topology or topology, the terms IAB network, IAB topology, and topology are used interchangeably in this application.

[0117] The IAB communication system 600 consists of two IAB networks or IAB topologies 691 and 692, each IAB topology including multiple IAB nodes or at least one IAB node. Multiple IAB nodes may include one or more initiator IAB donor DUs and one or more IAB nodes, such as initiator IAB nodes that generate BAP packets and intermediate or relay IAB nodes. Each IAB node communicates with at least one other IAB node via a radio 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 IAB donor CU 610 and its associated IAB donor DUs, IAB donor DU 601, IAB donor DU 602, and multiple IAB nodes 612 and 613, similar to IAB nodes 121 and 122. IAB topology 692 includes IAB donor CU620 and its associated IAB donor DU, IAB donor DU603, and IAB node 611, similar to IAB nodes 121 and 122. Although Figure 6 shows IAB topology 692 containing only one IAB node 611, it will be understood that IAB topology 692 may contain multiple IAB nodes, similar to IAB nodes 121 and 122. Furthermore, although Figure 6 shows two IAB topologies 691 and 692, the present invention is not limited to the two IAB topologies 691 and 692, and may be implemented in an IAB communication system having more than two IAB topologies, each topology containing multiple IAB nodes, as described above.

[0118] The wired backhaul IP network interconnects IAB donors CU610 and 620 and IAB donors DU601, 602, and 603 via routers 640 and 650, and links 641, 642, 643, 651, 652, and 660. For example, these wired links are composed of fiber optic cables.

[0119] IAB donor CU610, IAB donor DU601, IAB donor DU602, IAB node 612, and IAB node 613 are part of the same IAB network or IAB topology 691, configured and managed by IAB donor CU610.

[0120] IAB donor CU620, IAB donor DU603, and IAB node 611 are part of the same IAB network or IAB topology 692, configured and managed by IAB donor CU620. IAB network 692 is distinct from IAB network 691. IAB network 692 can be a neighbor or adjacent IAB network of IAB network 691.

[0121] IAB node 611 is connected to parent IAB donor DU603 via wireless BH link 634, and IAB node 613 is connected to parent IAB donor DU601 via wireless BH link 633.

[0122] IAB node 612 is connected to parent IAB donor DU602 via wireless BH link 631 and to child IAB node 613 via wireless BH link 632. Although IAB node 612 belongs to IAB network 691, it is also connected to IAB node 611 (which acts as the parent node of IAB node 612) via wireless BH link 635 because of its proximity to IAB network 692, particularly to IAB node 611. Because IAB node 612 belongs to IAB network 691 but is also connected to IAB node 611 which belongs to IAB network 692, it can be called a boundary node between IAB network 691 and IAB network 692. Since IAB node or boundary node 612 is part of IAB network 691, it is controlled (e.g., configured and managed) by IAB donor CU610 of IAB network 691. For example, the IAB donor CU610 configures boundary node 612 using configuration information during and outside of the initial setup to take into account changes / updates to the configuration / topology of IAB network 691 (and IAB network 692 which may affect the configuration of boundary node 612).

[0123] In one or more embodiments of the present invention, each IAB donor CU independently assigns BAP addresses within the IAB topology it controls. Boundary nodes, such as IAB node 612, are assigned two BAP addresses: one for topology 691 assigned by IAB donor CU 610 and one for topology 692 assigned by IAB donor CU 620. Since IAB node 612 is a boundary node belonging to IAB topology 691, IAB donor CU 610 may send both assigned BAP addresses to IAB node 612 using a configuration message, as described later. In addition or alternatively, IAB donor CU610 may send the BAP address for topology 691 assigned by IAB donor CU610 to IAB node 612 in a configuration message as described later (see, for example, Figure 12), and IAB donor CU620 may send the BAP address for topology 692 assigned by IAB donor CU620 to IAB node 612 using a configuration message as described later.

[0124] IAB donors DU601, 602, and 603, and IAB nodes 611, 612, and 613 serve UE627, 621, 622, 624, 623, 625, and 626, respectively, and therefore also function as access IAB nodes for each of those UEs.

[0125] For example, a downlink path from IAB donor CU610 to IAB node 613, a first default BAP path (PATH1) via IAB donor DU601, a second BAP path (PATH2) via IAB donor DU602, and a redundant path involving IAB node 612 may exist between pairs of IAB nodes. Symmetrically, there are also two uplink paths from IAB node 613 to IAB donor CU610, each involving the same node.

[0126] The BH radio link 633 between IAB node 612 and IAB donor DU601 may experience radio link loss due to unexpected interference or shadowing phenomena, such as radio link failure (RLF). Additionally, link 633 may become congested due to excessive data traffic.

[0127] For these reasons, IAB donor CU610 may decide, if possible, to reroute some BAP PDUs that were originally scheduled to be routed via PATH1, through an alternative path that does not go through BH radio link 633, such as PATH2.

[0128] In addition to RLF or congestion that degrades link 633, congestion (or RLF) may also exist simultaneously on link 631 between IAB node 612 and IAB donor DU602. Since IAB node 612 is a boundary node with respect to topology 692, IAB donor CU610 may decide to offload some BAP PDUs over an alternative path through topology 692. At the request of IAB donor CU610, IAB donor CU620 may configure IAB donor DU603 and IAB node 611 to route BAP PDUs for topology 691 toward boundary node 612. In other words, between IAB donor CU610 and IAB donor DU602, IAB nodes 611 and 612, and IAB node 613, there is a third BAP path (PATH3) that can be used to route data packets through multiple IAB topologies (i.e., IAB topology 691 and IAB topology 692) in the upstream and downstream directions, via BH radio links 634, 635 and 632. This use case is sometimes called inter-topology routing.

[0129] Considering the uplink transmission from IAB node 613 to IAB donor CU610, IAB node 613 may be configured by IAB donor CU610 to route the BAP PDU to IAB donor DU601 via link 633 by default (i.e., PATH1 is the default path), and as a backup, to route the BAP PDU to IAB donor DU602 via IAB node 612, via links 632 and 631 as a backup path (PATH2). If an RLF (or congestion) occurs on link 633, IAB node 613 may decide to reroute the BAP PDU using the backup path, PATH2. Boundary node 612 can be configured by IAB donor CU610 to route BAP PDUs to IAB donor DU602 via link 631 by default, and as a backup, as a backup path (PATH3), to route BAP PDUs to IAB donor DU603 via IAB node 611 through links 635 and 634. This latter use case may be called inter-topology rerouting. When rerouting to another donor DU within the same topology, this use case may be called inter-donor DU rerouting.

[0130] Next, processes for managing such rerouting or offload situations will be described according to some embodiments of the present invention. The following description applies to the routing of uplink or downlink data packets.

[0131] Figure 13 shows steps of an exemplary method 1300 for processing data packets according to a first embodiment of the present invention. Method 1300 is performed on an IAB node in an IAB communication system (or IAB configuration) having at least two IAB topologies, each containing multiple IAB nodes or at least one IAB node. For example, referring to the IAB communication system shown and described in Figure 6, the IAB node performing Method 1300 may be an IAB node in either 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 or is part of either the first IAB topology 691 or the second IAB topology 692. Furthermore, an IAB node may be an IAB donor DU (601, 602, 603, etc.) for data packets routed downstream, or an initiator IAB node for data packets routed upstream (for example, an initiator IAB node may be an IAB node that transmits data from the UE (i.e., acts as an access IAB node) or an IAB node that transmits control data from itself). The method shown and described therein may be implemented by software and / or hardware elements. An IAB node may be implemented in a communication device 1100 as shown and described therein in Figure 11, and the method shown and described therein in Figure 13 may be implemented by one or more processing units, such as a central processing unit 1111. For example, a program element executed by the CPU 1111 in Figure 11 for BAP entities (DU or MT portions) of a BAP sublayer may perform the method shown in Figure 13. The method in Figure 13 may be applied to routing upstream or downstream data packets.

[0132] In short, in step 1302, the IAB node receives a data packet (e.g., a BAP packet or BAP PDU). The data packet contains a routing identifier for routing the received data packet to the destination IAB node. The routing identifier may include the destination address of the destination IAB node for the data packet and a path identifier that identifies the routing path of the data packet to the destination IAB node. In one example, the data packet contains a header with a destination address and path identifier indicating the routing identifier (e.g., fields 305 and 306 of the BAP PDU in Figure 3). An IAB node may receive data packets from a preceding IAB node via an ingress BH link (i.e., the IAB node is a relay or intermediate IAB node such as IAB node 612 or IAB node 611), or an IAB node may generate data packets in a portion of its IAB node (such as a portion of the IAB node's BAP entity or a sublayer) and receive data packets generated in another portion of its IAB node (such as another portion of the IAB node's BAP entity or a sublayer) for routing to another IAB node. In the latter case, the IAB node is acting as an initiator IAB node.

[0133] The IAB topology associated with a received data packet is one of at least two IAB topologies, and the IAB topology associated with the next IAB node to which the data packet should be routed is either the same IAB topology or another one of at least two IAB topologies. For example, in Figure 6, IAB node 612 is part of or belongs to the first IAB topology 691, and when IAB node 612 receives a data packet for routing, it may route the data packet to the next IAB node in the first IAB topology 691 or the second IAB topology 692, depending on the routing identifier.

[0134] In step 1304, the IAB node determines the IAB topology associated with the received data packet. For example, when an IAB node receives a data packet from a preceding IAB node via an ingress BH link, the IAB node determines the IAB topology associated with the received data packet by determining the IAB topology associated with the preceding IAB node (and also associated with the ingress backhaul link). As will be discussed later with reference to Figure 10, the BAP sublayer of an IAB node can establish relationships between the BAP addresses, topologies, and backhaul links of parent or child IAB nodes, and these relationships can be used to determine the IAB topology associated with the received data packet. In an example where the IAB node is an initiator IAB node (for example, receiving data generated by the IAB node itself), the IAB node determines the IAB topology associated with the received data packet based on knowing which IAB topology it belongs to. For example, in the case of an initiator IAB node, the BAP routing identifier (ID) of the generated packet is indicated by a table (not shown) called the Uplink Traffic to Routing ID Mapping Configuration, described in section 5.2.1.2.1 of TS 38.340. The indicated BAP routing ID points to the topology to which the initiator IAB node belongs.

[0135] In step 1306, the IAB node determines, based on the routing configuration information associated with the determined IAB topology and the routing identifier of the received data packet, whether the routing identifier should be updated before routing the data packet to another IAB node. In one example, the routing configuration information is a routing configuration table (or backhaul routing configuration table or BAP routing configuration table), such as the routing configuration table shown and described therein in Figure 7. As described with reference to Figure 7, the routing configuration table 700 has at least one entry, each corresponding to an entry 500 in the backhaul routing configuration table in Figure 5a, and has an update field 703 (also called a rewrite field or header rewrite configuration field 703), which is an additional field for identifying whether the routing identifier of the entry should be updated (or rewritten). In another example described later, each entry in the routing configuration table may correspond to an entry 500 in the Backhaul routing configuration table in Figure 5a, but the routing configuration table is configured such that the next-hop address field having a specific value in at least part of the next-hop address field indicates that the routing identifier should be updated or rewritten. In one example, a specific value in either the update field or at least part of the next-hop address field of an entry indicates whether the routing identifier should be updated and the priority of that entry compared to another entry with the same routing identifier or destination address. In another example, a specific value in either the update field or at least part of the next-hop address field of an entry indicates whether the routing identifier of a data packet should be updated first (i.e., before attempting to route the data packet), updated as a backup option if no exit link is found after attempting to route the data packet, or not updated at all.

[0136] An IAB node may determine whether a routing identifier should be updated by determining whether there are routing options for the received data packet. For example, an IAB node may determine whether there are routing options for the received data packet in the routing configuration table by checking 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. In response to determining a match with an entry in the routing configuration table, the IAB node determines whether the routing identifier should be updated by checking the values ​​of at least some of the update fields (e.g., field 703) or the next-hop address field of the matched entry. The IAB node may determine that the routing identifier should be updated if the value of update field 703 indicates that the routing identifier should be updated or rewritten, or if the value of at least some of the next-hop address field corresponds to a specific value that indicates that the routing identifier should be updated or rewritten.

[0137] Based on the routing identifier of the received data packet, an IAB node may determine whether the current exit backhaul link is RLF or congested, and then decide whether to update the routing identifier.

[0138] If an IAB node determines that it should update a routing identifier, in step 1308, the IAB node identifies a new routing identifier and the IAB topology associated with that new routing identifier (for example, the IAB topology associated with the next IAB node (exit backhaul link) determined by the new routing identifier) ​​based on the routing identifier mapping information and the routing identifier of the received data packet. In one example, the routing identifier mapping information is a routing identifier mapping table (or BAP routing identifier mapping table) containing at least one entry, each entry containing a field for indicating the IAB topology associated with the routing identifier to be updated, and / or a field for indicating the IAB topology associated with the new routing identifier.

[0139] For example, a routing identifier mapping table may include a preceding routing identifier field for a routing identifier, a preceding topology field for indicating the IAB topology associated with the routing identifier in the preceding routing identifier field, a new or next routing field for a routing identifier, and a new topology field for indicating the IAB topology associated with the routing identifier in the new routing identifier field, where alternative routing options (e.g., at least one redundant path) are available. In one example, the routing identifier mapping table is the routing identifier mapping table shown and described in Figure 8. An IAB node may identify a new routing identifier and the IAB topology associated with that new routing identifier (e.g., the exit backhaul link to which the data packet is routed) by checking the routing identifier mapping table and determining whether the routing identifier of the received data packet matches the routing identifier in the preceding 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. If an IAB node determines that an entry matches, the IAB node uses the routing identifier in the matching entry's new routing identifier field as the identified new routing identifier, and the IAB topology indicated by the matching entry's new topology field as the identified IAB topology associated with the new routing identifier. The IAB topology information in the topology field provides an indication of whether the data packet will be routed to the same IAB topology or to a different IAB topology.

[0140] As will be discussed later with reference to Figures 7, 8, and 15, the fields in the routing configuration table may be combined with the fields in the routing identifier mapping table within a single table. The routing configuration table and routing identifier mapping table may be configured by the IAB donor control unit CU of the first topology (e.g., IAB donor CU610) and / or the IAB donor control unit CU of the second topology (e.g., IAB donor CU620) using F1AP protocol messages (such as BAP mapping configuration messages). An example of how IAB nodes can be configured is described below with reference to Figure 12.

[0141] In 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, in order to provide an updated data packet containing the identified new routing identifier. For example, the routing identifier of the received data may be replaced or rewritten with the new routing identifier.

[0142] In step 1312, the IAB node determines the next IAB node to which the data packet should be routed (for example, the exit backhaul link to which the data packet should be routed) based on the identified IAB topology associated with the new routing identifier and the routing configuration information associated with that identified new routing identifier. In other words, the IAB node looks up routing options for the received data packet based on the identified IAB topology and the routing configuration information associated with the identified new routing identifier.

[0143] An IAB node may determine the next IAB node by checking the routing configuration table associated with the identified IAB topology (associated with the exit backhaul link) to determine whether the identified new routing identifier matches the routing identifier in the entry's routing identifier field, or whether the destination address of the new routing identifier matches the destination address in the entry's destination address field. If an IAB node finds a match with an entry, it uses the next-hop address in the next-hop address field of the matching entry to determine the next IAB node.

[0144] The order of entries in a routing configuration table that have the same routing identifier or destination address may indicate the priority of the entries. In such cases, checking the routing configuration table (for example, when checking the table to determine whether the routing identifier of a received data packet should be updated, or when checking the table to determine the next IAB node) may involve checking the entries according to their priority.

[0145] In step 1314, the IAB node routes the updated data packet to the next IAB node via the exit backhaul link.

[0146] Method 1300 may further include determining whether an exit backhaul link is available (e.g., whether an RLF or congestion is detected), and provided that an exit backhaul link is available, the data packet is routed through the exit backhaul link to the next IAB node. If an RLF or congestion is detected, the routing identifier of the received data packet is not updated, the new routing identifier of the updated data packet is updated, or it is overwritten with the original routing identifier of the received data packet.

[0147] The IAB node does not need to perform method 1300 in the order shown in Figure 13. For example, the updating step 1310 may be performed before or after the determining step 1312, or substantially simultaneously with the determining step 1312.

[0148] As will be described later with reference to Figure 10, if an IAB node decides not to update the routing identifier, the data packet is routed to the next IAB node via the exit backhaul link, provided that the exit backhaul link is identified and available (e.g., free from RLF or congestion).

[0149] Method 1300 may further include selecting a backhaul RLC channel for an exit backhaul link based on an identified IAB topology associated with the next IAB node (which is also associated with an exit backhaul link) and backhaul RLC channel mapping information. In one 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 and described in relation to Figure 5(b) or Figure 5(c) or Figure 9a or Figure 9b. In another example, the BH RLC channel mapping information may provide information as shown in Figure 5(b) or Figure 5(c), where fields 511 and 522 indicate the identifier of the exit link and field 512 indicates the identifier of the inlet link. In this case, the inlet link identifier and the exit link identifier indicate both the link and the topology (primary / MCG or secondary / SCG).

[0150] When an IAB node receives data packets from a preceding IAB node via an ingress backhaul link, the BH RLC channel mapping configuration table corresponds to the table described with respect to Figure 5(b) or Figure 9a. In the case of the BH RLC channel mapping configuration table in Figure 9a, selecting a backhaul RLC channel for an egress backhaul link may involve checking whether the backhaul RLC channel ID of the ingress backhaul link, the address of the preceding IAB node, the determined IAB topology associated with the preceding IAB node (e.g., the ingress backhaul link), 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. If a match is determined, the backhaul RLC channel for the egress backhaul link is selected using the egress backhaul RLC channel ID of the matched entry.

[0151] When an IAB node receives data packets generated by that IAB node (for example, if the IAB node is the initiator node), the BH RLC channel mapping configuration table corresponds to the table described with respect to Figure 5(c) or Figure 9b. In the case of the BH RLC channel mapping configuration table in Figure 9b, selecting a backhaul RLC channel for an exit backhaul link may involve checking the backhaul RLC channel mapping configuration table to determine if the traffic type of 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 exit backhaul link) match the respective fields of the entity in the backhaul RLC channel mapping configuration table. If a match is determined, the backhaul RLC channel for the exit backhaul link is selected using the exit backhaul RLC channel ID of the matched entry.

[0152] Processing resources and processing time (which affects latency) can be saved by first checking whether the routing identifier of the received data packet should be updated before routing the data packet to another IAB node, for example by having an update / rewrite identifier for each entry in the routing configuration table, and determining whether the routing identifier should be updated, updating the routing identifier if it is determined that the routing identifier should be updated, and determining the next IAB node based on the updated routing identifier (i.e., by checking the update field 703 or the destination address field to recognize whether the routing identifier of the entry should be updated). Processing resources and processing time can be saved by avoiding unnecessary parsing of all entries in the routing identifier mapping table and / or routing configuration table by the IAB node (for example, when an entry for the corresponding routing identifier is not found). For example, if a boundary node receives a data packet with an alias BAP address, following the decision that the routing identifier of the received data packet should be updated using the routing configuration table, the IAB node can directly check the routing identifier mapping table without continuing to parse the routing configuration table, thus avoiding unnecessary parsing of the routing configuration table. For example, if there is no entry for the routing identifier of a received data packet, unnecessary parsing of the routing identifier mapping table can be avoided, and after determining that there are no available exit BH links via the routing configuration table, there is no need to parse the routing identifier mapping table. Furthermore, the IAB node has the flexibility to update the routing identifier of received data packets based on the current radio conditions and congestion (i.e., optimize the routing of data packets based on the current conditions).For example, if an IAB node detects that the exit link is unavailable in a second IAB topology after rewriting a BAP routing identifier, it can disable the rewrite indication for that routing identifier in the routing configuration table, saving processing time when routing the next BAP data packet with the same BAP routing identifier.

[0153] Figure 14 shows steps of an exemplary method 1400 for processing data packets according to a second embodiment of the present invention. Method 1400 is performed on an IAB node of an IAB communication system (or IAB configuration) having at least two IAB topologies, each containing multiple IAB nodes or at least one IAB node. For example, referring to the IAB communication system shown and described in Figure 6, an IAB node performing method 1400 may be an IAB node in either a first IAB topology (or first IAB network) 691 or a second IAB topology (or second IAB network) 692. In other words, an IAB node belongs to or is part of either the first IAB topology 691 or the second IAB topology 692. Furthermore, an IAB node may be an IAB donor DU (601, 602, 603, etc.) for data packets routed in the downlink direction, or an initiator IAB node for data packets routed in the uplink direction (for example, an initiator IAB node may be an IAB node that transmits data from the UE (i.e., acts as an access IAB node) or an IAB node that transmits control data from itself). The method shown and described therein may be implemented by software and / or hardware elements. An IAB node may be implemented in a communication device 1100 shown and described with reference to Figure 11, in which one or more processing units, such as a central processing unit 1111, perform the method shown and described therein. For example, a program element executed by the CPU 1111 in Figure 11 for BAP entities (DU or MT portions) of a BAP sublayer may perform the method shown in Figure 14. The method in Figure 14 may be applied to routing data packets in the uplink or downlink direction.

[0154] In short, in step 1402, the IAB node receives a data packet (e.g., a BAP packet or BAP PDU). The data packet contains a routing identifier for routing the received data packet to the destination IAB node. The routing identifier may include the destination address of the destination IAB node for the data packet and a path identifier that identifies the routing path of the data packet to the destination IAB node. In one example, the data packet includes a header that has a destination address and a path identifier that together indicate the routing identifier (e.g., fields 305 and 306 of the BAP PDU in Figure 3). An IAB node may receive data packets from a preceding IAB node via an ingress BH link (i.e., the IAB node is a relay node or intermediate IAB node such as IAB node 612 or IAB node 611), or an IAB node may generate data packets in a portion of the IAB node (such as a portion of the BAP entity or sublayer of the IAB node) and receive the generated data packets in another portion of the IAB node (such as another portion of the BAP entity or sublayer of the IAB node) for routing to another IAB node. In the latter case, the IAB node acts as an initiator IAB node.

[0155] In step 1403, the IAB node determines the IAB topology associated with the received data packet. For example, if an IAB node receives a data packet from a preceding IAB node via an ingress BH link, the IAB node determines the IAB topology associated with the received data packet by determining the IAB topology associated with the preceding IAB node (which is also associated with the ingress backhaul link). As will be discussed later with reference to Figure 10, the BAP sublayer of an IAB node can establish relationships between the BAP addresses, topologies, and backhaul links of parent or child IAB nodes, and these relationships can be used to determine the IAB topology associated with the received data packet. In one example, if an IAB node is an initiator IAB node (for example, receiving data generated by the IAB node itself), the IAB node determines the IAB topology associated with the received data packet based on knowing which IAB topology the IAB node belongs to. For example, in the case of an initiator IAB node, the BAP routing identifier (ID) of the generated packet is indicated by a table (not shown) called the Uplink Traffic vs. Routing ID Mapping Configuration, described in Section 5.2.1.2.1 of TS38.340. The indicated BAP routing ID refers to the topology to which the initiator IAB node belongs. Step 1403 may be omitted if the data packet is received from a higher layer (for example, if 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 described with respect to Figure 9b.

[0156] In step 1404, the IAB node determines the exit backhaul link to which the data packet should be routed to the next IAB node, based on the routing identifier of the received data packet. In other words, the IAB node explores routing options for the received data packet based on the routing identifier of the received data packet. The IAB node may determine the exit backhaul link to which the data packet should be routed to the next IAB node by determining the address of the next IAB node, by using the routing identifier or the destination address of the routing identifier (for example, as input) to check a backhaul routing configuration table, such as the backhaul routing configuration table in Figure 5(a) or the routing configuration table in Figure 7. The backhaul routing configuration table has at least one entry, and each entry in the routing configuration table includes at least a routing identifier field for the routing identifier and a next-hop address field for indicating the address of the next IAB node in the routing path identified by the path identifier of the routing identifier. If a match is found with an entry in the backhaul routing configuration table (a routing option for the incoming data packet is found), the IAB node determines the exit backhaul link based on the address of the next IAB node determined to match the entry.

[0157] If there is no match with the entries in the backhaul routing configuration table (i.e., no routing options are found for the received data packet), the method may further include initiating a process to update or rewrite the routing identifier (for example, in the header of the received data packet if header updating / rewriting is permitted). As part of the rewriting process, the IAB node checks the routing identifier mapping table using the routing identifier of the received data packet, and if there is a match with the entries in the routing identifier mapping table, the IAB node determines the new routing identifier of the received data packet based on the new routing identifier of the matched entry. The routing identifier mapping table includes at least a preceding routing identifier field for the routing identifier and a new routing identifier field for the routing identifier for which alternative routing options (e.g., at least one redundant path) are available. The routing identifier mapping table may include a table such as the one shown and described in Figure 8. The IAB node then updates or rewrites the routing identifier of the received data packet with the new routing identifier and provides an updated data packet containing the identified new routing identifier. The IAB node determines the address of the next IAB node by checking the backhaul routing configuration table using the new routing identifier or the destination address of the new routing identifier, and if there is a match with the entry in the backhaul routing configuration table, it determines the exit backhaul link to which the data packet will be routed to the next IAB node by determining the exit backhaul link based on the determined next IAB node address of the matched entry.

[0158] In step 1406, the IAB node determines the IAB topology associated with the next IAB node (for example, the IAB topology associated with the exit BH link through which the data packet is routed to the next IAB node). If the routing identifier has not been updated in step 1404, the IAB topology of the next IAB node is the same as the IAB topology associated with the received data packet. If the routing identifier has been updated in step 1404, the IAB topology associated with the next IAB node may be determined from a routing identifier mapping table, as shown and described in Figure 8.

[0159] In step 1408, the IAB node selects a backhaul RLC channel for the exit backhaul link based on the determined IAB topology and backhaul RLC channel mapping configuration table associated with the next IAB node. In one 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 and described in relation to Figure 9a or Figure 9b. Instead of a BH RLC channel mapping configuration table having fields 911, 912, and 922 indicating the exit / inlet topology, as shown and described in Figures 9a and 9b, the BH RLC channel mapping information may provide information as shown in Figure 5(b) or Figure 5(c), where fields 511 and 522 indicate the exit link identifier and field 512 indicates the inlet link identifier. In this case, the inlet link identifier and the exit link identifier indicate both the link and the topology (primary / MCG or secondary / SCG).

[0160] When an IAB node receives data packets from a preceding IAB node via an ingress backhaul link, the BH RLC channel mapping configuration table corresponds to the table described with respect to Figure 9a. Selecting a backhaul RLC channel for an egress backhaul link may involve checking the backhaul RLC channel mapping configuration table to determine if the backhaul RLC channel for the ingress backhaul link, the address of the preceding IAB node, the determined IAB topology associated with the preceding IAB node (e.g., the ingress backhaul link), 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. If a match is determined, the backhaul RLC channel for the egress backhaul link is selected using the egress backhaul RLC channel ID of the matching entry.

[0161] When a data packet is received from a higher layer (for example, if the IAB node is the initiator node that generated the packet), the BH RLC channel mapping configuration table corresponds to the table described with respect to Figure 9b. Selecting a backhaul RLC channel for an exit backhaul link may involve checking the backhaul RLC channel mapping configuration table to determine if the traffic type of 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 exit backhaul link) match the respective fields of the entity in the backhaul RLC channel mapping configuration table. If a match is determined, the backhaul RLC channel for the exit backhaul link is selected using the exit backhaul RLC channel ID of the matched entry.

[0162] In step 1410, the IAB node routes the updated data packet to the next IAB node via the exit backhaul link.

[0163] Although not shown in Figure 14, method 1400 may further include determining whether an exit backhaul link is available (e.g., whether an RLF or congestion is detected), and provided that an exit backhaul link is available, the data packet is routed through the exit backhaul link to the next IAB node. If an RLF or congestion is detected and the exit backhaul link is unavailable, the method may return to step 1404 and determine the exit BH link based on checking the routing configuration table for another entry using the routing identifier or destination address of the routing identifier of the received data packet.

[0164] Next, refer to Figure 7. Figure 7 shows an example of entries in a routing configuration table 700 in an IAB node according to an embodiment of the present invention, having at least one entry 710, 711, 712. Entry 710 in the routing configuration table 700 corresponds to entry 500 in the backhaul routing configuration table of Figure 5(a) and has an additional field, update field 703 (also called rewrite field 703), to identify whether the routing identifier of the entry is updated (or rewritten). The other fields of the backhaul routing configuration table of Figure 5(a), routing ID field 501 (including destination address field 5011 and path identifier field 5012), and next-hop BAP address field 502 are shown in Figure 7 and are specified using the same reference numbers as in Figure 5(a).

[0165] An IAB node acting as a boundary node (such as IAB node 612) may have a routing configuration table, such as the routing configuration table 700 shown and described with reference to Figure 7, for the IAB topology to which the IAB node actually belongs (e.g., topology 691 for IAB node 612), also called the primary or first topology, and one routing configuration table for each of the other topologies to which the IAB node is connected (e.g., topology 692 for IAB node 612), also called the secondary or second topology.

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

[0167] In another example, the routing configuration table 700 for the primary topology is configured by the IAB donor CU that manages the primary topology of the IAB node, and the routing configuration table 700 for the secondary topology is configured by the IAB donor CU that manages the secondary topology of the IAB node. For example, in the case of IAB node 612, the routing configuration table 700 for IAB topology 691 (the primary topology) is configured by IAB donor CU 610, and the routing configuration table 700 for IAB topology 692 (the secondary topology) is configured by IAB donor CU 620.

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

[0169] The configuration of the routing configuration table 700 in the IAB node will be described later with reference to Figure 12.

[0170] For boundary nodes (such as IAB node 612 in Figure 6), the next-hop BAP address field 502 of the entry in the routing configuration table 700 for a particular IAB topology (primary or secondary topology) is therefore associated with that particular IAB topology (primary or secondary topology). For a single routing configuration table 700, which is a combination of separate routing configuration tables for each topology, the next-hop BAP address field 502 of the entry in the single routing configuration table 700 for a particular IAB topology (primary or secondary topology) is therefore associated with that particular IAB topology (primary or secondary topology). Thus, the next-hop BAP address field 502 and the associated topology define a unique exit link (or exit BH link).

[0171] Figure 7 schematically shows some entries 711 and 712, such as entry 710, of a backhaul routing configuration table 700 according to some embodiments of the present invention.

[0172] As mentioned above, field 703, in addition to fields 501 and 502, defines an update or rewrite field, which indicates whether to update the routing identifier.

[0173] If an exit BH link identified by the destination address in the destination field 5011 and the path identifier in the path field 5012 of an entry in the routing configuration table 700 is unavailable, and the entry in the routing configuration table 700 has the same routing identifier in the routing ID field 501, or has the same destination address in the destination field 5011 (i.e., has the same destination address as the destination address that identifies the unavailable exit BH link), then the rewrite field 703 may indicate an alternative routing identifier. If the rewrite field 703 has the same destination address as the destination address that identifies the unavailable exit BH link, and indicates that the routing identifier will be updated, then the rewrite field 703 may indicate that an alternative route is available with an alternative exit BH link that requires rewriting fields 305 and 306 of the BAP header of the received data packet. The alternative exit BH link may be determined using routing identifier mapping information, such as the routing identifier (ID) mapping table 800, as shown and described with reference to Figure 8.

[0174] In one example, an RLF (Rapid Load Factor) occurring on the link could render the exit BH link unavailable. In another example, congestion could render the exit BH link unavailable.

[0175] In one example, the rewrite field 703 carries information indicating whether an alternative exit BH link is available by rewriting the BAP header. For example, the rewrite field 703 can be a 1-bit field. In one example, setting the rewrite field to "1" (or "0") can be used to indicate that the routing identifier should be updated (and that an alternative path with an alternative exit BH may be available), and setting the rewrite field to "0" (or "1") can be used to indicate that the routing identifier should not be updated (and that an alternative path with an alternative exit BH is not available). Furthermore, the rewrite field 703 may carry some priority information (for example, the number in the rewrite field 703 of an entry can be used to indicate the priority of that entry by comparing it to another entry with a different number in the rewrite field 703), indicating whether the IAB node should consider an exit BH link determined using the routing ID mapping table 800 before or after another alternative exit BH link associated with another entry in the routing configuration table 700 whose destination field 5011 matches the destination field 305 of the BAP header of the received data packet. The priority indicated by the rewrite field 703 can be used to indicate the order in which alternative exit BH links should be considered (e.g., a first alternative and one or more additional backup alternatives in terms of priority). In another example, the rewrite field 703 may indicate whether the routing identifier of a data packet should be updated first (i.e., before attempting to route the data packet), updated as a backup option in case no exit link is found after attempting to route the data packet, or not updated at all.

[0176] In the example shown in Figure 7, the routing configuration table 700 includes a field 703 for update or rewrite fields, which are additional fields 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 in Figure 5(a). In another example, each entry in the routing configuration table may have a routing ID field 501 (including the destination address field 5011 and the path identifier field 5012) and a next-hop BAP address field 502 of the backhaul routing configuration table in Figure 5(a), where a specific value in at least part of the next-hop address field or the next-hop BAP address field 502 indicates that the routing identifier should be updated. For example, a rewrite field may be indicated by a specific or predetermined value (e.g., a reserved address value) in the next-hop BAP address field 502 reserved for this use, which can be used to indicate that the routing identifier should be updated (and that an alternative path with an alternative exit BH may be available), such as the value "0". In another example, certain values ​​in part of the next-hop BAP address field 502, such as one or more of the most significant bits of the next-hop BAP address field 502, can be used to indicate that the routing identifier should be updated (and that an alternative path with an alternative exit BH is available). As described above with respect to the routing configuration table 700 having an additional update or rewrite field 703, certain values ​​in at least part of the next-hop address field or the next-hop BAP address field 502 can be used to provide priority information in addition to indicating whether the routing identifier should be updated.In another example, a specific value in at least part of the next-hop address field or the next-hop BAP address field 502 may be used to indicate whether the routing identifier of a data packet should be updated first (i.e., before attempting to route the data packet), updated as a backup option if no exit link is found after attempting to route the data packet, or not updated at all.

[0177] In one embodiment of the present invention, as described in 3GPP TS38.473 v16.4.0, the BAP MAPPING CONFIGURATION message (F1AP protocol) is used to send a routing configuration table, such as a routing configuration table 700, to an IAB node. In the example described above with respect to a routing configuration table 700 having an additional update or rewrite field 703, the BAP MAPPING CONFIGURATION message (F1AP protocol) is used to send a routing configuration table 700 with the rewrite field 703 introduced into an information element (IE) containing the table 700.

[0178] In one embodiment of the present invention, the BH Routing Information Added List (IE) information element (IE) defined in section 9.2.9.1 of 3GPP TS38.473 v16.4.0 is modified as follows to allow the IAB donor CU to set the rewrite field 703. TIFF0007912059000001.tif53168

[0179] Routing identifier mapping information may include a routing identifier mapping table. Figure 8 shows an example of entries in a routing identifier mapping table or routing ID mapping configuration (or header rewrite configuration) table having at least one entry 810-813 in an IAB node according to an embodiment of the present invention.

[0180] In one example, the routing ID mapping table 800 is configured by the IAB donor CU, which manages the primary topology for the IAB node. For example, relating to Figure 6, the routing ID mapping table 800 for IAB node 612 is configured by the IAB donor CU 610.

[0181] In another example, the routing ID mapping table 800 is configured by the IAB donor CU, which manages the secondary topology for the IAB node. For example, relating to Figure 6, the routing ID mapping table 800 for IAB node 612 is configured by the IAB donor CU 620.

[0182] The configuration of the routing ID mapping table 800 in the IAB node will be described later with reference to Figure 12.

[0183] Figure 8 schematically shows some entries 811, 812, and 813, such as entry 810, in the routing ID mapping table 800 according to some embodiments of the present invention.

[0184] Fields 821 and 831 both define routing identifier fields or BAP routing IDs for the routing identifier of a data packet, corresponding to the concatenation of path field 306 and destination field 305 as defined in Figure 3. The routing identifier field 821 (hereinafter referred to as the preceding routing identifier field) is for the previous routing identifier of the data packet and includes the concatenation of path field 8212 and destination field 8211. The route identifier field 831 (hereinafter referred to as the new (or next) route identifier field) includes the concatenation of route field 8312 and destination field 8311 for the new route identifier or next route identifier of the data packet.

[0185] The topology field 822 (hereinafter referred to as the previous topology field) is a field for indicating the IAB topology associated with the routing identifier in the preceding routing identifier field 821. The topology field 832 (hereinafter referred to as the new topology field or next topology field) is for indicating the IAB topology associated with the routing identifier in the new routing identifier field 831. Both topology fields 822 and 832 are n-bit fields. In one example, the topology field (e.g., field 822 and / or field 832) indicates that the topology is either the topology to which the IAB node actually belongs (such a topology may be called the primary topology or first topology) or another topology to which the IAB node is additionally connected (such a topology may be called the secondary topology or second topology). In another example, the topology field (e.g., field 822 and / or field 832) contains a topology identifier that has a value that uniquely identifies a given topology. In the example shown in Figure 6, the primary topology of the boundary node IAB node 612 is IAB topology 691, and the secondary topology is IAB topology 692. Therefore, each of the topology fields 822 and 832 in the routing identifier mapping table for IAB node 612 has a value indicating either IAB topology 691 or IAB topology 692.

[0186] Field 820, composed of fields 821 and 822, is called the Previous BAP Routing Information Element (IE), and field 830, composed of fields 831 and 832, is called the New BAP Routing Information Element (IE).

[0187] In relation to Figure 7, if an IAB node, such as IAB node 612, decides to route a data packet over an alternative exit BH link that requires rewriting fields 305 and 306 of the BAP header of the received data packet, the IAB node may check the entries in the routing ID mapping table 800 to determine whether the routing identifier of the received data packet (corresponding to the routing identifier field 501 associated with the rewritten field 703 of the entry in the routing configuration table defined in Figure 7) matches the routing identifier in the preceding routing identifier field 821 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 8211 of the entry. If a match is found with an entry in the routing ID mapping table 800, the IAB node updates or rewrites the BAP header of the received data packet using the routing identifier in the new routing identifier field 831 of the matched entry as the new routing identifier. The IAB topology shown in the new topology field 832 of the matching entry is used as the identified IAB topology associated with the next IAB node (e.g., the exit backhaul link).

[0188] The IAB node then updates or rewrites the received data packet by replacing the destination address in the destination field 305 and the path identifier in the path field 306 within the BAP header of the received data packet with the destination address in the new destination field 8311 and the path identifier in the new path field 8312, respectively, and finally routes this data packet on the topology identified by the topology field 832 using the new routing identifier.

[0189] The routing ID mapping table 800 may contain multiple entries that have the same destination BAP address in the destination address field 8211, but have different path identifiers in the path field 8212 and different routing identifiers in the new routing identifier field 831. The order of entries in the routing ID mapping table 800 may indicate the priority of the entries. For example, the first entry provides a default new BAP address corresponding to a new default path for reaching the destination, while other entries with the same destination BAP address relate to a backup redundant path that should be selected, for example, when the default link is unavailable due to a radio link failure (RLF) or congestion.

[0190] In one embodiment of the present invention, as described in 3GPP TS38.473 v16.4.0, the BAP MAPPING CONFIGURATION message (F1AP protocol) is used to send a routing identifier mapping table to an IAB node, which includes a new information element (IE) containing table 800, such as the routing ID mapping table 800.

[0191] A routing configuration table, such as the routing configuration table 700 shown and described in Figure 7, may be separate from a routing identifier mapping table, such as the routing ID mapping table 800 shown and described in Figure 8. Alternatively, both tables may be combined into a single table, as shown in Figure 15, which shows entry 1510 of a composite configuration table 1500 according to an example embodiment of the present invention. Fields similar to those shown in Figures 7 and 8 are referred to by the same reference number.

[0192] Backhaul (BH) RLC channel mapping information may include a BH RLC channel mapping configuration table. Figures 9a and 9b show examples of entries in a BH RLC channel mapping configuration table according to embodiments of the present invention. Instead of a BH RLC channel mapping configuration table having fields 911, 912, and 922 indicating the exit / inlet topology, as shown and described in Figures 9a and 9b, the BH RLC channel mapping information may provide information as shown in Figure 5(b) or Figure 5(c), where fields 511 and 522 indicate the exit link identifier and field 512 indicates the inlet link identifier. In this case, the inlet link identifier and exit link identifier indicate both the link and the topology (primary / MCG or secondary / SCG).

[0193] Figure 9a shows an example of entries in a BH RLC channel mapping configuration table 900 having at least one entry 910 in 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 acting as a relay (e.g., an intermediate IAB node) to identify backhaul (BH) RLC channels for routing data packets (e.g., BAP packets or PDUs) over exit links previously selected using the backhaul routing configuration table in Figure 5a or previously selected using the routing configuration table described with respect to Figure 7. The data packets are received at the IAB node from a preceding IAB node (e.g., a preceding hop IAB node) over the ingress BH link.

[0194] Entry 910 of the BH RLC channel mapping configuration table 900 corresponds to entry 510 of the BH RLC channel mapping configuration table in Figure 5(b), with additional fields 911 and 912. Additional field 911 is the exit topology field, which indicates the IAB topology associated with the next IAB node and the exit backhaul link between the IAB node and the next IAB node, indicated by the next hop address field. Additional field 912 is the inlet topology field, which indicates the IAB topology associated with the preceding IAB node and the inlet backhaul link between the IAB node and the preceding IAB node, indicated by the preceding hop address field. Other fields, the next-hop BAP address field 511 for the next-hop address of the next IAB node located after the IAB node in the routing path, the preceding-hop BAP address field 512 for the preceding-hop address of the preceding IAB node located before the IAB node in the routing path, the inlet BH RLC channel ID field 513 for the backhaul RLC channel identifier of the backhaul RLC channel of the inlet backhaul link, and the outlet BH RLC channel ID field 514 for the backhaul RLC channel identifier of the backhaul RLC channel of the outlet backhaul link, are shown in Figure 9a and specified with the same reference numerals as in Figure 5(b).

[0195] Field 911, also called the exit topology, or next topology field 911, identifies the topology associated with the next-hop BAP address 511. The associated topology identified in the next-hop BAP address field 511 and the exit topology field 911 defines a unique exit link (or exit BH link). Field 912, also called the inlet topology, or preceding topology field 912, identifies the topology associated with the preceding hop BAP address 512. The associated topology identified in the preceding hop BAP address field 512 and the inlet topology field 912 defines a unique inlet link (or inlet BH link).

[0196] 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 either the topology to which the IAB node actually belongs (such a topology may be called the primary topology or first topology) or another topology to which the IAB node is additionally connected (such a topology may be called the secondary topology or second topology). In another example, a topology field (e.g., field 911 and / or field 912) contains a topology identifier that has a value that uniquely identifies a given topology. In the example shown in Figure 6, the primary topology of IAB node 612, which is a boundary node, is IAB topology 691, and the secondary topology is IAB topology 692. Therefore, each of the topology fields 911 and 912 in the BH RLC channel mapping configuration table for IAB node 612 has a value that indicates either IAB topology 691 or IAB topology 692.

[0197] In the example where the routing configuration table described with respect to Figure 7 is used to select an exit BH link, when an IAB node, such as IAB node 612, decides to route a data packet through an alternative exit BH link that requires rewriting fields 305 and 306 of the BAP header of the received data packet, the IAB node may check the entries in the routing ID mapping table 800 to determine whether the routing identifier of the received data packet (corresponding to the routing identifier field 501 associated with the considered rewrite field 703 of the entry in the routing configuration table) matches the routing identifier in the preceding routing identifier field 821 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 8211 of the entry.

[0198] If a match is found with an entry in the routing ID mapping table 800, the IAB node updates or rewrites the BAP header of the received data packet using the routing identifier in the new routing identifier field 831 of the matched entry as the new routing identifier. The IAB node may determine from the routing configuration table 700 the next IAB node in the next-hop address field 502 associated with an entry whose routing identifier in the routing identifier field 501 matches the new routing identifier in the new routing identifier field 831 of the routing ID mapping table 800 as defined in Figure 8 (e.g., the address of the next IAB node or the next-hop BAP address), or the address of the next IAB node in the next-hop address field 502 associated with an entry whose destination address in the destination address field 5011 matches the new destination address in the new destination field 8311 of the routing ID mapping table 800 (e.g., the next-hop BAP address).

[0199] When an IAB node receives data packets from a preceding IAB node via an ingress BH link for routing to another IAB node via an egress BH link, the IAB node may select a backhaul RLC channel for the egress BH link based on the IAB topology associated with the egress BH link and a BH RLC channel mapping configuration table, such as table 900 in Figure 9a. For example, the IAB node may select a BH RLC channel for the egress BH link by checking the BH RLC channel mapping configuration table 900 and determining whether the BH RLC channel ID of the ingress BH link, the address of the preceding IAB node, the IAB topology associated with the preceding IAB node (e.g., the ingress BH link), the address of the next IAB node, and the IAB topology associated with the next IAB node match each field in the entry in the BH RLC channel mapping configuration table 900. If a match with an entry is determined, the IAB node can use the egress BH RLC channel ID of the matched entry to select a BH RLC channel for the egress BH link.

[0200] For example, if an exit BH link and associated topology indicated by the determined next IAB node (e.g., next-hop BAP address) is available (e.g., no RLF or congestion is detected), the IAB node checks the BH RLC channel mapping configuration table 900 and, considering the address of the preceding IAB node with respect to the preceding-hop BAP address field 512, the associated ingress topology with respect to the ingress topology field 912, or the address of the next IAB node with respect to the preceding topology field 912, the next-hop BAP address field 511, the associated exit topology with respect to the exit topology field 911 or next topology field 911, and the BH RLC channel ID with respect to the ingress BH RLC channel ID field 513, the IAB node may route the data packet through the exit BH RLC channel identified by the exit BH RLC channel ID field 514.

[0201] In one embodiment of the present invention, the BAP layer BH RLC channel mapping information list information element (IE) as defined in section 9.3.1.98 of 3GPP TS38.473 v16.4.0 is modified as follows, in accordance with some aspects of the present invention, so that the IAB donor CU can configure the BH RLC channel mapping configuration table 900 of the IAB node. TIFF0007912059000002.tif77158

[0202] The Mapping Information Index contains an index of one mapping information entry for an IAB donor DU or IAB-DU. The BAP layer BH RLC channel mapping information list IE, if included in UE-related F1AP signaling for setting or modifying a BH RLC channel, contains either the preceding hop BAP address IE512, inlet topology IE912, and inlet BH RLC channel (CH) ID IE513 for setting downlink (or downstream) direction mapping, or the next hop BAP address IE511, exit topology IE911, and exit BH RLC channel (CH) ID IE514 for setting uplink direction mapping.

[0203] In one example, the BH RLC channel mapping configuration table 900 is configured by the IAB donor CU that manages the primary topology of the IAB node. For example, relating to Figure 6, the BH RLC channel mapping configuration table 900 for IAB node 612 is configured by the IAB donor CU 610. In another example, the BH RLC channel mapping configuration table 900 is configured by the IAB donor CU that manages the secondary topology of the IAB node. For example, relating to Figure 6, the BH RLC channel mapping configuration table 900 for IAB node 612 is configured by the IAB donor CU 620. In yet another example, the entry in table 900 for the primary topology's exit BH RLC channel ID 514 is configured by the IAB donor CU that manages the primary topology of the boundary IAB node, and the entry in table 900 for the secondary topology's exit BH RLC channel ID 514 is configured by the IAB donor CU that manages the secondary topology of the boundary IAB node.

[0204] The configuration of the BH RLC Channel mapping setting table 900 in the IAB node will be described later with reference to Figure 12.

[0205] In one embodiment of the present invention, table 900 is sent to the IAB node using the BAP MAPPING CONFIGURATION message (F1AP protocol) described in 3GPP TS38.473 v16.4.0.

[0206] Figure 9b shows an example of entries in a BH RLC channel mapping configuration table 921 (also known as the uplink traffic vs. BH RLC channel mapping configuration table) having at least one entry 920 in an IAB node, according to an embodiment of the present invention. The BH RLC channel mapping configuration table 921 is used by an initiator IAB node (not an IAB donor DU). The IAB node generates data packets (e.g., BAP packets or PDUs from BAP SDUs (Service Data Units) received from higher layers) in a portion of the IAB node (e.g., a sublayer of a BAP entity) and provides the generated data packets to another portion of the IAB node (e.g., another sublayer of a BAP entity) for processing before routing them to another IAB node. The IAB node uses the BH RLC channel mapping configuration table 921 to identify BH RLC channels for sending these data packets uplink over an exit link previously selected using the backhaul routing configuration table described in Figure 5(a) or the routing configuration table described in relation to Figure 7. Entry 920 of the BH RLC channel mapping configuration table 921 corresponds to entry 520 of the uplink traffic versus BH RLC channel mapping configuration table in Figure 5(c), with an additional field 922. The additional field 922 is an exit topology field to indicate the IAB topology associated with the next IAB node and to indicate the exit backhaul link between the IAB node and the next IAB node, using the next-hop address.Other fields, a traffic type identifier field 521 for indicating the traffic type of data packets to be routed, a next-hop BAP address field 522 for indicating the next-hop address of the next IAB node adjacent to the IAB node in the routing path, and an exit BH RLC channel ID field 514 for the backhaul RLC channel identifier of the backhaul RLC channel of the exit backhaul link in the uplink traffic versus BH RLC channel mapping configuration table in Figure 5(c), are shown in Figure 9b and specified using the same reference numbers as in Figure 5(b).

[0207] Field 922, also called the exit topology or next topology field 922, identifies the topology associated with the next-hop BAP address 522. The next-hop BAP address field 522 and the associated topology identified in the exit topology field 922 define a unique exit link (or exit BH link).

[0208] The topology field 922 is an n-bit field. In one example, the topology field 922 indicates that the topology is either the topology to which the IAB node actually belongs (such a topology may be called the primary topology or first topology) or another topology to which the IAB node is additionally connected (such a topology may be called the secondary topology or second topology). In another example, the topology field 922 contains a topology identifier that has a value that uniquely identifies a given topology. In the example shown in Figure 6, the primary topology of the boundary node IAB node 612 is IAB topology 691, and the secondary topology is IAB topology 692. Therefore, the topology field 922 of the BH RLC channel mapping configuration table 920 for IAB node 612 has a value that indicates either IAB topology 691 or IAB topology 692.

[0209] Each entry in the Uplink Traffic vs. BH RLC Channel Mapping Configuration Table 921 includes a traffic type designator 521, 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 TS38.473. The other fields 522, 922, and 523 are indicated by BH information IEs as defined in section 9.3.1.114 of 3GPP TS38.473 v16.4.0, modified as follows according to one embodiment of the present invention: TIFF0007912059000003.tif63158

[0210] In one example, the BH RLC channel mapping configuration table 921 is configured by the IAB donor CU that manages the primary topology of the IAB node. For example, relating to Figure 6, the BH RLC channel mapping configuration table 921 for IAB node 612 is configured by the IAB donor CU 610. In another example, it is configured by the IAB donor CU that manages the secondary topology of the IAB node. For example, relating to Figure 6, the BH RLC channel mapping configuration table 921 for IAB node 612 is configured by the IAB donor CU 620. In yet another example, the entries in table 921 for the primary topology as exit topology 922 are configured by the IAB donor CU that manages the primary topology of the boundary IAB node, and the entries in table 921 for the secondary topology as exit topology 922 are configured by the IAB donor CU that manages the secondary topology of the boundary IAB node.

[0211] The configuration of the BH RLC Channel mapping setting table 921 in the IAB node will be described later with reference to Figure 12.

[0212] In one embodiment of the present invention, the BAP MAPPING CONFIGURATION message (F1AP protocol) described in 3GPP TS38.473 v16.4.0 is used to send table 921 to the IAB node.

[0213] In another example, an IAB node is configured using multiple tables 520 (such as the uplink traffic vs. BH RLC channel mapping configuration table in Figure 5(c)), each associated with a single IAB topology. In this example, one table per topology is used, allowing the exit topology field 922 to be omitted.

[0214] Figure 10 illustrates, using flowchart 1000, an exemplary method for processing data packets (for example, for managing the routing of BAP PDUs (or data packets) over one or more IAB networks (one or more IAB topologies)) according to embodiments and examples of the present invention. For example, a program element executed by CPU 1111 in Figure 11 for a BAP entity (DU or MT portion) of a BAP sublayer may perform the exemplary method shown in Figure 10. The method in Figure 10 may be applied to routing uplink or downlink data packets. The method in Figure 10 is similar to the method described above with reference to Figure 13, using configuration tables 7 and 8.

[0215] The process begins in step 1001, when an IAB node, such as IAB node 612, receives a BAP packet or BAP PDU to be routed.

[0216] In step 1004, the IAB node identifies the IAB topology associated with the routed BAP packet (e.g., the received BAP packet).

[0217] For example, when an IAB node receives a data packet from a preceding IAB node via an ingress BH link, the IAB node determines the IAB topology associated with the received data packet by determining the IAB topology associated with the preceding IAB node (which is also associated with the ingress backhaul link). In one example of the present invention, the ingress backhaul link from which the BAP PDU is received may be indicated to the BAP sublayer by a lower layer, for example, by a MAC sublayer including a scheduler. When an IAB node first connects to an IAB node DU, it receives the BAP address of the parent IAB node through the CellGroupConfig information element, which is included in the RRC message and defined in the 3GPP TS38.331 specification. Thus, the IAB node can associate the BAP address of the parent IAB node with the link. Also, when connecting to a second parent IAB node, the IAB node can detect whether the second parent IAB node DU connects to the same IAB donor CU as the first parent IAB node. The IAB node can then associate the BAP address of each parent IAB node with an IAB topology (primary or secondary, etc.). Therefore, the BAP sublayer of an IAB node can establish relationships between the BAP address of each parent IAB node, the IAB topology, and the links. When a non-boundary IAB node DU provides services to a new child IAB node, the child IAB node belongs to the same IAB topology as the IAB node DU. When a boundary IAB node provides services to a new child IAB node, it can determine the IAB topology to which the child IAB node belongs (by default, the child IAB node belongs to the primary IAB topology of the boundary IAB node). Furthermore, the IAB donor CU sends an F1AP message, UE CONTEXT SETUP message, to the IAB node DU, which contains the information element Configured BAP address, which is the BAP address set for the corresponding child IAB node. This message and this information element are described in the 3GPP TS38.473 specification.Therefore, the BAP sublayer of an IAB node can establish relationships between the BAP addresses of child IAB nodes, the IAB topology, and the links. In the example where an IAB node is an initiator IAB node, the IAB node determines the IAB topology associated with the received data packet based on knowing which IAB topology the IAB node belongs to. For example, for an initiator IAB node, the BAP routing identifier (ID) of the generated packet is shown by a table (not shown) called "Uplink Traffic to Routing ID Mapping Configuration" described in section 5.2.1.2.1 of TS 38.340. The shown BAP routing ID points to the topology to which the initiator IAB node belongs.

[0218] In another example, a flag (or identifier) ​​in the BAP header, using one or more reserved bits such as 302, 303, or 304, indicates the topology associated with the received packet. For generated packets first sent in the primary IAB topology of a boundary IAB node, the flag may be set to "0" (or "1"). For generated packets first sent in the secondary IAB topology of a boundary IAB node, the flag may be set to "1" (or "0"). If there are two or more topologies for inter-topology routing / rerouting, an additional value (i.e., added to "0" and "1") is used so that each topology can be identified from the flag value. Non-boundary nodes can ignore this flag. Boundary nodes can use it to associate links with topologies. Boundary nodes still associate links with parent or child BAP addresses as described above.

[0219] An IAB node can parse the header of a BAP packet and obtain destination address information or the destination address in the destination field 305 (as explained with reference to Figure 3). Although not shown in Figure 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 destination field 305 matches its own BAP address. If it is determined that the destination address in the destination field 305 does indeed match the IAB node's own BAP address, the IAB node removes the BAP header from the BAP PDU and carries it to the upper layer. If the IAB node is a boundary node, the boundary node compares the destination field 305 to only one of its own BAP addresses that is associated with the same topology to which the received BAP packet should be routed.

[0220] Next, in step 1005, the IAB node checks the routing configuration table or backhaul routing configuration table 700 associated with the IAB topology identified in step 1004 to find routing options for the received BAP PDU.

[0221] Routing options can be configured by discovering entries in the backhaul routing configuration table 700 associated with the IAB topology, which include a routing identifier in the routing identifier field (BAP routing ID) field 501 that matches the routing identifier in the BAP routing ID field 30 of the BAP header of the received data packet (i.e., the concatenation of the destination field 305 and the path field 306).

[0222] Routing options may be configured by finding an entry in the backhaul routing configuration table 700 associated with the IAB topology that includes in the destination field 5011 a destination address that matches the destination address in the destination field 305 of the BAP header of the received BAP PDU.

[0223] If no routing options are found in step 1006, the IAB node may discard the BAP PDU or save it for a new routing attempt (step 1007).

[0224] If a routing option is found in step 1006, in step 1008 the IAB node may check the information in the update or rewrite field 703 associated with the entry in the routing configuration table identified in step 1005 (or the information in the destination field 5011, if the backhaul routing configuration table does not include an update or rewrite field 703, and the IAB node reserves a specific value for at least part of the information in the destination field 5011 to indicate whether the routing identifier should be updated).

[0225] If the rewrite field 703 (or the information in the destination field 5011) indicates that the BAP header should not be rewritten in order to route the BAP PDU, the IAB node identifies the exit backhaul (BH) link to which the BAP PDU should be routed in step 1009 by checking the next-hop BAP address field 502 associated with the backhaul routing configuration table entry identified in steps 1005 and 1006.

[0226] Next, in step 1010, the IAB node determines whether the exit BH link identified in step 1009 is available. If it is determined that the exit BH link is not available, the IAB node returns to step 1005 and may again check the backhaul routing configuration table 700 associated with the IAB topology identified in step 1004 to look for new routing options for the received BAP PDU.

[0227] If an exit BH link is determined to be available, the IAB node, in step 1011, determines the BH RLC channel to which the BAP PDU should be routed based on information from the BH RLC channel mapping configuration table, as described in Figures 5(b), 5(c), 9a, and 9b, and finally routes the BAP PDU on the determined BH RLC channel.

[0228] If the rewrite field 703 indicates that in step 1008 some rewrite of the BAP header should be performed in order to route the BAP PDU, the IAB node checks in a routing ID mapping table, such as the routing ID mapping table 800 shown and described therein in Figure 8, for entries where the destination field 8211 and path field 8212 of the preceding routing identifier field 821 or routing ID field 821, i.e., the preceding BAP routing field 820, match the routing identifier of the received data packet (i.e., the routing ID field of the BAP header of the BAP PDU being routed, i.e., the destination field 305 and path field 306), and the IAB topology in the preceding topology field or topology field 822 matches the inbound IAB topology identified in step 1004.

[0229] Next, in step 1012, the IAB node replaces (updates or rewrites) the routing identifier in the received data packet with the new routing identifier of the matched entry by replacing (updating or rewriting) 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 destination field 8311 and the path identifier in the new path identifier field or path identifier in the path field 8312 of the new BAP routing field 830, which is associated with the considered previous BAP routing field 820 of the matched entry, as discussed in Figure 8.

[0230] Next, in step 1013, the IAB node checks the new topology field 832 associated with the new BAP routing field 830 considered in step 1012 and identifies the IAB topology associated with the exit BH link to which the BAP PDU should be routed.

[0231] The IAB node then returns to step 1005 and may again check the backhaul routing configuration table 700 associated with the IAB topology identified in step 1013 to look for new routing options for the received BAP PDU.

[0232] During the process, the IAB node may return to step 1006 several times to discover new routing options in the same BH routing configuration table 700; therefore, in one example, the IAB node remembers or tracks each entry in the BH routing configuration table 700 that has already been examined (to avoid an infinite loop).

[0233] The order of entries in the BH routing configuration table may reflect the priority between routing options. For example, the first entry in the BH routing configuration table matching the BAP routing ID of a received data packet may indicate that no rewrite operation is requested. If an exit BH link corresponding to this first entry is not available, the IAB node may find a second entry (i.e., routing option) that requests a rewrite operation. After the header rewrite using the routing ID mapping configuration table 800, the IAB node attempts to route the packet using the new BAP routing ID. If no available exit BH link is found with the new BAP routing ID, the IAB node may find an entry in the BH routing configuration table requesting that the BAP routing ID in the header be rewritten back to the original BAP routing ID. Subsequently, a third entry matching the original BAP routing ID (or at least the destination BAP address) may be found in the BH routing configuration table 700, thereby attempting another exit BH link.

[0234] As an example, if a data packet must cross a boundary node (such as IAB node 612 in Figure 6), the data packet is first routed to the boundary node in the first topology. When the boundary node receives this packet, it does not hold it and carry it to the upper layer because the packet is not actually assigned to the boundary node itself. This means that the destination BAP address of the data packet cannot be the BAP address of the boundary node in the first topology. Therefore, a different BAP address must be used as the destination BAP address. For the same reason, this BAP address cannot be the address of either an IAB node or an IAB donor DU in the first IAB topology. This different BAP address used to route the packet to the boundary node may be called an alias BAP address. Therefore, the IAB donor CU controlling the first IAB topology sets an alias BAP address for the true destination, which is used only in the first topology before rewriting the BAP header and is used as a routing identifier that is not noticed by the true destination.

[0235] In an example of the present invention, the following limitations may be considered to reduce the complexity of the configuration and processing time at the boundary node: the number of parent IAB nodes may be limited to two, and all child IAB nodes of the boundary node may be controlled by the same IAB donor CU as the boundary node in the primary topology. This means that the boundary node has its own link for sending data packets to and receiving data packets from the secondary topology. In this case, a BH routing configuration table for the secondary topology is not required for the boundary node: - Regarding upstream routing, if a boundary node detects a rewrite using a new BAP routing ID 831 associated with the secondary topology (indicated by field 832), the boundary node can directly select a unique exit link associated with the secondary topology. - For downstream routing, if a data packet received on the ingress BH link corresponding to the secondary topology contains a destination BAP address that is not the boundary node's BAP address, the boundary node can directly check the routing ID mapping configuration table 800 to find an entry for header rewriting.

[0236] Using the data packets according to the present invention (for example, by the exemplary method described above) as an example of processing, and using the example in Figure 6 for PATH2 and PATH3 identified above, two routing configuration tables may be provided to the boundary node IAB node 612 (belonging to IAB topology 691), or the IAB node 612 may be configured using its two routing configuration tables.

[0237] The routing configuration table for the first IAB topology 691 has at least the following entries: TIFF0007912059000004.tif31162

[0238] The routing configuration table for the second IAB topology 692 has at least the following entries: TIFF0007912059000005.tif30160

[0239] A routing ID mapping table like the one shown below (for example, based on the routing identifier mapping table 800 in Figure 8) may be provided to the boundary node IAB node 612, or the IAB node 612 may be configured using this routing ID mapping table: TIFF0007912059000006.tif42164

[0240] When IAB node 612 receives a data packet with the routing identifier BAP Add Donor-DU 602:PATH2, IAB node 612 checks the routing configuration table of the first IAB topology 691 for entries with matching routing identifiers or destination addresses. The first entry indicates that the next-hop address is BAP Add Donor-DU 602, and the rewrite field has a value of "No" indicating that the routing identifier should not be updated. Next, it checks whether an exit backhaul link 631 to the next IAB node (IAB donor DU602) with the address BAP Add Donor-DU 602 is available. If an exit backhaul link 631 (e.g., PATH2) 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. This second entry indicates that the routing identifier of the received data packet should be updated (by the value of "Yes" in the rewrite field 703). Then, IAB node 612 checks the routing ID mapping table using BAP Add Donor-DU 602:PATH2 as input and determines that the new routing identifier for the matching entry is BAP Add Donor-DU 603:PATH3 (related to the second IAB topology). IAB node 612 updates the header of the received data packet, rewriting the routing identifier with the new routing identifier, and checks the routing configuration table of the second IAB topology 692 using the new routing identifier Add Donor-DU 603:PATH3 as input for entries with a matching routing identifier or destination address. Provided that the exit BH link (link 635) to the next hop IAB node 611 is available, IAB node 612 routes the updated data packet to IAB node 611.

[0241] Figure 11 is a schematic diagram of an exemplary communication device (apparatus) or station according to one or more exemplary embodiments of the present disclosure.

[0242] The communication device 1100 may preferably be a device such as a microcomputer, workstation, or lightweight portable device. The communication device 1100 preferably has a communication bus 1113 to which the following are connected: - A central processing unit (CPU), such as a microprocessor; -Memory for storing a computer program containing instructions for the operation of the data and communication device 1100. The computer program may contain instructions for various operations and may include a number of different program elements (modules) or subroutines for implementing the present invention. For example, the program elements may include elements for implementing BAP entities for routing data packets to nodes in the IAB topology, as described above; and, - At least one communication interface 1102 for communicating with other devices or nodes in a wireless communication system, such as a wireless communication system 100 according to 5G NR release 16. The at least one communication interface 1102 may be connected to a communication network 1103, such as the wireless access network of system 100, to which digital data packets or frames or control frames are transmitted. Frames are written to the communication interface from the FIFO transmit memory of RAM 1112 for transmission, or read from the communication interface and written to the FIFO receive memory of RAM 1112 for reception, under the control of a software application running on CPU 1111.

[0243] Each of the donor CU, donor DU, and IAB node may include such a communication device 1100.

[0244] The central processing unit 1111 may be a single processing unit or processor, or it may include two or more processing units or processors that perform the processing necessary for the operation of the communication device 1100. The number of processors and the assignment of processing functions to the central processing unit 1111 are a matter of design choice for those skilled in the art.

[0245] Memory - A read-only memory 1107, denoted as ROM, for storing a computer program for implementing the present invention; - Random access memory 1112, denoted as RAM, for storing registers for recording executable code for a method according to one or more embodiments of the present invention, and variables and parameters necessary for implementing a method according to one or more embodiments of the present invention. It may include.

[0246] As an option, the communication device 1100 is - Data storage means such as a hard disk for storing a computer program for implementing a method according to one or more embodiments of the present invention; - A disk drive 1105 for disk 1106, which is adapted to read data from or write data to disk 1106; - A screen 1109, which displays the decoded data via a keyboard 1110 or other pointing means, and / or functions as a graphical interface with the user. It may also include that.

[0247] Preferably, the communication bus provides communication and interoperability between various elements included in or connected to the communication device 1100. The representation of the bus is not limited, and in particular, the central processing unit can be operated to transmit commands to any element of the communication device 1100 directly or using another element of the communication device 1100.

[0248] The disk 1106 can optionally be replaced by any information medium, such as a compact disk (CD-ROM), ZIP disk, USB key, or memory card, whether rewritable or not, generally speaking, an information storage means adapted to store one or more programs that can be read by a microcomputer or microprocessor, and which may be removable, whether integrated with the device or not, and which can, by execution, perform the method according to the embodiments of the present invention.

[0249] The executable code may optionally be stored in read-only memory 1107, on a hard disk 1104, or on any of the above-mentioned removable digital media such as disk 1106. According to an optional modification, the program's executable code may be received via interface 1102 using the communication network 1103 in order to be stored in one of the storage means of the communication device 1100, such as the hard disk 1104, before execution.

[0250] The central processing unit 1111 is preferably adapted to control and direct the execution of instructions or parts of instructions of the software code of one or more programs according to the present invention, and these instructions are stored in one of the storage means described above. When power is turned on, one or more programs stored in non-volatile memory, for example, the hard disk 1104 or the read-only memory 1107 are transferred to the random access memory 1112, which stores the executable code of one or more programs and registers for storing variables and parameters necessary to implement the present invention.

[0251] In a preferred embodiment, the device is a programmable device that uses software to implement the present invention. However, alternatively, the present invention may be implemented in hardware (for example, in the form of an application-specific integrated circuit (ASIC)).

[0252] Figures 16a and 16b illustrate steps of exemplary methods 1600 and 1604 for managing the processing of data packets according to embodiments of the present invention. Methods 1600 and 1604 are performed in a first donor CU of a first IAB topology in an IAB communication system (or IAB configuration) which includes at least two IAB topologies, each containing multiple IAB nodes or at least one IAB node. For example, the first donor CU could be IAB donor CU 610 of IAB topology 691 or IAB donor CU 620 of IAB topology 692 in the IAB communication system shown in Figure 6, or IAB donor CU 1210 or IAB donor CU 1220 in the IAB communication system shown in Figure 12. The methods shown in and described in relation to Figures 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 Figure 11 below, in which the method shown in Figures 16a and 16b is performed by the central processing unit 1111.

[0253] Figure 12 shows an exemplary message flow 1200 for managing the processing of data packets (for example, configuring and managing BAP PDU routing across multiple IAB networks or IAB topologies) according to embodiments and examples of the present invention. Figure 12 shows an exemplary message flow that includes exemplary messages for providing data packet routing configuration information configured in the manner shown and described with respect to Figure 16a, and also exemplary messages for performing steps configured in the manner shown and described with respect to Figure 16b.

[0254] IAB node 1211 (IAB node 612, etc.), belonging to the first IAB network (IAB network 691, etc.), also called the first topology, managed by the first IAB donor CU1210 (IAB donor CU610, etc.), acts as a boundary node with the second IAB network (IAB network 692, etc.), also called the second topology, managed by the second IAB donor CU1220 (IAB donor CU620, etc.). The second IAB topology includes at least one IAB donor Distributed Unit (DU) (IAB donor DU603, etc., in the example shown in Figure 6).

[0255] As described above, in one example, the first IAB donor CU1210 may provide data packet routing configuration information to at least one IAB node of the first IAB topology (e.g., IAB nodes 612, 613) for routing data packets on at least the first IAB topology (step 1602 in Figure 16a). The data packet routing configuration information includes a routing configuration table and a routing identifier mapping table. The routing configuration table has at least one entry that includes a routing identifier field for a routing identifier, which includes a destination address field indicating the address of the IAB node and a path identifier field indicating the path identifier of the routing path to that IAB node; a next hop address field indicating the address of the next IAB node in the routing path identified by the path identifier; and a field indicating whether the routing identifier of an incoming data packet matching the routing identifier in the routing identifier field should be updated. The routing identifier mapping information includes a routing identifier mapping table having at least one entry that includes: a preceding routing identifier field for a routing identifier; a preceding topology field for indicating the IAB topology associated with the routing identifier in the preceding routing identifier field; a new routing identifier field for a routing identifier; and a new topology field for indicating the IAB topology associated with the routing identifier in the new routing identifier field. The field indicating whether the routing identifier of an incoming data packet matching the routing identifier in the routing identifier field should be updated includes at least a portion of an update field (e.g., rewrite field 703) in which the value in it indicates that the routing identifier should be updated, or a portion of a next-hop address field in which the value in it indicates that the routing identifier should be updated.

[0256] The step of providing data packet routing configuration information for routing data packets on at least one IAB node of the first IAB topology (e.g., IAB nodes 612, 613) includes providing a routing configuration table in the routing configuration information element (IE) of a configuration message to be sent to at least one IAB node, and providing a routing identifier mapping table in the routing identifier mapping information element (IE) of a configuration message to be sent to at least one IAB node. As described above with respect to Figure 7, in the exemplary implementation, the BH Routing Information Added List (IE) element, as defined in section 9.2.9.1 of 3GPP TS38.473 v16.4.0, is modified so that the IAB donor CU can set the rewrite 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. The configuration message can be a BAP MAPPING CONFIGURATION message (F1AP protocol), as described in 3GPP TS38.473 v16.4.0.

[0257] The data packet routing configuration information may further include information for configuring a backhaul RLC channel mapping configuration table (for example, the BH RLC channel mapping configuration table as described above with reference to Figure 9a). As described above with reference to Figure 9a, in an exemplary implementation, the BAP layer BH RLC channel mapping Information List (IE) information element (IE) as defined in section 9.3.1.98 of 3GPP TS38.473 v16.4.0 may be modified in some aspects of the present invention to enable the IAB donor CU to configure the BH RLC channel mapping configuration table 900 of the IAB node. The data packet routing configuration information may additionally or alternatively include information for configuring the uplink traffic versus backhaul RLC channel mapping configuration table, as described above with reference to Figure 9b. As described above with reference to Figure 9b, in an exemplary implementation, each entry in the uplink traffic versus BH RLC channel mapping configuration table 921 includes a traffic type specifier 521, 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 TS38.473. Other fields 522, 922, and 523 of table 921 may be indicated by BH information IEs as defined in section 9.3.1.114 of 3GPP TS38.473 v16.4.0, which has been modified to allow an IAB donor CU to configure the BH RLC channel mapping configuration table 921 of an IAB node, according to some aspects of the present invention. The IEs for the BH RLC channel mapping configuration table and the uplink traffic versus BH RLC channel mapping configuration table may be included in the same message (e.g., the same message as the IEs for the routing configuration table and the routing identifier mapping table) or in different messages.

[0258] The configuration message (which may be included in configuration requests 1241 and 1251 shown in Figure 12) may also be a BAP MAPPING CONFIGURATION message (F1AP protocol), as described in 3GPP TS38.473 v16.4.0.

[0259] Data packet routing configuration information may be provided to at least one IAB node in a second IAB topology (in addition to at least one IAB node in the first IAB topology) of at least two IAB topologies. IAB node 1211 (e.g., IAB node 612) acts as a boundary node in response to detecting and connecting to a second IAB node (e.g., IAB node 611) belonging to a second IAB network (e.g., IAB network 691) managed by a second IAB donor CU 1220 (e.g., IAB donor CU 620), as described above with reference to Figure 6. The MT portion of IAB node 1211, upon first connecting to the network, attempts to detect the PSS (Primary Synchronization Signal) and SSS (Secondary Synchronization Signal) by performing a cell search procedure as defined in 3GPP TS38.300. Based on the acquired system information, the MT unit of IAB node 1211 determines whether it can connect to a new cell, i.e., a new IAB node such as IAB node 611. If IAB node 1211 successfully establishes a connection with IAB node 611, it may notify IAB donor CU 1210 (for example, by sending a DUAL CU CONNECTION NOTIFICATION message) that it has established dual connectivity with an IAB node belonging to a neighboring IAB network. In other words, IAB node 1211 may send a notification to the donor Central Unit (CU) 1210 of the first IAB network indicating that IAB node 1211 can route data packets to one or more IAB nodes in the second IAB network.

[0260] If IAB donor CU1210 wishes to establish inter-topology routing, i.e., route or offload data packets from the first IAB network to the second IAB network or from the second IAB network to the first IAB network, IAB donor CU1210 sends a request or notification, such as an OFFLOAD NEGOTIATION REQUEST message, to IAB donor CU1220 to establish routing of data packets between the first network or topology and the second IAB network topology (step 1606 in Figure 16b).

[0261] In step 1608 of Figure 16b, IAB donor CU1210 receives a response from IAB donor CU1220, such as an OFFLOAD NEGOTIATION RESPONSE message 1232. The response includes acknowledgment information indicating whether IAB donor CU1220 accepted the request, when IAB donor CU1220 accepted the request, and configuration information relating to one or more IAB nodes in the second IAB topology to identify routing paths for routing data packets between at least one IAB node in the first IAB topology and at least one IAB node in the second IAB topology. Details of the configuration information and the OFFLOAD NEGOTIATION RESPONSE message 1232 will be described later. In one embodiment of the present invention, message 1231 may be a New Xn Application Protocol (XnAP) message. The XnAP protocol is defined in the 3GPP TS38.423 specification.

[0262] Subsequently, IAB donor CU1220 may send a response to IAB donor CU1210, for example, using OFFLOAD NEGOTIATION RESPONSE message 1232. The response may indicate that IAB donor CU1220 is able to respond to the request and has accepted the offload request. If IAB donor CU1220 accepts the offload request, the response may include configuration information related to one or more IAB nodes in the second IAB topology to identify routing paths for routing data packets between at least one IAB node in the first IAB topology and at least one IAB node in the second IAB topology. Based on the configuration information received from IAB donor CU1220, IAB donor CU1210 may provide data packet routing configuration information to at least one IAB node (to the IAB nodes in the first IAB topology, and possibly to at least one IAB node in the second IAB topology as well). Details of the configuration information and OFFLOAD NEGOTIATION RESPONSE message 1232 will be described later.

[0263] Offload notification or message 1231 may contain all or part of the following IE: - Information element (IE) regarding the requested direction (up or down), -IE (e.g., IP address, BAP address) that identifies the IAB donor DU (e.g., IAB donor DU603 in Figure 6) in the secondary topology that IAB donor CU1210 is intended to use to send or receive data packets in wired backhaul, - Identify boundary node 1211 involved in routing across different topologies, for example, the IP address or BAP address of the boundary node in the secondary topology. - An IE indicating the destination of the offloaded data packet in the downlink direction, which can be either the boundary node 1211 itself, or belong to the first IAB topology, or be another IAB node (i.e., a child IAB node of the boundary node) of the first IAB topology. This indication can be limited to 1 bit, for example, where a value of "1" means the destination is the boundary node and a value of "0" means the destination is another IAB node. In other words, the IE can include 1 bit whose value is used to indicate whether the destination of the offloaded data packet in the downlink direction is the boundary node or another IAB node of the first IAB topology. With such an indication, the IAB donor CU 1220 can adapt the settings of the IAB donor DU that generates the BAP header of the offloaded data packet. When the destination is the boundary node 1211, the IAB donor DU can be instructed by the IAB donor CU 1220 to set the destination BAP address field of the header with the BAP address of the boundary node of the second IAB topology. When the destination is not the boundary node, the IAB donor DU can be instructed to set the destination BAP address field of the header with the alias BAP address of the actual destination in the first IAB topology (i.e., the alias BAP address of another IAB node of the first IAB topology that is the actual destination). This alias BAP address is only used in the second IAB topology before rewriting the BAP header at the boundary node 1211 to avoid routing ID or BAP address conflicts. - IE related to the expected throughput and / or desired quality of service (QoS) for the data flow to be routed. For example, the IE may include an index representing the QoS level. To properly manage the bearer mapping to BH RLC channels corresponding to the desired QoS level, the IAB donor CU1210 may also indicate the BH RLC channel ID to be used for the boundary node in the primary topology, on the inlet link for uplink transmissions and on the outlet link for downlink transmissions. Based on this latter information, the IAB donor CU1220 can determine whether the BH RLC channel ID to be used by the IAB donor CU1210 is new or already in use for an offload transmission that has already been set up.

[0264] For new downlink transmissions (i.e., 1:1 mapping using one bearer per RLC channel), IAB donor CU1220 can understand that it cannot reuse the same BH RLC channel ID used for previous downlink offloads (e.g., N:1 mapping where multiple 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 mapping configuration table 900, each having two different exit BH RLC channel IDs 514 as outputs. Similarly for uplink transmissions, if IAB donor CU1210 indicates a BH RLC channel ID that is already in use, IAB donor CU1220 can understand that it must also reuse a BH RLC channel ID that was already used for a previous uplink offload.

[0265] If the IAB donor CU 1220 is responsible for setting the whole or part of the routing ID setting mapping table 800 shown in and described with reference to FIG. 8 in the boundary node 1211, the IAB donor CU 1210 may include, in another IE in the message 1231, information related to the content of the fields for the primary topology (i.e., the fields 8211 and 8212 for entries added in the case of uplink transmission, or the fields 8311 and 8312 for entries added in the case of downlink transmission).

[0266] If the IAB donor CU 1220 is responsible for setting the whole or part of the BH RLC channel mapping setting table 900 shown in and described with reference to FIG. 9a in the boundary node 1211, the IAB donor CU 1210 may also include, in another IE in the message 1231, information related to the content of the fields for the primary topology (i.e., the fields 511 and 514 for entries added in the case of downlink transmission, or the fields 512 and 513 for entries added in the case of uplink transmission).

[0267] The IAB donor CU 1210 can concatenate multiple offload requests for different BAP routing IDs of the primary topology. In that case, the message 1231 includes a list of items, and each item includes some or all of the above-mentioned information elements.

[0268] Upon receiving the OFFLOAD NEGOTIATION REQUEST message 1231, the IAB donor CU 1220 can determine whether it can satisfy the offload request according to the state of the IAB network (e.g., the load or RLF of the link in the path towards the boundary node on the secondary topology). In other words, the IAB donor CU 1220 can determine whether it can support the routing or offload of data packets from the first IAB network to the second IAB network, or from the second IAB network to the first IAB network.

[0269] If IAB donor CU1220 can accommodate the requested traffic offload, it may determine one or more alias BAP addresses to be used to route downlink data packets to boundary node 1211 via a second topology. These one or more alias BAP addresses are used only in the second topology, before the BAP header is rewritten at boundary node 1211, in order to avoid routing ID or BAP address collisions.

[0270] Next, IAB donor CU1220 may send a response to IAB donor CU1210 using OFFLOAD NEGOTIATION RESPONSE message 1232. In one embodiment of the present invention, message 1232 may be a new Xn application protocol (XnAP) message.

[0271] An offload notification or message 1232 (for example, configuration information included in a response from IAB donor CU1220) may include: - Information element (IE) indicating an acknowledgment or non-acknowledgment in response to an offload request. -IE (e.g., IP address, BAP address) that identifies the IAB donor DU (e.g., IAB donor DU603 in Figure 6) in the secondary topology, which the IAB donor CU1210 can use to send or receive data packets in wired backhaul. - Identify boundary node 1211 involved in routing across different topologies (e.g., the IP address or BAP address of the boundary node in the secondary topology), -IE indicating the alias BAP address used or intended to be used (i.e., intended to be used by IAB donor CU1220) for routing data packets downstream to boundary node 1211, - The BH RLC channel IDs used or intended to be used (i.e., intended to be used by IAB donor CU1220) for the secondary topology IAB in the ingress link in the case of downlink transmission or in the egress link in the case of uplink transmission. Based on this latter information, IAB donor CU1210 can understand whether the BH RLC channel IDs to be used by IAB donor CU1220 are new (1:1 bearer mapping) or already used for offload transmissions that have already been set up (N:1 bearer mapping).

[0272] If IAB donor CU1210 is responsible for configuring all or part of the routing configuration table 700 shown and described in Figure 7 for the secondary topology at boundary node 1211, IAB donor CU1220 may include information related to the contents of the fields for the secondary topology (i.e., fields 5011, 5012, 502, 703 for one or more entries to be added) in another IE within message 1232.

[0273] If IAB donor CU1210 is responsible for configuring all or part of the routing ID configuration mapping table 800 shown and described in Figure 8 at boundary node 1211, IAB donor CU1220 may include in another IE within message 1232 information relating to the contents of fields related to the primary topology (i.e., fields 8211 and 8212 for entries added in the case of downlink, or fields 8311 and 8312 for entries added in the case of uplink).

[0274] If IAB donor CU1210 is responsible for configuring all or part of the BH RLC channel mapping configuration table 900 shown and described in Figure 9a at boundary node 1211, IAB donor CU1220 may include in message 1232 another IE relating to the contents of the fields for the primary topology (i.e., fields 511 and 514 for entries added in the case of uplink transmission, or fields 512 and 513 for entries added in the case of downlink transmission).

[0275] IAB donor CU1220 may concatenate multiple offload responses. In that case, message 1232 includes a list of items, each item including some or all of the information elements described above.

[0276] If IAB donor CU1220 responds or denies approving the offload request using OFFLOAD NEGOTIATION RESPONSE message 1232, it may use the IE in message 1232 to make a new proposal, for example, by indicating another IAB donor DU used to send or receive packets, another bearer mapping on the BH RLC channel, another boundary IAB node, etc. If IAB donor CU1210 receives such a response with a new proposal, it may compose a new OFFLOAD NEGOTIATION REQUEST 1231 by appropriately adapting the contents of the IE based on the new proposal.

[0277] Furthermore, when routing inbound data packets to boundary node 1211 via the first topology managed by IAB donor CU1210, one or more inbound alias BAP addresses may be used further by IAB nodes belonging to the first topology. These one or more alias BAP addresses are used only in the first topology before the BAP header is rewritten at boundary node 1211 to avoid routing ID or BAP address collisions.

[0278] If IAB donor CU1220 responds with an OFFLOAD NEGOTIATION RESPONSE message 1232 acknowledging the offload request, IAB donor CU1210 can configure the IAB node under control. In particular, IAB donor CU1210 may send a CONFIGURATION REQUEST message 1241 to boundary node 1211.

[0279] Subsequently, the IAB donor CU1220 may configure the IAB node to be controlled. In particular, the IAB donor CU1220 may send the message CONFIGURATION REQUEST1251 to the boundary node 1211.

[0280] In one embodiment of the present invention, CONFIGURATION REQUEST messages 1241 and 1251 may be BAP MAPPING CONFIGURATION messages (F1AP protocol) as described in 3GPP TS38.473 v16.4.0.

[0281] Figure 19 shows steps of an exemplary method 1900 for processing data packets according to a third embodiment of the present invention. Method 1900 is performed on an IAB node in an IAB communication system (or IAB configuration) having at least two IAB topologies, each containing multiple IAB nodes or at least one IAB node. For example, referring to the IAB communication system shown and described in Figure 6, an IAB node performing Method 1900 may be an IAB node in either a first IAB topology (or first IAB network) 691 or a second IAB topology (or second IAB network) 692. In other words, an IAB node belongs to or is part of either the first IAB topology 691 or the second IAB topology 692. Furthermore, an IAB node may be an IAB donor DU (601, 602, 603, etc.) for data packets to be routed downstream, or an initiator IAB node for data packets to be routed upstream (for example, an initiator IAB node may be an IAB node that sends data from the UE (i.e., acts as an access IAB node) or an IAB node that sends control data from itself). The method shown and described with reference to Figure 19 may be implemented by software and / or hardware elements. The IAB node may be implemented in a communication device 1100 shown and described with reference to Figure 11, where the method shown and described with reference to Figure 19 is implemented by one or more processing units such as a central processing unit 1111. For example, a program element executed by the CPU 1111 in Figure 11 for BAP entities (DU or MT portions) of a BAP sublayer may perform the method shown in Figure 19. The method in Figure 19 may be applied to routing data packets upstream or downstream.

[0282] In short, in step 1902, the IAB node receives a data packet (e.g., a BAP packet or BAP PDU). The data packet contains a routing identifier for routing the received data packet to a destination IAB node. The routing identifier may include the destination address of the destination IAB node for the data packet and a path identifier that identifies the routing path of the data packet to the destination IAB node. In one example, the data packet contains a header with a destination address and path identifier (e.g., fields 305 and 306 of the BAP PDU in Figure 3) that together show the routing identifier. The IAB node may receive data packets from a preceding IAB node via 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), generate a data packet in a part of the IAB node (such as a part of the BAP entity or a sublayer of the IAB node), and receive the generated data packet in another part of the IAB node (such as another part of the BAP entity or a sublayer of the IAB node) for routing to another IAB node. In the latter case, the IAB node acts as an initiator IAB node.

[0283] The IAB topology associated with a received data packet is one of at least two IAB topologies, and the IAB topology associated with the next IAB node to which the data packet should be routed is either the same IAB topology or another one of at least two IAB topologies. For example, IAB node 612 in Figure 6 is part of or belongs to the first IAB topology 691, and when IAB node 612 receives a data packet for routing, it may route the data packet to the next IAB node in the first IAB topology 691 or the second IAB topology 692, depending on the routing identifier.

[0284] In step 1904, the IAB node determines the IAB topology associated with the data packet. For example, if the IAB node receives a data packet from a previous IAB node via an ingress BH link, the IAB node determines the IAB topology associated with the received data packet by determining the IAB topology associated with the previous IAB node (which is also associated with the ingress backhaul link). As described above with reference to FIG. 10, the BAP sublayer of the IAB node can establish the relationship between the BAP address, topology, and backhaul link of the parent or child IAB node, and use this relationship to determine the IAB topology associated with the received data packet. In an example where the IAB node is an initiator IAB node (e.g., receiving data generated by the IAB node itself), the IAB node determines the IAB topology associated with the received data packet based on knowing which IAB topology the IAB node belongs to. For example, in the case of an initiator IAB node, a table (not shown) called the Uplink Traffic to Routing ID Mapping Configuration described in section 5.2.1.2.1 of TS38.340 indicates the BAP routing identifier (ID) of the generated packet. The indicated BAP routing ID refers to the topology to which the initiator IAB node belongs.

[0285] In step 1906, the IAB node determines whether the received data packet should be carried to the layer above the IAB node. For example, determining whether the received data packet should be carried to the layer above the IAB node involves comparing the destination address of the routing identifier of the received data packet with the address of the IAB node associated with each previously determined IAB topology. That is, if the IAB is a non-boundary node with a single BAP address associated with the IAB topology to which it belongs, it means that the IAB node checks whether the destination address information or destination address in the destination field 305 of the routing identifier matches the single BAP address of the IAB node itself. If the IAB node is a boundary node, the boundary node compares the destination field 305 of the routing identifier with only one of its own BAP addresses associated with the same topology as the BAP packet being routed.

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

[0287] In one example, 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 and described in Figure 5(a), or alternatively, routing configuration table 700 shown and described in Figure 7 (or alternatively, routing configuration table 1500 shown in Figure 15). An IAB node may determine whether an exit backhaul link exists by checking the entries in the backhaul routing configuration table 500 (alternatively 700 or 1500) associated with the determined IAB topology, which include a routing identifier in the routing identifier field 501 that matches the routing identifier in the BAP routing ID field 30 (i.e., the concatenation of the destination field 305 and the path field 306) in the BAP header of the BAP packet. This may be done by checking the entry in the backhaul routing configuration table 500 (or alternatively, the backhaul routing configuration table 700 (or table 1500 in Figure 15)) associated with the determined IAB topology, which contains the 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 an entry is found, the IAB node identifies the exit backhaul (BH) link to which the BAP PDU should be routed, for example, by checking the next-hop BAP address field 502 associated with the found entry in the backhaul routing configuration table. The IAB node then determines whether the identified exit BH link is available.

[0288] If it is determined that an exit BH link is unavailable (for example, an exit BH link is not identified, or an exit BH link is identified but unavailable (for example, due to RLF / congestion)), the IAB node determines in step 1910 whether it can update the routing identifier of the received data packet. For example, the IAB node may check the update or rewrite field 703 information in the backhaul routing configuration table 700 (or at least some values ​​in the next-hop address field 502, where at least some specific values ​​in the next-hop address field are used to indicate whether a header rewrite should be performed) for entries in the BAP routing ID mapping table (or header rewrite configuration) 800 that match the routing identifier in the BAP routing ID field 30 of the data packet's BAP header.

[0289] If an IAB node determines that it should update a routing identifier, in step 1912, the IAB node determines a new routing identifier and the IAB topology associated with that new routing identifier (for example, the IAB topology associated with the next IAB node (exit backhaul link) determined by the new routing identifier) ​​based, for example, on routing identifier mapping information and the routing identifier of the received data packet. In one example, the routing identifier mapping information is a routing identifier mapping table (or BAP routing identifier mapping table) having at least one entry that includes a field for indicating the IAB topology associated with each routing identifier to be updated, and / or a field for indicating the IAB topology associated with the new routing identifier. For example, a routing identifier mapping table may include a preceding routing identifier field for a routing identifier, a preceding topology field for indicating the IAB topology associated with the routing identifier in the preceding routing identifier field, a new or next routing identifier field for a routing identifier, and a new topology field for indicating the IAB topology associated with the routing identifier in the new routing identifier field, if alternative routing options (e.g., at least one redundant path) are available. In one example, the routing identifier mapping table is the routing identifier mapping table shown and described in Figure 8. An IAB node may identify a new routing identifier and the IAB topology associated with that new routing identifier (e.g., the exit backhaul link to which the data packet should be routed) by checking the routing identifier mapping table to determine whether the routing identifier of a data packet matches the routing identifier in the preceding routing identifier field of the entry, or whether the destination address of the routing identifier of a received data packet matches the destination address in the destination address field of the entry. If an IAB node determines a match with an entry, it uses the routing identifier in the matching entry's new routing identifier field as the identified new routing identifier, and the IAB topology indicated by the matching entry's new topology field as the identified or determined IAB topology associated with the new routing identifier. The IAB topology information in the topology field provides an indication of whether the data packet will be routed to the same IAB topology or to a different IAB topology.

[0290] For example, if the rewrite field 703 (or the value in at least part of the next-hop address field 502) indicates that some rewrite of the BAP header can be performed to route the BAP PDU, or if an entry is found in the BAP routing ID mapping table 800, the IAB node identifies the new routing identifier and the IAB topology associated with the new routing identifier based on the routing identifier mapping information and the routing identifier of the received data packet. The IAB node may determine the new routing identifier and the IAB topology associated with the new routing identifier by checking, as shown and described in Figure 8, that the preceding routing identifier field 821 or routing ID field 821 of the preceding BAP routing field 820, i.e., the destination field 8211 and path field 8212, match the routing identifier of the received data packet (i.e., the routing ID field in the BAP header of the BAP PDU being routed, i.e., the destination field 305 and path field 306), and that the IAB topology of the preceding topology field or topology field 822 matches an entry in a routing ID mapping table such as the routing ID mapping table 800 that matches a previously identified IAB topology.

[0291] Furthermore, in 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, thereby providing an updated data packet containing the identified new routing identifier. For example, the routing identifier of the received data may be replaced or rewritten with the new routing identifier. The IAB node then returns to step 1906 and repeats at least step 1906 to first determine whether the updated data packet should be carried to a higher layer. The IAB node may repeat steps 1906 through 1912 for the updated data packet for at least one cycle until it is determined that the updated data packet should be carried to a higher layer, or that there is an available exit backhaul link for routing the data, or that the routing identifier should not be updated.

[0292] For example, in response to the determination that the updated data packet will not be carried to a higher layer, the IAB node determines whether there is an exit backhaul link to route the data to the next IAB node (as per step 1908) based on the determined IAB topology associated with the new routing identifier of the updated data packet and the routing configuration information associated with the new routing identifier. The IAB node may determine the next IAB node (and the exit backhaul link associated with the next IAB node) by checking the routing configuration table associated with the identified IAB topology (associated with the exit backhaul link) to determine whether the identified new routing identifier matches the routing identifier in the routing identifier field of the entry, or whether the destination address of the new routing identifier matches the destination address in the destination address field of the entry. If the IAB node determines a match with the entry, the IAB node uses the next-hop address in the next-hop address field of the matched entry to determine the next IAB node and routes the updated data packet to the next IAB node via the associated exit backhaul link.

[0293] In response to determining that there is no available exit backhaul link for routing the updated data packet (for example, no exit backhaul link is identified, or an exit backhaul link is identified but unavailable due to RLF / congestion), the IAB node may determine (by step 1910) whether it can update the new routing identifier of the updated data packet. If it can update the new routing identifier, the IAB node (by step 1912) determines another new routing identifier and the IAB topology associated with that other new routing identifier, and updates the updated data packet by updating the new routing identifier with the determined other new routing identifier and providing a new updated data packet. The flow then returns to step 1906.

[0294] In response to determining that an available exit backhaul link exists, method 1900 may further include routing data packets to the next IAB node through that available exit backhaul link.

[0295] Method 1900 may further include selecting a backhaul RLC channel if an exit backhaul link for routing data packets is identified and available. The selection is based on the identified IAB topology associated with the next IAB node (which is also associated with the exit backhaul link) and backhaul RLC channel mapping information. In one 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 and described in Figure 5(b) or Figure 5(c) or Figure 9a or Figure 9b. In another example, the BH RLC channel mapping information may provide information as shown in Figure 5(b) or Figure 5(c), where fields 511 and 522 indicate the exit link identifier and field 512 indicates the ingress link identifier. In this case, the ingress link identifier and exit link identifier indicate both the link and topology (primary / MCG or secondary / SCG).

[0296] When an IAB node receives data packets from a preceding IAB node via an ingress backhaul link, the BH RLC channel mapping configuration table corresponds to the table described with respect to Figure 5(b) or Figure 9a. Selecting a backhaul RLC channel for an egress backhaul link with respect to the BH RLC channel mapping configuration table in Figure 9a may involve checking the backhaul RLC channel mapping configuration table to determine if the backhaul RLC channel ID of the ingress backhaul link, the address of the preceding IAB node, the determined IAB topology associated with the preceding IAB node (e.g., the ingress backhaul link), the address of the next IAB node, and the identified IAB topology associated with the next IAB node match each field in the entry in the backhaul RLC channel mapping configuration table. If a match is determined, the backhaul RLC channel for the egress backhaul link is selected using the egress backhaul RLC channel ID of the matched entry.

[0297] When an IAB node receives data packets generated by another IAB node (for example, if the IAB node is the initiator node), the BH RLC channel mapping configuration table corresponds to the table described with respect to Figure 5(c) or Figure 9b. Selecting a backhaul RLC channel for an exit backhaul link against the BH RLC channel mapping configuration table in Figure 9b may involve checking the backhaul RLC channel mapping configuration table to determine if the data traffic type in the received data packet, the address of the next IAB node, and the identified IAB topology associated with the next IAB node (for example, the exit backhaul link) match the respective fields of the entry in the backhaul RLC channel mapping configuration table. If a match is determined, the backhaul RLC channel for the exit backhaul link is selected using the exit backhaul RLC channel ID of the matched entry.

[0298] A confirmation can be made to determine whether the updated data packet should be carried to a higher layer by determining whether the updated data packet should be carried to a higher layer (i.e., by updating the routing identifier of the received data packet with the determined new routing identifier and providing the updated data packet, thus repeating step 1906 after the received data packet has been updated or rewritten). If no confirmation is made after the received data packet has been updated or rewritten, the data packet may be discarded even if it has reached the correct destination. For example, a data packet may be routed from a first topology 691 to a second topology 692, and the destination IAB node may be boundary node 612 in the second topology. If, after the received data packet has been updated to the address of boundary node 612 in the second topology, no confirmation is made (in step 1906) as to whether the updated data packet should be carried to a higher layer, the updated data packet is likely to be discarded at the boundary node. Repeating the determination made in step 1906 means that additional checks after a data packet has been updated or rewritten can be easily integrated into the existing flow without requiring significant changes. Furthermore, by repeating determination step 1906, the boundary node is not required to initially determine whether the received packet must be forwarded to a different IAB topology. This is detected when checking whether the packet's routing identifier must be updated.

[0299] Figure 18, using flowchart 1800, illustrates another exemplary method for processing data packets (for example, for managing the routing of BAP PDUs (or data packets) over one or more IAB networks (one or more IAB topologies)) according to embodiments and examples of the present invention. For example, a program element executed by CPU 1111 in Figure 11 for a BAP entity (DU or MT portion) of a BAP sublayer may perform the exemplary method shown in Figure 18. The method in Figure 18 may be applied to routing data packets in the uplink or downlink direction. The method in Figure 18 may use the configuration tables in Figure 5(a) (or alternatively, Figure 7, or Figure 15) and Figure 8.

[0300] The process begins in step 1801 when an IAB node, such as IAB node 612, receives a BAP packet or BAP PDU to be routed.

[0301] In step 1802, the IAB node identifies the IAB topology associated with the BAP packet to be routed (e.g., the received BAP packet). For example, the IAB node may determine the IAB topology associated with the received data packet according to one or more of the examples described above with respect to step 1004 in Figure 10.

[0302] In step 1803, the IAB node checks whether the destination address information or destination address in destination field 305 of the header of the received BAP packet (for example, as described above with reference to Figure 3) matches its own BAP address. If it is determined that the destination address in destination field 305 actually matches the IAB node's own BAP address, the IAB node removes the BAP header from the BAP PDU and carries it to the upper layer (step 1808). If the IAB node is a boundary node, the boundary node compares the destination address in destination field 305 with only one of its BAP addresses that is associated with the same topology as the topology to which the BAP packet should be routed.

[0303] If the packet is not carried to a higher layer (i.e., the destination address in the header of the received BAP packet does not match the address of the IAB node), in step 1811, the IAB node checks the routing configuration information, such as the routing configuration table or backhaul routing configuration table 500 (or alternatively 700), associated with the IAB topology identified in step 1802, based on the routing identifier of the data packet, to find a routing option for the BAP packet to be routed. In other words, the IAB node determines if there is an exit backhaul link to route the data (e.g., the received data packet).

[0304] The routing options may lie in finding an entry in the backhaul routing configuration table 500 (or 700) associated with the identified IAB topology, which includes a routing identifier in the routing identifier field 501 of the routing identifier (BAP ROUTING ID) field 501 that matches the routing identifier in the BAP header of the BAP packet (i.e., the concatenation of the destination field 305 and the path field 306).

[0305] The routing option may involve finding an entry in the backhaul routing configuration table 500 (or alternatively, the backhaul routing configuration table 700, as described above for Figure 7) associated with the identified IAB topology, in which the destination field 5011 contains a destination address that matches the destination address in the destination field 305 of the BAP header of the BAP packet.

[0306] If a routing option is found in step 1812, the IAB node in step 1813 identifies the exit backhaul (BH) link to which the BAP PDU should be routed, for example, by checking the next-hop BAP address field 502 associated with the backhaul routing configuration table entry identified in steps 1811 and 1812.

[0307] Then, in step 1814, the IAB node determines whether the exit BH link identified in step 1813 is available. If it is determined that the exit BH link is not available, the IAB node returns to step 1811 and may check the backhaul routing configuration table again for a new routing option.

[0308] If an exit BH link is determined to be available, the IAB node, in step 1815, determines the BH RLC channel to which the BAP PDU should be routed based on information from the BH RLC channel mapping configuration table, as discussed with reference to Figures 5(b), 5(c), 9a, and 9b, and finally routes the BAP PDU on the determined BH RLC channel. As described above, the BH RLC channel mapping information may provide information as shown in Figure 5(b) or Figure 5(c), where fields 511 and 522 indicate the exit link identifier and field 512 indicates the inlet link identifier. In this case, the inlet and exit link identifiers indicate both the link and the topology (primary / MCG or secondary / SCG).

[0309] If, in step 1812, no routing options or available routing options are found (for example, no routing options are found, or a routing option is found but the exit backhaul link for that routing option is not available), the IAB node may check whether rerouting by header rewriting is possible. For example, in step 1816, the IAB node may check the information in the backhaul routing configuration table 700 update or rewrite field 703 (or, if a specific value in at least part of the next-hop address field 502 is used to indicate whether header rewriting is performed, as described above) for entries in the BAP header of the BAP packet that match the routing identifier in the BAP routing ID field 30 (i.e., the concatenation of the destination field 305 and the path field 306). Alternatively, the IAB node checks whether entries in the BAP routing ID mapping table (or header rewrite configuration) 800 match the routing identifier in the BAP routing ID field 30 of the BAP header of the BAP packet.

[0310] If the rewrite field 703 (or at least some of the values ​​in the next-hop address field 502) indicates that the BAP header cannot be rewritten to route the BAP PDU, or if no entry is found in the BAP routing ID mapping table 800, the IAB node may discard the BAP PDU or store it for a new routing attempt (step 1819).

[0311] If the rewrite field 703 (or at least some value of the next-hop address field 502) indicates that some BAP header rewrite can be performed for routing of the BAP PDU, or if an entry is found in the BAP routing ID mapping table 800, the IAB node identifies the new routing identifier and associated IAB topology by checking, for example, an entry in a routing ID mapping table such as the routing ID mapping table 800 shown and described in Figure 8, based on the routing identifier mapping information and the routing identifier of the BAP packet, where the preceding routing identifier field 821 or routing ID field 821 of the preceding BAP routing field 820, i.e., the destination field 8211 and path field, matches the routing identifier of the incoming data packet (i.e., the routing ID field in the BAP header of the BAP PDU to be routed, i.e., the destination field 305 and path field 306), and the IAB topology in the preceding topology field or topology field 822 matches the inbound IAB topology identified in step 1802.

[0312] In step 1817, following the decision that the BAP header should be rewritten, the IAB node replaces (updates or rewrites) the routing identifier in the BAP packet with the new routing identifier, for example, by replacing (updating or rewriting) the destination address in the destination field 305 and the path identifier in the path field 306 of the BAP header of the BAP PDU to be routed with the destination address in the new destination field or destination field 8311 and the path identifier in the new path identifier field or path field 8312 of the new BAP routing field 830, which are associated with the considered preceding BAP routing field 820 of the matched entry, for example, as discussed in Figure 8.

[0313] In step 1818, the IAB node determines the IAB topology associated with the new routing identifier by, for example, examining the new topology field 832 associated with the new BAP routing field 830 considered in step 1817 and identifying the IAB topology associated with the exit BH link to which the BAP PDU (e.g., an received BAP data packet updated with the new routing identifier) ​​should be routed.

[0314] The IAB node then returns to step 1803 to check whether the destination address information or destination address in the destination field 305 of the updated header of the updated BAP packet matches its own BAP address. As described above, if it is determined that the destination address in the destination field 305 of the updated BAP packet does indeed match the IAB node's own BAP address, the IAB node removes the BAP header from the BAP PDU and carries it to the upper layer (step 1808). If the IAB node is a boundary node, the boundary node compares the destination address in the destination field 305 with only one of its BAP addresses that is associated with the determined IAB topology associated with the new routing identifier of the updated BAP packet to be routed.

[0315] If the destination address information does not match its own BAP address, the IAB node will, for example, in step 1811, re-examine the backhaul routing configuration table 500 (or alternatively 700) associated with the new IAB topology identified in step 1818, look for a new routing option for the received BAP PDU, and then attempt to route the BAP packet with the new routing identifier by following steps 1812-1819 as before, determining a new routing option for the received BAP PDU based on the identified new routing identifier and the routing configuration information associated with the determined IAB topology associated with the new routing identifier.

[0316] Regarding Figures 18 and 19, note that BAP packets that must transition from one topology to another must arrive at a boundary node that has a destination BAP address different from the BAP address of the boundary node in the entry topology (i.e., an alias of the actual destination in the other topology). Furthermore, BAP operations of non-boundary nodes and boundary nodes can be unified in the following steps.

[0317] An IAB node that receives a BAP data packet to be routed first determines the IAB topology associated with that data packet. This IAB topology is the entry topology for the BAP packet and is also associated with the entry backhaul link.

[0318] Subsequently, the IAB node determines whether the packet needs to be carried to a higher layer by comparing the destination BAP address with the IAB node's BAP address. If the IAB node is a boundary node, the boundary node compares the destination BAP address with the BAP address associated with the ingress topology.

[0319] If a packet should not be carried to a higher layer, the IAB node checks the routing configuration associated with the ingress topology to identify an available exit link. If no available exit link is identified using the routing configuration, the IAB node further checks the BAP routing ID mapping (or header rewrite configuration) to discover new routing options through header rewriting. If a single entry is found that matches the ingress topology and the BAP routing ID in the packet header, the IAB node rewrites the header with the new BAP routing ID to identify the exit topology associated with the new BAP routing ID.

[0320] Subsequently, the IAB node determines again whether the packet should be carried to a higher layer by comparing the new destination BAP address with the BAP address of the IAB node associated with the exit topology. If the packet should not be carried to a higher layer, the IAB node re-examines the routing configuration associated with the data packet's exit topology. If rerouting is performed without changing the topology, the exit topology becomes equal to the ingress topology.

[0321] If no available exit links are found, the IAB node re-examines the BAP routing ID mapping (or header rewrite configuration) to find a new routing option with a different header rewrite.

[0322] Finally, once an available exit link is identified, a mapping to a BH RLC channel is performed. The BH RLC channel mapping takes into account the ingress topology (ingress backhaul link) for the preceding hop's BAP address and the exit topology (exit backhaul link) for the next hop's BAP address.

[0323] Figure 17, using flowchart 1700, illustrates another exemplary method for processing data packets (for example, for managing BAP PDU (or data packet) routing over one or more IAB networks (one or more IAB topologies)) according to embodiments and examples of the present invention. For example, a program element executed by CPU 1111 in Figure 11 for BAP entities (DU or MT portions) of a BAP sublayer may perform the exemplary method shown in Figure 17. The method in Figure 17 may be applied to routing data packets in the uplink or downlink direction. The method in Figure 17 may use the configuration tables in Figure 5(a) (or alternatively, Figure 7) and Figure 8.

[0324] The process begins in step 1701 when an IAB node, such as IAB node 612, receives a BAP packet or BAP PDU to be routed.

[0325] In step 1702, the IAB node identifies the IAB topology associated with the BAP packet to be routed (e.g., the received BAP packet). For example, the IAB node may determine the IAB topology associated with the received data packet according to one or more of the examples described above with respect to step 1004 in Figure 10.

[0326] In step 1703, the IAB node identifies the type of traffic associated with the received BAP packet. Two types of traffic may be distinguished: - A traffic type for traffic intended to traverse boundary nodes and be routed through different topologies (i.e., inter-topology routing). This type of traffic may be called transit traffic, cross-traffic, or concatenated traffic. This is, for example, when data from a donor CU620 topology is carried to a higher layer at boundary node 612 (i.e., donor CU610 sends data to the boundary node). - A type of traffic that is routed through a single topology. This type of traffic may be called non-transit traffic, normal traffic, or unconnected traffic. For example, when data from a donor CU620 topology is carried to the upper layer at boundary node 612 (i.e., when donor CU620 sends data to the boundary node), or when data from a donor CU610 topology is carried to the upper layer of boundary node 612 (i.e., when donor CU610 sends data to the boundary node).

[0327] In one example, the determination of the traffic type (i.e., transit / concatenated or non-transit / non-concatenated) can be obtained via a flag (or traffic type identifier) ​​in the BAP header, for example, using one of the reserved bits 302, 303, or 304. For example, the flag might be 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. Non-boundary nodes can ignore this flag. Boundary nodes can use this flag to associate traffic with BAP packets that should be routed. In another example, the determination can be obtained by parsing the header of the BAP packet and checking the value of the path field 306. In fact, the set of path identifier values ​​is reserved by the IAB donor CU controlling routing (i.e., IAB donor CU 610 in Figure 6) and can only be used for transit (or concatenated) traffic. By identifying such a specific path identifier in path field 306, the boundary node can detect transit traffic. A dedicated path identifier for transit traffic may be called a transit path identifier, which identifies the transit path.

[0328] For example, the BH routing information supplemental list information element (IE) defined in section 9.2.9.1 of 3GPP TS38.473 v16.4.0 has been modified to allow the IAB donor CU to set 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.

[0329] In step 1704, the IAB node checks the type of traffic. This step (and step 1703) may be skipped in non-boundary nodes. For example, if an IAB node is configured with only one BAP address, it is a non-boundary node and may skip steps 1703 and 1704. If the type of traffic is transit traffic, in step 1705, the IAB node identifies a new routing identifier based on routing identifier mapping information, such as the BAP routing ID mapping table 800, and the routing identifier of the received data packet, and updates or rewrites the BAP header of the received data packet using the identified new routing identifier. For example, if the type of traffic is transit traffic, the IAB node rewrites the BAP header of the packet if an entry is found in the BAP routing ID mapping table (or header rewrite configuration) 800 as described with reference to Figure 8. In this case, the IAB node replaces (updates or rewrites) the routing identifier in the received data packet with the new routing identifier of the matched entry by replacing (updating or rewriting) the destination address in the destination field 305 and the path identifier in the path field 306 of the BAP header of the BAP PDU to be routed with the destination address in the new destination field or destination field 8311 and the path identifier in the new path identifier field or path field 8312 of the new BAP routing field associated with the considered preceding BAP routing field of the matched entry, as discussed with respect to Figure 8. Then, in step 1706, the IAB node identifies the IAB topology associated with the new routing identifier, for example by checking the new topology field 832 associated with the new BAP routing field 830 considered in step 1705, and identifies the IAB topology associated with the exit BH link to which the BAP PDU should be routed.

[0330] In step 1704, if the traffic is not transit traffic, the IAB node proceeds directly to step 1707 without performing steps 1705 and 1706. For example, in the case of a non-transit BAP packet, the header is not rewritten, and the exit topology is the same as the inbound topology.

[0331] In step 1707, the IAB node checks whether the destination address information or destination address in destination field 305 matches its own BAP address. If it is determined that the destination address in destination field 305 actually matches the IAB node's own BAP address, the IAB node removes the BAP header from the BAP PDU and carries it to the upper layer (step 1708). If the IAB node is a boundary node, the boundary node compares destination field 305 to only one of its own BAP addresses that is associated with the same topology as the incoming BAP packet to be routed.

[0332] If the packet is not carried to a higher layer, in step 1711, the IAB node checks the routing configuration information, such as the routing configuration table or backhaul routing configuration table 500 (or alternatively 700), associated with the IAB topology identified in step 1702 or step 1706, based on the routing identifier of the received data packet, to find a routing option for the BAP PDU that should be routed.

[0333] The routing options may lie in discovering entries in the backhaul routing configuration table 500 (or 700) associated with the IAB topology, which include a routing identifier in the BAP ROUTING ID field 501 that matches the routing identifier in the BAP Routing ID field 30 (i.e., the concatenation of the destination field 305 and the path field 306) of the BAP header of the received data packet.

[0334] The routing option may involve finding an entry in the backhaul routing configuration table 500 (or alternatively, the backhaul routing configuration table 700, as described above for Figure 7) associated with the IAB topology, which contains in the destination field 5011 a destination address that matches the destination address in the destination field 305 of the BAP header of the received BAP PDU.

[0335] If a routing option is found in step 1712, the IAB node identifies the exit backhaul (BH) link to which the BAP PDU should be routed in step 1713, for example, by checking the next-hop BAP address field 502 associated with the backhaul routing configuration table entry identified in steps 1711 and 1712.

[0336] Then, in step 1714, the IAB node determines whether the exit BH link identified in step 1713 is available. If it is determined that the exit BH link is not available, the IAB node may return to step 1711 and check the backhaul routing configuration table again for new routing options.

[0337] If an exit BH link is determined to be available, the IAB node, in step 1715, determines the BH RLC channel on which the BAP PDU should be routed, based on information from the BH RLC channel mapping configuration table, as described in Figures 5(b), 5(c), 9a, and 9b, and finally routes the BAP PDU on the determined BH RLC channel.

[0338] If no routing options are found in step 1712, the IAB node may check whether rerouting by header rewriting is possible. For example, in step 1716, the IAB node may check the information in the backhaul routing configuration table 700 update or rewrite field 703 (or the values ​​in at least part of the next-hop address field 502, if those values ​​are used to indicate whether a header rewrite should be performed) for entries in the BAP routing ID mapping table (or header rewrite configuration) 800 that match the routing identifier in the BAP routing ID field 30 (i.e., the concatenation of the destination field 305 and the path field 306) in the BAP header of the received data packet. Alternatively, the IAB node checks whether entries in the BAP routing ID mapping table (or header rewrite configuration) 800 match the routing identifier in the BAP routing ID field 30 in the BAP header of the received data packet.

[0339] If the rewrite field 703 (or at least some of the values ​​in the next-hop address field 502) indicates that the BAP header should not be rewritten in order to route the BAP PDU, or if no entry is found in the BAP routing ID mapping table 800, the IAB node may discard the BAP PDU or store it for a new routing attempt (step 1719).

[0340] If the rewrite field 703 (or at least some value in the next-hop address field 502) indicates that some rewrite of the BAP header should be performed in order to route the BAP PDU, the IAB node identifies the new routing identifier and associated IAB topology by checking, based on the routing identifier mapping information and the routing identifier of the received data packet, in a routing ID mapping table such as the routing ID mapping table 800 shown and described therein in Figure 8, for example, the preceding routing identifier field 821 or routing ID field 821, i.e., the destination field 8211 and path field 8212 of the preceding BAP routing field 820, which matches the routing identifier of the received data packet (i.e., the routing ID field, i.e., the destination field 305 and path field 306 in the BAP header of the BAP PDU to be routed), and the IAB topology in the preceding topology field or topology field 822 matches the entry IAB topology identified in step 1702 or step 1706.

[0341] In step 1717, following the determination that the BAP header should be rewritten, the IAB node replaces (updates or rewrites) the routing identifier in the received data packet with the new routing identifier by replacing (updating or rewriting) the destination address in the destination field 305 and the path identifier in the path field 306 of the BAP header of the BAP PDU to be routed with the destination address in the new destination field or destination field 8311 and the path identifier in the new path identifier field or path field 8312 of the new BAP routing field 830 associated with the considered preceding BAP routing field 820 of the matched entry, for example, as described in Figure 8.

[0342] In step 1718, the IAB node determines the IAB topology associated with the new routing identifier by, for example, examining the new topology field 832 associated with the new BAP routing field 830 considered in step 1717 and identifying the IAB topology associated with the exit BH link to which the BAP PDU should be routed.

[0343] The IAB node then returns to step 1711 and, based on the routing configuration information associated with the identified IAB topology and the identified new routing identifier, may search for new routing options for the received BAP PDU by, for example, checking again the backhaul routing configuration table 500 (or alternatively 700) associated with the IAB topology identified in step 1718.

[0344] Based on Figure 17, we can say the following:

[0345] A boundary IAB node is an IAB node in which the IAB-DU terminates to a different IAB donor CU than the parent DU.

[0346] For an IAB node (including boundary nodes), the IAB topology controlled by the terminal IAB donor CU refers to the primary topology (or master cell group (MCG) topology). For a boundary node, the IAB topology controlled by the non-terminal IAB donor CU refers to the secondary topology (or secondary cell group (SCG) topology).

[0347] For any IAB node, the IAB topology associated with the ingress backhaul link that receives BAP data packets is referred to as the ingress topology, and the IAB topology associated with the egress backhaul link that sends BAP data packets is referred to as the egress topology.

[0348] BAP data packets that must traverse boundary nodes from one ingress topology to a different egress topology represent transit traffic. The term transit traffic is equivalent to the term linked traffic. Due to rerouting at boundary nodes, BAP packets identified as transit traffic may ultimately be routed to the same egress topology as the ingress topology. For the same reason, BAP packets not identified as transit traffic may ultimately be routed to an egress topology different from the ingress topology of the boundary node.

[0349] We assume that boundary nodes have one BAP address for each topology, and that each IAB donor CU independently assigns the BAP address, BAP routing ID, and BH RLC channel ID to the IAB node. Therefore, the same BAP address, BAP routing ID, or BH RLC channel ID may be assigned in two different topologies.

[0350] The BAP address should only be intended to uniquely identify an IAB node. Therefore, the destination BAP address of a BAP packet is not an alias different from the BAP address of the boundary node in the ingress topology. Thus, BAP packets in transit traffic are received by boundary nodes with a destination BAP address equal to the BAP address of the boundary node in the ingress topology.

[0351] Identifying transit traffic at boundary nodes relies on a dedicated path identifier called a transit path ID, which is specifically used to route BAP packets across two topologies. The standard may reserve a range of dedicated path ID values ​​for transit path IDs, or the IAB donor CU may assign and define a set of transit path ID values ​​at boundary nodes. Alternatively, transit traffic may be identified using a flag in the BAP header (e.g., one of the reserved bits).

[0352] Boundary nodes should be able to identify the ingress link that received the BAP data packet, as well as the ingress topology (primary / MCG or secondary / SCG).

[0353] For boundary nodes, the BAP routing ID mapping (or header rewriting configuration) indicates the topology (MCG / SCG) referenced by the preceding routing ID and the topology (MCG / SCG) referenced by the new routing ID. This configuration table can be used to rewrite the BAP header of transit traffic at boundary nodes, and also when rewriting the BAP header for rerouting (to a different Donor-DU) at IAB nodes. This configuration table can be used for both inbound and outbound routing.

[0354] Boundary nodes are configured with separate routing configurations for the primary / MCG topology and the secondary / SCG topology. Alternatively, a unique routing configuration indicates the topology referenced by the BAP routing ID and the next-hop BAP address (i.e., the exit link) for each entry.

[0355] For mapping inlet BH RLC channels to outlet BH RLC channels at boundary nodes, it is necessary to specify the outlet topology associated with the next-hop BAP address and the inlet topology associated with the preceding-hop BAP address. Alternatively, the BH RLC channel mapping configuration provides a mapping between (inlet link + inlet BH RLC channel ID) and (outlet link + outlet BH RLC channel ID), where each link is associated with a topology (primary / MCG or secondary / SCG).

[0356] If N:1 bearer mapping is applied on the ingress link for BAP data packets traversing a boundary node from an ingress topology different from the egress topology, then N:1 bearer mapping must also be applied on the egress link. Coordination between IAB donor CUs is required to ensure consistent configuration of IAB nodes in both topologies.

[0357] A BAP operation to process a BAP data packet could be as follows:

[0358] A non-boundary IAB node first operates as per the Rel-16 specification: it determines transport to the upper layer and checks the routing configuration. However, if the routing configuration does not identify an available exit link, the IAB node further checks the BAP routing ID mapping (or header rewrite configuration) to discover new routing options through header rewriting. If one entry is found with a preceding BAP routing ID that matches the BAP routing ID in the packet header, the IAB node rewrites the header with the new BAP routing ID and checks the routing configuration again. Finally, if an available exit link is identified, mapping to a BH RLC channel is performed.

[0359] In comparison, boundary nodes behave similarly to other IAB nodes, except that they take topology into consideration and require additional steps to be performed beforehand.

[0360] The boundary node must first identify the ingress topology associated with the BAP packet it will process. This identification can be performed simultaneously with the identification of the ingress link of the BAP packet received from the lower layer.

[0361] The boundary node must then determine whether a BAP packet is transit traffic, for example, based on the identification of the transit path in the BAP header. If transit traffic is identified, the boundary node checks the BAP routing ID mapping (or header rewriting configuration) to rewrite the BAP header. To do this, the boundary node looks for an entry in the packet header that matches the ingress topology and BAP routing ID. Using the BAP routing ID mapping configuration, the boundary node must also identify the egress topology associated with the new BAP routing ID.

[0362] For non-transit BAP packets, the header is not rewritten, and the exit topology is the same as the entry topology.

[0363] The boundary node then confirms that the packet will be carried to the upper layer. To do this, the boundary node compares the destination BAP address with only one of its own BAP addresses that is associated with the BAP packet's exit topology.

[0364] If a packet is not carried to a higher layer, the boundary node checks the routing configuration of the exit topology associated with the BAP packet. Similar to non-boundary nodes, if the routing configuration does not identify an available exit link, the boundary node further checks the BAP routing ID mapping (or header rewrite configuration) to discover new routing options through header rewriting. If one entry is found with a matching couple (preceding BAP routing ID and topology) between the BAP routing ID in the header and the topology of the BAP packet, the boundary node rewrites the header with the new BAP routing ID to identify the relevant exit topology and checks the routing configuration of the identified exit topology again.

[0365] Finally, mapping to the BH RLC channel is performed, taking into account the ingress topology of the preceding hop's BAP address and the outgress topology of the next hop's BAP address, once an available exit link has been identified.

[0366] Furthermore, by rewriting the header first at the boundary node, it is possible to avoid using alias BAP addresses for transit traffic and to avoid unnecessary analysis of the routing configuration before rewriting.

[0367] Furthermore, considering that the exit topology is always equal to the inlet topology for non-boundary nodes, it should be noted that BAP operations can be described in a unified manner for both non-boundary and boundary nodes.

[0368] In fact, the flowchart in Figure 17 can be summarized in the following steps: 1. Determining whether traffic is linked or unlinked based on a dedicated path identifier (i.e., using a specific value for the path ID to distinguish between linked and unlinked traffic); 2. The header is rewritten with boundary nodes for concatenated traffic. Here, the entry topology needs to be identified; 3. As per the Release 16 specification, it is checked whether the traffic should be forwarded to a higher layer; 4. Check the routing table for routing; 5. When rerouting between topologies or between donor DUs is triggered, rewrite the header for rerouting and select the next hop by looking up the routing table with the new routing ID; 6. Mapping to BH RLC Channels. To map inlet BH RLC channels to outlet BH RLC channels at boundary nodes, it is necessary to show the IAB topology associated with the next IAB node and the IAB topology associated with the previous IAB node.

[0369] In addition, the following can be pointed out: -Solutions based on header rewriting should avoid BAP address collisions. -As a first step, the boundary node checks whether the traffic is connected or not. In this regard, this solution proposes relying on a dedicated path identifier used specifically to identify connected traffic (although other options are permitted for identifying connected traffic, even if a flag in the BAP header requires the use of reserved bits in the BAP header, on the other hand, connected and unconnected traffic cannot be closed based on the inbound link), - In routing table configuration 500 or 700, it is not necessary to specify whether it is for linked or unlinked traffic. - In routing table configuration 500 or 700, it is not necessary to indicate whether it is for upstream or downstream traffic. -On the other hand, it is necessary to be able to associate the topology with the BAP address in routing table 500 or 700. - In header rewriting setting 800, it is not necessary to specify whether it is for the up or down direction. -On the other hand, in header rewrite setting 800, it is necessary to be able to associate the topology with the BAP address. - This avoids the need for two separate rewrite tables for BAP header rewriting settings for inter-topology routing and BAP header rewriting settings for rerouting at boundary nodes.

[0370] While the present invention has been described with reference to embodiments, it should be understood that the present invention is not limited to the disclosed embodiments. Those skilled in the art will understand that various changes and modifications can be made without departing from the scope of the invention as defined in the appended claims. All features disclosed herein (including the appended claims, abstract and drawings), and / or all steps of any method or process disclosed herein, can be combined in any combination, except for combinations in which at least some of such features and / or steps are mutually exclusive. Each feature disclosed herein (including the appended claims, abstract and drawings) can be replaced by an alternative feature serving the same, equivalent or similar purpose unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is merely one example of a general set of equivalent or similar features.

[0371] In the claims, the words “comprising” do not exclude other elements or steps, and the indefinite articles “a” or “an” do not exclude plurals. The mere fact that different features are described in different dependent claims does not imply that combinations of these features cannot be used advantageously.

[0372] The reference numbers included in the claims are for illustrative purposes only and are not intended to limit the scope of the claims.

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

[0374] Computer-readable media may include computer-readable storage media corresponding to tangible media such as data storage media, or communication media including any media that facilitates the transfer of computer programs from one place to another, for example, according to a communication protocol. Thus, computer-readable media may generally correspond to (1) non-temporary tangible computer-readable storage media, or (2) communication media such as signals or carrier waves. Data storage media may be any available media accessible by one or more computers or one or more processors to obtain instructions, code and / or data structures for implementation of the technology described herein. Computer program products may include computer-readable media.

[0375] Such computer-readable storage media can include, but are not limited to, computer-readable storage media, such as RAM, ROM, EEPROM, CD-ROM or other optical disk storage devices, magnetic disk storage devices, or other magnetic storage devices, flash memory, or any other media that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection can appropriately be called a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technology such as infrared, radio, or microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technology such as infrared, radio, or microwave are included in the definition of a medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carriers, signals, or other transient media, but instead refer to non-transient tangible storage media. As used herein, the terms "Disk" and "Disc" include compact discs (CDs), laserdiscs, optical discs, digital-purpose discs (DVDs), floppy disks, and Blu-ray discs. Disks typically reproduce data magnetically, while Discs reproduce data optically using a laser. Any combination of the above should also be included in the range of computer-readable media.

[0376] 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 circuits. Therefore, the term “processor” as used herein may refer to any of the aforementioned structures or other structures suitable for implementing the technology described herein. Furthermore, in some embodiments, the functions described herein may be provided within dedicated hardware and / or software modules configured for encoding and decoding, or incorporated into a composite codec. The technology may also be fully implemented in one or more circuits or logic elements.

[0377] Clauses specifying further aspects and embodiments 1. A method for processing data packets in an IAB node of an IAB communication system comprising at least two Integrated Access and Backhaul (IAB) topologies, each IAB topology comprising multiple IAB nodes, Receiving a data packet containing a routing identifier, Determining the IAB topology associated with the received data packet, Before routing the data packet to another IAB node, it is determined whether the routing identifier should be updated based on the routing configuration information associated with the determined IAB topology and the routing identifier of the received data packet. In response to the determination that the aforementioned routing identifier should be updated, Based on routing identifier mapping information and the routing identifier of the received data packet, a new routing identifier and its associated IAB topology are identified. To provide an updated data packet containing the identified new routing identifier, the received data packet is updated by updating the routing identifier of the received data packet with the identified new routing identifier, Based on the identified IAB topology and the routing configuration information associated with the identified new routing identifier, the system determines the exit backhaul link to which the data packet should be routed to the next IAB node. A method comprising routing the updated data packet to the next IAB node via the exit backhaul link.

[0378] 2. The method of Clause 1, wherein the received data packet is a BAP data packet having a Backhaul Adaptation Protocol (BAP) header containing the routing identifier, wherein the routing configuration information includes a backhaul routing configuration table containing a field for indicating whether the BAP routing identifier of the received data packet is updated.

[0379] 3. The method of Clause 2, wherein the routing identifier mapping information includes a routing identifier mapping table that includes a field for indicating the IAB topology associated with the BAP routing identifier and / or a field for indicating the IAB topology associated with the new routing identifier.

[0380] 4. The method of Clause 1, wherein the routing configuration information includes a routing configuration table having at least one entry, each entry of the routing configuration table including: a routing identifier field for a routing identifier, which includes a destination address field indicating the address of an IAB node and a path identifier field indicating the path identifier of a routing 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; and an update field indicating whether the routing identifier should be updated.

[0381] 5. Routing configuration information includes a routing configuration table having at least one entry, each entity of the routing configuration table including a routing identifier field for a routing identifier, which includes a destination address field indicating the address of an IAB node and a path identifier field indicating the path identifier of a routing path to the IAB node; and a next-hop address field for indicating the address of the next IAB node in the routing path identified by the path identifier, wherein a predetermined value in at least a portion of the next-hop address field indicates the routing identifier to be updated in the manner of Clause 1.

[0382] 6. The method of Clause 4 or Clause 5, wherein a specific value in the update field for an entry or at least a portion of the next-hop address field indicates whether the routing identifier should be updated and the priority of the entry compared to another entry using the same precursor routing identifier or destination address.

[0383] 7. The method according to any one of the clauses 1 to 6, further comprising selecting a backhaul RLC channel for the exit backhaul link based on identified IAB topology and backhaul RLC channel mapping information associated with the exit backhaul link.

[0384] 8. The method according to Clause 7, wherein the backhaul RLC channel mapping information includes a backhaul RLC channel mapping configuration table having at least one entry, each entry comprising: a next-hop address field for the next-hop address of a next IAB node adjacent to the IAB node in the routing path; an exit topology field for indicating the IAB topology associated with the next IAB node and for indicating the exit backhaul link between the IAB node and the next IAB node using the next-hop address; an advance-hop address field for the advance-hop address of a preceding IAB node prior to the IAB node in the routing path, for indicating the IAB topology associated with the preceding IAB node and for indicating the inlet backhaul link between the IAB node and the preceding IAB node using the advance-hop address field; an inlet backhaul RLC channel identifier field for the backhaul RLC channel identifier of the inlet backhaul link; and an exit backhaul RLC channel identifier field for the backhaul RLC channel identifier of the backhaul RLC channel for the exit backhaul link.

[0385] 9. Receiving a data packet includes receiving the data packet from a preceding IAB node via an ingress BH link, and determining the IAB topology associated with the received data packet includes determining the IAB topology associated with the ingress backhaul link. Selecting a backhaul RLC channel for the aforementioned exit backhaul link is, In order to determine whether the backhaul RLC channel ID of the inlet backhaul link, the address of the previous IAB node, the determined IAB topology associated with the previous IAB node, the address of the next IAB node, and the IAB topology associated with the next IAB node match each field of the entry in the backhaul RLC channel mapping configuration table, the backhaul RLC channel mapping configuration table is checked. If a match with an entry is determined, the backhaul RLC channel of the exit backhaul link is selected using the exit backhaul RLC channel ID of the matched entry. The method described in Article 8, including the method described in Article 8.

[0386] 10. The method according to Clause 7, wherein the backhaul RLC channel mapping information includes a backhaul RLC channel mapping configuration table having at least one entry, each entry comprising: a traffic type identifier field for indicating the traffic type of data packets to be routed; a next hop address field for the next hop address of a next IAB node adjacent to the IAB node in the routing path; an exit topology field for indicating the IAB topology associated with the next IAB node and for indicating the exit backhaul link between the IAB node and the next IAB node using the next hop address; and an exit backhaul RLC channel identifier field for the backhaul RLC channel for the exit backhaul link.

[0387] 11. The method of Clause 10, wherein receiving a data packet includes generating the data packet in one part of the IAB node and receiving the data packet in another part of the IAB node for routing to another IAB node, and selecting a backhaul RLC channel for the exit backhaul link includes checking the backhaul RLC channel mapping configuration table to determine whether the traffic type of the received data packet, the address of the next IAB node, and the IAB topology associated with the next IAB node match the corresponding fields of an entity in the backhaul RLC channel mapping configuration table, and if a match with an entry is determined, selecting the backhaul RLC channel for the exit backhaul link using the exit backhaul RLC channel ID of the matched entry.

[0388] 12. The method according to any one of the clauses 4 to 11, wherein the routing identifier mapping information includes a routing identifier mapping table having at least one entry, and each entry in the routing identifier mapping table includes a preceding routing identifier field for a routing identifier, a preceding topology field for indicating the IAB topology associated with the routing identifier in the preceding routing identifier field, a new routing identifier field for a routing identifier, and a new topology field for indicating the IAB topology associated with the routing identifier in the new routing identifier field.

[0389] 13. The method of Clause 12, wherein the routing identifier of the received data packet includes the destination address of the destination IAB node for the data packet, and the method for identifying the new routing identifier and the IAB topology associated with the next IAB node to which the data packet is routed includes checking the routing identifier mapping table to determine whether the routing identifier of the received data packet matches the routing identifier in the preceding 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 when a match with an entry is determined, using the routing identifier in the new routing identifier field of the matched entry as the identified new routing identifier, and using the IAB topology indicated by the new topology field of the matched entry as the identified IAB topology.

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

[0391] 15. The method according to any one of Clauses 4 to 14, wherein the routing identifier of the received data packet includes the destination address of the destination IAB node for the data packet, and determining whether the routing identifier should be updated includes determining whether there are routing options for the received data packet by checking the routing configuration table associated with the determined IAB topology, associated with the received data packet, to determine whether the routing identifier of the received data packet matches 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, and determining whether the routing identifier should be updated includes determining whether the routing identifier should be updated by checking the value in the update field or the next-hop address field of the matched entry, in response to determining whether a match with the entry has been determined.

[0392] 16. The method according to any one of the clauses 4 to 15, wherein the new routing identifier includes the destination address of the destination IAB node for the data packet, and determining the exit backhaul link includes checking the routing configuration table associated with the identified IAB topology to determine whether the identified new routing identifier matches the routing identifier in the routing identifier field of the entry, or whether the destination address of the new routing identifier matches the destination address in the destination address field of the entry, and when a match with an entry is determined, using the next hop address in the next hop address field of the matched entity to determine the next IAB node.

[0393] 17. The method according to clause 15 or 16, wherein the order of entries in the routing configuration table having the same routing identifier or destination address indicates the priority of the entries.

[0394] 18. The method of Clause 17, wherein checking the routing configuration table includes checking the entries in accordance with the priority of the entries.

[0395] 19. A method for processing data packets in an IAB node of an IAB communication system comprising at least two Integrated Access and Backhaul (IAB) topologies, each IAB topology comprising multiple IAB nodes, (a) Receiving a data packet containing a routing identifier, (b) Determining the IAB topology associated with the received data packet, (c) Determining whether the received data packet should be transported to the upper layer of the IAB node, (d) In response to the determination that the received data packet should not be transported to a higher layer, determine whether there is an available exit backhaul link for routing the data to the next IAB node, based on the routing configuration information associated with the determined IAB topology and the routing identifier of the received data packet, (e) Determining whether the routing identifier of the received data packet should be updated in response to the determination that there is no available exit backhaul link for routing the data, (f) In response to the determination that the routing identifier of the received data packet should be updated, the new routing identifier and the IAB topology associated with the new routing identifier are determined, and in order to provide an updated data packet containing the determined new routing identifier, the received data packet is updated by updating the routing identifier of the received data packet using the determined new routing identifier, (g) Repeat step (c) at least for the updated data packet, A method that includes this.

[0396] 20. The method of Clause 19, which includes repeating steps (c) through (f) for at least one cycle for an updated data packet until it is determined that the updated data packet should be transported to the upper layer or that the routing identifier should not be updated.

[0397] 21. The method according to Clause 19 or 20, wherein each of the routing identifiers of the received data packet and the updated data packet includes the destination address of the destination IAB node, and each of the determinations of whether the received data packet should be carried to the upper layer of the IAB node and whether the updated data packet should be carried to the upper layer of the IAB node includes comparing the address of the IAB node associated with the respective determined IAB topology with the destination address of the routing identifier.

[0398] 22. The method according to clause 21, wherein the IAB node is a boundary node such that it is part of a first IAB topology among the at least two IAB topologies and is connected to an IAB node of a second IAB topology among the at least two IAB topologies, and the IAB node has a first address associated with the first IAB topology and a second address associated with the second IAB topology, and each of determining whether an received data packet should be carried to a higher layer of the IAB node and determining whether an updated data packet should be carried to a higher layer of the IAB node includes comparing the destination address of the routing identifier with one of the first address and the second address of the IAB node, wherein if the determined IAB topology is the first topology, the one address is the first address of the IAB node, and if the determined IAB topology is the second topology, the one address is the second address of the IAB node.

[0399] 23. The method of any one of the clauses 19 to 22, wherein determining a new routing identifier and the IAB topology associated with the new routing identifier includes determining a new routing identifier and the associated IAB topology based on routing identifier mapping information and the routing identifier of the received data packet.

[0400] 24. The method according to Clause 23, wherein the routing identifier mapping information includes a routing identifier mapping table having at least one entry, and each entry in the routing identifier mapping table includes a preceding routing identifier field for a routing identifier, a preceding topology field for indicating the IAB topology associated with the routing identifier in the preceding routing identifier field, a new routing identifier field for a routing identifier, and a new topology field for indicating the IAB topology associated with the routing identifier in the new routing identifier field.

[0401] 25. The method according to any one of the clauses 19 to 23, wherein the received data packet is a BAP data packet having a Backhaul Adaptation Protocol (BAP) header containing the routing identifier, and the routing configuration information includes a backhaul routing configuration table containing a field for indicating whether the BAP routing identifier of the received data packet is updated.

[0402] 26. The method according to clauses 2 and 25, wherein the routing identifier mapping information includes a routing identifier mapping table that includes a field for indicating the IAB topology associated with the updated BAP routing identifier, and / or a field for indicating the IAB topology associated with the new routing identifier.

[0403] 27. The method according to any one of the clauses 19 to 24, wherein the routing configuration information includes a routing configuration table having at least one entry, each entry in the routing configuration table including a routing identifier field for a routing identifier that includes a destination address field indicating the address of an IAB node and a path identifier field indicating the path identifier of a routing 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, and an update field indicating whether the routing identifier should be updated.

[0404] 28. The method according to any one of the clauses 19 to 24, wherein the routing configuration information includes a routing configuration table having at least one entry, each entry of the routing configuration table including a routing identifier field for a routing identifier which includes a destination address field indicating the address of an IAB node and a path identifier field indicating a path identifier for a routing path to the IAB node, and a next-hop address field for indicating the address of the next IAB node in the routing path identified by the path identifier, wherein a predetermined value in at least a portion of the next-hop address field indicates that the routing identifier should be updated.

[0405] 29. The method according to clause 27 or 28, which indicates whether a predetermined value in the update field of an entry or in at least a portion of the next-hop address field should update the routing identifier, and the priority of that entry compared to another entry having the same routing identifier or destination address.

[0406] 30. The method according to any one of the clauses 19 to 29, further comprising: determining that an exit backhaul link is available, selecting a backhaul RLC channel for the exit backhaul link based on the IAB topology and backhaul RLC channel mapping information associated with the exit backhaul link; and routing the data packets through the selected backhaul RLC channel of the exit backhaul link to the next IAB node.

[0407] 31. The method according to any one of clauses 3, 12, 25, or 26, wherein the fields of the routing configuration table are combined with the fields of the routing identifier mapping table in a single table.

[0408] 32. The method according to any one of the clauses 1 to 31, wherein receiving a data packet includes receiving the data packet from a preceding IAB node via an ingress backhaul link, and determining the IAB topology associated with the received data packet includes determining the IAB topology associated with the ingress backhaul link.

[0409] 33. The method according to any one of the clauses 1 to 31, further comprising generating the data packet in a portion of the IAB node, receiving the data packet, receiving the data packet in another portion of the IAB node, generating the data packet for routing to another IAB node, and determining the IAB topology associated with the received data packet, which comprises determining the IAB topology associated with the IAB node.

[0410] 34. The method according to any one of the clauses 1 to 33, 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 routed is the same IAB topology or another one of the at least two IAB topologies.

[0411] 35. The method according to any one of the clauses 1 to 34, further comprising receiving routing configuration information and routing identifier mapping information from at least one donor Control Unit (CU) of the at least two IAB topologies.

[0412] 36. The method according to any one of Clauses 1 to 35, wherein if the IAB node is a boundary IAB node that is part of a first IAB topology among the at least two IAB topologies and is also connected to an IAB node of a second IAB topology among 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, and the determination of whether the routing identifier should be updated is based on the first routing configuration information if the determined IAB topology is the first IAB topology, and based on the second routing configuration information if the determined IAB topology is the second IAB topology.

[0413] 37. A method for processing data packets in an IAB node in an IAB communication system, comprising at least two topologies, each having multiple Integrated Access and Backhaul (IAB) nodes, Receiving a data packet containing a routing identifier from the aforementioned IAB node via the ingress backhaul link, Determining the IAB topology associated with the received data packet, Based on the routing identifier of the received data packet, the exit backhaul link to which the data packet is routed to the next IAB node is determined, Determine the IAB topology associated with the next IAB node, Select a backhaul RLC channel for the exit backhaul link based on the determined IAB topology associated with the next IAB node and the backhaul RLC channel mapping configuration table, This includes routing the data packets to the next IAB node via the selected backhaul RLC channel, The aforementioned backhaul RLC channel mapping configuration table includes at least one entity, each entity being: In the routing path, the next-hop address field for the next-hop address of the next IAB node adjacent to the IAB node, An exit topology field for indicating the IAB topology associated with the next IAB node, and for indicating the exit backhaul link between the IAB node and the next IAB node using the next hop address, A preceding hop address field for the preceding hop address of a preceding IAB node in the routing path, An inlet topology field for indicating the IAB topology associated with the preceding IAB node, and for indicating the inlet backhaul link between the IAB node and the preceding IAB node using the preceding hop address field, The inlet backhaul RLC channel identifier field for the backhaul RLC channel identifier of the inlet backhaul link, A method comprising an exit backhaul RLC channel identifier field for a backhaul RLC channel identifier for the exit backhaul link.

[0414] 38. Further includes determining the IAB topology associated with the aforementioned IAB node, Selecting a backhaul RLC channel for the aforementioned exit backhaul link is, In order to determine whether the backhaul RLC channel ID of the exit backhaul link, the address of the previous IAB node, the determined IAB topology associated with the previous IAB node, the address of the next IAB node, and the determined IAB topology associated with the next IAB node match each field of the entry in the backhaul RLC channel mapping configuration table, the backhaul RLC channel mapping configuration table is checked. The method according to clause 37, which includes, if a match with an entry is determined, selecting the backhaul RLC channel of the exit backhaul link using the exit backhaul RLC channel ID of the matched entry.

[0415] 39. A method for processing data packets in an IAB node in an IAB communication system, comprising at least two topologies, each having multiple Integrated Access and Backhaul (IAB) nodes, The IAB node receives a data packet containing a routing identifier, which is generated at the aforementioned IAB node, for routing to another IAB node. Based on the routing identifier of the received data packet, the exit backhaul link to which the data packet is routed to the next IAB node is determined, Determine the IAB topology associated with the next IAB node, Select a backhaul RLC channel for the exit backhaul link based on the determined IAB topology associated with the next IAB node and the backhaul RLC channel mapping configuration table, The data packets are routed to the next IAB node via the selected backhaul RLC channel. Includes, The aforementioned backhaul RLC channel mapping configuration table includes at least one entity, and each entry is: A traffic type identifier field to indicate the traffic type of the data packet to be routed, In the routing path, the next-hop address field for the next-hop address of the next IAB node adjacent to the IAB node, An exit topology field for indicating the IAB topology associated with the next IAB node, and for indicating the exit backhaul link between the IAB node and the next IAB node using the next hop address, A method comprising an exit backhaul RLC channel identifier field for a backhaul RLC channel identifier for the exit backhaul link.

[0416] 40. The method of Clause 39, wherein selecting a backhaul RLC channel for the exit backhaul link includes checking the backhaul RLC channel mapping configuration table to determine whether the traffic type of the received data packet, the address of the next IAB node, and the identified IAB topology associated with the next IAB node match the corresponding fields of entities in the backhaul RLC channel mapping configuration table, and if a match with an entry is determined, using the exit backhaul RLC channel ID of the matched entry to select the backhaul RLC channel for the exit backhaul link.

[0417] 41. The method according to any one of the clauses 37 to 40, wherein the routing identifier of the received data packet includes the destination address of the destination IAB node for the data packet, and determining the exit backhaul link to which the data packet should be routed to the next IAB node includes determining the address of the next IAB node by checking a backhaul routing configuration table using the routing identifier or the destination address of the routing identifier, and determining the exit backhaul link based on the determined address of the next IAB node of the matching entry in the backhaul routing configuration table, wherein the backhaul routing configuration table has at least one entry, each entry of the routing configuration table including at least a routing identifier field for the routing identifier and a next-hop address field for indicating the address of the next IAB node in a routing path identified by the path identifier of the routing identifier.

[0418] 42. If there is no match with an entry in the backhaul routing configuration table, the method further includes checking the routing identifier mapping table using the routing identifier of the received data packet, determining the new routing identifier of the received data packet based on the new routing identifier of the matched entry if there is a match with an entry in the routing identifier mapping table, and updating the routing identifier of the received data packet with the new routing identifier to provide an updated data packet containing the identified new routing identifier, wherein the new routing identifier contains the destination address of the destination IAB node for the data packet, and determining the exit backhaul link to which the data packet should be routed to the next IAB node includes determining the address of the next IAB node by checking the backhaul routing configuration table using the new routing identifier or the destination address of the new routing identifier, and determining the exit backhaul link based on the determined address of the next IAB node of the matched entry if there is a match with an entry in the backhaul routing configuration table.

[0419] 43. A method for managing the processing of data packets in an IAB communication system comprising at least two IAB topologies, each having multiple Integrated Access and Backhaul (IAB) nodes and donor central units (CUs), wherein the method in a first donor CU of a first IAB topology among the at least two IAB topologies includes the following: A method comprising providing data packet routing configuration information for routing data packets through at least the first IAB topology to at least one IAB node of the first IAB topology, wherein the data packet routing configuration information includes a routing configuration table and a routing identifier mapping table, the routing configuration table having at least one entry including a routing identifier field for a routing identifier that includes a destination address field indicating the address of an IAB node and a path identifier field indicating the path identifier of a routing path to the IAB node, a next hop address field indicating the address of the next IAB node in the routing path identified by the path identifier, and a field indicating whether the routing identifier of a received data packet matching the routing identifier in the routing identifier field should be updated, and the routing identifier mapping information having at least one entry including a preceding routing identifier field for a routing identifier, a preceding topology field indicating the IAB topology associated with the routing identifier in the preceding routing identifier field, a new routing identifier field for a routing identifier, and a new topology field indicating the IAB topology associated with the routing identifier in the new routing identifier field.

[0420] 44. The method according to Clause 43, wherein the field for indicating whether the routing identifier of an received data packet matching the routing identifier in the routing identifier field should be updated includes an update field, or at least a portion of the next-hop address field, the value of the update field indicating that the routing identifier should be updated, and a predetermined value in at least a portion of the next-hop address field indicating that the routing identifier should be updated.

[0421] 45. The method of Clause 43 or 44, wherein providing the routing configuration table in the routing configuration information element (IE) of the configuration message for transmission to the at least one IAB node, and providing the routing identifier mapping table in the routing identifier mapping information element (IE) of the configuration message for transmission to the at least one IAB node.

[0422] 46. ​​The method according to any one of the claims 43 to 45, wherein the data packet routing configuration information further includes a backhaul RLC channel mapping configuration table having at least one entry, which includes a next-hop address field for the next IAB node following the at least one IAB node in the routing path, an exit topology field for indicating the IAB topology associated with the next IAB node and for indicating the exit backhaul link between the IAB node and the next IAB node using the next-hop address, an exit backhaul RLC channel identifier field for the backhaul RLC channel for the exit backhaul link, and / or an entry topology field for indicating the previous hop address of a preceding IAB node prior to the IAB node in the routing path, for indicating the IAB topology associated with the preceding IAB node and for indicating the inbound backhaul link between the IAB node and the preceding IAB node using the previous hop address field, an entry backhaul RLC channel identifier field for the backhaul RLC channel for the inbound backhaul link.

[0423] 47. The method according to any one of the claims 43 to 46, further comprising an uplink traffic to backhaul RLC channel mapping configuration table having at least one entry, the data packet routing configuration information includes: a traffic type identifier field for indicating the traffic type of data packets to be routed; a next-hop address field for the next-hop address of a next IAB node adjacent to the IAB node in the routing path; an exit topology field for indicating the IAB topology associated with the next IAB node and for indicating the exit backhaul link between the IAB node and the next IAB node using the next-hop address; and an exit backhaul RLC channel identifier field for the backhaul RLC channel identifier for the backhaul RLC channel for the exit backhaul link.

[0424] 48. The method of Clause 46 or 47, which includes providing the backhaul RLC channel mapping configuration table in the routing configuration information element (IE) of the configuration message for transmission to the at least one IAB node.

[0425] 49. The method according to any one of the clauses 43 to 48, wherein providing the data packet routing configuration information is provided to at least one IAB node of a second IAB topology, which is different from the first IAB topology and is managed by a second donor CU, among the at least two IAB topologies.

[0426] 50. The method according to any one of the 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 routing of data packets between the first IAB topology and the second IAB topology; and receiving a response from the second donor CU including recognition information indicating whether and when the second donor CU has received the request, and configuration information relating to one or more IAB nodes in the second IAB topology for identifying routing paths for routing data packets between at least one IAB node in the first IAB topology and at least one IAB node in the second IAB topology, wherein providing the data packet routing configuration information includes providing the data packet routing configuration information based on the configuration information received from the second donor CU.

[0427] 51. A method for managing the processing of data packets in an IAB communication system comprising at least two IAB topologies, each having multiple Integrated Access and Backhaul (IAB) nodes and donor central units (CUs), wherein the method is performed in a first donor CU of a first IAB topology among the at least two IAB topologies. Sending a request to the second donor CU of the second IAB topology among the at least two IAB topologies to establish routing of data packets between the first IAB topology and the second IAB topology, Receiving a response from the second donor CU that includes acknowledgment information indicating whether the second donor CU has accepted the request and when the second donor CU accepted the request, and configuration information relating to one or more IAB nodes in the second IAB topology for identifying routing paths for routing data packets between at least one IAB node in the first IAB topology and at least one IAB node in the second IAB topology, Includes, The request transmitted to the second donor CU is: An IE that identifies the routing direction of the request, wherein if the routing direction is uplink, the request relates to the routing of data packets from the first IAB topology to the second IAB topology, and if the routing direction is downlink, the request relates to the routing of data packets from the second IAB topology to the first IAB topology. An IE that identifies at least one IAB donor distributed unit (DU) in the second IAB topology used by the first donor CU to transmit or receive data packets, A boundary IAB node for use in the second IAB topology, comprising an IE that identifies the address of the boundary IAB node, which is an IAB node in the first IAB topology connected to an IAB node in the second IAB topology, An IE indicating the destination of the data packet in the downstream direction, which is either a boundary node or another IAB node in the first IAB topology, IE, which shows the expected throughput of the data to be routed, IE, which indicates the quality of service (QoS) of the data to be routed, An IE indicating a backhaul RLC channel identifier ID for use by the first donor CU for the boundary IAB node in the inlet link when routing data in the upstream direction, and / or an IE indicating a backhaul RLC channel identifier ID for use by the first donor CU for the boundary IAB node in the exit link when routing data in the downstream direction, An IE showing the contents of at least one preceding routing identifier field for the routing identifier mapping table when routing data in the upstream direction, and / or the contents of at least one new routing identifier field for the routing identifier mapping table when routing data in the downstream direction, A method that includes at least one of the following IEs.

[0428] 52. The method according to clause 51, wherein the configuration information received from the second donor CU includes at least one IE among: an IE identifying the at least one IAB donor DU in the second IAB topology; an IE identifying the address of the boundary IAB node for use in the second IAB topology; an IE indicating an alias address used by the second donor CU for routing data packets downstream to the boundary IAB node; and an IE indicating a backhaul RLC channel identifier for an RLC channel used by the second donor CU for routing data packets for the boundary IAB node in the second topology, either in the ingress backhaul link or the egress backhaul link. 53. A computer program which, when the program is executed by a processing unit, includes instructions that cause the processing unit to perform an action as described in any of the preceding clauses.

[0429] 54. A computer-readable medium for carrying the computer program described in Clause 53.

[0430] 55. An IAB node for an IAB communication system comprising a plurality of Integrated Access and Backhaul (IAB) nodes, the IAB node having at least one communication interface for communicating with at least one IAB node, and a central processing unit connected to the at least one communication interface and configured to perform the method described in any one of the clauses 1 to 42.

[0431] 56. A donor central unit (CU) for managing the processing of data packets in an IAB communication system comprising at least two IAB topologies, each having multiple Integrated Access and Backhaul (IAB) nodes and donor central units (CUs), the donor CU having at least one communication interface and a processing unit connected to the at least one communication interface and configured to perform the method described in any one of the clauses 43 to 52.

Claims

1. A method for processing data packets in an IAB node of an IAB communication system comprising at least two Integrated Access and Backhaul (IAB) topologies, each IAB topology comprising multiple IAB nodes, Receiving a data packet containing a routing identifier, Before sending the aforementioned data packet to another IAB node, it is determined whether to update the routing identifier, In response to the determination that the aforementioned routing identifier should be updated, Based on the header rewrite configuration information and the routing identifier of the received data packet, a new routing identifier and the associated IAB topology are identified. To provide an updated data packet containing the identified new routing identifier, the received data packet is updated by updating the routing identifier of the received data packet with the identified new routing identifier, Based on the identified IAB topology and the routing configuration information associated with the identified new routing identifier, the system determines the exit backhaul link to which the data packet should be routed to the next IAB node. The updated data packet is transmitted to the next IAB node via the exit backhaul link. A method comprising the header rewrite configuration information, wherein the header rewrite configuration information includes a field for indicating the IAB topology associated with the new routing identifier.

2. The method according to claim 1, characterized in that the received data packet is a BAP data packet having a Backhaul Adaptation Protocol (BAP) header containing the routing identifier.

3. The method according to claim 1, characterized in that the header rewrite configuration information includes a header rewrite configuration table that includes the fields for indicating the IAB topology associated with the new routing identifier.

4. The method according to claim 1, characterized in that determining whether to update the routing identifier before sending the data packet to another IAB node is based on routing configuration information and the routing identifier of the received data packet.

5. The routing configuration information includes a routing configuration table having at least one entry, and each entry in the routing configuration table is: A routing identifier field for a routing identifier, which includes a destination address field indicating the address of the IAB node and a path identifier field indicating the path identifier of the routing 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, The method according to claim 1, characterized by including the following:

6. The method according to claim 1, comprising a routing identifier field for defining a routing identifier, the routing identifier field including a destination address field for the address of an IAB node and a path identifier field for the path identifier of a routing 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, and an additional field for use in determining whether the routing identifier of the received data packet should be updated.

7. The method according to claim 1, further comprising selecting a backhaul RLC channel for the exit backhaul link based on identified IAB topology and backhaul RLC channel mapping information associated with the exit backhaul link.

8. The backhaul RLC channel mapping information includes a backhaul RLC channel mapping configuration table having at least one entry, where each entry is: The next-hop address field for the next-hop address of the next IAB node adjacent to the IAB node in the routing path, An exit topology field for indicating the IAB topology associated with the next IAB node, and for indicating the exit backhaul link between the IAB node and the next IAB node using the next hop address, A preceding hop address field for the preceding hop address of a preceding IAB node that is located before the aforementioned IAB node in the routing path, An inlet topology field for indicating the IAB topology associated with the preceding IAB node, and for indicating the inlet backhaul link between the IAB node and the preceding IAB node using the preceding hop address field, The inlet backhaul RLC channel identifier field for the inlet backhaul RLC channel of the inlet backhaul link, The method according to 7, further comprising an exit backhaul RLC channel identifier field for an exit backhaul RLC channel identifier for the backhaul RLC channel for the exit backhaul link.

9. Receiving a data packet includes receiving the data packet from a preceding IAB node via the ingress BH link. Selecting a backhaul RLC channel for the aforementioned exit backhaul link is, The backhaul RLC channel mapping configuration table is checked to determine whether the inlet backhaul RLC channel identifier of the inlet backhaul link, the address of the preceding IAB node, the IAB topology associated with the preceding IAB node, the address of the next IAB node, and the IAB topology associated with the next IAB node match the respective fields of the entry in the backhaul RLC channel mapping configuration table. If a match with an entry is determined, the backhaul RLC channel of the exit backhaul link is selected using the exit backhaul RLC channel identifier of the matched entry. The method according to 8, characterized by including the following:

10. The backhaul RLC channel mapping information includes a backhaul RLC channel mapping configuration table having at least one entry, where each entry is: A traffic type identifier field to indicate the traffic type of the data packet to be routed, In the routing path, the next-hop address field for the next-hop address of the next IAB node adjacent to the IAB node, An exit topology field for indicating the IAB topology associated with the next IAB node, and for indicating the exit backhaul link between the IAB node and the next IAB node using the next hop address, The exit backhaul RLC channel identifier field for the backhaul RLC channel for the exit backhaul link, The method according to 7, characterized by including the following:

11. Receiving a data packet includes generating the data packet in one part of the IAB node and receiving the data packet in another part of the IAB node for routing to another IAB node. Selecting a backhaul RLC channel for the aforementioned exit backhaul link is, The backhaul RLC channel mapping configuration table is checked to determine whether the traffic type of the received data packet, the address of the next IAB node, and the IAB topology associated with the next IAB node match the corresponding fields of the entries in the backhaul RLC channel mapping configuration table. The backhaul RLC channel mapping configuration table is checked to determine whether the traffic type of the received data packet, the address of the next IAB node, and the IAB topology associated with the next IAB node match the corresponding fields of the entries in the backhaul RLC channel mapping configuration table. If a match with an entry is determined, the backhaul RLC channel of the exit backhaul link is selected using the exit backhaul RLC channel identifier of the matched entry. The method according to the present invention, characterized by including the following:

12. The header rewrite setting information includes a header rewrite setting table having at least one entry, Each entry in the header rewriting settings table is: The preceding routing identifier field for the preceding routing identifier, A new routing identifier field for the new routing identifier, A new topology field for indicating the IAB topology associated with the routing identifier in the new routing identifier field, The method according to claim 1, characterized by including the following:

13. The method according to 12, wherein each entry in the header rewrite setting table further includes a prior topology field for indicating the IAB topology associated with the routing identifier in the preceding routing identifier field.

14. The routing identifier of the received data packet includes the destination address of the destination IAB node for the data packet. Identifying a new routing identifier and the IAB topology associated with the next IAB node to which the data packet is routed, In order to determine whether the routing identifier of the received data packet matches the routing identifier in the preceding 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 header rewrite configuration table is checked, When a match with an entry is determined, the routing identifier in the new routing identifier field of the matched entry is used as the identified new routing identifier, and the IAB topology indicated by the new topology field of the matched entry is used as the identified IAB topology. The method according to 12, characterized by including the following:

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

16. The new routing identifier includes the destination address of the destination IAB node for the data packet, Determining the exit backhaul link is To determine whether the identified new routing identifier matches the routing identifier in the new routing identifier field of the entry, or whether the destination address of the new routing identifier matches the destination address in the destination address field of the entry, the routing configuration table associated with the identified IAB topology is checked. When determining whether an entry matches, the next hop address in the next hop address field of the matched entry is used to determine the next IAB node. The method according to feature 14.

17. The IAB node is a boundary node such that it is part of a first IAB topology among the at least two IAB topologies and is also connected to an IAB node of a second IAB topology among the at least two IAB topologies, and the IAB node has a first address associated with the first IAB topology and a second address associated with the second IAB topology. The aforementioned method, Identifying the IAB topology associated with the received data packet, The system determines whether a received data packet should be transported to the upper layer of the IAB node by checking whether the destination address of the routing identifier matches either the first address or the second address of the IAB node, by comparing the destination address of the routing identifier with either the first address or the second address of the IAB node. Includes, In the comparison described above, either the first address or the second address of the IAB node used is an address associated with the same topology as the topology associated with the received data packet. The method according to feature 1.

18. Receiving a data packet includes receiving the data packet from the preceding IAB node via the ingress backhaul link. The method further includes determining the IAB topology associated with the received data packet by determining the IAB topology associated with the ingress backhaul link. The method according to feature 1.

19. The method according to claim 1, 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 routed is either the same IAB topology or the other IAB topology among the at least two IAB topologies.

20. The method according to claim 1, further comprising receiving routing configuration information and header rewriting configuration information from a Control Unit (CU) of at least one of the donors in the at least two IAB topologies.

21. A method for processing data packets at an IAB node in an IAB communication system, comprising at least two IAB topologies, each having multiple Integrated Access and Backhaul (IAB) nodes, The data packet containing the routing identifier is received from the aforementioned IAB node via the ingress backhaul link; Based on the routing identifier of the received data packet, the exit backhaul link to which the data packet is routed to the next IAB node is determined, Based on the backhaul RLC channel mapping setting table, select the backhaul RLC channel for the exit backhaul link, The data packets are routed to the next IAB node via the selected backhaul RLC channel. Includes, The aforementioned backhaul RLC channel mapping configuration table includes at least one entry, each entry being: In the routing path, the next-hop address field for the next-hop address of the next IAB node adjacent to the IAB node, An exit topology field for indicating the IAB topology associated with the next IAB node, and for indicating the exit backhaul link between the IAB node and the next IAB node using the next hop address, A preceding hop address field for the preceding hop address of a preceding IAB node that is located before the aforementioned IAB node in the routing path, An inlet topology field for indicating the IAB topology associated with the preceding IAB node, and for indicating the inlet backhaul link between the IAB node and the preceding IAB node using the preceding hop address field, The inlet backhaul RLC channel identifier field for the inlet backhaul RLC channel of the inlet backhaul link, Includes an exit backhaul RLC channel identifier field for the exit backhaul RLC channel identifier for the exit backhaul link, A method characterized by the following:

22. Selecting a backhaul RLC channel for the aforementioned exit backhaul link is, In order to determine whether the inlet backhaul RLC channel identifier of the inlet backhaul link, the address of the preceding IAB node, the IAB topology associated with the preceding IAB node, the address of the next IAB node, and the IAB topology associated with the next IAB node match the respective fields of the entry in the backhaul RLC channel mapping configuration table, the backhaul RLC channel mapping configuration table is checked. If a match with an entry is determined, the backhaul RLC channel of the exit backhaul link is selected using the exit backhaul RLC channel identifier of the matched entry. The method according to claim 21, characterized by including the following:

23. A method for processing data packets at an IAB node in an IAB communication system, comprising at least two IAB topologies, each having multiple Integrated Access and Backhaul (IAB) nodes, Receiving a data packet generated at the aforementioned IAB node, which includes a routing identifier, for routing to another IAB node, Based on the routing identifier of the received data packet, the exit backhaul link to which the data packet is routed to the next IAB node is determined, Based on the backhaul RLC channel mapping setting table, select the backhaul RLC channel for the exit backhaul link, The data packets are routed to the next IAB node via the selected backhaul RLC channel. Includes, The aforementioned backhaul RLC channel mapping configuration table includes at least one entry, each entry being: A traffic type identifier field to indicate the traffic type of the data packet to be routed, In the routing path, the next-hop address field for the next-hop address of the next IAB node adjacent to the IAB node, An exit topology field for indicating the IAB topology associated with the next IAB node, and for indicating the exit backhaul link between the IAB node and the next IAB node using the next hop address, The exit backhaul RLC channel identifier field for the backhaul RLC channel for the exit backhaul link, A method characterized by including the following.

24. Selecting a backhaul RLC channel for the aforementioned exit backhaul link is, The backhaul RLC channel mapping configuration table is checked to determine whether the traffic type of the received data packet, the address of the next IAB node, and the IAB topology associated with the next IAB node match the corresponding fields of the entries in the backhaul RLC channel mapping configuration table. If a match with an entry is determined, the backhaul RLC channel of the exit backhaul link is selected using the exit backhaul RLC channel identifier of the matched entry. The method according to 23, characterized by including the following:

25. A method for managing the processing of data packets in an IAB communication system, comprising at least two IAB topologies, each having multiple Integrated Access and Backhaul (IAB) nodes and Donor Central Units (CUs), The method in the first donor CU of the first IAB topology among the at least two IAB topologies is To provide data packet routing configuration information for routing data packets to at least one IAB node of the first IAB topology via at least the first IAB topology, the data packet routing configuration information including a routing configuration table and a header rewriting configuration table. Includes, The routing configuration table has at least one entry that includes a routing identifier field for a routing identifier, which includes a destination address field indicating the address of an IAB node and a path identifier field indicating the path identifier of the routing path to the IAB node, and a next-hop address field for indicating the address of the next IAB node in the routing path identified by the path identifier, The header rewrite configuration table has at least one entry that includes a preceding routing identifier field for a routing identifier, a new routing identifier field for a routing identifier, and a new topology field for indicating the IAB topology associated with the routing identifier in the new routing identifier field. A method characterized by the following:

26. The method according to 25, characterized in that providing includes providing the routing configuration table in the routing configuration information element (IE) of the configuration message for transmission to the at least one IAB node, and providing the header rewrite configuration table in the header rewrite configuration information element (IE) of the configuration message for transmission to the at least one IAB node.

27. ​​The data packet routing configuration information further includes: The next-hop address field for the next-hop address of the next IAB node following the at least one IAB node in the routing path, An exit topology field for indicating the IAB topology associated with the next IAB node, and for indicating the exit backhaul link between the IAB node and the next IAB node using the next hop address, The exit backhaul RLC channel identifier field for the backhaul RLC channel for the exit backhaul link, and / or, The preceding hop address field for the preceding hop address of a preceding IAB node that is located before the aforementioned IAB node in the routing path, An inlet topology field for indicating the IAB topology associated with the preceding IAB node, and for indicating the inlet backhaul link between the IAB node and the preceding IAB node using the preceding hop address field, The inlet backhaul RLC channel identifier field for the inlet backhaul RLC channel identifier of the inlet backhaul link, The method according to 25, characterized in that it has a backhaul RLC channel mapping configuration table having at least one entry including

28. Sending a request to the second donor CU of the second IAB topology among the at least two IAB topologies to establish routing of data packets between the first IAB topology and the second IAB topology, Receiving a response from the second donor CU that includes acknowledgment information indicating whether the second donor CU has accepted the request and when the second donor CU accepted the request, and configuration information relating to one or more IAB nodes in the second IAB topology for identifying routing paths for routing data packets between at least one IAB node in the first IAB topology and at least one IAB node in the second IAB topology, It further includes, Providing the data packet routing configuration information includes providing the data packet routing configuration information based on the configuration information received from the second donor CU. The method according to the present invention of the present invention.

29. A method for managing the processing of data packets in an IAB communication system, comprising at least two IAB topologies, each having multiple Integrated Access and Backhaul (IAB) nodes and a Donor Central Unit (CU), wherein the method in the first Donor CU of the first IAB topology among the at least two IAB topologies is This includes providing data packet routing configuration information to at least one IAB node of the first IAB topology for routing data packets through the first IAB topology, The data packet routing configuration information includes a header rewrite configuration table that contains a field for indicating the IAB topology associated with the new routing identifier. A method characterized by the following:

30. A method for managing the processing of data packets in an IAB communication system, comprising at least two IAB topologies, each having multiple Integrated Access and Backhaul (IAB) nodes and a Donor Central Unit (CU), wherein the method in the first Donor CU of the first IAB topology among the at least two IAB topologies is This includes providing data packet routing configuration information to at least one IAB node of the first IAB topology for routing data packets through the first IAB topology, The aforementioned data packet routing configuration information, The next-hop address field for the next-hop address of the next IAB node following the at least one IAB node in the routing path, An exit topology field for indicating the IAB topology associated with the next IAB node, and for indicating the exit backhaul link between the IAB node and the next IAB node using the next hop address, The exit backhaul RLC channel identifier field for the backhaul RLC channel for the exit backhaul link, and / or The preceding hop address field for the preceding hop address of a preceding IAB node that is located before the aforementioned IAB node in the routing path, An inlet topology field for indicating the IAB topology associated with the preceding IAB node, and for indicating the inlet backhaul link between the IAB node and the preceding IAB node using the preceding hop address field, The inlet backhaul RLC channel identifier field for the inlet backhaul RLC channel identifier of the inlet backhaul link, A method comprising a backhaul RLC channel mapping configuration table having at least one entry including

31. The aforementioned data packet routing configuration information further includes, A traffic type identifier field to indicate the traffic type of data packets to be routed. The next-hop address field for the next-hop address of the next IAB node adjacent to the IAB node in the routing path, An exit topology field for indicating the IAB topology associated with the next IAB node, and for indicating the exit backhaul link between the IAB node and the next IAB node using the next hop address, and The method according to 30, comprising an uplink traffic versus backhaul RLC channel mapping configuration table having at least one entry including an outlink backhaul RLC channel identifier field for an outlink backhaul RLC channel identifier for the outlink backhaul link.

32. The method according to 30, characterized in that it provides the backhaul RLC channel mapping configuration table in the routing configuration information element (IE) of the configuration message for transmission to the at least one IAB node.

33. A method for managing the processing of data packets in an IAB communication system, comprising at least two IAB topologies, each having multiple Integrated Access and Backhaul (IAB) nodes and a Donor Central Unit (CU), wherein the method in the first Donor CU of the first IAB topology among the at least two IAB topologies is This includes providing data packet routing configuration information to at least one IAB node of the first IAB topology for routing data packets through the first IAB topology, The aforementioned data packet routing configuration information is: A traffic type identifier field to indicate the traffic type of data packets to be routed. The next-hop address field for the next-hop address of the next IAB node adjacent to the IAB node in the routing path, An exit topology field for indicating the IAB topology associated with the next IAB node, and for indicating the exit backhaul link between the IAB node and the next IAB node using the next hop address, and For the exit backhaul link, the exit backhaul RLC channel identifier field for the backhaul RLC channel of the aforementioned exit backhaul link, A method comprising a backhaul RLC channel mapping configuration table having at least one entry including

34. A method for processing data packets in an IAB node of an IAB communication system comprising at least two Integrated Access and Backhaul (IAB) topologies, each IAB topology comprising multiple IAB nodes, (a) Receiving a data packet containing a routing identifier, (b) Determine the IAB topology associated with the received data packet, (c) Determining whether the received data packet should be transported to the upper layer of the IAB node. (d) In response to the determination that the received data packet should not be transported to a higher layer, determine whether there is an available exit backhaul link for routing the data to the next IAB node, based on the routing configuration information associated with the determined IAB topology and the routing identifier of the received data packet. (e) Determining whether the routing identifier of the received data packet should be updated in response to the determination that there is no exit backhaul link available for routing the data. (f) In response to the determination that the routing identifier of the received data packet should be updated, the system determines a new routing identifier and the IAB topology associated with the new routing identifier, and updates the received data packet by updating the routing identifier of the received data packet using the determined new routing identifier, in order to provide an updated data packet containing the determined new routing identifier, and (g) Repeat at least step (c) for the updated data packet. A method characterized by including the following.

35. The method according to 34, characterized in that the repetition includes repeating steps (c) to (f) for at least one cycle for the updated data packet until it is determined that the updated data packet should be transported to the upper layer, or until it is determined that the routing identifier should not be updated.

36. A computer program that, when the computer program is executed by a processing unit, includes an instruction that causes the processing unit to perform the method according to any one of claims 1, 21, 23, and 30.

37. A computer-readable medium for transporting the computer program described in claim 36.

38. An IAB node device of an IAB communication system comprising at least two Integrated Access and Backhaul (IAB) topologies, each IAB topology comprising multiple IAB nodes, Processing unit and A memory that can be operably connected to the aforementioned processing unit, and which, when executed by the aforementioned processing unit, is connected to the aforementioned processing unit. Before sending a received data packet to another IAB node, determine whether to update the routing identifier of that data packet, In response to the determination that the aforementioned routing identifier should be updated, Based on the header rewrite configuration information and the routing identifier of the received data packet, a new routing identifier and the associated IAB topology are identified. To provide an updated data packet containing the identified new routing identifier, the received data packet is updated by updating the routing identifier of the received data packet with the identified new routing identifier, Based on the identified IAB topology and the routing configuration information associated with the identified new routing identifier, the system determines the exit backhaul link to which the data packet should be routed to the next IAB node. The updated data packet is provided to the next IAB node for transmission via the exit backhaul link, It has a memory that stores instructions to execute, The device is characterized in that the header rewrite configuration information includes a field for indicating the IAB topology associated with the new routing identifier.

39. The apparatus according to claim 38, characterized in that the received data packet is a BAP data packet having a Backhaul Adaptation Protocol (BAP) header containing the routing identifier.

40. The apparatus according to claim 38, wherein the header rewrite configuration information includes a header rewrite configuration table that includes a field for indicating the IAB topology associated with the new routing identifier.

41. Routing configuration information includes a routing configuration table having at least one entry. Each entry in the aforementioned routing configuration table is: A routing identifier field for a routing identifier, which includes a destination address field indicating the address of the IAB node and a path identifier field indicating the path identifier of the routing 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, The apparatus according to claim 38, characterized by including the following:

42. The apparatus according to claim 38, wherein the routing configuration information includes a routing configuration table, the routing configuration table comprising a routing identifier field for defining a routing identifier, the routing identifier field comprising a destination address field for the address of an IAB node and a path identifier field for a path identifier of a routing path to the IAB node, a next-hop address field for indicating the address of the next IAB node in the routing path identified by the path identifier, and an additional field for use in determining whether the routing identifier of the received data packet should be updated.

43. The apparatus according to claim 38, characterized in that when the instruction is executed by the processing unit, it causes the processing unit to select a backhaul RLC channel for the exit backhaul link based on the identified IAB topology and backhaul RLC channel mapping information associated with the exit backhaul link.

44. The backhaul RLC channel mapping information includes a backhaul RLC channel mapping configuration table having at least one entry. Each entry is In the routing path, the next-hop address field for the next-hop address of the next IAB node adjacent to the IAB node, An exit topology field for indicating the IAB topology associated with the next IAB node, and for indicating the exit backhaul link between the IAB node and the next IAB node using the next hop address, A preceding hop address field for the preceding hop address of a preceding IAB node that is located before the aforementioned IAB node in the routing path, An inlet topology field for indicating the IAB topology associated with the preceding IAB node, and for indicating the inlet backhaul link between the IAB node and the preceding IAB node using the preceding hop address field, The inlet backhaul RLC channel identifier field for the inlet backhaul RLC channel of the inlet backhaul link, The exit backhaul RLC channel identifier field for the backhaul RLC channel for the exit backhaul link, The apparatus according to claim 43, characterized by including the following:

45. The aforementioned data packet is received at the IAB node from the aforementioned IAB node via the ingress BH link. The aforementioned processing unit is In order to determine whether the inlet backhaul RLC channel identifier of the inlet backhaul link, the address of the preceding IAB node, the IAB topology associated with the preceding IAB node, the address of the next IAB node, and the IAB topology associated with the next IAB node match the respective fields of the entry in the backhaul RLC channel mapping configuration table, the backhaul RLC channel mapping configuration table is checked. If a match with an entry is determined, the backhaul RLC channel of the exit backhaul link is selected using the exit backhaul RLC channel identifier of the matched entry. The apparatus according to claim 44, characterized in that it is configured to select a backhaul RLC channel for the outlet backhaul link by means of the above.

46. The backhaul RLC channel mapping information includes a backhaul RLC channel mapping configuration table having at least one entry. Each entry is A traffic type identifier field to indicate the traffic type of the data packet to be routed, In the routing path, the next-hop address field for the next-hop address of the next IAB node adjacent to the IAB node, An exit topology field for indicating the IAB topology associated with the next IAB node, and for indicating the exit backhaul link between the IAB node and the next IAB node using the next hop address, The exit backhaul RLC channel identifier field for the backhaul RLC channel for the exit backhaul link, The apparatus according to claim 43, characterized by including the following:

47. The data packet is generated in one part of the IAB node and received in another part of the IAB node for transmission to another IAB node, and the processing unit, The backhaul RLC channel mapping configuration table is checked to determine whether the traffic type of the received data packet, the address of the next IAB node, and the IAB topology associated with the next IAB node match the corresponding fields of the entries in the backhaul RLC channel mapping configuration table. If a match with an entry is determined, the backhaul RLC channel of the exit backhaul link is selected using the exit backhaul RLC channel identifier of the matched entry. The apparatus according to claim 46, characterized in that it is configured to select a backhaul RLC channel for the outlet backhaul link by means of the above.

48. An IAB node for an IAB communication system including multiple Integrated Access and Backhaul (IAB) nodes, At least one communication interface for communicating with at least one IAB node, A processing unit connected to at least one communication interface and configured to perform the method according to claim 1, An IAB node characterized by having the following features.

49. A Donor Central Unit (CU) for managing the processing of data packets in an IAB communication system, which includes at least two IAB topologies, each having multiple Integrated Access and Backhaul (IAB) nodes and Donor Central Units (CUs), At least one communication interface, A processing unit connected to at least one communication interface and configured to perform the method according to claim 25, A donor CU characterized by having the following features.

Images