WO2022226838A1

WO2022226838A1 - Packets re-routing

Info

Publication number: WO2022226838A1
Application number: PCT/CN2021/090563
Authority: WO
Inventors: Xiang Xu; Henri Markus Koskinen; Esa Mikael MALKAMÄKI; Matti Einari Laitila; Oliver Blume
Original assignee: Nokia Shanghai Bell Co., Ltd.; Nokia Solutions And Networks Oy; Nokia Technologies Oy
Priority date: 2021-04-28
Filing date: 2021-04-28
Publication date: 2022-11-03
Also published as: EP4331316A1; CN115553054A

Abstract

Example embodiments of the present disclosure relate to packets re-routing in a communication network. A first device receives, from a second device, a request for establishing at least one tunnel between the first device and a third device. The first device transmits, to the second device, tunnel information concerning the at least one tunnel to be established between the first device and the third device. The first device receives at least one uplink packet targeted to the first device from a fourth device, via the third device and the at least one tunnel. This solution may avoid uplink packet loss, for example, during the inter-donor-DU migration. In addition, this solution may not violate the security policy in a transport network and IAB-donor-DU. In other words, the source filtering can be applied normally for the re-routed packets.

Description

PACKETS RE-ROUTING

FIELD

Embodiments of the present disclosure generally relate to the field of telecommunication and in particular, to devices, methods, apparatuses and computer readable storage medium for re-routing packets in a communication network.

BACKGROUND

A communication system may include one or more Integrated Access and Backhaul (IAB) nodes. An IAB donor has wired/fiber connectivity with a core network. It may be implemented as a gNB that terminates wireless backhaul radio interface from one or more IAB nodes. The IAB donor may serve directly connected IAB nodes and IAB nodes that are chained over multiple wireless backhaul hops. The IAB donor may also serve directly connected terminal devices. The IAB node may also serve the connected terminal devices and other connected child IAB nodes. The IAB donor may include a central unit (CU) and one or more distributed units (DUs) .

An IAB node may include a DU (IAB-DU) , and a mobile terminal (IAB-MT) that maintains connectivity with one or more upstream nodes (using for example, dual connectivity) . The IAB node may serve one or more terminal devices directly connected to the IAB node.

An IAB topology in a communication system may be non-static since an migration may be performed, for example a handover may be performed for the IAB-MT based on signal strength, signal quality and other factors.

SUMMARY

In general, example embodiments of the present disclosure provide a solution for re-routing packets in a communication network. Embodiments that do not fall under the scope of the claims, if any, are to be interpreted as examples useful for understanding various embodiments of the disclosure.

In a first aspect, there is provided a first device. The first device comprises at least one processor; and at least one memory including computer program code. The at least one memory and the computer program code are configured to, with the at least one processor, cause the first device to receive, from a second device, a request for establishing at least one tunnel between the first device and a third device; transmit, to the second device, tunnel information concerning the at least one tunnel to be established between the first device and the third device; and receive at least one uplink packet targeted to the first device from a fourth device, via the third device and the at least one tunnel.

In a second aspect, there is provided a second device. The second device comprises at least one processor; and at least one memory including computer program code. The at least one memory and the computer program code are configured to, with the at least one processor, cause the second device to transmit, to a first device, a request for establishing at least one tunnel between the first device and a third device for forwarding, from the third device to the first device, at least one uplink packet targeted to the first device from a fourth device; receive, from the first device, tunnel information concerning the at least one tunnel; provide, to the third device, the tunnel information for establishment of the at least one tunnel; and provide, to the third device, identity information concerning at least one uplink packet to be forwarded over the at least one tunnel from the third device to the first device.

In a third aspect, there is provided a third device. The third device comprises at least one processor; and at least one memory including computer program code. The at least one memory and the computer program code are configured to, with the at least one processor, cause the third device to obtain, from a second device, tunnel information concerning at least one tunnel to be established between the third device and a first device; obtain, from the second device, identity information concerning at least one uplink packet targeted to the first device from a fourth device and to be forwarded to the first device via the at least one tunnel and the third device; in accordance with a determination that an uplink packet received from the fourth device comprises the obtained identity information, forward the received uplink packet to the first device via one of the at least one tunnel.

In a fourth aspect, there is provided a method. The method may be performed by a first device and comprises receiving, at a first device from a second device, a request for establishing at least one tunnel between the first device and a third device; transmitting, to the second device, tunnel information concerning the at least one tunnel to be established between the first device and the third device; and receiving at least one uplink packet targeted to the first device from a fourth device, via the third device and the at least one tunnel.

In a fifth aspect, there is provided a method. The method may be performed by a second device and comprises transmitting, from a second device to a first device, a request for establishing at least one tunnel between the first device and a third device for forwarding, from the third device to the first device, at least one uplink packet targeted to the first device from a fourth device; receiving, from the first device, tunnel information concerning the at least one tunnel; providing, to the third device, the tunnel information for establishment of the at least one tunnel; and providing, to the third device, identity information concerning at least one uplink packet to be forwarded over the at least one tunnel from the third device to the first device.

In a sixth aspect, there is provided a method. The method may be performed by a third device and comprises obtaining, at a third device from a second device, tunnel information concerning at least one tunnel to be established between the third device and a first device; obtaining, from the second device, identity information concerning at least one uplink packet targeted to the first device from a fourth device and to be forwarded to the first device via the at least one tunnel and the third device; and in accordance with a determination that an uplink packet received from the fourth device comprises the obtained identity information, forwarding the received uplink packet to the first device via one of the at least one tunnel.

In a seventh aspect, there is provided a first apparatus. The first apparatus comprises means for: receiving, at the first apparatus from a second apparatus, a request for establishing at least one tunnel between the first apparatus and a third apparatus; transmitting, to the second apparatus, tunnel information concerning the at least one tunnel to be established between the first apparatus and the third apparatus; and receiving at least one uplink packet targeted to the first apparatus from a fourth apparatus, via the third apparatus and the at least one tunnel.

In an eighth aspect, there is provided a second apparatus. The second apparatus comprises means for: transmitting, from the second apparatus to a first apparatus, a request for establishing at least one tunnel between the first apparatus and a third apparatus for forwarding, from the third apparatus to the first apparatus, at least one uplink packet targeted to the first apparatus from a fourth apparatus; receiving, from the first apparatus, tunnel information concerning the at least one tunnel; providing, to the third apparatus, the tunnel information for establishment of the at least one tunnel; and providing, to the third apparatus, identity information concerning at least one uplink packet to be forwarded over the at least one tunnel from the third apparatus to the first apparatus.

In a ninth aspect, there is provided a third apparatus. The third apparatus comprises means for: obtaining, at the third apparatus from a second apparatus, tunnel information concerning at least one tunnel to be established between the third apparatus and a first apparatus; obtaining, from the second apparatus, identity information concerning at least one uplink packet targeted to the first apparatus from a fourth apparatus and to be forwarded to the first apparatus via the at least one tunnel and the third apparatus; and in accordance with a determination that an uplink packet received from the fourth apparatus comprises the obtained identity information, forwarding the received uplink packet to the first apparatus via one of the at least one tunnel.

In a tenth aspect, there is provided a computer readable medium. The computer readable medium comprises program instructions that, when executed by at least one processor, cause an apparatus to perform at least the method according to the fourth aspect.

In an eleventh aspect, there is provided a computer readable medium. The computer readable medium comprises program instructions that, when executed by at least one processor, cause an apparatus to perform at least the method according to the fifth aspect.

In a twelfth aspect, there is provided a computer readable medium. The computer readable medium comprises program instructions that, when executed by at least one processor, cause an apparatus to perform at least the method according to the sixth aspect.

It is to be understood that the summary section is not intended to identify key or essential features of embodiments of the present disclosure, nor is it intended to be used to limit the scope of the present disclosure. Other features of the present disclosure will become easily comprehensible through the following description.

BRIEF DESCRIPTION OF THE DRAWINGS

Some example embodiments will now be described with reference to the accompanying drawings, where:

Fig. 1 illustrates an example communication network in which example embodiments of the present disclosure can be implemented;

Fig. 2 illustrates a signaling flow for re-routing packets in accordance with some example embodiments of the present disclosure;

Fig. 3 illustrates an example IAB protocol stack for at least one tunnel in accordance with some example embodiments of the present disclosure;

Fig. 4 illustrates another example IAB protocol stack for at least one tunnel in accordance with some example embodiments of the present disclosure;

Fig. 5 illustrates a signaling flow for re-routing packets in accordance with some other example embodiments of the present disclosure;

Fig. 6 illustrates a flowchart of a method implemented at a first device in accordance with some example embodiments of the present disclosure;

Fig. 7 illustrates a flowchart of a method implemented at a second device in accordance with some example embodiments of the present disclosure;

Fig. 8 illustrates a flowchart of a method implemented at a third device in accordance with some example embodiments of the present disclosure;

Fig. 9 illustrates a simplified block diagram of an apparatus that is suitable for implementing example embodiments of the present disclosure; and

Fig. 10 illustrates a block diagram of an example computer readable medium in accordance with some example embodiments of the present disclosure.

Throughout the drawings, the same or similar reference numerals represent the same or similar element.

DETAILED DESCRIPTION

Principle of the present disclosure will now be described with reference to some example embodiments. It is to be understood that these embodiments are described only for the purpose of illustration and help those skilled in the art to understand and implement the present disclosure, without suggesting any limitation as to the scope of the disclosure. Embodiments described herein can be implemented in various manners other than the ones described below.

