CN113853773B

CN113853773B - Mapping bearer identities to IPv6 architecture

Info

Publication number: CN113853773B
Application number: CN201980096346.7A
Authority: CN
Inventors: E·梅特萨拉; A·坎达拉; E·马尔卡马基; 许翔; D·科齐欧
Original assignee: Nokia Shanghai Bell Co Ltd; Nokia Solutions and Networks Oy
Current assignee: Nokia Shanghai Bell Co Ltd; Nokia Solutions and Networks Oy
Priority date: 2019-05-13
Filing date: 2019-05-13
Publication date: 2024-03-08
Anticipated expiration: 2039-05-13
Also published as: CN113853773A; WO2020227906A1

Abstract

Embodiments of the present disclosure relate to apparatuses, methods, and computer-readable storage media for mapping bearer identities to internet protocol version 6 (IPv 6) architecture. The first device includes: 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 at least: acquiring a bearing identifier of an indication tunnel from second equipment; and generating a first packet conforming to the first protocol, the first packet including a first header, the first header being generated by mapping the bearer identification to a first source address in the first header. In this way, the intermediate node can access the separate bearer because the TE ID is now visible in the source address of the IPv6SA, even if IPsec is applied.

Description

Mapping bearer identities to IPv6 architecture

Technical Field

Embodiments of the present disclosure relate generally to the field of telecommunications and, more particularly, relate to a method, apparatus, and computer readable medium for mapping bearer identities to an internet protocol version 6 (IPv 6) architecture.

Background

The third generation partnership project (3 GPP) determines standards and specifications for New Radio (NR) Integrated Access and Backhaul (IAB). In IAB, it is proposed to map a General Packet Radio Service (GPRS) tunneling protocol (GTP-U) tunnel endpoint identification (TE ID) into a flow label in an Internet protocol version 6 (IPv 6) header.

The 5G RAN requires IPsec to protect logical interfaces, such as the forwarding (F1) interface and NG interface. IPSec may be used to create VPN tunnels or site-to-site IPSec tunnels (between two VPN gateways, also referred to as IPSec tunnel modes) for end-to-end IP traffic (also referred to as IPSec transport modes). In IPSec tunnel mode, the original IP packets (IP header and data payload) are encapsulated in another packet. In IPSec transmission mode, only the data payload is protected by IPSec.

Disclosure of Invention

In summary, example embodiments of the present disclosure provide a scheme for mapping bearer identities to an internet protocol version 6 (IPv 6) architecture.

In a first aspect, a first device is provided. The first device includes: 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 at least: acquiring a bearing identifier of an indication tunnel from second equipment; and generating a first packet conforming to the first protocol, the first packet including a first header, the first header generated by mapping the bearer identification to a first source address in the first header.

In a second aspect, a third device is provided. The third device includes: 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 at least: receiving a first packet conforming to a first protocol from a first device, the first packet including a first header, the first header generated by mapping a bearer identification to a first source address; encapsulating the first packet based on a second protocol; mapping a bearer identification of a first source address in a first header to a second source address in a second header; and generating a second packet conforming to the second protocol based on the encapsulated packet and the second header.

In a third aspect, a fourth apparatus is provided. The fourth device includes: 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 fourth device to at least: receiving a first packet conforming to a first protocol from a first device, the first packet including a first header; determining a bearing identifier in a first source address of a first header; and generating a third packet conforming to a third protocol according to the bearer identification so that the third packet can be mapped to the backhaul channel.

In a fourth aspect, a method is provided. The method comprises the following steps: acquiring a bearing identifier of an indication tunnel from second equipment; and generating a first packet conforming to the first protocol, the first packet including a first header, the first header generated by mapping the bearer identification to a first source address in the first header.

In a fifth aspect, a method is provided. The method comprises the following steps: receiving a first packet conforming to a first protocol from a first device, the first packet including a first header, the first header generated by mapping a bearer identification to a first source address; encapsulating the first packet based on a second protocol; mapping a bearer identification of a first source address in a first header to a second source address in a second header; and generating a second packet conforming to the second protocol based on the encapsulated packet and the second header.

In a sixth aspect, a method is provided. The method comprises the following steps: receiving a first packet conforming to a first protocol from a first device, the first packet including a first header; determining a bearing identifier in a first source address of a first header; and generating a third packet conforming to a third protocol according to the bearer identification so that the third packet can be mapped to the backhaul channel.

In a seventh aspect, an apparatus is provided. The device comprises: means for obtaining, from a second device, a bearer identification indicating a tunnel; and means for generating a first packet conforming to the first protocol, the first packet comprising a first header, the first header generated by mapping the bearer identification to a first source address in the first header.

