WO2019047197A1 - Method and system to integrate fixed access into converged 5g core - Google Patents

Abstract

This specification presents methods and apparatus in an end device 100, 100'a nd a network entity 140 implementing an interworking function, FXIWF, between a fixed access network and a mobile operator network and more particularly a 5G core network of a mobile operator. The fixed access network is viewed as an additional access network supported by the 5G core network. When the end device connected to a fixed access network signals (broadcast of EAPoL-start or TLS Client-Hello) that it wants to connect to the 5G core network, the network entity 140 instructs the end device to authenticate and register with the 5G core network. The network entity 140 relays the NAS registration and authentication over the N2 interface to the 5G core network. Following successful authentication and registration, an ethernet connection, NFu, is also established between the end device and the network entity. When a PDU session is established with the 5G core network over NFu and N2 connection to the AMF/SMF of the 5G Core, the network entity 140 relays application or user data between the end device over NFu and a UPF in the 5G core network over an N3 connection. Different VLAN tagging is used over NFu for control (NAS, EAPoL) payload and user plane payload.

Description

METHOD AND SYSTEM TO INTEGRATE FIXED ACCESS INTO CONVERGED 5G CORE TECHNICAL FIELD

The present description generally relates to wireless and fixed access communications networks, and more particularly relates to interworking between a fixed access network and a mobile operator network.

BACKGROUND

