WO2020227906A1

WO2020227906A1 - Mapping of bearer identification into ipv6 architecture

Info

Publication number: WO2020227906A1
Application number: PCT/CN2019/086718
Authority: WO
Inventors: Esa METSÄlÄ; Anantha KANDALA; Esa Malkamäki; Xiang Xu; Dawid Koziol
Original assignee: Nokia Shanghai Bell Co., Ltd.; Nokia Solutions And Networks Oy; Nokia Technologies Oy
Priority date: 2019-05-13
Filing date: 2019-05-13
Publication date: 2020-11-19
Also published as: CN113853773A; CN113853773B

Abstract

Embodiments of the present disclosure relate to apparatuses, methods and computer readable storage media for mapping of bearer identification into Internet Protocol Version 6 (IPv6) architecture. The first device comprises at least one processor; and at least one memory including computer program codes; the at least one memory and the computer program codes are configured to, with the at least one processor, cause the device at least to obtain, from a second device, a bearer identifier indicating a tunnel; and generate a first packet in compliance with a first protocol, the first packet including a first header, the first header generated by mapping the bearer identifier to a first source address in the first header.. In this way, the intermediate node can access the individual bearer since the TE ID is now visible in the source address of the IPv6 SA even the IPsec is applied.

Description

MAPPING OF BEARER IDENTIFICATION INTO IPV6 ARCHITECTURE

FIELD

Embodiments of the present disclosure generally relate to the field of telecommunication, and in particular, to methods, devices and computer readable media for mapping of bearer identification into Internet Protocol Version 6 (IPv6) architecture.

BACKGROUND

The 3rd Generation Partnership Project (3GPP) determines standards and specifications for new radio (NR) Integrated Access and Backhaul (IAB) . In IAB, it is proposed to map general packet radio service (GPRS) tunneling protocol (GTP-U) Tunnel Endpoint Identifier (TE ID) into the flow label in the Internet Protocol Version 6 (IPv6) header.

5G RAN requires IPsec for protection of logical interfaces like a front-haul (F1) interface and NG interface. IPSec can be used to create VPN Tunnels to end-to-end IP Traffic (also called as IPSec Transport mode) or site-to-site IPSec Tunnels (between two VPN Gateways, also known as IPSec Tunnel mode) . In IPSec Tunnel mode, the original IP packet (IP header and the Data payload) is encapsulated within another packet. In IPSec Transport mode, only the Data Payload is secured by IPSec.

SUMMARY

In general, example embodiments of the present disclosure provide a solution for mapping of bearer identification into Internet Protocol Version 6 (IPv6) architecture.

In a first aspect, there is a first device. The first device comprises at least one processor; and at least one memory including computer program codes; the at least one memory and the computer program codes are configured to, with the at least one processor, cause the first device at least to obtain, from a second device, a bearer identifier indicating a tunnel; and generate a first packet in compliance with a first protocol, the first packet including a first header, the first header generated by mapping the bearer identifier to a first source address in the first header.

In a second aspect, there is a third device. The third device comprises at least one processor; and at least one memory including computer program codes; the at least one memory and the computer program codes are configured to, with the at least one processor, cause the third device at least to receive a first packet in compliance with a first protocol from a first device, the first packet including a first header, the first header generated by mapping a bearer identifier to a first source address; encapsulate the first packet based on a second protocol; map the bearer identifier of the first source address in the first header to a second source address in a second header; and generate a second packet in compliance with the second protocol based on the encapsulated packet and the second header.

In a third aspect, there is a fourth device. The fourth device comprises at least one processor; and at least one memory including computer program codes; the at least one memory and the computer program codes are configured to, with the at least one processor, cause the fourth device at least to receive a first packet in compliance with a first protocol from a first device, the first packet including a first header; determine a bearer identifier in a first source address of the first header; and generate a third packet in compliance with a third protocol based on the bearer identifier to enable the third packet to be mapped to a backhaul channel.

In a fourth aspect, there is provided a method. The method comprising obtaining, from a second device, a bearer identifier indicating a tunnel; and generating a first packet in compliance with a first protocol, the first packet including a first header, the first header generated by mapping the bearer identifier to a first source address in the first header.

In a fifth aspect, there is provided a method. The method comprising receiving a first packet in compliance with a first protocol from a first device, the first packet including a first header, the first header generated by mapping a bearer identifier to a first source address; encapsulating the first packet based on a second protocol; mapping the bearer identifier of the first source address in the first header to a second source address in a second header; and generating a second packet in compliance with the second protocol based on the encapsulated packet and the second header.

In a sixth aspect, there is provided a method. The method comprising receiving a first packet in compliance with a first protocol from a first device, the first packet including a first header; determining a bearer identifier in a first source address of the first header; and generating a third packet in compliance with a third protocol based on the bearer identifier to enable the third packet to be mapped to a backhaul channel.

In a seventh aspect, there is provided an apparatus comprises means for means for obtaining, from a second device, a bearer identifier indicating a tunnel; and means for generating a first packet in compliance with a first protocol, the first packet including a first header, the first header generated by mapping the bearer identifier to a first source address in the first header.

