WO2021005456A1

WO2021005456A1 - Remapping of bearers in iab networks

Info

Publication number: WO2021005456A1
Application number: PCT/IB2020/056200
Authority: WO
Inventors: Oumer Teyeb; Liang Hu; Ajmal MUHAMMAD
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2019-07-11
Filing date: 2020-06-30
Publication date: 2021-01-14

Abstract

A method of remapping a bearer in an integrated access and wireless backhaul (IAB) network and an IAM node are provided that perform operations including determining whether to remap an ingress back haul, BH, radio link channel, RLC, channel having an associated first logical channel identifier, LCID, from an egress to BH RLC channel having the associated first LCID to an egress BH RLC channel having an associated second LCID different from the first LCID. The operations include responsive to determining to remap the ingress BH RLC channel having the associated first LCID, remapping the bearer from the ingress BH RLC channel having the associated first LCID to the egress BH RLC channel having the associated second LCID different from the first LCID.

Description

REMAPPING OF BEARERS IN IAB NETWORKS

TECHNICAL FIELD

[0001] The present disclosure is related to communication systems and more particularly to how bearers are remapped in integrated access and wireless access backhaul networks.

BACKGROUND

[0002] 3GPP is currently standardizing integrated access and wireless access backhaul in new radio (IAB) in Rel-16 (RP-RP-182882).

[0003] The usage of short range mmWave spectrum in new radio (NR) creates a need for densified deployment with multi-hop backhauling. However, optical fiber to every base station may be too costly and sometimes not even possible (e.g. historical sites). The main IAB principle is the use of wireless links for the backhaul (instead of fiber) to enable flexible and very dense deployment of cells without the need for densifying the transport network. Use case scenarios for IAB can include coverage extension, deployment of massive number of small cells and fixed wireless access (FWA) (e.g. to residential/office buildings). The larger bandwidth available for NR in mmWave spectrum may provide opportunity for self-backhauling, without limiting the spectrum to be used for the access links. On top of that, the inherent multi-beam and MIMO support in NR may reduce cross-link interference between backhaul and access links allowing higher densification.

[0004] During the study item phase of the IAB work (summary of the study item can be found in the technical report TR 38.874), an agreement was reached to adopt a solution that leverages the Central Unit (CU)/Distributed Unit (DU) split architecture of NR, where the IAB node will be hosting a DU part that is controlled by a central unit. The IAB nodes also have a Mobile Termination (MT) part that they use to communicate with their parent nodes.

[0005] IAB strives to use existing functions and interfaces defined for access. In particular, MT, generation node B distributed unit, gNB-DU, generation node B central unit, gNB-CU, user plane function, UPF, access and mobility function, AMF, and session management function, SMF, as well as the corresponding interfaces NR Uu (between MT and gNB), FI, NG, X2 and N4 may be used as baseline for the IAB architectures. Modifications and/or enhancements to these functions and interfaces for the support of IAB will be explained in the context of the architecture discussion. Additional functionality such as multi- hop forwarding is included in the architecture discussion as it is necessary for the

understanding of IAB operation.

[0006] The Mobile-Termination (MT) function has been defined as a component of the Mobile Equipment. In the context of this study, MT is referred to as a function residing on an IAB-node that terminates the radio interface layers of the backhaul Uu interface toward the IAB -donor or other IAB -nodes.

[0007] Figure 1 shows a reference diagram for IAB in standalone mode, which contains one IAB -donor and multiple IAB -nodes. The IAB -donor may be treated as a single logical node that comprises a set of functions such as gNB-DU, gNB-CU control plane, gNB- CU-CP, gNB-CU user plane, gNB-CU-UP and potentially other functions. In a deployment, the IAB -donor can be split according to these functions, which can all be either collocated or non-collocated as allowed by 3GPP NG-RAN architecture. IAB-related aspects may arise when such split is exercised. Some of the functions presently associated with the IAB -donor may eventually be moved outside of the donor in case it becomes evident that they do not perform IAB -specific tasks

[0008] A decision was made to standardize using the architecture illustrated in Figure 2, which illustrates baseline user plane and control plane protocol stacks for IAB in rel-16. The proposed user plane (UP) and control plane (CP) protocol stacks for the selected architecture is shown in Figures 3 and 4.

[0009] As shown in Figure 3, the chosen protocol stacks reuse the current CU- DU split specification in rel-15, where the full user plane Fl-U (GTP-U/UDP/IP) is terminated at the IAB node (like a normal DU) and the full control plane Fl-C (Fl- AP/SCTP/IP) is also terminated at the IAB node (like a normal DU). In the above cases, Network Domain Security (NDS) has been employed to protect both UP and CP traffic (IPsec in the case of UP, and datagram transport layer security, DTFS, in the case of CP). IPsec could also be used for the CP protection instead of DTFS (in this case no DTFS layer would be used).

[0010] A new protocol layer, called Backhaul Adaption Protocol (BAP) (and abbreviated as "Adapt" in Figure 3), has been introduced in the IAB nodes and the IAB donor, which is used for routing of packets to the appropriate downstream/upstream node and also mapping the UE bearer data to the proper backhaul RFC channel (and also between backhaul RFC channels in intermediate IAB nodes) to satisfy the end to end QoS requirements of bearers. [0011] The UE may establish RLC channels to the DU on the UE's access IAB- node in compliance with TS 38.300. Each of these RLC-channels is extended via Fl-U between the UE's access DU and the I AB -donor. The information embedded in Fl-U is carried over backhaul RLC-channels across the backhaul links. Transport of Fl-U over the wireless backhaul will be performed by the BAP. Since BAP is a newly defined layer for IAB networks, hence, 3GPP has made only the following agreements related to the BAP layer functionality:

- RAN2 confirms that routing and bearer mapping (e.g. mapping of BH RLC

channels) are BAP layer functions.

- RAN2 assumes that the TX part of the BAP layer performs routing and“bearer mapping”, and the RX part of the BAP layer performs“bearer de-mapping”.

- RAN2 assumes that SDUs are forwarded from the RX part of the BAP layer to the TX part of the BAP layer (for the next hop) for packets that are relayed by the IAB node.

- It is FFS how to model BAP layer protocol entities, e.g. whether separate for DU and MT or not, and how these are configured, i.e. via Fl-AP or RRC.

[0012] Furthermore, for the BAP routing, 3GPP made the following agreements:

The BAP routing id (carried in the BAP header) consists of BAP address and BAP path ID. Encoding of the path ID in the header is FFS.

Each BAP address defines a unique destination (unique for IAB network of one donor-IAB, either an IAB access node, or the IAB donor)

Each BAP address can have one or multiple entries in the routing table to enable local route selection. Multiple entries are for load balancing, re-routing at RLF. For load balancing still FFS what is decided locally and/or decided by the Donor.

Each BAP routing id has only one entry in the routing table.

The routing table can hold other information, e.g. priority level for entries with same BAP address, to support local selection. Configuration of this information is optional.

Load balancing by routing by donor-IAB CU shall be possible.

Local selection of path/route is done at link failure, other cases FFS.

[0013] An IAB -node may need to multiplex the UE dedicated radio bearers

