WO2020221954A1

WO2020221954A1 - Method and apparatus for transmission of bearer information

Info

Publication number: WO2020221954A1
Application number: PCT/FI2019/050346
Authority: WO
Inventors: Anantha KANDALA; Esa METSÄlÄ; Esa Malkamäki
Original assignee: Nokia Technologies Oy
Priority date: 2019-05-02
Filing date: 2019-05-02
Publication date: 2020-11-05

Abstract

In accordance with an example embodiment of the present invention, there is provided a method in a network element. The method includes obtaining a bearer identifier; establishing a secure IP connection; and furnishing an optional IP header of the secure IP connection with information about the bearer identifier.

Description

METHOD AND APPARATUS FOR TRANSMISSION OF BEARER INFORMATION

TECHNICAL FIELD

[0001] Various example embodiments relate to transmission of bearer information.

BACKGROUND

[0002] This section illustrates useful background information without admission of any technique described herein representative of the state of the art.

[0003] 5G RAN, Radio Access Network, requires IPsec, IP security suite of protocols, for protection of logical interfaces like FI interface (between CU, Centralized Unit, and DU, Distributed Unit) and NG interface (to core network). IPsec however may hide information that is needed in intermediate IAB, Integrated Access and Backhaul, nodes. A solution to tackle this is needed.

SUMMARY

[0004] Various aspects of examples of the invention are set out in the claims.

[0005] According to a first example aspect, there is provided a method in a network element. The method comprises obtaining a bearer identifier;

establishing a secure IP connection; and

furnishing an optional IP header of the secure IP connection with information about the bearer identifier.

[0006] In an example embodiment, the information about the bearer identifier comprises the bearer identifier. In another example embodiment, the information about the bearer identifier comprises a value usable for finding out the bearer identifier. The value may be one-to-one mapped to the associated bearer identifier.

[0007] In an example embodiment, obtaining the bearer identifier comprises receiving the bearer identifier. In another example embodiment, obtaining the bearer identifier comprises generating the bearer identifier.

[0008] In an example embodiment, the secure IP connection is an IPsec connection.

[0009] The optional IP header may be an optional IPv4 header or an optional IPv6 header. In an example embodiment, the optional IP header is an optional clear text IP header that is set to be inspected en route. In an example embodiment, the optional IP header is an IPv6 hop-by-hop options header. [0010] In an example embodiment, the bearer identifier is a GTP-U tunnel endpoint identifier.

[0011] In an example embodiment, the optional IP header comprises an option type field and the option type field is set to indicate transport of the information about the bearer identifier.

[0012] In an example embodiment, the method further comprises accompanying an existing IP header with the optional IP header. This may be referred to as transport mode operation. In another example embodiment, the method further comprises adding a new IP header and accompanying the new IP header with the optional IP header. This may be referred to as tunnel mode operation.

[0013] In an example embodiment, the network element is a network element that operates as an endpoint of the secure IP connection.

[0014] In an example embodiment, the network element is one of: an IAB donor CU, an IAB donor DU, an IAB node, a security gateway.

[0015] According to a second example aspect, there is provided an apparatus comprising a processor, a memory, and a computer program code residing in the memory, wherein the computer code when executed by the processor, is configured to cause the apparatus to

obtain a bearer identifier;

establish a secure IP connection; and

furnish an optional IP header of the secure IP connection with information about the bearer identifier.

[0016] In an example embodiment, the apparatus is a network element that operates as an endpoint of the secure IP connection.

[0017] In an example embodiment, apparatus is one of: an IAB donor CU, an IAB donor DU, an IAB node, a security gateway.

[0018] The computer code when executed by the processor, may be further configured to cause the apparatus to perform the method of any embodiment related to the first example aspect.

[0019] According to a third example aspect, there is provided a method in a second network element. The method comprises:

receiving an IP packet;

reading information about a bearer identifier from an optional IP header of the IP packet; and

performing predefined actions based on the information about the bearer identifier.