In an eighth aspect, there is provided an apparatus comprises means for means for receiving a first packet in compliance with a first protocol from a first device, the first packet including a first header, the first header generated by mapping a bearer identifier to a first source address; means for encapsulating the first packet based on a second protocol; means for mapping the bearer identifier of the first source address in the first header to a second source address in a second header; and means for generating a second packet in compliance with the second protocol based on the encapsulated packet and the second header.

In a ninth aspect, there is provided an apparatus comprises means for means for receiving a first packet in compliance with a first protocol from a first device, the first packet including a first header; means for determining a bearer identifier in a first source address of the first header; and means for generating a third packet in compliance with a third protocol based on the bearer identifier to enable the third packet to be mapped to a backhaul channel.

In a tenth aspect, there is provided a computer readable medium having a computer program stored thereon which, when executed by at least one processor of a device, causes the device to carry out the method according to the fourth aspect.

In an eleventh aspect, there is provided a computer readable medium having a computer program stored thereon which, when executed by at least one processor of a device, causes the device to carry out the method according to the fifth aspect.

In a twelfth aspect, there is provided a computer readable medium having a computer program stored thereon which, when executed by at least one processor of a device, causes the device to carry out the method according to the sixth aspect.

Other features and advantages of the embodiments of the present disclosure will also be apparent from the following description of specific embodiments when read in conjunction with the accompanying drawings, which illustrate, by way of example, the principles of embodiments of the disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the disclosure are presented in the sense of examples and their advantages are explained in greater detail below, with reference to the accompanying drawings, where

FIG. 1 shows an example communication network in which example embodiments of the present disclosure may be implemented;

FIG. 2 shows a schematic diagram of example protocol stack for an IAB architecture;

FIG. 3 shows a schematic diagram illustrating a process for mapping of a bearer identification into Internet Protocol Version 6 (IPv6) architecture according to example embodiments of the present disclosure;

FIG. 4 shows a diagram of an example of IPv6 header according to some example embodiments of the present disclosure;

FIG 5 shows a diagram of example of IPsec modes according to some example embodiments of the present disclosure;

FIG. 6 shows a flowchart of an example method 600 for mapping of a bearer identification into Internet Protocol Version 6 (IPv6) architecture according to some example embodiments of the present disclosure;

FIG. 7 shows a flowchart of an example method 700 for mapping of a bearer identification into Internet Protocol Version 6 (IPv6) architecture according to some example embodiments of the present disclosure;

FIG. 8 shows a flowchart of an example method 800 for mapping of a bearer identification into Internet Protocol Version 6 (IPv6) architecture according to some example embodiments of the present disclosure;

FIG. 9 shows a simplified block diagram of a device that is suitable for implementing example embodiments of the present disclosure; and

Fig. 10 shows a block diagram of an example computer readable medium in accordance with some 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. The disclosure 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.

As used herein, the term “communication network” refers to a network that follows any suitable communication standards or protocols such as long term evolution (LTE) , LTE-Advanced (LTE-A) and 5G NR, and employs any suitable communication technologies, including, for example, MIMO, OFDM, time division multiplexing (TDM) , frequency division multiplexing (FDM) , code division multiplexing (CDM) , Bluetooth, ZigBee, machine type communication (MTC) , enhanced mobile broadband (eMBB) , massive machine type communications (mMTC) and ultra-reliable low-latency communications (uRLLC) technologies. For the purpose of discussion, in some example embodiments, the LTE network, the LTE-Anetwork, the 5G NR network or any combination thereof is taken as an example of the communication network.

As used herein, the term “network device” refers to any suitable device at a network side of a communication network. The network device may include any suitable device in an access network of the communication network, for example, including a base station (BS) , a relay, an access point (AP) , a node B (NodeB or NB) , an evolved NodeB (eNodeB or eNB) , an NG-RAN node (gNB or ng-eNB) , a remote radio module (RRU) , a radio header (RH) , a remote radio head (RRH) , a low power node such as a femto, a pico, a gNB Distributed Unit (DU) , an Integrated Access and Backhaul (IAB) node and a gNB Central Unit (CU) and the like. For the purpose of discussion, in some example embodiments, the gNB is taken as an example of the network device.

The network device may also include any suitable device in a core network, for example, including multi-standard radio (MSR) radio equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs) , multi-cell/multicast coordination entities (MCEs) , mobile switching centers (MSCs) and MMEs, operation and management (O&M) nodes, Operation Support System (OSS) nodes, self-organization network (SON) nodes, positioning nodes, such as enhanced serving mobile location centers (E-SMLCs) , and/or mobile data terminals (MDTs) , and 5G Core network nodes such as the access management function (AMF) , session management function (SMF) .