(DRBs) to the BH RLC-Channel. The following two options can be considered on bearer mapping in IAB -node.

[0014] Option 1. One-to-one (1 : 1) mapping between UE DRB and BH RLC- channel, an example of which is illustrated in Figure 4. In this option, each UE DRB may be mapped onto a separate BH RLC-channel. Further, each BH RLC-channel may be mapped onto a separate BH RLC-channel on the next hop. The number of established BH RLC- channels is equal to the number of established UE DRBs. Identifiers (e.g. for the UE and/or DRB) may be required (e.g. if multiple BH RLC-channels are multiplexed into a single BH logical channel). Which exact identifiers are needed, and which of these identifier(s) are placed within the adaptation layer header depends on the architecture/protocol option.

[0015] Option 2. Many-to-one (N: l) mapping between UE DRBs and BH RLC- channel, an example of which is illustrated in Figure 5. For the many-to-one mapping, several UE DRBs may be multiplexed onto a single BH REC-channel based on specific parameters such as bearer QoS profile. Other information such as hop-count could also be configured. The IAB-node can multiplex UE DRBs into a single BH RLC-channel even if they belong to different UEs. Furthermore, a packet from one BH RLC-channel may be mapped onto a different BH RLC-channel on the next hop (details of IAB L2 structure for bearer multiplexing are given in section 8.2.5 of TR 38.874). All traffic mapped to a single BH RLC-channel may receive the same QoS treatment on the air interface.

[0016] Since the BH RLC-channel multiplexes data from/to multiple bearers, and possibly even different UEs, each data block transmitted in the BH RLC-channel needs to contain an identifier of the UE, DRB, and/or IAB-node it is associated with. Which exact identifiers are needed, and which of these identifier(s) are placed within the adaptation layer header depends on the architecture/protocol option.

[0017] With respect to bearer mapping, 3GPP has made the following agreements:

Confirm that the intention is to support 1 :1 and N: 1 bearer mapping, for UE bearers, at least for UP.

For user plane, The UL mapping in the IAB access node to BH RLC channels should be based on the knowledge about UE bearers (identified with GTP TEID)

For control plane (Fl-C messages) The UL mapping in the IAB access node to BH RLC channels should be based on Fl-C message type. FFS if per UE.

FFS if the mapping should also consider DSCP/FIow labels (e.g. as an intermediate step).

Observation: The UL/DL mapping in intermediate IAB node(s) to egress BH RLC channel will take into account ingress BH RLC channel.

FFS: The UL DL mapping in intermediate IAB node(s) to egress BH RLC channel could also take into account some ID(s) (from BAP Layer).

The above two Bullets are applicable for all types of traffic (e.g. UP, CP, OAM).

SUMMARY

[0018] According to some embodiments of inventive concepts, a method may be provided to remap a bearer in an integrated access and wireless backhaul, IAB network. The method may include determining whether to remap an ingress back haul, BH, radio link channel, RLC, channel having an associated first logical channel identifier, LCID, to an egress BH RLC channel having an associated second LCID different from the first LCID. The method may further include responsive to determining to remap the ingress BH RLC channel having the associated first LCID, remapping the bearer from the ingress BH RLC channel having the associated first LCID to the egress BH RLC channel having the associated second LCID different from the first LCID.

[0019] Advantages of the inventive concepts described may include the enabling of the possibility to perform bearer remapping at intermediate hops, which may be required due to several reasons such as re-routing due to radio link failure or mismatch of LCID spaces between different hops (e.g. due to IAB nodes implementing different NR releases). Further advantages that may result may ensure that any QoS granularity that may be lost during a remapping at one hop can be undone at a subsequent hop, by including an optional information of the original bearer mapping on the BAP header. This optional information can be used by an intermediate IAB node to remap the packet back to the original LCID that was used to route the packet before the previous remapping was performed.

[0020] According to other embodiments of inventive concepts, an integrated access and wireless backhaul (IAB) node configured to operate in a communication network is provided. The IAB node includes processing circuitry; and memory coupled with the processing circuitry, wherein the memory includes instructions that when executed by the processing circuitry causes the IAB node to perform operations. The operations include determining whether to remap an ingress back haul, BH, radio link channel, RLC, channel having an associated first logical channel identifier, LCID, to an egress BH RLC channel having an associated second LCID different from the first LCID. The operations include responsive to determining to remap the ingress BH RLC channel having the associated first LCID, remapping (1306) a bearer from the ingress BH RLC channel having the associated first LCID to the egress BH RLC channel having the associated second LCID different from the first LCID.

[0021] Analogous computer program products are also provided.

BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The accompanying drawings, which are included to provide a further understanding of the disclosure and are incorporated in and constitute a part of this application, illustrate certain non-limiting embodiments of inventive concepts. In the drawings:

[0023] Figure 1 illustrates a block diagram of IAB architectures. [0024] Figure 2 is a block diagram illustrating the baseline user plane, UP, protocol stack and control plane, CP, protocol stack for the IAB.

[0025] Figure 3 is block diagrams illustrating potential architectures to implement

IAB.

[0026] Figure 4 is a diagram illustrating an example of a one-to-one mapping between UE DRB and BF1 RLC-channel in accordance with some concepts.

[0027] Figure 5 is a diagram illustrating an example of a many-to-one mapping between UE DRBs and BF1 RLC-channel in accordance with some concepts.

[0028] Figure 6 is a diagram illustrating an example of an IAB network with both N:1 and 1:1 mapping between UE DRBs and BF1 RLC-channels.

[0029] Figure 7 is a diagram illustrating an example of an IAB network with N: 1 mapping between UE DRBs and BF1 RLC-channels.

[0030] Figure 8 is a diagram illustrating an example of an IAB network according to some embodiments of inventive concepts.

[0031] Figure 9 is a diagram illustrating an example of an IAB network according to some embodiments of inventive concepts

[0032] Figure 10 is a block diagram of user equipment node in accordance with some embodiments of inventive concepts.

[0033] Figure 11 is a block diagram of an IAB node in accordance with some embodiments of inventive concepts.

[0034] Figure 12 is a flow chart illustrating an embodiment of remapping a bearer in an IAB network in accordance with some embodiments of inventive concepts.

[0035] Figure 13 is a flow chart illustrating an embodiment of remapping a bearer in an IAB network in accordance with some embodiments of inventive concepts.

DETAILED DESCRIPTION

[0036] Inventive concepts will now be described more fully hereinafter with reference to the accompanying drawings, in which examples of embodiments of inventive concepts are shown. Inventive concepts may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of present inventive concepts to those skilled in the art. It should also be noted that these embodiments are not mutually exclusive. Components from one embodiment may be tacitly assumed to be present/used in another embodiment. [0037] The following description presents various embodiments of the disclosed subject matter. These embodiments are presented as teaching examples and are not to be construed as limiting the scope of the disclosed subject matter. For example, certain details of the described embodiments may be modified, omitted, or expanded upon without departing from the scope of the described subject matter. For example, some of the functions presently associated with the IAB-donor or the IAB node may be moved outside of the donor or node in case it becomes evident that they do not perform IAB-specific tasks.

[0038] PROBLEM AND POTENTIAL ADVANTAGES