In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.

References in the present disclosure to “one embodiment, ” “an embodiment, ” “an example embodiment, ” and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

It shall be understood that although the terms “first” and “second” etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term “and/or” includes any and all combinations of one or more of the listed terms.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. 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. It will be further understood that the terms “comprises” , “comprising” , “has” , “having” , “includes” and/or “including” , when used herein, specify the presence of stated features, elements, and/or components etc., but do not preclude the presence or addition of one or more other features, elements, components and/or combinations thereof.

As used in this application, the term “circuitry” may refer to one or more or all of the following:

(a) hardware-only circuit implementations (such as implementations in only analog and/or digital circuitry) and

(b) combinations of hardware circuits and software, such as (as applicable) :

(i) a combination of analog and/or digital hardware circuit (s) with software/firmware and

(ii) any portions of hardware processor (s) with software (including digital signal processor (s) ) , software, and memory (ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and

(c) hardware circuit (s) and or processor (s) , such as a microprocessor (s) or a portion of a microprocessor (s) , that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.

This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

As used herein, the term “communication network” refers to a network following any suitable communication standards, such as New Radio (NR) , Long Term Evolution (LTE) , LTE-Advanced (LTE-A) , Wideband Code Division Multiple Access (WCDMA) , High-Speed Packet Access (HSPA) , Narrow Band Internet of Things (NB-IoT) and so on. Furthermore, the communications between a terminal device and a network device, or communication between network devices in the communication network may be performed according to any suitable generation communication protocols, including, but not limited to, the first generation (1G) , the second generation (2G) , 2.5G, 2.75G, the third generation (3G) , the fourth generation (4G) , 4.5G, the fifth generation (5G) communication protocols, and/or any other protocols either currently known or to be developed in the future. Embodiments of the present disclosure may be applied in various communication systems or networks. Given the rapid development in communications, there will of course also be future type communication technologies, networks and systems with which the present disclosure may be embodied. It should not be seen as limiting the scope of the present disclosure to only the aforementioned system/network.

As used herein, the term “network device” refers to a node in a communication network via which a terminal device accesses the network and receives services therefrom. The network device may refer to a base station (BS) or an access point (AP) , for example, a node B (NodeB or NB) , an evolved NodeB (eNodeB or eNB) , a NR NB (also referred to as a gNB) , a Remote Radio Unit (RRU) , a radio header (RH) , a remote radio head (RRH) , a relay, an Integrated and Access Backhaul (IAB) node, an IAB-DU, and IAB-CU, a low power node such as a femto, a pico, a non-terrestrial network (NTN) or non-ground network device such as a satellite network device, a low earth orbit (LEO) satellite and a geosynchronous earth orbit (GEO) satellite, an aircraft network device, and so forth, depending on the applied terminology and technology.

The term “terminal device” refers to any end device that may be capable of wireless communication. By way of example rather than limitation, a terminal device may also be referred to as a communication device, user equipment (UE) , a Subscriber Station (SS) , a Portable Subscriber Station, a Mobile Station (MS) , or an Access Terminal (AT) . The terminal device may include, but not limited to, a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones, a tablet, a wearable terminal device, a personal digital assistant (PDA) , portable computers, desktop computer, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, vehicle-mounted wireless terminal devices, wireless endpoints, mobile stations, laptop-embedded equipment (LEE) , laptop-mounted equipment (LME) , USB dongles, smart devices, wireless customer-premises equipment (CPE) , an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD) , a vehicle, a drone, a medical device and applications (e.g., remote surgery) , an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts) , a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like. In the following description, the terms “terminal device” , “communication device” , “terminal” , “user equipment” and “UE” may be used interchangeably.

Fig. 1 shows an example communication network 100 in which example embodiments of the present disclosure can be implemented. The communication network 100 may comprise a first device 110, a second device 120, a third device 130, a fourth device 140, a parent device 150, a parent device 160, a child device 170, a grandchild device 180 and a terminal device 190.

In the example of Fig. 1, each of the first device 110 and the third device 130 are in communication with the second device 120. The fourth device 140 is connected to the first device 110 via the parent device 150. The terminal device 190 accesses the communication network 100 via the grandchild device 180. In other embodiments, the communication network 100 may not comprise the parent device 150 and the parent device 160. As such, the fourth device 140 may be connected to the first device 110 directly.

In some embodiments, the communication network 100 may be implemented as an IAB network. In such embodiments, each of the fourth device 140, the

parent devices

150 and 160, the child device 170 and the grandchild device 180 may be implemented as an IAB-node. In such embodiments, the second device 120 may be implemented as an IAB-donor-CU, and each of the first device 110 and the third device 130 may be implemented as an IAB-donor-DU. Alternatively, the first device 110 may be implemented as an IAB-donor-CU-User Plane, the second device 120 may be implemented as an IAB-donor-CU-Control Plane, and the IAB-donor-DU serving the parent device 150 is not shown in Fig. 1.

In embodiments where each of the first device 110 and the third device 130 may be implemented as an IAB-donor-DU, the first device 110 and the third device 130 may be in communication with different IAB-donor-CUs. For example, the first device 110 may be in communication with the second device 120 acting as a source IAB-donor-CU, the third device 130 may be in communication with a target IAB-donor-CU (which is not shown in Fig. 1) that is different from the source IAB-donor-CU. In such embodiments, the source IAB-donor-CU may be in communication with the target IAB-donor-CU via an Xn interface.

In embodiments where the communication network 100 is implemented as an IAB network, the IAB-donor-CU and IAB-donor-DUs may be collectively referred to as an IAB-donor. For example, in the example of Fig. 1, the second device 120, the first device 110 and the third device 130 may be collectively referred to as an IAB-donor 105. The IAB-donor 105 may be implemented as a gNB that terminates wireless backhaul radio interface from one or more IAB-nodes. The IAB-donor 105 has wired/fiber connectivity with a core network. It should be understood that Fig. 1 shows that the IAB-donor 105 includes two IAB-donor-DUs by way of example. In other embodiments, the IAB-donor 105 may include one IAB-donor-DU or more than two IAB-donor-DUs. Hereinafter, the CU of the IAB-donor is also referred to as Donor-CU or donor central unit or IAB-donor-CU; and the DU of the IAB-donor is also referred to as Donor-DU or donor distributed unit or IAB-donor-DU.

In embodiments where the communication network 100 is implemented as an IAB network, an IAB node, for example, each of the

devices

140, 150, 160, 170 and 180, may include a DU (IAB-DU) , and a mobile terminal (IAB-MT) that maintains connectivity with one or more upstream nodes (using for example, dual connectivity) . Similar to a conventional user equipment, the MT of an IAB node may use radio resource control (RRC) signaling to supply radio link measurements of alternative upstream nodes to its current serving gNB CU. A migration may be performed, for example, a handover is performed for the IAB-MT based on signal strength, signal quality and other factors. Hence, the IAB topology, such as the one as shown in Fig. 1, may be non-static. As a result of the migration, the device 140 may change the parent node from source parent node device 150 to target parent node device 160 after the migration. The IAB topology may change over time as radio conditions fluctuate, and as IAB nodes move, are added or removed.

A CU (such as Donor-CU) may be a logical node which may include the functions (for example, gNB functions) such as transfer of user data, mobility control, radio access network sharing, positioning, session management etc., except those functions allocated exclusively to DUs. The CU may control the operation of the DUs over a front-haul (F1) interface. A DU is a logical node which may include a subset of the functions (for example, gNB functions) .

The IAB-donor 105 may serve directly connected IAB-nodes such as the

devices

150 and 160 acting as IAB-nodes, and IAB-nodes that are chained over multiple wireless backhaul hops such as the

devices

140, 170 and 180 acting as IAB-nodes. The IAB-donor 105 may also serve directly connected terminal devices (not shown) . The IAB-nodes, such as the

devices

140, 150, 160, 170 and 180 acting as IAB-nodes, may serve one or more terminal devices directly connected thereto. For example, as shown in Fig. 1, the device 180 may serve the terminal device 190 directly connected to the device 180.

It is to be understood that the number of IAB-nodes and terminal devices connected to the IAB-nodes is only for the purpose of illustration without suggesting any limitations. The IAB network may include any suitable number of IAB-nodes and terminal devices adapted for implementing example embodiments of the present disclosure. In other embodiments, the first device 110 may be implemented as other network devices. For example, in the case where an IPsec tunnel mode with a separate security gateway (SEG) is used to protect the traffic between the second device 120 and the fourth device 140 (or child device 170, or grandchild device 180, and so on) , the first device 110 may be implemented as the SEG.

It is to be understood that the architecture of the network 100 shown in Fig. 1 is described only for the purpose of illustration without suggesting any limitation. In addition, it is to be understood that the number of devices and their connections shown in Fig. 1 are only for the purpose of illustration without suggesting any limitation. The network 100 may include any suitable number of devices adapted for implementing embodiments of the present disclosure. Although not shown, it would be appreciated that one or more additional devices may be deployed in the network 100.