As used herein, the term “terminal device” refers to a device capable of, configured for, arranged for, and/or operable for communications with a network device or a further terminal device in a communication network. The communications may involve transmitting and/or receiving wireless signals using electromagnetic signals, radio waves, infrared signals, and/or other types of signals suitable for conveying information over air. In some example embodiments, the terminal device may be configured to transmit and/or receive information without direct human interaction. For example, the terminal device may transmit information to the network device on predetermined schedules, when triggered by an internal or external event, or in response to requests from the network side.

Examples of the terminal device include, but are not limited to, user equipment (UE) such as smart phones, wireless-enabled tablet computers, laptop-embedded equipment (LEE) , laptop-mounted equipment (LME) , Mobile Terminals (MT) , such as those embedded in IAB nodes and/or wireless customer-premises equipment (CPE) . For the purpose of discussion, in the following, some example embodiments will be described with reference to UEs as examples of the terminal devices, and the terms “terminal device” and “user equipment” (UE) may be used interchangeably in the context of the present disclosure.

As used herein, the term “cell” refers to an area covered by radio signals transmitted by a network device. The terminal device within the cell may be served by the network device and access the communication network via the network device.

As used herein, 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 singular forms “a” , “an” , and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. The term “includes” and its variants are to be read as open terms that mean “includes, but is not limited to” . The term “based on” is to be read as “based at least in part on” . The term “one embodiment” and “an embodiment” are to be read as “at least one embodiment” . The term “another embodiment” is to be read as “at least one other embodiment” . Other definitions, explicit and implicit, may be included below.

FIG. 1 shows an example communication network 100 in which example embodiments of the present disclosure can be implemented. The communication network 100 includes network devices 110-1, 110-2 and 110-3, which may be collectively referred to as the network device 110. If the communication network 100 is an IAB system, for example, the network devices 110-1 may be referred to as a central unit (CU) of IAB donor and the network devices 110-3 may be referred to a Distributed Unit (DU) of IAB donor. The network devices 110-2 may be referred to a Distributed Unit (DU) of IAB node. The network device 110-1 and network device 110-3 are connected via wired connection, for example, a fiber connection. The network device 110-2 wirelessly connected to the network device 110-3. The wireless connection is also referred as wireless backhaul. The network device 110-2 indirectly connect to network device 110-1 via network device 110-3. The network device 110-3 is also referred as intermediate node.

The communication network may also comprises a terminal device 120 connected to the network device 110-3. The network device 110-1 may be connected to a gateway 130 which may perform the corresponding security operation for the data transmitted from the network device 110-1. However, the gateway 130 may also be integrated in the network device 110-1. After performing the corresponding security operation, the data may be transmitted to the network device 110-3 either from the network device 110-1 or the gateway 130.

Further, the network devices 110 may also refer to any of gNB base station, a gNB-DU and a gNB-CU.

As an example of the communication network 100, the IAB system comprises an IAB donor and one or more IAB nodes. The IAB donor may be implemented as a gNB that terminates wireless backhaul radio interface from one or more IAB nodes. The IAB donor has wired/fiber connectivity with a core network. The IAB donor may include a central unit (CU) and one or more DUs.

In case where the IAB system is implemented by using the L2-based solutions, the IAB node may include a DU, but does not include CU. In case where the IAB system is implemented by using the L3-based solutions, the IAB node may include a DU or include a DU and a CU.

In example embodiments, each IAB node logically includes a mobile terminal (MT) that maintains connectivity with one or more upstream nodes (using for example, dual connectivity) . Similar to a conventional user equipment which includes an MT, 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. Based on signal strength, signal quality and other factors, a handover of an IAB node to a different upstream node may be triggered by RRC. The Donor-CU may also add or remove dual/Multi-Connectivity (DC/MC) legs by sending RRC Connection Reconfiguration messages. The IAB topology may change over time as radio conditions fluctuate, and as IAB nodes move, are added or removed. Handover and addition or removal of DC legs may be designed to work on a time scale of seconds to minutes, corresponding to macroscopic movement of MTs through a cellular network.

A CU (such as Donor-CU or CU of an IAB node) 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) , depending on the functional split option. The operations of the DUs may be controlled by the CU.

The IAB donor may serve directly connected IAB nodes such as the network device 110-2 and IAB node. The IAB donor may also serve directly connected terminal devices (not shown) . The IAB node may serve one or more terminal devices directly connected to the IAB node. For example, the IAB node may serve a terminal device 120 directly connected to the IAB node.

It is to be understood that the number of IAB nodes, the intermediate nodes, and terminal devices connected to the IAB nodes is only for the purpose of illustration without suggesting any limitations. The communication network may include any suitable number of IAB nodes and terminal devices adapted for implementing example embodiments of the present disclosure.

Currently, 3GPP is working on NR Integrated Access and Backhaul. In an example of IAB architecture, backhauling of F1-U uses an adaptation layer or general packet radio service (GPRS) tunneling protocol (GTP-U) combined with an adaptation layer. FIG. 2 shows an example protocol stack of IAB architecture.

As shown in FIG. 2, the IP layer carried by adapt is connected to the fronthaul’s IP-plane through a routing function at the IAB Donor-DU. On this IP layer, all IAB nodes hold IP addresses, which are routable from the IAB donor CU-CP.

