Field of the invention

The present invention relates to an apparatus, a method, and a computer program product related to mapping of parameters of control plane and user plane, in particular in 3GPP networks.

Abbreviations

3GPP 3 ^rd Generation Partnership Project

4G / 5G 4 ^th / 5 ^th Generation

5GC 5G Core Network

AMF Access and Mobility Management Function

BEB Backbone Edge Bridge

BS Base Station

CP Control Plane

CPF Control Plane Function

DA Destination MAC address

DL Downlink

DN Data Network

eNB evolved NodeB

ETH Ethernet

E-UTRAN Evolved UTRAN

gNB next generation NodeB

GPRS General Packet Radio Service

GRE Generic Routing Encapsulation

GTP GPRS Tunneling Protocol

GTP-C GPRS Tunneling Protocol - Control Plane

GTP-U GPRS Tunneling Protocol - User Plane

ID Identifier

IEEE Institute of Electrical and Electronics Engineers

IETF Internet Engineering Task Force

IP Internet Protocol

l-SID Backbone Service Instance Identifier

I -TAG Backbone Service Instance Tag L1 / L2 Layer 1 (physical layer) / Layer 2 (data link layer)

LAN Local Area Network

LTE Long Term Evolution

MAC Medium Access Control

MME Mobility Management Entity

MN Mobile Network

MSC Message Sequence Chart

NG Next Generation

NGAP Next Generation Application Protocol

NGMN Next Generation Mobile Networks

PBB Provider Backbone Bridge

PDCP Packet Data Convergence Protocol

PDN GW (P-GW) Packet Data Network Gateway

PDU Packet Data Unit

PMIP Proxy Mobile IP

(R)AN (Radio) Access Network

RFC Request for Comments

RLC Radio Link Control

S1 -AP S1 -Application Protocol

SA Source MAC address

SCTP Stream Control Transmission Protocol

SDAP Service Data Adaptation Protocol

S-GW Serving Gateway

SID Service Instance ID

TEID Tunnel Endpoint Identifier

TR Technical Report

TS Technical Specification

UDP User Datagram Protocol

UE User Equipment

UL Uplink

UMTS Universal Mobile Telecommunications System

UP User Plane

UPF User Plane Function

UTRAN UMTS Terrestrial Radio Access Network

VI D VLAN ID

VLAN Virtual LAN Background of the invention

Current wireless/cellular communication systems like 4G do not meet the strong requirements on latency and reliability for industrial applications.

A principle use case for industrial application is shown in Fig. 1 : The 5G network is part of the industrial factory. The machines, robots, sensors, actuators, industrial process controllers etc. are communicating with each other over the network. In many cases, they use Ethernet or Industrial Ethernet which provides determinism and real-time control.

In order to meet the strong requirements in a 5G network, a new user plane protocol stack may be used inside the 5G network. A focus is on the RAN-Core interface (shown as N3 interface in the figures, also known as S1 -interface in 4G) as well as interfaces inside the 5G Packet Core (shown as N9 interface in the figures). A proposed 5G user plane protocol stack is shown in Fig. 14. There, Ethernet shall be used on the N3 and N9 interface instead of GTP/UDP/IP.

Providing high reliable and low latency wireless/cellular connectivity (e.g. with 5G) inside an industrial network is discussed e.g. in:

- NGMN, "Perspectives on Vertical Industries and Implications for 5G, v2.0", September 2016.

- 3GPP TS 22.261“Service requirements for the 5G system”, especially Annex D on critical communication use cases, including discrete automation.

For the air-interface, several activities related to URLLC (Ultra-reliable low latency communication) are going on, however, also the other interfaces (like the RAN-Core interface and the Core internal user plane interfaces) may be adapted to meet the high reliability and low latency requirements. In this context, it is discussed to have a new user plane protocol stack between the 3GPP RAN and Core. The new protocol stack shall better support real time requirements as needed e.g. for Industrial Applications. Current IP-based protocol stack (GTP/UDP/IP) does not support realtime features as e.g. implemented in industrial Ethernet. The following section summarizes current status on protocol stacks in 3GPP and IEEE as a background for understanding the invention. Since some embodiments of the invention are related to the 3GPP Tunnel Endpoint Identifier (TEID), this section explains where the TEID is currently used.

Standard 3GPP Protocol stacks and procedures

• Protocol stacks in 4G