Communications in the communication network 100 may be implemented according to any proper communication protocol (s) , comprising, but not limited to, cellular communication protocols of the first generation (1G) , the second generation (2G) , the third generation (3G) , the fourth generation (4G) and the fifth generation (5G) and on the like, wireless local network communication protocols such as Institute for Electrical and Electronics Engineers (IEEE) 802.11 and the like, and/or any other protocols currently known or to be developed in the future. Moreover, the communication may utilize any proper wireless communication technology, comprising but not limited to: Code Division Multiple Access (CDMA) , Frequency Division Multiple Access (FDMA) , Time Division Multiple Access (TDMA) , Frequency Division Duplex (FDD) , Time Division Duplex (TDD) , Multiple-Input Multiple-Output (MIMO) , Orthogonal Frequency Division Multiple (OFDM) , Discrete Fourier Transform spread OFDM (DFT-s-OFDM) and/or any other technologies currently known or to be developed in the future.

In IAB communication, a Donor-DU acts as a first hop router for its descendant IAB-nodes, for example, the Internet Protocol (IP) address (es) for IAB-nodes are allocated from an address space of the Donor-DU, which is also referred as the Internet Protocol (IP) address (es) for IAB-nodes anchored in the Donor-DU. Per security policy, a Donor-DU may perform source IP filtering (also referred as source IP address filter, or filtering on IP source address) on an IP packet received from its descendant IAB-node. In particular, the Donor-DU may check whether a source IP address of the received IP packet is related to the Donor-DU. If the received IP packet comprises a source IP address that is not related to the Donor-DU, the received IP packet will be discarded.

During an IAB migration, an inter-Donor-DU migration is performed when the target Donor-DU is different to the source Donor-DU. When the source Donor-DU and the target Donor-DU belong to same Donor-CU, an intra-Donor-CU inter-Donor-DU migration occurs. When the source Donor-DU and the target Donor-DU belong to different Donor-CU or the source Donor-DU and the target Donor-DU are connected to different Donor-CU, an inter-Donor-CU migration occurs.

In some embodiments, the fourth device 140 may perform an inter-Donor-DU migration procedure, for example, due to handover. In such embodiments, the fourth device 140 may be referred to as a migrating IAB node. With the migration procedure, the fourth device 140 may change a communication connection from the first device 110 to the third device 130 by migrating from the parent device 150 to the parent device 160. In such embodiments, the first device 110 may be referred to as a source IAB-donor-DU, the parent device 150 may be referred to as a source parent node of the fourth device 140, the third device 130 may be referred to as a target IAB-donor-DU, and the parent device 160 may be referred to as a target parent node of the fourth device 140.

In some embodiments, the migration may be a planned migration. For example, handover preparation is performed for the migrating IAB node. Alternatively, the migration may be an unplanned migration. For example, the migrating IAB node declares a radio link failure (RLF) with a source parent cell/node and then connects with a target parent cell/node.

For UL routing, before the migration, the UL routing identities (IDs) and source IP address (es) of UL packets are related to the source Donor-DU. The source IP address (es) of the IP header in the UL packets originated from an IAB node are the IAB’s IP address (es) , which are anchored in the source Donor-DU. For example, an UL routing ID of an UL packet may comprise a BAP address of the source Donor-DU, and a source IP address of the UL packet is the IAB node’s IP address allocated from an address space of the source Donor-DU. After the migration, the migrating IAB node and descendant IAB nodes shall use new UL routing IDs and new IP addresses that are related to the target Donor-DU for UL routing. The source IP address (es) of the IP header in the UL packets are the IAB node’s IP address (es) , which are anchored in the target Donor-DU. For example, an UL routing ID of an UL packet may comprise a BAP address of the target Donor-DU, and a source IP address of the UL packet is the IAB node’s IP address allocated from an address space of the target Donor-DU. In the example of Fig. 1, before the migration, the UL routing ID and the source IP address of the UL packet sent by the fourth device 140 (or by the child device 170, or by the grandchild device 180, and so on) are related to the first device 110. After the migration, the fourth device 140, the child device 170, the grandchild device 180, and so on, shall use new UL routing ID and new IP address that are related to the third device 130 for new UL packet transmitted to the second device 120.

During the migration, the migrating IAB node and its descendant IAB node may have one or more buffered UL packets received from their respective child IAB node. The UL packets comprise the UL Routing ID and IP address related to the source Donor-DU. After the migration, if the buffered UL packets are sent to the target Donor-DU, the UL packet (s) will be discarded due to source IP filtering (also referred as source IP address filter, or filtering on IP source address) . This will cause UL packet loss.

Some options may be considered to avoid UL packet loss. For example, in option 1, an IAB-donor-CU may configure a target IAB-donor-DU with the IP address (es) related to the source Donor-DU for source IP filtering in the target IAB-donor-DU. However, the option 1 may not work. This option can only avoid the source IP filtering in the target Donor-DU; however, due to the security policy, a transport network node between the target Donor-DU and the target Donor-CU may still enforce source IP filtering and discard the UL packets. For example, an IP router between the second device 120 and the third device 130 may also perform the source IP filtering, which results in UL packet loss.

For another example, in option 2, the source IP filtering in the target IAB-donor-DU may be suspended or disabled. However, this option may cause security issue, since the source IP filtering introduced to ensure security is disabled. This is undesirable, considering that the transport network may be administrated by different operators and the source IP filtering may be part of their security policy.

For another example, in option 3, re-routing is only allowed among a configured subset of IAB-donor-DUs. Option 3 may be considered a variation of option 2 where the source IP filtering is suspended or disabled in the subset. Then similar security problem also exists.

In accordance with some example embodiments of the present disclosure, there is provided a solution for re-routing packets in a communication network. In this solution, at least one tunnel is established between a first device and a third device. If the third device determines that an uplink packet received from a fourth device is targeted to the first device (e.g., based on identity information concerning at least one uplink packet) , the third device forwards the received uplink packet to the first device via one of the at least one tunnel. This solution may avoid uplink packet loss, for example, during the inter-donor-DU migration. In addition, this solution may not violate the security policy in a transport network and IAB-donor-DU. In other words, the source IP filtering can be applied normally for the re-routed packets.

Example embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings.

Reference is now made to Fig. 2, which shows a signaling flow 200 for packet re-routing in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the signaling flow 200 will be described with reference to Fig. 1. The signaling flow 200 may involve the first device 110, the second device 120, the third device 130, the fourth device 140, the parent device 150 and the parent device 160 in Fig. 1.

The second device 120 transmits 205 to the first device 110 a request for establishing at least one tunnel between the first device 110 and the third device 130. Accordingly, the first device 110 receives 210 the request from the second device 120.

The second device 120 may transmit the request in any appropriate scenario. For example, in the case of a planned migration, the second device 120 may transmit the request during the handover preparation for the migrating IAB (such as the fourth device 140) . Alternatively, in the case of an unplanned migration, the second device 120 may transmit the request during the re-establishment of the migrating IAB. Alternatively, when the target IAB-donor-DU (such as the third device 130) received an UL Backhaul Adaptation Protocol (BAP) packet related to the source donor-DU (such as the first device 110) , the second device 120 may transmit the request per the request from the target donor-DU.

In some example embodiments, the request may indicate a format of at least one UL packet to be forwarded to the first device 110. For example, the request may indicate whether the UL packet to be forwarded will comprise a BAP header. In some other embodiments, the format of the at least one UL packet to be forwarded to the first device 110 is preconfigured or predefined, and then the format indication is not included in the request.

In some example embodiments, additionally or alternatively, the request may indicate the number of the at least one tunnel to be established when a plurality of tunnels is to be established.

Upon receiving the request, the first device 110 transmits 215, to the second device 120, tunnel information concerning the at least one tunnel to be established between the first device 110 and the third device 130. Accordingly, the second device 120 receives 220 the tunnel information from the first device 110.

In some example embodiments, the at least one tunnel may comprise a first tunnel. In such embodiments, the tunnel information may comprise at least one of an IP address of the first device 110 or an identity (ID) of a tunnel endpoint associated with the first tunnel.

In some example embodiments, additionally or alternatively, the tunnel information may comprise the format of the at least one uplink packet to be forwarded to the first device 110 over the tunnel between the first device 110 and the third device 130. For example, in the case where the request for establishing the at least one tunnel does not indicate the format of the at least one uplink packet, the tunnel information may comprise the format of the at least one uplink packet that is acceptable to the first device 110. For example, the format may indicate whether the uplink packet to be forwarded should comprise a BAP header. In some embodiments, the format of the at least one UL packet to be forwarded is preconfigured or predefined, and then the format indication is not included in the tunnel information.

With continued reference to Fig. 2, upon receiving the tunnel information, the second device 120 provides 225 the tunnel information to the third device 130 for establishment of the at least one tunnel. In one example embodiment, the second device 120 receives the format of the at least one uplink packet from the first device 110, and provides it to the third device 130. In another example embodiment, the second device 120 may determine the format of the at least one uplink packet to be forwarded to the first device 110 over the tunnel between the first device 110 and the third device 130, and provides it to the first device 110 in the request, and to the third device 130. Accordingly, the third device 130 obtains 230 the tunnel information from the second device 120.

In some example embodiments, the second device 120 may directly transmit the tunnel information to the third device 130 without via another target donor-CU as mentioned in following paragraphs.