[0039] As agreed upon by 3GPP, the BAP of an intermediate IAB-node can reroute the traffic locally (i.e., by itself) under certain conditions such as a backhaul radio link failure (RLF). Flowever, what is agreed upon so far is regarding the routing aspect and not the bearer mapping. It is not clear on what the IAB node will do if there is a bearer that was mapped to a BF1 RLC channel (e.g. logical channel identifier x (LCIDx)) and a similar BF1 RLC channel with the same LCID (i.e. able to provide the same QoS guarantee) is not available on the new route. This can be important in the case of bearers that are mapped 1 : 1, as they require a dedicated BF1 RLC channel on all the hops, and there will not be a dedicated BF1 RLC channel on the new route for that bearer.

[0040] Consider the IAB network shown in figure 6, some of the UE bearers, e.g., for UE1 and UE2 served by IAB5 are mapped in N: 1 manner to a BF1 RLC channel on all the links of its path with IAB-donor (i.e., path IAB-donor-IAB l-IAB2-IAB4-IAB5) while a UE bearer for UE3 is mapped 1 : 1 (i.e., over a dedicated BF1 RLC channel 2) over the same path. Similarly, the UE bearers for UE4, UE5, and UE6 connected to IAB6 are mapped to BF1 RLC channel 3 (using N: 1 bearer mapping) on all the links of its path with the IAB-donor (i.e., path IAB-donor-IABl-IAB3-IAB4-IAB6).

[0041] If an RLF occurs at the link between IAB 1 and IAB2, based on pre configuration (by the IAB-donor CU), IAB 1 can reroute the traffic that was intended to be sent via IAB 2 towards IAB 3. Since there is only one BH RLC channel setup between IAB 1 and IAB 3, the IAB1 may decide to remap all the traffic (formerly carried by BH RLC channel 1 and BH RLC channel 2 between IAB 1 and IAB2) into the BH RLC channel 3 with IAB3. Hence, the originally 1 :1 mapped bearer for UE3 traffic will be remapped on the N: 1 BH bearer over the rerouted link from IAB1 to IAB 3. As there has been more than one BH RLC channel between IAB 1 and IAB 3, each mapped N: l, it is not clear on which one of them the IAB1 will remap the traffic to. Additionally , on the next link between IAB3 and IAB4, the originally 1 : 1 mapped traffic for UE3 will be mapped to BH RLC channel 3 in N: 1 manner. [0042] Finally, on the last link (between IAB4 and IAB5) of the path from IAB- donor to IAB5, the dedicated 1: 1 bearer for UE3 traffic is still active. However, since the IAB4 is configured to map the UE3 traffic received at the ingress BH RLC channel 2 (coming from the IAB2) onto this dedicated BH RLC channel (BH RLC channel 2), it will not be possible for the IAB4 to know that the same UE3 traffic is now forwarded by the IAB3 via the N:1 mapped BH RLC channel 1. Thus, IAB4 will use the egress BH RLC channel 1 for UE3 traffic despite the existence/availability of dedicated BH RLC channel (channel 2) for the UE3 traffic on the same link.

[0043] Similarly, Figure 7 illustrates another scenario where traffic for UE1 and UE2 is mapped to BH RLC channel 1 and traffic for UE3 and UE4 is mapped to BH RLC channel 2 (using N:1 mapping) on all the links of the path from IAB -donor and IAB5.

Similarly, traffic for UE5, UE6, and UE7 is mapped to BH RLC channel 3 (using N: 1 mapping) on all the links of the path from IAB-donor to IAB6. In a similar situation explained above for figure 6 (i.e., the occurrence of RLF and consequently the rerouting and remapping of traffic for UE1, UE2, and UE3 to the only BH RLC channel available between IAB1 and IAB3), the traffic of UE3 and UE4 will be mapped to BH RLC channel 1 even on the link between IAB4 and IAB5, despite the availability of a separate egress BH RLC channel (BH RLC channel 2) for these UEs traffic.

[0044] Advantages of the inventive concepts described may include the enabling of the possibility to perform bearer remapping at intermediate hops, which may be required due to several reasons such as re-routing due to radio link failure or mismatch of LCID spaces between different hops (e.g. due to IAB nodes implementing different NR releases).

[0045] Further advantages that may result may ensure that any QoS granularity that may be lost during a remapping at one hop can be undone at a subsequent hop, by including an optional information of the original bearer mapping on the BAP header. This optional information can be used by an intermediate IAB node to remap the packet back to the original LCID that was used to route the packet before the previous remapping was performed.

[0046] Approaches are described below on how to handle bearer remapping, such as when an RLF occurs and rerouting and remapping is needed.

[0047] Prior to discussing the approaches, Figure 10 depicts an example of a UE 1000 of a wireless communication network configured to provide wireless communication according to embodiments of inventive concepts. As shown, the UE 1000 may include a transceiver circuit 1002 (also referred to as a transceiver) including a transmitter and a receiver configured to provide uplink and downlink radio communications with wireless devices. The UE 1000 may also include a processor circuit 1004 (also referred to as a processor) coupled to the transceiver circuit 1002, and a memory circuit 1006 (also referred to as memory) coupled to the processor circuit 1004. The memory circuit 1006 may include computer readable program code that when executed by the processor circuit 1004 causes the processor circuit to perform operations according to embodiments disclosed herein.

According to other embodiments, processor circuit 1004 may be defined to include memory so that a separate memory circuit is not required.

[0048] As discussed herein, operations of the UE 1000 may be performed by processor 1004 and/or transceiver 1102. For example, the processor 1004 may control transceiver 1002 to transmit uplink communications through transceiver 1002 over a radio interface to one or more network nodes and/or to receive downlink communications through transceiver 1002 from one or more network nodes over a radio interface. Moreover, modules may be stored in memory 1006, and these modules may provide instructions so that when instructions of a module are executed by processor 1004, processor 1004 performs respective operations (e.g., operations discussed herein with respect to example embodiments).

[0049] Accordingly, a UE 1000 according to some embodiments includes a processor circuit 1004, a transceiver 1002 coupled to the processor circuit 1004, and a memory 1006 coupled to the processor circuit, the memory including machine readable program instructions that, when executed by the processor circuit, cause the UE to perform operations.

[0050] Figure 11 is a block diagram of an IAB node according to some embodiments. Various embodiments provide an IAB node that includes a processor circuit 1106, a transceiver 1102 coupled to the processor circuit, and a memory 1108 coupled to the processor circuit. The memory 1108 includes machine-readable computer program instructions that, when executed by the processor circuit, cause the processor circuit 1106 to perform some of the operations depicted in Figures 12-13.