[0020] The IP packet may an IP packet of a secure IP connection. In an example embodiment the second network element is an intermediate node of a secure IP connection.

[0021] In an example embodiment, the predefined actions comprise one or more of the following: bearer mapping, scheduling, and quality of service operations.

[0022] According to a fourth example aspect there is provided a second network element comprising a processor, a memory, and a computer program code residing in the memory, wherein the computer code when executed by the processor, is configured to cause the intermediate network element to

receive an IP packet;

read information about a bearer identifier from an optional IP header of the IP packet; and

perform predefined actions based on the information about the bearer identifier.

[0023] In an example embodiment, the second network element is one of: an IAB donor CU, an IAB donor DU, an IAB node, a security gateway.

[0024] According to a fifth example aspect, there is provided a computer program comprising computer executable program code configured to execute the method of the first or third example aspect and/or any related embodiment.

[0025] The computer program may be stored in a computer readable memory medium.

[0026] Any foregoing memory medium may comprise a digital data storage such as a data disc or diskette, optical storage, magnetic storage, holographic storage, opto-magnetic storage, phase-change memory, resistive random access memory, magnetic random access memory, solid-electrolyte memory, ferroelectric random access memory, organic memory or polymer memory. The memory medium may be formed into a device without other substantial functions than storing memory or it may be formed as part of a device with other functions, including but not limited to a memory of a computer, a chip set, and a sub assembly of an electronic device.

[0027] Different non-binding example aspects and embodiments have been illustrated in the foregoing. The embodiments in the foregoing are used merely to explain selected aspects or steps that may be utilized in implementations of the present invention. Some embodiments may be presented only with reference to certain example aspects. It should be appreciated that corresponding embodiments may apply to other example aspects as well.

BRIEF DESCRIPTION OF THE DRAWINGS

[0028] For a more complete understanding of example embodiments, reference is now made to the following descriptions taken in connection with the accompanying drawings in which:

[0029] Fig. 1A shows an IAB protocol stack in a usage scenario of an example embodiment;

[0030] Figs. IB and 1C show simplified network diagrams of usage scenarios of example embodiments;

[0031] Fig. 2 shows a simplified block diagram of an apparatus of an example embodiment;

[0032] Figs. 3A and 3B show flow charts of processes of example embodiments;

[0033] Fig. 4 shows an IPv6 header of an example embodiment;

[0034] Figs. 5 and 6 show hop-by-hop options header of example embodiments;

[0035] Fig. 7 shows an example of IPv6 IPsec transport mode packets; and

[0036] Fig. 8 shows an example of IPv6 IPsec tunnel mode packets.

DETAILED DESCRIPTON OF THE DRAWINGS

[0037] Various example embodiments and their potential advantages are understood by referring to Figs. 1 A through 8 of the drawings. In this document, like reference signs denote like parts or steps.

[0038] With reference to the background section, in 5G networks there is a requirement to use IPsec, but IPsec may hide necessary information from intermediate IAB, Integrated Access and Backhaul, nodes. For example, for QoS and scheduling purposes, a bearer identifier (e.g., TEID, GTP-U Tunnel Endpoint Identifier) should be available in intermediate IAB nodes. Example embodiments provide a solution where an optional IP, Internet Protocol, header (for instance, an optional IPv6 header) is used for transport of information about the bearer identifier, such as the TEID. Instead of using fixed IP header fields, such an IPv6 flow label field, using optional headers provides a possibility to accommodate more information. For example, the flow label of fixed IPv6 header is 20 bits long, whereas TEID is 32 bits long. Thereby, it may be difficult to accommodate bearer identifier into the flow label field, for example. Whereas optional IP header may accommodate 32 bits. By using optional IP headers, the bearer identifier can be transported in clear text format and the information is thus available for intermediate IAB nodes when needed. In an example embodiment, the optional IP header is an extension header. The optional IP header may be an optional IPv4 header or an optional IPv6 header. In an example embodiment, the optional IP header is an optional clear text IP header that is set to be inspected en route. In an example embodiment, the optional IP header is an IPv6 hop-by-hop options header.