As mentioned above, in some example embodiments, each of the first device 110 and the third device 130 may be implemented as an IAB-donor-DU. In some embodiments, the first device 110 and the third device 130 may be in communication with different IAB-donor-CUs or be connected to different IAB-donor-CUs. In such embodiments, for example, in an Xn application protocol (XnAP) Handover Preparation procedure for a planned migration or in an XnAP Retrieve UE Context procedure for an unplanned migration, the second device 120 may first transmit, via an Xn interface, the tunnel information to the target donor-CU (not shown in Fig. 2) in communication with the third device 130. Then, the target donor-CU forwards the tunnel information to the third device 130. That is, in some embodiments, at 225, the second device 120 may provide the tunnel information to the third device 130 via another device, e.g., the target donor-CU.

In addition to the tunnel information, the second device 120 also provides 235, to the third device 130, identity information concerning at least one uplink packet targeted to the first device 110 from the fourth device 140 and to be forwarded to the first device 110 via the at least one tunnel and the third device 130. The identity information is related to one or more tunnel (s) . Similar to the tunnel information, in some example embodiments, the second device 120 may transmit the tunnel information to the third device 130 directly. Alternatively, the second device 120 may provide the identity information to the third device 130 via the target donor-CU in communication with the third device 130. Accordingly, the third device 130 obtains 240 the identity information from the second device 120.

In some example embodiments, the identity information may comprise at least one identity associated with the first device 110. For example, the identity information may comprise at least one of a source IP address or a destination IP address. In this case, the source IP address is an IAB node’s IP address allocated from an address space of the first device 110. Alternatively, the destination IP address is an IP address of the first device 110, or an IP address of the second device 120 or a security gateway. For another example, the identity information may comprise at least one of a BAP address or a BAP routing ID. In this case, the BAP address is the same as the BAP address of the first device 110. The BAP routing ID is an UL Routing ID and contains the BAP address of the first device 110. For another example, the at least one uplink packet may comprise at least one of a Flow Label or a Differentiated Services Code Point (DSCP) , and the IP address or BAP address or BAP routing ID. In this case, the Flow Label and/or DSCP are used to further differentiate the UL packets sharing the IP address or BAP address or BAP routing ID related to the first device 110, but with different Flow Label and/or DSCP.

Upon obtaining the tunnel and identity information, the third device 130 establishes 245 the at least one tunnel with the first device 110.

In some example embodiments, the signaling flow 200 may be performed in an IAB migration procedure for the fourth device 140 (which also referred to as the migrating IAB-node 140) . Before the IAB migration, the downlink (DL) packets, for example, the F1-U traffic, to the fourth device 140 (and in some embodiments its descendant IAB nodes, for example, child IAB 170) , and the uplink (UL) packets, for example, the F1-U traffic, from the fourth device 140 (and in some embodiments its descendant IAB nodes, for example, child IAB node 170) , are routed to the second device 120 via the parent device 150 and the first device 110. After the IAB migration, the downlink (DL) packets, for example, F1-U traffic, to the fourth device 140 (and in some embodiments also its descendant IAB nodes, for example, child IAB node 170) , and uplink (UL) packets, for example, F1-U traffic, from the fourth device 140 (and in some embodiments its descendant IAB nodes, for example, child IAB node 170) are routed to the second device 120 via the parent device 160 and the third device 130.

In embodiments where the signaling flow 200 is performed in an IAB migration procedure for the fourth device 140, the fourth device 140 connects 250 to a target cell. For example, the fourth device 140 may connect to a cell of the parent device 160 under the third device 130 acting as the target donor-DU. Alternatively, the fourth device 140 may connect to a cell of the third device 130 acting as the target donor-DU, or may connect to a cell of an IAB-node under the third device 130 acting as the target donor-DU.

Upon migration to the target parent device 160, the fourth device 140 forwards 252 an UL packet to the third device 130 via the target parent device 160. Accordingly, the third device 130 receives 254 the UL packet from the fourth device 140. The UL packet forwarded by the fourth device 140 may be originated from the fourth device 140, or from the descendant IAB node, for example, the child device 170 shown in Fig. 1, the grandchild node 180 shown in Fig. 1, and so on.

In some example embodiments, the UL packet may comprise an UL packet targeted to the first device 110 and to be forwarded to the first device 110 via the at least one tunnel and the third device 130. For example, the UL packet may be a packet buffered prior to the migration. Alternatively, the UL packet may comprise an UL packet targeted to the third device 130.

In some example embodiments, the at least one uplink packet targeted to the first device 110 may comprise at least one identity associated with the first device 110. For example, the at least one uplink packet may comprise at least one of a source IP address or a destination IP address. For another example, the at least one uplink packet may comprise at least one of a BAP address or a BAP routing ID. For another example, the at least one uplink packet may comprise at least one of a Flow Label or a Differentiated Services Code Point (DSCP) .

Upon receiving the UL packet, the third device 130 determines 260 whether the UL packet comprises the identity information matching with that obtained from the second device 120. If the UL packet comprises the identity information, the third device 130 forwards 270 the UL packet to the first device 110 via one of the at least one tunnel. In other words, if the UL packet comprises one or more identities associated with the first device 110, the third device 130 forwards the UL packet to the first device 110. The UL packet comprising one or more identities associated with the first device 110 is considered to be a buffered packet. Accordingly, the first device 110 receives 272 the UL packet.

On the other hand, if the UL packet does not comprise the identity information obtained from the second device 120, the third device 130 forwards 278 the UL packet to the second device 120. In other words, if the UL packet comprises no identities associated with the first device 110, the third device 130 forwards the UL packet to the second device 120. The UL packet comprising no identities associated with the first device 110 is also considered to be a fresh packet. Accordingly, the second device 120 receives 280 the UL packet.

The at least one tunnel may be configured in various ways. For illustration rather than limitation, some example options for the configuration are provided below.

Option 1: all UL packets originated from one or more IAB-nodes share one tunnel. For example, in the example of Fig. 1, all UL packets originated from the fourth device 140 share one tunnel, and all UL packets originated from the child device 170 and the grandchild device 180 share another tunnel. Alternatively, all UL packets originated from the fourth device 140, the child device 170 and the grandchild device 180 share one tunnel.

In option 1, the obtained identity information in the third device 130 may include one or more source IP address (es) related to the first device 110, for example, one or more IP address (es) allocated to the fourth device 140 (and in some embodiments its descendant IAB nodes, for example, the child device 170) , and the IP address (es) are anchored in the first device 110 which means the downlink (DL) IP packet using the IP address as the destination IP address in the IP header will be routed via the first device 110. When the fourth device 140 (and in some embodiments its descendant IAB nodes, for example, the child device 170) send an UL IP packet (for example, a F1-U packet) , the fourth device 140 (and in some embodiments its descendant IAB nodes, for example, the child device 170) use its IP address as the source IP address field in the IP header of the UL packet. The third device 130 determine the applicable UL packet to be forwarded over one of the at least one tunnel and the related tunnel, based on the source IP address field in the IP header of the received UL packet and the obtained identity information. For example, when the third device 130 determines that an IP address included in a source IP address field in the received uplink packet matches a source IP address in the obtained identity information, the third device 130 forwards the received UL packet to the first device 110 via one of the at least one tunnel.

Option 2: all UL packets destined to the first device 110 share one tunnel. In option 2, the obtained identity information in the third device 130 may include one or more IP address (es) related to the first device, for example, one or more IP address (es) of the second device 120 or a security gateway, and the IP address (es) may be routable via the first device 110 (for example, the UL packet to the second device 120 or a security gateway is routed via the first device 110) . In another example embodiment, the obtained identity information in the third device 130 may include one or more UL routing ID (s) related to the first device 110, for example, one or more UL routing ID (s) allocated to the fourth device 140 and the routing ID (s) are related to the first device 110. The UL routing ID includes the BAP address of the first device 110. In yet another example, the obtained identity information in the third device 130 may include one or more BAP address related to the first device 110, for example, one or more BAP address of the first device 110. The third device 130 determine the applicable UL packet to be forwarded over one of the at least one tunnel and the related tunnel, based on the destination IP address field in the IP header or the UL routing ID or the BAP address in the received UL packet, and the obtained identity information. For example, when the third device 130 determines that an IP address included in a destination IP address field in the received uplink packet matches a destination IP address in the obtained identity information, and/or an UL routing ID included in BAP header of the received uplink packet matches an UL routing ID in the obtained identity information, and/or a BAP address included in the received uplink packet matches a BAP address in the obtained identity information, the third device 130 forwards the received UL packet to the first device 110 via the tunnel.

Option 3: all UL packets destined to the first device 110 and sharing one or multiple DSCPs share one tunnel. In option 3, the obtained identity information in the third device 130 may include one or more BAP address (es) related to the first device 110, and one or more DSCP value (s) . The third device 130 determine the applicable UL packet to be forwarded over one of the at least one tunnel and the related tunnel, based on the BAP address in the received UL packet and the obtained identity information. For example, when the third device 130 determines that a BAP address included in the received uplink packet matches a BAP address in the obtained identity information and that a DSCP in the IP header of the received uplink packet matches a DSCP in the obtained identity information, the third device 130 forwards the received UL packet to the first device 110 via the tunnel.

Option 4: all UL packets destined to the first device 110 and sharing one or multiple Flow Label share one tunnel. In option 4, the obtained identity information in the third device 130 may include one or more BAP address (es) related to the first device 110, and one or more Flow Label value (s) . The third device 130 determine the applicable UL packet to be forwarded over one of the at least one tunnel and the related tunnel, based on the BAP address and Flow Label or DSCP in the received UL packet and the obtained identity information. For example, when the third device 130 determines that a BAP address included in the received uplink packet matches a BAP address in the obtained identity information and that a Flow Label in an IP header of the received uplink packet matches a Flow Label in the obtained identity information, the third device 130 forwards the received UL packet to the first device 110 via the tunnel.