[0051] Figure 11 depicts an example of an IAB node 1100 (also referred to as a base station, eNB, eNodeB, gNB, gNodeB, etc.) of a communication network configured to provide communication according to embodiments of inventive concepts. The IAB node 1100 may correspond to a central unit, a radio unit or a combination of a central unit and a radio unit in a RAN node. As shown, IAB node 1100 may include a transceiver circuit 1102 (also referred to as a transceiver) including a transmitter and a receiver configured to provide uplink and downlink radio communications with wireless devices. The IAB node 1100 may include a network interface circuit 1104 (also referred to as a network interface) configured to provide communications with other nodes (e.g., with other IAB nodes, base stations and/or core network nodes) of the wireless communication network. The IAB node 1100 may also include a processor circuit 1106 (also referred to as a processor) coupled to the transceiver circuit 1102, and a memory circuit 1108 (also referred to as memory) coupled to the processor circuit 1106. The memory circuit 1208 may include computer readable program code that when executed by the processor circuit 1106 causes the processor circuit to perform operations according to embodiments disclosed herein. According to other embodiments, processor circuit 1106 may be defined to include memory so that a separate memory circuit is not required.

[0052] As discussed herein, operations of the IAB node 1100 may be performed by processor 1106, network interface 1104, and/or transceiver 1102. For example, processor 1106 may control transceiver 1102 to transmit downlink communications through transceiver 1102 over a radio interface to one or more UEs and/or to receive uplink communications through transceiver 1102 from one or more UEs over a radio interface. Similarly, processor 1106 may control network interface 1104 to transmit communications through network interface 1104 to one or more other IAB nodes and/or to receive communications through network interface from one or more other IAB nodes. Moreover, modules may be stored in memory 1108, and these modules may provide instructions so that when instructions of a module are executed by processor 1106, processor 1106 performs respective operations (e.g., operations discussed below with respect to example embodiments).

[0053] Accordingly, an IAB node 1100 according to some embodiments includes a processor circuit 1106, a transceiver 1102 coupled to the processor circuit, and a memory 1108 coupled to the processor circuit, the memory including machine readable program instructions that, when executed by the processor circuit, cause the IAB node 1100 to perform operations depicted in Figures 12-13.

[0054] The inventive concepts described herein addresses the remapping of packets from ingress BH RLC channel to egress BH RLC channels. Several methods are described. These methods include:

A method at the IAB -donor CU to configure an IAB node (or an IAB -donor DU) alternative egress BH RLC channels to map a packet from an ingress BH RLC channel, when an egress BH RLC channel with the same LCID as the ingress BH RLC channel is not available. A method at the IAB node (or an IAB -donor DU) to remap an ingress BH RLC channel to an egress BH RLC channel with a different LCID

^■ based on IAB -donor CU configuration.

^■ based on IAB node (or IAB -donor DU) implementation.

A method at the IAB node (or an IAB -donor DU) to include a re-mapping information on the BAP header after a re-mapping is performed, where the re mapping information includes the LCID of the ingress BH RLC channel the packet was received (known as original BH RLC Channel LCID)

A method at the IAB node to use the re-mapping information on the BAP header to map the ingress BH channel back to the egress BH RLC channel with an LCID matching the original BH RLC Channel LCID.

[0055] In the description that follows, the terms“backhaul RLC channel” and “backhaul bearer” are used interchangeably. The term“IAB-donor CU” and“donor CU” are used interchangeably.

[0056] In the description that follows, the DL case shall be described for the sake of brevity, but the methods described are applicable also to the UL case. The main reason for re-routing from one path to another is backhaul radio link failure. However, there could be other reasons like congestion on one path.

[0057] The description for some of the embodiments will be based on the topology shown in Figure 8. The IAB-donor has performed the bearer mapping in the following way:

UE bearers for UE1, UE2, and UE3 that are served by IAB5 are mapped to BH RLC channel 1 using N:1 bearer mapping approach.

UE bearer for UE4 that is served by IAB 5 is mapped to BH RLC channel 2 using 1 : 1 bearer mapping approach.

UE bearers for UE5 that is served by IAB 6 are mapped to BH RLC channel 3 using N: 1 bearer mapping approach.

UE bearers for UE6 and UE7 that are served by IAB6 are mapped to BH RLC channel 4 using N:1 bearer mapping approach.

[0058] Similarly, the IAB 1 mapped the ingress bearers received from the IAB- donor in the following manner:

Ingress BH RLC channel 1 and 2 are mapped to egress BH RLC channel 1 and 2 on the link toward IAB2. Ingress BH RLC channel 3 and 4 are mapped to egress BH RLC channel 3 and 4 on the link toward IAB 3.

[0059] The other downstream IAB nodes, i.e., IAB3 and IAB4 follow similar approach for bearer mapping between ingress and egress BH RLC channels. Furthermore, the IAB2 is preconfigured by the IAB-donor CU to reroute its traffic that are destined for IAB5 from the link with IAB2 to the link with IAB3 when an RLF occurs (i.e., when IAB2 is not accessible).

[0060] In a first embodiment of inventive concepts, the I AB -donor CU pre configures the IAB node on bearer re-mapping that is to be performed during re-routing (i.e. if there is no corresponding BH RLC channel with the same LCID on the new route). This could be done by a mapping as captured in the example table below:

[0061] According to the above table, traffic that was mapped formerly to BH RLC channel with LCID 1 will be mapped to BH RLC channel with LCID2 on the new route, if BH RLC channel with LCID 1 is not available on the new route. Traffic that was mapped formerly to BH RLC channel with LCID 3 or 4 will be mapped to BH RLC channel with LCID1 on the new route, if BH RLC channel with LCID 3 or 4 is not available on the new route. If LCID 1 is not available, from the table it can be seen that LCID1 could be mapped to LCID2, then 3 and 4 could end up being mapped to LCID2 as well. It is also possible to have more than one mapping option, as in the case of LCID 5, where the remapping could be done to LCID1 or LCID2. How to choose among the multiple choices can be left to the IAB node, or it can be a prioritized list (e.g. for the remapping information related to LCID 5, the IAB node will remap to LCID1 if that is available, if not it will remap to LCID2, and so on). If the proposed LCID is not available, a default LCID could be provided that can be used to remap all traffic that does not have a matching new LCID on the new route.

[0062] The remapping configuration can be provided during the IAB integration procedure or during bearer setup or modification process. It can be provided all at once, or only on a need basis when bearers are created and the IAB node can compile the remapping table. For example, for 1 : 1 bearer mapping, there is a need to perform a UE context modification procedure towards the donor DU, the access IAB node and all intermediate IAB nodes to setup the dedicated BH RLC channels. During this backhaul RLC channel setup, the IAB nodes will be indicated which LCID to allocate the BH RLC channel, and in that configuration fallback or remapping LCID(s) can be indicated as well.

[0063] Though the main use case of the remapping is for handling rerouting situations, it is possible to employ the remapping even in normal scenarios. For example, assume it is decided to have an LCID space of x values in Rel-16 and this is extended to y in Rel-17. In some future deployments, there could be IAB nodes that support only Rel-16 while there are others that support Rel-17. Thus, it is likely that LCID values greater than x will be used for BH RLC channels between the Rel-17 IAB nodes, but not between Rel-16 IAB nodes or between a Rel-16 IAB node and Rel-17 IAB node. Thus, the Rel-17 IAB node may need to remap the packets arriving from another Rel-17 IAB node via ingress BH channel z (where z>x) to w (w<=x) when forwarding it to an egress BH RLC channel towards a Rel-16 IAB node.