[0039] In more general terms, the example embodiments disclosed herein may be implemented in logical or physical network elements that operate as endpoints of secure IP connections. The example embodiments provide a mechanism for transport of information that may be needed by intermediate nodes. An intermediate node herein refers to a logical or physical node that handles or forwards data packets of a secure IP connection, but is not entitled to see content of the data packets of the secure IP connection.

[0040] In the following, example embodiments are discussed in connection with IAB of 5G networks, IPsec and IPv6. It is to be noted that these are examples of implementation details only and other implementation alternatives may be equally applied.

[0041] Fig. 1A shows an IAB protocol stack in a usage scenario of an example embodiment. Fig. 1A shows a UE 101, user equipment, an IAB-node 2 102, an IAB-node 1 103, an IAB-donor DU, distributed unit, 104, and an IAB-donor CU, centralized unit, 105, and associated protocol layers.

[0042] There is a SDAP, Service Data Adaptation Protocol, layer connection and a PDCP, Packet Data Convergence Protocol connection between the UE 101 and the IAB-donor CU 105. The connections go through the IAB-node 2 102, the IAB-node 1 103, and the IAB- donor DU 104. The IAB-node 2 102, the IAB-node 1 103, and the IAB-donor DU 104 handle the connections in lower protocol layers below the SDAP and PDCP layers.

[0043] In case IPsec is used to protect the IP layer between the IAB-node 2 102 and the IAB-donor 104 CU, the intermediate nodes (e.g. the IAB-donor DU 104 and/or the IAB- node 1 103) cannot see anything except the unprotected fields of the IP layer packet. However, for example for QoS and scheduling purposes as well as for bearer mapping, some information about the bearer identifier (e.g. TEID) should be available for the IAB-donor DU 104 and/or the IAB-node 1 103. According to example embodiments, the endpoints of the IPsec connection, such as the IAB-node 2 103 and the IAB-donor CU 105, are configured to set information about the bearer identifier into an optional IP header to provide that information about the bearer identifier is accessible to the intermediate nodes such as the IAB-donor DU 104 and/or the IAB-node 1 103. In this way, a mechanism to transport information to intermediate nodes is achieved.

[0044] Figs. IB and 1C show simplified network diagrams of usage scenarios of example embodiments. Fig. IB shows a scenario with an IAB-node 2 102, an IAB-node 1 103, an IAB-donor DU 104, an IAB-donor CU 105, and a SEG, security gateway, 110. Further, there is shown a secure IP connection 120 between the IAB-node 2 102 and the SEG 110. The secure IP connection 120 goes through the IAB-node 1 103 and the IAB-donor DU 104. In other words, the IAB-node 2 102 and the SEG 110 operate as endpoints of the secure IP connection 120 and the IAB-node 1 103 and the IAB-donor DU 104 are intermediate nodes in this example scenario.

[0045] Fig. 1C shows a scenario with an IAB-node 2 102, an IAB-node 1 103, an IAB-donor DU 104, and an IAB-donor CU 105. Further, there is shown a secure IP connection 120 between the IAB-node 2 102 and IAB-donor CU 105. The IAB-donor CU 105 may comprise a security gateway that operates as an endpoint of the secure IP connection 120 or the IAB-donor CU 105 may be the endpoint. The IAB-node 2 102 operates as the other endpoint of the secure IP connection 120. The secure IP connection 120 goes through the IAB- node 1 103 and the IAB-donor DU 104. That is, the IAB-node 1 103 and the IAB-donor DU 104 are intermediate nodes in this example scenario.

[0046] Fig. 2 shows a simplified block diagram of an apparatus 20 of an example embodiment. The apparatus 20 is for example a dedicated network element or a general- purpose computer or server or some other electronic data processing apparatus. The apparatus 20 can be used for implementing embodiments of the invention. That is, with suitable configuration the apparatus 20 is suited for implementing the functionality of a logical or physical network element that operates as an endpoint of a secure IP connection. Such network element may be for example the IAB-node 2 102, an IAB-donor DU 104, and/or the IAB-donor CU 105, and/or the SEG 110 of Figs. 1A-1C.