In an eighth aspect, an apparatus is provided. The device comprises: means for receiving a first packet conforming to a first protocol from a first device, the first packet comprising a first header, the first header generated by mapping a bearer identification to a first source address; means for encapsulating the first packet based on a second protocol; means for mapping a bearer identification of a first source address in a first header to a second source address in a second header; and means for generating a second packet conforming to a second protocol based on the encapsulated packet and the second header.

In a ninth aspect, an apparatus is provided. The device comprises: means for receiving a first packet conforming to a first protocol from a first device, the first packet including a first header; means for determining a bearer identification in a first source address of a first header; and means for generating a third packet conforming to a third protocol from the bearer identification to enable the third packet to be mapped to the backhaul channel.

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

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

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

Other features and advantages of embodiments of the present disclosure will become apparent from the following description of the embodiments, taken in conjunction with the accompanying drawings, which illustrate, by way of example, the principles of the embodiments of the disclosure.

Drawings

Embodiments of the present disclosure are presented by way of example and their advantages are explained in more detail below with reference to the drawings, in which:

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

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

FIG. 3 shows a schematic diagram of a process of mapping bearer identities to an Internet protocol version 6 (IPv 6) architecture, according to an example embodiment of the present disclosure;

fig. 4 illustrates a block diagram of an example of an IPv6 header according to some example embodiments of the present disclosure;

fig. 5 illustrates a block diagram of IPsec mode in accordance with some example embodiments of the present disclosure;

fig. 6 illustrates a flowchart of an example method 600 for mapping bearer identities to an internet protocol version 6 (IPv 6) architecture, according to some example embodiments of the present disclosure;

fig. 7 illustrates a flowchart of an example method 700 for mapping bearer identities to an internet protocol version 6 (IPv 6) architecture, according to some example embodiments of the present disclosure;

fig. 8 illustrates a flowchart of an example method 800 for mapping bearer identities to an internet protocol version 6 (IPv 6) architecture, according to some example embodiments of the present disclosure;

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

fig. 10 illustrates a block diagram of an example computer-readable medium, according to some embodiments of the disclosure.

The same or similar reference numbers will be used throughout the drawings to refer to the same or like elements.

Detailed Description

Principles of the present disclosure will now be described with reference to some example embodiments. It should be understood that these embodiments are described merely for illustration and to aid one skilled in the art in understanding and practicing the present disclosure and do not imply any limitation on the scope of the present disclosure. The disclosure described herein may be implemented in various ways other than those 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 skill in the art to which this disclosure belongs.

As used herein, the term "communication network" refers to a network that conforms to and employs any suitable communication standard or protocol, such as Long Term Evolution (LTE), LTE-advanced (LTE-a), and 5G NR. Communication technologies include, 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), large-scale machine type communication (emtc), and ultra-reliable low-delay communication (uilllc) technologies. For discussion purposes, in some example embodiments, an LTE network, an LTE-a network, a 5G NR network, or any combination thereof is taken as an example of a communication network.

As used herein, the term "network device" refers to any suitable device on the network side of a communication network. The network devices may include any suitable devices in an access network of a communication network, including, for example, base Stations (BSs), relays, access Points (APs), node BS (nodebs or NB), evolved nodebs (enodebs or enbs), NG-RAN nodes (gNB or NG-eNB), remote radio modules (RRUs), radio Headers (RH), remote Radio Headers (RRHs), low power nodes, such as femto, pico, gNB Distributed Units (DUs), integrated Access and Backhaul (IAB) nodes, and gNB Central Units (CUs), among others. For discussion purposes, in some example embodiments, the gNB is taken as an example of a network device.

The network devices may also include any suitable devices in the core network, including, for example, multi-standard radio (MSR) radio devices such as MSR BS, network controllers (BSCs) such as Radio Network Controllers (RNCs) or base station controllers, multi-cell/Multicast Coordination Entities (MCEs), mobile Switching Centers (MSCs) and MMEs, operation and management (O & M) nodes, operation Support System (OSS) nodes, self-organizing network (SON) nodes, positioning nodes, e.g., enhanced services mobile positioning centers (E-SMLCs) and/or Mobile Data Terminals (MDTs), and 5G core network nodes, e.g., access Management Functions (AMFs), session Management Functions (SMFs).

As used herein, the term "terminal device" refers to a device that is configurable, arranged and/or operable to communicate with a network device or another terminal device in a communication network. Communication may involve the transmission and/or reception of wireless signals using electromagnetic signals, radio waves, infrared signals, and/or other types of signals suitable for conveying information over the air. In some example embodiments, the terminal device may be configured to send and/or receive information without direct human interaction. For example, the terminal device may transmit information to the network device according to a predetermined schedule when triggered by an internal or external event, or in response to a request from the network side.