[0064] In a second embodiment of this invention, an optional field for instance “original BH RLC channel LCID” will be added to the BAP header to indicate that this packet has been remapped at some point in the path. A flag (e.g. re-mapping flag) in the BAP header can be included for indicating whether or not this field is included in the BAP header. IAB nodes receiving such a packet will check to see if there is an egress BH RLC channel that matches the one indicated in the“original BH RLC channel LCID”. If so, they will map the packet to that egress BH RLC channel (also removing the“original BH RLC channel LCID” from the header). Otherwise, the egress BH RLC channel will be chosen based on the ingress BH RLC channel where the packet was received from (i.e. normal operation of intermediate IAB nodes).

[0065] For the scenario of figure 8, assume that there is a re-mapping

configuration at IAB1 that re-maps LCID 1 to LCID3, and LCID 2 to LCID 4. When the IAB1 remaps traffic (carried by BH RLC channel 1 and 2 over the link toward IAB 2) to BH RLC channel 3 and 4 of the link with IAB3, IAB1 will use the“original BH RLC channel LCID” field to indicate BH RLC ID 1 for packets belong to UE1, UE2, and UE3 while BH RLC ID 2 for packets belonging to packets for UE4. Also, the IAB 1 will set the re-mapping flag to 1 in the BAP header indicating remapping information is available. When IAB3 receives a BAP packet on ingress BH RLC channel with LCID 3 that contains the re-mapping information indicating BH RLC ID1 in the original BH RLC channel field, it checks to see if it has an egress BH RLC channel with LCID 1 towards the next hop (i.e. IAB4), and finding it doesn’t exist, it will simply forward it to the BH RLC channel with the same LCID (i.e.

LCID3). When the packet arrives at IAB4, IAB4, on finding that it has an egress BH RLC channel with LCID 1 towards IAB5, will remove the re-mapping information and forward the packet into the egress BH RLC channel with LCID 1.

[0066] In a variant of the second embodiment, if an IAB node receives a BAP packet that has a re-mapping information (e.g. original BH RLC channel LCID = a) from an ingress BH RLC channel (e.g. LCID =b), but it has no egress BH RLC channel corresponding to LCID a or b, the IAB node could make a further remapping. This remapping could be done in several ways. Consider the case where the IAB node has a remapping table as shown below:

[0067] The IAB node could re-map the BAP packet to LCID x (i.e. the remapping target corresponding to LCID a, which was the original LCID of the BAP packet before the first remapping was done at an earlier node), or it could re-map it to LCID y (i.e. the remapping target corresponding to LCID b, the ingress BH RLC channel in which the IAB node received the packet). In both cases, the re-mapping information will be kept in the BAP header to ensure that a further node downstream can re-map it back to the original LCID.

[0068] For example, in the scenario shown in Figure 9, assume that there is a re mapping configuration at IAB1 that re-maps LCID 1 to LCID3, and LCID 2 to LCID 4, where LCID3 and LCID4 carry traffic for UE1 and UE2, respectively. When the IAB1 remaps traffic (carried by BH RLC channel 1 and 2 over the link toward IAB2) to BH RLC channel 3 and 4 of the link with IAB3, IAB1 will use the“original BH RLC channel LCID” field to indicate BH RLC ID 1 for packets belong to UE3 and UE4 while BH RLC ID 2 for packets belonging to packets for UE5. However, when the IAB 3 receives the packets for UE3 and UE4 on ingress BH RLC channel 3, while for UE5 on ingress RLC channel 4 with the re mapping flag set, the IAB3 will further re-map the packets for UE3 and UE4 to egress BH RLC channel 5, and packets for UE5 to egress BH RLC channel 6 without removing the “original BH RLC channel LCID” from the packet’s header.

[0069] The CU functionality and the DU functionality described above could be implemented in the cloud.

[0070] Inventive concepts described herein include:

A remapping of bearers from an ingress BH RLC channel of a given LCID to an egress BH RLC channel of a different LCID, if an egress BH RLC channel with the same LCID as the ingress one is not available due to several reasons like re routing to a different link due to overload, radio link failure, capability of IAB nodes, etc.

A remapping of bearers back to the original BH RLC channel LCID at a further node, when that LCID becomes available.

EMBODIMENTS OF THE INVENTIVE CONCEPTS

[0071] Operations of an IAB node 1100 (implemented using the structure of Figure 11) will now be discussed with reference to the flow chart of Figure 12 according to some embodiments of inventive concepts. For example, modules may be stored in memory 1108 of Figure 11, and these modules may provide instructions so that when the instructions of a module are executed by respective IAB node processing circuitry 1106, processing circuitry 1106 performs respective operations of the flow chart.

[0072] Turning now to Figure 12, in operation 1200, the processing circuitry 1106 may, via transceiver circuitry 1102 and/or network interface circuitry 1204, receive a preconfigured remapping configuration. The preconfigured remapping configuration may be received during one of an IAB integration procedure, a bearer setup, or a bearer modification process. For example, the preconfigured remapping configuration may be the tables described above in paragraphs 0067 and 0073.

[0073] In operation 1202, the processing circuitry 1106 may determine whether an egress backhaul, BH, radio link channel, RLC channel having an associated first logical channel identifier, LCID, is available for an ingress BH RLC channel having the associated first LCID. In some embodiments, the determining may be from determining whether there is a link failure in a link used for the egress BH RLC channel having the associated first LCID. In other embodiments, the determining may be from determining whether there is a resource utilization overload in an IAB node in a link used for the egress BH RLC channel having the associated first LCID. In further embodiments, the determining may be from determining whether a capability of an IAB node needed for a link used for the egress BH RLC channel having the associated first LCID is not supported by the IAB node.

[0074] In operation 1204, the processing circuitry 1106 may determine the egress BH RLC channel having the associated second LCID different from the first LCID. The egress BH RLC channel may be determined from the preconfigured remapping configuration.

[0075] In operation 1206, responsive to determining that the egress BH RLC channel having the associated first LCID is not available, the processing circuitry 1106 may remap the bearer from the ingress BH RLC channel having the associated first LCID to the egress BH RLC channel having the associated second LCID different from the first LCID.

[0076] In operation 1208, the processing circuitry 1106 may add remapping information in a header to indicate that a packet being sent has been remapped responsive to the remapping. The remapping information may be an original BH RLC channel LCID indication. The indication may be in the form of a flag in some embodiments.

[0077] In operation 1210, the processing circuitry 1106 may further remap the bearer back to the associated first LCID at a further node when the associated first LCID becomes available subsequent to the remapping of the bearer from the ingress BH RLC channel having the associated first LCID to the egress BH RLC channel having the associated second LCID different from the first LCID. The remapping information may be used in some embodiments to remap the bearer.

[0078] Various operations from the flow chart of Figure 12 may be optional with respect to some embodiments of IAB nodes and related methods. Regarding methods of example embodiment 1 (set forth below), for example, operations of blocks 1200, 1204, 1208, and 1210 of Figure 12 may be optional.

[0079] Turning now to Figure 13, in operation 1300, the processing circuitry 1106 may, via transceiver circuitry 1102 and/or network interface circuitry 1204, receive a preconfigured remapping configuration. The preconfigured remapping configuration may be received during one of an IAB integration procedure, a bearer setup, or a bearer modification process. For example, the preconfigured remapping configuration may be the tables described above in paragraphs 0067 and 0073.