[0047] The general structure of the apparatus 20 comprises a processor 21, and a memory 22 coupled to the processor 21. The apparatus 20 further comprises program code 23 stored in the memory 52 and operable to be executed in the processor 21. The program code 23 may comprise one or more software modules and can be in the form of a computer program product. The processor 21 is configured to control the operation of the apparatus 20 based on the computer program code 23 when executing the program code 23. Further, the apparatus 20 comprises an input/output function 25 coupled to the processor 21. [0048] The processor 21 may comprise any suitable processing circuitry, e.g., a central processing unit (CPU), a microprocessor, a digital signal processor (DSP), an application specific integrated circuit (ASIC); a field programmable gate array; a microcontroller; a portion of one or more virtualized or cloud computing processing cores, or the like. Fig. 2 shows one processor 21 , but the apparatus 20 may comprise a plurality of processors.

[0049] The memory 22 may comprise for example a non-volatile or a volatile memory. The apparatus 50 may comprise a plurality of memories. The input/output function 25 may comprise, e.g., a local area network (LAN) port such as an Ethernet port; a data bus; a wireless local area network (WLAN) unit; cellular data communication unit (e.g. 3G, 4G, and/or 5G radio module); or satellite data communication unit. Further the apparatus 20 may comprise a control interface (not shown). The control interface may be implemented through the input/output function 25, too.

[0050] Fig. 3A shows a flow chart of a process of an example embodiment. The process may be implemented in a logical or physical network element that operates as an endpoint of a secure IP connection. Such network element may be for example the IAB-node 2 102, and/or an IAB-donor DU 104, the IAB-donor CU 105, and/or the SEG 110 of Figs. 1 A- 1C. The process proceeds as follows:

[0051] 301 : A bearer identifier is obtained. The bearer identifier may be associated with a bearer of a UE served by a network node. The network node may be the remote end (receiving end) of the secure IP connection. The bearer identifier may be, for instance, a GTP- U TEID, GTP-U tunnel endpoint identifier. The bearer identifier may be received. For example, the remote end TEID may be received by signaling (Fl-AP in case of IAB DU-CU). The bearer identifier may be received also together with the data packet. For example, a security gateway may receive the GTP-U TEID inside the IP packet it receives from the CU. In this case, some packet inspection is needed. Alternatively, the bearer identifier may be generated in the network element implementing the process of Fig. 3. For example, IAB-donor CU may generate the TEID. In yet another example, the TEID is obtained from SDN, Software Defined Networking, controller.

[0052] 303: A secure IP connection is established. The secure IP connection is for example an IPsec connection.

[0053] 305: An optional IP header of the secure IP connection is furnished with information about the bearer identifier. In example embodiment the optional IP header is set so that it is not encrypted. The optional header is for example an optional IPv4 header or an optional IPv6 header. In an example embodiment, the optional IP header is an optional clear text IP header that is set to be inspected en route. In an example embodiment, the optional IP header is an IPv6 hop-by-hop options header.

[0054] The information about the bearer identifier may be the bearer identifier (e.g. the TEID) or alternatively, the information may comprise a value usable for obtaining the bearer identifier. The information may be for example a value that is one-to-one mapped to the bearer identifier.

[0055] It is to be noted that the phase 305 may be performed before performing the phase 303. That is, the order of the phases may vary.

[0056] The process of Fig. 3A provides that, any intermediated node (e.g. an IAB node or an IAB-donor DU) along the path of the secure IP connection is able to access the information about the bearer identifier for example for bearer mapping, QoS and scheduling purposes. That is, information about the bearer identifier is being transmitted also to the intermediate nodes or at least to one of the intermediate nodes.