Option 5: all UL packets using one or multiple specific routing ID share one tunnel. In option 5, the obtained identity information in the third device 130 may include one or more UL routing ID (s) related to the first device 110, for example, one or more UL routing ID (s) allocated to the fourth device 140 and the routing ID (s) are related to the first device 110. The third device 130 determine the applicable UL packet to be forwarded over one of the at least one tunnel and the related tunnel, based on the UL routing ID in the received UL packet and the obtained identity information. For example, when the third device 130 determines that a routing identity included in the received uplink packet matches a UL routing ID in the obtained identity information, the third device 130 forwards the received UL packet to the first device 110 via the tunnel.

It is appreciated that the obtained identity information in the third device 130 may include any combination of a source IP address, a destination IP address, an UL routing ID, a BAP address, a DSCP, and a Flow Label for each tunnel of the at least one tunnel. The applicable UL packet may be identified by any combination of the source IP address, the destination IP address, the UL routing ID, the BAP address, the DSCP, and the Flow Label. It is also appreciated that the obtained information in the third device 130 may include the identify information related to the first device 110 and/or the descendant IAB node (for example, the child device 170, and so on) , thus the obtained identity information can be applicable to UL packet originated from the descendant IAB node (for example, child device 170, and so on) . For example, the obtained identity information may include one or more IP address (es) allocated to a descendant IAB node of the fourth device 140, for example, child IAB 170, and the IP address (es) are anchored in the first device 110. When the descendant IAB node of the fourth device 140, for example, child IAB 170, send an UL IP packet (for example, a F1-U packet) , the descendant IAB node of the fourth device 140, for example, child IAB 170, use the IP address as the source IP address field in the IP header of the UL packet.

In some example embodiments, upon receiving 272 the UL packet from the third device 130, the first device 110 determines whether the at least one uplink packet is targeted to the first device 110 based on at least one BAP header included in the received at least one uplink packet. If the at least one uplink packet is targeted to the first device 110, the first device 110 removes the at least one BAP header from the at least one uplink packet, and forwards 274 the at least one uplink packet without the at least one BAP header to the second device 120 or a security gateway. If the at least one uplink packet comprises no BAP headers, the first device 110 forwards 274 the at least one uplink packet to the second device 120 or a security gateway. Accordingly, the second device 120 receives 276 the at least one uplink packet.

In some example embodiments, the second device 120 may indicate the third device whether to keep or remove the BAP header in the uplink packet received from the fourth device 140, e.g., via the indicated packet format.

In some example embodiments, the established at least one tunnel may be released after the completion of the migration. For example, the second device 120 may transmit to the first device 110 a first request for releasing the at least one tunnel and to the third device 130 a second request for releasing the at least one tunnel. Upon receiving the first request, the first device 110 releases the at least one tunnel. Upon receiving the second request, the third device 130 releases the at least one tunnel.

Alternatively, the at least one tunnel may be kept and reused for other IAB-node. for example, when the source donor-DU assigns that IP address to a different IAB-node, and that IAB-node may perform the same migration later. This may happen for Mobile IAB for train. Alternatively, in some embodiments, the at least one tunnel may be released based on a timer.

Fig. 3 illustrates an example IAB protocol stack 300 for at least one tunnel in accordance with some example embodiments of the present disclosure. In the example of Fig. 3, the second device 120 may be implemented as an IAB-donor-CU, and each of the first device 110 and the third device 130 may be implemented as an IAB-donor-DU, and each of the fourth device 140, the parent device 160 and the child device 170 may be implemented as an IAB-node. Each of the fourth device 140, the parent device 160 and the child device 170 may comprise an IAB-DU and an IAB-MT.

As shown, the child device 170 supports a General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTP-U) protocol, User Datagram Protocol (UDP) , and IP for communication with the second device 120. The child device 170 also supports BAP, Radio Link Control (RLC) protocol, Media Access Control (MAC) protocol, and Physical Layer (PHY) protocol for communication with the fourth device 140. The fourth device 140 supports BAP, RLC, MAC and PHY protocols for communication with the target parent device 160. The third device 130 supports BAP, RLC, MAC and PHY protocols for communication with the target parent device 160 and supports BAP, GTP-U, UDP and IP protocols for communication with the first device 110. The first device 110 supports IP protocol for communication with the child device 170, supports BAP, GTP-U, UDP and IP protocols for communication with the third device 130, and supports IP, Layer 1 (L1) /Layer 2 (L2) protocols for communication with the second device 120.

A General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTP-U) tunnel is established between the first device 110 and the third device 130. In other example embodiments, it is possible that other tunnel protocol, for example, Generic Routing Encapsulation (GRE) protocol, IP in IP tunnel protocol, such as Mobile IP (MIP) , Proxy Mobile IP (PMIP) , may also be used for establishing the tunnel. As shown, a BAP layer is terminated in the first device 110. In this case, an UL packet forwarded from the third device 130 to the first device 110 comprises a BAP header.

Fig. 4 illustrates another example IAB protocol stack 400 for at least one tunnel in accordance with some example embodiments of the present disclosure. Similar to the example in Fig. 3, in the example of Fig. 4, the second device 120 may be implemented as an IAB-donor-CU, and each of the first device 110 and the third device 130 may be implemented as an IAB-donor-DU, and each of the fourth device 140, the parent device 160 and the child device 170 may be implemented as an IAB-node.

The architecture of the IAB protocol stack 400 is similar to that of the IAB protocol stack 300. For example, a GTP-U tunnel is established between the first device 110 and the third device 130. In other example embodiments, it is possible that other tunnel protocol may also be used for establishing the tunnel. As shown, different from the example in Fig. 3, in the example of Fig. 4, a BAP layer is terminated in the third device 130. In this case, an UL packet forwarded from the third device 130 to the first device 110 comprises no BAP headers.

Reference is now made to Fig. 5, which shows a signaling flow 500 for re-routing packets in accordance with some other example embodiments of the present disclosure. For the purpose of discussion, the signaling flow 500 will be described with reference to Fig. 1. The signaling flow 500 may involve the first device 110, the second device 120, the third device 130, the fourth device 140, the parent device 150, the parent device 160, the child device 170, the grandchild device 180 and the terminal device 190 in Fig. 1. In some example embodiments, the signaling flow 500 may be performed in an IAB migration procedure for the fourth device 140 (which also referred to as the fourth device 140) . Thus, the signaling flow 500 will be described in combination with the IAB migration procedure. However, the signaling flow 500 may be performed independent of the IAB migration procedure.

The fourth device 140 sends 501 a MeasurementReport message to the parent device 150. This report is based on a Measurement Configuration in the fourth device 140 received from the second device 120 before.

Upon receiving 502 the MeasurementReport message, the parent device 150 sends 503 an UL RRC MESSAGE TRANSFER message to the second device 120 to convey the received MeasurementReport.

Upon receiving 504 the UL RRC MESSAGE TRANSFER message, the second device 120 sends 505 a UE CONTEXT SETUP REQUEST message to the parent device 160 to create the UE context for the fourth device 140 and set up one or more bearers. These bearers can be used by the fourth device 140 for its own signaling, and, optionally, data traffic.

Upon receiving 506 the UE CONTEXT SETUP REQUEST message, the parent device 160 responds to the second device 120 with a UE CONTEXT SETUP RESPONSE message 507. Accordingly, the second device 120 receives 508 the UE CONTEXT SETUP RESPONSE message.

After the second device 120 decides to perform an IAB-node migration procedure, for example, after receiving UE CONTEXT SETUP RESPONSE message, the second device 120 may initiate the procedure 509 to establish at least one tunnel between the first device 110 and the third device 130. For example,

actions

205, 210, 215, 220, 225, 230, 235, 240 and 245 in Fig. 2 may be performed to establish the at least one tunnel between the first device 110 and the third device 130. In another example, the second device 120 may initiate the procedure to establish at least one tunnel between the first device 110 and the third device 130, early before 508, for example, it may be performed after 504.

The second device 120 sends 510 a UE CONTEXT MODIFICATION REQUEST message to the parent device 150, which includes a generated RRCReconfiguration message. The RRCReconfiguration message includes a default Backhaul (BH) Radio Link Control (RLC) channel and a default BAP Routing ID configuration for UL F1 Control plane interface (F1-C) /non-F1 traffic mapping on the target path. It may include additional BH RLC channels. This action may also include allocation of Transport Network Layer (TNL) address (es) that is (are) routable via the third device 130. The new TNL address (es) may be included in the RRCReconfiguration message as a replacement for the TNL address (es) that is (are) routable via the first device 110. In case Internet Protocol Security (IPsec) tunnel mode is used to protect the F1 and non-F1 traffic, the allocated TNL address is outer IP address. The TNL address replacement is not necessary if the source and target paths use the same IAB-donor-DU. The Transmission Action Indicator in the UE CONTEXT MODIFICATION REQUEST message indicates to stop the data transmission to the fourth device 140.

Upon receiving 511 the UE CONTEXT MODIFICATION REQUEST message, the parent device 150 forwards 512 the received RRCReconfiguration message to the fourth device 140. Accordingly, the fourth device 140 receives 513 the forwarded RRCReconfiguration message.