[0080] In operation 1302, the processing circuitry 1106 may determine whether to remap an ingress back haul, BH, radio link channel, RLC, channel having an associated first logical channel identifier, LCID, to an egress BH RLC channel having an associated second LCID different from the first LCID. In some embodiments, the determining may be from determining whether there is a link failure in a link used for the egress BH RLC channel having the associated first LCID. In other embodiments, the determining may be from determining whether there is a resource utilization overload in an IAB node in a link used for the egress BH RLC channel having the associated first LCID. In further embodiments, the determining may be from determining whether a capability of an IAB node needed for a link used for the egress BH RLC channel having the associated first LCID is not supported by the IAB node. [0081] In operation 1304, the processing circuitry 1106 may determine the egress BH RLC channel having the associated second LCID different from the first LCID. The egress BH RLC channel may be determined from the preconfigured remapping configuration.

[0082] In operation 1306, responsive to determining to remap the ingress BH RLC channel having the associated first LCID, the processing circuitry 1106 may remap the bearer from the ingress BH RLC channel having the associated first LCID to the egress BH RLC channel having the associated second LCID different from the first LCID.

[0083] In operation 1308, the processing circuitry 1106 may add remapping information in a header to indicate that a packet being sent has been remapped responsive to the remapping. The remapping information may be an original BH RLC channel LCID indication. The indication may be in the form of a flag in some embodiments.

[0084] Various operations from the flow chart of Ligure 13 may be optional with respect to some embodiments of IAB nodes and related methods. Regarding methods of example embodiment 17 (set forth below), for example, operations of blocks 1300, 1304, and 1308 of Ligure 13 may be optional.

ABBREVIATIONS

[0085] At least some of the following abbreviations may be used in this disclosure. If there is an inconsistency between abbreviations, preference should be given to how it is used above. If listed multiple times below, the first listing should be preferred over any subsequent listing(s).

Abbreviation Explanation

3GPP 3rd Generation Partnership Project

IAB Integrated Access Backhaul

BH Backhaul

CN Core Network

CU Central Unit

DU Distributed Unit

CP Control Plane

UP User Plane

LCID Logical Channel Identifier

UE User Equipment

PDCP Packet Data Convergence Protocol

RLC Radio Link Control MAC Medium Access Control

MAC Message Authentication Code

DRB Dedicated Radio Bearer

SDU Service Data Unit

PDU Protocol Data Unit

SR Scheduling Request

BSR Buffer Status Report

UL Uplink

DL Downlink

ACK Acknowledgement

NACK Negative ACK

RRC Radio Resource Control

SIB System Information Block

[0086] References:

[1] 3GPP TR 38.874

LISTING OL EXAMPLE EMBODIMENTS

[0087] Example Embodiments are discussed below. Reference numbers/letters are provided in parenthesis by way of example/illustration without limiting example embodiments to particular elements indicated by reference numbers/letters.

Embodiment 1. A method of remapping a bearer in an integrated access and wireless backhaul network, the method comprising:

determining (1202) whether an egress backhaul, BH, radio link channel, RLC channel having an associated first logical channel identifier, LCID, is available for an ingress BH RLC channel having the associated first LCID;

responsive to determining that the egress BH RLC channel having the associated first LCID is not available, remapping (1206) the bearer from the ingress BH RLC channel having the associated first LCID to an egress BH RLC channel having an associated second LCID different from the first LCID.

Embodiment 2. The method of Embodiment 1, further comprising:

further remapping (1210) the bearer back to the associated first LCID at a further node when the associated first LCID becomes available subsequent to the remapping of the bearer from the ingress BH RLC channel having the associated first LCID to the egress BH RLC channel having the associated second LCID different from the first LCID.

Embodiment 3. The method of any of Embodiments 1-2 wherein determining whether the egress BH RLC channel having the associated first LCID is available comprises determining whether there is a link failure in a link used for the egress BH RLC channel having the associated first LCID.

Embodiment 4. The method of any of Embodiments 1-2 wherein determining whether the egress BH RLC channel having the associated first LCID is available comprises determining whether there is a resource utilization overload in an IAB node in a link used for the egress BH RLC channel having the associated first LCID.

Embodiment 5. The method of any of Embodiments 1-2 wherein determining whether the egress BH RLC channel having the associated first LCID is available comprises determining whether a capability of an IAB node needed for a link used for the egress BH RLC channel having the associated first LCID is not supported by the IAB node.

Embodiment 6. The method of any of Embodiments 1-5, further comprising:

determining (1204) the egress BH RLC channel having the associated second LCID different from the first LCID.

Embodiment 7. The method of Embodiment 6, wherein determining the egress BH RLC channel having the associated second LCID different from the first LCID comprises: determining the egress BH RLC channel having the associated second LCID from a preconfigured remapping configuration.

Embodiment 8. The method of Embodiment 7 further comprising receiving (1200) the preconfigured remapping configuration during one of an IAB integration procedure, a bearer setup, or a bearer modification process.

Embodiment 9. The method of any of Embodiments 1-7, further comprising:

adding (1208) remapping information in a header to indicate that a packet being sent has been remapped responsive to the remapping.

Embodiment 10. The method of Embodiment 9 wherein the remapping information comprises an original BH RLC channel LCID indication.

Embodiment 11. The method of any of Embodiments 9-10 further comprising: remapping, using the remapping information, the bearer back to the associated first LCID at a further node when the associated first LCID is available.

Embodiment 12. The method of any of Embodiment 11 further comprising:

responsive to remapping the bearer back to the associated first LCID at the further node when the associated first LCID is available, removing the original BH RLC channel LCID indication.

Embodiment 13. An integrated access and wireless backhaul, IAB, node (1100) configured to operate in a communication network, the IAB node comprising:

processing circuitry (1103); and

memory (1105) coupled with the processing circuitry, wherein the memory includes instructions that when executed by the processing circuitry causes the IAB node to perform operations according to any of Embodiments 1-12.

Embodiment 14. An integrated access and wireless backhaul, IAB, node (1100) configured to operate in a communication network, wherein the IAB node is adapted to perform according to any of Embodiments 1-12.

Embodiment 15. A computer program comprising program code to be executed by processing circuitry (1103) of an integrated access and wireless backhaul, IAB, node (1100) configured to operate in a communication network, whereby execution of the program code causes the IAB node (1100) to perform operations according to any of embodiments 1-12.

Embodiment 16. A computer program product comprising a non-transitory storage medium including program code to be executed by processing circuitry (1103) of an integrated access and wireless backhaul, IAB, node (1100) configured to operate in a communication network, whereby execution of the program code causes the IAB node (1100) to perform operations according to any of embodiments 1-12.

Embodiment 17. A method of remapping a bearer in an integrated access and wireless backhaul, IAB network, the method comprising:

determining (1302) whether to remap an ingress back haul, BH, radio link channel, RLC, channel having an associated first logical channel identifier, LCID, to an egress BH RLC channel having an associated second LCID different from the first LCID;

responsive to determining to remap the ingress BH RLC channel having the associated first LCID, remapping (1306) the bearer from the ingress BH RLC channel having the associated first LCID to the egress BH RLC channel having the associated second LCID different from the first LCID.