[0057] Fig. 3B shows a flow chart of a process of an example embodiment. The process may be implemented a logical or physical network element that operates as an intermediate node of a secure IP connection. Such network element may be for example the IAB-node 1 103, and/or an IAB-donor DU 104 of Figs. 1A-1C. Additionally or alternatively, the process may be implemented in a logical or physical network element that operates as an endpoint of a secure IP connection. Such network element may be for example the IAB-node 2 102, and/or an IAB-donor DU 104, the IAB-donor CU 105, and/or the SEG 110 of Figs. 1 A- 1C. The process proceeds as follows:

[0058] 311 : An IP packet is received. The packet may be an IP packet of a secure IP connection, such as an IPsec connection.

[0059] 313: Information about a bearer identifier is read from an optional IP header of the IP packet. The information about the bearer identifier may be the bearer identifier (e.g. the TEID) or alternatively, the information may comprise a value usable for obtaining the bearer identifier. The information may be for example a value that is one-to-one mapped to the bearer identifier.

[0060] 315: Predefined actions are performed based on the information about the bearer identifier. The predefined actions comprise one or more of the following: bearer mapping, scheduling, and quality of service operations. In an example embodiment, the intermediate node is IAB donor DU and the action that is performed is mapping UE bearer to BH RLC, backhaul radio link controller, channels. In an example embodiment, the action that is performed is scheduling UE bearers based on quality of service configured to that bearer.

[0061] Fig. 4 shows an IPv6 header of an example embodiment. Fig. 4 shows a fixed IPv6 header 401 and a hop-by-hop extension header 402. The fixed IPv6 header 401 comprises the following fields: Version, Traffic Class, Flow label, Payload Fength, Next Header, Hop Fimit, Source Address, and Destination Address. The hop-by-hop extension header 402 comprises the following fields: Next Header, Hdr ext Fength, Option Type, Option Fength, and Option Data. In an example embodiment, the Option Data field 405 is furnished with bearer identifier such as GTP-U TEID. In an example embodiment, the Option Type field 406 is set to indicate transport of the bearer identifier. For example, a predefined value of the Option Type field 406 may be used for this purpose.

[0062] In an example embodiment, the hop-by-hop extension header 402 is placed before AH, Authentication Header, and/or ESP, Encapsulating Security Payloads, header, so that the hop-by-hop extension header 402 is not encrypted when the IP connection is secured using IPsec.

[0063] Figs. 5 and 6 show IPv6 hop-by-hop options headers of example embodiments.

[0064] Fig. 5 shows a hop-by-hop extension header 402 comprising the following fields: Next Header, Hdr ext length, Option Type, Option Fength, Message-Type, Sub-Type, and Option Data. In an example embodiment, the Option Data field 405 is furnished with bearer identifier such as GTP-U TEID.

[0065] In an example embodiment, fields of the hop-by-hop extension header 402 have the following content.

[0066] Option Type (8 bits) 406: Transit data (new). To be assigned by IANA. In an example embodiment the value 3 (00000011) in this field indicates Transit data.

[0067] Highest-order 2 bits of the Option Type specify the action that must be taken if the processing IPv6 node does not recognize the Option Type. The third highest-order bit of the Option Type specifies whether or not the Option data of that option can change en route to the packet's final destination. The following table illustrates meaning of different bits in the Option Type field. In the example embodiment using the value 3, first two bits are zero, thus the action to take if not understood is‘skip’ and the third bit is zero as well implying that data does not change en route. Hiqhest-order 2 bits third hiqhest-order bit act chq rest

fact): (chq.): 00 0 00000 Pad1

Act = Action to take if 0 - Option Data does not 00 0 00001 PadN

not understood (2) change en route 11 0 00010 Jumbo Payload

00 - skip 1 - Option Data may change 00 0 00100 Tunnel Encap 01 - discard en route Limit

10 - ICMP reply 00 0 00101 Router Alert

1 1 - ICMP reply (UC) 1 1 0 01001 Home Address