The IP address assignment to the IAB node could be based on IPv6 Neighbour Discovery Protocol where the DU acts as an IPv6 router sending out ICMPv6 Router Advertisement (RA) over one or more backhaul bearer towards the IAB node. Other methods are not excluded. The extended IP-plane allows native F1-C to be used between an IAB-node DU and IAB-donor CU-CP. Signaling traffic can be prioritized on this IP routing plane using differentiated services code point (DSCP) markings in compliance with TS 38.474. The UE’s and the MT’s RRC use signaling radio bearer (SRB) , which is carried over F1-C.

Currently, it is required that an IAB node’s IPv6 address shall be related to a Donor-DU. This is because when the Donor-CU sends an IP packet (for example, carrying the F1 application protocol (F1AP) message, or SCTP packet) with destination IP address set to the IAB node’s IPv6 address, the IP packet shall be routed to the Donor-DU. That is, Donor-DU is acting as an anchor and the message is routed via the Donor-DU to the IAB node. For the user plane of the IAB Architecture, when the Donor-CU sends a GTP-U packet with destination IP address set to IAB node’s address, the GTP-U packet must be routed to the Donor-DU. Then the Donor-DU will route the GTP-U packet to the IAB node. This does not preclude any other IP packet sent to the IAB node, when the destination IP address of the IP packet is set to the IAB node’s IPv6 address. These IP packets shall be routed to the Donor-DU.

5G RAN requires IPsec for protection of logical interfaces like a front-haul (F1) interface and NG interface. IPSec can be used to create VPN Tunnels to end-to-end IP Traffic (also called as IPSec Transport mode) or site-to-site IPSec Tunnels (between two VPN Gateways, also known as IPSec Tunnel mode) . In IPSec Tunnel mode, the original IP packet (IP header and the Data payload) is encapsulated within another packet.

In IAB, it is proposed to map general packet radio service (GPRS) tunneling protocol (GTP-U) Tunnel Endpoint Identifier (TE ID) into the flow label in the Internet Protocol Version 6 (IPv6) header. This is problematic since the flow label field is 20 bits while GTP-U TE ID is 32 bits.

If applying the IPSec operation for an IP packet, some information may be hided in the protected field of the IP packet. That is, the intermediate nodes may not read anything except the unprotected fields of the IP packet.

Moreover, another problem with IPsec is that load balancing/Equal Cost Multipath (ECMP) routing is not possible, since the IPsec hides the upper layer port numbers and there is no entropy in the header fields that are available clear-text.

Furthermore, active-active load sharing is important since it allows load balancing traffic over multiple links/paths, increasing the utilization of links, and provides resiliency against link failure. With both ECMP multi-path routing and L2 Ethernet link aggregation distribution, it is typically wished to keep conversation together on the same link/path and not deploy packet-based load balancing. This requires identifying the conversation or flow, which is identified typically by source and destination MAC/IP addresses, and source/destination L4 ports. When traffic is protected by IPsec, only the source and destination MAC/IP addresses are visible. Due to this, load balancing does not work since there is no entropy in these fields.

Therefore, the present disclosure proposes a solution for routing based on a bearer identifier for IPv6. With the proposed solution, IAB can use IPv6 IPsec while the intermediate node can access the individual bearer since the TE ID is now visible in the source address of the IPv6 SA. Intermediate IAB node reads the TE ID from the IPsec source IPv6 address field which is clear text. Meanwhile, ECMP with IPv6 IPsec is possible, as again now the source IPv6 address field varies and creates necessary entropy. Traffic can be load shared over two or more links in active-active mode on flow (conversation) basis.

FIG. 3 shows a schematic diagram of a process 300 for mapping of bearer identification into IPv6 architecture according to example embodiments of the present disclosure will be described with reference to FIG. 1. In this example, the process 300 may involve the network device 110 and the gateway 130 as illustrated in FIG. 1.

In the case shown in FIG. 3, the network device 110-2 may allocate radio resources for a terminal device 120 connected with it (for example the terminal device shown in FIG. 3) and allocate 310 a bearer identifier for a Data Radio Bearer (DRB) . The network device 110-2 may transmit 320 a message including the bearer identifier to the network device 110-1. This message may be transmitted to the network device 110-1 via one or more intermediate network nodes, for example, the network device 110-3. The bearer identifier may indicate tunnel for a downlink data transmission from the network device 110-1 to the network device 110-2. For example, the tunnel may be a GTP-U tunnel identified by a GTP-U TE ID.

When the network device 110-1 receives a data packet from, for example, the core network, and then the data packet is to be transmitted from the network device 110-1 to the network device 110-2, the network device 110-1 encapsulate the data packet in a GTP-U packet. The GTP-U packet includes the bearer identifier from the message received from the network device 110-2. The network device 110-1 maps the bearer identifier to a source address in an IPv6 header associated with network device 110-1. The network device 110-1 further generates 330 an IPv6 packet having the IPv6 header, and the GTP-U packet.