Embodiment 18. The method of Embodiment 17 wherein determining whether to remap the ingress BH RLC channel having the associated first LCID comprises determining whether there is a link failure in a link used for the egress BH RLC channel having the associated first LCID.

Embodiment 19. The method of Embodiment 17 wherein determining whether to remap the ingress BH RLC channel having the associated first LCID comprises determining whether there is a resource utilization overload in an IAB node in a link used for the egress BH RLC channel having the associated first LCID.

Embodiment 20. The method of Embodiment 17 wherein determining whether to remap the ingress BH RLC channel having the associated first LCID comprises determining whether a capability of an IAB node needed for a link used for the egress BH RLC channel having the associated first LCID is not supported by the IAB node.

Embodiment 21. The method of any of Embodiments 17-20, further comprising:

determining (1304) the egress BH RLC channel having the associated second LCID different from the first LCID.

Embodiment 22. The method of Embodiment 21, wherein determining the egress BH RLC channel having the associated second LCID different from the first LCID comprises: determining the egress BH RLC channel from a preconfigured remapping

configuration.

Embodiment 23. The method of Embodiment 22 further comprising receiving (1300) the preconfigured remapping configuration during one of an IAB integration procedure, a bearer setup, or a bearer modification process.

Embodiment 24. The method of any of Embodiments 17-23, further comprising:

adding (1308) remapping information in a header to indicate that a packet being sent has been remapped responsive to the remapping.

Embodiment 25. The method of Embodiment 9 wherein the remapping information comprises an original BH RLC channel LCID indication. Embodiment 26. An integrated access and wireless backhaul, IAB, node (1100) configured to operate in a communication network, the IAB node comprising:

processing circuitry (1103); and

memory (1105) coupled with the processing circuitry, wherein the memory includes instructions that when executed by the processing circuitry causes the IAB node to perform operations according to any of Embodiments 17-25.

Embodiment 27. An integrated access and wireless backhaul, IAB, node (1100) configured to operate in a communication network, wherein the IAB node is adapted to perform according to any of Embodiments 17-25.

Embodiment 28. A computer program comprising program code to be executed by processing circuitry (1103) of an integrated access and wireless backhaul, IAB, node (1100) configured to operate in a communication network, whereby execution of the program code causes the IAB node (1100) to perform operations according to any of embodiments 17-25.

Embodiment 29. A computer program product comprising a non-transitory storage medium including program code to be executed by processing circuitry (1103) of an integrated access and wireless backhaul, IAB, node (1100) configured to operate in a communication network, whereby execution of the program code causes the IAB node (1100) to perform operations according to any of embodiments 17-25.

ADDITIONAL EXPLANATION

[0088] Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and/or is implied from the context in which it is used. All references to a/an/the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and/or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following description. [0089] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as read-only memory (ROM), random- access memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.

[0090] The term unit may have conventional meaning in the field of electronics, electrical devices and/or electronic devices and may include, for example, electrical and/or electronic circuitry, devices, modules, processors, memories, logic solid state and/or discrete devices, computer programs or instructions for carrying out respective tasks, procedures, computations, outputs, and/or displaying functions, and so on, as such as those that are described herein.

[0091] In the above-description of various embodiments of present inventive concepts, it is to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of present inventive concepts. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which present inventive concepts belong. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

[0092] When an element is referred to as being "connected", "coupled", "responsive", or variants thereof to another element, it can be directly connected, coupled, or responsive to the other element or intervening elements may be present. In contrast, when an element is referred to as being "directly connected", "directly coupled", "directly responsive", or variants thereof to another element, there are no intervening elements present. Like numbers refer to like elements throughout. Furthermore, "coupled", "connected",

"responsive", or variants thereof as used herein may include wirelessly coupled, connected, or responsive. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. Well-known functions or constructions may not be described in detail for brevity and/or clarity. The term "and/or" includes any and all combinations of one or more of the associated listed items.

[0093] It will be understood that although the terms first, second, third, etc. may be used herein to describe various elements/operations, these elements/operations should not be limited by these terms. These terms are only used to distinguish one element/operation from another element/operation. Thus a first element/operation in some embodiments could be termed a second element/operation in other embodiments without departing from the teachings of present inventive concepts. The same reference numerals or the same reference designators denote the same or similar elements throughout the specification.

[0094] As used herein, the terms "comprise", "comprising", "comprises", "include", "including", "includes", "have", "has", "having", or variants thereof are open- ended, and include one or more stated features, integers, elements, steps, components or functions but does not preclude the presence or addition of one or more other features, integers, elements, steps, components, functions or groups thereof. Furthermore, as used herein, the common abbreviation "e.g.", which derives from the Latin phrase "exempli gratia," may be used to introduce or specify a general example or examples of a previously mentioned item, and is not intended to be limiting of such item. The common abbreviation "i.e.", which derives from the Latin phrase "id est," may be used to specify a particular item from a more general recitation.

[0095] Example embodiments are described herein with reference to block diagrams and/or flowchart illustrations of computer-implemented methods, apparatus (systems and/or devices) and/or computer program products. It is understood that a block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by computer program instructions that are performed by one or more computer circuits. These computer program instructions may be provided to a processor circuit of a general purpose computer circuit, special purpose computer circuit, and/or other programmable data processing circuit to produce a machine, such that the instructions, which execute via the processor of the computer and/or other programmable data processing apparatus, transform and control transistors, values stored in memory locations, and other hardware components within such circuitry to implement the functions/acts specified in the block diagrams and/or flowchart block or blocks, and thereby create means (functionality) and/or structure for implementing the functions/acts specified in the block diagrams and/or flowchart block(s).

[0096] These computer program instructions may also be stored in a tangible computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer- readable medium produce an article of manufacture including instructions which implement the functions/acts specified in the block diagrams and/or flowchart block or blocks.

Accordingly, embodiments of present inventive concepts may be embodied in hardware and/or in software (including firmware, resident software, micro-code, etc.) that runs on a processor such as a digital signal processor, which may collectively be referred to as "circuitry," "a module" or variants thereof.

[0097] It should also be noted that in some alternate implementations, the functions/acts noted in the blocks may occur out of the order noted in the flowcharts. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality/acts involved. Moreover, the functionality of a given block of the flowcharts and/or block diagrams may be separated into multiple blocks and/or the functionality of two or more blocks of the flowcharts and/or block diagrams may be at least partially integrated. Finally, other blocks may be added/inserted between the blocks that are illustrated, and/or blocks/operations may be omitted without departing from the scope of inventive concepts. Moreover, although some of the diagrams include arrows on communication paths to show a primary direction of communication, it is to be understood that communication may occur in the opposite direction to the depicted arrows.

[0098] Many variations and modifications can be made to the embodiments without substantially departing from the principles of the present inventive concepts. All such variations and modifications are intended to be included herein within the scope of present inventive concepts. Accordingly, the above disclosed subject matter is to be considered illustrative, and not restrictive, and the examples of embodiments are intended to cover all such modifications, enhancements, and other embodiments, which fall within the spirit and scope of present inventive concepts. Thus, to the maximum extent allowed by law, the scope of present inventive concepts are to be determined by the broadest permissible interpretation of the present disclosure including the examples of embodiments and their equivalents, and shall not be restricted or limited by the foregoing detailed description.