Examples of terminal devices include, but are not limited to, user Equipment (UE), such as a smart phone, a tablet computer supporting wireless functionality, a Laptop Embedded Equipment (LEE), a laptop equipment (LME), a Mobile Terminal (MT), such as those embedded in an IAB node and/or a wireless client device (CPE). For discussion purposes, some example embodiments will be described below with reference to a UE as an example of a terminal device, and the terms "terminal device" and "user equipment" (UE) may be used interchangeably in the following context.

As used herein, the term "cell" refers to the area covered by radio signals transmitted by a network device. Terminal devices within a cell may be served by network devices through which the communication network is accessed.

As used herein, the term "circuit" may refer to one or more or all of the following: (a) Pure hardware circuit implementations (e.g., implementations in analog and/or digital circuitry only); (b) A combination of hardware circuitry and software, for example (as applicable): (i) A combination of analog and/or digital hardware circuitry and software/firmware, and (ii) any portion of a hardware processor working with software (including digital signal processors), software, and memory to cause a device (e.g., a mobile phone or server) to perform various functions; (c) Hardware circuitry and/or a processor, such as a microprocessor or a portion of a microprocessor, requires software (e.g., firmware) to operate, but the software may not appear when operation is not required.

The definition of circuit applies to all uses of this term in this application, including in any claims. As another example, as used in this application, the term circuitry also encompasses hardware-only circuitry or a processor (or multiple processors) or a portion of hardware circuitry or a processor and its (or their) accompanying implementation of software and/or firmware. The term circuitry also encompasses, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit or server for a mobile device, a cellular network device, or a similar integrated circuit in another 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 "comprising" and variants thereof is to be construed as open-ended terms, meaning "including, but not limited to. The term "based on" is to be understood as "based at least in part on". The terms "one embodiment" and "an embodiment" are to be understood as "at least one embodiment". The term "another embodiment" should be understood as "at least one other embodiment". Other definitions, both explicit and implicit, may also be included below.

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

The communication network may also include a terminal device 120 connected to the network device 110-3. Network device 110-1 may be coupled to gateway 130 and gateway 130 may perform corresponding security operations on data transmitted from network device 110-1. However, gateway 130 may also be integrated in network device 110-1. After performing the corresponding security operations, data may be transmitted from network device 110-1 or gateway 130 to network device 110-3.

Furthermore, network device 110 may also refer to any of a gNB base station, a gNB-DU, and a gNB-CU.

As an example of the communication network 100, the IAB system includes an IAB donor and one or more IAB nodes. The IAB donor may be implemented as a gNB terminating a wireless backhaul radio interface from one or more IAB nodes. The IAB donor has a wire/fiber connection with the core network. The IAB donor may include a Central Unit (CU) and one or more DUs.

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

In an example embodiment, each IAB node logically includes a Mobile Terminal (MT) that maintains connectivity (e.g., using dual connectivity) with one or more upstream nodes. Similar to legacy user equipment including MTs, an MT of an IAB node may use Radio Resource Control (RRC) signaling to provide radio link measurements of alternative upstream nodes to its current serving gNB CU. Based on factors such as signal strength, signal quality, etc., handover of the IAB node to a different upstream node may be triggered by the RRC. The donor CU may also add or delete dual/multiple connection (DC/MC) legs by sending RRC connection reconfiguration messages. The IAB topology may change over time with fluctuations in radio conditions and movement, addition or deletion of IAB nodes. The switching and addition or removal of DC legs can be designed to operate on a time scale of seconds to minutes, which corresponds to macroscopic movement of the MT through the cellular network.