The parent device 150 responds 514 to the second device 120 with the UE CONTEXT MODIFICATION RESPONSE message. Accordingly, the second device 120 receives 515 the UE CONTEXT MODIFICATION RESPONSE message.

A Random Access procedure 516 is performed at the fourth device 140.

The fourth device 140 responds 517 to the parent device 160 with an RRCReconfigurationComplete message.

Upon receiving 518 the RRCReconfigurationComplete message, the parent device 160 sends 519 an UL RRC MESSAGE TRANSFER message to the second device 120 to convey the received RRCReconfigurationComplete message. Accordingly, the second device 120 receives 520 the UL RRC MESSAGE TRANSFER message.

The second device 120 configures 521 BH RLC channels and BAP-sublayer routing entries on the target path between the fourth device 140 and third device 130 as well as DL mappings on the third device 130 for the target path of the fourth device 140.

After the fourth device 140 connects with the cell of the parent device 160, for example after performing the action 521, the third device 130 starts to forward 270 the buffered UL packet via the tunnel to the first device 110. The packet forwarded to the first device may be a BAP PDU (or containing a BAP header) , or an IP packet. Upon receiving 272 the buffered UL packet, the first device 110 may forward 522 the buffered UL packet to the second device 120. Accordingly, the second device 120 receives 523 the buffered UL packet.

The F1-C connections are switched to use new TNL address (es) of the fourth device 140, the second device 120 updates the UL BH information associated to each GTP-tunnel to the fourth device 140. In other words, redirection 524 of the fourth device 140’s F1 association to new TNL address (es) is performed.

The second device 120 configures 525 BH RLC channels and BAP-sublayer routing entries on the target path between the child device 170 and third device 130 as well as DL mappings on the third device 130 for the target path of the child device 170.

The F1-C connections are switched to use new TNL address (es) of the child device 170, the second device 120 updates the UL BH information associated to each GTP-tunnel to the child device 170. In other words, redirection 526 of the child device 170’s F1 association to new TNL address (es) is performed.

The second device 120 configures 527 BH RLC channels and BAP-sublayer routing entries on the target path between the grandchild device 180 and third device 130 as well as DL mappings on the third device 130 for the target path of the grandchild device 180.

The F1-C connections are switched to use new TNL address (es) of the grandchild device 180, the second device 120 updates the UL BH information associated to each GTP-tunnel to the grandchild device 180. In other words, redirection 528 of the grandchild device 180’s F1 association to new TNL address (es) is performed.

After the migration is completed, e.g. after the action 528, the second device 120 may initiate the tunnel release 529.

It should be appreciated that signaling flow in Fig. 5 is just provided as an example without limitation. In some embodiments, similar mechanism for packet re-routing may be used in a different procedure with different signaling flow.

Fig. 6 shows a flowchart of an example method 600 implemented at a first device in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 600 will be described from the perspective of the first device 110 with respect to Fig. 1.

At block 610, the first device 110 receives, from the second device 120 in communication with the first device 110, a request for establishing at least one tunnel between the first device 110 and the third device 130.

In some example embodiments, the request may indicate a format of at least one UL packet to be forwarded to the first device 110. For example, the request may indicate whether the UP packet will comprise a BAP header.

In some example embodiments, additionally or alternatively, the request may indicate the number of the at least one tunnel to be established.

At block 620, the first device 110 transmits, to the second device 120, tunnel information concerning the at least one tunnel to be established between the first device 110 and the third device 130.

In some example embodiments, additionally or alternatively, the tunnel information may comprise the format of the at least one uplink packet to be forwarded to the first device 110. For example, in the case where the request for establishing the at least one tunnel does not indicate the format of the at least one uplink packet, the tunnel information may comprise the format of the at least one uplink packet.

At block 630, the first device 110 receives at least one uplink packet targeted to the first device 110 from the fourth device 140, via the third device 130 and the at least one tunnel. The received at least one uplink packet may be a BAP PDU (or containing a BAP header) , or an IP packet.

In some example embodiments, upon receiving the UL packet from the third device 130, the first device 110 determines whether the uplink packet comprises a BAP header.

In some embodiments, if the uplink packet comprises the BAP header, the first device 110 determines whether the uplink packet is targeted to the first device 110 based on the BAP header. If the uplink packet is targeted to the first device 110, the first device 110 removes the BAP header from the uplink packet, and forwards the uplink packet without the BAP header to the second device 120 or a security gateway.

In some embodiments, the uplink packet comprises no BAP headers, and the first device 110 forwards the uplink packet to the second device 120 or a security gateway.

Fig. 7 shows a flowchart of an example method 700 implemented at a second device in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 700 will be described from the perspective of the second device 120 with respect to Fig. 1.

At block 710, the second device 120 transmits, to the first device 110 in communication with the second device 120, a request for establishing at least one tunnel between the first device 110 and a third device 130 for forwarding, from the third device 130 to the first device 110, at least one uplink packet targeted to the first device 110 from a fourth device 140.

The second device 120 may transmit the request in any appropriate scenario. For example, in the case of a planned migration, the second device 120 may transmit the request during the handover preparation for the migrating IAB (such as the fourth device 140) . Alternatively, in the case of an unplanned migration, the second device 120 may transmit the request during the re-establishment of the migrating IAB. Alternatively, when the target IAB-donor-DU (such as the third device 130) received an UL Backhaul Adaptation Protocol (BAP) packet related to the source donor-DU (such as the first device 110) , the second device 120 may transmit the request per the request from the target donor-DU. In some embodiments, the second device 120 may transmit the request for establishing a tunnel in advance, i.e., prior to a need for handover or re-establishment is detected.

In some example embodiments, the request may indicate a format of at least one UL packet targeted to the first device 110. For example, the request may indicate whether the UP packet will comprise a BAP header.

At block 720, the second device 120 receives, from the first device 110, tunnel information concerning the at least one tunnel.

At block 730, the second device 120 provides, to the third device 130, the tunnel information for establishment of the at least one tunnel.

In some example embodiments, the second device 120 may transmit the tunnel information to the third device 130 directly.

In some example embodiments, each of the first device 110 and the third device 130 may be implemented as an IAB-donor-DU, and the first device 110 and the third device 130 may be in communication with different IAB-donor-CUs.

In such embodiments, for example, in an XnAP Handover Preparation procedure for a planned migration or in an XnAP Retrieve UE Context procedure for an unplanned migration, the second device 120 may first transmit, via an Xn interface, the tunnel information to the target donor-CU in communication with the third device 130. Then, the target donor-CU forwards the tunnel information to the third device 130.

At block 740, the second device 120 provides, to the third device 130, identity information concerning at least one uplink packet to be forwarded over the at least one tunnel from the third device 130 to the first device 110.

Similar to the tunnel information, in some example embodiments, the second device 120 may transmit the identity information to the third device 130 directly. Alternatively, the second device 120 may provide the identity information to the third device 130 via the target donor-CU in communication with the third device 130.

Fig. 8 shows a flowchart of an example method 800 implemented at a third device in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 800 will be described from the perspective of the third device 130 with respect to Fig. 1.

At block 810, the third device 130 obtains, from the second device 120, tunnel information concerning at least one tunnel to be established between the third device 130 and a first device 110.

In some example embodiments, additionally or alternatively, the tunnel information may comprise the format of the at least one uplink packet to be forwarded to the first device 110.

In some example embodiments, the third device 130 may receive the tunnel information from the second device 120 directly.

In some example embodiments, each of the first device 110 and the third device 130 may be implemented as an IAB-donor-DU, and the first device 110 and the third device 130 may be in communication with and/or controlled by different IAB-donor-CUs. In such embodiments, for example, in an XnAP Handover Preparation procedure for a planned migration or in an XnAP Retrieve UE Context procedure for an unplanned migration, the second device 120 may first transmit, via an Xn interface, the tunnel information to the target donor-CU in communication with the third device 130. Then, the target donor-CU forwards the tunnel information to the third device 130. Accordingly, the third device 130 may receive the tunnel information forwarded from the target donor-CU.

At block 820, the third device 130 obtains, from the second device 120, identity information concerning at least one uplink packet targeted to the first device 110 from a fourth device 140 and to be forwarded to the first device 110 via the at least one tunnel and the third device 130.

Similar to the tunnel information, in some example embodiments, the third device 130 may receive the identity information from the second device 120 directly. Alternatively, the second device 120 may provide the identity information to the third device 130 via the target donor-CU in communication with the third device 130. Accordingly, the third device 130 receives the identity information forwarded from the target donor-CU.

In some example embodiments, the identity information may comprise at least one identity associated with the first device 110. For example, the identity information may comprise at least one of a source IP address or a destination IP address. For another example, the identity information may comprise at least one of a BAP address or a BAP routing ID. For another example, the at least one uplink packet may comprise at least one of a Flow Label or a DSCP.

Upon receiving the UL packet, the third device 130 determines, at block 830, whether the UL packet comprises identity information matching the identity information obtained from the second device 120. The identity information is associated with each tunnel. Thus, when determining the UL packet comprises identity information matching the identity information obtained from the second device 120, the third device 130 may determine the UL packet is an applicable packet and may also determine the related tunnel (in case where more than one tunnel is established) . If the UL packet comprises the identity information, the third device 130 forwards, at block 840, the UL packet to the first device 110 via one of the at least one tunnel. In other words, if the UL packet comprises one or more identities associated with the first device 110, the third device 130 forwards the UL packet to the first device 110.

