Method for authenticating to a mobile communication network
The EAP-5G process facilitates UE registration and authentication with the 5G core network over non-3GPP access networks, maintaining consistent message types and protocols, thus addressing the lack of support for non-3GPP access in 3GPP 5G networks.
Patent Information
- Application Number
- CN202311474652.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2017-05-08
- Publication Date
- 2025-07-15
- Estimated Expiration
- 2037-05-08
AI Technical Summary
In 3GPP 5G networks, UEs cannot register with 5G core network through non-3GPP access networks, and lack mechanisms to support UEs to authenticate and connect to 5G core networks via non-3GPP access networks.
Using the new EAP-5G process, the NAS signaling messages of the 3GPP access network are reused through the non-3GPP access network, and the EAP extension data packet is used for authentication and connection. The interoperability function is used to convert the EAP messages of the non-3GPP access network into messages that can be identified by the 3GPP access network, realizing the connection between the UE and the 5G core network.
It realizes authentication and connection between UEs through non-3GPP access networks to 5G core networks, ensures the same type of NAS connection as the 3GPP access network, supports untrusted and trusted non-3GPP access networks, and improves network interoperability and security.
Smart Images

Figure CN117412290B_ABST
Abstract
Description
[0001] This application is a divisional application of the application with the PCT application number PCT / EP2017 / 060959, international filing date of May 8, 2017, Chinese application number 201780090431.3, and invention title of "Method for authenticating to a mobile communication network", which entered the Chinese national phase on November 5, 2019. Technical Field
[0002] The subject matter disclosed herein generally relates to wireless communication, and more particularly, to authenticating and establishing a connection with a mobile communication network via a non-3GPP access network. Background Art
[0003] The following abbreviations and acronyms are defined herein, and at least some of them are referenced in the following description.
[0004] 3rd Generation Partnership Project (“3GPP”), Acknowledgement (“ACK”), Access and Mobility Management Function (“AMF”), Authentication and Key Agreement (“AKA”), Authentication Server Function (“AUSF”), Common Control Plane Network Function (“CCNF”), Control Plane Function (“CPF”), Data Network Name (“DNN”), Downlink (“DL”), Enhanced Mobile Broadband (“eMBB”), Evolved Node B (“eNB”), European Telecommunications Standards Institute (“ETSI”), Extensible Authentication Protocol (“EAP”), Hybrid Automatic Repeat reQuest (“HARQ”), Internet Key Exchange (“IKE”), Internet Key Exchange version 2 (“IKEv2”), Internet of Things (“IoT”), Internet Protocol (“IP”), Long Term Evolution (“LTE”), LTE-Advanced (“LTE-A”), Media Access Control (“MAC”), Machine Type Communication (“MTC”), Massive MTC (“mMTC”), NarrowBand (“NB”), Negative Acknowledgement (“NACK”) or (“NAK”), Network Function (“NF”), Network Slice Instance (“NSI”), Network Slice Selection Assistance Information (“NSSAI”), Network Slice Selection Function (“NSSF”), Network Slice Selection Policy (“NSSP”), Next Generation Node B (“gNB”), Non-Access Stratum (“NAS”), Primary Cell (“PCell”), Public Land Mobile Network (“PLMN”), Quality of Service (“QoS”), Radio Access Network (“RAN”), Radio Resource Control (“RRC”), Receive (“RX”), Session Management (“SM”), Session Management Function (“SMF”), Secondary Cell (“SCell”), Single NSSAI (“S-NSSAI”), Slice Differentiator (“SD”), Slice / Service Type (“SST”), Transmission Control Protocol (“TCP”), Transmission and Reception Point (“TRP”), Transmit (“TX”), Uplink Control Information (“UCI”), User Datagram Protocol (“UDP”), User Equipment / Device (Mobile Terminal) (“UE”), Uplink (“UL”), User Plane Function (“UPF”), Universal Mobile Telecommunications System (“UMTS”), Ultra-Reliable and Low-Latency Communication (“URLLC”), Wireless Local Area Network (“WLAN”) and Worldwide Interoperability for Microwave Access (WiMAX).
[0005] In a 3GPP 5G network, a UE may connect to a non-3GPP access network; however, there is no mechanism to support the UE to register (e.g., authenticate and connect) to the 5G core network via the non-3GPP access network. Summary of the Invention
[0006] Methods for authenticating and establishing a connection to a mobile communication network via a non-3GPP access network are disclosed. Apparatus and systems also perform the functions of the methods. A method for a UE to authenticate and establish a connection to a mobile communication network includes: providing a first transceiver for communicating with the mobile communication network via a first access network and a second transceiver for communicating with the mobile communication network via a second access network, and sending a request to start authentication via the second access network. The method includes: receiving, via the second access network, an Extensible Authentication Protocol ("EAP") request having a first extension type; and sending, via the second access network, an EAP response that includes the first extension type, a first parameter set, and a first message. Here, the first message is of the same type that can be used to establish a connection to the mobile communication network via the first access network.
[0007] A method for an interworking function to authenticate and establish a connection to a mobile communication network includes: receiving, via a first access network (e.g., a non-3GPP access network), a request to start authentication from a remote unit, and sending an EAP request having a first extension type to the remote unit. The method further includes receiving, via the first access network, an EAP response that includes the first extension type, a first parameter set, and a first message. Here, the first message is of the same type that can be used to establish a connection to the mobile communication network via another access network (e.g., a 3GPP access network) that uses a different communication protocol from the first access network. BRIEF DESCRIPTION OF THE DRAWINGS
[0008] A more specific description of the embodiments briefly described above will be presented by reference to specific embodiments shown in the drawings. It is understood that these drawings only show some embodiments and should not be considered as limiting the scope. The embodiments will be described and explained with additional features and details by using the drawings, in which:
[0009] Figure 1 is a schematic block diagram showing an embodiment of a wireless communication system for authenticating and establishing a connection to a mobile communication network;
[0010] Figure 2 is a block diagram showing an embodiment of a network architecture for authenticating and establishing a NAS connection to a mobile communication network;
[0011] Figure 3 is a schematic block diagram showing an embodiment of a remote device for authenticating and establishing a NAS connection to a mobile communication network via a non-3GPP access network;
[0012] Figure 4is a schematic block diagram showing an embodiment of an interworking function device for authenticating and establishing a NAS connection with a mobile communication network via a non-3GPP access network;
[0013] Figure 5A is a block diagram showing an embodiment of a network procedure for authenticating and establishing a NAS connection with a mobile communication network via an untrusted non-3GPP access network using EAP;
[0014] Figure 5B is Figure 5A a continuation of the network procedure shown in;
[0015] Figure 6A is a block diagram showing another embodiment of a network procedure for connecting to a mobile communication network via an untrusted non-3GPP access network and authenticating with the mobile communication network using EAP;
[0016] Figure 6B is Figure 6A a continuation of the network procedure shown in;
[0017] Figure 7A is a block diagram showing an embodiment of a network procedure for authenticating and establishing a NAS connection with a mobile communication network via an untrusted non-3GPP access network using EAP;
[0018] Figure 7B is Figure 5A a continuation of the network procedure shown in;
[0019] Figure 8 is a schematic flowchart showing an embodiment of a method for authenticating with a mobile communication network; and
[0020] Figure 9 is a schematic flowchart showing an embodiment of a method for authenticating with a mobile communication network. Detailed Embodiments
[0021] As will be appreciated by those skilled in the art, aspects of the embodiments can be embodied as a system, apparatus, method, or program product. Accordingly, the embodiments can take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software aspects and hardware aspects.
[0022] For example, the disclosed embodiments may be implemented as hardware circuits, including custom very large scale integration ("VLSI") circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. The disclosed embodiments may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, etc. As another example, the disclosed embodiments may include one or more physical or logical blocks of executable code, which may be organized, for example, as objects, procedures, or functions.
[0023] In addition, embodiments may take the form of a program product, which is embodied in one or more computer-readable storage devices storing machine-readable code, computer-readable code, and / or program code (hereinafter referred to as code). The storage device may be tangible, non-transitory, and / or non-transmission. The storage device may not embody a signal. In some embodiments, the storage device only accesses the code using a signal.
[0024] Any combination of one or more computer-readable media may be utilized. The computer-readable media may be a computer-readable storage medium. The computer-readable storage medium may be a storage device storing the code. The storage device may be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micro-mechanical, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.
[0025] More specific examples (non-exhaustive list) of storage devices will include the following: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory ("RAM"), a read-only memory ("ROM"), an erasable programmable read-only memory ("EPROM") or flash memory, a portable compact disc read-only memory ("CD-ROM"), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium may be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.
[0026] Throughout the specification, references to "one embodiment", "an embodiment", or similar language mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, the phrases "in one embodiment", "in an embodiment", and similar language that appear throughout this specification may, but do not necessarily, all refer to the same embodiment, but rather refer to "one or more but not all embodiments" unless otherwise expressly specified. Unless otherwise expressly specified, the terms "comprising", "including", "having", and variations thereof mean "including but not limited to". Unless otherwise expressly specified, a list of items does not imply that any or all of the items are mutually exclusive. Unless otherwise expressly specified, the terms "a", "an", and "the" also refer to "one or more".
[0027] Furthermore, the described features, structures, or characteristics of the embodiments can be combined in any suitable manner. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of the embodiments. However, those skilled in the relevant art will recognize that the embodiments can be practiced without one or more of the specific details or by using other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the embodiments.
[0028] Aspects of the embodiments are described below with reference to the schematic flowcharts and / or schematic block diagrams of methods, apparatuses, systems, and program products according to the embodiments. It will be understood that each block in the schematic flowcharts and / or schematic block diagrams, and combinations of blocks in the schematic flowcharts and / or schematic block diagrams, can be implemented by code. The code can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine, such that the instructions executed by the processor of the computer or other programmable data processing device create a means for implementing the functions / actions specified in the schematic flowcharts and / or schematic block diagrams.
[0029] The code can also be stored in a storage device that can direct a computer, other programmable data processing device, or other device to operate in a particular manner, such that the instructions stored in the storage device produce an article of manufacture including the instructions that implement the functions / actions specified in the schematic flowcharts and / or schematic block diagrams.
[0030] The code can also be loaded onto a computer, other programmable data processing apparatus, or other devices, so as to perform a series of operational steps on the computer, other programmable apparatus, or other devices to generate a computer-implemented process, such that the code executed on the computer or other programmable apparatus provides a process for implementing the functions / actions specified in the schematic flowchart and / or the schematic block diagram.
[0031] The schematic flowcharts and / or schematic block diagrams in the drawings illustrate the architecture, functions, and operations of possible implementations of apparatuses, systems, methods, and program products according to various embodiments. In this regard, each block in the schematic flowchart and / or schematic block diagram may represent a module, segment, or portion of code, including one or more executable instructions for implementing the specified logical function.
[0032] It should also be noted that in some alternative implementations, the functions noted in the blocks may occur out of the order noted in the drawings. For example, depending on the functions involved, two consecutive blocks shown may actually be executed substantially simultaneously, or sometimes may be executed in the reverse order. Other steps and methods equivalent in function, logic, or effect to one or more blocks or portions thereof shown in the drawings may be envisioned.
[0033] The description of elements in each figure may refer to the elements in the previous figures. In all the drawings, the same numerals refer to the same elements, including alternative embodiments of the same elements.
[0034] To support the registration (e.g., connection) of a UE to a 5G core network via a non-3GPP access network, the present disclosure describes systems, methods, and apparatuses using a new EAP authentication method (referred to herein as the "EAP-5G" procedure), which allows a UE to register to a 5G core network via a non-3GPP access network by reusing the same message types (e.g., NAS signaling) used for registering a UE to a 5G core network via a 3GPP (radio) access network. The EAP-5G procedure uses a 3GPP-specific EAP extension data packet. Herein, the vendor ID of the EAP extension data packet points to 3GPP, while the vendor type identifies the EAP-5G procedure, and the vendor data packet contains messages defined for the EAP-5G procedure.
[0035] Figure 1FIG. 100 depicts a wireless communication system for authenticating and establishing a connection with a mobile communication network, e.g., via a non-3GPP access network, in accordance with an embodiment of the present disclosure. In one embodiment, the wireless communication system 100 includes a plurality of remote units 105, at least one 3GPP base station unit 110, a 3GPP radio access network (“RAN”) 111 including the at least one 3GPP base station unit 110, a 3GPP communication link 115, at least one non-3GPP access network (“AN”) 120 (herein, the depicted non-3GPP AN 120 includes at least one WLAN access point (“AP”) 121), and a non-3GPP communication link 125. Although Figure 1 a specific number of remote units 105, non-3GPP ANs 120, WLAN APs 121, WLAN 3GPP communication links 115, mobile radio access networks 120, 3GPP base station units 110, 3GPP RANs 111, 3GPP communication links 115, non-3GPP ANs, WLAN APs 121, and non-3GPP communication links 125 are depicted in FIG. 100, those skilled in the art will recognize that any number of remote units 105, non-3GPP ANs 120, WLAN APs 121, WLAN 3GPP communication links 115, mobile radio access networks 120, 3GPP base station units 110, 3GPP RANs 111, 3GPP communication links 115, non-3GPP ANs, WLAN APs 121, and non-3GPP communication links 125 may be included in the wireless communication system 100.
[0036] In one implementation, the wireless communication system 100 complies with a 5G system or a subsequent cellular network system specified in 3GPP specifications. However, more generally, the wireless communication system 100 may implement some other open or proprietary communication networks, such as LTE, LTE-A Advanced, or WiMAX, as well as other networks. The present disclosure is not intended to be limited to embodiments of any particular wireless communication system architecture or protocol.
[0037] In one embodiment, the remote unit 105 may include a computing device, such as a desktop computer, a laptop computer, a personal digital assistant (“PDA”), a tablet computer, a smart phone, a smart TV (e.g., a TV connected to the Internet), a smart appliance (e.g., an appliance connected to the Internet), a set-top box, a gaming console, a security system (including security cameras), an in-vehicle computer, a network device (e.g., a router, a switch, a modem), etc. In some embodiments, the remote unit 105 includes a wearable device, such as a smart watch, a fitness band, an optical head-mounted display, etc. Further, the remote unit 105 may be referred to as a subscriber unit, a mobile device, a mobile station, a user, a terminal, a mobile terminal, a fixed terminal, a subscriber station, a UE, a user terminal, a device, or other terms used in the art. The remote unit 105 may communicate directly with one or more of the 3GPP base station units 110 via uplink (“UL”) communication signals and downlink (“DL”) communication signals. Further, the UL communication signals and the DL communication signals may be transmitted over the 3GPP communication link 115. Similarly, the remote unit 105 may communicate with one or more WLAN APs 121 in the non-3GPP AN 120 via UL communication signals and DL communication signals transmitted over the non-3GPP AN 120. It should be noted that the 3GPP base station units 110 and the WLAN APs 121 use different communication standards, and the 3GPP communication link 115 and the non-3GPP communication link 125 transmit messages following different communication protocols, for example, at lower layers such as the MAC layer and the PHY layer.
[0038] The 3GPP base station units 110 may be distributed over a geographical area. In certain embodiments, the 3GPP base station units 110 may also be referred to as access terminals, base stations, base nodes, Node Bs, eNBs, gNBs, home Node Bs, relay nodes, femtocells, devices, or any other terms used in the art. The 3GPP base station units 110 are part of the 3GPP radio access network (“RAN”) 111 and may include one or more controllers communicatively coupled to one or more corresponding 3GPP base station units 110. Although these and other elements of the radio access network are not shown, they are well known to those of ordinary skill in the art. The 3GPP base station units 110 are connected to the mobile core network 135 via the 3GPP RAN 111.
[0039] The 3GPP base station unit 110 can serve a number of remote units 105 within a service area (e.g., a cell or a cell sector) via a wireless communication link. The 3GPP base station unit 110 can communicate directly with one or more of the remote units 105 via communication signals. Generally, the 3GPP base station unit 110 transmits DL communication signals in the time domain, frequency domain, and / or spatial domain to serve the remote units 105. Additionally, the DL communication signals can be transmitted over the 3GPP communication link 115. The 3GPP communication link 115 can be any suitable carrier in the licensed or unlicensed radio spectrum. The 3GPP communication link 115 facilitates communication between one or more of the remote units 105 and / or one or more of the 3GPP base station units 110.
[0040] The non-3GPP AN 120 can be distributed over a geographical area. As Figure 1 shown, the non-3GPP AN 120 is connected to the mobile core network 135 via the interworking function 130. In some embodiments, the non-3GPP AN 120 can be controlled by the operator of the mobile core network 135 and can directly access the mobile core network 135. Such a non-3GPP AN deployment is referred to as a "trusted non-3GPP AN". When operated by a 3GPP operator, the non-3GPP AN 120 is considered "trusted" and supports certain security features, such as 3GPP-based authentication and strong air interface encryption. In some embodiments, the interworking function 130 can be included within (e.g., co-located with) the trusted non-3GPP AN. In one embodiment, the interworking function 130 can be a component of the WLAN AP 121 or other non-3GPP access points within the trusted non-3GPP AN 120.
[0041] In other embodiments, the non-3GPP AN 120 is not controlled by the operator of the mobile core network 135 and thus cannot directly access the mobile core network 135. Such a non-3GPP access network deployment is referred to as an "untrusted" non-3GPP AN. For example, public hotspots deployed in shopping malls, coffee shops, and other public areas are considered untrusted. Here, the untrusted non-3GPP AN 120 relies on a data network (such as the Internet) to connect to the mobile core network 135. The mobile core network 135 can provide services to the remote units 105 via the non-3GPP AN 120, as described in more detail herein.
[0042] The WLAN AP 121 is an example of a non-3GPP access point and allows the remote unit 105 to connect to (e.g., access) the non-3GPP AN 120. Each WLAN AP 121 can serve several remote units 105 through a service area. Generally speaking, the service area of the WLAN AP 121 is smaller than that of the 3GPP base station unit 110. The WLAN AP 121 can directly communicate with one or more remote units 105 by receiving UL communication signals and transmitting DL communication signals to serve the remote units 105 in the time domain, frequency domain, and / or spatial domain. Both the DL communication signal and the UL communication signal are transmitted through the non-3GPP communication link 125. The WLAN AP 121 can use the unlicensed radio spectrum for communication.
[0043] In one embodiment, the mobile core network 135 is a 5G core network (“5GC”), which can be connected to data networks such as the Internet and private data networks, as well as other data networks. In some embodiments, the remote unit 105 communicates with a remote host via a network connection to the mobile core network 135. Each mobile core network 135 belongs to a single public land mobile network (“PLMN”). The present disclosure is not intended to be limited to the implementation of any specific wireless communication system architecture or protocol.
[0044] The mobile core network 135 includes several network functions (“NF”). In certain embodiments, the mobile core network may support one or more network slices. As shown, the mobile core network 135 includes at least one access and mobility management function (“AMF”) 140, at least one session management function (“SMF”) 145, at least one user plane function (“UPF”) 150, and at least one authentication server function (“AUSF”) 155. Although a specific number of NFs are depicted in Figure 1 the mobile core network 135 may include any number of NFs, as will be appreciated by those skilled in the art.
[0045] The AMF 140 and the SMF 145 are examples of the control plane network functions of the mobile core network 135. The control plane network functions provide services such as UE registration, UE connection management, UE mobility management, data session management, etc. The UPF 150 provides user plane (e.g., data) services to the remote unit 105. For example, the UPF 150 manages the data connection between the remote unit 105 and the remote host. The AUSF 155 authenticates the certificate of the remote unit 105 to find services in the mobile core network 135. The AUSF 155 can support multiple authentication methods, including NAS authentication.
[0046] Although depicted as being external to the mobile core network 135, in some embodiments, the interworking entity 130 may be located within the mobile core network 135. For example, an instance of the interworking function 130 located within the mobile core network 135 may provide interworking to an untrusted non-3GPP AN 120. The interworking function 130 provides interworking between the non-3GPP AN 120 and the mobile core network 135, thereby converting the non-3GPP access network protocol into messages sent over the N2 interface and the N3 interface. Here, the interworking function 130 may perform the AAA function for the non-3GPP AN 120 to convert the 3GPP authentication messages used by the mobile core network 135 into authentication messages used by the non-3GPP AN 120 (e.g., EAP messages).
[0047] Figure 2 A network architecture 200 is depicted for authenticating and establishing a NAS connection with a mobile communication network, e.g., via a non-3GPP access network, according to an embodiment of the present disclosure. The network architecture 200 may be a simplified embodiment of the wireless communication system 100. As shown, the network architecture 200 includes a UE 205, a 3GPP(R) AN 210, a non-3GPP AN 215, a non-3GPP interworking function (“N3IWF”) 220, and a core network 225. As shown, the UE 205 is capable of accessing the core network 225 using one or both of the 3GPP(R) AN 210 and the non-3GPP AN 215. Here, the core network 225 includes an AMF 140, a UPF 145, and an AUSF 150. Both the 3GPP(R) AN 210 and the N3IWF 220 communicate with the AMF 140 using the “N2” interface and communicate with the UPF 150 using the “N3” interface.
[0048] The UE 205 may be an embodiment of the remote unit 105, the 3GPP(R) AN 210 may be an embodiment of the 3GPP RAN 111, and the non-3GPP AN 215 may be an embodiment of the non-3GPP AN 120, as described above. The core network 225 may be an embodiment of the mobile core network 135 discussed above. Additionally, the N3IWF 220 may be an embodiment of the interworking function 130 discussed above. Here, the N3IWF 220 is depicted as being external to the non-3GPP AN 215 and the core network 225. In other embodiments, the N3IWF 220 may be collocated with the non-3GPP AN 215 (e.g., if the non-3GPP AN 215 is a trusted non-3GPP AN 215) or located within the core network 225.
[0049] In the network architecture 200, the UE 205 can establish a connection with the core network 225 via the 3GPP(R) AN 210 or the non-3GPP AN 215. When using the 3GPP(R) AN 210, the UE 205 sends the NAS message 240 transmitted via RRC to the 3GPP(R) AN 210 / receives the NAS message from the 3GPP(R) AN 210, and the 3GPP(R) AN 210 sends / receives the corresponding NAS message 235 transmitted via N2-AP. Additionally, when using the non-3GPP AN 215, the UE 205 sends an EAP message (e.g., the NAS message 230 transmitted via EAP-5G) to the core network 225. The N3IWF 220 converts the NAS message 230 transmitted via EAP-5G into the NAS message 235 transmitted via N2-AP. Using the NAS message encapsulated in the EAP-5G data packet, the UE 205 authenticates to the core network 225. The result of successful authentication is the establishment of a NAS connection between the UE 205 and the core network 225 via the non-3GPP AN 215.
[0050] Here, the NAS message 235 transmitted via N2-AP sent by the N3IWF 220 to the core network 225 has the same form (e.g., the same type) as the NAS message 240 transmitted via 3GPP. Thus, from the perspective of the core network 225 (including the AMF 140), messages of the same type (e.g., the NAS message 235 transmitted via N2-AP) are received from the 3GPP(R) AN210 and from the N3IWF 220 (but not necessarily with the same values). Here, the core network 225 can interpret and operate on the NAS message 235 transmitted via N2-AP received from the N3IWF 220 in the same manner as the interpretation and operation of the NAS message 235 transmitted via N2-AP received from the 3GPP(R) AN 210.
[0051] Figure 3 An embodiment of a remote device 300 according to an embodiment of the present disclosure is depicted, which can be used to authenticate and establish a connection with a mobile communication network, for example, via a non-3GPP access network. The remote device 300 can be an embodiment of the remote unit 105 and / or the UE 205. Additionally, the remote device 300 includes a processor 305, a memory 310, an input device 315, a display 320, a first transceiver 325, and a second transceiver 330. In some embodiments, the input device 315 and the display 320 are combined into a single device, such as a touch screen. In certain embodiments, the remote unit 105 may not include any input device 315 and / or display 320.
[0052] The first transceiver 325 (“Transceiver-1”) communicates with a mobile communication network (e.g., a core network) via a first access network, while the second transceiver 330 (“Transceiver-2”) communicates with the mobile communication network via a second access network. Each of the first access network and the second access network facilitates communication between the mobile core network 135 and the remote device 300. Herein, the first access network uses a different communication protocol than the second access network. In one embodiment, the first access network is a 3GPP RAN 111 or a 3GPP(R)AN 210, and the second access network is a non-3GPP AN 120, a non-3GPP AN 215, or other non-cellular access network. Herein, the first access network may use a first communication (e.g., Media Access Control (“MAC”) layer and / or Physical (“PHY”) layer) protocol, such as a 3GPP New Radio (“NR”) protocol, while the second access network may use a second communication (e.g., MAC layer and / or PHY layer) protocol, such as the IEEE 802.11 protocol family. In other embodiments, the first access network and the second access network may be other types of access networks, and the first access network is a different access network than the second access network (and supports different communication protocols). Each transceiver 325, 330 may include at least one transmitter and at least one receiver. Additionally, transceivers 325, 330 may each support at least one network interface for communicating with the access network and / or the core network, such as a “Uu” interface for communicating with a 3GPP base station unit 110 or a 5G(R)AN 210.
[0053] In one embodiment, the processor 305 may include any known controller capable of executing computer-readable instructions and / or capable of performing logical operations. For example, the processor 305 may be a microcontroller, a microprocessor, a central processing unit (“CPU”), a graphics processing unit (“GPU”), a co-processing unit, a field-programmable gate array (“FPGA”), or a similar programmable controller. In some embodiments, the processor 305 executes instructions stored in the memory 310 to perform the methods and routines described herein. The processor 305 is communicatively coupled to the memory 310, the input device 315, the display 320, the first transceiver 325, and the second transceiver 330.
[0054] In some embodiments, the processor 305 sends a request to start authentication via the second access network. In one embodiment, the processor 305 sends a request to connect to the mobile communication network via an untrusted non-3GPP access network and start authentication via the untrusted non-3GPP access network. In another embodiment, the processor 305 sends a request to start authentication via a trusted non-3GPP access network.
[0055] In some embodiments, the second access network is a non-3GPP access network, such as a WLAN or hotspot. In one embodiment, the connection request is embedded within an IKEv2 message (such as an IKE Authentication (“IKE_AUTH”) request). The connection request identifies the remote device 300, for example, using a permanent or temporary UE identifier. The processor 305 may send the request to an interworking function, such as the N3IWF 220.
[0056] In response to the connection request, the processor 305 may receive an Extensible Authentication Protocol (“EAP”) request with a first extension type via the second (e.g., non-3GPP) access network. Here, the first extension type may be a 3GPP-specific type, such as an EAP-5G extension type. This indicates to the processor 305 to start a specific authentication method that requires the use of NAS messages within EAP-5G messages. In one embodiment, the EAP request with the first extension type corresponds to a 5G start message. The EAP request may also be embedded within an IKEv2 message (such as an IKE-AUTH response).
[0057] In response to the EAP request, the processor 305 may send (via the second access network) an EAP response that includes the first extension type, a first parameter set, and a first message. Here, the first message is of the same type that can be used to establish a connection with the mobile communication network via the first access network. For example, the first message may be a non-access stratum (“NAS”) registration request. In the case where the mobile communication network is a 5G network, the first message may be a 5G-NAS registration request. Here, the result of successful authentication is the establishment of a NAS connection between the remote device 300 and the 5G core network via non-3GPP access. It should be noted that the same NAS message (a) encapsulated in RRC and N2-AP or (b) encapsulated in EAP-5G and N2-AP is sent to the mobile communication network (e.g., sent to the AMF in the core network), as discussed above. Thus, the same type of NAS connection as typically established via a 3GPP access network is established via a non-3GPP access network.
[0058] In some embodiments, the first parameter set includes 3GPP access network parameters ("AN-Params"), and the interworking function will use the 3GPP access network parameters to select an AMF within the mobile core network 135. Here, the AN-params can include one or more S-NSSAIs (slice information), DNN (data network name), SSC mode (session and service continuity), etc. Then, the interworking function forwards the first message to the selected AMF. In some embodiments, the processor 305 also receives one or more additional EAP requests and sends an equal number of EAP responses. Here, each of the additional EAP requests and responses encapsulates at least one NAS message. In this way, NAS messages can be used to identify and authenticate the remote device 300. In addition, the processor 305 establishes a NAS connection with the mobile communication network via the additional EAP requests and responses.
[0059] In some embodiments, the processor 305 can establish a secure IPsec connection with the interworking function (e.g., N3IWF 220). Then, the processor 305 exchanges NAS messages with the mobile communication network via the secure IPsec connection. The processor 305 can establish a secure IPsec connection in response to the completion of the authentication process.
[0060] In some embodiments, the processor 305 can determine that it does not support the first extension type (e.g., does not support EAP-5G and 5G-NAS protocols). Here, the processor 305 sends an EAP response via the second access network by sending an EAP response that includes the first extension type and a list of authentication methods supported by the device for authentication to the mobile communication network via the second access network. In such an embodiment, the processor 305 uses one of the supported authentication methods to perform an authentication process with the mobile communication network.
[0061] In some embodiments, although the processor 305 determines that the remote device 300 supports the first extension type (e.g., supports the EAP-5G protocol), it does not support the desired 5G-NAS message type (e.g., does not support the 5G-NAS protocol associated with the desired message type). Here, the processor 305 sends an EAP response via the second access network by sending an EAP response that includes the first extension type and one or more additional parameters available to the interworking function (e.g., an EAP "5G-info" message). Then, the interworking function can generate a message of the desired message type (e.g., a 5G-NAS registration request message) on behalf of the remote device 300. In some embodiments, the interworking function includes an (optional) indication in the 5G-NAS message that the message is created by the interworking function on behalf of the remote device 300.
[0062] In a case where the remote device 300 supports the EAP-5G protocol but does not support the 5G-NAS protocol (e.g., does not support the 5G-NAS protocol associated with the desired message type), the processor 305 may send an EAP information message (e.g., an EAP-5G-info message) to an interworking function that includes additional parameters (e.g., AN-params) to assist the interworking function, for example, when selecting an AMF in the 5G core network.
[0063] In one embodiment, the memory 310 is a computer-readable storage medium. In some embodiments, the memory 310 includes a volatile computer storage medium. For example, the memory 310 may include RAM, which includes dynamic RAM ("DRAM"), synchronous dynamic RAM ("SDRAM"), and / or static RAM ("SRAM"). In some embodiments, the memory 310 includes a non-volatile computer storage medium. For example, the memory 310 may include a hard disk drive, flash memory, or any other suitable non-volatile computer storage device. In some embodiments, the memory 310 includes both a volatile computer storage medium and a non-volatile computer storage medium. In some embodiments, the memory 310 stores data related to authentication to a mobile communication network, such as storing AN-params, UE ID, security keys, etc. In some embodiments, the memory 310 also stores program code and related data, such as an operating system or other controller algorithms that run on the remote unit 105 and one or more software applications.
[0064] In one embodiment, the input device 315 may include any known computer input device, including a touch panel, buttons, a keyboard, a stylus, a microphone, etc. In some embodiments, the input device 315 may be integrated with the display 320, such as a touch screen or a similar touch-sensitive display. In some embodiments, the input device 315 includes a touch screen such that text can be input using a virtual keyboard displayed on the touch screen and / or by handwriting on the touch screen. In some embodiments, the input device 315 includes two or more different devices, such as a keyboard and a touch panel.
[0065] In one embodiment, the display 320 may include any known electronically controllable display or display device. The display 320 may be designed to output visual, auditory, and / or tactile signals. In some embodiments, the display 320 includes an electronic display capable of outputting visual data to a user. For example, the display 320 may include, but is not limited to, an LCD display, an LED display, an OLED display, a projector, or a similar display device capable of outputting images, text, etc. to a user. As another non-limiting example, the display 320 may include a wearable display, such as a smartwatch, smart glasses, a heads-up display, etc. In addition, the display 320 may be a component of a smartphone, a personal digital assistant, a television, a desktop computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, etc.
[0066] In certain embodiments, the display 320 includes one or more speakers for generating sound. For example, the display 320 may generate an audible alarm or notification (e.g., a beep or a chime). In some embodiments, the display 320 includes one or more haptic devices for generating vibration, movement, or other tactile feedback. In some embodiments, all or part of the display 320 may be integrated with the input device 315. For example, the input device 315 and the display 320 may form a touchscreen or a similar touch-sensitive display. In other embodiments, the display 320 may be located near the input device 315.
[0067] The transceiver 325 communicates with the mobile communication network via a first access network, while the second transceiver 330 communicates with the mobile communication network via a second access network. As discussed above, the first access network may be an embodiment of 3GPP RAN 111 and / or 3GPP(R)AN 210, while the second access network is an embodiment of a non-3GPP access network 120 and / or non-3GPP AN 215. In other embodiments, the first access network and the second access network may be other types of access networks, and the first access network is a different type of access network from the second access network.
[0068] Transceivers 325 and 330 operate under the control of processor 305 to send messages, data, and other signals, and also to receive messages, data, and other signals. For example, processor 305 may selectively activate one or both of transceivers 325, 330 (or portions thereof) at a particular time to send and receive messages. Transceiver 325 may include one or more transmitters and one or more receivers for communicating via a first access network. Similarly, transceiver 330 may include one or more transmitters and one or more receivers for communicating via a second access network. As discussed above, first transceiver 325 and second transceiver 330 may support one or more network interfaces for communicating with a mobile communication network.
[0069] Figure 4 An embodiment of an interworking device 400 according to an embodiment of the present disclosure is depicted. The interworking device 400 may be used, for example, to authenticate a remote unit via a non-3GPP access network and establish a connection with a mobile communication network. The interworking device 400 may be an embodiment of the interworking function 130 and / or the N3IWF 220. Additionally, the interworking device 400 includes a processor 405, a memory 410, an input device 415, a display 420, a first transceiver 425, and a second transceiver 430. In some embodiments, the input device 415 and the display 420 are combined into a single device, such as a touchscreen. In certain embodiments, the interworking device 400 may not include any input device 415 and / or display 420.
[0070] The first transceiver 425 (“transceiver-1”) allows the interworking device 400 to communicate with the remote unit 105 and / or the UE 205 via a non-3GPP access network. The second transceiver 430 (“transceiver-2”) allows the interworking device 400 to communicate with other network elements within the mobile communication network, such as the AMF 140 and / or the UPF 145. Each of the first transceiver 425 and the second transceiver 430 may include at least one transmitter and at least one receiver. Additionally, the transceivers 425, 430 may each support at least one network interface, such as an “N2” interface for communicating with the AMF and an “N3” interface for communicating with the SMF.
[0071] In one embodiment, processor 405 may include any known controller capable of executing computer-readable instructions and / or capable of performing logical operations. For example, processor 405 may be a microcontroller, a microprocessor, a central processing unit (“CPU”), a graphics processing unit (“GPU”), an auxiliary processing unit, a field programmable gate array (“FPGA”), or a similar programmable controller. In some embodiments, processor 405 executes instructions stored in memory 410 to perform the methods and routines described herein. Processor 405 is communicatively coupled to memory 410, input device 415, display 420, first transceiver 425, and second transmitter 330.
[0072] In some embodiments, processor 405 receives a request to initiate authentication from a remote unit via a first access network. In certain embodiments, the first access network is a non-3GPP access network, such as a WLAN or hotspot. In one embodiment, the connection request identifies the remote unit, for example, using a permanent or temporary UE identifier. In some embodiments, processor 405 receives a request to connect to a mobile communication network via an untrusted non-3GPP access network and initiate authentication. In another embodiment, processor 405 receives a request to initiate authentication via a trusted non-3GPP access network.
[0073] In response to the connection request, processor 405 may send an Extensible Authentication Protocol (“EAP”) request with a first extension type to the remote unit. Here, the first extension type may be a 3GPP-specific type, such as an EAP-5G extension type. In certain embodiments, the EAP request may be embodied as an IKEv2 message, such as an IKE Authentication (“IKE_AUTH”) response. In certain embodiments, the request from the remote unit to authenticate to the mobile communication network includes an indication that the remote unit supports EAP messaging using the first extension type. Here, the sending of the EAP request with the first extension type by processor 405 occurs in response to the indication.
[0074] In some embodiments, the processor 405 may receive an EAP response via a first access network (e.g., a non-3GPP access network). Here, the EAP response may include a first extension type (e.g., an EAP-5G extension type), a first parameter set (e.g., AN-params), and a first message. In such an embodiment, the first message is of the same type as the message that can be used to establish a connection with the mobile communication network via another access network (e.g., a 3GPP access network), where the other access network uses a different communication protocol from the first access network. In one embodiment, the first message is a non-access stratum (“NAS”) registration request, such as a 5G-NAS registration request that can be used to establish a connection via a 3GPP access network. Here, the result of successful authentication is to establish a NAS connection between the remote unit and the 5G core network via non-3GPP access. It should be noted that the same NAS message (a) encapsulated in RRC and N2-AP or (b) encapsulated in EAP-5G and N2-AP is sent to the mobile communication network (e.g., sent to the AMF in the core network), as discussed above. Thus, the same type of NAS connection as that typically established via a 3GPP access network is established via the non-3GPP access network.
[0075] In some embodiments, the processor 405 sends one or more additional EAP requests and receives an equal number of EAP responses, where each of the additional EAP requests and responses encapsulates at least one NAS message. In some embodiments, the processor 405 also establishes a secure IPsec connection with the remote unit. Thereafter, the processor 405 may relay NAS messages between the remote unit and the mobile communication network via the secure IPsec connection. In other embodiments, the remote unit establishes a NAS connection with the mobile communication network via the additional EAP requests and responses.
[0076] In some embodiments, the processor 405 receives an indication that the remote unit does not support the first extension type (e.g., the EAP-5G extension type). Here, receiving an EAP response via the first access network may include: receiving an EAP response that includes the first extension type and a list of authentication methods supported by the remote unit for authentication to the mobile communication network via a second access network. In response, the processor 405 may forward the list of authentication methods supported by the remote unit to the mobile communication network.
[0077] In some embodiments, the processor 405 may send NAS messages to the mobile communication network on behalf of the remote unit and (optionally) send an indication that the NAS message is created by the device on behalf of the UE. The NAS message may be one or more of the following: a NAS registration request, a NAS registration request including a session establishment request, and a NAS service request. In one embodiment, the processor 405 may send an EAP request without a first extension type to the remote unit.
[0078] In some embodiments, the processor 405 receives an indication that the remote unit does not support the desired message type (e.g., 5G-NAS message type). For example, the remote unit may support the EAP-5G protocol (e.g., associated with the EAP-5G extension type), but does not support the 5G-NAS protocol associated with the desired message type. Here, the EAP response may include a first extension type (e.g., EAP-5G extension type) and one or more additional parameters (e.g., AN-params). Here, the processor generates a message with the desired message type (e.g., 5G-NAS message) on behalf of the remote unit. In some embodiments, the processor 405 includes the following indication in the 5G-NAS message: the message of the desired message type (e.g., 5G-NAS message type) is created by the interworking device 400 on behalf of the remote unit.
[0079] In one embodiment, the memory 410 is a computer-readable storage medium. In some embodiments, the memory 410 includes volatile computer storage media. For example, the memory 410 may include RAM, which includes dynamic RAM ("DRAM"), synchronous dynamic RAM ("SDRAM"), and / or static RAM ("SRAM"). In some embodiments, the memory 410 includes non-volatile computer storage media. For example, the memory 410 may include a hard disk drive, flash memory, or any other suitable non-volatile computer storage device. In some embodiments, the memory 410 includes both volatile computer storage media and non-volatile computer storage media. In some embodiments, the memory 410 stores data related to authentication to the mobile communication network, such as message content, UE AN-params, etc. In some embodiments, the memory 410 also stores program code and related data, such as an operating system or other controller algorithms running on the interworking device 400 and one or more software applications.
[0080] In one embodiment, the input device 415 may include any known computer input device, including a touch panel, buttons, a keyboard, a stylus, a microphone, etc. In some embodiments, the input device 415 may be integrated with the display 420, such as a touch screen or a similar touch-sensitive display. In some embodiments, the input device 415 includes a touch screen such that text can be input using a virtual keyboard displayed on the touch screen and / or by handwriting on the touch screen. In some embodiments, the input device 415 includes two or more different devices, such as a keyboard and a touch panel.
[0081] In one embodiment, the display 420 may include any known electronically controllable display or display device. The display 420 may be designed to output visual, auditory, and / or tactile signals. In some embodiments, the display 420 includes an electronic display capable of outputting visual data to a user. For example, the display 420 may include, but is not limited to, an LCD display, an LED display, an OLED display, a projector, or a similar display device capable of outputting images, text, etc. to a user. As another non-limiting example, the display 420 may include a wearable display, such as a smartwatch, smart glasses, a heads-up display, etc. Additionally, the display 420 may be a component of a smartphone, a personal digital assistant, a television, a desktop computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, etc.
[0082] In certain embodiments, the display 420 includes one or more speakers for generating sound. For example, the display 420 may generate an audible alarm or notification (e.g., a beep or a chime). In some embodiments, the display 420 includes one or more haptic devices for generating vibration, movement, or other tactile feedback. In some embodiments, all or part of the display 420 may be integrated with the input device 415. For example, the input device 415 and the display 420 may form a touch screen or a similar touch-sensitive display. In other embodiments, the display 420 may be located near the input device 415.
[0083] The transceiver 425 communicates with a remote unit or UE, while the second transceiver 430 communicates with an NF in a mobile communication network. The transceivers 425 and 430 operate under the control of the processor 405 to transmit messages, data, and other signals, and also receive messages, data, and other signals. For example, the processor 405 can selectively activate one or both of the transceivers 425, 430 (or portions thereof) at a specific time to send and receive messages. The first transceiver 425 can include one or more transmitters and one or more receivers for communicating via a first access network. Similarly, the second transceiver 430 can include one or more transmitters and one or more receivers for communicating via a second access network. As discussed above, the first transceiver 425 and the second transceiver 430 can support one or more network interfaces for communicating with a mobile communication network.
[0084] Figure 5A and Figure 5B FIG. 500 depicts a network procedure 500 according to an embodiment of the present disclosure, which is used to connect to a mobile communication network, authenticate to the mobile communication network, and establish a NAS connection with the mobile communication network using EAP, for example, via an untrusted non-3GPP access network. The network procedure 500 starts at Figure 5A and continues at Figure 5B The network procedure 500 involves the UE 205, the non-3GPP AN 215, the N3IWF 220, the 3GPP(R) AN 210, the AMF 140, and the AUSF 155. Here, the result of successful authentication is the establishment of a NAS connection between the UE 205 and the 5G core network via the non-3GPP AN 215.
[0085] The network procedure 500 depicts how the new EAP-5G procedure disclosed herein can be used to support the registration of the UE 205 to the 5G core network (e.g., the core network 225) via an untrusted non-3GPP access (such as the non-3GPP AN 215). It should be noted that the new EAP-5G procedure runs between the UE 205 and the N3IWF 220 and supports the exchange of NAS messages and other information between the UE 205 and the N3IWF 220 during the authentication process.
[0086] The network procedure 500 starts at Figure 5A where the UE 205 connects to the non-3GPP AN 215 and retrieves an IP from the network (see block 502). By doing so, the UE 205 obtains a connection to an external network such as the Internet. Here, the non-3GPP AN 215 is an untrusted non-3GPP access network, such as a public A hot spot or other public network. The UE 205 then decides to register with a 5G core network (e.g., core network 225) in a certain PLMN and discovers the IP address of the interworking function (here, N3IWF 220) in that PLMN (see block 504). Here, the UE 205 can perform a DNS discovery process to discover the IP address of the N3IWF 220.
[0087] After discovering the N3IWF 220, the UE 220 starts to establish an IPsec connection (e.g., an IPsec tunnel) with the N3IWF 220, and here uses the Internet Key Exchange version 2 (“IKEv2”) protocol IKE_SA_INIT exchange (see signaling 506). It should be noted that an IKE “exchange” consists of a pair of messages: a request and a response. Here, the IKE_SA_INIT exchange establishes security parameters for subsequent IKEv2 exchanges.
[0088] The UE 205 sends an IKE_AUTH request including its permanent or temporary identifier (see signaling 508). In some embodiments, the permanent or temporary identifier can be assigned to the UE 205 by the 5G core network during a previous registration process. Here, the IKE_AUTH request contains the UE identifier but is sent without an AUTH value.
[0089] In some embodiments, the IKE_AUTH request from the UE 205 includes an indication of whether the UE 205 supports an EAP method with a first extension type (e.g., the EAP-5G procedure). If this indication is missing (or includes a negative indication), then the N3IWF220 does not use the EAP method with the first extension type (EAP-5G), but instead uses a legacy EAP method (i.e., an EAP method without the first extension type). In the network procedure 500, the UE 205 supports an EAP method with a first extension type (e.g., the EAP-5G protocol and its associated extension types), and also supports the 5G-NAS protocol (and the desired 5G-NAS type of messages).
[0090] The N3IWF 220 sends an EAP Request message containing a 5G-initiation message to notify the UE 205 that it should initiate a NAS procedure (e.g., 5G-NAS) to establish a connection with the 5G core network (see signaling 510). It should be noted that the 5G-initiation message uses a first EAP extension type (e.g., corresponding to the EAP-5G procedure described herein). The UE 205 responds with a 5G message (e.g., embedded in an EAP Response message) containing access network parameters ("AN-params") and a NAS registration request message (see signaling 512). It should be noted that the 5G message also uses the first EAP extension type (e.g., the EAP-5G extension type associated with the EAP-5G protocol). The AN-params include information for the N3IWF 220 to route the NAS registration request message to the appropriate AMF (here, AMF 140) in the 5G core network. For example, the AN-params may include one or more S-NSSAIs (slice information), DNN (data network name), SSC mode (session and service continuity), etc.
[0091] Although Figure 5A a NAS registration request (specifically, a NAS-PDU registration request) sent by the UE 205 to the N3IWF is depicted, in other embodiments, another suitable NAS message, such as a NAS service request, may be used. In the depicted embodiment, when passed between the UE 205 and the N3IWF 220, the NAS registration request is embodied as a message in the "5G message" format. In other embodiments, when passed between the UE 205 and the N3IWF 220, the NAS registration request message may be embodied as a message in the "5G challenge" format. In response to the 5G message, the N3IWF 220 selects an AMF by using the AN-params provided by the UE to forward the NAS registration request to the AMF (see block 514). Here, the N3IWF 220 selects the AMF 140 in the PLMN.
[0092] Now referring to Figure 5B , the N3IWF 220 forwards the NAS registration request message to the selected AMF 140 (see signaling 516). Here, the N3IWF 220 generates an N2 message containing the NAS registration request. In the case where the 5G message received from the UE 205 contains a NAS service request (or other NAS message), the N3IWF 220 forwards the NAS service request message (or other NAS message) to the selected AMF.
[0093] In some embodiments, the AMF 140 may decide to request the UE identifier of UE 205 (e.g., detect a stolen UE) by sending a NAS identifier request message via the N3IWF 220 to the UE 205 (see signaling 518). Here, the AMF 140 sends an N2 message containing the NAS identifier request, and the N3IWF 220 converts the N2 message into an EAP-5G message. Similarly, the UE 205 sends an EAP-5G message containing the NAS identifier response, and the N3IWF 220 converts the EAP-5G message into an N2 message. The NAS identifier request / response message and all other NAS messages are encapsulated in an EAP-5G message packet and sent to the UE 205. In the depicted embodiment, when being passed between the UE 205 and the N3IWF 220, the NAS identity request / response message is embodied as a message in the "5G message" format. In other embodiments, when being passed between the UE 205 and the N3IWF 220, the NAS identity request / response message is embodied as a message in the "5G challenge" format.
[0094] In some embodiments, the AMF 140 may decide to authenticate the UE 205. In this case, normal NAS authentication messages are exchanged between the UE 205, the AMF 140, and the AUSF 155, as shown in signaling 520 to 534. Similarly, when being passed between the UE 205 and the N3IWF 220, these NAS authentication messages are encapsulated in an EAP-5G message packet. In the depicted embodiment, when being passed between the UE 205 and the N3IWF 220, the NAS authentication request / response message is embodied as a message in the "5G message" format. In other embodiments, when being passed between the UE 205 and the N3IWF 220, the NAS authentication request / response message is embodied as a message in the "5G challenge" format message.
[0095] As shown, the AMF 140 sends an AAA key request message to the AUSF 155 and receives an AAA message containing the NAS authentication request from the AUSF 155. The AMF 140 sends an authentication request to the N3IWF 220 in an N2 message, which is converted by the N3IWF 220 into an EAP-5G message. Similarly, the N3IWF 220 converts an EAP-5G message containing the NAS authentication response (received from the UE 205) into an N2 message sent to the AMF 140. The AMF 140 sends an AAA message containing the NAS authentication response to the AUSF 155 and receives an AAA key response message containing the K-SEAF key from the AUSF 155. It should be noted that messages 518 to 534 are optional steps in the network process 500 (as indicated by the dashed lines).
[0096] After successful authentication, the AMF 140 sends a Security Mode Command ("SMC") request to the UE 205 to activate NAS security (see signaling 536). This message is first sent to the N3IWF 220 together with the K_N3IWF key used to establish an IPsec Security Association ("SA") between the UE 205 and the N3IWF 220. The UE 205 generates the same K_N3IWF key during the authentication process. Before the N3IWF 220 sends the SMC request to the UE 205, it completes the EAP authentication process by sending an EAP success message to the UE (see signaling 538). The UE 205 and the N3IWF 220 also exchange IKE_AUTH requests / responses (see signaling 540). Here, the AUTH value is included in the IKE_AUTH exchange.
[0097] A secure IPsec tunnel is established between the UE and the N3IWF (see box 542). This tunnel uses a Security Association (SA) in the UE 205 and the N3IWF 220, and the security association contains security keys and algorithms for protecting data passing through the tunnel. After the IPsec tunnel is established, all NAS messages are exchanged between the UE 205 and the N3IWF 220 via this tunnel.
[0098] Via the IPsec tunnel, the N3IWF 220 forwards the SMC request to the UE 205 (see signaling 544), and the rest of the NAS registration process proceeds as normal (see box 546). It should be noted that during the authentication process, NAS messages need to be encapsulated in EAP-5G data packets, but the EAP protocol is not used after successful authentication. In fact, NAS messages are transmitted within the established IPsec tunnel. As shown, the result of successful authentication is the establishment of a NAS connection between the UE 205 and the 5G core via the non-3GPP AN 215. It should be noted that the same type of NAS connection is established through the non-3GPP access network as is typically established through the 3GPP access network.
[0099] Although the network process 500 is described in the context of connecting via an untrusted non-3GPP access network, the network process 500 is also applicable to a trusted non-3GPP access network, with the difference that in the trusted case, the EAP messages are not encapsulated within IKEv2 messages (as shown), but rather within IEEE 802.1x messages, as Figure 7A and Figure 7B shown in.
[0100] Figure 6A and Figure 6BDepicts a network procedure 600 for using EAP to connect to a mobile communication network and authenticate to the mobile communication network, for example, via an untrusted non-3GPP access network, according to an embodiment of the present disclosure. The network procedure 600 starts at Figure 6A and continues at Figure 6B . The network procedure 600 involves UE 205, non-3GPP AN 215, N3IWF 220, 3GPP(R)AN 210, AMF 140, SMF 145, UPF 150, and AUSF 155. The network procedure 600 describes how a UE 205 that does not support the NAS protocol can register with a 5G core network via an untrusted non-3GPP access network.
[0101] The network procedure 600 starts at Figure 6A where the UE 205 connects to the non-3GPP AN 215 and retrieves an IP from the network (see block 502). By doing so, the UE 205 obtains a connection to an external network such as the Internet. Here, the non-3GPP AN215 is an untrusted non-3GPP access network. The UE 205 then decides to register with a 5G core network (e.g., core network 225) in a certain PLMN and discovers the IP address of the interworking function (here, N3IWF 220) in that PLMN (see block 504).
[0102] After discovering the N3IWF 220, the UE 220 starts to establish an IPsec connection (e.g., an IPsec tunnel) with the N3IWF 220 using an IKE_SA_INIT exchange (see signaling 506). Additionally, the UE 205 sends an IKE_AUTH request that includes its permanent or temporary identity (see signaling 508). The N3IWF 220 sends an EAP request message containing an EAP 5G start message to notify the UE205 that it should initiate a NAS procedure for establishing a connection to the 5G core network (see signaling 510). It should be noted that the network procedure 600 starts with the same five steps (e.g., corresponding to 502 to 510) as the network procedure 500. So far, the two network procedures are the same.
[0103] Here, the UE 205 determines that it does not support the EAP-5G procedure (e.g., does not support the EAP-5G protocol and its extended types). Alternatively, the UE 205 may determine that it does not support the NAS message requested by the network (e.g., the UE 205 does not support the 5G-NAS protocol and its desired message types). In both cases, the UE 205 responds with an EAP-NaK message (e.g., embedded in an EAP response message), which contains a list of one or more alternative EAP methods (e.g., EAP-AKA) supported by the UE 205 (see signaling 602). It should be noted that the EAP-NaK message uses the same EAP extension type as the EAP 5G-initiation message.
[0104] In response to the EAP-NaK message, the N3IWF 220 creates a NAS registration request message including a PDU session establishment request on behalf of the UE 205 (e.g., 5G-NAS message type) (see box 604). This is necessary because the AMF 140 still expects a NAS registration request message to initiate the registration process, but the UE 205 does not support the EAP-5G protocol and / or does not support the 5G-NAS protocol. Here, the N3IWF 220 may use the default parameters in the NAS registration request message. A PDU session establishment request is required to establish a PDU session for the UE 205 to exchange user data after the authentication process. It should be noted that the UE 205 can only exchange user data with the 5G core network. Here, due to the lack of NAS protocol support, the signaling is not feasible.
[0105] In addition, the N3IWF 220 selects an AMF to forward the NAS registration request (see box 606). In some embodiments, the AMF is selected based on the user ID provided by the UE in step 3a or by selecting a default AMF. Here, the N3IWF 220 selects the AMF 140 in the PLMN.
[0106] Now referring to Figure 6B , the N3IWF 220 forwards the created NAS registration request message to the selected AMF 140 (see signaling 608). Here, the N3IWF 220 generates an N2 message containing the NAS registration request. The NAS registration request message may optionally include an indicator (e.g., type=Proxy), which indicates to the AMF 140 that the NAS registration request is generated by the N3IWF 220 acting as a proxy for the UE 205 (not by the UE 205). In some embodiments, the N3IWF 220 may also forward the alternative authentication method supported by the UE 205 (received in the EAP-NaK message), which is sent to the AUSF 155 to select the correct method for authenticating the UE 205.
[0107] In some embodiments, UE 205 may support the EAP-5G procedures described herein, but does not support the 5G-NAS protocol (and thus does not support the message types (5G-NAS) expected by AMF 140). Such a UE 205 may include additional information such as AN-params in the EAP-NaK message to help N3IWF create a proxy NAS registration request message and a PDU session establishment request. Recall that AN-params includes information for N3IWF 220 to route the NAS registration request message to the appropriate AMF (here AMF 140) in the 5G core network.
[0108] AMF 140 begins authenticating UE 205 by sending an AAA key request message to AUSF 155 (see signaling 610). In some embodiments, AMF 140 and / or AUSF 155 may decide to request the UE identity of UE 205. Since NAS messages are not feasible (due to lack of support at UE 205), AUSF 155 sends an EAP-AKA identity request message to UE 205 via AMF 140 and N3WFW 220, and UE 205 generates an EAP-AKA identity response message for the identity request message (see signaling 612 to 616). Here, AMF 140 receives an AAA message from AUSF 155 and sends an N2 message containing the EAP-AKA identity request to N3IWF 220. N3IWF 220 converts the N2 message into an IKE_AUTH message. Similarly, UE 205 sends an IKE_AUTH message containing the EAP-AKA identity response, N3IWF 220 converts the IKE_AUTH message into an N2 message, and AMF 140 converts the N2 message into an AAA message. Here, steps 612 to 616 are optional in network procedure 600 (as indicated by the dashed line).
[0109] When authenticating the UE 205, EAP-AKA authentication messages (e.g., EAP-AKA challenge requests and responses) are exchanged between the UE 205, N3IWF 220, AMF 140, and AUSF 155, as shown in signaling 618 to 628. As shown, the AMF 140 receives an AAA message containing an EAP-AKA challenge request from the AUSF 155. The AMF 140 sends the EAP-AKA challenge request to the N3IWF 220 in an N2 message, which is converted by the N3IWF 220 into an IKE_AUTH message containing the EAP-AKA challenge request. Similarly, the N3IWF 220 converts an IKE_AUTH message containing an EAP-AKA challenge response (received from the UE 205) into an N2 message that is sent to the AMF 140. The AMF 140 sends an AAA message containing the EAP-AKA challenge response to the AUSF 155. After completing the EAP-AKA challenge, the AMF 140 receives an AAA key response message with the K_SEAF key from the AUSF 155 (see signaling 630).
[0110] After a successful authentication process, the AMF 140 selects an SMF for the UE 205 (see box 632) and begins to establish a PDU session for the UE 205 (see box 634). In some embodiments, the AMF 140 uses default AN-params, such as a default S-NSSAI (slice information), a default DNN (data network name), a default SSC mode (session and service continuity), etc. These default parameters can be retrieved from the user's subscription data. In the case where the UE 205 provides AN-params to the AMF 140, the AMF 140 can use these AN-params when establishing the PDU session.
[0111] In response to establishing the PDU session, the AMF 140 sends an N2 message to the N3IWF 220 using the K_N3IWF key, which is used to establish an IPsec security association ("SA") between the UE 205 and the N3IWF 220 (see signaling 636). The UE 205 generates the same K_N3IWF key during the authentication process. The N3IWF 220 completes the EAP authentication process by sending an EAP success message to the UE 205 (see signaling 638). The UE 205 and the N3IWF 220 also exchange IKE_AUTH requests / responses (see signaling 640). Here, the AUTH value is included in the IKE_AUTH exchange.
[0112] A secure IPsec tunnel is established between the UE 205 and the N3IWF 220 (see box 642). This tunnel uses security associations (SAs) in the UE 205 and the N3IWF 220, and the security associations include security keys and algorithms for protecting data transmitted through the tunnel. Additionally, an N3 tunnel is established between the N3IWF 220 and the UPF 150. Here, the IPsec tunnel is used to transport user data but not NAS messages. Moreover, during the establishment of the IPsec tunnel, the UE 205 receives from the N3IWF 220 the IP address assigned by the SMF 145 for the established PDU session. It should be noted that in the network procedure 500, the UE 205 does not receive an IP address from the N3IWF 220; this is not required because the IPsec tunnel in the network procedure 500 is only used for NAS signaling.
[0113] Although the network procedure 600 is described as connecting via an untrusted non-3GPP access network, the network procedure 600 is also applicable to a trusted non-3GPP access network, with the difference that in the trusted case, the EAP messages are not encapsulated within IKEv2 messages (as shown), but rather within IEEE 802.1x messages.
[0114] Figure 7A and Figure 7B depicts a network procedure 700 according to an embodiment of the present disclosure for authenticating and establishing a NAS connection with a mobile communication network using EAP, for example, via a trusted non-3GPP access network. The network procedure 700 starts in Figure 7A and continues in Figure 7B The network procedure 700 involves the UE 205, the non-3GPP AN 215, the N3IWF 220, the 3GPP(R)AN 210, the AMF 140, and the AUSF 155.
[0115] The network procedure 700 depicts how the novel EAP-5G procedure disclosed herein can be used to support the registration of the UE 205 to a 5G core network (e.g., the core network 225) via a trusted non-3GPP access (depicted herein as the non-3GPP AN 215). It should be noted that the novel EAP-5G procedure operates between the UE 205 and the N3IWF 220 and supports the exchange of NAS messages and other information between the UE 205 and the N3IWF 220 during the authentication process. In some embodiments, the N3IWF 220 may be located within the trusted non-3GPP access network (e.g., within the non-3GPP AN 215).
[0116] The network procedure 700 is in Figure 7Astarting from where UE 205 is connected to non-3GPP AN 215 and starts the IEEE802.1x authentication process (see box 702). Here, non-3GPP AN 215 is a trusted non-3GPP access network under the control of the operator of AMF 140 and AUSF 155. UE 205 then decides to register with a 5G core network (e.g., core network 225) associated with the trusted non-3GPP access network and sends an 802.1x start message (see signaling 704). Although Figures 7A to 7B illustrates UE 205 using the 802.1x protocol, in other embodiments, other link layer protocols such as the Point-to-Point Protocol ("PPP") may be used.
[0117] N3IWF 220 sends an EAP-5G request message containing a 5G start message to notify UE 205 that it should initiate a NAS process (e.g., 5G-NAS) to establish a connection with the 5G core network (see signaling 706). Here, the EAP-5G request message is embedded within the 802.1x message. It should be noted that the 5G start message uses a first EAP extension type (e.g., corresponding to the EAP-5G protocol).
[0118] UE 205 responds with a message in 5G message format (e.g., embedded in an EAP-5G response message) that contains access network parameters ("AN-params") and a NAS registration request message (see signaling 708). Alternatively, UE 205 may respond with a message in 5G challenge format that contains AN-params and a NAS registration request message (e.g., embedded in an EAP-5G response message). It should be noted that the 5G message also uses the first EAP extension type (e.g., EAP-5G extension type). AN-params includes information for N3IWF 220 to route the NAS registration request message to the appropriate AMF (here AMF 140) in the 5G core network. Although Figure 7A illustrates a NAS registration request (specifically a NAS-PDU registration request) sent by UE 205 to N3IWF, in other embodiments, another suitable NAS message such as a NAS service request may be used.
[0119] In response to the 5G message, the N3IWF 220 selects an AMF by using the AN-params provided by the UE to forward the NAS registration request to the AMF (see block 710). Here, the N3IWF 220 selects the AMF 140 in the PLMN. Then, the N3IWF 220 forwards the NAS registration request message to the selected AMF 140 (see signaling 516). Here, the N3IWF 220 generates an N2 message containing the NAS registration request. In the case where the 5G message received from the UE 205 contains a NAS service request (or other NAS message), the N3IWF 220 forwards the NAS service request message (or other NAS message) to the selected AMF.
[0120] In some embodiments, the AMF 140 may decide to request the UE identifier of the UE 205 by sending a NAS identifier request message to the UE 205 via the N3IWF 220 (e.g., to detect a stolen UE) (see signaling 518). Here, the AMF 140 sends an N2 message containing the NAS identifier request, and the N3IWF 220 converts the N2 message into an EAP-5G message. Similarly, the UE 205 sends an EAP-5G message containing a NAS identifier response (embedded in an 802.1X message) (see signaling 712). Here, the N3IWF 220 converts the 802.1x / EAP-5G message into an N2 message. The NAS identifier request / response message and all other NAS messages are encapsulated in an EAP-5G message packet (embedded in an 802.1x message) and sent to the UE 205. It should be noted that steps 518 and 712 are optional in the network process 700. In the depicted embodiment, when being passed between the UE 205 and the N3IWF 220, the NAS identifier request / response message is embodied as a message in the "5G message" format. In other embodiments, when being passed between the UE 205 and the N3IWF 220, the NAS identifier request / response message is embodied as a message in the "5G challenge" format.
[0121] In some embodiments, the AMF 140 may decide to authenticate the UE 205. The AMF 140 starts by sending an AAA key request message to the AUSF 155 (see signaling 520), and receives an AAA message containing a NAS authentication request from the AUSF 155 (see signaling 522). In Figure 7BContinuing, the AMF 140 sends a NAS authentication request to the N3IWF 220 in an N2 message (see signaling 524), and the N2 message is converted by the N3IWF 220 into an EAP-5G message sent to the UE 205 (see signaling 714). Similarly, the N3IWF 220 receives an EAP-5G message containing a NAS authentication response from the UE 205 (see signaling 716) and converts it into an N2 message sent to the AMF 140 (see signaling 530). In the depicted embodiment, when passing between the UE 205 and the N3IWF 220, the NAS authentication request / response message is embodied as a message in the "5G message" format. In other embodiments, when passing between the UE 205 and the N3IWF 220, the NAS authentication request / response message is embodied as a message in the "5G challenge" format.
[0122] The AMF 140 sends an AAA message containing a NAS authentication response to the AUSF 155 (see signaling 532) and receives an AAA key response message containing the K-SEAF key from the AUSF 155 (see signaling 534). It should be noted that the UE authentication messages (e.g., 522, 524, 714, 716, 530, 532, and 534) are optional steps in the network process 700 (as indicated by the dashed lines). Also, when using 802.1x messages to pass between the UE 205 and the N3IWF 220, these NAS authentication messages are encapsulated in EAP-5G message packets.
[0123] After successful authentication, the AMF 140 sends a security mode command ("SMC") request to the UE 205 to activate NAS security (see signaling 536). This message is sent to the N3IWF 220 together with the K_N3IWF key used to establish an IPsec security association ("SA") between the UE 205 and the N3IWF 220. The UE 205 generates the same K_N3IWF key during the authentication process. Before the N3IWF 220 sends an SMC request to the UE 205, it completes the EAP authentication process by sending an EAP success message to the UE (see signaling 718). The UE 205 and the N3IWF 220 then execute the 802.1x four-way handshake protocol to create additional security keys (see signaling 720).
[0124] A secure link is then established between the UE and the N3IWF (see block 722). Here, the secure link is used for both NAS signaling and PDU session data. Via the secure link, the N3IWF 220 forwards the SMC request to the UE 205 (see signaling 724), and the remaining NAS registration process typically occurs over the secure link (see block 726). Here, the result of successful authentication is the establishment of a NAS connection between the UE 205 and the 5G core network via the non-3GPP AN 215. It should be noted that the same type of NAS connection is established via the non-3GPP access network as is typically established via the 3GPP access network.
[0125] Figure 8 Method 800 for authenticating to a mobile communication network via, for example, a non-3GPP access network according to an embodiment of the present disclosure is depicted. In some embodiments, method 800 is performed by a device such as remote unit 105, UE 205, and / or remote device 300. In certain embodiments, method 800 may be performed by a processor executing program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.
[0126] Method 800 begins and provides 805 a first transceiver for communicating with a mobile communication network via a first access network and a second transceiver for communicating with the mobile communication network via a second access network. Here, the first transceiver and the second transceiver are provided 805 in a remote unit such as remote unit 105, UE 205, and / or remote device 300. In one embodiment, the second access network is a non-3GPP access network, such as a wireless local area network (“WLAN”).
[0127] Method 800 includes sending 810 a request to initiate authentication via the second access network. In certain embodiments, sending 810 the request to initiate authentication via the second access network includes: sending a request to connect to the mobile communication network via an untrusted non-3GPP access network and then initiate authentication via the untrusted non-3GPP access network. In other embodiments, sending 810 the request to initiate authentication via the second access network includes sending a request to initiate authentication via a trusted non-3GPP access network.
[0128] In one embodiment, a connection request identifies a remote unit, for example, using a permanent or temporary UE identifier. Method 800 includes receiving 815, via a second access network, an Extensible Authentication Protocol (“EAP”) request having a first extension type (e.g., an EAP-5G extension type). Here, the first extension type may be a 3GPP-specific type, such as an EAP-5G extended data packet. In one embodiment, the EAP request having the first extension type corresponds to an EAP 5G start message. The EAP request may also be embedded within an IKEv2 message (such as an IKE-AUTH response). It should be noted that the EAP request indicates that the remote unit initiates a specific authentication method that requires the use of a 5G-NAS message within an EAP-5G message.
[0129] Method 800 includes sending 820, via a second access network (e.g., a non-3GPP access network), an EAP response that includes a first extension type (e.g., an EAP-5G extension type corresponding to the EAP-5G protocol), a first parameter set (e.g., AN-params), and a first message. Here, the first message is the same type of message that can be used to establish a connection with a mobile communication network via a first access network (e.g., a 5G-NAS message that can be used for a connection via a 3GPP access network). In one embodiment, the first message is a non-access stratum (“NAS”) registration request. In certain embodiments, sending 820 the EAP response includes initiating a secure IPsec connection with an interworking function. Future NAS messages may be exchanged with the mobile communication network via the secure IPsec connection.
[0130] In some embodiments, sending 820 the EAP response includes receiving one or more additional EAP-5G requests and sending an equal number of EAP-5G responses. Here, each of the additional EAP-5G requests and responses encapsulates at least one 5G-NAS message. In this way, 5G-NAS messages can be used to identify and authenticate the remote unit. Here, the result of successful authentication is the establishment of a NAS connection between the remote unit and the 5G core network via a non-3GPP access. Thus, the remote unit can establish a NAS connection with the mobile communication network via the additional EAP requests and responses.
[0131] In response to determining that the remote unit does not support the first extension type (e.g., an EAP-5G extension type associated with the EAP-5G protocol), sending 820 the EAP response via the second access network may include: sending an EAP response that includes the first extension type and a list of authentication methods supported by the remote unit for authentication to the mobile communication network via the second access network. Thereafter, the remote unit can authenticate to the mobile communication network using one of the supported authentication methods.
[0132] In response to determining that the device does not support a desired message type (e.g., a 5G-NAS message type associated with the 5G-NAS protocol), sending 820 the EAP response via a second access network may include sending an EAP response including a first extension type (e.g., an EAP-5G extension type) and one or more additional parameters, where the one or more additional parameters may be used by the interworking function to generate a message of the desired message type (e.g., a 5G-NAS message) on behalf of the remote unit. Here, the interworking function may (optionally) include an indication that the message of the expected message type (e.g., a 5G-NAS message) is created by the interworking function on behalf of the remote unit. Method 800 ends.
[0133] Figure 9 Method 900 for authenticating to a mobile communication network via, for example, a non-3GPP access network according to an embodiment of the present disclosure is depicted. In some embodiments, method 900 is performed by a device such as an interworking function 130, an N3IWF 220, and / or an interworking device 400. In certain embodiments, method 900 may be performed by a processor executing program code, such as a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, an FPGA, etc.
[0134] Method 900 begins and receives 905 a request to start authentication from a remote unit via a first access network. In some embodiments, the first access network is a WLAN or other non-3GPP access network. In one embodiment, the connection request identifies the remote unit, for example, using a permanent or temporary UE identifier. In some embodiments, receiving 905 the request to start authentication includes receiving a request to connect to the mobile communication network via an untrusted non-3GPP access network and start authentication. In another embodiment, receiving 905 the request to start authentication includes receiving a request to start authentication via a trusted non-3GPP access network.
[0135] Method 900 includes sending 910 an Extensible Authentication Protocol (“EAP”) request having a first extension type (e.g., an EAP-5G extension type) to the remote unit. Here, the first extension type may be a 3GPP-specific type, such as an EAP-5G extended data packet. In one embodiment, the EAP request having the first extension type corresponds to an EAP 5G start message. The EAP request may also be embedded within an IKEv2 message (such as an IKE-AUTH response).
[0136] In some embodiments, sending 910 the EAP request occurs in response to a request from a remote unit to start authentication, the request including an indication that the remote unit supports EAP messaging using a first extension type. Otherwise, if the remote unit indicates that it does not support the first extension type (e.g., does not support the EAP-5G protocol), then no EAP request of the first extension type is sent to the remote unit.
[0137] Method 900 includes receiving 915 an EAP response via a first access network, the EAP response including a first extension type (e.g., EAP-5G extension type), a first parameter set (e.g., AN-params), and a first message. Here, the first message is the same type of message that can be used to establish a connection with a mobile communication network via another access network (e.g., via a 3GPP access network), the other access network using a different communication protocol than the first access network. In some embodiments, the first message is a non-access stratum (“NAS”) registration request. In certain embodiments, receiving 915 the EAP response triggers the establishment of a secure IPsec connection with the remote unit. Future NAS messages can be exchanged between the remote unit and the mobile communication network via the secure IPsec connection.
[0138] In some embodiments, receiving 915 the EAP response includes sending one or more additional EAP-5G requests and receiving an equal number of EAP-5G responses. Here, each of the additional EAP-5G requests and responses encapsulates at least one 5G-NAS message. In this way, the interworking function can use the 5G-NAS messages to identify and authenticate the remote unit. Here, the result of successful authentication is the establishment of a NAS connection between the remote unit and the 5G core network via non-3GPP access. Thus, the remote unit can establish a NAS connection with the mobile communication network via the additional EAP requests and responses.
[0139] In some embodiments, receiving 915 the EAP response includes receiving at the interworking function an indication that the remote unit does not support the first extension type (e.g., the EAP-5G extension type associated with the EAP-5G protocol), where the EAP response includes a list of the first extension type and authentication methods supported by the remote unit for authentication to the mobile communication network via a second access network. Here, the interworking function can forward the list of authentication methods to the mobile communication network (e.g., to AUSF155). In certain embodiments, the interworking function can then send a NAS message to the mobile communication network on behalf of the remote unit, and optionally include an indication that the NAS message was created by the interworking function on behalf of the remote unit. In one embodiment, the NAS message is one of the following: a NAS registration request, a NAS registration request containing a session establishment request, and a NAS service request.
[0140] In some embodiments, receiving 915 the EAP response includes receiving, at the interworking function, an indication that the remote unit does not support a desired message type (e.g., the remote unit does not support the 5G-NAS protocol and its associated message types), where the EAP response includes a first extended type and one or more additional parameters of a message that can be used to generate the desired message type on behalf of the remote unit, and an indication that the message of the desired message type is created by the interworking function on behalf of the remote unit. Method 900 ends.
[0141] Embodiments may be practiced in other specific forms. The described embodiments are to be considered in all respects only illustrative and not restrictive. Thus, the scope of the invention is indicated by the appended claims rather than by the foregoing description. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.
Claims
1. A device, comprising: a processor; and a memory coupled to the processor, the processor being configured to cause the device to: send a first request to start authentication with a mobile communication network via an access network including a non-3GPP interworking function; receive an Extensible Authentication Protocol ("EAP") start packet, the EAP start packet initiating an EAP-5G session between the device and the non-3GPP interworking function, the EAP-5G session utilizing EAP-5G packets having an extended EAP type and a 3GPP vendor identifier, wherein the EAP-5G session is initiated for exchanging non-access stratum ("NAS") messages between the device and the mobile communication network via the non-3GPP interworking function, wherein the NAS messages are encapsulated within the EAP-5G packets; and send an EAP-5G response packet via the access network, the EAP-5G response packet including a set of access network parameters and a NAS registration request message, wherein the first set of access network parameters includes information for routing the NAS registration request message to an access management function ("AMF") in a core network.
2. The device according to claim 1, wherein The access network includes a wireless local area network ("WLAN").
3. The device according to claim 1, wherein, The processor is further configured to cause the device to: establish a secure network protocol security ("IPsec") connection with the non-3GPP interworking function in response to completion of authentication to the mobile communication network, and exchange NAS messages with the mobile communication network via the secure IPsec connection.
4. The apparatus according to claim 1, wherein, The processor is further configured to cause the device to: receive one or more additional EAP-5G request packets, send an equal number of EAP-5G response packets, wherein each of the one or more additional EAP-5G request packets and the equal number of EAP-5G response packets encapsulates at least one NAS message, and establish a NAS connection with the mobile communication network via the one or more additional EAP-5G request packets and the equal number of EAP-5G response packets.
5. The device according to claim 1, wherein The processor is further configured to cause the device to: determine that the device does not support the extended EAP type, wherein, for sending the EAP-5G response packet via a second access network, the processor is configured to cause the device to: send the EAP-5G response packet utilizing the extended EAP type and a list of authentication methods supported by the device for authentication to the mobile communication network via the access network.
6. The device according to claim 5, wherein, The processor is further configured to cause the device to: authenticate to the mobile communication network using an authentication method from the list of authentication methods supported by the device.
7. The apparatus according to claim 1, wherein The processor is further configured to cause the device to: determine that the device does not support a protocol associated with a desired message type, wherein, for sending the EAP-5G response packet via the access network, the processor is configured to cause the device to: send an EAP-5G response packet using the extended EAP type and one or more additional parameters, the one or more additional parameters being usable by the interworking function to generate a message of the desired message type on behalf of the device.
8. The apparatus according to claim 7, wherein, The generated message of the desired message type includes an indication that the generated message is created by the interworking function on behalf of the device.
9. The device according to claim 1, wherein, The access network is a trusted non-3GPP access network.
10. The apparatus according to claim 1, wherein The access network is an untrusted non-3GPP access network.
11. A method of a user equipment ("UE"), the method comprising: Sending a first request to start authentication with a mobile communication network via an access network including a non-3GPP interworking function; Receiving an Extensible Authentication Protocol ("EAP") start packet that initiates an EAP-5G session between the UE and the non-3GPP interworking function, the EAP-5G session using EAP-5G packets with an extended EAP type and a 3GPP vendor identifier, wherein the EAP-5G session is initiated for exchanging non-access stratum ("NAS") messages between the UE and the mobile communication network via the non-3GPP interworking function, and wherein the NAS messages are encapsulated within the EAP-5G packets; and Sending an EAP-5G response packet via the access network, the EAP-5G response packet including a first set of access network parameters and a NAS registration request message, wherein the first set of access network parameters includes information for routing the NAS registration request message to an access management function ("AMF") in a core network.
12. The method according to claim 11, wherein, The access network includes a Wireless Local Area Network ("WLAN").
13. The method according to claim 11, further comprising: Establishing a Secure Network Protocol Security ("IPsec") connection with the non-3GPP interworking function in response to completion of authentication to the mobile communication network, and Exchanging NAS messages with the mobile communication network via the secure IPsec connection.
14. The method according to claim 11, further comprising: Receiving one or more additional EAP-5G request packets, Sending an equal number of EAP-5G response packets, wherein each of the one or more additional EAP-5G request packets and the equal number of EAP-5G response packets encapsulates at least one NAS message, and Establishing the mobile communication network via the one or more additional EAP-5G request packets and the equal number of EAP-5G response packets.
15. The method according to claim 11 further includes determining that the UE does not support the extended EAP type, wherein, Sending the EAP-5G response packet via the access network includes: sending the EAP-5G response packet using the extended EAP type and a list of authentication methods supported by the UE for authentication to the mobile communication network via the access network.
16. The method according to claim 15 further includes authenticating to the mobile communication network using an authentication method from a list of the authentication methods supported by the UE.
17. The method according to claim 11 further comprises determining that the UE does not support a protocol associated with a desired message type, wherein, Sending the EAP-5G response packet via the access network includes: sending an EAP-5G response packet using the extended EAP type and one or more additional parameters, where the one or more additional parameters can be used by the interworking function to generate a message of the desired message type on behalf of the UE.
18. The method according to claim 17, wherein The message of the desired message type generated includes an indication that the generated message is created by the interworking function on behalf of the UE.
19. The method according to claim 11, wherein The access network is a trusted non-3GPP access network.
20. The method according to claim 11, wherein The access network is an untrusted non-3GPP access network.