A CU (e.g., an IAB node's donor-CU or CU) may be a logical node, which may include functions (e.g., a gNB function), such as transmission of user data, mobility control, radio access network sharing, positioning, session management, etc., in addition to those specifically assigned to DUs. The CU may control the operation of the DU through a forward (F1) interface. A DU is a logical node that may include a subset of functions (e.g., a gNB function), depending on the function split option. The operation of the DUs may be controlled by the CU.

The IAB donor may serve directly connected IAB nodes, such as network device 110-2 and the 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 will be appreciated that the number of IAB nodes, intermediate nodes, and terminal equipment connected to the IAB nodes are for illustration purposes only and are not meant to be limiting in any way. The communication network may include any suitable number of IAB nodes and terminal devices suitable for implementing example embodiments of the present disclosure.

Currently, 3GPP is researching NR integrated access and backhaul. In an example of an IAB architecture, the backhaul of F1-U is combined with an adaptation layer using an adaptation layer or a General Packet Radio Service (GPRS) tunneling protocol (GTP-U). Fig. 2 shows an example protocol stack of an IAB architecture.

As shown in fig. 2, the IP layer carried by the adaptation is connected to the forwarded IP plane through the routing function of the IAB donor-DU. At this IP layer, all IAB nodes hold IP addresses that can be routed from the IAB donor CU-CP.

The IP address assigned to the IAB node may be based on an IPv6 neighbor discovery protocol, wherein the DU acts as an IPv6 router sending ICMPv6 Router Advertisement (RA) towards the IAB node over one or more backhaul bearers. Other methods are not excluded. The extended IP plane allows the use of local F1-C between the IAB node DU and the IAB donor CU-CP. Signaling traffic may be prioritized over this IP routing plane using Differentiated Services Code Point (DSCP) marking conforming to TS 38.474. The RRC of the UE and MT uses a Signaling Radio Bearer (SRB), which is carried over the F1-C bearer.

Currently, it is required that the IPv6 address of the IAB node is related to the donor-DU. This is because when the donor-CU sends an IP packet with the destination IP address set to the IPv6 address of the IAB node, e.g., an SCTP packet or an F1 application protocol (F1 AP) message, the IP packet will be routed to the donor-DU. That is, the donor-DU acts as an anchor point and messages are routed to the IAB node via the donor-DU. For the user screen of the IAB architecture, when the donor-CU sends a GTP-U packet with the destination IP address set to the IAB node address, the GTP-U packet must be routed to the donor-DU. The donor-DU then routes the GTP-U packet to the IAB node. This does not exclude any other IP packets sent to the IAB node when the destination IP address of the IP packet is set to the IPv6 address of the IAB node. These IP packets will be routed to the donor-DU.

The 5G RAN requires IPsec to protect logical interfaces such as the forwarding (F1) interface and the NG interface. IPSec can be used to create VPN tunnels for peer-to-peer IP traffic (also referred to as IPSec transport mode) or site-to-site IPSec tunnels (between two VPN gateways, also referred to as IPSec tunnel mode). In IPSec tunnel mode, the original IP packets (IP header and data payload) are encapsulated in another packet.

In IAB, it is proposed to map a General Packet Radio Service (GPRS) tunneling protocol (GTP-U) tunnel endpoint identification (TE ID) into a flow label in an internet protocol version 6 (IPv 6) header. This is problematic because the flow label field is 20 bits and the GTP-UTE ID is 32 bits.

If IPSec is applied to an IP packet, some information may be hidden in the protected field of the IP packet. That is, the intermediate node may not read anything other than the unprotected fields of the IP packet.

Furthermore, another problem with IPsec is that it is not possible to implement load balancing/equal cost multi-path (ECMP) routing because IPsec hides upper layer port numbers and there is no entropy in the header fields of the available plain text.

In addition, active-active load sharing is important because it allows load balancing traffic across multiple links/paths, increases link utilization, and provides resilience to link failures. For both ECMP multipath routing and L2 ethernet link aggregation distribution, it is often desirable to maintain conversations over the same link/path rather than deploying packet-based load balancing. This requires identifying the session or flow, typically identified by the source and destination MAC/IP addresses and the source/destination L4 ports. When traffic is IPsec protected, only the source and destination MAC/IP addresses are visible. Thus, load balancing does not work because there is no entropy in these fields.

Therefore, the present disclosure proposes a scheme for routing based on an IPv6 bearer identification. Using the proposed scheme, the IAB may use IPv6 IPsec and the intermediate node may access a single bearer because the TE ID is now visible in the source address of the IPv6 SA. The intermediate IAB node reads the TEID from the plain text IPsec source IPv6 address field. At the same time ECMP with IPv6 IPsec is possible, also because now the source IPv6 address field changes and generates the necessary entropy. Traffic may be load shared on two or more links based on flows (conversations) in active-active mode.

Fig. 3 illustrates a schematic diagram of a process 300 of mapping bearer identities to IPv6 architecture according to an example embodiment of the present disclosure, which will be described with reference to fig. 1. In this example, process 300 may involve network device 110 and gateway 130 as shown in fig. 1.

In the case shown in fig. 3, the network device 110-2 may allocate radio resources for the terminal device 120 (e.g., the terminal device shown in fig. 3) connected thereto and allocate 310 bearer identities for Data Radio Bearers (DRBs). Network device 110-2 may send 320 a message to network device 110-1 that includes the bearer identification. The message may be transmitted to network device 110-1 via one or more intermediate network nodes (e.g., network device 110-3). The bearer identification may indicate a tunnel for downlink data transmission from network device 110-1 to network device 110-2. For example, the tunnel may be a GTP-U tunnel identified by a GTP-U TE ID.

When network device 110-1 receives a packet from, for example, a core network, and then the packet is to be transmitted from network device 110-1 to network device 110-2, network device 110-1 encapsulates the packet in a GTP-U packet. GTP-U packets include bearer identifications from messages received from network device 110-2. Network device 110-1 maps the bearer identification to a source address in an IPv6 header associated with network device 110-1. Network device 110-1 further generates 330 an IPv6 packet having an IPv6 header and a GTP-U packet.

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

In some example embodiments, the bearer identification may be mapped to an interface identification in the source address. The interface identifier may have a length of 64 bits and the bearer identifier may have a length of 32 bits. Thus, the bearer identification may be mapped to a certain range of interface identifications, e.g. the last 32 bits of the interface identification.

Referring back to fig. 3, network device 110-1 may send an IPv6 packet with an IPv6 header including a bearer identification to network device 110-3. Network device 110-3 may extract the bearer identification from the source address of the IP packet and generate 380, based on the bearer identification, a downlink packet comprising a packet conforming to a Backhaul Adaptation Protocol (BAP) for transmission over the wireless backhaul to network device 110-2.

In some example embodiments, network device 110-1 may encapsulate an IPv6 packet based on IPsec for data security. As described above, IPsec may include two encapsulation modes, namely, a transport mode and a tunnel mode.

Fig. 5 illustrates a block diagram of an example of IPsec mode in accordance with some example embodiments of the present disclosure. The packaging process for both modes can be described in detail with reference to fig. 5.

Fig. 5 shows an IPv6 packet 510, which may be an IPv6 packet generated by network device 110-1. As shown in fig. 5, IPv6 packet 510 may have an original IP header 511. After performing an IPsec based encapsulation operation in transport mode on the IPv6 packet 510, an encapsulated packet 520 is generated having an encapsulation field 522 associated with the IPv6 packet 510. In transport mode, the fields associated with the source address in original IP header 511 are unchanged. That is, the header 521 in the encapsulated packet 520 may be the same as the original IP header 511 in the IPv6 packet 510.

In contrast, if an IPsec-based encapsulation operation in tunnel mode is performed for an IPv6 packet 510, an encapsulated packet 530 is generated having an encapsulation field 532 associated with the IPv6 packet 510. In tunnel mode, the original IP header 511 may also be encapsulated. Thus, a new IPv6 header 531 is required for the encapsulated packet 530. At this point, the bearer identification in the source address of the original IP header 511 may be copied into the source address of the new IPv6 header 531 to ensure that the bearer identification is seen by the subsequent node for either upstream or downstream transmissions.

The IPsec-based encapsulation operation in tunnel mode may be performed by network device 110-1. In some example embodiments, for example, network device 110-1 implements a security gateway function, network device 110-1 may encapsulate an IPv6 packet and add a new IPv6 header to the encapsulated packet. Similarly, the bearer identification in the source address of the original IP header may be copied into the source address of the new IPv6 header. Network device 110-1 further transmits 360 the IPv6 packet generated by network device 110-1 to network device 110-3. It should be understood that the packet sent from the network device 110-1 may be a packet that is not encapsulated based on IPsec, or may be an encapsulated packet that is generated based on one of the encapsulation manners of the encapsulation operations described above.

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

Network device 110-3 may also extract the bearer identification from the source address of the IPSec packet when network device 110-3 receives the IPSec packet from network device 110-1 or from gateway 130. Network device 110-3 may generate 380, based on the bearer identification, a downlink packet comprising a data packet conforming to a Backhaul Adaptation Protocol (BAP) for transmission over a wireless backhaul to network device 110-2. The bearer identification may be mapped to another bearer identification in the backhaul adaptation protocol header or the bearer identification may be used to select a Backhaul (BH) Radio Link Control (RLC) channel/bearer. The latter means that the bearer identity is mapped to a logical channel identity for identifying the BH RLC channel/bearer.

In this way, the IAB may use IPv6 IPsec while the intermediate node may access a separate bearer because the TE ID is now visible in the source address of the IPv6 header. The intermediate node reads the TE ID from the plain text IPsec source IPv6 address field.

Furthermore, as noted above, for ECMP multipath routing and L2 ethernet link aggregation distribution, it is often desirable to keep conversations together on the same link/path and not deploy packet-based load balancing.

In IPsec tunnel mode, the IPv6 source address of the external IP header includes the TE ID. This means that there is a separate IPsec tunnel source address for each new bearer (e.g., session).

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

It should be noted that load balancing with ECMP and/or link aggregation is also possible on any network node on the path from the gNB to the core network, typically also between any two mobile network elements with GTP-U tunnels.

For example, in the case of a path from the gNB to the User Plane Function (UPF), the gNB maps the TE ID allocated by the UPF to its IPv6 source address field for the uplink direction. For the downstream direction, the UPF maps the TE ID allocated by the gNB to its IPv6 source address field. For paths from gNB-CUs and gNB-DUs, the TE IDs allocated by the CUs are mapped by the DUs to their source IPv6 addresses. The TE ID allocated by the DU is mapped to its source IPv6 address by the CU.

For load sharing with ECMP, the following common fields are used as examples:

source MAC address (Source MAC visible)

Destination MAC address (destination MAC visible)

Source IP Address (visible external Source IP with IPsec)

Destination IP address (visible external destination IP using IPsec)

L4 Source Port (invisible Source Port with IPsec)

L4 destination port (invisible source port using IPsec)

Protocol (IPsec external visible)

With IPsec tunnel mode, the IPsec tunnel source address changes when the TE ID is included in the IPv6 source address as proposed. This means that the ECMP load sharing hash algorithm can be made to divide traffic into one link and another based on TEID. It should be appreciated that any number of equivalent paths may exist. With IPsec transport mode, there is only a single IP source address, which varies from TEID to TEID. Any intermediate router/switch element can now use ECMP or link aggregation to implement load sharing traffic.

The same problem exists with the ethernet layer. The distribution algorithm is not standardized by IEEE 802.1 ax.

Ethernet link aggregation (802.1 ax) can divide traffic into two (or more) links, again typically based on the same input and additional ethernet source and destination MAC addresses, and ethernet type:

source IP Address (visible external Source IP with IPsec)

Destination IP address (visible external destination IP using IPsec)

Source MAC address (Source MAC visible)

Destination MAC address (destination MAC visible)

L4 Source Port (invisible Source Port with IPsec)

L4 destination port (invisible source port using IPsec)

With this solution, the source IPv6 address varies on a session basis because it includes the TE ID (even though all other fields are identical). IPsec tunnel traffic may be distributed when the link aggregation distribution algorithm also uses source IP. Any intermediate router/switch element can now use ECMP or link aggregation to implement load sharing traffic.

Further details of example embodiments according to the present disclosure will be described with reference to fig. 6-8.

Fig. 6 illustrates a flowchart of an example method 600 for mapping bearer identities to an internet protocol version 6 (IPv 6) architecture, according to some example embodiments of the present disclosure. Method 600 may be implemented at network device 110-1 as shown in fig. 1. For discussion purposes, the method 600 will be described with reference to fig. 1.

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

In some example implementations, network device 110-1 may map the bearer identification to an interface identification of the first source address, generate a first header based on the mapped interface identification, and generate the first packet based on the first header.

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

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

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

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

In some example embodiments, the second protocol is an internet protocol security protocol family in a transmission mode.

In some example embodiments, the second protocol is an internet protocol security protocol family in tunnel mode.

In some example implementations, the network device 110-1 may further send the first packet to the fourth device to cause the fourth device to obtain the bearer identification.

In some example embodiments, the first protocol is internet protocol version 6.

Fig. 7 illustrates a flowchart of an example method 700 for mapping bearer identities to an internet protocol version 6 (IPv 6) architecture, according to some example embodiments of the present disclosure. Method 700 may be implemented at gateway 130 as shown in fig. 1. For discussion purposes, the method 700 will be described with reference to fig. 1.

At 710, gateway 130 receives a first packet from a first device conforming to a first protocol, the first packet including a first header generated by mapping a bearer identification to a first source address.

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

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

At 740, gateway 130 generates a second packet conforming to a second protocol based on the encapsulated packet and the second header.

In some example embodiments, the first protocol is internet protocol version 6.

Fig. 8 illustrates a flowchart of an example method 800 for mapping bearer identities to an internet protocol version 6 (IPv 6) architecture, according to some example embodiments of the present disclosure. Method 800 may be implemented at network device 110-3 as shown in fig. 1. For discussion purposes, the method 800 will be described with reference to fig. 1.

At 810, network device 110-3 receives a first packet from network device 110-1 conforming to a first protocol, the first packet including a first header.

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

At 830, network device 110-3 generates a third packet according to the bearer identification that conforms to a third protocol to enable the third packet to be mapped to the backhaul channel. The third packet may include a third header generated by mapping the bearer identification to another bearer identification in the third header. Alternatively, the bearer identification is used to map the third packet to a backhaul Radio Link Control (RLC) channel and a corresponding Logical Channel Identification (LCID).

In some example implementations, the first protocol is internet protocol version 6 and the third protocol is backhaul adaptation protocol.

In some example implementations, an apparatus (e.g., implemented at network device 110-1) capable of performing method 600 may include means for performing the various steps of method 600. These means may be embodied in any suitable form. For example, these means may be implemented in a circuit or a software module.

In some example embodiments, the apparatus includes: means for obtaining, from the second device, a bearer identification indicating the tunnel; and means for generating a first packet conforming to the first protocol, the first packet comprising a first header, the first header generated by mapping the bearer identification to a first source address in the first header.

In some example implementations, an apparatus capable of performing method 700 (e.g., implemented at gateway 130) may include means for performing the various steps of method 700. These means may be embodied in any suitable form. For example, these means may be implemented in a circuit or a software module.

In some example embodiments, the apparatus includes: means for receiving a first packet conforming to a first protocol from a first device, the first packet comprising a first header, the first header generated by mapping a bearer identification to a first source address; means for encapsulating the first packet based on a second protocol; means for mapping a bearer identification of a first source address in a first header to a second source address in a second header; and means for generating a second packet conforming to a second protocol based on the encapsulated packet and the second header.

In some example implementations, an apparatus (e.g., implemented at network device 110-3) capable of performing method 800 may include means for performing the various steps of method 800. These means may be embodied in any suitable form. For example, these means may be implemented in a circuit or a software module.

In some example embodiments, the apparatus includes: means for receiving a first packet conforming to a first protocol from a first device, the first packet including a first header; means for determining a bearer identification in a first source address of a first header; and means for generating a third packet conforming to a third protocol from the bearer identification to enable the third packet to be mapped to the backhaul channel.

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

TX/RX 940 is used for two-way communication. TX/RX 940 has at least one antenna to facilitate communications. The communication interface may represent any interface required to communicate with other network elements.

The processor 910 may be of any type suitable for use in a local technical network and may include, by way of non-limiting example, one or more of the following: general purpose computers, special purpose computers, microprocessors, digital Signal Processors (DSPs), and processors based on a multi-core processor architecture. The device 900 may have multiple processors, such as an application specific integrated circuit chip that is slaved in time to the clock of the synchronous master processor.

Memory 920 may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memory include, but are not limited to, read-only memory (ROM) 924, electrically programmable read-only memory (EPROM), flash memory, hard disks, compact Disks (CD), digital Video Disks (DVD), and other magnetic and/or optical storage. Examples of volatile memory include, but are not limited to, random Access Memory (RAM) 922 and other volatile memory that does not last for the duration of the power outage.

The computer program 930 includes computer-executable instructions that are executed by the associated processor 910. Program 930 may be stored in ROM 924. Processor 910 may perform any suitable actions and processes by loading program 930 into RAM 922.

Embodiments of the present disclosure may be implemented by the program 930 such that the device 900 may perform any of the processes of the present disclosure discussed with reference to fig. 3-8. The embodiments of the present invention may also be realized in hardware or a combination of hardware and software.

In some implementations, the program 930 may be tangibly embodied in a computer-readable medium, which may be included in the device 900 (e.g., in the memory 920) or other storage device accessible to the device 900. Device 900 may load program 930 from a computer-readable medium into RAM 922 for execution. The computer readable medium may include any type of tangible, non-volatile memory, such as ROM, EPROM, flash memory, hard disk, CD, DVD, etc. Fig. 10 shows an example of a computer readable medium 1000 in the form of a CD or DVD. The computer readable medium has a program 930 stored thereon.

In general, various embodiments of the 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 the embodiments of the present disclosure are illustrated and described as block diagrams, flow charts, or using some other illustration, it is to be understood that these blocks, apparatus, systems, techniques or methods 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 comprises computer executable instructions, such as those included in program modules, executed in a device on a target real processor or virtual processor to implement the methods 500 and 600 as described above with reference to fig. 2-6. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform particular tasks or implement particular abstract data types. In various embodiments, the functionality of the program modules may be combined or split between program modules as desired. Machine-executable instructions for program modules may be executed within local or distributed devices. In distributed devices, program modules may be located in both local and remote memory storage media.

Program code for carrying out the methods of the present disclosure may be written in any combination of one or more programming languages. These program code may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus such that the program code, when executed by the processor or controller, causes the functions/operations specified in the flowchart and/or block diagram to be implemented. The program code may execute entirely on the 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 this disclosure, computer program code or related data may be carried by any suitable carrier to enable a device, apparatus, or processor to perform the various processes and operations described above. Examples of carriers include signals, computer readable media, and the like.

The computer readable medium may be a machine readable signal medium or a machine readable storage medium. The computer readable medium may include, but is 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 machine-readable storage media 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.

Moreover, although 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 some cases, multitasking and parallel processing may be advantageous. Also, while the above discussion contains several specific example embodiment details, these should not be construed as limitations on the scope of the 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 can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination.

Although the disclosure has been described in language specific to structural features and/or methodological acts, it is to be understood that the 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

1. A first device, comprising:

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 at least:

acquiring a bearing identifier of an indication tunnel from second equipment; and

generating a first packet conforming to internet protocol version 6IPv6, the first packet comprising a first header, the first header being generated by mapping the bearer identification to a first source address in the first header,

wherein the first device is further caused to:

encapsulating the first packet based on a second protocol without changing a field associated with the first source address in the first header when the second protocol is configured as an internet protocol security protocol family in a transport mode; or alternatively

When the second protocol is configured as an internet protocol security protocol family in tunnel mode, the bearer identification in the first source address in the first header is copied into a second source address to generate a second header.

2. The first device of claim 1, wherein the first device is caused to generate the first packet by:

Mapping the bearer identification to an interface identification of the first source address;

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

the first packet is generated based on the first header.

3. The first device of claim 1, wherein the first device is further caused to: when the second protocol is configured as an internet protocol security protocol family in tunnel mode:

encapsulating the first packet based on the second protocol;

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

a second packet conforming to the second protocol is generated based on the encapsulated packet and the second header.

4. The first device of claim 1, wherein the first device is further caused to:

the first packet is sent to a third device, which is configured to encapsulate the first packet based on a second protocol.

5. The first device of claim 4, wherein the third device is a security gateway.

6. The first device of claim 1, wherein the first device is a network device and the second device is a network device.

7. The first device of claim 1, wherein the first device is further caused to:

and sending the first packet to fourth equipment so that the fourth equipment can acquire the bearing identification.

8. A third device, comprising:

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 at least:

receiving a first packet conforming to internet protocol version 6IPv6 from a first device, the first packet comprising a first header generated by mapping a bearer identification to a first source address;

encapsulating the first packet based on a second protocol;

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

9. The third device of claim 8, wherein the third device comprises a security gateway.

10. The third device of claim 8, wherein the second protocol is an internet protocol security protocol family in tunnel mode.

11. The third device of claim 8, wherein the first device is a network device.

12. A fourth device, comprising:

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 fourth device to at least:

receiving a first packet conforming to internet protocol version 6IPv6 from a first device, the first packet comprising a first header;

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

and generating a third packet conforming to a backhaul adaptation protocol according to the bearer identification so that the third packet can be mapped to a backhaul channel.

13. The fourth device of claim 12, wherein the first device is a network device and the fourth device is a network device.

14. A method, comprising:

generating a first packet conforming to internet protocol version 6IPv6, the first packet comprising a first header generated by mapping the bearer identification to a first source address in the first header, further comprising:

15. The method of claim 14, wherein generating the first packet comprises:

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

the first packet is generated based on the first header.

16. The method of claim 14, further comprising: when the second protocol is configured as an internet protocol security protocol family in tunnel mode:

encapsulating the first packet based on the second protocol;

17. The method of claim 14, further comprising:

18. The method of claim 17, wherein the third device is a security gateway.

19. The method of claim 14, wherein the first device operable to perform the method is a network device and the second device is a network device.

20. The method of claim 14, further comprising:

21. A method, comprising:

encapsulating the first packet based on a second protocol;

22. The method of claim 21, wherein a third device operable to perform the method comprises a security gateway.

23. The method of claim 21, wherein the second protocol is an internet protocol security protocol suite in tunnel mode.

24. The method of claim 21, wherein the first device is a network device.

25. A method, comprising:

based on the bearer identification, a third packet conforming to a backhaul adaptation protocol is generated such that the third packet can be mapped to a backhaul channel.

26. The method of claim 25, wherein the first device is a network device and the fourth device that can be used to perform the method is a network device.

27. An apparatus, comprising:

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

means for generating a first packet conforming to internet protocol version 6IPv6, the first packet comprising a first header generated by mapping the bearer identification to a first source address in the first header, further comprising:

When a second protocol is configured as an internet protocol security protocol family in a transport mode, means for encapsulating the first packet based on the second protocol without changing a field associated with the first source address in the first header; or alternatively

When the second protocol is configured as an internet protocol security protocol family in tunnel mode, means for copying the bearer identification in the first source address in the first header into a second source address to generate a second header.

28. An apparatus, comprising:

means for receiving a first packet conforming to internet protocol version 6IPv6 from a first device, the first packet comprising a first header generated by mapping a bearer identification to a first source address;

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

means for mapping the bearer identification 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 conforming to the second protocol based on the encapsulated packet and the second header.

29. An apparatus, comprising:

Means for receiving a first packet conforming to internet protocol version 6, IPv6, from a first device, the first packet comprising a first header;

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

generating a third packet conforming to a backhaul adaptation protocol from the bearer identification such that the third packet can be mapped to a backhaul channel.

30. A non-transitory computer readable medium comprising program instructions for causing an apparatus to perform at least the method of any one of claims 14-20.

31. A non-transitory computer readable medium comprising program instructions for causing an apparatus to perform at least the method of any one of claims 21-24.

32. A non-transitory computer readable medium comprising program instructions for causing an apparatus to perform at least the method of any one of claims 25-26.