[0068] Option Length (8 bits): Length of the Option Data field of this option, in octets.

[0069] Message Type (8 bits):

[0071] Option Data (32 bits) 405: TEID value.

[0072] Fig. 6 shows a hop-by-hop extension header 402 comprising the following fields: Next Header, Hdr ext length, Option Type, Option Length, and Option Data. In an example embodiment, the Option Data field 405 is furnished with bearer identifier such as GTP-U TEID.

[0073] In an example embodiment, fields of the hop-by-hop extension header 402 have the following content.

[0074] Option Type (8 bits) 406: GTP-U TEID (new). To be assigned by IANA. In an example embodiment the value 3 (00000011) in this field indicates TEID.

[0075] Highest-order 2 bits of the Option Type specify the action that must be taken if the processing IPv6 node does not recognize the Option Type. The third highest-order bit of the Option Type specifies whether or not the Option data of that option can change en route to the packet's final destination. The following table illustrates meaning of different bits in the Option Type field. In the example embodiment using the value 3, first two bits are zero, thus the action to take if not understood is‘skip’ and the third bit is zero as well implying that data does not change en route.

Hiqhest-order 2 bits third hiqhest-order bit act chq rest

(act): (chq.): 00 0 00000 Pad1

Act = Action to take if 0 - Option Data does not 00 0 00001 PadN

not understood (2) change en route 11 0 00010 Jumbo Payload

10 - ICMP reply 00 0 00101 Router Alert

1 1 - ICMP reply (UC) 1 1 0 01001 Home Address

[0076] Option Length (8 bits): Length of the Option Data field of this option, in octets.

[0077] Option Data (32 bits) 405: TEID value.

[0078] Fig. 7 shows an example of IPv6 IPsec transport mode packets with ESP. In transport mode an existing IP header is accompanied with the optional IP header according to example embodiment. IPv6 IPsec transport mode may be used for example between the IAB- node 2 102 and the IAB-donor CU 105 of Figs. 1A-1C. Fig. 7 shows IPv6 packet before 701 and after 702 adding information about the bearer identifier and applying ESP. The packet 702 after applying ESP shows the original IP header accompanied with the optional IP header 402 carrying the information about the bearer identifier before the ESP header. The original IP header and extension headers before the ESP header are clear text and accessible by intermediate nodes. In an example embodiment, the IPv6 header of the packet 702 after applying ESP comprises the original IP header as well as a hop-by-hop options header including GPT-U TEID e.g. in the last 32 bits.

[0079] Fig. 8 shows an example of IPv6 IPsec tunnel mode packets with ESP. In tunnel mode the original IP header is secured, and a new IP header accompanied with the optional IP header according to example embodiment is added. IPv6 IPsec tunnel mode may be used for example between the IAB-node 2 102 and the SEG 110, or between the IAB-node 2 102 and the IAB-donor CU 105 of Figs. 1A-1C. Fig. 8 shows IPv6 packet before 801 and after 802 adding information about the bearer identifier and applying ESP. After applying ESP, the original IP header and any associated extension headers are secured and not accessible by intermediate nodes. A new (fixed) IP header is added and the new IP header is accompanied with the optional IP header 402 according to example embodiment as shown in packet 802. The new IP header and optional header 402 are clear text and accessible by intermediate nodes. In an example embodiment, after applying ESP there is new IPv6 header accompanied with a hop-by-hop options header that includes GPT-U TEID. In tunnel mode, the outer IP address in the new IP header may in general be different from the inner IP address in the original IP header, especially in case of an external SEG.

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

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

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

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