The current 3GPP user plane protocol stack for 4G as defined in 3GPP TS 23.401“GPRS Enhancements for E-UTRAN access” is shown in Fig. 2. GTP-U/UDP/IP is used as user plane protocol stack on the S1 -U as well as on the S5/S8 interface.

3GPP also allows as alternative to GTP-U/UDP/IP to use GRE/IP at least on the S5/S8 interface as specified in 3GPP TS 23.402 “Architecture enhancements for non-3GPP accesses” and as shown in Fig. 3.

For the control plane, also different protocols are used.

On the interface between eNodeB and MME, the S1 Application Protocol (S1 -AP) is used as shown in Fig. 4. S1 -AP is defined in 3GPP TS 36.413“E-UTRAN; S1 Application Protocol (S1 AP)(Release13)”. One important parameter used in S1 -AP is the GTP Tunnel Endpoint Identifier (GTP-TEID) identifying the tunnel between eNB and the serving gateway. A differentiation is made between TEIDs used in the downlink and in the uplink (DL GTP-TEID, UL GTP-TEID).

On the interface between MME and S-GW, GTP-C is used as control plane protocol as shown in Fig. 5. GTP-C is defined in [3GPP TS 29.274] “Evolved GPRS Tunnelling Protocol for Control plane (GTPv2-C); Stage 3”. This protocol also uses GTP-TEIDs.

This document also specifies:

- Tunnel Endpoint: A tunnel endpoint is identified with a TEID, an IP address and a UDP port number (see subclause 4.1 "GTP Tunnel"). - Tunnel Endpoint Identifier (TEID): unambiguously identifies a tunnel endpoint in scope of a path (see subclause 4.1 "GTP Tunnel").

• User plane protocol stack in 5G

The current 3GPP user plane protocol stack for 5G as defined in 3GPP TS 23.501“System Architecture for the 5G System; Stage 2 (Release 15)” is shown in Fig. 6.

Ethernet is already allowed as one of the End-to-end protocols on the PDU-layer besides e.g. IP.

The“5G UP Encapsulation” is based on GTP-U/UDP/IP as defined in 3GPP TS 38.300 “NG Radio Access Network; Overall Description; Stage 2” and as shown in Fig. 7. Please note that the N3 interface from TS 23.501 is called NG-U interface in TS 38.300 and terminology may still change.

Fig. 8 combines the information described above and shows the end-to-end protocol stack marked by an arrow“End-to-end protocol layer”. The end-to-end protocol can be IPv4, IPv6, Ethernet or transparent data.

The protocol header of a user plane message using Ethernet as end-to-end-protocol on top of GTP-U/UDP/IP is shown in Fig. 9:

The GTP-U header is marked as“GTP-U”. An important field is the GTP Tunnel-Endpoint Identifier (TEID). A TEID unambiguously identifies a tunnel endpoint in the receiving GTP-U protocol entity for a given UDP/IP endpoint. The receiving end side of a GTP tunnel locally assigns the TEID value the transmitting side has to use. The TEID values are exchanged between tunnel endpoints using one or more control plane messages (e.g. S1 -AP or GTP- C).

The GTP-header does not contain a protocol type field because this information is exchanged via a control plane protocol (e.g. GTP-C or S1 -AP) during the setup of the tunnel. • 3GPP Procedures with GTP