The third Generation Partnership Project, 3GPP, standards development organization has identified architectural requirements for a 5G core as specified in 3GPP TS 23.501. Notably, the new 5G core will support a new 5G radio access technology, as well as LTE, evolved LTE, and non 3GPP access types (such as wireless local area networks (WLANs) based on the Institute for Electronics and Electrical Engineers, IEEE, 802.11 standards, more specifically known as Wireless Fidelity WiFi^TM. The new 5G core will support a unified authentication framework for different access systems. The new 5G core will support multiple simultaneous connections of a user equipment, UE, via multiple access technologies. The new 5G core will allow independent evolutions of the core network and the radio access network, RAN. The new 5G core will support a separation of Control plane, CP, and User plane, UP, functions. The new 5G core will support Internet protocol, IP, connectivity services and connectivity services for data units other than IP. The new 5G core will leverage techniques such as Network Function virtualization, NFV, and SDN to reduce total cost of ownership, improve operational efficiency, energy efficiency, and simplicity and flexibility for offering new services. The new 5G core will support different levels of UE mobility (including stationary UEs) .

Fixed Wireless Access, FWA, is an established means of providing internet access to homes using wireless mobile network technology rather than fixed lines. FWA is not new. There have been several approaches to building FWA networks. Some have used proprietary systems； some have used standards derived from the Wi-Fi family. WiMAX was conceived as a fixed wireless access solution. Even 4G LTE can serve as the foundation for FWA.

While FWA can often prove more convenient to set up, its key weakness compared to fixed line broadband is performance. Current mobile network technology simply isn’ t able to provide download speeds or latency levels that can compete with a modern fibre broadband connection.

However, the next stage of FWA will utilize 5G network technology, such as beam-forming and a high-frequency millimeter wave, mmWave, spectrum, to provide a considerable performance boost to wireless broadband services. The mmWave is being trialled by a number of operators and it matches the performance of fibre and cable in some ways. The mmWave spectrum facilitates massive MIMO and beamforming which means that 5G FWA using mmWave should be able to provide equivalent capacity to the best-in-class fixed access such as fibre-based broadband, unlike 4G FWA. This performance is achieved under a well coverage condition such as enabling outdoor-to-indoor coverage or placing the Terminal antennas outdoors on rooftop or walls as well as indoors. The cost benefits of FWA will be small if the technology is too dependent on external antennas or on more or taller towers available. The mobile operators look to 5G as a way to enter the home and small and middle business, SMB, broadband market. The 5G FWA is able to bring Internet service access to rural areas where wired services are not available. It can also offer services in more developed areas that already have other broadband options to compete against FTTx on replacing of legacy broadband such as DSL, cable modem. The 5G FWA not only allows mobile operators to expand into new service areas, it also helps operators better prepare to deploy 5G once standard is set. FWA has been positioned as a solution to serve the underserved. 5G FWA can be used in those areas, but its capabilities make it suitable for more.

Operators can use 5G FWA to offer services in more developed areas that already have other broadband options.

In 5G FWA, a CPE (or a RG) supporting FWA is connected to a 5G core through 5G wireless access. At the same time, the CPE can also be connected to the 5G core through fixed or wireline access, Figure 1 illustrates an example of 5G FWA deployment. When a standalone 5G UE is behind a relay CPE, the UE should be able to connect to the 5G core through fixed access. Connecting to 5G core allows offering more than just raw Internet access. This capacity can also be used to support extra services such as High Definition, HD, video and voice services. The extra service offering could create extra revenue streams to accelerate return on investment. At the same time, the service convergence is already a market reality. As such, the convergence based on 5G and fixed dual or hybrid accesses will provide network redundancy, enhance user experience with always best connected. The convergence will also increase peak throughput by using dual connection technology such as Multi-path Transport Control Protocol, MPTCP. In addition, it can  also unify resources (e.g. antennas, cable, sites, equipment…) by providing a unified network architecture.

In recent decade, the broadband network was migrating to an architecture that is based on Ethernet aggregation as specified by the Broadband forum, BBF, Technical Report, TR-101 and TR-156. Ethernet is supposed to provide a technology foundation to meet the needs of the broadband network through a maturing transport mechanism that efficiently provides higher connection speeds, packet based QoS, simpler provisioning, multicast, and redundancy. The Ethernet aggregation architecture allow Ethernet based connection setup to BNG in central office. Ethernet aggregation architecture also allow possibility to transfer the control and legacy features from end devices or customer premises to operator network when the network is deployed in cloud environment with SDN support.

The BBF TR-348 specifies a hybrid access converged architecture by placing a hybrid access gateway, HAG, behind the packet gateway, P-GW of an Evolved Packet Core, EPC, (also known as 4G Core network) and a Broadband Network Gateway BNG for traffic aggregation/anchor for hybrid accesses. It is a L3 or L4 level connection convergence without considering fixed access to integrated into 4G EPC network. The 3GPP standard TS 23.139 describes the interworking between a 3GPP system and a Fixed Broadband Access network as defined by BBF to provide IP connectivity to a 3GPP UE using a WLAN connected to a Fixed Broadband Access network. The interworking enables traffic to be anchored at a P-GW (rather than in a HAG behind a P-GW) . However, the interworking solution of 3GPP TS 23.139 illustrated in Figure 2 describes how to integrate a device of WLAN access into 4G/EPC through fixed access network but does not specify integrating the fixed access itself into EPC network such the LTE access or WLAN access (e.g., trusted WLAN) . In the architecture specified in 3GPP TS 23.139, the fixed access network acts as backhaul which provides IP level connection and where the UE is connected indirectly to the P-GW via s2b or s2c interfaces as defined in 3GPP TS 23.402 for a WLAN device connected to the EPC network.

SUMMARY

As stated above and illustrated in Figure 2, current systems (end device and fixed access network) can only establish access connection to BNG/BRAS and can only establish L3 or higher level connection to an anchor in the P-GW in EPC network or the HAG (after EPC network) for dual access convergence. Methods and apparatus are provided to support connectivity of an end  device (i.e., a CPE-mode (or CPE-based) UE or a standalone UE behind a relay CPE (or standalone-mode UE) ) to a converged 5G core through fixed or wireline access via a fixed gateway/interworking function, FXIWF, and where the fixed access is handled as one of the supported new access. The FXIWF terminates fixed access from the end device and connects the end device to the converged 5G Core. The end device is configured to establish 5G connection over the fixed access in similar way done over 5G wireless access. The setup of 5G connection over fixed access will make use of the same credential and subscription as that used over the 5G wireless access.

In one aspect, as the fixed access is upgraded to support 5G connection to 5G converged core, the fixed access network could be required to support the existing legacy connection to BNG/BRAS, in which case co-existence of 5G connection and legacy BNG connection is possible. Note that converged 5G Core and 5G Core are interchangeable herein.

In one aspect, the end device (the CPE-mode UE or standalone-mode UE) is connected to the FXIWF using Ethernet communication with 5G support capabilities, i.e., 5G Ethernet frame. For the CPE-mode UE, the Ethernet communication is between the CPE and the FXWIF. For the standalone-mode UE, the Ethernet communication is between the UE and the relay CPE, and between the relay CPE and the FXIWF.

In one aspect, on the uplink, from the CPE to the FXIWF, the CPE sends 5G Ethernet frame based on 5G specific Ethernet type (Ethertype) . In another aspect, the 5G Ethernet frame is tagged with 5G VLAN id (It may be further tagged with S-TAG when it is traversing the access network) . In one aspect, on the reverse direction, the FXIWF sends to the CPE a 5G Ethernet frame (possibly with the same VLAN tag copied from the received uplink Ethernet frame) . In yet another aspect, the CPE supports co-existence of 5G connectivity and existing legacy BNG connectivity and is able to distinguish the 5G Ethernet frame from non-5G Ethernet frame (i.e., of existing legacy BNG access)

In one aspect, the standalone-mode UE supports the connection capability negotiation with the CPE replay using EAPoL extension and/or DHCP extension.

In another aspect, roaming end devices or end-devices of multiple mobile operators over given fixed access are supported by enabling a per operator/PLMN 5G Ethernet frame which is tagged with a per PLMN specific 5G VLAN id. In one aspect, the per PLMN 5GVLAN configuration is provided using DHCP extension.

In one aspect, the end device and the FXIWF exchange 5G Ethernet frames for signaling and transport of upper application protocol PDU. The upper application protocols include EAPoL and a proposed Layer 2 application protocol, L2AP. L2AP is designed to support user authentication and registration, PDU session setup on fixed access and transport of NAS messages to and from the end device. The FXIWF interworks with the AMF in the 5G Core where the AMF provides control plane anchor. Once the end device is successfully authenticated by the 5G Core network (5G PLMN) , a point to point Ethernet connection referred to as NFu between the end device and FXIWF is also established. When a PDU session is established following the NAS procedures over NFu and N2 interface, user plane connection is established between the end device and FXIWF (user plane) over NFu and between the FXIWF and the UPF in 5G Core network over N3 interface.

Different embodiments are described for identifying the PDU session over NFu. L2AP may be used to transport user data between the end device and the FXIWF.

This summary is not an extensive overview of all contemplated embodiments, and is not intended to identify key or critical aspects or features of any or all embodiments or to delineate the scope of any or all embodiments. In that sense, other aspects and features will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments in conjunction with the accompanying figures.

BRIEF DESCRIPTION OF THE DRAWINGS

Exemplary embodiments will be described in more detail with reference to the following figures, in which:

Figure 1 (prior art) is a schematic diagram of an example 5G FWA deployment.

Figure 2 (prior art) is a schematic diagram of BBF interworking with EPC according to 3GPP TS 23.139.

Figure 3 is a schematic diagram of an example fixed access network interworking with 5G Core network in accordance with some embodiments.

Figure 4 illustrates embodiments of example implementations of FXIWF 140 with and without control and user plane split.

Figures 5a and 5b are example illustrations of some embodiments of a CPE-mode UE and a standalone-mode UE implementation respectively.

Figure 6a and 6b is an illustration of two example control plane protocol stack of the NFu interface between UE 100/100’ and FXIWF 140 in accordance with some embodiments.

Figure 7 illustrates an ETLS record protocol in accordance with some embodiments.

Figures 8a-8e are example illustrations of user plane protocol stack on the NFu interface between UE 100/100’ and FXIWF 140 in accordance with some embodiments.

Figure 9 is a sequence diagram illustrating a high level NFu connection procedure in accordance with an embodiment.

Figure 10 is a sequence diagram illustrating a high level NFu connection procedure in accordance with another embodiment.

Figure 11 is a sequence diagram illustrating DHCP procedure in accordance with an embodiment.

Figure 12 is a sequence diagram illustrating T-connection establishment between a standalone-mode UE and a CPE relay in accordance with some embodiments.

Figure 13 is a sequence diagram illustrating 5g registration and authentication procedure in accordance with an embodiment.

Figure 14 is a sequence diagram illustrating PDU connection establishment procedure in accordance with an embodiment.

Figure 15 is a method of operation of a UE in accordance with some embodiments.

Figure 15a is flow chart describing detailed operation of CPE-mode UE in accordance with some embodiments.

Figure 15b is flow chart describing detailed operation of standalone-mode UE in accordance with some embodiments.

Figure 16 is a flow chart of operations of a FXIWF in accordance with some embodiments.

Figure 16a is a flow chart describing detailed operation of FXIWF in accordance with some embodiments.

Figure 17 is a block diagram of a UE in accordance with some embodiments.

Figure 18 is another block diagram of a UE in accordance with some embodiments.

Figure 19 is a block diagram of a network node implementing the FXIWF in accordance with some embodiments.

Figure 20 is another block diagram of a network node implementing the FXIWF in accordance with some embodiments.

Figure 21 is another block diagram of a network node implementing the FXIWF in accordance with other embodiments.

DETAILED DESCRIPTION

The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments. Upon reading the following description in light of the accompanying figures, those skilled in the art will understand the concepts of the description and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the description.

In the following description, numerous specific details are set forth. However, it is understood that embodiments may be practiced without these specific details. In other instances, well-known circuits, structures, and techniques have not been shown in detail in order not to obscure the understanding of the description. Those of ordinary skill in the art, with the included description, will be able to implement appropriate functionality without undue experimentation.

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

As used herein, the singular forms "a" , "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises, ” “comprising, ” “includes, ” and/or “including” when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

It will be further understood that the terms “end device” , “5G device” , “user equipment” , and “wireless device” when used herein refer to the device 100 or 100’ a s referenced in Figure 3 and are interchangeable.

It will be further understood that the terms “5G Core network” is used to refer to a core network that supports 5G use cases. An example of such network is the 5G Core specified by 3GPP in TS 23.501. Other mobile operator core networks can also be used. Embodiments herein are described using the 3GPP 5G core network 150.

Figure 3 illustrates an example of a network illustrating fixed access network 130 interworking with 5G Core network 150 in accordance with some embodiments. The network enables 5G devices, wireless devices, or user equipments, UEs 100, 100’ to connect to the 5G mobile operator network in order to have access to the 5G services over the fixed access network. The 5G Core network as currently being defined by 3GPP TS 23.501 is partially illustrated by the Access and mobility function, AMF 160, the session and mobility management function, SMF 170 and the User plane function 180.

The AMF 160 provides access and mobility management functionalities, some of which are provided below. Some or all of the AMF functionalities may be supported in a single instance of a AMF 160:

- Termination of Radio Access Network control plane, RAN CP interface (N2) .

- Termination of Non-Access Stratum, NAS, (N1) with a user equipment, UE, NAS ciphering and integrity protection.

- Registration management.

- Connection management.

- Reachability management.

- Mobility Management.

- Lawful intercept (for AMF events and interface to Lawful Intercept, LI System) .

- Provide transport for Session management, SM, messages between UE and SMF.

- Transparent proxy for routing SM messages.

- Access Authentication.

- Access Authorization.

- Security Anchor Function (SEA) . It interacts with the Authentication server function, AUSF and the UE, receives the intermediate key that was established as a result of the UE authentication process.

- Security Context Management (SCM) . The SCM receives a key from the SEA that it uses to derive access-network specific keys.

The SMF 170 provides session management functionalities some of which are provided below. Some or all of the SMF functionalities may be supported in a single instance of a SMF 170:

- Session Management e.g., Session establishment, modify and release, including tunnel maintain between UPF and Access network, AN, node (e.g., gNB) .

- UE IP address allocation &management (incl optional Authorization) .

- Selection and control of user plane, UP, function.

- Configures traffic steering at UPF to route traffic to proper destination.

- Termination of interfaces towards Policy control functions.

- Control part of policy enforcement and Quality of Service, QoS.

- Lawful intercept (for SM events and interface to LI System) .

- Termination of SM parts of NAS messages.

- Downlink Data Notification.

- Initiator of AN specific SM information, sent via AMF over N2 interface to AN.

- Roaming functionality:

- Handle local enforcement to apply QoS Service Level Agreements, SLAs (Visited Public Land Mobile Network, VPLMN) .

- Lawful intercept (in VPLMN for SM events and interface to LI System) .

- Support for interaction with external Data Network, DN, for transport of signalling for Packet Data Unit, PDU, session authorization/authentication by external DN.

The UPF 180 provides user plane functionalities some of which are provided below. Some or all of the UPF functionalities may be supported in a single instance of a UPF 180.

Anchor point for Intra-/Inter-RAT mobility (when applicable) .

- External PDU session point of interconnect to Data Network, DN.

- Packet routing &forwarding.

- Packet inspection and User plane part of Policy rule enforcement.

- Lawful intercept (UP collection) .

- Traffic usage reporting.

- Uplink classifier to support routing traffic flows to a data network.

- Branching point to support multi-homed PDU session.

- QoS handling for user plane, e.g. packet filtering, gating, Uplink/Downlink, UL/DL rate enforcement

- Uplink Traffic verification (SDF to QoS flow mapping) .

- Transport level packet marking in the uplink and downlink.

- Downlink packet buffering and downlink data notification triggering.

The Fixed Access Network interworking function, FXIWF 140 is a proposed function to support the embodiments described herein. The FXIWF 140 may be part of the fixed access network 130 or the 5G Core network 150. Similar to a RAN node, the FXIWF 140 supports the N2 interface towards the AMF 160 and N3 interface towards the UPF 180 of the 5G Core network 150. The FXIWF 140 according to the embodiments herein supports one or more of the following functionalities. Some or all of the FXIWF functionalities may be supported in a single instance of a FXIWF 140:

- perform Ethernet frame exchanges with the UE.

- is able send Ethernet frame to the UE with same VLAN id that is received in the received uplink Ethernet frame

- is able to support both native Ethernet encapsulation method and ETLS Ethernet encapsulation method for Ethernet frame exchange with the UE.

- is able to establish and maintain NFu connection with the UE. The NFu is an Ethernet connection established between the UE 100, 100’ and the FXIWF 140.

- is able to implement EAPoL-extension, Layer 2 Application Protocol L2AP (as proposed herein) to encapsulate NAS and user plane packets and Transport Layer Security over Ethernet, ETLS, on the NFu interface.

- is able to act as an authenticator for user authentication with 5G core network 150.

- is able to perform PDU setup on the NFu interface

- is able to perform user payload transfer on the NFu interface using L2AP, virtual MAC, vMAC, address or virtual Local Area Network, VLAN.

- is able to support QoS flow on the NFu interface for user payload transfer

- is able to support ETLS security and/or support user plane security on the NFu interface

- is able to interwork with AMF 160 for control plane procedures (following N2 interface definition as specified in 3GPP TS 23.501) .

- is able to support user plane separation from control plane.

- may consist of a separate control plane entity, FXIWF-CP 141 and a user plane function FXIWF-UP 142. Figure 4 illustrates embodiments of example implementations of FXIWF 140 with and without control and user plane split. Details are described below.

- FXIWF-UP 142 can be implemented as a standalone function or part of 5G UPF 180.

- When the FXIWF-UP 142 is a standalone node, the FXIWF-UP 140 is able to interwork with 5G UPF 180 for user plane transport (N3 interface) .

- When the FXIWF-UP 142 is part of 5G UPF 180, the FXIWF-UP 142 provide N3 interface with Access Node, AN, 135.

User Plane Separation in FXIWF 140

When either vMAC or VLAN is used for user payload transport, the FXIWF user plane (FXIWF-UP 142) can be separated from the FXIWF control plane (FXIWF-CP 141) to form an individual node or act as part of 5G UPF 180. Three embodiments for FWIXF UP 142 location are illustrated in Figure 4.

- Case 1: non-FXIWF UP separation (FXIWF-UP is tightly coupled with FXIWF-CP) 

- Case 2: FXIWF-CP controlled FXIWF UP (FXIWF-UP is implemented in an individual function)

- Case 3: 5G core controlled FXIWF UP (FXIWF-UP 142 integrated into 5G UPF 180 or part of it)

PDU user plane setup in FXIWF user plane

When the FXIWF-UP 142 is implemented in an individual node (case 2 of Figure 4) , PDU user plane in the FXIWF-UP 142 is controlled from the FXIWF-CP 141 via internal (NFx) interface.

When the FXIWF-UP 142 is implemented or collocated in 5G UPF 180 (case 3 of Figure 4) , PDU user plane in the FXIWF-UP 142 is controlled by the 5G SMF 170 via internal interface (N4-internal) as illustrated in Figure 4.

When configuring the user plane of the FXIWF, one or more of the following information should be configured:

- VMAC and/or VLAN id for PDU user plane connection, and/or PDU connection id for L2AP user payload transport.

- QoS rules information: provide the service data flow, SDF, template. i.e. the set of packet filters together with the SDF precedence and the corresponding quality of service parameters or index. Details of QoS support on the NFu interface (between FXIWF 140 and UE 100/100’) is described in section “QoS support on fixed access” below.

- Security information: key material generated during the user authentication in control plane procedures. The key material will be used for user plane security. Details of security requirements on the NFu interface (between FXIWF 140 and UE 100/100’ ) is described in section “Security over NFu interface” below.

QoS support over NFu and fixed access network:

In the 5G QoS model as stated in 3GPP TS 23.501, the user traffic will be mapped to different QoS Flows. In embodiments described herein, a QoS Flow will be mapped to Access node 135 resources in the fixed access network 130 so that QoS for user traffic can be supported. A QoS Flow includes QoS Flow Identifier (QFI) and QoS Flow parameters.

During PDU session setup setup, the FXIWF 140 maps QoS Flow to the access node 135 resource based on QFI and corresponding QoS parameters. The FXIWF 140 support QoS Flow preemption which is used to determine if the QoS Flow setup will be performed unconditionally and immediately.

With VLAN priority supported for traffic class on an Ethernet frame, each traffic class has corresponding QoS treatments according to the fixed access network 130 provider definition. For example, different queue length, different scheduling priority, etc.

The following describes some embodiments for handling QoS on the NFu interface at the FXIWF 140 and UE 100/100’ :

- The FXIWF 140 support QoS Flow setup and marks VLAN priority value for its Ethernet frame according to QoS Flow parameters.

- To support QoS Flow preemption, the FXIWF 140 may setup QoS Flow and mark a VLAN priority value for its Ethernet frame and release a low priority QoS Flow.

- During PDU session on NFu interface, the FXIWF 140 signals QoS Flow parameters to the UE 100/100’.

- The UE 100/100’ and the FXIWF 140 perform traffic mapping to appropriate QoS flow. The UE 100/100’ and the FXIWF 140 enforce user traffic QoS according to QoS parameters such as aggregated maximum bit rate, AMBR.

Security over NFu interface (UE-FXIWF interface)

Secure connectivity between the UE 100/100’ and the FXIWF 140 is described for both for signaling and user payload over the NFu interface.

The control plane security is supported when DTLS is used in native Ethernet method (for L2AP PDU transport) and when ETLS method is used.

For user plane security as illustrated, when user plane is terminated in FXIWF 140 (not a standalone FXIWF-UP 142 as in user plane separation shown in case 2 and case 3 of Figure 4) . The Same security method used in control plane is applied. For embodiments of user plane protocol stacks see Figures 8a to 8e.

When user plane is terminated in standalone FXIWF-UP 142 (case 2 of Figure 4) or a FXIWF-UP 142 in 5G UPF 180 (case 3 of Figure 4) , a user plane security layer (UP sec) is required between Ethernet layer and user payload. Key material in FXIWF-UP 142 is received from the control plane (FXIWF-CP 141 or SMF 170) .

- When ETLS is used, ETLS tunnel provide user plane, UP, security.

- However, other security method such IPSEC ESP could be applied which can be different from security method used in control plane

The User equipment 100, 100’ a lso referred to as wireless device, end device may operate in two modes in accordance with the embodiments herein:

- CPE-mode UE 100’ : which is integrated into a customer premise equipment, CPE, 110 that supports 5G connectivity over fixed access. Figure 5a illustrates an example of an embodiment of a CPE-mode UE implementation to support the embodiments herein.

- Standalone-mode UE 100: which is connected to 5G core via a CPE 110. Figure 5b illustrates an example of an embodiment of a Standalone-mode UE implementation to support the embodiments herein.

UE 100, 100’ common functionalities

- able to perform Ethernet frame exchanges with the FXIWF 140.

- able to support Ethernet frame exchange with the FXIWF 140 by using either Native Ethernet encapsulation method or ETLS Ethernet encapsulation method.

- able to establish and maintain NFu connection toward the FXIWF 140.

- able to implement EAPoL-extension, L2AP and ETLS on the NFu interface.

- able to perform user authentication with 5G core.

- able to perform PDU setup on the NFu interface.

- able to perform user payload transfer on the NFu interface using L2AP, virtual MAC address or VLAN.

- able to support QoS flow on the NFu interface for user payload transfer

- able to support ETLS base security and/or support user plane security on the NFu interface.

Standalone-mode UE 100 specific functionalities

The standalone-mode UE 100 is able to support T-connection negotiation with the CPE 135 using either 802.1x procedures or DHCP procedures

The standalone-mode UE 100 is able to support VLAN tag for uplink Ethernet frames if negotiated. The standalone-mode UE 100 is able to support tagged or untagged Ethernet frame transfer on the T interface.

As used herein, UE 100, 100’ may be a wired or a wireless device, WD. A wireless device, WD, 100, 100’ refers to a device capable, configured, arranged and/or operable to communicate wirelessly with network nodes and/or other wireless devices. Communicating wirelessly may involve transmitting and/or receiving wireless signals using electromagnetic signals, radio waves, infrared signals, and/or other types of signals suitable for conveying information through air. In some embodiments, a WD may be configured to transmit and/or receive information without direct human interaction. For instance, a WD may be designed to transmit information to a network on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the network. Examples of a WD include, but are not limited to, user equipment (UE) , smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal data assistant (PDA) , wireless cameras, gaming terminal devices, music storage, playback appliances, wearable terminal devices, wireless endpoints, mobile stations, tablets, laptops, laptop-embedded equipment (LEE) , laptop-mounted equipment (LME) , USB dongles, smart devices, wireless customer-premise equipment (CPE) and vehicle-mounted wireless terminal devices. A WD may support device-to-device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, and may in this case be referred to as a D2D communication device. As yet another specific example, in an Internet of Things (IoT) scenario, a WD may represent a machine or other device that performs monitoring and/or  measurements, and transmits the results of such monitoring and/or measurements to another WD and/or a network node. The WD may in this case be a machine-to-machine (M2M) device, which may in a 3GPP context be referred to as a machine-type communication (MTC) device. As one particular example, the WD may be a UE implementing the 3GPP narrow band internet of things (NB-IoT) standard, Wireless Fidelity, WiFi^TM standard, Bluetooth, or other. Particular examples of such machines or devices are sensors, metering devices such as power meters, industrial machinery, or home or personal appliances (e.g. refrigerators, televisions, etc. ) personal wearables (e.g., watches, fitness trackers, etc. ) . In other scenarios, a WD may represent a vehicle or other equipment that is capable of monitoring and/or reporting on its operational status or other functions associated with its operation. A WD as described above may represent the endpoint of a wireless connection, in which case the device may be referred to as a wireless terminal. Furthermore, a WD as described above may be mobile, in which case it may also be referred to as a mobile device or a mobile terminal. A wired device is similar to a wireless device except it communicates with network nodes over wired interface instead of radio technology.

Customer Premise Equipment, CPE, 110

The CPE shall be able to act as a CPE-mode UE and act as a relay for standalone UE relaying NAS and application data between the UE 100 and the 5G Core network 150.

The CPE shall act as DHCP client to support per PLMN 5GVLAN configuration when DHCP is used by the UE 100, 100’ .

The CPE as a CPE-mode UE 100’ is able to support all the UE common functionalities as stated above.

CPE Relay functionalities for standalone-mode UE 100

The CPE 110 is able to support T-connection negotiation with the standalone-mode UE using either 802.1x procedures or DHCP procedures.

The CPE is able to create MAC record in forwarding (FWD) table. A record looks like:

- MAC address1 (UE1) : transparently forward from CPE downstream port to upstream port and visa verse.

- MAC address 2 (UE2) : in uplink direction, add VLAN tag for Ethernet frame and forward it from CPE downstream port to upstream port； in downlink direction, forward from CPE upstream port to downstream port

The CPE 110 is able to support tagging 5GVLAN id for untagged Ethernet frame received on the T interface and forwarding the tagged Ethernet frame to the fixed access network.

For VLAN tagged Ethernet frames, the CPE transparently forwards the frames from the UE 100 to the fixed access network 130.

Figure 6a and 6b is an illustration of two example control plane protocol stack of the NFu interface between UE 100/100’ and FXIWF 140 in accordance with some embodiments.

Figures 6a and 6b illustrates two Ethernet Encapsulation methods used to encapsulate and transport upper application protocol PDU: native Ethernet encapsulation method is illustrated in Figure 6a and ETLS encapsulation method is illustrated in Figure 6b.

The upper control application protocols include EAP and Layer 2 Application Protocol, L2AP as described herein. L2AP is a protocol proposed herein used to transport NAS messages that should be relayed by FXIWF 140 to the 5G Core network 150 and is also used for management of the NFu connection between the UE 100/100’ and FXIWF 140.

Native Ethernet encapsulation method, Figure 6a: (1) EAP is encapsulated into Ethernet as EAPoL frame as defined in IEEE standard 802.1x, Feb 2010； (2) L2AP PDU is set as content of DTLS which is encapsulated into Ethernet as its payload. A new Ethertype is defined to support transport of the DTLS PDU using Ethernet frame.

ETLS encapsulation method: ETLS is a new type of Ethernet payload which encapsulates both EAP PDU and L2AP PDU as payload of its TLS sublayer. Embodiments describing examples of ETLS definition is provided with the description of Figure 10.

Table below illustrates the different encapsulation method and summarizes the new Ethertype proposed to support some embodiments as described herein. Figure 7 illustrates an ETLS record definition in accordance with some embodiments. Figure 7 illustrates the L2AP as a new record sub-layer.

Figures 9 and 10 illustrate NFU connection management methods according to some embodiments. During the initial 5G Ethernet frame exchanges and when user registration and authentication of the UE 100/100’ with 5G Core 150 is done, an Ethernet level connection is established as well between the UE 100/100’ and FXIWF 140. The Ethernet level connection is identified by pairs of UE and FXIWF MAC addresses. It is named NFu connection (or AN connection) .

Establishment and maintenance of the Ethernet NFu connection depends on the different Ethernet methods as specified in Figure 9 and 10.

Figure 9 illustrates a sequence diagram of a high level NFu connection procedure in accordance with an embodiment based on native Ethernet method and EAPoL extension. As shown, the end device 100/100’ may be a CPE-mode UE 100’ or standalone-mode UE 100. In standalone-mode UE 100, the CPE 110 acts as a relay. In addition, when operating in standalone-mode, the UE 100, must first establish a T-connection with the CPE 110 before it starts communicating with the FXIWF 140. Details of T_connection establishment are further illustrated in Figure 12. The signaling flow in Figure 9 assumes the T-connection is already established between the standalone-mode UE 100 and the CPE 110.

The initial Ethernet frame exchanges between the UE 100/100’ and the FXIWF are used for NFu connection setup. After that, the Ethernet frames can be exchanged to transfer upper application PDU and user payload. On the uplink direction towards the fixed access network, the UE 100/100’s hould set its MAC address as source MAC address. For the very first broadcasting Ethernet frame, the broadcast MAC address is set as destination MAC address. For the subsequent unicast Ethernet frames, FXIWF MAC address is set as destination MAC address.

At step A1 in Figure 9, the UE 100/100’ broadcasts EAPoL-start frame to establish NFu connection. The FXIWF receiving the EAPoL-start will trigger establishment of the NFu connection with the UE 100/100’ . The FXIWF 140 responds to the UE at step A2 with EAPoL-announcement that comprises a Type Length Value parameter or similar parameter indicating:  “request for authentication” to indicate user authentication via 5G registration should be performed. The EAP-announcement may also include the FXIWF IP address for L2AP transport.

At steps A3, The NAS PDUs of 5G registration procedure are transported using L2AP protocol over Ethernet or IP/Ethernet. The FXIWF 140 extracts the NAS PDUs from the L2AP envelop and transfers them to the AMF 160 in the 5G Core 150 over the N2 interface at step A3a. Details of 5G registration procedure are shown in Figure 13. Similarly, NAS PDUs received from the AMF 160 are encapsulated in an L2AP prior to sending them to the UE 100/100’ . The 5G Registration and authentication procedure is described in 3GPP TS 23.501. At step A4, when 5G registration procedure is performed and user authentication is successfully completed between the UE 100/100’ and the 5G core 150 over the FXIWF 140, both the UE 100/100’ and the FXIWF 140 will at completion of the registration and user authentication treat the NFu connection as also established. At step A5, the UE 100/100’ is considered attached with the 5G Core network 150, The UE 100/100’ may exchange subsequent NAS messages for PDU session establishment. The NAS messages are relayed by the FXWIF 140.

Periodically, both the UE 100/100’ and FXIWF 140 use EAPoL-heartbeat request and response to keep-alive the NFu connection. Both the UE 100/100’ and FXIWF 140 can send EAPoL-logoff to explicitly release the NFu connection.

The FXIWF 140 may at any time at step A0 trigger re-establishment of a released NFu connection. In this case, the FXIWF 140 will send an EAPoL-announcement (with TLV indicating “request for connection setup” ) to the UE 100/100’ . The UE 100/100’ repeats steps A3 to A4 as described above leading to re-establishment of the NFu connection. The UE 100/100’ may perform the EAPoL procedures again (steps A1 and A2) if necessary.

If authentication fails or no response is received from the 5G Core, or the FXIWF 140 has not received an indication that the user authentication is completed, the FXIWF 140 will terminate L2AP protocol handling for the UE and may send EAPoL-logoff to indicate abnormal termination of the Nfu connection procedure. The UE 100/100’ may re-initiate EAPoL-start to repeat the procedure.

The UE 100/100’ may trigger re-establishment of a released NFu connection by sending EAPoL-start message.

TLV definition for EAPoL messages used in Figure 9

EAPoL-announcement definition

The FXIWF 140 will send EAPoL-announcement to the UE 100/100’ either as a response of receiving EAPoL-start or for network-initiated procedures

The FXIWF 140 will include Indication TLV and/or FXIWF-IP-address TLV in the EAPoL-announcement message

1. Definition TLV of Indication:

2. Definition TLV of FXIWF-IP-Address

The FXIWF-IP-address can be IPv4 (4octet) or IPv6 (16octet) address used as FXIWF IP address when L2AP is tranported over IP

Figure 10 illustrates a sequence diagram of a high level NFu connection procedure in accordance with an embodiment based on ETLS Ethernet method. As shown, the end device 100/100’ may be a CPE-mode UE 100’ or standalone-mode UE 100. In standalone-mode UE 100, the CPE 110 acts as a relay. In addition, when operating in standalone-mode, the UE 100, must first establish a T-connection with the CPE 110 before it starts communicating with the FXIWF 140. Details of T_connection establishment are further illustrated in Figure 12. The signaling flow in  Figure 10 assumes the T-connection is already established between the standalone-mode UE 100 and the CPE 110.

In ETLS Ethernet method, UE 100/100’ broadcasts ETLS frame to establish the NFu connection. At step B1, the UE 100/100’ broadcasts ETLS Ethernet frame carrying TLS handshake client-hello message PDU to setup TLS session. The UE 100/100’ will include the requested ETLS capability in the client-hello message. At step B2, the FXIWF 140 receives the ETLS frame, and responds with an ETLS frame carrying the TLS handshake server-hello message PDU. The FXIWF 140 will include the negotiated ETLS capability in the server-hello message. Both sides continue the subsequent TLS handshake procedures and complete TLS connection setup.

When the UE 100/100’ receives a TLS message indicating completion of the TLS session establishment (e.g., TLS Finished message received from the FXIWF 140) , the UE 100/100’ will at step B3 perform 5G registration and user authentication procedure with the 5G Core network 150 as described further in Figure 13. The NAS PDU of 5G registration procedure will be transported using L2AP protocol which run over ETLS between the UE 100/100’ and FXIWF 140 and on the N2 interface between the FXIWF 140 and the AMF 160.

At step B4, when 5G registration procedures is performed and user authentication is successfully completed, both the UE 100/100’ and FXIWF 140 will receive an indication that user authentication and registration is successfully completed and treat the NFu connection as established.

At step B5, the UE 100/100’ is considered attached with the 5G Core network 150, The UE 100/100’ may exchange subsequent NAS messages for PDU session establishment over the ETLS on the NFu connection and N2 connection. The NAS messages are relayed by the FXWIF 140.

Both the UE 100/100’ and FXIWF 140 use TLS heartbeat to keep-alive the connection.

If the FXIWF 140 has not received an indication of successfull completion of registration and authentication or the registration has failed, the FXIWF 140 will terminate L2AP protocol handling with the UE 100/100’ , release the TLS connection. The UE may reinitiate the NFu connection by re-initiating TLS setup. Both the UE 100/100’ and FXIWF 140 can send TLS-Alert (release) to explicitly release the NFu connection.

If the UE 100/100’ wants to re-establish NFu connection, it restarts the NFu establishment procedure from step B1.

At step B0, if the NFu connection has been released, the FXIWF 140 may trigger re-establishment of the released NFu connection. In this case, the FXIWF 140 sends TLS hello request message to the UE 100/100’ which will trigger the re-establishment procedure starting from step B1 of Figure 10.

ETLS definition:

The following are proposed ETLS definitions in support of some embodiments illustrated in Figure 10, Figure 7 and Figure 6b.

As shown on Figure 7, a new record sub-layer is added in existing TLS: L2AP sub-layer record Update on existing handshake, App_data, and alert sub-layers are also specified below as examples.

TLS Handshake hello extension to support ETLS capability negotiation

Hello extension as defined in section 7.4.1.4 of TLS protocol in IETF RFC 5246.

Following extension definition is added for ETLS capability negotiation in the TLS handshake hello messages

The format of the ETLS Hello Extension is defined by:

The EtlsCapacityExtension is used in the extension_data of Extension struct in section 7.4.1.4 in TLS protocol [9]

The ExtensionType for the EtlsCapacityExtension is defined as below 

Definition of TLS upper sub-layer l2ap protocol

This protocol is used to carry the encrypted l2ap through TLS connection. The corresponding content types are added in section 6.2.1 of TLS protocol specified in IETF RFC 5246.

The protocol messages consisting of a type and an arbitrary payload will be filled in TLSPlaintext. fragment in section 6.2.1 in TLS protocol specified in IETF RFC 5246.

TLS Alert message error extension

Following errors are added in section 7.2 of TLS protocol [9]

- User authentication failure (XXX) //the number XXX to be assigned by IANA

Indicate the user authentication failure during the tunneled authentication procedure. It is a fatal error, should be followed by a close_notify.

- User release (YYY) //the number YYY to be assigned by IANA

Indicate to the peer that the user is released from TLS client side or from TLS server side. This message is generally a warning. TLS connection is not released.

Data format in TLS applicaton_data protocol

When full Ethernet data is negotiated to use (that is, the PDU session of Ethernet PDU type is established) , the data carried through TLS application_data will follow the format below

Ether_type

Indicate the Ethernet type of the original Ethernet frame

Payload:

The data field from the original Ethernet frame

A. 5G Ethernet communication method for CPE-mode UE

The initial Ethernet frame exchanges between the CPE-mode UE and the FXIWF are used for NFu connection setup as illustrated in Figure 9 and 10. After that, the Ethernet frames can be exchanged to transfer upper application PDU and user payload.

To support the Ethernet communication, the CPE-mode UE 100’ will support following behavior:

- On the uplink direction towards the fixed access network 130, the CPE-mode UE 100’should set its MAC address as source MAC address. For the very first broadcasting Ethernet frame, the broadcast MAC address is set as destination MAC address. For the subsequent unicast Ethernet frames, FXIWF MAC address is set as destination MAC address.

- the CPE-mode UE 100’ may tag the Ethernet frame with 5GVLAN id and forward the tagged Ethernet frame on the upstream port. To tag Ethernet frame on the upstream port, the CPE-mode UE 100’should have been configured with 5GVLAN id. The 5GVLAN id is related to UE’s PLMN so that the Ethernet frame can reach to the FXIWF in home 5G core. Note that a CPE-mode UE 100’ will belong to a given PLMN (based on its SIM information) . The CPE-mode UE may retrieve its PLMN specific 5GVLAN ID configuration using DHCP method as illustrated in Figure 11.

- On the downlink direction, the CPE-mode UE receives the Ethernet frame on the port from fixed access network 130. The frame may be tagged with a 5GVLAN id. The CPE-mode UE 100’ will determine if the Ethernet frame is 5G Ethernet frame or not based on the Ethernet type and/or 5GVLAN id. The CPE-mode UE 100’ will determine if the Ethernet frame is destined to the CPE  itself (based on the destination MAC address) . If the downlink Ethernet frame is destined for the CPE, the CPE is responsible to handle it internally.

The Ethernet VLAN Tagging method is applied in the following cases:

- No 5G-specific Ethernet type is used in the Ethernet encapsulation.

- To support co-existence of 5G connectivity and legacy BNG connectivity, 5GVLAN tag is used to distinguish 5G Ethernet frame from other Ethernet frames.

B. 5GVLAN configuration

Figure 11 illustrates the DHCP procedures for 5GVLAN configuration using a DHCP option extension in accordance with one embodiment. The 5GVLAN configuration supports both CPE-mode UE 100’ and standalone-mode UE 100. In the standalone-mode UE case, multiple PLMNs are configured in the CPE and per-PLMN specific 5GVLAN configuration may be supported. In Figure 11, the CPE acts as DHCP client for 5GVLAN configuration.

A DHCP server 138 can be placed in the fixed access network 130. It may also be placed in its mobile operator network 150. For roaming UEs or UEs of multiple operators supported over the fixed access network 130 a common DHCP relay agent may be placed in the fixed access network 130.

As shown in Figure 11, for PLMN id configured in the CPE 110 (for standalone-mode UE 100) or in CPE-mode UE 100’ , the CPE broadcasts at step C1 a DHCP DISCOVER message indicating a 5G device type and/or a PLMN id in option/60 extension. When a DHCP server 138 that supports the option extension receives the message and has 5GVLAN id configured, it sends a response DHCP OFFER message at step C1b with 5GVLAN id in option/125. The CPE subsequently sends, at step C3, a DHCP REQUEST message with same option/60 extension to the DHCP server 138, the server 138 responds with a DHCP ACK message at step C3b with same option/125 extension.

C. 5G Ethernet communication method for standalone-mode UE

The initial Ethernet frame exchange between the standalone-mode UE 100 and the FXIWF 140 are used for NFu connection setup as illustrated in Figure 9 and Figure 10. Once the NFu connection is established, Ethernet frames can be exchanged to transfer upper application PDU and user payload.

On the uplink direction towards fixed access network, the UE 100 should set its MAC address as source MAC address. For the very first broadcasting Ethernet frame, the broadcast MAC address is set as destination MAC address. For the subsequent unicast Ethernet frames, FXIWF MAC address is set as destination MAC address.

Ethernet frames are exchanged between the standalone-mode UE 100 and the FXIWF 140, with CPE acting as a relay.

However, as previously stated, before any Ethernet frame exchange happens between the UE 100 and the CPE (relay) 110, a T-connection should be established on the T-interface between the UE 100 and the relay CPE 110. T connection establishment can be based on IEEE802.1x procedures or DHCP procedures.

There are two Ethernet transport modes on the T-interface between the UE and the CPE

- Untagged Ethernet transport: The UE 100 will send the untagged Ethernet frame directly on the uplink link to the CPE 110.

- Tagged Ethernet transport: The UE 100 will retrieve VLAN id during the T-connection negotiation. The UE 100 will tag the Ethernet with VLAN id and transport the tagged Ethernet frame on the uplink link to the CPE 110.

802.1x support for T-connection negotiation

Figure 12, box 10A illustrates the 802.1x procedures for T-connection negotiation bases on EAPoL extension for standalone-mode UE in accordance with an embodiment.

The UE 100, at step 10A1 sends EAPoL-announcement-req (rather than EAPoL-Start) to the relay CPE which acts as WLAN Access Ppoint, AP. The EAPoL-announcement-req includes 5G device type and/or PLMN id in the extension TLV. The CPE 110 supporting EAPoL extension will respond at step 10A2 with an EAPoL-announcement that includes 5G device support. If the CPE 110 supports tagged Ethernet transport, 5GVLAN id will also be included in the EAPoL-announcement.

Examples of the TLV definition that may be included in the EAPoL-announcement-request and EAPoL-announcement messages are illustrated below. Each TLV has TLV header and TLV content.

New example TLVs are proposed: 5G-device-type, 5G-device-support, PLMN id, and VLAN id. The TLV is TBD (required to be assigned by IANA) . Following tables provide details of  the TLVs definition. It is however understood that other mechanisms or definitions could be used to provide similar information to the UE.

5G-device-type TLV definition:

5G-device-support TLV definition:

VLAN id TLV definition:

PLMN id TLV definition: PLMN id value (string) as defined in [1]

DHCP support for T-connection negotiation

Figure 12, box 10B illustrates the DHCP procedures for T-connection negotiation based on DHCP option extension for standalone-mode UE 100 in accordance with an embodiment.

The standalone-mode UE 100 acts as DHCP client, and the CPE 110 acts as DHCP server

The UE 100 broadcasts at step 10B1 a DHCP DISCOVER message with a 5G device type and/or a PLMN id in option/60 extension. When the CPE 110 receives the message, if the CPE  supports the option extension, it will respond with a DHCP OFFER message at step 10B2 and includes a 5G device support in option/125. If the CPE 110 supports tagged Ethernet transport, then 5GVLAN id will be included as well in the option/125. The UE 100 will at step 10B3, send DHCP REQUEST message with same option/60 extension to the CPE, the DHCP ACK message comprising the same option/125 extension is returned to the UE 100 at step 10B4. The following provides further details of the proposed DHCP options:

DHCP definition

The DHCP option extension supports T-connection negotiation between standalone-mode UE 100 and relay CPE 110 as well as to support 5GVLAN configuration for CPE.

Definition for Option 125

This is Vendor-Identifying Vendor-Specific Information option. The following new sub-options used in the option 125 are introduced to indicate:

- PLMN id

- VLAN id

To support multi operators in the option, enterprise-number field will be used in the option format. Each operator will have corresponding enterprise number (assigned by IANA) set in enterprise-number.

Definition for Option 60

This is the Vendor class identifier option. Same format as option 125 is used for this option

Option format definition:

Sub-option format definition:

The following new sub-options used in the option 125:

- Device type

- PLMN id

To support multi operators in the option, enterprise-number field in the option format will be used. Each operator will have corresponding enterprise number (assigned by IANA) set in enterprise-number.

Sub options definition

Each operator may have its own definition of sub-option, otherwise, following common definition is applied.

D. CPE as a relay for the 5G Ethernet frame exchange

To support Ethernet frame exchange between the standalone-mode UE 100 and the FXIWF 140, the CPE 110 acting as a relay will support following behaviors:

- On the uplink direction towards fixed access network 130, the CPE 110 will receive Ethernet frame on the downstream port between the UE 100 and the CPE 110. For the untagged  Ethernet frame received, the CPE 110 may tag it with 5GVLAN id then forwards the 5GVLAN tagged Ethernet frame on its upstream port towards the fixed access network 130. For the 5GVLAN id tagged Ethernet frame received, the CPE 110 transparently forward it on its upstream port towards fixed access network.

- To tag Ethernet frame on the upstream port on the uplink direction, the CPE 110 may have 5GVLAN id which is related to the PLMN of the UE. The CPE 110 may retrieve the PLMN-specific 5GVLAN ID configuration by using the DHCP method as illustrated in Figure 12 (described above) .

- On the downlink direction, the CPE 110 receives the Ethernet frame on its upstream port from fixed access network 130. The Ethernet frame may be tagged with a 5GVLAN id. The CPE 110 will determine if the Ethernet frame is 5G Ethernet frame or not based on Ethernet type and/or 5GVLAN id. The CPE 110 will determine if the Ethernet frame is for standalone-mode UE 100 (which has already sent uplink an Ethernet frame through the CPE) . If the downlink Ethernet frame is for standalone-mode UE 100, the CPE will transparently forward it from its upstream port to its downstream port to the UE 100.

The Ethernet Tagging method is applied in the following cases:

- No 5G-specific Ethernet type is used in the Ethernet encapsulation.

- To support co-existence of 5G connectivity and legacy BNG connectivity, 5GVLAN tag is used to distinguish 5G Ethernet frame from other Ethernet frames.

- To support roaming UEs, at least two different 5GVLAN ids are used to tag Ethernet frame to distinguish roaming UEs or non-roaming UEs.

- To support UEs of multiple mobile operators, per PLMN 5GVLAN id is used to tag Ethernet frame to distinguish each operator

Referring to Figure 13, the 5G registration procedure between the UE 100/100’ and the 5G Core 150 over the established Nfu connection and N2 connection is illustrated in accordance with an embodiment. 5G registration procedures is used for user authentication and setup of NFu connection between the UE 100 and the FXIWF 140. The details of the 5G core related procedures are defined in 3GPP TS 23.502 V 1.1.1, June 2017. As shown, the wireless device/end device/UE 100/100’ initiates an NFU connection request at step 11D2. The NFU connection request may be a broadcast EAPoL-start message as shown in Figure 9 or a broadcast TLS Client-Hello message for  a secure L2 link (e.g., ETLS) as shown in Figure 10. When the UE 100/100’ receives an EAPoL-Announcement message or a TLS finish message establishing a secure L2 ETLS link with the FXIWF, and the message indicates UE 100/100’s hould authenticate with the 5G Core, the UE 100/100’ initiates the NAS registration procedure by sending a NAS registration request encapsulated by L2AP at step 11D3. The FXIWF 140 at step 11D4 determines from the L2AP message type that it is a NAS message and that the Ethernet frame type or VLANID of the Ethernet frame carrying the L2AP with the NAS message indicates a 5G mobile operator network, performs an AMF selection procedure. The AMF selection procedure is similar to the procedure described in 3GPP TS 23.501 and 3GPP TS 23.502.

At step 11D5, the FXIWF 140 decapsulates and sends the NAS registration message over the N2 interface towards the AMF 160 of the 5G core network 150.

Step 11D6 refers to the NAS registration and authentication procedure between the UE 100/100’ and the AMF 160 as per step 4 to step 20 of the procedure in fig. 4.2.2.2.2-1 of 3GPP TS 23.502 V.1.1.1, June 2017.

At step 11D7, the AMF 160 sends to the FXIWF 140 a NAS Registration Accept message over the N2 interface indicating that the user is successfully authenticated and registered in the 5G Core network. The FXIWF 140 may determine that the registration is completed at this point. At step 11D8, the FXIWF 140 forwards the NAS Registration Accept encapsulated in L2AP and sent over a tagged or untagged (secure –ETLS) Ethernet frame.

As per the 3GPP TS 23.502 procedure, the UE 100/100’ may send a NAS Registration complete message. The FXIWF 140 may alternatively determine that the registration is complete at this point. Once the registration is completed the NFu connection is also established between the UE 100/100’ and the FXIWF 140 as shown at step 11D10. Ethernet frames are now transmitted carrying control data which include other NAS messages or EAPoL messages and where NAS messages are further transmitted by FXIWF 140 over the N2 connection to the AMF 160. NAS messages are identified by the L2AP message type when transferred over the NFu connection.

After 5G registration is completed, both UE and AMF will enter RM-REGISTERED state as per registration management definition in 3GPP TS 23.501.

In CM-CONNECTED state with NFu connection established, both the UE 100/100’ and the FXIWF 140 may need to keep-alive the NFu connection. When the NFu connection is released, both the UE 100/100’ and the FXIWF 140 will change to CM-IDLE state. The UE in CM-IDLE  state may initiate re-establishment of the NFu connection when for example, the UE 100/100’ wants to send a NAS service request for a PDU session causing a state change to CM-CONNECTED state. In case the UE 100/100’ is in CM-IDLE state but the NFu connection is not broken, the FXIWF 140 may send an Ethernet frame to the UE 100/100’ to trigger re-establishment of the NFu connection.

Figure 14 illustrates a PDU connection establishment procedure in accordance with an embodiment. After the UE is registered into 5G core network (Figure 13) , the UE 100/100’ can initiate 5G PDU session over the fixed access network 130 with the 5G Core 150. The UE 100/100’ is required to re-establish NFu connection if it has been previously released.

L2AP as proposed herein is designed to support PDU connection setup on NFu interface for fixed access as well as transport of NAS signaling for end to end PDU session with the 5G Core network 150. L2AP PDU session procedure is used to negotiate the user payload transport method and to provide corresponding configuration information for the transport method. The information provided to UE 100/100’ may include: PDU connection id, vMAC, VLAN id assigned by the FXIWF.

L2AP supports the following functionalities in support of PDU connection management on the NFu interface

- PDU connection (establishment, modification and release) on fixed access.

- Per UE multiple PDU connections on the fixed access

- Multiple QoS flows on the fixed access

- Transport of e2e NAS signaling PDU session

Referring to Figure 14, an NFu connection is established between the UE 100/100’ and the FXWIF 140 at 12E. At step 12E1, the UE 100/100’ initiates a PDU connection/session with the 5G Core network 150 and sends an L2AP message of type NAS Transport and encapsulates a NAS PDU session establishment request message to the FXIWF 140. The FXIWF 140 determines from the L2AP message type that a NAS message is encapsulated, extracts the NAS PDU session establishment request and forwards it over the N2 interface to the AMF160 as shown at step 12E1a. At step 12E2, the AMF 160 executes the PDU session establishment procedure as specified in 3GPP TS 23.502 steps 2-9 of Figure 4.3.2.2.1-1. At step 12E2a, the AMF 160 sends over the N2 interface to the FXIWF 140 an N2 message comprising a NAS PDU session Establishment accept. The FXIWF 140 extracts the NAS message and forwards it to the UE 100/100’ in an L2AP bearer connection setup request message at step 12E2b. Other parameters to configure the PDU parameters  over the NFu interface may be included in the underlying L2AP message, e.g., PDU connection id, vMAC, VLAN id.

At step 12E3, the UE 100/100’ configures the PDU transport over the NFu based on the received parameters and establishes the PDU connection with the 5G Core and sends a NAS PDU session establishment complete encapsulated in an L2AP Bearer connection setup response. At step 12E3a, the FXIWF 140 extracts the NAS message and forwards it to the AMF 160 over the N2 interface. The AMF 160 executes at step 12E3b the known procedure specified in 3GPP TS 23.502 from steps 14 of Figure 4.3.2.2.1-1. At this point, an N3 connection is established between the FXIWF 140 and the UPF 180 in the 5G Core. The application data is transmitted over

1. the NFu interface tagged by a VLAN id, or vMAC as provided in the PDU connection parameters in the L2AP message, and

2. the N3 connection between the FXIWF 140 and the UPF 180.

E. L2AP protocol

the L2AP is designed to support 5G PDU session on fixed access as well as end to end 5G NAS signaling over fixed access. It can also be used to transport user plane payload if negotiated.

The purpose of PDU session is to establish/modify/release PDU connection in control plane and user plane connection with configured QoS flow.

E.1 L2AP Protocol description

E.1.1 Procedures

E.1.1.1 Bearer connection setup procedure

The purpose of bearer connection setup procedure is to establish bearer connection for user payload transport between the UE 100/101’ and the FXIWF 140. One or more QoS flows are configured in a bearer connection. The procedure is used either to establish the first bearer connection or to establish subsequent bearer connections. The procedure is initiated by the FXIWF, only after successful EAP authentication and authorization has been completed. The bearer refers to the NFu connection.

In addition, NAS signaling can be transported through messages in the procedure.

E.1.1.2 Bearer connection modify procedure

The purpose of bearer connection modify procedure is to modify bearer connection for user payload transport between the UE 100/100’ and the FXIWF 140. One or more QoS flows are modified (add/update/release) in a bearer connection. The procedure is initiated by FXWIF 140. In addition, NAS signaling can be transported through messages in the procedure.

E.1.1.3 PDU connection release procedure

The purpose of bearer connection release procedure is to release bearer connection for user payload transport between the UE and the FXIWF. The procedure can be initiated either by the UE or by FXWIF.

E.1.1.4 NAS transport procedure

This purpose of NAS transport procedure is to transport NAS from the UE to the FXIWF or from the FXIWF to the UE. The procedure does not provide in-sequence transport capability.

E.1.1.5 User payload transport procedure

This purpose of user payload transport procedure is to transport user payload from the UE to the FXIWF or from the FXIWF to the UE. The procedure does not provide in-sequence transport capability.

E.1.2 Message function definition

The following describe example embodiments providing definitions for some information elements required for fixed access of a UE 100/100’ to a 5G mobile operator network 150.

E.1.2.1 Bearer Connection Setup Request

This message is sent by the FXIWF 140 to setup a PDU connection and corresponding user plane with certain QoS flow (s)

E.1.2.2 Bearer Connection Setup Response

This message is the response of Bearer Connection Setup Request message.

E.1.2.3 Bearer Connection Modify Request

This message is sent by the FXIWF to create/update/delete QoS flow (s) on user plane of a PDU connection.

E.1.2.4 Bearer Connection Modify Response

This message is the response of Bearer Connection Modify Request message.

E.1.2.5 Bearer Connection Release Request

This message is sent by the UE or the FXIWF to release a PDU connection.

E.1.2.6 Bearer Connection Release Response

This message is the response of Bearer Connection Release Request message.

Information Element	Remark
Cause	Can refer to section 8.11 of WLCP [3]

E.1.2.7 Uplink NAS Transport

This message is sent by the UE to transport Uplink NAS message to the FXIWF.

E.1.2.8 Downlink NAS Transport

This message is sent by the FXIWF to transport downlink NAS message to the UE.

E.1.2.9 Uplink User Payload Transport

This message is sent by the UE to transport Uplink user payload to the FXIWF.

Information Element	Remark
User-Payload	Any IP or non-IP user traffic to transport

E.1.2.9 Downlink User Payload Transport

This message is sent by the FXIWF to transport downlink user payload to the UE.

Information Element	Remark
User-Payload	Any IP or non-IP user traffic to transport

E.1.3 Message format and IE definition

The L2AP message consists of the following elements:

a) Message type；