On the other hand, if the UL packet does not comprise the identity information, the third device 130 may forward the UL packet to the second device 120. In other words, if the UL packet comprises no identities associated with the first device 110, the third device 130 may forward the UL packet to the second device 120.

In some example embodiments, the third device 130 may determine the applicable UL packet to be forwarded to the first device 110 based on whether an IP address included in a source IP address field in the received uplink packet matches a source IP address in the obtained identity information. In these embodiments, if the IP address included in a source IP address field in the received uplink packet matches the source IP address in the obtained identity information, the received uplink packet is determined to be an applicable UL packet to be forwarded to the first device 110.

In some example embodiments, alternatively or additionally, the third device 130 may determine the applicable UL packet to be forwarded to the first device 110 based on whether an IP address included in a destination IP address field in the received uplink packet matches a destination IP address in the obtained identity information.

In some example embodiments, alternatively or additionally, the third device 130 may determine the applicable UL packet to be forwarded to the first device 110 based on whether a routing identity included in the received uplink packet matches a UL routing identity in the obtained identity information.

In some example embodiments, alternatively or additionally, the third device 130 may determine the applicable UL packet to be forwarded to the first device 110 based on whether a BAP address included in the received uplink packet matches a BAP address in the obtained identity information.

In some example embodiments, alternatively or additionally, the third device 130 may determine the applicable UL packet to be forwarded to the first device 110 based on whether a Flow Label in an IP header of the received uplink packet matches a Flow Label in the obtained identity information.

In some example embodiments, alternatively or additionally, the third device 130 may determine the applicable UL packet to be forwarded to the first device 110 based on whether a Differentiated Services Code Point value in the IP header of the received uplink packet matches a Differentiated Services Code Point in the obtained identity information.

The

methods

600, 700 and 800 described above may avoid uplink packet loss, for example, during the inter-donor-DU migration. In addition, the method 800 may not violate the security policy in a transport network and an IAB-donor-DU. In other words, the source filtering can be applied normally for the re-routed packets in the transport network and the IAB-donor-DU.

In some embodiments, the first device may be a source Donor-DU for an IAB node, the second device may be a Donor-CU, the third device may be a target Donor-DU for the IAB node, while the fourth device may be the IAB node.

In some example embodiments, a first apparatus capable of performing any of the method 600 (for example, the first device 110) may comprise means for performing the respective operations of the method 600. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The first apparatus may be implemented as or included in the first device 110. In some example embodiments, the means may comprise a processor and a memory.

In some example embodiments, the first apparatus comprises means for: receiving, at the first apparatus from a second apparatus in communication with the first apparatus, a request for establishing at least one tunnel between the first apparatus and a third apparatus; transmitting, to the second apparatus, tunnel information concerning the at least one tunnel to be established between the first apparatus and the third apparatus; and receiving at least one uplink packet targeted to the first apparatus from a fourth apparatus, via the third apparatus and the at least one tunnel.

In some example embodiments, the at least one tunnel comprises a first tunnel, and the tunnel information comprises at least one of following for the first tunnel: an Internet Protocol address of the first apparatus, an identity of a tunnel endpoint associated with the first tunnel, or a format of the at least one uplink packet.

In some example embodiments, the at least one uplink packet targeted to the first apparatus includes at least one of the following identities associated with the first apparatus 110: a source IP address, a destination IP address, a BAP address, a BAP routing identity, a Flow Label, or a Differentiated Services Code Point .

In some example embodiments, the request indicates at least one of the following: a format of the at least one uplink packet, or the number of the at least one tunnel to be established.

In some example embodiments, the first apparatus further comprises means for: determining whether the at least one uplink packet comprises at least one Backhaul Adaptation Protocol, BAP, header; and in accordance with a determination that the at least one uplink packet comprises the at least one BAP header, determining whether the at least one uplink packet is targeted to the first apparatus based on the at least one BAP header, in accordance with a determination that the at least one uplink packet is targeted to the first apparatus 110, removing the at least one BAP header from the at least one uplink packet, and forwarding the at least one uplink packet without the at least one BAP header to the second apparatus or a security gateway; and in accordance with a determination that the at least one uplink packet comprises no BAP headers, forwarding the at least one uplink packet to the second apparatus or a security gateway.

In some example embodiments, a second apparatus capable of performing any of the method 700 (for example, the second device 120) may comprise means for performing the respective operations of the method 700. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The second apparatus may be implemented as or included in the second device 120. In some example embodiments, the means may comprise a processor and a memory.

In some example embodiments, the second apparatus comprises means for: transmitting, from a second apparatus to a first apparatus in communication with the second apparatus, a request for establishing at least one tunnel between the first apparatus and a third apparatus for forwarding, from the third apparatus to the first apparatus, at least one uplink packet targeted to the first apparatus from a fourth apparatus; receiving, from the first apparatus, tunnel information concerning the at least one tunnel; providing, to the third apparatus, the tunnel information for establishment of the at least one tunnel; and providing, to the third apparatus, identity information concerning at least one uplink packet to be forwarded over the at least one tunnel from the third apparatus to the first apparatus.

In some embodiments, various examples of the at least one tunnel, the request, the tunnel information, and the identity information described above with reference to methods 600-800 and the first apparatus also apply here.

In some example embodiments, a third apparatus capable of performing any of the method 800 (for example, the third device 130) may comprise means for performing the respective operations of the method 800. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The third apparatus may be implemented as or included in the third device 130. In some example embodiments, the means may comprise a processor and a memory.

In some example embodiments, the third apparatus comprises means for: obtaining, at a third apparatus from a second apparatus, tunnel information concerning at least one tunnel to be established between the third apparatus and a first apparatus; obtaining, from the second apparatus, identity information concerning at least one uplink packet targeted to the first apparatus from a fourth apparatus and to be forwarded to the first apparatus via the at least one tunnel and the third apparatus; and in accordance with a determination that an uplink packet received from the fourth apparatus comprises the obtained identity information, forwarding the received uplink packet to the first apparatus via one of the at least one tunnel.

In some embodiments, various examples of the at least one tunnel, the tunnel information, and the identity information described above with reference to methods 600-800, the first apparatus and the second apparatus also apply here.

In some example embodiments, the determination is based on at least one of following: an IP address included in a source IP address field in the received uplink packet matches a source IP address in the obtained identity information; an IP address included in a destination IP address field in the received uplink packet matches a destination IP address in the obtained identity information; a routing identity included in the received uplink packet matches a BAP routing identity in the obtained identity information; a BAP address included in the received uplink packet matches a BAP address in the obtained identity information; a Flow Label in an IP header of the received uplink packet matches a Flow Label in the obtained identity information; or a Differentiated Services Code Point value in the IP header of the received uplink packet matches a Differentiated Services Code Point in the obtained identity information.

Fig. 9 is a simplified block diagram of a device 900 that is suitable for implementing example embodiments of the present disclosure. The device 900 may be provided to implement a communication device, for example, the first device 110, the second device 120, or the third device 130 as shown in Fig. 1. As shown, the device 900 includes one or more processors 910, one or more memories 920 coupled to the processor 910, and one or more communication modules 940 coupled to the processor 910.

The communication module 940 is for bidirectional communications. The communication module 940 has one or more communication interfaces to facilitate communication with one or more other modules or devices. The communication interfaces may represent any interface that is necessary for communication with other network elements. In some example embodiments, the communication module 940 may include at least one antenna.

The processor 910 may be of any type suitable to the local technical network and may include one or more of the following: general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples. The device 900 may have multiple processors, such as an application specific integrated circuit chip that is slaved in time to a clock which synchronizes the main processor.

The memory 920 may include one or more non-volatile memories and one or more volatile memories. Examples of the non-volatile memories include, but are not limited to, a Read Only Memory (ROM) 924, an electrically programmable read only memory (EPROM) , a flash memory, a hard disk, a compact disc (CD) , a digital video disk (DVD) , an optical disk, a laser disk, and other magnetic storage and/or optical storage. Examples of the volatile memories include, but are not limited to, a random access memory (RAM) 922 and other volatile memories that will not last in the power-down duration.

A computer program 930 includes computer executable instructions that could be executed by the associated processor 910. The program 930 may be stored in the memory, e.g., ROM 924. The processor 910 may perform any suitable actions and processing by loading the program 930 into the RAM 922.

The example embodiments of the present disclosure may be implemented by means of the program 930 so that the device 900 may perform any process of the disclosure as discussed with reference to Figs. 2 to 8. The example embodiments of the present disclosure may also be implemented by hardware or by a combination of software and hardware.

In some example embodiments, the program 930 may be tangibly contained in a computer readable medium which may be included in the device 900 (such as in the memory 920) or other storage devices that are accessible by the device 900. The device 900 may load the program 930 from the computer readable medium to the RAM 922 for execution. The computer readable medium may include any types of tangible non-volatile storage, such as ROM, EPROM, a flash memory, a hard disk, CD, DVD, and the like. Fig. 10 shows an example of the computer readable medium 1000 which may be in form of CD, DVD or other optical storage disk. The computer readable medium has the program 930 stored thereon.

Generally, various embodiments of the present disclosure may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. While various aspects of embodiments of the present disclosure are illustrated and described as block diagrams, flowcharts, or using some other pictorial representations, it is to be understood that the block, apparatus, system, technique or method described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