The Message Sequence Chart (MSC) of the Attach or Service Request Procedure is shown in Fig. 10. This MSC shows in which nodes the TEIDs are created, in which messages they are transported and when the tunnels are then available. Namely, for the N9 interface between different UPFs (UPF1 , UPF2), each of the UPFs creates a respective N9-TEID (N9-TEID(UL) and N9-TEID(DL) and informs the other UPFin Create Session Request and Create Session response message, respectively (steps 4 and 5 of Fig. 10). For the N3 interface, respective TEIDs are created by the base station and UPF1 (e.g. S-GW) and communicated to the other entity via CPF (e.g. MME) (steps 6 and 7 for N3-TEID (UL) and steps 1 1 and 12 for N3-TEID(DL)).

In these procedures, the TEID exchanged via the control plane protocols (GTP-C, S1 -AP) is directly (1 :1 ) mapped to the TEID used in the user plane protocol (GTP-U) (see Fig. 1 1 ).

• 3GPP Alternative procedures with GRE and PMIP

For non-3GPP access, 3GPP allows the use of GRE as a user plane protocol on the S5/S8 interface between the S-GW and the P-GW as shown in Fig. 3. In that case, Proxy Mobile IP (PMIP) is used as control plane protocol.

In that case, the GRE Key is used as tunnel identifier. The GRE key is used in the KEY- field of the GRE user plane messages. In the control plane, the PMIP messages Proxy Binding Update and Proxy Binding Acknowledgement then also include a GRE Key identifier as option (IETF RFC 5845).

This mapping of the GRE key is shown on the right side of Fig. 12, in parallel to the TEID mapping which is still used on the S1 -interface. I.e., the PMIP GRE key of the IETF control plane is 1 :1 mapped to the GRE key field of the user plane.

• Alternative procedures mapping 3GPP TEID to IETF GRE Key

H. R. G. Rydnell,“GTP and GRE user-plane selection,” European Patent EP 2371 164 B1 , Nov 1 1 , 2012 [Rydnell] describes an invention where GTP-C is used on the control plane while on the user plane, both GTP-U and GRE are allowed. The user plane protocol type (GTP-U, GRE) is signalled in the control plane messages. In case GRE is used on the user plane, the TEID as used in GTP-C is mapped 1 :1 to the GRE Key field. This mapping is shown in Fig. 13.

This mapping is simple because the GTP-TEID has 32 bits, and the optional KEY-field of the GRE header has also 32 bits.

• IEEE 802.1 ah Provider Backbone Bridging (PBB) Overview

Provider Backbone Bridges (PBB; known as "mac-in-mac") is a set of architecture and protocols for routing over a provider's network allowing interconnection of multiple Provider Bridge Networks without losing each customer's individually defined VLANs. The final standard was approved by the IEEE in June 2008 as IEEE 802.1 ah-2008 and has been integrated into IEEE 802.1 Q-201 1. See also: https://en.wikipedia.org/wiki/IEEE_802.1 ah- 2008 and https://infoproducts.alcatel-lucent.com/html/0_add-h-f/93-00 76-10-

01/7750 SR OS Services Guide/services PBB.html

• Modified 3GPP Protocol stack with IEEE 802.1 ah for the RAN/Core interface (and similar interfaces)

Alternatives for this GTP-U/UDP/IP protocol stack have been discussed in 3GPP (See 3GPP TR 23.799 “Study on Architecture for Next Generation System (Release 14)”, sections 4.9, 4.10, 4.1 1 and 4.12) , in research pipes [GZ FatPipes] as well as in public deliverables of research projects [MII-D42]

According to the current state of discussion in 3GPP, for phase 1 of 5G, only one user plane protocol will be selected, which is GTP-U/UDP/IP, but for future releases, other options are likely to come. In order to be future proof, 3GPP has designed control protocols in such a way that a protocol type can be exchanged in order to allow different protocol stacks.

For industrial applications with high reliability and low latency requirements, an Ethernet based protocol stack is seen as advantageous compared to the GTP-U/UDP/IP protocol stack. Such a protocol stack is shown in Fig. 14. The advantageous are e.g. reduced protocol overhead, signalling reduction and avoidance of IP procedures. In this protocol stack, the Ethernet layer in the Backbone (which replaces GTP-U/UDP/IP) is marked as“Backbone ETH”. Because industrial applications are targeting Ethernet as end-to-end protocol, there is an end-to-end Ethernet layer (also known as Customer Ethernet) which is marked as“Cust. ETH”.

As can be seen in Fig. 14, there is“Ethernet-over-Ethernet” (the Customer Ethernet/IEEE MAC over the Backbone Ethernet/IEEE MAC”) on the N3 and N9 interface. Methods for such Ethernet-over-Ethernet exist in IEEE 802.1 ah (now part of 802.1 Q).

802.1 ah employs a MAC tunneling encapsulation scheme for tunneling customer Ethernet frames within provider Ethernet frames across a Provider Backbone Bridged Network (PBBN).

Provider Backbone Bridging (PBB, also known as“mac-in-mac” - where mac means IEEE MAC as used in Ethernet and not the cellular mac as used in 3GPP) is a technology standardized in IEEE 802.1 ah-2008 (now integrated in IEEE 802.1 Q-2014) for transporting data belonging to a customer network over a provider network, also called backbone. In our case, the industrial network is the customer network and the mobile network is the provider’s backbone network. A key element in PBB is the Backbone Edge Bridge (BEB). According IEEE 802.1 Q-2014 section 3.10, a Backbone Edge Bridge (BEB) is a system that encapsulates customer frames for transmission across a Provider Backbone Bridged Network (PBBN).

The protocol stack and the header fields as used in 802.1 ah for provider backbone bridging are shown in Fig. 15. The Customer Ethernet header comprises a (Customer) Source Destination Address, a (Customer) Destination MAC Address, and optional Service VLAN ID and the Customer VLAN ID.

The Backbone Ethernet header comprises the Backbone Destination MAC Address, the Source MAC Address, the Backbone VLAN-ID (B-VID) and the Backbone Service Instance ID (l-SID).

REFERENCES:

[3GPP TS 23.401] GPRS enhancements for E-UTRAN access (Release 15) [3GPP TS 23.501] System Architecture for the 5G System; Stage 2 (Release 15)

[3GPP TR 23.799] “Study on Architecture for Next Generation System (Release 14)”

[3GPP TS 29.281] “General Packet Radio System (GPRS) Tunnelling Protocol User

Plane (GTPv1 -U))”