b) Identity；

c) other information elements, as required.

The organization of a message is illustrated in the example shown in the table below.

General message organization for L2AP message

E.1.3.1 Message type

The message type octet is the first octet in a L2AP message

E.1.3.2 Identity

The Identity octet is the second octet in a L2AP message. The Identity is used to match the request and corresponding response message. That is a response message copy the identify value from the received request message. For other messages, the Identity is set to value 0.

E.1.3.3 connection identifier

This identity is allocated by the FXIWF 140 and used to identify PDU connection between the UE 100/100’ and the FXIWF 140 for the control plane.

E.1.3.4 User plane transport information

E.1.3.5 AN QoS flow list

In the 5G core network 150, the QoS Flow is as specified in 3GPP TS 23.501 and is defined by QoS Flow Identifier (QFI) and QoS Flow parameters.

The AN QoS flow specify how a QoS Flow will be supported on the user plane transport in fixed access network. Currently, VLAN priority bits can be used to support traffic classes for Ethernet frames on NFu interface.

Each AN QoS Flow may comprise the following information

- QFI

- QoS Flow parameters

- VLAN priority [0…7]

E.1.3.6 QoS rule info

QoS rules information: provide the SDF (service data flow) template. i.e. the set of packet filters together with the SDF precedence and the corresponding QFI.