Claims

1. A method of remapping a bearer in an integrated access and wireless backhaul network, the method comprising:

determining (1302) whether to remap an ingress back haul, BH, radio link channel, RLC, channel having an associated first logical channel identifier, LCID, from an egress to BH RLC channel having the associated first LCID to an egress BH RLC channel having an associated second LCID different from the first LCID; and

2. The method of Claim 1, wherein:

determining whether to remap the ingress BH radio link channel comprises determining (1202) whether the egress BH RLC channel having the associated first LCID is available for the ingress BH RLC channel having the associated first LCID; and

remapping the bearer from the ingress BH RLC channel comprises responsive to determining that the egress BH RLC channel having the associated first LCID is not available, remapping (1206) the bearer from the ingress BH RLC channel having the associated first LCID to the egress BH RLC channel having the associated second LCID different from the first LCID.

3. The method of Claim 2, further comprising:

4. The method of any of Claims 1-3 wherein determining whether to remap the ingress BH RLC channel having the associated first LCID comprises determining whether there is a link failure in a link used for the egress BH RLC channel having the associated first LCID.

5. The method of any of Claims 1-3 wherein determining whether to remap the ingress BH RLC channel having the associated first LCID comprises determining whether there is a resource utilization overload in an IAB node in a link used for the egress BH RLC channel having the associated first LCID.

6. The method of any of Claims 1-3 wherein determining whether to remap the ingress BH RLC channel having the associated first LCID comprises determining whether a capability of an IAB node needed for a link used for the egress BH RLC channel having the associated first LCID is not supported by the IAB node.

7. The method of any of Claims 1-6, further comprising:

determining (1204, 1304) the egress BH RLC channel having the associated second LCID different from the first LCID.

8. The method of Claim 7, wherein determining the egress BH RLC channel having the associated second LCID different from the first LCID comprises:

determining the egress BH RLC channel having the associated second LCID from a preconfigured remapping configuration.

9. The method of Claim 8 further comprising receiving (1200, 1300) the preconfigured remapping configuration during one of an IAB integration procedure, a bearer setup, or a bearer modification process.

10. The method of any of Claims 1-8, further comprising:

adding (1208, 1308) remapping information in a header to indicate that a packet being sent has been remapped responsive to the remapping.

11. The method of Claim 10 wherein the remapping information comprises an original BH RLC channel LCID indication.

12. The method of any of Claims 10-11 further comprising:

remapping, using the remapping information, the bearer back to the associated first LCID at a further node when the associated first LCID is available.

13. The method of Claim 12 further comprising:

14. An integrated access and wireless backhaul, IAB, node (1100) configured to operate in a communication network, the IAB node comprising:

processing circuitry (1103); and

memory (1105) coupled with the processing circuitry, wherein the memory includes instructions that when executed by the processing circuitry causes the IAB node to perform operations comprising:

determining (1302) whether to remap an ingress back haul, BH, radio link channel, RLC, channel having an associated first logical channel identifier, LCID, to an egress BH RLC channel having an associated second LCID different from the first LCID; and

responsive to determining to remap the ingress BH RLC channel having the associated first LCID, remapping (1306) a bearer from the ingress BH RLC channel having the associated first LCID to the egress BH RLC channel having the associated second LCID different from the first LCID.

15. The IAB node (1100) of Claim 14, wherein

in determining whether to remap the ingress BH radio link channel, the memory includes further instructions that when executed by the processing circuitry causes the IAB node to perform operations comprising determining (1202) whether the egress BH RLC channel having the associated first LCID is available for the ingress BH RLC channel having the associated first LCID; and

in remapping the bearer from the ingress BH RLC channel, the memory includes further instructions that when executed by the processing circuitry causes the IAB node to perform operations comprising responsive to determining that the egress BH RLC channel having the associated first LCID is not available, remapping (1206) the bearer from the ingress BH RLC channel having the associated first LCID to the egress BH RLC channel having the associated second LCID different from the first LCID.

16. The IAB node (1100) of any of Claims 14-15, wherein the memory includes further instructions that when executed by the processing circuitry causes the IAB node to perform operations further comprising:

17. The IAB node (1100) of any of Claims 14-16 wherein in determining whether to remap the ingress BH RLC channel having the associated first LCID, the memory includes instructions that when executed by the processing circuitry causes the IAB node to perform further operations comprising determining whether there is a link failure in a link used for the egress BH RLC channel having the associated first LCID.

18. The IAB node (1100) of Claims 14-16 wherein in determining whether to remap the ingress BH RLC channel having the associated first LCID, the memory includes instructions that when executed by the processing circuitry causes the IAB node to perform further operations comprising determining whether there is a resource utilization overload in an IAB node in a link used for the egress BH RLC channel having the associated first LCID.

19. The IAB node (1100) of Claim 14-16 wherein in determining whether to remap the ingress BH RLC channel having the associated first LCID, the memory includes instructions that when executed by the processing circuitry causes the IAB node to perform further operations comprising determining whether a capability of an IAB node needed for a link used for the egress BH RLC channel having the associated first LCID is not supported by the IAB node.

20. The IAB node (1100) of any of Claims 14-19, wherein the memory includes further instructions that when executed by the processing circuitry causes the IAB node to perform operations further comprising:

21. The IAB node (1100) of Claim 20, wherein in determining the egress BH RLC channel having the associated second LCID different from the first LCID, the memory includes further instructions that when executed by the processing circuitry causes the IAB node to perform operations further comprising:

22. The IAB node (1100) of Claim 21, wherein the memory includes further instructions that when executed by the processing circuitry causes the IAB node to perform operations further comprising receiving (1200, 1300) the preconfigured remapping configuration during one of an IAB integration procedure, a bearer setup, or a bearer modification process.

23. The IAB node (1100) of any of Claims 14-19, wherein the memory includes further instructions that when executed by the processing circuitry causes the IAB node to perform operations further comprising:

24. The IAB node (1100) of Claim 23, wherein the remapping information comprises an original BH RLC channel LCID indication.

25. The IAB node (1100) of any of Claims 23-24, wherein the memory includes further instructions that when executed by the processing circuitry causes the IAB node to perform operations further comprising:

26. The IAB node (1100) of Claim 25, wherein the memory includes further instructions that when executed by the processing circuitry causes the IAB node to perform operations further comprising:

27. An integrated access and wireless backhaul, IAB, node (1100) configured to operate in a communication network, wherein the IAB node is adapted to perform according to any of Claims 1-13.

28. A computer program comprising program code to be executed by processing circuitry (1103) of an integrated access and wireless backhaul, IAB, node (1100) configured to operate in a communication network, whereby execution of the program code causes the IAB node

(1100) to perform operations according to any of Claims 1-13.

29. A computer program product comprising a non-transitory storage medium including program code to be executed by processing circuitry (1103) of an integrated access and wireless backhaul, IAB, node (1100) configured to operate in a communication network, whereby execution of the program code causes the IAB node (1100) to perform operations according to any of Claims 1-13.