[3GPP TS 29.274] “Evolved GPRS Tunnelling Protocol for Control plane (GTPv2-C);

Stage 3”

[3GPP TS 36.413] “E-UTRAN; S1 Application Protocol (S1 AP)(Release13)”

[802.1 ah] IEEE,“IEEE 802.1 ah-2008 Provider Backbone Bridges,” IEEE, Tech.

Rep., 2008. [Online].

Available at: http://standards.ieee.Org/getieee802/download/802.1 ah- 2008.pdf

[802.1 Q] IEEE 802.1 Q-2014 Standard for Local and metropolitan area networks

- Bridges and Bridged Networks,” IEEE, Tech. Rep., 2014.

[Rydnell] H. R. G. Rydnell, “GTP and GRE user-plane selection,” European

Patent EP 2371 164 B1 , Nov 1 1 , 2012.

[GZ FatPipes] J. Gebert and D. K. Zeller,“Fat pipes for user plane tunneling in 5G,” in

2016 IEEE Conference on Standards for Communications and Networking (CSCN) (CSCN’16), Berlin, Germany, Oct. 2016, pp. 97- 102.

ICT-671680 METIS-II, Deliverable D4.2, “Final air interface harmonization and user plane design”, April 2017. https://metis-ii.5g- ppp.eu/wp-content/uploads/METIS-ll_D4.2_V1 .0.pdf

Summary of the invention

It is an object of the present invention to improve the prior art.

According to a first aspect of the invention, there is provided an apparatus, comprising at least one processor, at least one memory including computer program code, and the at least one processor, with the at least one memory and the computer program code, being arranged to cause the apparatus to at least perform generating a user plane parameter; generating an instance identifier such that the instance identifier is unambiguously derivable from the user plane parameter according to a predefined mapping rule; performing a control plane communication to enable a user plane communication, wherein the control plane communication comprises the user plane parameter; performing the user plane communication as an ethernet communication, wherein each packet of the user plane communication is identified by the instance identifier; wherein the user plane communication carries a payload, and the control plane communication does not carry any payload.

The user plane parameter may be a control plane identifier identifying the control plane communication; and the instance identifier may be generated from the control plane identifier by the predefined mapping rule. The control plane identifier may comprise the instance identifier.

The payload may be received from an access network or to be transmitted to the access network in an access network communication, and the at least one processor, with the at least one memory and the computer program code, may be arranged to cause the apparatus to further perform generating the control plane identifier of the control plane communication such that the control plane identifier is unambiguously related to an access identifier of the access network communication.

The access network may be at least one of a radio access network and a fixed broadband access network. The control plane identifier may be a tunnel endpoint identifier. The instance identifier may comprise a service instance identifier.

According to a second aspect of the invention, there is provided a method, comprising generating a user plane parameter; generating an instance identifier such that the instance identifier is unambiguously derivable from the user plane parameter according to a predefined mapping rule; performing a control plane communication to enable a user plane communication, wherein the control plane communication comprises the user plane parameter; performing the user plane communication as an ethernet communication, wherein each packet of the user plane communication is identified by the instance identifier; wherein the user plane communication carries a payload, and the control plane communication does not carry any payload.

The user plane parameter may be a control plane identifier identifying the control plane communication; and the instance identifier may be generated from the control plane identifier by the predefined mapping rule.