User payload transport methods on NFu interface

Three UP transport methods are used to transport user plane traffic on the NFu interface for a PDU session. Each method provides a different way to identify user plane or PDU connection/session. PDU connection identifier is necessary in order to support multiple PDU connections of the same user. The three methods are:

- Using L2AP for user payload transport: the L2AP protocol is used to transport user payload. The identity field in the L2AP header is used to identify PDU connection in user plane. Both IP and non-IP user payload can be transferred by using the L2AP method

- vMAC (Virtual MAC) method: raw user payload or L2AP encapsulated user payload is directly encapsulated in Ethernet frame. The FXIWF vMAC address is used to identify PDU connection in user plane. The FXIWF vMAC address is assigned to UE 100/100’ during L2AP procedures.

- VLAN method: raw user payload or L2AP encapsulated user payload is encapsulated in VLAN tagged Ethernet frame. The VLAN ID is used to identify PDN connection in user plane. The VLAN ID is assigned during L2AP procedures. Note that the VLAN ID is different from VLAN ID in control plane which is configured using method such as DHCP.

PDU types

Some embodiments provide user plane transport of different PDU type such as IP, Ethernet, and unstructured user data payload. See Figure 8a-8e for the different user plane type.

When non-Ethernet PDU payload is transported, the Ethernet layer acts as the underlying encapsulation layer, with MAC addresses of the UE 100/100’and the FXIWF 140 as the endpoint MAC addresses.