FIG. 4 shows a diagram of an example of IPv6 header 400 according to some example embodiments of the present disclosure. In the IPv6 header 400 as shown in FIG. 4, the bearer identifier obtained from the network device 110-2 may be mapped into the source address in the source address field 401 of the IPv6 header 400.

In some example embodiments, the bearer identifier may be mapped into the interface identifier in the source address. The interface identifier may have a length of 64 bit while the bearer identifier may have a length of 32 bit. Thus, the bearer identifier may be mapped into a certain range of the interface identifier, for example, the last 32 bit in the interface identifier.

Referring back to FIG. 3, the network device 110-1 may transmit the IPv6 packet having the IPv6 header including a bearer identifier to the network device 110-3. The network device 110-3 may extract the bearer identity from the source address of the IP packet and generates 380, based on the bearer identity, a downlink packet including the data packet in compliance with a Backhaul Adaptation Protocol (BAP) , to be transmitted to the network device 110-2 over the wireless backhaul.

In some example embodiments, for the sake of data security, the network device 110-1 may encapsulate the IPv6 packet based on the IPsec. As mentioned above, the IPsec may include two encapsulating mode, i.e. the transport mode and the tunnel mode.

FIG 5 shows a diagram of example of IPsec modes according to some example embodiments of the present disclosure. The encapsulating process in both modes may be described in detail with reference to FIG. 5 as below.

FIG. 5 shows an IPv6 packet 510 which may be the IPv6 packet generated by the network device 110-1. As shown in FIG. 5, an IPv6 packet 510 may have an original IP header 511. After performing an encapsulating operation based on the IPsec in a transport mode for the IPv6 packet 510, an encapsulated packet 520 is generated which have encapsulated field 522 associated with the IPv6 packet 510. In the transport mode, the field associated with the source address in the original IP header 511 is not changed. That is, the header 521 in the encapsulated packet 520 may be same as the original IP header 511 in the IPv6 packet 510.

On the contrast, if an encapsulating operation based on the IPsec in a tunnel mode is performed for the IPv6 packet 510, an encapsulated packet 530 is generated which have encapsulated field 532 associated with the IPv6 packet 510. In the tunnel mode, the original IP header 511 may also be encapsulated. Thus, a new IPv6 header 531 is required for the encapsulated packet 530. In this case, the bearer identifier in the source address of the original IP header 511 may be copied to a source address of the new IPv6 header 531 to ensure the bearer identifier to be seen by the subsequent node for an uplink transmission or a downlink transmission.

The encapsulating operation based on the IPsec in a tunnel mode may be performed by the network device 110-1. In some example embodiments, for example, the network device 110-1 implement the security gateway function, the network device 110-1 may encapsulate the IPv6 packet and add the new IPv6 header for the encapsulated packet. Similarly, the bearer identifier in the source address of the original IP header may be copied to a source address of the new IPv6 header. The network device 110-1 further transmit 360 the IPv6 packet generated by the network device 110-1 to the network device 110-3. It should be understood that the packet transmitted from the network device 110-1 may be a packet without encapsulating based on the IPsec or an encapsulated packet generated based on one of the encapsulating mode of the encapsulating operation above.

In some example embodiments, the encapsulating operation based on the IPsec in a tunnel mode may also be performed by an external device, for example, the gateway 130. Referring back to FIG. 3, in some example embodiments, the network device 110-1 may transmit 340 the IPv6 packet to a security gateway 130. The security gateway may encapsulate 350 the IPv6 packet in an IPSec packet, and add the new IPv6 header for the encapsulated packet. Similarly, the bearer identifier in the source address of the original IP header may be copied to a source address of the new IPv6 header. The security gateway may transmit 370 the encapsulated packet to the network device 110-3.

Upon the network device 110-3 received the IPSec packet from the network device 110-1, or from the gateway 130, the network device 110-3 may also extract the bearer identity from the source address of the IPSec packet. The network device 110-3 may generate 380, based on the bearer identity, a downlink packet including the data packet in compliance with a Backhaul Adaptation Protocol (BAP) , to be transmitted to the network device 110-2 over the wireless backhaul. The bearer identity may be mapped to another bearer identity in the Backhaul Adaptation Protocol header or the bearer identity may be used to select the backhaul (BH) Radio Link Control (RLC) channel/bearer. The latter implies that the bearer identity is mapped to a logical channel identity identifying the BH RLC channel/bearer.

In this way, IAB can use IPv6 IPsec while the intermediate node can access the individual bearer since the TE ID is now visible in the source address of the IPv6 header. The intermediate node (s) reads the TE ID from the IPsec source IPv6 address field which is clear text.

Furthermore, as described above, with both ECMP multi-path routing and L2 Ethernet link aggregation distribution, it is typically wished to keep conversation together on the same link/path and not deploy packet-based load balancing.

With IPsec tunnel mode, the IPv6 source address of the Outer IP header includes TE ID. This means that for each new bearer (e.g. conversation) , a separate IPsec tunnel source address exists.