The control plane identifier may comprise the instance identifier. The payload may be received from an access network or to be transmitted to the access network in an access network communication, and the method may further comprise generating the control plane identifier of the control plane communication such that the control plane identifier is unambiguously related to an access identifier of the access network communication.

The access network may be at least one of a radio access network and a fixed broadband access network. The control plane identifier may be a tunnel endpoint identifier. The instance identifier may comprise a service instance identifier.

The method may be a method of parameter mapping.

According to a third aspect of the invention, there is provided a computer program product comprising a set of instructions which, when executed on an apparatus, is configured to cause the apparatus to carry out the method according to the second aspect. The computer program product may be embodied as a computer-readable medium or directly loadable into a computer.

According to some embodiments of the invention, at least one of the following advantages may be achieved:

• high reliability and low latency, in particular for industrial networks;

• reduced number of independent parameters.

It is to be understood that any of the above modifications can be applied singly or in combination to the respective aspects to which they refer, unless they are explicitly stated as excluding alternatives.

Brief description of the drawings

Further details, features, objects, and advantages are apparent from the following detailed description of the preferred embodiments of the present invention which is to be taken in conjunction with the appended drawings, wherein:

Fig. 1 shows an industrial network including a 5G system; Fig. 2 shows a 4G User plane protocol stack with GTP-U/UDP/IP as defined in 3GPP TS 23.401 ;

Fig. 3 shows an alternative 4G User plane protocol stack with GRE Tunnelling layer on S5/S8 as defined in 3GPP TS 23.402;

Fig. 4 shows a 4G Control plane protocol stack with S1 -AP on S1 -MME interface as defined in 3GPP TS 23.401 ;

Fig. 5 shows a 4G Control plane protocol stack with GTP-C on the S1 1 -interface between MME and S-GW as defined in 3GPP TS 23.401 ;

Fig. 6 shows a 5G User plane protocol stack as defined in 3GPP TS 23.501 ;

Fig. 7 shows a user plane protocol stack on the N3/NG-U interface as defined in 3GPP TS 38.300;

Fig. 8 shows a user plane protocol stack with GTP-U/UDP/IP on the N3 interface, here shown with Ethernet as end-to-end service (Figure based on 3GPP TS 23.501 )

Fig. 9 shows a protocol header for Ethernet over GTP-U/UDP/IP;

Fig. 10 shows a Message Sequence Chart for the 5G Attach/Service Request procedure (based on 4G procedure, using 5G terminology);

Fig. 1 1 shows a one-to-one mapping of GTP-C/S1 -AP TEID to GTP-U TEID;

Fig. 12 shows a one-to-one mapping for TEID (left) and GRE key (right);

Fig. 13 shows a mapping of TEID from Control Plane to either GTP-TEID or GRE key;

Fig. 14 shows a proposed 5G user plane protocol stack using Ethernet at least on the N3 interface;

Fig. 15 shows a protocol stack and header fields (simplified on left side, more detailed on right side) for the protocol stack of Fig. 14;

Fig. 16 shows a mapping principle of TEID of 3GPP control plane towards l-SID as used in IEEE 802.1 h. Note: Only 24 bits can be mapped.

Fig. 17 shows a mapping principle of TEID of 3GPP control plane towards l-SID + B-VLAN- ID as used in IEEE 802.1 h. Note: All 32 bits of TEID can be mapped.

Fig. 18 shows a mapping principle of TEID of 3GPP control plane to either GTP-U TEID or IEEE 802.1 ah l-SID (+optionally B- VLAN- ID);

Fig. 19 shows a mapping principle of TEID of 3GPP control plane to either GTP-U TEID or IEEE 802.1 ah l-SID (+optionally B- VLAN- ID) or IETF GRE Key-field;

Fig. 20 shows a detailed mapping of 3GPP TEID towards l-SID as used in IEEE 802.1 h. Note: Only 24 bits can be mapped.

Fig. 21 shows a detailed mapping of 3GPP TEID towards l-SID + B-VLAN-ID as used in IEEE 802.1 h. Note: All 32 bits of TEID can be mapped. Fig. 22 shows a Message Sequence Chart for the Attach/Service Request procedure showing TEID and l-SID usage;

Fig. 23 shows an apparatus according to an embodiment of the invention;

Fig. 24 shows a method according to an embodiment of the invention; and

Fig. 25 shows an apparatus according to an embodiment of the invention.

Detailed description of certain embodiments