When Ethernet PDU payload is transported, the MAC address of the UE and of the remote host (not the FXIWF) are used as the endpoint MAC addresses.

When Ethernet PDU payload is transported using the ETLS method, the TLS layer of ETLS will indicate the Ethernet type of the original Ethernet payload (between the UE and the remote host) .

Figure 15 illustrates a flow chart of a UE method 1500 in accordance with some embodiments.

Step 1501: The UE (CPE-mode or standalone mode) executes the step of performing a registration and authentication with the 5G Core network/mobile operator network over the fixed access network via the FXIWF based on information received over the fixed access network and where the registration and authentication corresponds to Non-Access Stratum, NAS, messages transmitted encapsulated using a first ethernet encapsulation method.

The UE may receive the information indicating that registration and authentication is required with the 5G Core network in an EAPoL announcement message as a response to an EAPoL start broadcast message. The EAPoL-Start is a broadcast Ethernet message and the UE may either set the ethertype of the ethernet frame to indicate for example 5G, or tag the frame with a 5G VLAN id that may be obtained by the UE via DHCP.

Alternatively, The UE may receive the information indicating that registration and authentication is required with the 5G Core network in a ETLS: TLS-Finish message when completing the ETLS setup initiated by a TLS client-hello broadcast message.

A standalone-mode UE must first connect to a CPE by establishing a T-connection prior to broadcasting an EAPoL-Start or a TLS client-hello. The details of T-connection establishment using EAPoL or DHCP are described above.