With IPsec transport mode, there is no separate IPsec tunnel source address, but the original IPv6 source address is visible. Thus, with IPsec transport mode, similarly each new conversation can be identified by the IPv6 source address (with TE ID included to the interface ID portion) .

It should be noted that the load balancing with ECMP and/or Link aggregation is possible on any network node on the path from a gNB to the core network, also in general between any two mobile network elements that have GTP-U tunnel.

For example, in case of a path from a gNB to a User Plane Function (UPF) , the gNB maps the TE ID allocated by UPF, to its IPv6 source address field, for the uplink direction. For the downlink direction, the UPF maps the TE ID allocated by the gNB, to its IPv6 source address field. In case of a path from a gNB-CU and a gNB-DU, the TE ID allocated by CU is mapped by DU to its’ source IPv6 address. The TE ID allocated by DU is mapped by CU to its’ source IPv6 address.

For load sharing with ECMP, common fields as below are used as an example:

source MAC address (source MAC visible)

destination MAC address (destination MAC visible)

source IP address (outer source IP visible with IPsec)

destination IP address (outer destination IP visible with IPsec)

L4 source port (source port not visible with IPsec)

L4 destination port (source port not visible with IPsec)

protocol (outer visible with IPsec)

With IPsec tunnel mode, the IPsec tunnel source address varies, when TE ID is included into IPv6 source address as proposed. This means that it is possible to have ECMP load sharing hash algorithm divide traffic into a link and a further link on TEID basis. It should be understood that there can be any number of equal cost paths. With IPsec transport mode, there is only single IP source address, which varies due to TEID. Any intermediate router/switch element may now load share traffic using ECMP or Link aggregation.

Same issue exists with Ethernet layer. Distribution algorithm is not standardized by IEEE802.1ax.

Ethernet Link aggregation (802.1ax) can divide traffic into two (or more) links, once again typically based on the same input and additionally Ethernet Source and destination MAC addresses, and the Ethertype:

source IP address (outer source IP visible with IPsec)

destination IP address (outer destination IP visible with IPsec)

source MAC address (source MAC visible)

destination MAC address (destination MAC visible)

L4 source port (source port not visible with IPsec)

L4 destination port (source port not visible with IPsec)

With the solution, the source IPv6 address varies on conversation basis as it includes TE ID, even if all other fields are identical. When the Link Aggregation distribution algorithm utilizes also source IP, the IPsec tunnel traffic can be distributed. Any intermediate router/switch element may now load share traffic using ECMP or Link aggregation.

More details of the example embodiments in accordance with the present disclosure will be described with reference to FIGs. 6-8.

FIG. 6 shows a flowchart of an example method 600 for mapping of bearer identification into Internet Protocol Version 6 (IPv6) architecture according to some example embodiments of the present disclosure. The method 600 can be implemented at the network device 110-1 as shown in FIG. 1. For the purpose of discussion, the method 600 will be described with reference to FIG. 1.

At 610, the network device 110-1 obtains a bearer identifier indicating a tunnel from the network device 110-2.

In some example embodiments, the network device 110-1 may map the bearer identifier into an interface identifier of the first source address, generate the first header based on the mapped interface identifier and generate the first packet based on the first header.

At 620, the network device 110-1 generates a first packet in compliance with a first protocol, the first packet including a first header, the first header generated by mapping the bearer identifier to a first source address in the first header.

In some example embodiments, the network device 110-1 may further encapsulate the first packet based on a second protocol without changing a field associated with the first source address in the first header.

In some example embodiments, the network device 110-1 may further encapsulate the first packet based on a second protocol, map the first source address in the first header to a second source address in a second header and generate a second packet in compliance with the first protocol based on the encapsulated packet and the second header.

In some example embodiments, the network device 110-1 may further transmit the first packet to a gateway 130 for encapsulating the first packet based on a second protocol.

In some example embodiments, the second protocol is an Internet Protocol Security suite of protocols in transport mode.

In some example embodiments, the second protocol is an Internet Protocol Security suite of protocols in tunnel mode.

In some example embodiments, the network device 110-1 may further transmit the first packet to a fourth device to enable the fourth device to obtain the bearer identifier.

In some example embodiments, the first protocol is an Internet Protocol Version 6.

FIG. 7 shows a flowchart of an example method 700 for mapping of bearer identification into Internet Protocol Version 6 (IPv6) architecture according to some example embodiments of the present disclosure. The method 700 can be implemented at the gateway 130 as shown in FIG. 1. For the purpose of discussion, the method 700 will be described with reference to FIG. 1.

At 710, the gateway 130 receives a first packet in compliance with a first protocol from a network device 110-1, the first packet including a first header, the first header generated by mapping a bearer identifier to a first source address.

At 720, the gateway 130 encapsulates the first packet based on a second protocol.

At 730, the gateway 130 maps the bearer identifier of the first source address in the first header to a second source address in a second header.

At 740, the gateway 130 generates a second packet in compliance with the second protocol based on the encapsulated packet and the second header.