Herein below, certain embodiments of the present invention are described in detail with reference to the accompanying drawings, wherein the features of the embodiments can be freely combined with each other unless otherwise described. However, it is to be expressly understood that the description of certain embodiments is given by way of example only, and that it is by no way intended to be understood as limiting the invention to the disclosed details.

Moreover, it is to be understood that the apparatus is configured to perform the corresponding method, although in some cases only the apparatus or only the method are described.

Some embodiments of the invention provide a method for mapping 3GPP control plane identifiers to IEEE user plane protocol headers for a case that the user plane communication is performed via Ethernet (as shown e.g. in the user plane protocol stack of Fig. 14). That is, some embodiments of the invention use the protocol architecture of Fig. 14 and extend the same. The l-SID shown in Fig. 15 is of particular importance for some embodiments of this invention.

According to some embodiments of the invention, the 3GPP Tunnel Endpoint Identifier (TEID) used in a control plane protocol like GTP-C, S1 -AP or NGAP is mapped towards the Backbone Service Instance Identifier (l-SID) used in the IEEE 802.1 ah/802.1 Q user plane messages. This mapping principle is shown in Fig. 16. The mapping works in both directions: TEID -> l-SID and l-SID -> TEID.

The 3GPP TEID has 32 bits. The IEEE l-SID has 24 bits. Therefore, only 24 bits of the TEID shall be mapped to the l-SID. 8 bits in the TEID may remain unused for the mapping. E.g. they may be used for other purposes within the control plane. As a further embodiment, when a TEID with 32-bits shall be used, the TEID may mapped to two different parameters of the user plane. As shown in Fig. 17, 24 bits of the TEID are mapped to the l-SID while the remaining 8 bits of the TEID are mapped to the IEEE Backbone-VLAN-ID. Note: The Backbone VLAN-ID has 12 bits. This means that 4 bits in the Backbone VLAN-ID are not used for the mapping.

In general, if one of the identifiers of the control plane and the user plane to be mapped on each other has more bits than the other one, only the smaller number of bits may be used for the mapping, while the remaining bits of the identifier with more bits may be used for other purposes, or may remain unused. In the sense discussed here, an“identifier to be mapped” may comprise one or more identifiers of the respective plane, such as l-SID and B-VLAN ID in the above example.

In some embodiments of the invention, multiple user plane protocols are used. As already discussed in 3GPP, it is recommendable to transport the type of user plane protocol as parameter in the control plane protocol. For example, in GTP-C (not yet in S1 -AP), there is a protocol type field“Protocol Type over S5/S8” (See 3GPP 23.401 and“S5/S8 Protocol Type” in 3GPP 29.274 GTP-C)

Fig. 18 shows that the TEID as used in the control plane protocol is - dependent on the user plane protocol - either mapped to the GTP-U TEID or to the l-SID field (optionally additionally also to 8 bits of the B-VLAN-ID) of the IEEE 802.1 ah header.

A similar mapping using 3 user plane protocols is shown in Fig. 19. The TEID as used in the control plane protocol is - dependent on the user plane protocol - either mapped to the GTP-U TEID or to the l-SID field (optionally additionally also to 8 bits of the B-VLAN-ID) of the IEEE 802.1 ah header or the IETF GRE Key field.

Fig. 20 shows the detailed mapping of 24 bits from the GTP TEID as used in the control plane protocol to the 24 bits of the IEEE l-SID. 8 bits of the GTP TEID shall be unused, e.g. set to 0, or may be used for other purposes. Fig. 20 is the detailed version of the principle shown in Fig. 16. Fig. 21 shows the detailed mapping of 32 bits from the GTP TEID as used in the control plane protocol to the 24 bits of the IEEE l-SID + 8 bits of the Backbone VLAN-ID. Fig. 21 is the detailed version of the principle shown in Fig. 17.

The Message Sequence Chart in Fig. 22 shows the Attach/Service Request procedure. This MSC shows in which control plane messages the TEIDs are exchanged and in which user plane messages the l-SID (containing the value of the TEID) is used. The MSC of Fig. 22 corresponds to that of Fig. 10. However, the user plane data are transmitted in an Ethernet communication instead of the tunnels according to Fig. 10.

Fig. 23 shows an apparatus according to an embodiment of the invention. The apparatus may be a base station (such as eNB or gNB), or a user plane function (such as S-GW or P- GW) or an element thereof. Fig. 24 shows a method according to an embodiment of the invention. The apparatus according to Fig. 23 may perform the method of Fig. 24 but is not limited to this method. The method of Fig. 24 may be performed by the apparatus of Fig. 23 but is not limited to being performed by this apparatus.