UE sends and receives NAS messages for registration and authentication encapsulated in L2AP protocol messages defined herein. The L2AP messages are sent on secure Ethernet frames that may be VLAN tagged or that may include an Ethernet type indicating the device is a 5G device and for which interworking with 5G public mobile network or 5G core network is required.

Step 1502: upon successful registration and authentication with the mobile operator network, the UE executes the step of establishing a packet data unit session with the mobile operator network. The UE initiates sending a NAS PDU session establishment request encapsulated in an L2AP message. The PDU session is required for exchanging application data units (user data) over the fixed access network. Once the PDU session is established, the application data units are transmitted by the UE encapsulated using a second ethernet encapsulation method such as VLAN  tagging where the VLAN id is provided to the UE during the PDU session establishment procedure by the FXIWF.

Figure 15a is a flow chart illustrating detailed embodiment of CPE-mode UE operation as described in the embodiments herein.

Figure 15b is a flow chart illustrating detailed embodiment of standalone-mode UE operation as described in the embodiments herein.

Figure 16 illustrates an embodiment of a method 1600 performed at the FXIWF.

Step 1601: when the FXIWF receives an Ethernet broadcast message from the end device over a fixed access network wherein the Ethernet broadcast message is indicative that interworking with the mobile operator network is required, the FXIWF execute the steps of instructing the end device in a response message to perform registration and authentication with the mobile operator network. The indication that interworking with the mobile operator is either the ethertype of the ethernet frame indicating for example 5G, or the Ethernet frame is tagged with a 5G VLAN id that may be obtained by the UE via DHCP.