The present disclosure also provides at least one computer program product tangibly stored on a non-transitory computer readable storage medium. The computer program product includes computer-executable instructions, such as those included in program modules, being executed in a device on a target physical or virtual processor, to carry out any of the methods as described above with reference to Figs. 2 to 8. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, or the like that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Machine-executable instructions for program modules may be executed within a local or distributed device. In a distributed device, program modules may be located in both local and remote storage media.

Program code for carrying out methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program codes, when executed by the processor or controller, cause the functions/operations specified in the flowcharts and/or block diagrams to be implemented. The program code may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of the present disclosure, the computer program code or related data may be carried by any suitable carrier to enable the device, apparatus or processor to perform various processes and operations as described above. Examples of the carrier include a signal, computer readable medium, and the like.

The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable medium may include but not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the computer readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM) , a read-only memory (ROM) , an erasable programmable read-only memory (EPROM or Flash memory) , an optical fiber, a portable compact disc read-only memory (CD-ROM) , an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

It should be appreciated that though some embodiments may be implemented by/at IAB nodes, solutions including methods and apparatus proposed in this disclosure could also be applied in other communication systems where similar technical problems exist. Further, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable sub-combination.

Although the present disclosure has been described in languages specific to structural features and/or methodological acts, it is to be understood that the present disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

A first device, comprising:

at least one processor; and

at least one memory including computer program code;

wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the first device to:

receive, from a second device, a request for establishing at least one tunnel between the first device and a third device;

transmit, to the second device, tunnel information concerning the at least one tunnel to be established between the first device and the third device; and

receive at least one uplink packet targeted to the first device from a fourth device, via the third device and the at least one tunnel.
The first device of claim 1, wherein the at least one tunnel comprises a first tunnel, and the tunnel information comprises at least one of following for the first tunnel:

an Internet Protocol address of the first device,

an identity of a tunnel endpoint associated with the first tunnel, or

a format of the at least one uplink packet.
The first device of claim 1, wherein the at least one uplink packet targeted to the first device includes at least one of the following identities associated with the first device:

a source Internet Protocol, IP, address,

a destination IP address,

a Backhaul Adaptation Protocol, BAP, address,

a BAP routing identity,

a Flow Label, or

a Differentiated Services Code Point.
The first device of claim 1, wherein the request indicates at least one of the following:

a format of the at least one uplink packet, or

the number of the at least one tunnel to be established.
The first device of claim 1, wherein the at least one memory and the computer program code are configured to, with the at least one processor, to further cause the first device to perform at least one of the following:

forwarding the received at least one uplink packet to the second device or a security gateway; or

in accordance with a determination that the at least one uplink packet is targeted to the first device based on at least one Backhaul Adaptation Protocol, BAP, header included in the received at least one uplink packet,

removing the at least one BAP header from the at least one uplink packet, and

forwarding the at least one uplink packet without the at least one BAP header to the second device or a security gateway.
A second device, comprising:

at least one processor; and

at least one memory including computer program code;

wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the second device to:

transmit, to a first device, a request for establishing at least one tunnel between the first device and a third device for forwarding, from the third device to the first device, at least one uplink packet targeted to the first device from a fourth device;

receive, from the first device, tunnel information concerning the at least one tunnel;

provide, to the third device, the tunnel information for establishment of the at least one tunnel; and

provide, to the third device, identity information concerning at least one uplink packet to be forwarded over the at least one tunnel from the third device to the first device.
The second device of claim 6, wherein the at least one tunnel comprises a first tunnel, and the tunnel information comprises at least one of the following for the first tunnel:

an Internet Protocol address of the first device,

an identity of a tunnel endpoint associated with the first tunnel, or

a format of the at least one uplink packet.
The second device of claim 6, wherein the identity information comprises at least one of the following identities associated with the first device:

a source Internet Protocol, IP, address,

a destination IP address,

a Backhaul Adaptation Protocol, BAP, address,

a BAP routing identity,

a Flow Label, or

a Differentiated Services Code Point.
The second device of claim 6, wherein the request indicates at least one of the following:

a format of the at least one uplink packet, or

the number of the at least one tunnel.
A third device, comprising:

at least one processor; and

at least one memory including computer program code;

wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the third device to:

obtain, from a second device, tunnel information concerning at least one tunnel to be established between the third device and a first device;

obtain, from the second device, identity information concerning at least one uplink packet targeted to the first device from a fourth device and to be forwarded to the first device via the at least one tunnel and the third device; and

in accordance with a determination that an uplink packet received from the fourth device comprises the obtained identity information, forward the received uplink packet to the first device via one of the at least one tunnel.
The third device of claim 10, wherein the at least one tunnel comprises a first tunnel, and the tunnel information comprises at least one of following for the first tunnel:

an Internet Protocol address of the first device,

an identity of a tunnel endpoint associated with the first tunnel, or

a format of the at least one uplink packet.
The third device of claim 10, wherein the identity information comprises at least one of the following identities associated with the first device:

a source Internet Protocol, IP, address,

a destination IP address,

a Backhaul Adaptation Protocol, BAP, address,

a BAP routing identity,

a Flow Label, or

a Differentiated Services Code Point.
The third device of claim 10, wherein the determination is based on at least one of following:

an Internet Protocol, IP, address included in a source IP address field in the received uplink packet matches a source IP address in the obtained identity information;

an IP address included in a destination IP address field in the received uplink packet matches a destination IP address in the obtained identity information;

a routing identity included in the received uplink packet matches a Backhaul Adaptation Protocol, BAP, routing identity in the obtained identity information;

a BAP address included in the received uplink packet matches a BAP address in the obtained identity information;

a Flow Label in an IP header of the received uplink packet matches a Flow Label in the obtained identity information; or

a Differentiated Services Code Point value in the IP header of the received uplink packet matches a Differentiated Services Code Point in the obtained identity information.
A method, comprising:

receiving, at a first device from a second device, a request for establishing at least one tunnel between the first device and a third device;

transmitting, to the second device, tunnel information concerning the at least one tunnel to be established between the first device and the third device; and

receiving at least one uplink packet targeted to the first device from a fourth device, via the third device and the at least one tunnel.
The method of claim 14, wherein the at least one tunnel comprises a first tunnel, and the tunnel information comprises at least one of following for the first tunnel:

an Internet Protocol address of the first device,

an identity of a tunnel endpoint associated with the first tunnel, or

a format of the at least one uplink packet.
The method of claim 14, wherein the at least one uplink packet targeted to the first device includes at least one of the following identities associated with the first device:

a source Internet Protocol, IP, address,

a destination IP address,

a Backhaul Adaptation Protocol, BAP, address,

a BAP routing identity,

a Flow Label, or

a Differentiated Services Code Point .
The method of claim 14, wherein the request indicates at least one of the following:

a format of the at least one uplink packet, or

the number of the at least one tunnel to be established.
A method, comprising:

transmitting, from a second device to a first device, a request for establishing at least one tunnel between the first device and a third device for forwarding, from the third device to the first device, at least one uplink packet targeted to the first device from a fourth device;

receiving, from the first device, tunnel information concerning the at least one tunnel;

providing, to the third device, the tunnel information for establishment of the at least one tunnel; and

providing, to the third device, identity information concerning at least one uplink packet to be forwarded over the at least one tunnel from the third device to the first device.
A method, comprising:

obtaining, at a third device from a second device, tunnel information concerning at least one tunnel to be established between the third device and a first device;

obtaining, from the second device, identity information concerning at least one uplink packet targeted to the first device from a fourth device and to be forwarded to the first device via the at least one tunnel and the third device; and

in accordance with a determination that an uplink packet received from the fourth device comprises the obtained identity information, forwarding the received uplink packet to the first device via one of the at least one tunnel.
A first apparatus, comprising means for:

receiving, from a second apparatus, a request for establishing at least one tunnel between the first apparatus and a third apparatus;

transmitting, to the second apparatus, tunnel information concerning the at least one tunnel to be established between the first apparatus and the third apparatus; and

receiving at least one uplink packet targeted to the first apparatus from a fourth apparatus, via the third apparatus and the at least one tunnel.
A second apparatus, comprising means for:

transmitting, to a first apparatus, a request for establishing at least one tunnel between the first apparatus and a third apparatus for forwarding, from the third apparatus to the first apparatus, at least one uplink packet targeted to the first apparatus from a fourth apparatus;

receiving, from the first apparatus, tunnel information concerning the at least one tunnel;

providing, to the third apparatus, the tunnel information for establishment of the at least one tunnel; and

providing, to the third apparatus, identity information concerning at least one uplink packet to be forwarded over the at least one tunnel from the third apparatus to the first apparatus.
A third apparatus, comprising means for:

obtaining, from a second apparatus, tunnel information concerning at least one tunnel to be established between the third apparatus and a first apparatus;

obtaining, from the second apparatus, identity information concerning at least one uplink packet targeted to the first apparatus from a fourth apparatus and to be forwarded to the first apparatus via the at least one tunnel and the third apparatus; and

in accordance with a determination that an uplink packet received from the fourth apparatus comprises the obtained identity information, forwarding the received uplink packet to the first apparatus via one of the at least one tunnel.
A computer readable medium comprising program instructions that, when executed by at least one processor, cause an apparatus to perform at least the method of any of claims 14 to 17.
A computer readable medium comprising program instructions that, when executed by at least one processor, cause an apparatus to perform at least the method claim 18.
A computer readable medium comprising program instructions for causing an apparatus to perform at least the method claim 19.