FIG. 8 shows a flowchart of an example method 800 for mapping of bearer identification into Internet Protocol Version 6 (IPv6) architecture according to some example embodiments of the present disclosure. The method 800 can be implemented at the network device 110-3 as shown in FIG. 1. For the purpose of discussion, the method 800 will be described with reference to FIG. 1.

At 810, the network device 110-3 receives a first packet in compliance with a first protocol from a network device 110-1, the first packet including a first header.

At 820, the network device 110-3 determines a bearer identifier in a first source address of the first header.

At 830, the network device 110-3 generates a third packet in compliance with a third protocol based on the bearer identifier to enable the third packet to be mapped to a backhaul channel. The third packet may include a third header generated by mapping the bearer identifier to a further bearer identifier in the third header. Alternatively, the bearer identifier is used for mapping of the third packet to a backhaul radio link control (RLC) channel and the corresponding logical channel identity (LCID) .

In some example embodiments, the first protocol is an Internet Protocol Version 6 and the third protocol is Backhaul Adaptation Protocol.

In some example embodiments, an apparatus capable of performing the method 600 (for example, implemented at network device 110-1) may comprise means for performing the respective steps 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.

In some example embodiments, the apparatus comprises means for obtaining, from a second device, a bearer identifier indicating a tunnel; and means for generating a first packet in compliance with a first protocol, the first packet including a first header, the first header generated by mapping the bearer identifier to a first source address in the first header.

In some example embodiments, an apparatus capable of performing the method 700 (for example, implemented at the gateway 130) may comprise means for performing the respective steps 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.

In some example embodiments, the apparatus comprises means for receiving a first packet in compliance with a first protocol from a first device, the first packet including a first header, the first header generated by mapping a bearer identifier to a first source address; means for encapsulating the first packet based on a second protocol; means for mapping the bearer identifier of the first source address in the first header to a second source address in a second header; and means for generating a second packet in compliance with the first protocol based on the encapsulated packet and the second header.

In some example embodiments, an apparatus capable of performing the method 800 (for example, implemented at the network device 110-3) may comprise means for performing the respective steps 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.

In some example embodiments, the apparatus comprises means for receiving a first packet in compliance with a first protocol from a first device, the first packet including a first header; means for determining a bearer identifier in a first source address of the first header; and means for generating a third packet in compliance with a third protocol based on the bearer identifier to enable the third packet to be mapped to a backhaul channel.

FIG. 9 is a simplified block diagram of a device 900 that is suitable for implementing embodiments of the present disclosure. The device 900 may be provided to implement the communication device, for example the network device 110 as shown in Fig. 1. As shown, the device 900 includes one or more processors 910, one or more memories 940 coupled to the processor 910, and one or more transmitters and/or receivers (TX/RX) 940 coupled to the processor 910.

The TX/RX 940 is for bidirectional communications. The TX/RX 940 has at least one antenna to facilitate communication. The communication interface may represent any interface that is necessary for communication with other network elements.

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) , 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 are executed by the associated processor 910. The program 930 may be stored in the ROM 930. The processor 910 may perform any suitable actions and processing by loading the program 930 into the RAM 920.

The 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. 3 to 8. The embodiments of the present disclosure may also be implemented by hardware or by a combination of software and hardware.

In some 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 in form of CD or DVD. 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 real or virtual processor, to carry out the methods 500 and 600 as described above with reference to FIGs. 2-6. 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 codes 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.

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 codes;

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

obtain, from a second device, a bearer identifier indicating a tunnel; and

generate a first packet in compliance with a first protocol, the first packet including a first header, the first header generated by mapping the bearer identifier to a first source address in the first header.
The first device of claim 1, wherein the first device is caused to generate the first packet by:

mapping the bearer identifier into an interface identifier of the first source address;

generating the first header based on the mapped interface identifier; and

generating the first packet based on the first header.
The first device of claim 1, wherein the first device is further caused to:

encapsulate the first packet based on a second protocol without changing a field associated with the first source address in the first header.
The first device of claim 3, wherein the second protocol is an Internet Protocol Security suite of protocols in transport mode.
The first device of claim 1, wherein the first device is further caused to:

encapsulate the first packet based on a second protocol;

map the first source address in the first header to a second source address in a second header; and

generate a second packet in compliance with the second protocol based on the encapsulated packet and the second header.
The first device of claim 1, wherein the first device is further caused to:

transmit the first packet to a third device for encapsulating the first packet based on a second protocol.
The first device of Claim 5 or 6, wherein the second protocol is an Internet Protocol Security suite of protocols in tunnel mode.
The first device of Claim 6, wherein the third device is a security gateway.
The first device of Claim 1, wherein the first device is a network device and the second device is a network device.
The first device of claim 1, wherein the first device is further caused to:

transmit the first packet to a fourth device to enable the fourth device to obtain the bearer identifier.
The first device of claim 1 or 5, wherein the first protocol is an Internet Protocol Version 6.
A third device comprising:

at least one processor; and

at least one memory including computer program codes;

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

receive a first packet in compliance with a first protocol from a first device, the first packet including a first header, the first header generated by mapping a bearer identifier to a first source address;