How FXIWF instructs the UE to register and authenticate depends on the received broadcast message. As previously described, if FXIWF received an EAPoL-start message, it sends an indicator in an EAPoL announcement message to instruct the UE to register with 5G Core network. if FXIWF received a TLA Client-Hello broadcast message, it sends an indicator in a TLS finish, at completion of the TLS session establishment to instruct the UE to register with 5G Core network. Step 1602: The FXIWF executes the step of relaying registration and authentication messages exchanged between the end device and the mobile operator network. Once the registration and authentication in the 5G core network is successfully completed, the FXIWF is notified at which point it will establish/activate the NFu Ethernet connection with the end device. NFu is used for UE interworking with the mobile operator network. The FXIWF provides the interworking by relaying NAS messages and application data between the NFu connection and the N2 interface (for NAS) and N3 interface (for application data) .

Step 1603: Upon establishment of a packet data unit, PDU, session for the end device, as illustrated in Figure 14, FXIWF may assign a VLAN id to tag the application data over the established PDU session and executes the step of relaying application data between the end device and the mobile operator network over the established Ethernet connection and over the N3 connection with the mobile operator network.

Figure 16a is a flow chart of a detailed operation of the FXIWF in accordance with some embodiments described herein.

Some embodiments of a UE 100/100’ will now be described with respect to Figures 17 and 18.

Figure 17 is a block diagram of an exemplary UE 100/100’ in accordance with some embodiments. UE 100/100’ includes one or more of a transceiver, processor, and memory. In some embodiments, the transceiver facilitates transmitting wireless or wired signals to and receiving wireless or wired signals from RAN node 120 and access node 135 (e.g., via transmitter (s) (Tx) , receiver (s) (Rx) and antenna (s) ) . The processor executes instructions to provide some or all of the functionalities described above as being provided by UE 100/100’ , and the memory stores the instructions executed by the processor. In some embodiments, the processor and the memory form processing circuitry.

The processor may include any suitable combination of hardware to execute instructions and manipulate data to perform some or all of the described functions of the UE 100/100’ , such as the functions of UE 100/100’ described above. In some embodiments, the processor may include, for example, one or more computers, one or more central processing units (CPUs) , one or more microprocessors, one or more application specific integrated circuits (ASICs) , one or more field programmable gate arrays (FPGAs) and/or other logic.

The memory is generally operable to store instructions, such as a computer program, software, an application including one or more of logic, rules, algorithms, code, tables, etc. and/or other instructions capable of being executed by a processor. Examples of memory include computer memory (for example, Random Access Memory (RAM) or Read Only Memory (ROM)) , mass storage media (for example, a hard disk) , removable storage media (for example, a Compact Disk (CD) or a Digital Video Disk (DVD) ) , and/or or any other volatile or non-volatile, non-transitory computer-readable and/or computer-executable memory devices that store information, data, and/or instructions that may be used by the processor of the UE 100/100’ .

Other embodiments of UE 100/100’ may include additional components beyond those shown in Figure 17 that may be responsible for providing certain aspects of the wireless device’s functionalities, including any of the functionalities described above and/or any additional functionalities (including any functionality necessary to support the solution described above) . As just one example, UE 100/100’ may include input devices and circuits, output devices, and one or  more synchronization units or circuits, which may be part of the processor. Input devices include mechanisms for entry of data into UE 100/100’ . For example, input devices may include input mechanisms, such as a microphone, input elements, a display, etc. Output devices may include mechanisms for outputting data in audio, video and/or hard copy format. For example, output devices may include a speaker, a display, etc.

Figure 18 is a block diagram of another exemplary UE 100/100’ in accordance with some embodiments. As illustrated, in some embodiments, the UE 100/100’ may comprise a series of modules (or units) configured to implement some or all of the functionalities of the UE 100/100’ described above.

It will be appreciated that the various modules may be implemented as combination of hardware and/or software, for instance, the processor, memory and transceiver (s) of UE 100/100’ shown in Figure 17. Some embodiments may also include additional modules to support additional and/or optional functionalities.

Some embodiments of a network node implementing FXIWF 140 will now be described with respect to Figures 19, 20 and 21.

Figure 19 is a block diagram of a network node implementing FXIWF in accordance with some embodiments. As illustrated, the network node implementing FXIWF 140 includes one or more processors 1920 (e.g., Central Processing Units (CPUs) , Application Specific Integrated Circuits (ASICs) , Digital Signal Processors (DSPs) , Field Programmable Gate Arrays (FPGAs) , and/or the like) to execute instructions to provide some or all of the functionalities described above, memory 1922 stores the instructions executed by the processor, and a network interface (s) 1924 to interface with mobile operator network and the UE. In some embodiments, the functionality of the network node 140 described above may be fully or partially implemented in software that is, e.g., stored in the memory 1922 and executed by the processor (s) 1920.