The apparatus comprises first generating means 10, second generating means 20, first performing means 30, and second performing means 40. Each of the first generating means 10, second generating means 20, first performing means 30, and second performing means 40 may be a first generator, second generator, first performer, and second performer, respectively. Each of the first generating means 10, second generating means 20, first performing means 30, and second performing means 40 may be a first generating processor, second generating processor, first performing processor, and second performing processor, respectively.

The first generating means 10 generates a user plane parameter (S10). The second generating means 20 generates an instance identifier such that the instance identifier is unambiguously derivable from the user plane parameter according to a predefined mapping rule (S20). The sequence of S10 and S20 is arbitrary. The two steps may be performed fully or partly in parallel. For example, the user plane parameter and the instance identifier may be derived in parallel from a same input value.

The first performing means 30 performs a control plane communication to enable a user plane communication (S30). The control plane communication comprises the user plane parameter. For example, the user plane parameter may be a part of a control plane identifier identifying the control plane communication.

The second performing means 40 performs the user plane communication as an ethernet communication. Each packet of the user plane communication is identified by the instance identifier.

The user plane is different from the control plane at least with respect to the following aspect: the user plane communication carries a payload, and the control plane communication does not carry any payload.

Fig. 25 shows an apparatus according to an embodiment of the invention. The apparatus comprises at least one processor 410, at least one memory 420 including computer program code, and the at least one processor 410, with the at least one memory 420 and the computer program code, being arranged to cause the apparatus to at least perform the method according to Fig. 24.

An access network may be a radio access network. However, in some embodiments, it may be another kind of access network such as a fixed broadband access network.

Embodiments of the invention are explained based on the 3GPP TEID on the S1 -AP. However, the invention is not restricted to the TEID. Other identifiers may be used in the control plane. For example, in 5G, the“NGAP” (Next Generation Application Protocol) as specified in 3GPP TS 38.413 will be used in the control plane. In such embodiments, 3GPP TEID is replaced by a corresponding identifier of NGAP, currently named“GTP-TEID”.

In some embodiments of the invention, the parameter identifying the user plane communication (e.g. I-SID or l-SID + B-VLAN-ID) may be transported in the control plane in a parameter different from the control plane identifier (TEID etc.).

The control plane (either the (part of the) identifier of the control plane or the additional parameter) may transport a parameter which is 1 :1 mappable to the parameter identifying the user plane communication. Some embodiments of the invention are explained where Ethernet over Ethernet is used on both the N3 interface and the N9 interface. However, according to some embodiments, Ethernet over Ethernet may be used on only one of these interfaces.

Some embodiments of this invention may also be employed in an Enterprise LAN using 5G as a replacement for Ethernet and WLAN connectivity (Use case discussed in 3GPP TR 22.821“Feasibility Study on LAN Support in 5G (Release 16)”).

One piece of information may be transmitted in one or plural messages from one entity to another entity. Each of these messages may comprise further (different) pieces of information.

Names of network elements, protocols, and methods are based on current standards. In other versions or other technologies, the names of these network elements and/or protocols and/or methods may be different, as long as they provide a corresponding functionality.

If not otherwise stated or otherwise made clear from the context, the statement that two entities are different means that they perform different functions. It does not necessarily mean that they are based on different hardware. That is, each of the entities described in the present description may be based on a different hardware, or some or all of the entities may be based on the same hardware. It does not necessarily mean that they are based on different software. That is, each of the entities described in the present description may be based on different software, or some or all of the entities may be based on the same software. Each of the entities described in the present description may be embodied in the cloud.

According to the above description, it should thus be apparent that example embodiments of the present invention provide, for example, a user plane device such as a base station (e.g. a eNB or gNB), or a UPF (such as a S-GW or PDN-GW), or a component thereof, an apparatus embodying the same, a method for controlling and/or operating the same, and computer program(s) controlling and/or operating the same as well as mediums carrying such computer program(s) and forming computer program product(s).

Implementations of any of the above described blocks, apparatuses, systems, techniques or methods include, as non-limiting examples, implementations as hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

It is to be understood that what is described above is what is presently considered the preferred embodiments of the present invention. However, it should be noted that the description of the preferred embodiments is given by way of example only and that various modifications may be made without departing from the scope of the invention as defined by the appended claims.