encapsulate the first packet based on a second protocol;

map the bearer identifier of the first source address in the first header to a second source address in a second header; and

generate a second packet in compliance with the second protocol based on the encapsulated packet and the second header.
The third device of Claim 12, wherein the third device comprises security gateway.
The third device of Claim 12, wherein the second protocol is an Internet Protocol Security suite of protocols in tunnel mode.
The third device of claim 12, wherein the first device is a network device.
The third device of claim 12, wherein the first protocol is an Internet Protocol Version 6.
A fourth device comprising:

at least one processor; and

at least one memory including computer program codes;

the at least one memory and the computer program codes are configured to, with the at least one processor, cause the fourth device at least to:

receive a first packet in compliance with a first protocol from a first device, the first packet including a first header;

determine a bearer identifier in a first source address of the first header; and

generate a third packet in compliance with a third protocol based on the bearer identifier to enable the third packet to be mapped to a backhaul channel.
The fourth device of Claim 17, wherein the first device is a network device and the fourth device is a network device.
The third device of claim 17, wherein the first protocol is an Internet Protocol Version 6 and the third protocol is Backhaul Adaptation Protocol.
A method comprising:

obtaining, from a second device, a bearer identifier indicating a tunnel; and

generating a first packet in compliance with a first protocol, the first packet including a first header, the first header generated by mapping the bearer identifier to a first source address in the first header.
The method of Claim 20, wherein generating the first packet comprises:

mapping the bearer identifier into an interface identifier of the first source address;

generating the first header based on the mapped interface identifier; and

generating the first packet based on the first header.
The method of Claim 20, further comprising:

encapsulating the first packet based on a second protocol without changing a field associated with the first source address in the first header.
The method of Claim 22, wherein the second protocol is an Internet Protocol Security suite of protocols in transport mode.
The method of Claim 20, further comprising:

encapsulating the first packet based on a second protocol;

mapping the first source address in the first header to a second source address in a second header; and

generating a second packet in compliance with the first protocol based on the encapsulated packet and the second header.
The method of Claim 20, further comprising:

transmitting the first packet to a third device for encapsulating the first packet based on a second protocol.
The method of Claim 24 or 25, wherein the second protocol is an Internet Protocol Security suite of protocols in tunnel mode.
The method of Claim 25, wherein the third device is a security gateway.
The method of Claim 20, wherein the first device is a network device and the second device is a network device.
The method of Claim 20, further comprising:

transmitting the first packet to a fourth device to enable the fourth device to obtain the bearer identifier.
The method of Claim 20 or 24, wherein the first protocol is an Internet Protocol Version 6.
A method comprising:

receiving a first packet in compliance with a first protocol from a first device, the first packet including a first header, the first header generated by mapping a bearer identifier to a first source address;

encapsulating the first packet based on a second protocol;

mapping the bearer identifier of the first source address in the first header to a second source address in a second header; and

generating a second packet in compliance with the second protocol based on the encapsulated packet and the second header.
The method of Claim 31, wherein the third device comprises security gateway.
The method of Claim 31, wherein the second protocol is an Internet Protocol Security suite of protocols in tunnel mode.
The method of Claim 31, wherein the first device is a network device.
The method of Claim 31, wherein the first protocol is an Internet Protocol Version 6.
A method comprising:

receiving a first packet in compliance with a first protocol from a first device, the first packet including a first header;

determining a bearer identifier in a first source address of the first header; and

generating a third packet in compliance with a third protocol based on the bearer identifier to enable the third packet to be mapped to a backhaul channel.
The method of Claim 36, wherein the first device is a network device and the fourth device is a network device.
The method of Claim 36, wherein the first protocol is an Internet Protocol Version 6 and the third protocol is Backhaul Adaptation Protocol.
An apparatus, comprising:

means for obtaining, from a second device, a bearer identifier indicating a tunnel; and

means for generating a first packet in compliance with a first protocol, the first packet including a first header, the first header generated by mapping the bearer identifier to a first source address in the first header.
An apparatus, comprising:

means for receiving a first packet in compliance with a first protocol from a first device, the first packet including a first header, the first header generated by mapping a bearer identifier to a first source address;

means for encapsulating the first packet based on a second protocol;

means for mapping the bearer identifier of the first source address in the first header to a second source address in a second header; and

means for generating a second packet in compliance with the second protocol based on the encapsulated packet and the second header.
An apparatus, comprising:

means for receiving a first packet in compliance with a first protocol from a first device, the first packet including a first header;

means for determining a bearer identifier in a first source address of the first header; and

means for generating a third packet in compliance with a third protocol based on the bearer identifier to enable the third packet to be mapped to a backhaul channel.
A non-transitory computer readable medium comprising program instructions for causing an apparatus to perform at least the method of any of claims 20-30.
A non-transitory computer readable medium comprising program instructions for causing an apparatus to perform at least the method of any of claims 31-35.
A non-transitory computer readable medium comprising program instructions for causing an apparatus to perform at least the method of any of claims 36-38.