Figure 20 is a schematic block diagram that illustrates a virtualized embodiment of the network node 140 according to some embodiments of the present disclosure. As used herein, a “virtualized” network node is a network node in which at least a portion of the functionality is implemented as a virtual component (e.g., via a virtual machine (s) executing on a physical processing node (s) in a network (s) ) . As illustrated, the network node 140 includes one or more processing nodes 2026 coupled to or included as part of a network (s) 2028. Each processing node  2026 includes one or more processors 2030 (e.g., CPUs, ASICs, DSPs, FPGAs, and/or the like) , memory 2032, and a network interface 2034.

In this example, functions 2036 of the network node implementing FXIWF 140 described herein are implemented at the one or more processing nodes 2026 (e.g., distributed across multiple processing nodes 2026) in any desired manner. In some particular embodiments, some or all of the functions 2036 of the network node 140 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment (s) hosted by the processing node (s) 2026.

In some embodiments, a computer program including instructions which, when executed by the at least one processor 2020, 2030 causes the at least one processor 2020, 2030 to carry out the functionality of the network node 140 or a processing node 2026 according to any of the embodiments described herein is provided. In some embodiments, a carrier containing the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as the memory 2022, 2032) .

Figure 21 is a schematic block diagram of the network node 140 according to some other embodiments of the present disclosure. The network node 140 includes one or more modules 2100, each of which is implemented in software. The module (s) 2100 provide the functionality of the network node 140 described herein, e.g., with respect to Figures 9, 10, 13, 14, 16 and 16a.

The above-described embodiments are intended to be examples only. Alterations, modifications and variations may be effected to the particular embodiments by those of skill in the art without departing from the scope of the description.

ABBREVIATIONS

The present description may comprise one or more of the following abbreviation:

Claims (34)

1. A method for establishing a connection to a mobile operator network, the method performed at an end device and comprising:

   - performing registration and authentication with the mobile operator network over the fixed access network based on information received from the fixed access network and where the registration and authentication corresponds to Non-Access Stratum, NAS, messages transmitted encapsulated using a first ethernet encapsulation method； and

   - upon successful registration and authentication with the mobile operator network, establishing a packet data unit session with the mobile operator network for exchanging application data units over the fixed access network, wherein the application data units are transmitted encapsulated using a second ethernet encapsulation method.
2. The method of claim 1, wherein the information is received subsequent to broadcasting of an Extended Authentication Protocol over Local area network, EAPoL-start message in an Ethernet frame over the fixed access network where the Ethernet frame indicates that the end device should be connected to the mobile operator network.
3. The method of claim 1 and 2, wherein the information indicates registration and authentication should be performed with the mobile operator network and wherein the information is received in an EAPoL-announcement Ethernet message over the fixed access network.
4. The method of claim 1, wherein the information is received subsequent to broadcasting of a Transport Layer security, TLS Client-Hello message in an Ethernet frame over the fixed access network, and wherein the Ethernet frame indicates that the end device should be connected to the mobile operator network.
5. The method of claim 1, wherein the information indicates registration and authentication should be performed with the mobile operator network and wherein the information is received in a Transport Layer security over Ethernet, ETLS finish message.
6. The method of claim 1, wherein the mobile operator network is a fifth generation, 5G, mobile operator network.
7. The method of claims 2 and 6, wherein the Ethernet frame broadcasted over the fixed access network comprises an Ethernet frame type indicating at least one of communication with the 5G mobile operator network being desired or the end device is a 5G device.
8. The method of claim 1, wherein the first ethernet encapsulation method comprises encapsulating the NAS messages within a protocol message and wherein the protocol message is further encapsulated by a datagram transport layer security protocol, DTLS.
9. The method of claim 8, wherein the encapsulated NAS messages are transported natively over Ethernet identifying NAS messages as payload to transmit towards the mobile operator network.
10. The method of claim 8, wherein the encapsulated NAS messages are sent over an Ethernet frame tagged by a first virtual Local Area Network, VLAN identifier.
11. The method of claim 10, where in the first VLAN identifier is configured via Dynamic Host Control Protocol, DHCP.
12. The method of claim 10, where in the first VLAN identifier is provided in an EAPoL-announcement message in response to an EAPoL-start broadcast message.
13. The method of claim 1, wherein the first ethernet encapsulation method and the second ethernet encapsulation method are identical.
14. The method of claim 1, wherein the second ethernet encapsulation method encapsulating the application data corresponds to encapsulating the application data in a secure protocol and where the secure protocol is further encapsulated in an Ethernet frame tagged by a second virtual Local Area Network, VLAN identifier.
15. The method of claim 14, wherein the second VLAN identifier is obtained from the fixed access network following successful PDU session establishment with the mobile operator network.
16. A computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any one of embodiments 1 to 15.
17. A carrier containing the computer program of embodiment 16, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.
18. A method for establishing a connection to a mobile operator network for an end device, the method performed at an interworking entity and comprising:

    - upon receiving an Ethernet broadcast message from the end device over a fixed access network wherein the Ethernet broadcast message is indicative that interworking with the mobile operator network is required, instructing the end device to perform registration and authentication with the mobile operator network；

    - relaying registration and authentication messages exchanged between the end device and the mobile operator network and upon successful registration and authentication of the end device, establishing an Ethernet connection with the end device for interworking the end device with the mobile operator network；

    - upon establishment of a packet data unit, PDU, session for the end device, relaying application data between the end device and the mobile operator network over the established Ethernet connection.
19. The method of claim 18, wherein the mobile operator network is a fifth generation, 5G, mobile operator network.
20. The method of claim 18, wherein the Ethernet broadcast message is an Extended Authentication protocol over Local Area Network, EAPoL broadcast encapsulated in an ethernet frame which indicates at least one of communication with the 5G mobile operator network being desired or the end device is a 5G device.
21. The method of claim 18 and 20 wherein instructing the end device to perform registration and authentication with the mobile operator network comprises including an indication in an EAPoL-announcement message instructing the end device to perform registration and authentication with the mobile operator network.
22. The method of claim 18, wherein the step of relaying the registration and authentication messages further comprises:

    - receiving from the end device the registration and authentication messages encapsulated within a link layer protocol and further encapsulated in an Ethernet frame that comprises an indication that the registration and authentication messages are to be relayed to the mobile operator network；

    - decapsulating and sending the registration and authentication messages to the mobile operator network.
23. The method of claim 22 wherein the indication is a first virtual local area network, VLAN identifier.
24. The method of claim 18, wherein relaying application data between the mobile operator network and the end device comprises

    - receiving the application data from the mobile operator network and sending the application data encapsulated in an ethernet frame tagged with a second VLAN identifier.

    - receiving from the end device the application data encapsulated in an ethernet frame tagged with the second VLAN identifier and sending the application data to the mobile operator network.
25. The method of claims 18 and 24 wherein the method further comprises providing the second VLAN identifier for the established Ethernet connection with the end device.
26. A computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any one of embodiments 18 to 25.
27. A carrier containing the computer program of embodiment 26, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.
28. An end device (100, 100’) adapted to perform the method of any one of claims 1 to 15.
29. An end device (100, 100’) comprising

    a network interface；

    one or more processors； and

    memory comprising instructions executable by the one or more processors whereby the end device is configured to:

    - perform registration and authentication with the mobile operator network over the fixed access network based on information received from the fixed access network and where the registration and authentication corresponds to Non-Access Stratum, NAS, messages transmitted encapsulated using a first ethernet encapsulation method； and

    - upon successful registration and authentication with the mobile operator network, establish a packet data unit session with the mobile operator network for exchanging application data units over the fixed access network, wherein the application data units are transmitted encapsulated using a second ethernet encapsulation method.
30. The end device (100, 100’) of claim 29 configured to perform the method of any one of claims 2 to 15.
31. An end device (100, 100’) comprising

    a processing module operable to

    - perform registration and authentication with the mobile operator network over a fixed access network via a communication module based on information received over the fixed access network via the communication module and where registration and authentication are Non-Access Stratum messages are transmitted encapsulated using a first ethernet encapsulation method over the communication module；

    - upon successful registration and authentication with the mobile operator network, establish a packet data unit session with the mobile operator network for exchanging  application data units over the fixed access network through the communication module, wherein the application data units are transmitted over the communication module encapsulated using a second ethernet encapsulation method；

    the communication module operable to

    - send and receive Ethernet frames comprising NAS registration and authentication messages over the fixed access network；

    - send and receive Ethernet frames comprising other NAS messages and application data； a memory module operable to:

    - store registration and authentication related context information；

    - store context related to the PDU session.
32. A network entity (140) adapted to perform the method of any one of claims 18 to 25.
33. A network entity (140) comprising

    a network interface；

    one or more processors； and

    memory comprising instructions executable by the one or more processors whereby the end device is operable to:

    - upon receiving an Ethernet broadcast message from the end device over a fixed access network wherein the Ethernet broadcast message is indicative that interworking with the mobile operator network is required, instruct the end device to perform registration and authentication with the mobile operator network；

    - relay registration and authentication messages exchanged between the end device and the mobile operator network and upon successful registration and authentication of the end device, establish an Ethernet connection with the end device for interworking the end device with the mobile operator network； and

    - upon establishment of a packet data unit, PDU, session for the end device, relay application data between the end device and the mobile operator network over the established Ethernet connection.
34. A network entity (140) comprising:

    a processing module configured to:

    - upon receiving over a communication module an Ethernet broadcast message from the end device over a fixed access network wherein the Ethernet broadcast message is indicative that interworking with the mobile operator network is required, instruct the end device to perform registration and authentication with the mobile operator network；

    - relay over the communication module registration and authentication messages exchanged between the end device and the mobile operator network and upon successful registration and authentication of the end device, establish an Ethernet connection with the end device for interworking the end device with the mobile operator network； and

    - upon establishment of a packet data unit, PDU, session for the end device, relay over the communication module application data between the end device and the mobile operator network over the established Ethernet connection；

    the communicating module configured to:

    - send and receive NAS messages；

    - send and receive application data；

    the storage module configured to

    - store context related to the ethernet connection；

    - store context related to the PDU session.

Images