[0005] (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

[0006] (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.

[0007] 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.

[0008] Without in any way limiting the scope, interpretation, or application of the claims appearing below, a technical effect of one or more of the example embodiments disclosed herein is that improved IAB operation may be provided. Another technical effect of one or more of the example embodiments disclosed herein is that IAB can use IPv6 IPsec while the intermediate nodes can access the bearer information. As the bearer identifier (e.g. TEID) is visible in the hop-by-hop options header of IPv6, intermediate IAB nodes may easily read the bearer identifier.

[0009] Various embodiments may be implemented in software, hardware, application logic or a combination of software, hardware and application logic. In an example embodiment, the application logic, software or an instruction set is maintained on any one of various conventional computer-readable media. In the context of this document, a“computer-readable medium” may be any non-transitory media or means that can contain, store, communicate, propagate or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer, with one example of a computer described and depicted in Fig. 2. A computer-readable medium may comprise a computer-readable storage medium that may be any media or means that can contain or store the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer.

[0010] If desired, the different functions discussed herein may be performed in a different order and/or concurrently with each other. Furthermore, if desired, one or more of the before-described functions may be optional or may be combined.

[0011] Although various aspects are set out in the independent claims, other aspects comprise other combinations of features from the described embodiments and/or the dependent claims with the features of the independent claims, and not solely the combinations explicitly set out in the claims.

[0012] It is also noted herein that while the foregoing describes example embodiments, these descriptions should not be viewed in a limiting sense. Rather, there are several variations and modifications which may be made without departing from the scope of the present invention as defined in the appended claims.

Claims

1. A method in a network element, the method comprising:

obtaining a bearer identifier;

establishing a secure IP connection; and

2. The method of claim 1, wherein the information about the bearer identifier comprises the bearer identifier.

3. The method of claim 1, wherein the information about the bearer identifier comprises a value usable for finding out the bearer identifier.

4. The method of any preceding claim, wherein obtaining the bearer identifier comprises receiving the bearer identifier.

5. The method of any one of claims 1-3, wherein obtaining the bearer identifier comprises generating the bearer identifier.

6. The method of any preceding claim, wherein the secure IP connection is an IPsec connection.

7. The method of any preceding claim, wherein the optional IP header is an optional clear text IP header that is set to be inspected en route.

8. The method of any preceding claim, wherein the optional IP header is an IPv6 hop-by- hop options header.

9. The method of any preceding claim, wherein the bearer identifier is a GTP-U tunnel endpoint identifier.

10. The method of any preceding claim, wherein the optional IP header comprises an option type field and the option type field is set to indicate transport of the information about the bearer identifier.

11. The method of any preceding claim, wherein the method further comprises accompanying an existing IP header with the optional IP header.

12. The method of any one of claims 1-10, wherein the method further comprises adding a new IP header and accompanying the new IP header with the optional IP header.

13. The method of any preceding claim, wherein the network element is a network element that operates as an endpoint of the secure IP connection.

14. The method of any preceding claim, wherein the network element is one of: an IAB donor CU, an IAB donor DU, an IAB node, a security gateway.

15. An apparatus comprising a processor, a memory, and a computer program code residing in the memory, wherein the computer code when executed by the processor, is configured to cause the apparatus to

obtain a bearer identifier;

establish a secure IP connection; and

16. The apparatus of claim 15, wherein the apparatus is a network element that operates as an endpoint of the secure IP connection.

17. The apparatus of claim 15, wherein apparatus is one of: an IAB donor CU, an IAB donor DU, an IAB node, a security gateway.

18. The apparatus of any one of claims 15-17, wherein the computer code when executed by the processor, is further configured to cause the apparatus to perform the method of any one of claims 2-12.

19. A computer program comprising computer executable program code configured to execute the method of any one of claims 1-14.

20. The computer program of claim 19 stored in a computer readable memory medium.

21. A method in a second network element, the method comprising:

receiving an IP packet;

22. The method of claim 21, wherein the predefined actions comprise one or more of the following: bearer mapping, scheduling, and quality of service operations.

23. A second network element comprising a processor, a memory, and a computer program code residing in the memory, wherein the computer code when executed by the processor, is configured to cause the intermediate network element to

receive an IP packet;

24. The second network element of claim 23, wherein the second network element is one of: an IAB donor CU, an IAB donor DU, an IAB node, a security gateway.