Data session protection

Abstract

Example embodiments of the present disclosure relate to data session protection. In one method, an apparatus determines a security key based at least on a session key, the security key used to protect a data session between the apparatus and a device. The session key is used by a network entity in a 3GPP network to determine another security key used to protect the data session. The apparatus is in a non-3GPP access network and connected to the device. The apparatus performs communications using the data session based on the security key. In this way, security of communications between the apparatus and the 3GPP network is improved.

Description

Technical Field

[0001] The various exemplary embodiments disclosed herein relate generally to the telecommunications field, and more particularly to methods, apparatuses, devices, and computer-readable storage media for data session protection. Background Technology

[0002] A communication network can be used as a facility that enables communication between two or more communication devices or provides communication devices with access to a data network. A mobile or wireless communication network is an example of a communication network. Communication devices may be serviced by an application server.

[0003] Communication networks can operate according to standards provided by organizations such as the 3rd Generation Partnership Project (3GPP) or the European Telecommunications Standards Institute (ETSI). Examples of standards provided by 3GPP are the so-called 3GPP standards for cellular technology generations, such as the 3GPP standards for 4G, 5G, 6G, and so on. Summary of the Invention

[0004] In a first aspect of this disclosure, an apparatus is provided. The apparatus includes at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: determine a security key based on a session key, the security key being used to protect a data session between the apparatus and a device, wherein the session key is used by a network entity in a 3GPP network to determine another security key for protecting the data session, and wherein the apparatus is in a non-3GPP access network and is connected to a device; and perform communication using the data session based on the security key.

[0005] In a second aspect of this disclosure, an apparatus is provided. The apparatus includes at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: receive a security key from a network entity in a 3GPP network, the security key being used to protect a data session between the apparatus and the device, wherein the apparatus is in a non-3GPP access network and is connected to the device, the security key being determined based on a session key, and the session key being used by the apparatus to determine another security key for protecting the data session; and perform communication using the data session based on the security key.

[0006] In a third aspect of this disclosure, a network entity is provided. The network entity includes: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the network entity to at least: determine a security key based on a session key, the security key being used to protect a data session between a device and a device, wherein the device is in a non-3GPP access network and is connected to the device, the network entity is in a 3GPP network, and the session key is used by the device to determine another security key for protecting the data session; and send the security key to the device.

[0007] In a fourth aspect of this disclosure, a network entity is provided. The network entity includes: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the network entity to at least: receive from another network entity a request for authenticating a device in a non-3GPP access network to a 3GPP network, the request including a serving network identifier configured by the device in the 3GPP network, wherein the network entity and the other network entity are in the 3GPP network; determine authentication information for the device based on the serving network identifier; and send a response to the request to the other network entity, wherein the response includes the authentication information.

[0008] In a fifth aspect of this disclosure, a network entity is provided. The network entity includes: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the network entity to at least: receive from a device a request to authenticate a device to a 3GPP network, wherein the device is in a non-3GPP access network and is connected to the device, and the network entity is in a 3GPP network; send to another network entity a further request to authenticate a device to a 3GPP network, wherein the other network entity is in a 3GPP network; receive authentication information for the device from the other network entity; receive response information from the device, the response information being associated with the authentication information; and verify the response information based on the authentication information.

[0009] In a sixth aspect of this disclosure, a network entity is provided. The network entity includes at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the network entity to at least: receive from another network entity a request for authenticating a device to a 3GPP network, wherein the device is in a non-3GPP access network and is connected to the device, and the network entity and the other network entity are in a 3GPP network; and send a response to the request to the other network entity, the response including authentication information for the device.

[0010] In a seventh aspect of this disclosure, a method is provided. The method includes: determining a security key based at least on a session key, the security key being used to protect a data session between a device and an equipment, wherein the session key is used by a network entity in a 3GPP network to determine another security key for protecting the data session, and wherein the device is in a non-3GPP access network and is connected to an equipment; and performing communication using the data session based on the security key.

[0011] In an eighth aspect of this disclosure, a method is provided. The method includes: receiving a security key from a network entity in a 3GPP network, the security key being used to protect a data session between a device and an equipment, wherein the device is in a non-3GPP access network and is connected to the equipment, the security key being determined based on a session key, and the session key being used by the device to determine another security key for protecting the data session; and performing communication using the data session based on the security key.

[0012] In a ninth aspect of this disclosure, a method is provided. The method includes: determining a security key based at least on a session key, the security key being used to protect a data session between a device and an equipment, wherein the device is in a non-3GPP access network and is connected to the equipment, the network entity is in a 3GPP network, and the session key is used by the device to determine another security key for protecting the data session; and sending the security key to the equipment.

[0013] In a tenth aspect of this disclosure, a method is provided. The method includes: receiving from another network entity a request for authenticating a device in a non-3GPP access network to a 3GPP network, the request including a serving network identifier configured by the device in the 3GPP network, wherein the network entity and the other network entity are in the 3GPP network; determining authentication information for the device based on the serving network identifier; and sending a response to the request to the other network entity, wherein the response includes the authentication information.

[0014] In the eleventh aspect of this disclosure, a method is provided. The method includes: receiving from a device a request to authenticate a device to a 3GPP network, wherein the device is in a non-3GPP access network and is connected to the device, and a network entity is in a 3GPP network; sending another request to another network entity for authenticating the device to a 3GPP network, wherein the other network entity is in a 3GPP network; receiving authentication information for the device from the other network entity; receiving from the device response information of the device, the response information being associated with the authentication information; and verifying the response information based on the authentication information.

[0015] In a twelfth aspect of this disclosure, a method is provided. The method includes: receiving from another network entity a request to authenticate a device to a 3GPP network, wherein the device is in a non-3GPP access network and is connected to the device, and the network entity and the other network entity are in a 3GPP network; and sending a response to the request to the other network entity, the response including authentication information for the device.

[0016] In a thirteenth aspect of this disclosure, an apparatus is provided. The apparatus includes: components for determining a security key at least based on a session key, the security key being used to protect a data session between the apparatus and a device, wherein the session key is used by a network entity in a 3GPP network to determine another security key for protecting the data session, and wherein the apparatus is in a non-3GPP access network and is connected to a device; and components for performing communication using the data session based on the security key.

[0017] In a fourteenth aspect of this disclosure, an apparatus is provided. The apparatus includes: components for receiving a security key from a network entity in a 3GPP network, the security key being used to protect a data session between the apparatus and the apparatus, wherein the apparatus is in a non-3GPP access network and is connected to the apparatus, the security key being determined based on a session key, and the session key being used by the apparatus to determine another security key for protecting the data session; and components for performing communication using the data session based on the security key.

[0018] In a fifteenth aspect of this disclosure, a network entity is provided. The network entity includes: components for determining a security key at least based on a session key, the security key being used to protect a data session between a device and a device, wherein the device is in a non-3GPP access network and is connected to the device, the network entity is in a 3GPP network, and the session key is used by the device to determine another security key for protecting the data session; and components for sending the security key to the device.

[0019] In a sixteenth aspect of this disclosure, a network entity is provided. The network entity includes: components for receiving from another network entity a request for authenticating a device in a non-3GPP access network to a 3GPP network, the request including a serving network identifier of the 3GPP network configured by the device, wherein the network entity and the other network entity are in a 3GPP network; components for determining authentication information for the device based on the serving network identifier; and components for sending a response to the request to the other network entity, wherein the response includes the authentication information.

[0020] In a seventeenth aspect of this disclosure, a network entity is provided. The network entity includes: components for receiving from a device a request for authenticating a device to a 3GPP network, wherein the device is in a non-3GPP access network and is connected to the device, and the network entity is in a 3GPP network; components for sending to another network entity a further request for authenticating a device to a 3GPP network, wherein the other network entity is in a 3GPP network; components for receiving authentication information for the device from the other network entity; components for receiving response information from the device, the response information being associated with the authentication information; and components for verifying the response information based on the authentication information.

[0021] In an eighteenth aspect of this disclosure, a network entity is provided. The network entity includes: components for receiving from another network entity a request for authenticating a device to a 3GPP network, wherein the device is in a non-3GPP access network and is connected to a device, and the network entity and the other network entity are in a 3GPP network; and components for sending a response to the request to the other network entity, the response including authentication information for the device.

[0022] In a nineteenth aspect of this disclosure, a computer-readable medium is provided. The computer-readable medium includes instructions stored thereon for causing the apparatus to perform at least the methods according to the seventh, eighth, ninth, tenth, eleventh, or twelfth aspects.

[0023] It should be understood that the summary portion is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0024] Some exemplary embodiments will now be described with reference to the accompanying drawings, in which: Figure 1A An example communication environment in which example embodiments of the present disclosure may be implemented is shown; Figure 1B An example communication environment in which example embodiments of this disclosure may be implemented is shown; Figure 2A A schematic diagram of the non-roaming architecture within the Evolved Packet System (EPS) is shown; Figure 2B The signaling flow for the initial attach procedure on the Proxy Mobile Internet Protocol (PMIP) is shown. Figure 3 A schematic diagram of an end-to-end (E2E) protocol stack according to some example embodiments of the present disclosure is shown; Figure 4A A schematic diagram of an example architecture of an E2E protocol stack according to some example embodiments of the present disclosure is shown; Figure 4B A schematic diagram of an example architecture of an E2E protocol stack according to some example embodiments of the present disclosure is shown; Figure 5 The signaling flow of a data session protection process according to some embodiments of this disclosure is shown; Figure 6 An example signaling flow of a data session protection procedure according to some embodiments of this disclosure is shown; Figure 7 A schematic diagram illustrating a process for generating a security key according to some embodiments of the present disclosure is shown; Figure 8 The signaling flow of a data session protection process according to some embodiments of this disclosure is shown; Figure 9 An example signaling flow illustrating a data session protection process according to some embodiments of this disclosure is shown; Figure 10 A schematic diagram illustrating a process for generating a security key according to some embodiments of the present disclosure is shown; Figure 11 The signaling flow of an authentication process on a heterogeneous network according to some embodiments of the present disclosure is illustrated; Figure 12A An example signaling flow of an authentication process on a heterogeneous network according to some embodiments of the present disclosure is shown; Figure 12B An example signaling flow of an authentication process on a heterogeneous network according to some embodiments of the present disclosure is shown; Figure 13 A flowchart is shown illustrating a method implemented at an apparatus according to some example embodiments of the present disclosure; Figure 14 A flowchart illustrating a method implemented at a device according to some example embodiments of the present disclosure is shown; Figure 15 A flowchart is shown illustrating a method implemented at a network entity according to some example embodiments of the present disclosure; Figure 16 A flowchart is shown illustrating a method implemented at a network entity according to some example embodiments of the present disclosure; Figure 17 A flowchart is shown illustrating a method implemented at a network entity according to some example embodiments of the present disclosure; Figure 18 A flowchart is shown illustrating a method implemented at a network entity according to some example embodiments of the present disclosure; Figure 19 A flowchart is shown illustrating a method implemented at an apparatus according to some example embodiments of the present disclosure; Figure 20A flowchart illustrating a method implemented at a device according to some example embodiments of the present disclosure is shown; Figure 21 A flowchart is shown illustrating a method implemented at a network entity according to some example embodiments of the present disclosure; Figure 22 A flowchart is shown illustrating a method implemented at a network entity according to some example embodiments of the present disclosure; Figure 23 A simplified block diagram of a device suitable for implementing example embodiments of the present disclosure is shown; and Figure 24 A block diagram of an example computer-readable medium according to some example embodiments of the present disclosure is shown.

[0025] Throughout the accompanying drawings, the same or similar reference numerals denote the same or similar elements. Detailed Implementation

[0026] The principles of this disclosure will now be described with reference to some exemplary embodiments. It should be understood that these embodiments are described for illustrative purposes only and to assist those skilled in the art in understanding and implementing this disclosure, without imposing any limitation on the scope of this disclosure. The embodiments described herein can be implemented in various ways other than those described below.

[0027] In the following description and claims, unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains.

[0028] References to "an embodiment," "an embodiment," "an example embodiment," etc., in this disclosure indicate that the described embodiment may include a particular feature, structure, or characteristic, but not every embodiment needs to include that particular feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same embodiment. Moreover, when a particular feature, structure, or characteristic is described in connection with an embodiment, whether explicitly described or not, it is believed that incorporating other embodiments to affect such a feature, structure, or characteristic is within the knowledge of those skilled in the art.

[0029] It should be understood that although the terms "first," "second," etc., preceding the noun(s) may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another, and they do not restrict the order of the noun(s). For example, without departing from the scope of the exemplary embodiments, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element. As used herein, the term "and / or" includes any and all combinations of one or more of the listed terms.

[0030] As used herein, “at least one of the following: ” and “at least one of ” and similar wording, where the list of two or more elements is connected by “and” or “or”, means at least any one of the elements, or at least any two or more of the elements, or at least all of the elements.

[0031] As used herein, unless explicitly stated otherwise, the execution step “in response to A” does not indicate that the step is performed immediately after “A” occurs, and may include one or more intervention steps.

[0032] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments. As used herein, unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “the” are also intended to include the plural forms. It will be further understood that the terms “comprising,” “including,” “having,” “containing,” “comprise,” and / or “containing” as used herein specify the presence of the stated features, elements, and / or components, etc., but do not exclude the presence or addition of one or more other features, elements, components, and / or combinations thereof.

[0033] As used in this application, the term "circuit system" may refer to one or more or all of the following: (a) Hardware circuit implementation only (such as implementation in analog and / or digital circuits only), and (b) A combination of hardware circuitry and software, such as (if applicable): (i) A combination of (multiple) analog and / or digital hardware circuits and software / firmware, and (ii) Any part of the (multiple) hardware processors having software (including (multiple) digital signal processors working together to enable a device (such as a mobile phone or server) to perform various functions), software, and (multiple) memory), and (c) The operation of the hardware circuitry and / or processors, such as microprocessors or a portion thereof, requires software (e.g., firmware) for operation, but the software may not be present when operation is not required.

[0034] This definition of "circuit" applies to all uses of the term in this application, including in any claim. As another example, as used in this application, the term "circuit" also covers implementations of hardware circuitry or processors (or processors in general) or a portion thereof and their accompanying software and / or firmware. For example, and if applicable to a particular claim element, the term "circuit" also covers baseband integrated circuits or processor integrated circuits used in mobile devices or servers, cellular network devices, or other computing or networking devices.

[0035] As used herein, the term "communication network" refers to a network that conforms to any suitable communication standard, such as New Radio (NR), Long Term Evolution (LTE), LTE-A Advanced (LTE-A), Wideband Code Division Multiple Access (WCDMA), High-Speed ​​Packet Access (HSPA), Narrowband Internet of Things (NB-IoT), etc. Furthermore, communication between terminal devices and network devices in a communication network can be performed according to any suitable generated communication protocol, including but not limited to first-generation (1G), second-generation (2G), 2.5G, 2.75G, third-generation (3G), fourth-generation (4G), 4.5G, fifth-generation (5G), 5.5G, sixth-generation (6G) communication protocols and / or any other currently known or to be developed in the future. Embodiments of this disclosure can be applied to a variety of communication systems. Given the rapid development in communications, there will naturally also be future types of communication technologies and systems that can implement this disclosure. The scope of this disclosure should not be limited to the aforementioned systems only.

[0036] As used herein, the term "network device" refers to a node in a communications network through which terminal devices access the network and receive services. Network devices can refer to base stations (BS) or access points (APs), such as Node B (NodeB or NB), evolved Node B (eNodeB or eNB), NR NB (also known as gNB), Remote Radio Unit (RRU), Radio Head (RH), Remote Radio Head (RRH), repeater, Integrated Access and Backhaul (IAB) node, low-power node (such as femtoseconds, picoseconds), non-terrestrial network (NTN) or non-terrestrial network equipment (such as satellite network equipment, low Earth orbit (LEO) satellites, and geostationary Earth orbit (GEO) satellites), spacecraft network equipment, etc., depending on the terminology and technology applied. In some example embodiments, the Radio Access Network (RAN) split architecture includes a centralized unit (CU) and a distributed unit (DU) at the IAB donor node. An IAB node includes a mobile terminal (IAB-MT) portion that behaves like a UE toward its parent node, and a DU portion of the IAB node that behaves like a base station toward the next-hop IAB node.

[0037] The term "terminal device" refers to any terminal device capable of wireless communication. As an example and not a limitation, a terminal device may also be referred to as a communication device, user equipment (UE), subscriber station (SS), portable subscriber station, mobile station (MS), or access terminal (AT). Terminal devices can include, but are not limited to, mobile phones, cellular phones, smartphones, Voice over IP (VoIP) phones, wireless local loop phones, tablets, wearable terminal devices, personal digital assistants (PDAs), portable computers, desktop computers, image capture terminal devices (such as digital cameras), gaming terminal devices, music storage and playback devices, in-vehicle wireless terminal devices, wireless endpoints, mobile stations, laptop embedded devices (LEEs), laptop devices (LMEs), USB dongles, smart devices, wireless customer premises equipment (CPEs), Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. The terminal device may also correspond to the mobile terminal (MT) portion of an IAB node (e.g., a relay node). In the following description, the terms "terminal device," "communication device," "terminal," "user equipment," and "UE" are used interchangeably.

[0038] As used herein, the terms “resource,” “transmission resource,” “resource block,” “physical resource block” (PRB), “uplink resource,” or “downlink resource” can refer to any resource used to perform communication, such as communication between a terminal device and a network device, including resources in the time domain, frequency domain, spatial domain, code domain, or any other combination of time, frequency, spatial, and / or code domain resources used to achieve communication. In the following, unless explicitly stated otherwise, resources in both the frequency and time domains will be used as examples of transmission resources used to describe some exemplary embodiments of this disclosure. It should be understood that the exemplary embodiments of this disclosure are equally applicable to other resources in other fields.

[0039] The core network functions described herein can be implemented as core network entities comprising a combination of hardware processing circuitry and software and / or firmware including machine-readable instructions, or software including machine-readable instructions executable by at least one processor of the hardware processing circuitry. The hardware processing circuitry includes at least one processor and at least one memory storing machine-readable instructions executable by at least one processor of the hardware processing circuitry. The processor includes any one or a combination of an accelerator, a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, a digital signal processor, a central processing unit, a graphics processing unit, and a tensor processing unit. The memory includes any one or a combination of volatile or non-volatile memory (e.g., flash memory, cache, random access memory (RAM), and / or read-only memory (ROM)). The memory stores machine-readable instructions for execution by at least one processor of the hardware processing circuitry. The machine-readable instructions are executable by at least one processor of the hardware processing circuitry to cause the hardware processing circuitry to perform the actions or operations of the methods described herein. For example, the session management function described in this paper can be implemented as a session management entity, and the session management policy control function described in this paper can be implemented as a session management policy control entity.

[0040] Figure 1A An example communication environment 100A is shown in which exemplary embodiments of the present disclosure may be implemented. Communication environment 100A relates to apparatus 110, device 120, network entity 130, and network entity 140. Apparatus 110 can communicate bidirectionally with device 120. Device 120 can communicate bidirectionally with network entity 130. Network entity 130 can communicate bidirectionally with network entity 140. Figure 1A In the examples, device 110 may include a terminal device (e.g., a UE). In some example embodiments, device 110 may be implemented as a UE capable of supporting 5G and / or 4G communication. Device 120 may include a gateway, such as an evolved packet data gateway (ePDG). Network entity 130 may include network functions, such as an authentication server function (AUSF). Network entity 140 may include another network function, such as a unified data management (UDM) function.

[0041] It should be understood that Figure 1A The number of devices 110, 120, network entities 130 and 140 and their connections shown are for illustrative purposes only and do not impose any limitations. The communication environment 100A may include any suitable number of devices and / or equipment configured to implement the exemplary embodiments of this disclosure.

[0042] In the following description, for illustrative purposes, some example embodiments are described in which device 110 operates as a terminal device, device 120 operates as a device, network entity 130 includes network functions, and network entity 140 includes network functions. However, in some example embodiments, the operations described in connection with the terminal device can be implemented at the network device or other devices, and the operations described in connection with the network device can be implemented at the terminal device or other devices.

[0043] Communication in communication environment 100 can be implemented according to any suitable communication protocol, including but not limited to cellular communication protocols, wireless local area network communication protocols (such as IEEE 802.11), and / or any other currently known or future-developed protocols. Furthermore, communication can utilize any suitable wireless communication technology, including but not limited to: Code Division Multiple Access (CDMA), Frequency Division Multiple Access (FDMA), Time Division Multiple Access (TDMA), Frequency Division Duplex (FDD), Time Division Duplex (TDD), Multiple Input Multiple Output (MIMO), Orthogonal Frequency Division Multiple Access (OFDM), Discrete Fourier Transform Extended OFDM (DFT-s-OFDM), and / or any other currently known or future-developed technologies.

[0044] ePDG can be used between 3GPP networks and untrusted non-3GPP access networks (e.g., Wi-Fi). (See reference) Figure 2A The diagram 200A illustrates a non-roaming architecture within the EPS. As shown, the ePDG 201 can communicate with the UE 202 and the Packet Data Network (PDN) gateway 203. Specifically, the interface between the ePDG 201 and the PND gateway 203 may include an S2b interface.

[0045] In some cases, UE 202 can be powered on in untrusted non-3GPP Internet Protocol (IP) access networks via a PMIP-based S2b interface. A proxy Mobile Internet Protocol version 6 (PMIPv6) tunnel can be established between ePDG 201 and PDN Gateway (GW) 203. The Mobile Access Gateway (MAG) can be co-located with ePDG 201. An IP-secure (IPsec) tunnel between UE 202 and ePDG 201 can provide a virtual peer-to-peer link between UE 202 and the MAG on ePDG 201.

[0046] refer to Figure 2BThe diagram illustrates signaling flow 200B for the initial attach procedure on PMIP. This procedure can be performed for Home Roaming, Non-Roaming, and Lightweight Baseband Operation (LBO) architectures. Procedures (A), (B), (C), (D), and (E) within the dashed boxes are used for the S2b interface based on the General Packet Radio Service (GPRS) Tunneling Protocol (GTP). Before UE 202 initiates the establishment of an IPsec tunnel with ePDG 201, UE 202 can configure an IP address from an untrusted non-3GPP IP access network. The IP address can be used to send all Internet Key Exchange (IKE) version 2 (IKEv2) messages and as the source address in the outer header of the IPsec tunnel.

[0047] In the context of an LBO architecture, the 3GPP Authentication, Authorization, and Charging (AAA) Agent (AAA-p) 205 can act as an intermediary, forwarding messages from the 3GPP AAA Server (AAA-s) in the Home Public Land Mobile Network (HPLMN) to the PDN GW 203 in the Visiting Public Land Mobile Network (VPLMN). Messages from the PDN GW 203 in the VPLMN can be forwarded by the 3GPP AAA Agent 205 to the 3GPP AAA Server in the HPLMN. Messages between the PDN GW 203 in the VPLMN and the Home Policy and Charging Rules Function (hPCRF) 208 in the HPLMN can be forwarded by the Visit Policy and Charging Rules Function (vPCRF) 207 in the VPLMN.

[0048] In cases involving home-roaming and non-roaming architectures, vPCRF 207 and 3GPP AAA Agent 205 may not be involved.

[0049] If no dynamic policy provisioning is deployed, the process (B) in the dashed box (e.g., step 3) can be omitted. Instead, the PDN GW 203 can employ a statically configured policy.

[0050] When UE 202 has only an active PDN connection via 3GPP access and attempts to establish simultaneous PDN connections to different Access Point Names (APNs) via multiple access methods, Figure 2B The process can be used on the S2b interface to establish a PDN connection (referred to as the “first PDN connection” for the purposes of discussion) through an untrusted non-3GPP access via a PMIPv6 tunnel.

[0051] UE 202 can be authenticated and authorized to access untrusted non-3GPP access networks using access network-specific procedures. This procedure can be outside the scope of 3GPP.

[0052] Access authentication between UE 202 and the 3GPP Evolved Packet Core (EPC) can be performed. In roaming situations, signaling can be routed via the 3GPP AAA Proxy 205 in the VPLMN. As part of the AAA exchange for network access authentication, the Home Subscriber Server (HSS) / device implementing AAA 206 and / or the 3GPP AAA Proxy 205 can return to the non-3GPP IP access 204. A set of home / access operator policies can be implemented on the use of the local IP address or Internet Protocol version 6 (IPv6) prefix assigned by the access system upon successful authentication. Subscription data can be provided to the non-3GPP IP access 204 by the HSS / AAA 206.

[0053] The IKEv2 tunnel establishment process can be initiated by UE 202. UE 202 can indicate in the notification section of the IKEv2 authentication request that it supports Mobile IPsec Key Exchange (MOBIKE). The ePDG IP address required by UE 202 to form the IPsec tunnel can be discovered via a Domain Name System (DNS) lookup. UE 202 can request a connection to the PDN, which provides the APN. This request can be transmitted along with the IKEv2 request.

[0054] For networks supporting multiple mobility protocols, if any dynamic IP Mobility Management System (IPMS) decision is involved, that decision can be stored in the 3GPP AAA server. PDN GW 203 information can be returned as part of the response from the 3GPP AAA server to ePDG 201. If UE 202 has provided an APN, ePDG 201 can verify that UE 202 is permitted by the subscription. If UE 202 has not provided an APN, ePDG 201 can use the default APN. PDN GW 203 selection can then occur.

[0055] An additional name resolution procedure can be requested to be made to the DNS server. If the requested IP address is not present in the CFG_Request message from UE 202 to ePDG 201, and the requested IP address indicates that the attachment is an initial attachment, then ePDG 201 can perform a new PDN GW 203 selection procedure, for example, to allocate PDN GW 203, which allows for more efficient routing. UE 202 can indicate the type of address(s) (e.g., Internet Protocol version 4 (IPv4) or IPv6 prefix / address, or both) in the CFG_Request message sent to ePDG 201 during IKEv2 message exchange.

[0056] If the PDN requires additional authentication and authorization with an external AAA server, UE 202 may include authentication credentials. As part of the IKEv2 tunneling process, ePDG 201 may request UE 202 to provide UE 202's International Mobile Equipment Identity (IMEI) (software version). In this case, UE 202 may signal its IMEI (software version) to ePDG 201. ePDG 201 may, for example, forward the IMEI (software version) received from UE 202 to the 3GPP AAA server via a Service Working Model (SWm) interface.

[0057] If the operator policy requires IMEI checking, and if ePDG 201 is in the HPLMN, the IMEI check can be performed by the Equipment Identifier Register (EIR) in the home country. The 3GPP AAA server can request the EIR to perform the IMEI check by sending a Mobile Equipment (ME) Identity Check Request message (including ME identity and IMSI) to the EIR. Upon receiving an ME Identity Check Confirmation message (including the result of the IMSI check) from the EIR, the 3GPP AAA server can determine whether to continue or stop the authentication and authorization process. If the 3GPP AAA server determines to stop the authentication and authorization process, it can reply to ePDG 201 with a failure message containing an appropriate reason value.

[0058] If the operator policy requires IMEI checking, and if ePDG 201 is in a VPLMN, the IMEI check can be performed by the EIR in the access country. 3GPP AAA Agent 205 can request the EIR to perform the IMEI check by sending an ME identity check request message (including ME identity and IMSI) to the EIR. Upon receiving an ME identity check confirmation message (including the result of the IMSI check) from the EIR, 3GPP AAA Agent 205 can determine whether to continue or stop the authentication and authorization process. If 3GPP AAA Agent 205 determines to stop the authentication and authorization process, it can reply to ePDG 201 with a failure message with an appropriate reason value.

[0059] ePDG 201 can send agent binding update messages (including Mobile Node Network Access Identifier (MN-NAI), lifetime, APN, access technology type, handover indicator, Generic Routing Encapsulation (GRE) key for downlink services, UE address information, billing features, additional parameters, IMEI (software version), etc.) to PDN GW 203.

[0060] The access technology type option can be set to a value that matches the characteristics of non-3GPP IP access. The handover indicator can be set to indicate attachment on a new interface. Agent binding update messages can be protected. The MN-NAI can identify UE202. In the case of registration, the lifetime field can be set to a non-zero value, and in the case of deregistration, the lifetime field can be set to zero. When the PDN GW 203 supports multiple PDN connections, the PDN GW 203 can use the APN to determine which PDN to establish a connection for.

[0061] If ePDG 201 supports multiple PDN connections to a single APN, ePDG 201 can create and include PDN connection identities. UE address information can be set based on the CFG_Request in step 1 and the subscription profile, in the same way as the PDN type selected during initial attachment to the Evolved Universal Terrestrial Radio Access Network (E-UTRAN). If authorization credentials for additional authorization and authentication with an external AAA server are provided by UE 202 in step 2, the additional parameters can include these authentication credentials. If access to a given APN is required, PDN GW 203 can perform authentication and authorization with the external AAA server.

[0062] The PDN GW 203 can initiate the IP Connectivity Access Network (CAN) session establishment process with devices implementing the Policy and Charging Rules (PCRF) function. If available, devices implementing the PCRF can provide the PDN GW 203 with the Access Point Name, Aggregated Maximum Bit Rate (APN-AMBR), and Default Bearer Quality of Service (QoS) in the response message.

[0063] The selected PDN GW 203 can notify the 3GPP AAA server of its identity. The 3GPP AAA server can then notify the HSS 206 of the PDN GW 203's identity and the APN associated with the PDN connection to UE 202. A message including information identifying the Public Land Mobile Network (PLMN) to which the PDN GW 203 resides can be sent. This information can be registered in the HSS 206. If these parameters are not received in step 4, the PDN GW 203 can use only the APN-AMBR and default bearer QoS received from the 3GPP AAA server. Then, in step 5, the PDN GW address can be updated by the PDN GW 203 and hPCRF 208.

[0064] PDN GW 203 can handle the proxy binding update process (e.g., step 3) and create a binding cache entry for UE 202. PDN GW 203 can assign an IP address to UE 202. At step 6, PDN GW 203 can then send a proxy binding confirmation message (including MN-NAI, UE address information, GRE key for uplink services, and charging identifier (ID)) to ePDG 201, including the IP address(s) assigned to UE 202 (identified by the MN-NAI). If the corresponding proxy binding update message contains a PDN connection identifier, PDN GW 203 can confirm whether multiple PDN connections to a given APN are supported. Charging IDs can be assigned to PDN connections for charging-related purposes.

[0065] If UE 202 requests both an IPv4 address and an IPv6 prefix, both can be assigned. If the PDN GW203 operator specifies that only IPv4 addresses or only IPv6 prefixes are used for the APN, the PDN GW203 can assign only an IPv4 address or only an IPv6 prefix to UE 202. If UE 202 requests only an IPv4 address or only an IPv6 prefix, only one address / prefix can be assigned accordingly. The ePDG 201 can learn from the Proxy Binding Confirmation (PBA) whether the PDN GW 203 supports multiple PDN connections to the same APN.

[0066] After the proxy binding update process (i.e., step 3) is successful, ePDG 201 can be authenticated by UE 202 and can indicate to UE 202 that authentication and authorization with the external AAA server were successful. At step 7, the IPsec tunnel establishment process is completed for UE 202 and ePDG 201.

[0067] At step 8, ePDG 201 may send a final IKEv2 message with an IP address in the IKEv2 configuration payload. ePDG 201 may also include the identity of the associated PDN (APN) in the IKEv2 Identifier Responder (IDr) payload. If UE 202 provides an APN to ePDG 201, ePDG 201 may not change the provided APN.

[0068] An IP connection can be established from UE 202 to PDN GW 203. Any packets in the uplink direction can be tunneled by UE 202 to ePDG 201 using an IPSec tunnel. ePDG 201 can then tunnel the packets to PDN GW 203. Normal IP-based routing can then occur from PDN GW 203. In the downlink direction, packets (Home Address (HoA)) for UE 202 can reach PDN GW 203. At step 9, PDN GW 203 can tunnel the packets to ePDG 201 based on a bound cache entry, and ePDG 201 can tunnel the packets to UE 202 via an appropriate IPsec tunnel.

[0069] The aim of this study is to investigate the mechanism for supporting IP Multimedia Subsystem (IMS) voice via Wi-Fi connected to the 5G core network (5GC) in both standalone deployment and 3GPP-non-3GPP interoperability, without relying on non-3GPP interoperability features (N3IWF).

[0070] For example, an architecture could be studied to support an ePDG that connects to a device that implements AUSF (also referred to as “AUSF” for the purposes of discussion), a device that implements UDM functionality (also referred to as “UDM” for the purposes of discussion), and a device that implements Network Repository Function (NRF) functionality (also referred to as “NRF” for the purposes of discussion), without requiring an intermediate 3GPP AAA device.

[0071] The impact of using ePDG for attach and PDN connection establishment when interfacing with AUSF and UDM needs to be investigated. A 3GPP-N3GPP interoperability scheme needs to be studied without using N3IWF, aiming to minimize UE and network (NW) impacts in control plane management functions. Short-term use of voice via Wi-Fi for mobile network operators (MNOs) will be studied. Other use cases and scenarios can be considered lower priority, such as allowing Access Service Switching, Handover, and Split (ATSSS) functionality "on top." Support for standalone deployments, i.e., in the absence of 3GPP links, may be required.

[0072] It is necessary to enable the evolved residential gateway (eRG) to access the 5GC via the ePDG without affecting, for example, wired networks.

[0073] ePDG may require support from a 5G system (5GS). The authentication mechanism for UEs used to connect to the ePDG needs to be investigated.

[0074] Embodiments of this disclosure propose a new protocol stack for data session protection and authentication over heterogeneous networks (e.g., E2E protocol stacks). Specifically, the new protocol stack introduces a new interface between ePDG and AUSF.

[0075] refer to Figure 3 This illustrates a schematic diagram of an end-to-end (E2E) protocol stack 300 according to some example embodiments of the present disclosure. Figure 3 In the example, a new interface (i.e., service-based interface (SBI) 303) is proposed between ePDG 304 (also referred to as “enhanced ePDG” for discussion purposes) and AUSF 305 for non-3GPP access. As shown, SBI 303 is associated with a new interface stack 301 on ePDG 304 and a new interface stack 302 on AUSF 305, respectively.

[0076] In this way, ePDG can communicate with AUSF via the proposed interface stack to transmit authentication messages efficiently over heterogeneous networks.

[0077] In some example embodiments, the architecture involving ePDG and AUSF may include additional devices for data session protection and authentication on heterogeneous networks. (Reference) Figure 4A , Figure 4A A schematic diagram of an example architecture 400A of an E2E protocol stack according to some example embodiments of the present disclosure is shown.

[0078] exist Figure 4A In the example, 5G UE 410 can connect to an enhanced ePDG (also referred to as "ePDG" for the purposes of discussion) 430 via a non-3GPP access 420. An IKEv2 tunnel is established between 5G UE 410 and ePDG 430. ePDG 430 connects to AUSF 440, and AUSF 440 connects to UDM 450. Architecture 400A can support both 4G UE and 5G UE 410. That is, in some example implementations, 5G UE 410 can be in 4G mode or operate as a 4G UE. 5G UE 410 can be routed to AUSF 440 and then to UDM 450. During the authentication vector acquisition phase, AUSF 440 can communicate with UDM 450. Additionally, either AUSF 440 or UDM 450 can be included in a 3GPP network (e.g., 5GC).

[0079] In this way, 5G UE 410 can be efficiently authenticated in architecture 400A via heterogeneous networks based on ePDG 430. Communication between 5G UE 410 and 3GPP networks can be performed and secured using ePDG 430. ePDG 430 can be supported by 5GC, which includes AUSF 440 or UDM 450. See below for further details. Figures 5 to 10 Discussion and Figure 4A More details about the architecture of the 400 A.

[0080] refer to Figure 4B , Figure 4B A schematic diagram of an example architecture 400B of an E2E protocol stack according to some example embodiments of this disclosure is shown. Figure 4A In the example, 5G UE 411 can connect to enhanced ePDG 431 via non-3GPP access 421. An IKEv2 tunnel is established between 5G UE 411 and ePDG 431. ePDG 431 connects to AUSF 441. AUSF 441 connects to UDM 451. HSS 461 connects to both AUSF 441 and UDM 451.

[0081] Architecture 400B can support a 4G UE or 5G UE 411 in 4G mode, or act as a 4G UE. AUSF 441, UDM 451, or HSS 461 can be included in a 3GPP network (e.g., a 5G network). During the authentication vector acquisition phase, AUSF 441 can communicate with HSS 461 via UDM 451. In some example embodiments, AUSF 441 can communicate directly with HSS 461.

[0082] In this way, 5G UE 411 can be efficiently authenticated in architecture 400B via heterogeneous networks based on ePDG 431. Communication between 5G UE 411 and 3GPP networks can be performed and protected using ePDG 431. ePDG 431 can be supported by 3GPP networks, including AUSF 441, UDM 451, or HSS 461. See below for further details. Figure 11 , Figure 12A and Figure 12B Discussion and Figure 4B More details about the 400B architecture.

[0083] Embodiments of this disclosure present several solutions for data session protection. In these solutions, a device determines a security key (referred to as a "first security key" for the purpose of discussion) for protecting a data session between the device and an equipment, based at least on a session key. The device is a non-3GPP access network, such as a Wi-Fi network, and is connected to the equipment. The session key is used by a network entity in a 3GPP network (e.g., a 5G network) to determine another security key (referred to as a "second security key" for the purpose of discussion). Using the data session, the device performs communication based on the first security key.

[0084] In this way, the data session is protected by a first security key and a second security key, determined at least based on the session key. Communication is performed by using the protected data session in an efficient manner. Therefore, the security of communication between devices (e.g., UEs) in non-3GPP access networks and 3GPP networks is improved.

[0085] In another solution, at least one parameter is sent from a network entity to the device via a device in a non-3GPP access network. The device is connected to the network entity. Based on this at least one parameter, the device determines a security key (also referred to as the "first security key" for the purposes of discussion) to protect the data session between the device and the network entity. At least one parameter is used by the network entity in the 3GPP network to determine another security key (also referred to as the "second security key" for the purposes of discussion). The device then performs communication based on the first security key using the data session.

[0086] In this way, the data session is protected by a first security key and a second security key, which are determined by using (multiple) identical parameters. Communication is performed by using the protected data session in an efficient manner. Therefore, the security of communication between a device (e.g., a UE) in a non-3GPP access network and a 3GPP network is improved.

[0087] Several solutions of this disclosure have been briefly described. The principles and implementation methods of this disclosure will now be described in detail. Example embodiments of this disclosure will be described in detail below with reference to the accompanying drawings.

[0088] It should be understood that Figures 5 to 12B The sequence of actions shown is merely an example and not a limitation. Actions can be performed in any suitable manner. Reference Figures 5 to 12B The described example embodiments can be implemented individually or in any combination. For example, one or more example embodiments shown in a single figure can be combined with one or more example embodiments shown in one or more other figures.

[0089] Additionally, Figures 5 to 12B The process described is merely an example and not a limitation. Figures 5 to 12B The process indicated by the dashed lines is optional and may be excluded from the process according to some exemplary embodiments of this disclosure.

[0090] refer to Figure 5 , Figure 5 Signaling flow 500 of a data session protection process according to some embodiments of this disclosure is illustrated. For discussion purposes, reference will be made to... Figure 1A Discuss signaling flow 500. Figure 5 Involving Figure 1A The device 110, equipment 120, network entity 130 and network entity 140.

[0091] In some example implementations, apparatus 110 may be implemented as or include a terminal device (e.g., a UE) in a non-3GPP access network (e.g., non-3GPP access network 420). For example, the non-3GPP access network may be a Wi-Fi network. Figure 5 Device 110 can be implemented as a 5G UE 410. Device 120 to which device 110 is connected can be implemented as or include a gateway (e.g., ePDG 430). Network entity 130 can be implemented as or include a device implementing network functions (e.g., AUSF 440). Network entity 140 can be implemented as or include a device implementing network functions (e.g., UDM 450). Network entities 130 and 140 are in a 3GPP network (e.g., a 5G network).

[0092] In operation, device 110 may send (5010) a request (also referred to as the “first request” for authenticating device 110 to the 3GPP network) to device 120. This request may include an encrypted identifier of device 110. In some example embodiments, the encrypted identifier may include the device’s Subscription Hidden Identifier (SUCI). Accordingly, device 120 may receive (5020) the first request from device 110.

[0093] The first request can be used to initiate a process protected by the data session of device 110. In some example embodiments, device 110 may determine whether it is connected to device 120 before sending the first request. If device 110 determines that it is connected to device 120, it may send the first request.

[0094] Upon receiving the first request, device 120 may send (5025) to network entity 130 a request to 3GPP network authentication device 110 (also referred to as the "second request" for the purposes of discussion). The second request may include an encrypted identifier of device 110, a serving network identifier of the 3GPP network configured by device 120, or an indication indicating that the second request is associated with device 120. Additionally, the serving network identifier may include a Public Land Mobile Network (PLMN) identifier of the 3GPP network.

[0095] In some example embodiments, the 3GPP network may include or may be a 5G network, and the Serving Network Identifier of the 3GPP network may be a Serving Network (SN) name that indicates the 5G network. The PLMN identifier may be associated with the 5G network. Additionally, this indication can be used to indicate that device 120 is involved in a process for data session protection.

[0096] Accordingly, network entity 130 can receive (5027) the second request from device 120. Then, network entity 130 can send (5030) a request (also referred to as the "third request" for discussion purposes) to network entity 140 in the 3GPP network for the 3GPP network authentication device 110. The third request may include various information, such as the encrypted identifier of device 110, the serving network identifier of the 3GPP network configured by device 120, and indications indicating that the third request is associated with device 120, etc.

[0097] Network entity 140 receives (5040) a third request from network entity 130 and determines (5050) authentication information for device 110 based on the serving network identifier. In some example embodiments, the authentication information may indicate a value to be sent to device 110 for authentication, such as an Authentication and Key Agreement (AKA) challenge value or an Authentication and Key Agreement Master (AKA') challenge value.

[0098] Then, network entity 140 sends (5060) a response to the third request (also referred to as a “third response” for the purposes of discussion) to network entity 130. The third response includes authentication information. Accordingly, network entity 130 may receive (5070) the third response from network entity 140.

[0099] Subsequently, at point 5075, a process for authenticating device 110 based on authentication information can be executed. Specifically, network entity 130 can receive response information from device 110 from device 120. The response information can be associated with authentication information. For example, if the authentication information is an AKA challenge value, the response information may include an AKA response value associated with the AKA challenge value. Alternatively, if the authentication information is an AKA' challenge value, the response information may include an AKA' response value associated with the AKA' challenge value.

[0100] Then, network entity 130 can verify the response information based on authentication information. For example, it can verify the AKA response value based on the AKA challenge value. Alternatively, it can verify the AKA response value based on the AKA' challenge value.

[0101] In some example embodiments, if the verification of the response information is successful, the device 110 is successfully authenticated. In this case, the device 110 can be triggered to perform the remainder of the data session protection process.

[0102] Device 110 determines (5080) a security key (also referred to as the “first security key” for the purpose of discussion) for protecting data sessions (e.g., Protocol Data Unit (PDU) sessions) between device 110 and equipment 120, based at least on the session key. The session key is used by network entity 130 to determine another security key (also referred to as the “second security key” for the purpose of discussion).

[0103] In some example implementations, device 120 may send a response to the first request (referred to as the "first response" for the purposes of discussion) to the device. Upon receiving the first response, device 110 may determine a first security key. For example, if the verification of the response information is successful, network entity 130 may notify device 120. Device 120 may then send the first response to device 110.

[0104] Similar to device 110, if the response information is successfully verified, network entity 130 can then execute the remainder of the data session protection process. Network entity 130 determines (5090) the second security key based at least on the session key.

[0105] In some example embodiments, the session key may include a Master Session Key (MSK), an Extended Master Session Key (EMSK), etc. Additionally, the session key may be determined based on a key (e.g., a master key) used to authenticate the 3GPP network to device 110. Additionally, in some example implementations, both device 110 and network entity 130 may use the same session key, which may be determined separately on both sides. Figure 5 For examples, refer to Figure 7Discuss the process of determining the session key.

[0106] After determining the second security key, network entity 130 sends (5100) the second security key to device 120. Accordingly, device 120 receives (5110) the second security key from network entity 130 and performs (5130) communication using a data session based on the second security key.

[0107] For example, for device 110, communication (5120) is performed using a data session based on a first security key. In some example embodiments, the communication may be between device 110 and device 120 via a data session, which may be protected by a security key.

[0108] For example, device 110 can perform communication with the PDN via device 120. In this case, device 110 can encrypt data packets used for communication using a first security key and send the encrypted data packets to device 120. Device 120 can receive the encrypted data packets and decrypt them based on a second security key. Device 120 can then send the decrypted data packets to the PDN.

[0109] The PDN can send data packets to device 120. Device 120 can then receive the data packets and encrypt them using a second security key. Subsequently, device 120 can send the encrypted data packets to device 110. Device 110 can use a first security key to receive and decrypt the encrypted data packets.

[0110] Additionally, device 120 may store the second security key in context information associated with device 110. The context information may include the second security key, configuration information for data session security, or a temporary identifier of device 110. For example, the context information may be the context of device 110, such as the UE context. The temporary identifier of device 110 may be used by device 120 to identify device 110.

[0111] In some example embodiments, multiple data sessions between device 110 and device 120 can be supported. If communication based on another data session is to be performed, the context information stored in device 120 can be reused.

[0112] In this way, device 110 can efficiently perform communication using a data session protected by a first security key and a second security key determined at least based on the session key. Device 110 can be authenticated by the 3GPP network based on device 120, network entity 130, and network entity 140. Therefore, the security and efficiency of communication can be improved.

[0113] refer to Figure 6 This illustrates an example signaling flow 600 of a data session protection process according to some embodiments of this disclosure. Regarding... Figure 6 The example embodiments discussed may be considered as references. Figure 5 The implementation of the example embodiments discussed. For the purposes of discussion, reference will be made to... Figure 1A Discuss signaling flow 600.

[0114] Figure 6 This involves 5G UE 610, non-3GPP access 612, enhanced ePDG (also referred to as "ePDG" for discussion purposes) 620, AUSF 630, and UDM 640. 5G UE 610 can be... Figure 1A The implementation of device 110 in the middle. The enhanced ePDG620 can be Figure 1A The implementation of device 120 in AUSF 630. Figure 1A The implementation of network entity 130 in the UDM640. Figure 1A The implementation method of network entity 140 in the text.

[0115] The 5G UE 610 can be in a non-3GPP access network (e.g., Wi-Fi) and connected to the enhanced ePDG 620. The AUSF 630 and UDM can be in a 3GPP network (e.g., a 5G network).

[0116] During operation, at point 6001, 5G UE 610 can perform enhanced ePDG selection. For example, 5G UE 610 can select enhanced ePDG 620 from multiple ePDGs. Then, at point 6002, 5G UE 610 can determine that 5G UE 610 is connected to enhanced ePDG 620. In this case, the SUCI of 5G UE 610 can be sent to enhanced ePDG 620 in the initial message.

[0117] The IKEv2 tunnel establishment process can be executed, such as... Figure 6 The dashed box in the diagram illustrates this. Specifically, at 6003, the IKE_SA_INIT switching process can be initiated by the 5G UE 610 and executed between the 5G UE 610 and the enhanced ePDG 620. At 6004, the 5G UE 610 can send an IKE_AUTH request message to the enhanced ePDG 620, which includes the UE ID of the 5G UE 610. For example, the UE ID could be the SUCI of the 5G UE 610.

[0118] Subsequently, at 6005, the enhanced ePDG 620 can use the SBI (e.g., by calling the application programming interface (API)). Figure 3 The SBI 303 in the diagram is directed towards the 5GS Home Network (HM). Specifically, at 6006, the enhanced ePDG 620 can use the interface to send a Nausf_UEAuthentication_Authenticate request message to the AUSF 630. The Nausf_UEAuthentication_Authenticate request message can include the SUCI and SN name of the 5G UE 610 as 5G:ePDG:PLMN ID. The PLMN ID can be the PLMN ID of the 5G network (which includes the AUSF 630 and UDM 640) and is configured in the enhanced ePDG 620.

[0119] Alternatively or additionally, a separate ePDG indication may be included as an additional parameter in the Nausf_UEAuthentication_Authenticate request message to indicate that the message is for the enhanced ePDG 620 and that there is no subsequent expected registration from the enhanced ePDG 620 to the UDM 640 for the UE (i.e., 5G UE 610).

[0120] Then, AUSF 630 can route the Nausf_UEAuthentication_Authenticate request message from the enhanced ePDG 620 to the UDM 640. Specifically, at 6007, AUSF 630 can send a Nudm_UEAuthentication_Get request message to the UDM 640, which includes the SUCI and SN name. A separate ePDG indication can also be included in the Nudm_UEAuthentication_Get request message to indicate to the UDM 640 that the message is for the enhanced ePDG 620 and that there is no subsequent registration from the enhanced ePDG 620 to the UDM 640 for the 5G UE 610.

[0121] At 6008, UDM 640 receives the SN name in the message and can know that the message is used for UE authentication via the enhanced ePDG 620. UDM 640 can perform a SUCI de-hiding procedure for the Subscription Permanent Identifier (SUPI) or International Mobile Subscriber Identity (IMSI) of the 5G UE 610 on the SUCI. UDM 640 can select the EAP-AKA master (EAP-AKA') method for UE authentication of the 5G UE 610. In this case, UDM 640 can determine the AKA' challenge (also referred to as "EAP-AKA' challenge" for the 5G UE 610) value. In some example embodiments, the EAP-AKA method is already supported by the 5G UE 610.

[0122] Subsequently, at position 6009, UDM 640 sends a Nudm_UEAuthentication_Get response message to AUSF 630, including the SUPI or IMSI of 5G UE 610 and the AKA' challenge value. At position 6010, AUSF 630 can send a Nausf_UEAuthentication_Authenticate response message to the enhanced ePDG 620, including an EAP request message for 5G UE 610 and the AKA' challenge value. The EAP request message can be used to request an EAP-AKA' challenge for UE authentication from 5G UE 610.

[0123] The enhanced ePDG 620 can send an IKE_AUTH response message to the 5G UE 610 at point 6011. The IKE_AUTH response message may include an EAP request message and an AKA' challenge value. After receiving the IKE_AUTH response message, the 5G UE 610 can determine the AKA' response value associated with the AKA' challenge value, and at point 6012, send an IKE_AUTH request message to the enhanced ePDG 620, including an EAP response message to the EAP request message and the AKA' response value.

[0124] At 6014, the 5G UE 610 determines a security key (also referred to as the "first security key" for IPsec purposes) for protecting the data session between the 5G UE 610 and the enhanced ePDG 620, based at least on a session key (e.g., MSK and / or EMSK). In some example embodiments, the MSK or EMSK may be determined by the 5G UE 610. (Refer to...) Figure 7 Describe the determination of MSK or EMSK.

[0125] It should be understood that the procedure at 6014, which is executed after the procedure at 6012, is for illustrative purposes only and does not impose any limitations. In the exemplary embodiments of this disclosure, the procedures can be executed in any suitable order. For example, the procedure at 6014 can be executed after the procedures at 6011, 6018, or 6019.

[0126] The enhanced ePDG 620 can route the IKE_AUTH request message received at 6012 to the AUSF 630 for authentication. Specifically, at 6013, the enhanced ePDG 620 can send a Nausf_UEAuthentication_Authenticate request message to the AUSF 630, including an EAP response message and an AKA' response value. At 6015, the AUSF 630 verifies the AKA' response value, for example, based on the AKA' challenge value.

[0127] Specifically, at 6015, if verification is successful, AUSF 630 determines a security key (also referred to as the "second security key" for IPsec purposes) for protecting the data session between the 5G UE 610 and the enhanced ePDG 620, based at least on the session key (e.g., MSK and / or EMSK). In some example embodiments, the MSK or EMSK may be determined by AUSF 630. (See reference...) Figure 7 Describe the determination of MSK or EMSK.

[0128] At 6016, AUSF 630 sends a Nausf_UEAuthentication_Authenticate response message that includes a second security key and an EAP success message indicating successful AKA' response. At 6017, the enhanced ePDG 620 may, for example, store the second security key in the UE context associated with the 5G UE 610.

[0129] At 6018, the enhanced ePDG 620 can send an IKE_AUTH response message, including an EAP success message, to the 5G UE 610. At 6019, an IPsec security association (SA) can be established between the 5G UE 610 and the enhanced ePDG 620.

[0130] At 6020, the UE context may include a security configuration for the data session, a temporary UE ePDG identity for the 5G UE 610, and a second security key. The UE context can be maintained in both the 5G UE 610 and the enhanced ePDG 620.

[0131] At point 6021, the 5G UE 610 performs communication using a data session based on a first security key, and the enhanced ePDG 620 performs communication using a data session based on a second security key. For example, the PDN can communicate with the 5G UE 610 via the enhanced ePDG 620. In some example embodiments, further authentication may not be required for each new data session (e.g., PDU session). In this case, the UE context maintained in the 5G UE 610 and the enhanced ePDG 620 can be reused.

[0132] For example, the 5G UE 610 can perform communication with the PDN via the enhanced ePDG 620. In this case, the 5G UE 610 can encrypt the data packets used for communication using a first security key and send the encrypted data packets to the enhanced ePDG 620. The enhanced ePDG 620 can receive the encrypted data packets and decrypt them based on a second security key. The enhanced ePDG 620 can then send the decrypted data packets to the PDN.

[0133] The PDN can send data packets to the enhanced ePDG 620. The enhanced ePDG 620 can then receive the data packets and encrypt them using a second security key. Subsequently, the enhanced ePDG 620 can send the encrypted data packets to the 5G UE 610. The 5G UE 610 can use a first security key to receive and decrypt the encrypted data packets.

[0134] In this way, the 5G UE 610 can be authenticated to the 3GPP network and can communicate with the 3GPP network efficiently via the enhanced ePDG 620. Communication between the 5G UE 610 and the enhanced ePDG 620 can be performed based on a data session protected by a first security key and a second security key determined at least based on the session key. Therefore, the security and efficiency of data session protection can be improved.

[0135] refer to Figure 7 The diagram 700 illustrates a process for generating a security key according to some embodiments of the present disclosure. Figure 7 The process in the example can be derived from Figure 1A This is implemented using device 110 and / or network entity 130. In some example embodiments, Figure 7 The process in the example can be derived from Figure 6 It is implemented using 5G UE 610 and / or AUSF 630.

[0136] At 710, the EAP method credential can be associated with EAP. At 720, EAP authentication can be performed. For example, the encryption key (CK') and integrity key (IK') for the EAP-AKA' method can be determined independently based on the long-term key in the AUSF, UDM, or UE. Then, CK' and IK' can be used to independently determine the master key by the AUSF or UE. At 730, the master key can be used to determine the MSK or EMSK. In some example embodiments, the MSK and / or EMSK can be used to determine the session key. For example, the MSK or EMSK can be determined as the session key. Then, the security key (denoted as "K") can be determined at 740. ePDG "), such as the first security key or the second security key.

[0137] In some example implementations, the master key can be implemented as follows: MK = PRF'(IK'|CK',"EAP-AKA'"|Identity)(1) Here, PRF' refers to the pseudo-random function prime number, which can be obtained from the EAP-response message.

[0138] Specifically, MSK and EMSK can be part of the master key. For example, MSK and EMSK can be determined as follows: MSK = MK[640..1151](2) EMSK = MK[1152..1663](3) Additionally, several keys determined based on the master key may exist, as follows: K_encr = MK[0..127](4) K_aut = MK[128..383](5) K_re = MK[384..639](6) Where K_encor refers to the encryption key, K_aut refers to the authentication key, and K_re refers to the re-authentication key.

[0139] In this way, the MSK and EMSK can be determined independently by the AUSF and the UE. The first security key can be determined independently by the UE based at least on the session key (i.e., MSK or EMSK), and the second security key can be determined independently by the AUSF based at least on the session key (i.e., MSK or EMSK). Therefore, the determination of the first and second security keys can be performed in an efficient manner.

[0140] In some example embodiments, at least one parameter can be used to determine the security key used for data session protection. (See reference) Figure 8This illustrates a signaling flow 800 of a data session protection process according to some embodiments of the present disclosure. For discussion purposes, reference will be made to... Figure 1A Discuss signaling flow 800. Figure 8 Involving Figure 1A The device 110, equipment 120, network entity 130 and network entity 140.

[0141] In some example implementations, device 110 may be implemented as or include a terminal device (e.g., UE 410) in a non-3GPP access network (e.g., non-3GPP access network 420). For example, the non-3GPP access network may be a Wi-Fi network. Device 120 to which device 110 is connected may be implemented as or include a gateway (e.g., ePDG 430). Network entity 130 may be implemented as or include a device implementing network functions (e.g., AUSF 440). Network entity 140 may be implemented as or include a device implementing network functions (e.g., UDM 450). Network entities 130 and 140 are in a 3GPP network (e.g., a 5G network).

[0142] In operation, device 110 may send (8001) a request (also referred to as the “first request” for authenticating device 110 to the 3GPP network) to device 120. This request may include an encrypted identifier of device 110. In some example embodiments, the encrypted identifier may include the device’s SUCI. Accordingly, device 120 may receive (8002) the first request from device 110.

[0143] The first request can be used to initiate the data session protection process of device 110. In some example embodiments, device 110 may determine whether it is connected to device 120 before sending the first request. If device 110 determines that it is connected to device 120, it may send the first request.

[0144] Upon receiving the first request, device 120 may send (8003) to network entity 130 a request to 3GPP network authentication device 110 (also referred to as the "second request" for the purposes of discussion). The second request may include an encrypted identifier of device 110, a serving network identifier of the 3GPP network configured by device 120, or an indication indicating that the second request is associated with device 120. Additionally, the serving network identifier may include the PLMN identifier of the 3GPP network.

[0145] In some example embodiments, the 3GPP network may include a 5G network, and the serving network identifier of the 3GPP network may include an SN name indicating the 5G network. The PLMN identifier may be associated with the 5G network. Additionally, this indication can be used to indicate that device 120 is involved in the process.

[0146] Accordingly, network entity 130 can receive (8004) a second request from device 120. Then, network entity 130 can send (8010) a request (also referred to as a “third request” for the purpose of discussion) to network entity 140 in the 3GPP network for the purpose of requesting the 3GPP network authentication device 110. The third request may include the encrypted identifier of device 110, the serving network identifier of the 3GPP network configured by device 120, or an indication indicating that the third request is associated with device 120.

[0147] Accordingly, network entity 140 receives (8020) a third request from network entity 130. After receiving the third request, network entity 140 determines (8030) authentication information for device 110 based on the serving network identifier. In some example embodiments, the authentication information may indicate a value to be sent to device 110 for authentication, such as an AKA challenge value or an AKA' challenge value.

[0148] Then, network entity 140 sends (8040) a response to the third request (also referred to as a “third response” for the purposes of discussion) to network entity 130. The third response includes authentication information. Accordingly, network entity 130 may receive (8050) the third response from network entity 140.

[0149] Subsequently, at 8055, a process for authenticating device 110 based on authentication information can be executed. Specifically, network entity 130 can receive response information from device 110 from device 120. The response information can be associated with authentication information. For example, if the authentication information is an AKA challenge value, the response information may include an AKA response value associated with the AKA challenge value. Alternatively, if the authentication information is an AKA' challenge value, the response information may include an AKA' response value associated with the AKA' challenge value.

[0150] Then, network entity 130 can verify the response information based on authentication information. For example, it can verify the AKA response value based on the AKA challenge value. Alternatively, it can verify the AKA response value based on the AKA' challenge value.

[0151] In some example embodiments, if the verification of the response information is successful, device 110 can be successfully authenticated, and network entity 130 can be triggered to perform the remainder of the data session protection process. Network entity 130 may determine or receive at least one parameter. This at least one parameter is used by the device to determine a security key (referred to as the "first security key" for the purposes of discussion) for protecting the data session between device 110 and device 120. The at least one parameter may include a random value, a counter value, etc.

[0152] Network entity 130 determines (8060) another security key (referred to as the "second security key" for discussion purposes) based on at least one parameter. Specifically, network entity 130 may determine the second security key based on a session key, the identifier of device 110, or at least one parameter. In particular, the session key may include MSK, EMSK, etc. Additionally, the session key may be determined based on a key used to authenticate device 110 to the 3GPP network (e.g., a master key). (See reference...) Figure 10 Describe the process used to determine the second security key.

[0153] After determining the second security key, network entity 130 sends (8070) the second security key and at least one parameter to device 120. Accordingly, device 120 receives (8080) the second security key and at least one parameter from network entity 130, and then sends (8090) the at least one parameter to device 110.

[0154] Accordingly, device 110 receives (8100) the at least one parameter from device 120. Then, device 110 determines (8110) a first security key for protecting the data session based on at least the at least one parameter. (See reference...) Figure 10 Describe the process used to determine the first security key.

[0155] Specifically, device 110 may determine the first security key based on a session key, an identifier of device 110, or at least one parameter. In particular, the session key may include MSK, EMSK, etc. Additionally, the session key may be determined based on a key (e.g., a master key) used to authenticate device 110 to the 3GPP network.

[0156] After determining the first security key, device 110 performs communication (8120) using a data session based on the first security key. Device 120 performs communication (8130) using a data session based on a second security key. In some example embodiments, communication can occur between device 110 and device 120.

[0157] For example, device 110 can perform communication with the PDN via device 120. In this case, device 110 can encrypt data packets used for communication using a first security key and send the encrypted data packets to device 120. Device 120 can receive the encrypted data packets and decrypt them based on a second security key. Device 120 can then send the decrypted data packets to the PDN.

[0158] The PDN can send data packets to device 120. Device 120 can then receive the data packets and encrypt them using a second security key. Subsequently, device 120 can send the encrypted data packets to device 110. Device 110 can use a first security key to receive and decrypt the encrypted data packets.

[0159] Additionally, device 120 may store the second security key in context information associated with device 110. The context information may include the second security key, configuration information for data session security, or a temporary identifier of device 110. For example, the context information may be the UE context of device 110. The temporary identifier of device 110 may be used by device 120 to identify device 110.

[0160] In some example embodiments, multiple data sessions between device 110 and device 120 can be supported. If communication based on another data session is to be performed, the context information stored in device 120 can be reused.

[0161] In this way, device 110 can efficiently perform communication using a data session protected by a first security key and a second security key determined based on at least one parameter. Device 110 can be authenticated by the 3GPP network based on device 120, network entity 130, and network entity 140. Therefore, the security and efficiency of communication can be improved.

[0162] refer to Figure 9 This illustrates an example signaling flow 900 of a data session protection process according to some embodiments of this disclosure. Regarding... Figure 9 The example embodiments discussed may be considered as references. Figure 8 The implementation of the example embodiments discussed. For the purposes of discussion, reference will be made to... Figure 1A Discuss signaling flow 900.

[0163] Figure 9 This involves 5G UE 910, non-3GPP access 912, enhanced ePDG (also referred to as "ePDG" for discussion purposes) 920, AUSF 930, and UDM 940. 5G UE 910 can be... Figure 1AThe implementation of device 110 in the middle. The enhanced ePDG920 can be Figure 1A The implementation of device 120 in AUSF 930. Figure 1A The implementation of network entity 130 in the UDM940. Figure 1A The implementation method of network entity 140 in the text.

[0164] The 5G UE 910 can be in a non-3GPP access network (e.g., Wi-Fi) and connect to the enhanced ePDG 920. The AUSF 930 and UDM can be in a 3GPP network (e.g., a 5G network).

[0165] During operation, at point 9001, 5G UE 910 can perform enhanced ePDG selection. For example, 5G UE 910 can select enhanced ePDG 920 from multiple ePDGs. Then, at point 9002, 5G UE 910 can determine that 5G UE 910 is connected to enhanced ePDG 920. In this case, the SUCI of 5G UE 910 can be sent to enhanced ePDG 920 in the initial message.

[0166] The IKEv2 tunnel establishment process can be executed, such as... Figure 9 The dashed box in the diagram illustrates this. Specifically, at 9003, the IKE_SA_INIT exchange process can be initiated by the 5G UE 910 and executed between the 5G UE 910 and the enhanced ePDG 920. At 9004, the 5G UE 910 can send an IKE_AUTH request message to the enhanced ePDG 920, including the UE ID of the 5G UE 910. For example, the UE ID could be the SUCI of the 5G UE 910.

[0167] Subsequently, at point 9005, the enhanced ePDG 920 can be used by calling the API. Figure 3 The SBI 303 in the image faces the 5GS HM. Specifically, at 9006, the enhanced ePDG 920 can use the interface to send a Nausf_UEAuthentication_Authenticate request message to the AUSF 930. The Nausf_UEAuthentication_Authenticate request message can include the SUCI and SN name of the 5G UE 910 as 5G:ePDG:PLMN ID. The PLMN ID can be the PLMN ID of the 5G network including the AUSF 930 and UDM 940, and is configured in the enhanced ePDG 920.

[0168] Alternatively or additionally, a separate ePDG indication may be included as an additional parameter in the Nausf_UEAuthentication_Authenticate request message to indicate that the message is for the enhanced ePDG 920 and that there is no subsequent expected registration from the enhanced ePDG 920 to the UDM 940 for the UE (i.e., 5G UE 910).

[0169] Then, AUSF 930 can route the Nausf_UEAuthentication_Authenticate request message from the enhanced ePDG 920 to UDM 940. Specifically, at 9007, AUSF 930 can send a Nudm_UEAuthentication_Get request message to UDM 940, including the SUCI and SN names. A separate ePDG indication can also be included in the Nudm_UEAuthentication_Get request message to indicate to UDM 940 that the message is for the enhanced ePDG 920 and that there is no subsequent expected registration from the enhanced ePDG 920 to UDM 940 for the 5G UE 910.

[0170] At 9008, UDM 940 receives the SN name in the message and can know that the message is used for UE authentication via the enhanced ePDG 920. UDM 940 can perform a SUCI de-hiding procedure for the SUPI or IMSI of the 5G UE 910 on the SUCI. UDM 940 can select the EAP-AKA' method for UE authentication of the 5G UE 910. In this case, UDM 940 can determine the AKA' challenge (also referred to as "EAP-AKA' challenge" for the 5G UE 910 for the purposes of discussion) value. In some example embodiments, the EAP-AKA method is already supported by the 5G UE 910.

[0171] Subsequently, at position 9009, UDM 940 sends a Nudm_UEAuthentication_Get response message to AUSF 930, including the SUPI or IMSI of 5G UE 910 and the AKA' challenge value. At position 9010, AUSF 930 can send a Nausf_UEAuthentication_Authenticate response message to the enhanced ePDG 920, including an EAP request message for 5G UE 910 and the AKA' challenge value. The EAP request message can be used to request an EAP-AKA' challenge for UE authentication from 5G UE 910.

[0172] The enhanced ePDG 920 can send an IKE_AUTH response message to the 5G UE 910 at 9011. The IKE_AUTH response message may include an EAP request message and an AKA' challenge value. After receiving the IKE_AUTH response message, the 5G UE 910 can determine the AKA' response value associated with the AKA' challenge value, and at 9012, send an IKE_AUTH request message to the enhanced ePDG 920, including an EAP response message to the EAP request message and the AKA' response value.

[0173] The enhanced ePDG 920 can route the IKE_AUTH request message received at 9012 to the AUSF 930 for authentication. Specifically, at 9013, the enhanced ePDG 920 can send a Nausf_UEAuthentication_Authenticate request message to the AUSF 930, including an EAP response message and an AKA' response value. At 9014, the AUSF 930 can verify the AKA' response value based on the AKA' challenge value.

[0174] In some example embodiments, if authentication is successful, the 5G UE 910 can be successfully authenticated, and the AUSF 930 can be triggered to perform the remainder of the data session protection process. The AUSF 930 can determine or receive at least one parameter. At least one parameter can be used by the 5G UE 910 to determine a security key (referred to as the “first security key” for the purposes of discussion) for protecting the data session (e.g., PDU session) between the 5G UE 910 and the enhanced ePDG 920. At least one parameter can include a random value, a counter value, etc.

[0175] If the verification is successful, at 9014, AUSF 930 determines a security key for IPsec (also referred to as the “second security key” for discussion purposes) based on at least one parameter (e.g., a counter value, a random value, etc.).

[0176] Additionally, the AUSF 930 can determine the second security key based on a session key (e.g., MSK or EMSK), the identifier of the 5G UE 910 (e.g., the SUPI or IMSI of the 5G UE 910), or at least one parameter. In some example embodiments, the MSK or EMSK can be determined by the AUSF 930. Alternatively, the session key can be determined based on a key used to authenticate the 5G UE 910 to the 3GPP network (e.g., a master key). (See reference...) Figure 10 Describe the determination of the second security key.

[0177] Then, at 9015, AUSF 930 sends a Nausf_UEAuthentication_Authenticate response message including at least one parameter, a second security key, and an EAP success message indicating successful AKA' response. At 9016, the enhanced ePDG 920 may, for example, store the second security key in the UE context associated with the 5G UE 910.

[0178] At 9017, the enhanced ePDG 920 can send an IKE_AUTH response message to the 5G UE 910, including an EAP success message and at least one parameter. At 9018, after receiving at least one parameter, the 5G UE 910 determines a first security key for IPsec to protect the data session between the 5G UE 910 and the enhanced ePDG 920, based on at least one parameter (e.g., a counter value, a random value, etc.).

[0179] Additionally, the 5G UE 910 may determine the first security key based on a session key (e.g., MSK or EMSK), the identifier of the 5G UE 910 (e.g., the SUPI or IMSI of the 5G UE 910), or at least one parameter. In some example embodiments, the MSK or EMSK may be determined by the 5G UE 910. Additionally, the session key may be determined based on a key used to authenticate the 5G UE 910 to the 3GPP network (e.g., a master key). (See reference...) Figure 10 Describe the determination of the first security key.

[0180] At 9019, an IPsec security association (SA) can be established between the 5G UE 910 and the enhanced ePDG 920. At 9020, the UE context can include a security configuration for the data session, a temporary UE ePDG identifier for the 5G UE 910, and a second security key. The UE context can be maintained in both the 5G UE 910 and the enhanced ePDG 920.

[0181] At position 9021, the 5G UE 910 performs communication using a data session based on a first security key, and the enhanced ePDG 920 performs communication using a data session based on a second security key. For example, the PDN can communicate with the 5G UE 910 via the enhanced ePDG 920. In some example embodiments, further authentication may not be required for each new data session (e.g., PDU session). In this case, the UE context maintained in the 5G UE 910 and the enhanced ePDG 920 can be reused.

[0182] For example, the 5G UE 910 can perform communication with the PDN via the enhanced ePDG 920. In this case, the 5G UE 910 can encrypt the data packets used for communication using a first security key and send the encrypted data packets to the enhanced ePDG 920. The enhanced ePDG 920 can receive the encrypted data packets and decrypt them based on a second security key. The enhanced ePDG 920 can then send the decrypted data packets to the PDN.

[0183] The PDN can send data packets to the enhanced ePDG 920. The enhanced ePDG 920 can then receive the data packets and encrypt them using a second security key. Subsequently, the enhanced ePDG 920 can send the encrypted data packets to the 5G UE 910. The 5G UE 910 can use a first security key to receive and decrypt the encrypted data packets.

[0184] In this way, the 5G UE 910 can be authenticated to the 3GPP network and can communicate with the 3GPP network efficiently via the enhanced ePDG 920. Communication between the 5G UE 910 and the enhanced ePDG 920 can be performed based on a data session protected by a first security key and a second security key determined based on at least one parameter. Therefore, the security and efficiency of data session protection can be improved.

[0185] refer to Figure 10 The diagram 100 illustrates a process for generating a security key according to some embodiments of the present disclosure. Figure 10 The process in the example can be derived from Figure 1A This is implemented using device 110 and / or network entity 130. In some example embodiments, Figure 10 The process in the example can be derived from Figure 9 It is implemented using 5G UE 910 and / or AUSF 930.

[0186] As shown, in Figure 10 The example involves a Key Derivation Function (KDF). MSK or EMSK, the UE's SUPI or IMSI, or a random value or counter value can be used as input to the KDF. The security key (denoted as "K") ePDG "" can be the output of KDF.

[0187] In this way, the first security key can be independently determined by the UE based on at least one parameter (i.e., a random value or a counter value), and the second security key can be independently determined by the AUSF based on at least one parameter (i.e., a random value or a counter value). Therefore, the determination of the first and second security keys can be performed in an efficient manner.

[0188] In some example embodiments, the UE can behave in 4G mode or operate as a 4G UE when connected to an enhanced ePDG. In this case, procedures for data session protection can be performed based on the ePDG with signaling supported by the 4G UE. (See reference...) Figure 11 The document illustrates a signaling flow 1100 of an authentication process on a heterogeneous network according to some embodiments of the present disclosure.

[0189] For the purpose of discussion, references will be included. Figure 1B Discuss signaling flow 1100. Figure 11 Involving Figure 1B Network entities 150 and 160. In some example implementations, network entity 150 may be implemented as or include devices implementing network functions (e.g., AUSF). Network entity 150 may be implemented as... Figure 4B AUSF 441. Network entity 140 can be implemented as or include devices that implement network functions, such as a UDM or HSS. Network entity 160 can be implemented as... Figure 4B UDM 451 or HSS 461.

[0190] Network entity 150 and network entity 160 are in a 3GPP network (e.g., a 5G network).

[0191] In operation, network entity 150 receives (11010) a request (also referred to as a “first request”) from the device for authenticating a 3GPP network device. The device is a non-3GPP access network, such as Wi-Fi, and is connected to the device. Additionally, the device may be implemented as a UE that behaves in 4G mode or operates as a 4G UE. In some example embodiments, the device may be implemented as a terminal device, such as a UE, and the device may be implemented as a gateway, such as an ePDG.

[0192] Specifically, the first request may include an identifier for the device, an access network identifier for a non-3GPP access network, etc. For example, the identifier for the device may include the device's SUPI or IMSI. The access network identifier for a non-3GPP access network may include the access network identifier (AN ID) for the non-3GPP access network.

[0193] Then, network entity 150 sends (11020) to network entity 160 another request (also referred to as the “second request” for the purpose of discussion) to authenticate the device to the 3GPP network. Specifically, the second request may include the device’s identifier, the access network identifier of a non-3GPP access network, etc.

[0194] Accordingly, network entity 160 receives (11030) the second request from network entity 150. Then, network entity 160 sends (11040) a response to the second request to network entity 150. The response to the second request includes the device's authentication information. Accordingly, network entity 150 receives (11050) a response to the second request from network entity 160.

[0195] In some example embodiments, authentication information may indicate the value to be sent to the device for authentication, such as the AKA challenge value or the AKA' challenge value.

[0196] In some example implementations, network entity 160 can be implemented as an HSS. In this case, network entity 160 can determine the device's authentication information based on the second request. Then, network entity 160 can send a response to the second request, which includes the authentication information.

[0197] Alternatively, network entity 160 may include UDM functionality. In this case, network entity 160 may send a request (also referred to as a "third request" for authenticating a device to the 3GPP network) to the HSS in the 3GPP network. The third request may include the device's identifier, the access network identifier of a non-3GPP access network, etc.

[0198] Then, network entity 160 can receive a response to the third request from the HSS. The response to the third request may include the device's authentication information. The authentication information may be determined by the HSS. Subsequently, network entity 160 may send a response to network entity 150, including the authentication information, to the second request.

[0199] Network entity 150 receives (11060) response information from the device. The response information may be associated with authentication information. For example, if the authentication information is an AKA challenge value, the response information may include an AKA response value associated with the AKA challenge value. Alternatively, if the authentication information is an AKA' challenge value, the response information may include an AKA' response value associated with the AKA' challenge value.

[0200] Then, network entity 150 verifies (11070) the response information based on the authentication information. In some example embodiments, if the verification (11070) is successful, the device can be authenticated to the 3GPP network. If the verification (11070) fails, the device may not be authenticated to the 3GPP network.

[0201] It should be understood that the reception (11060) performed after reception (11050) is for illustrative purposes only and does not impose any limitations. In the exemplary embodiments of this disclosure, Figure 11 The processes in the example can be executed in any suitable order.

[0202] In this way, a device operating in 4G mode or as a 4G UE can be efficiently authenticated to the 3GPP network via network entity 150 and network entity 160.

[0203] In some example embodiments, such as Figure 4B As shown, AUSF 441 can be connected to HSS 461 via UDM 451. (Reference) Figure 12A Example signaling flow 1200 A for an authentication process on a heterogeneous network according to some embodiments of this disclosure. Regarding... Figure 12A The example embodiments discussed may be considered as references. Figure 11 The implementation of the example embodiments discussed. For the purposes of discussion, reference will be made to... Figure 1B Discuss signaling flow 1200 A.

[0204] Figure 12A This involves 5G UE 1210, non-3GPP access 1212, enhanced ePDG (also referred to as "ePDG" for discussion purposes) 1220, AUSF 1230, UDM 1240, and HSS 1250. AUSF 1230 can be... Figure 1B The implementation of network entity 150 in the UDM 1240. Figure 1B The implementation of network entity 160 in the example.

[0205] exist Figure 12A In the example, the 5G UE 1210 can be in a non-3GPP access network (e.g., Wi-Fi) and connected to the ePDG 1220. The AUSF 1230, UDM 140, and HSS 1250 can be in a 3GPP network (e.g., a 5G network). Additionally, the device is in a non-3GPP access network (e.g., Wi-Fi) and connected to a device. Additionally, the 5G UE 1210 can be implemented as a UE exhibiting 4G mode or operating as a 4G UE.

[0206] During operation, at position 12001, 5G UE 1210 can perform enhanced ePDG selection. For example, 5G UE 1210 can select ePDG 1220 from multiple ePDGs. The IKEv2 tunnel establishment process can be performed, such as... Figure 12A The dashed box in the diagram illustrates this. Specifically, at 12002, the IKE_SA_INIT exchange process can be initiated by 5G UE 1210 and executed between 5G UE 1210 and ePDG 1220. At 12003, 5G UE 1210 can send an IKE_AUTH request message to ePDG 1220, including the UE ID of 5G UE 1210. For example, the UE ID can be in plain text, such as the IMSI of 5G UE 1210.

[0207] Then, at 12004, ePDG 1220 sends a Nausf_UEAuthentication_Authenticate request message to AUSF 1230. The Nausf_UEAuthentication_Authenticate request message may include the IMSI of the 5G UE1210 and the AN ID as a Wi-Fi access.

[0208] At 12005, AUSF 1230 sends a Nudm_UEAuthentication_Get request message including IMSI and AN ID to UDM 1240. At 12006, UDM 1240 may send a Nudm_UEAuthentication_Get request message including IMSI and AN ID to HSS 1250. At 12007, HSS 1250 may determine the AKA challenge value for 5G UE 1210. In some example embodiments, the EAP-AKA method is already supported by 5G UE 1210.

[0209] Then, at 12008, HSS 1250 can send a Nudm_UEAuthentication_Get response message to AUSF 1230, including the IMSI and AKA challenge value of 5G UE 1210. At 12009, UDM 1240 sends a Nudm_UEAuthentication_Get response message to AUSF 1230, including the IMSI and AKA challenge value of 5G UE 1210. At 12010, AUSF 1230 can send a Nausf_UEAuthentication_Authenticate response message to ePDG 1220, including an EAP request message for 5G UE 1210 and the AKA challenge value. The EAP request message can be used to request an AKA challenge for UE authentication from 5G UE 1210.

[0210] At point 12011, ePDG 1220 can send an IKE_AUTH response message to 5G UE 1210. The IKE_AUTH response message can include an EAP request message and an AKA challenge value. After receiving the IKE_AUTH response message, 5G UE 1210 can determine the AKA response value associated with the AKA challenge value, and at point 12012, send an IKE_AUTH request message to ePDG 1220, including an EAP response message to the EAP request message and the AKA response value.

[0211] At step 12013, ePDG 1220 sends a Nausf_UEAuthentication_Authenticate request message to AUSF 1230, including an EAP response message and an AKA response value. Then, at step 12014, AUSF 1230 verifies the AKA response value based on the AKA challenge value. If the verification at step 12014 is successful, the 5G UE 1210 is authenticated to the 3GPP network.

[0212] Then, at 12015, AUSF 1230 can send a Nausf_UEAuthentication_Authenticate response message to ePDG 1220, including an EAP success message indicating successful authentication with an AKA response. At 12016, ePDG 1220 sends an IKE_AUTH response message to 5G UE 1210, including an EAP success message. At 12017, an IPsec SA can be established between 5G UE 1210 and ePDG 1220.

[0213] Then, the 5G UE 1210 can perform communication, and the ePDG 1220 can also perform communication. For example, the PDN can communicate with the 5G UE 1210 via the ePDG 1220. In some example embodiments, for each PDN connection, an authentication process on the heterogeneous network may need to be performed each time.

[0214] In this way, the 5G UE 1210, operating in 4G mode or as a 4G UE, can be authenticated to the 3GPP network and can communicate with the 3GPP network efficiently via ePDG 1220, AUSF 1230, UDM 1240 and HSS 1250.

[0215] In some example embodiments, such as Figure 4B As shown, the AUSF 441 can be directly connected to the HSS 461. (Reference) Figure 12B Example signaling flow 1200 B for an authentication process on a heterogeneous network according to some embodiments of this disclosure. Regarding... Figure 12B The example embodiments discussed may be considered as references. Figure 11 The implementation of the example embodiments discussed. For the purposes of discussion, reference will be made to... Figure 1B Discuss signaling flow 1200 B.

[0216] Figure 12B This involves 5G UE 1210, non-3GPP access 1212, enhanced ePDG (also referred to as "ePDG" for discussion purposes) 1220, AUSF 1230, and HSS 1251. AUSF 1230 can be... Figure 1B The implementation of network entity 150 in the code. HSS1251 can be... Figure 1B The implementation of network entity 160 in the example.

[0217] exist Figure 12B In the example, the 5G UE 1210 can be in a non-3GPP access network (e.g., Wi-Fi) and connected to the ePDG 1220. The AUSF 1230 and HSS 1251 can be in a 3GPP network (e.g., a 5G network). Additionally, the device is in a non-3GPP access network (e.g., Wi-Fi) and connected to the device. Additionally, the 5G UE 1210 can be implemented as a UE exhibiting 4G mode or operating as a 4G UE.

[0218] During operation, at point 12501, 5G UE 1210 can perform enhanced ePDG selection. For example, 5G UE 1210 can select ePDG 1220 from multiple ePDGs. The IKEv2 tunnel establishment process can be performed, such as... Figure 12AThe dashed box in the diagram illustrates this. Specifically, at 12502, the IKE_SA_INIT exchange process can be initiated by 5G UE 1210 and executed between 5G UE 1210 and ePDG 1220. At 12503, 5G UE 1210 can send an IKE_AUTH request message to ePDG 1220, including the UE ID of 5G UE 1210. For example, the UE ID can be in plain text, such as the IMSI of 5G UE 1210.

[0219] Then, at 12504, ePDG 1220 sends a Nausf_UEAuthentication_Authenticate request message to AUSF 1230. The Nausf_UEAuthentication_Authenticate request message may include the IMSI of the 5G UE1210 and the AN ID as Wi-Fi access.

[0220] At 12505, AUSF 1230 sends a Nudm_UEAuthentication_Get request message to HSS 1251, including the IMSI and AN ID. At 12506, HSS 1251 can determine the AKA challenge value for 5G UE 1210. In some example embodiments, the EAP AKA method is already supported by 5G UE 1210.

[0221] At 12507, HSS 1251 sends a Nudm_UEAuthentication_Get response message to AUSF 1230, including the IMSI and AKA challenge value of 5G UE 1210. At 12508, AUSF 1230 can send a Nausf_UEAuthentication_Authenticate response message to ePDG 1220, including an EAP request message for 5G UE 1210 and the AKA challenge value. The EAP request message can be used to request an AKA challenge for UE authentication from 5G UE 1210.

[0222] The ePDG 1220 can send an IKE_AUTH response message to the 5G UE 1210 at point 12509. The IKE_AUTH response message can include an EAP request message and an AKA challenge value. Upon receiving the IKE_AUTH response message, the 5G UE 1210 can determine the AKA response value associated with the AKA challenge value, and at point 12510, send an IKE_AUTH request message to the ePDG 1220, including an EAP response message for the EAP request message and the AKA response value.

[0223] At step 12511, ePDG 1220 sends a Nausf_UEAuthentication_Authenticate request message to AUSF 1230, including an EAP response message and an AKA response value. Then, at step 12512, AUSF 1230 verifies the AKA response value based on the AKA challenge value. If the verification at step 12512 is successful, the 5G UE 1210 is authenticated to the 3GPP network.

[0224] Then, at 12513, AUSF 1230 can send a Nausf_UEAuthentication_Authenticate response message to ePDG 1220, including an EAP success message indicating successful authentication with an AKA response. At 12514, ePDG 1220 sends an IKE_AUTH response message to 5G UE 1210, including an EAP success message. At 12515, an IPsec SA can be established between 5G UE 1210 and ePDG 1220.

[0225] Then, the 5G UE 1210 can perform communication, and the ePDG 1220 can also perform communication. For example, the PDN can communicate with the 5G UE 1210 via the ePDG 1220. In some example embodiments, for each PDN connection, an authentication process on the heterogeneous network may need to be performed each time.

[0226] In this way, the 5G UE 1210, operating in 4G mode or as a 4G UE, can be authenticated to the 3GPP network and can communicate with the 3GPP network efficiently via ePDG 1220, AUSF 1230 and HSS 1251.

[0227] Figure 13 A flowchart of an example method 1300 implemented at a device according to some example embodiments of the present disclosure is shown. For the purposes of discussion, [the following will be discussed]. Figure 1A Method 1300 is described by the angle of the device 110 in the middle.

[0228] At block 1310, device 110 determines a security key based at least on a session key. This security key is used to protect the data session between device 110 and the device. The session key is used by network entities in a 3GPP network to determine another security key used to protect the data session. Device 110 is in a non-3GPP access network and connected to the device.

[0229] At box 1320, device 110 performs communication using a data session based on a security key.

[0230] This improves the security of communication between the device and the 3GPP network.

[0231] In some example embodiments, device 110 may send a request to the device for authenticating device 110 to the 3GPP network, the request including an encrypted identifier of the device. Therefore, device 110 may trigger data session protection.

[0232] In some example embodiments, the encrypted identifier may include the Subscription Hidden Identifier (SUCI) of device 110. Therefore, the identifier of device 110 is protected based on the SUCI.

[0233] In some example embodiments, device 110 may determine a security key, at least based on a session key, after receiving a response to a request from a device. In this way, device 110 can be triggered to determine a security key.

[0234] In some example embodiments, the session key may be determined based on a key used to authenticate the 3GPP network authentication device 110.

[0235] In some example embodiments, the session key may include at least one of the following: Master Session Key (MSK) and Extended Master Session Key (EMSK).

[0236] In some example embodiments, the apparatus may include a terminal device, which may include an evolved packet data gateway (EPDG), and the network entity may include an authentication server function (AUSF).

[0237] Figure 14 A flowchart of an example method 1400 implemented at a device according to some example embodiments of the present disclosure is shown. For the purposes of discussion, [the following will be discussed]. Figure 1A Method 1400 is described by the angle of device 120 in the middle.

[0238] At box 1410, device 120 receives a security key from a network entity in a 3GPP network. This security key is used to protect the data session between the device and device 120. The device is in a non-3GPP access network and connected to device 120. The security key is determined based on a session key, and this session key is used by the device to determine another security key for protecting the data session.

[0239] At box 1420, device 120 performs communication using a data session based on a security key.

[0240] In this way, the security of communication between the device and the 3GPP network can be improved via device 120.

[0241] In some example embodiments, device 120 may receive a request from the device for authenticating the device to a 3GPP network, the request including an encrypted identifier of the device. Device 120 may then send a response to the request to the device.

[0242] In some example embodiments, device 120 may send another request to a network entity for authenticating the device to the 3GPP network. This other request may include at least one of the following: an encrypted identifier of the device, a serving network identifier of the 3GPP network configured by the device, and an indication that the other request is associated with the device. Thus, the other request can be used to indicate the network entity associated with the device.

[0243] In some example embodiments, the serving network identifier may include a Public Land Mobile Network (PLMN) identifier for a 3GPP network.

[0244] In some example embodiments, the encrypted identifier may include the device’s Subscription Hidden Identifier (SUCI).

[0245] In some example embodiments, device 120 may store a security key in context information associated with the device. The context information may include at least one of the following: a security key, configuration information for the security of a data session, or a temporary identifier for the device. In this way, the context information can be reused for communication using another data session based on a secure network.

[0246] In some example implementations, the session key may be determined based on a key used to authenticate the 3GPP network.

[0247] In some example embodiments, the session key may include at least one of the following: Master Session Key (MSK) and Extended Master Session Key (EMSK).

[0248] In some example embodiments, the apparatus may include a terminal device, which may include an evolved packet data gateway (EPDG), and the network entity may include an authentication server function (AUSF).

[0249] Figure 15 A flowchart of an example method 1500 implemented at a network entity according to some example embodiments of the present disclosure is shown. For discussion purposes, [the following will be discussed]. Figure 1A Method 1500 is described from the perspective of network entity 130.

[0250] At box 1510, network entity 130 determines a security key based at least on the session key, the security key being used to protect the data session between the device and the equipment. The device is in a non-3GPP access network and is connected to the network entity, which is in a 3GPP network, and the session key is used by the device to determine another security key for protecting the data session.

[0251] At box 1520, network entity 130 sends a security key to the device.

[0252] In this way, network entities can determine a security key, and data sessions are protected based on that security key.

[0253] Therefore, the security of communication between devices and equipment can be improved.

[0254] In some example embodiments, network entity 130 may determine a session key based on a key used to authenticate the 3GPP network.

[0255] In some example embodiments, the session key may include at least one of the following: Master Session Key (MSK) and Extended Master Session Key (EMSK).

[0256] In some example embodiments, network entity 130 may receive a request from a device for authenticating a device to a 3GPP network. The request may include at least one of the following: an encrypted identifier of the device, a serving network identifier of the 3GPP network configured by the device, and an indication that the request is associated with the device.

[0257] In some example embodiments, network entity 130 may receive authentication information for a device from another network entity. Network entity 130 may also receive response information from the device, which is associated with the authentication information. Network entity 130 may verify the response information based on the authentication information.

[0258] In some example embodiments, network entity 130 may send another request to another network entity in the 3GPP network for authenticating the device with the 3GPP network. Network entity 130 may receive a response to this other request from the other network entity, the response including authentication information for the device. Therefore, the device can be authenticated with the 3GPP network based on the authentication information.

[0259] In some example embodiments, the other request may include at least one of the following: an encrypted identifier of the device, a serving network identifier of the 3GPP network configured by the device, and an indication that the other request is associated with the device.

[0260] In some example embodiments, another network entity may include a device that implements unified data management (UDM) functionality.

[0261] In some example embodiments, the serving network identifier may include a Public Land Mobile Network (PLMN) identifier for a 3GPP network.

[0262] In some example embodiments, the encrypted identifier may include the device’s Subscription Hidden Identifier (SUCI).

[0263] In some example embodiments, the apparatus may include a terminal device, which may include an evolved packet data gateway (EPDG), and the network entity may include an authentication server function (AUSF).

[0264] Figure 16 A flowchart of an example method 1600 implemented at a network entity according to some example embodiments of the present disclosure is shown. For the purposes of discussion, [the following will be discussed]. Figure 1A Method 1600 describes the network entity 140 from the perspective of network entity 140.

[0265] At box 1610, network entity 140 receives from another network entity a request for authentication of a device in a non-3GPP access network within the 3GPP network. This request includes the serving network identifier of the 3GPP network configured by the device. Both the network entity and the other network entity are in a 3GPP network.

[0266] At box 1620, network entity 140 determines authentication information for the device based on the service network identifier.

[0267] At box 1630, network entity 140 sends a response to the request to another network entity. This response may include authentication information.

[0268] Therefore, the device can be authenticated to the 3GPP network based on the authentication information.

[0269] In some example embodiments, the request may also include at least one of the following: an encrypted identifier of the device, or an indication that the request is associated with a device.

[0270] In some example embodiments, the encrypted identifier may include the device’s Subscription Hidden Identifier (SUCI).

[0271] In some example embodiments, the serving network identifier may include a Public Land Mobile Network (PLMN) identifier for a 3GPP network.

[0272] In some example embodiments, a network entity may include a unified data management (UDM) function, an apparatus may include an end device, an apparatus may include an evolved packet data gateway (EPDG), and another network entity may include an authentication server function (AUSF).

[0273] Figure 17 A flowchart of an example method 1700 implemented at a network entity according to some example embodiments of the present disclosure is shown. For discussion purposes, [the following will be discussed]. Figure 1B Method 1700 describes the network entity 150 from the perspective of network entity 150.

[0274] At box 1710, network entity 150 receives a request from a device for authenticating a device to a 3GPP network. The device is in a non-3GPP access network and is connected to the device, while the network entity is in a 3GPP network.

[0275] At box 1720, network entity 150 sends another request to another network entity for authenticating the device to the 3GPP network. The other network entity is in the 3GPP network.

[0276] At box 1730, network entity 150 receives authentication information for the device from the other network entity.

[0277] At box 1740, network entity 150 receives response information from the device, which is associated with authentication information.

[0278] At box 1750, network entity 150 verifies the response information based on the authentication information.

[0279] Therefore, the device can be authenticated by the 3GPP network based on the network entity 150, which has authentication and response information.

[0280] In some example embodiments, the request may include at least one of the following: the identifier of the device, or the identifier of the access network of a non-3GPP access network.

[0281] In some example embodiments, the other request may include at least one of the following: the identifier of the device, or the access network identifier of the non-3GPP access network.

[0282] In some example embodiments, network entity 150 may receive authentication information for the device from another network entity. The authentication information for the device is obtained from the Home Subscriber Server (HSS) in the 3GPP network.

[0283] In some example embodiments, network entity 150 may receive authentication information for the device from another network entity. The authentication information for the device is determined by the other network entity.

[0284] In some example embodiments, the network entity may include an Authentication Server Function (AUSF), the apparatus may include an end device, and the apparatus may include an Evolved Packet Data Gateway (EPDG).

[0285] Figure 18 A flowchart of an example method 1800 implemented at a network entity according to some example embodiments of the present disclosure is shown. For discussion purposes, [the following will be discussed]. Figure 1B Method 1800 describes the network entity 160 from the perspective of network entity 160.

[0286] At box 1810, network entity 160 receives a request from another network entity for authenticating a device to a 3GPP network. The device is in a non-3GPP access network and is connected to the device, while the network entity and the other network entity are in a 3GPP network.

[0287] At box 1820, network entity 160 sends a response to the request to the other network entity, the response including authentication information for the device.

[0288] In some example embodiments, network entity 160 may receive a request from another network entity. The request may include at least one of the following: an identifier of the device, and an access network identifier of the non-3GPP access network. Based on the request, network entity 160 may determine authentication information for the device. Network entity 160 may send a response to the request to the other network entity. The response may include authentication information.

[0289] In some example embodiments, network entity 160 may receive a request from another network entity. Network entity 160 may send another request to the Home Subscriber Server (HSS) in the 3GPP network for authenticating the device to the 3GPP network. This other request may include at least one of the following: the identifier of the device, and the access network identifier of the non-3GPP access network.

[0290] In some example embodiments, network entity 160 may receive another response to another request from the HSS. This other response may include authentication information for the device. Network entity 160 may send a response to the request to the other network entity. This response may include authentication information.

[0291] In some example embodiments, the apparatus may include a terminal device, and the other network entity may include an Authentication Server Function (AUSF).

[0292] In some example embodiments, the means capable of performing any of the methods in method 1300 (e.g., Figure 1A The device 110 may include components for performing the corresponding operations of method 1300. These components may be implemented in any suitable form. For example, the components may be implemented in a circuit or software module. The device may be implemented as or included in... Figure 1A In device 110.

[0293] In some example embodiments, the apparatus may include components for determining a security key based at least on a session key, the security key being used to protect a data session between the apparatus and a device. The session key is used by network entities in a 3GPP network to determine another security key used to protect the data session. The apparatus is in a non-3GPP access network and is connected to the device. The apparatus may include components for performing communication using the data session based on the security key.

[0294] In some example embodiments, the apparatus may further include a component for sending a request to the device for authenticating the device to the 3GPP network, the request including an encrypted identifier of the device.

[0295] In some example embodiments, the encrypted identifier may include the device’s Subscription Hidden Identifier (SUCI).

[0296] In some example embodiments, the apparatus may further include a component for determining a security key based at least on a session key after receiving a response to a request from the device.

[0297] In some example implementations, a session key can be determined based on a key used to authenticate the 3GPP network.

[0298] In some example embodiments, the session key may include at least one of the following: Master Session Key (MSK) and Extended Master Session Key (EMSK).

[0299] In some example embodiments, the apparatus may include a terminal device, which may include an evolved packet data gateway (EPDG), and the network entity may include an authentication server function (AUSF).

[0300] In some example embodiments, a device capable of performing any of the methods in method 1400 (e.g., Figure 1A The device 120 may include components for performing the corresponding operations of method 1400. These components may be implemented in any suitable form. For example, the components may be implemented in a circuit or software module. The device may be implemented as or included in... Figure 1A Among the equipment 120.

[0301] In some example embodiments, the device may include components for receiving a security key from a network entity in a 3GPP network, the security key being used to protect a data session between the device and the network. The device is in a non-3GPP access network and connected to the network; the security key is determined based on a session key, and the session key is used by the device to determine another security key for protecting the data session. The device may include components for performing communications using the data session based on the security key.

[0302] In some example embodiments, the device may further include: components for receiving from the device a request for authenticating the device to the 3GPP network, the request including an encrypted identifier of the device; and components for sending a response to the request to the device.

[0303] In some example embodiments, the device may further include a component for sending another request to a network entity for authenticating the device to the 3GPP network. This other request may include at least one of the following: an encrypted identifier of the device, a serving network identifier of the 3GPP network configured by the device, and an indication indicating that the other request is associated with the device.

[0304] In some example embodiments, the serving network identifier may include a Public Land Mobile Network (PLMN) identifier for a 3GPP network.

[0305] In some example embodiments, the encrypted identifier may include the device’s Subscription Hidden Identifier (SUCI).

[0306] In some example embodiments, the device may include components for storing a security key in context information associated with the device. The context information may include at least one of the following: a security key, configuration information for the security of data sessions, or a component for a temporary identifier of the device.

[0307] In some example implementations, a session key can be determined based on a key used to authenticate the 3GPP network.

[0308] In some example embodiments, the session key may include at least one of the following: Master Session Key (MSK) and Extended Master Session Key (EMSK).

[0309] In some example embodiments, the apparatus may include a terminal device, which may include an evolved packet data gateway (EPDG), and the network entity may include an authentication server function (AUSF).

[0310] In some example embodiments, network entities capable of performing any of the methods in method 1500 (e.g., Figure 1A The network entity 130 may include components for performing the corresponding operations of method 1500. These components may be implemented in any suitable form. For example, the components may be implemented in a circuit or software module. The network entity may be implemented as or included in... Figure 1A Among network entities 130.

[0311] In some example embodiments, the network entity may include components for determining a security key, at least based on a session key, for protecting a data session between the device and the equipment. The device is in a non-3GPP access network and connected to the equipment, the network entity is in a 3GPP network, and the session key is used by the device to determine another security key for protecting the data session. The network entity may include components for sending the security key to the equipment.

[0312] In some example embodiments, the network entity may further include: a component for determining a session key based on a key used to authenticate the 3GPP network.

[0313] In some example embodiments, the session key may include at least one of the following: Master Session Key (MSK) and Extended Master Session Key (EMSK).

[0314] In some example embodiments, the network entity may further include a component for receiving from the device a request for authenticating the device to the 3GPP network. The request may include at least one of the following: an encrypted identifier of the device, a serving network identifier of the 3GPP network configured by the device, and an indication indicating that the request is associated with the device.

[0315] In some example embodiments, the network entity may further include: a component for receiving authentication information for a device from another network entity; a component for receiving response information of the device from the device, the response information being associated with the authentication information; and a component for verifying the response information based on the authentication information.

[0316] In some example embodiments, the network entity may further include: components for sending another request to another network entity in the 3GPP network for authenticating a device in the 3GPP network; and components for receiving a response to the other request from the other network entity, the response including authentication information for the device.

[0317] In some example embodiments, the other request may include at least one of the following: an encrypted identifier of the device, a serving network identifier of the 3GPP network configured by the device, and an indication that the other request is associated with the device.

[0318] In some example embodiments, another network entity may include a device that implements unified data management (UDM) functionality.

[0319] In some example embodiments, the serving network identifier may include a Public Land Mobile Network (PLMN) identifier for a 3GPP network.

[0320] In some example embodiments, the encrypted identifier may include the device’s Subscription Hidden Identifier (SUCI).

[0321] In some example embodiments, the apparatus may include a terminal device, which may include an evolved packet data gateway (EPDG), and the network entity may include an authentication server function (AUSF).

[0322] In some example embodiments, network entities capable of performing any of the methods in method 1600 (e.g., Figure 1A The network entity 140 may include components for performing the corresponding operations of method 1600. These components may be implemented in any suitable form. For example, the components may be implemented in a circuit or software module. The network entity may be implemented as or included in... Figure 1A Among network entities 140.

[0323] In some example embodiments, a network entity may include components for receiving from another network entity a request to authenticate a device in a non-3GPP access network within a 3GPP network, the request including a serving network identifier of the 3GPP network configured by the device. The network entity and the other network entity are in a 3GPP network. The network entity may include components for determining authentication information for the device based on the serving network identifier; and components for sending a response to the request to the other network entity. The response may include authentication information.

[0324] In some example embodiments, the request may also include at least one of the following: an encrypted identifier of the device, or an indication that the request is associated with a device.

[0325] In some example embodiments, the encrypted identifier may include the device’s Subscription Hidden Identifier (SUCI).

[0326] In some example embodiments, the serving network identifier may include a Public Land Mobile Network (PLMN) identifier for a 3GPP network.

[0327] In some example embodiments, a network entity may include a unified data management (UDM) function, an apparatus may include an end device, an apparatus may include an evolved packet data gateway (EPDG), and another network entity may include an authentication server function (AUSF).

[0328] In some example embodiments, network entities capable of performing any of the methods in method 1700 (e.g., Figure 1B The network entity 150 may include components for performing the corresponding operations of method 1700. These components may be implemented in any suitable form. For example, the components may be implemented in a circuit or software module. The network entity may be implemented as or included in... Figure 1B Among the network entities in 150.

[0329] In some example embodiments, a network entity may include components for receiving from a device a request to authenticate a device to a 3GPP network. The device is in a non-3GPP access network and is connected to the device, while the network entity is in a 3GPP network. The network entity may include components for sending another request to another network entity for authenticating the device to that 3GPP network. This other network entity is also in a 3GPP network. The network entity may include: components for receiving authentication information for the device from the other network entity; components for receiving response information from the device, the response information being associated with the authentication information; and components for verifying the response information based on the authentication information.

[0330] In some example embodiments, the request may include at least one of the following: the device identifier, the access network identifier of a non-3GPP access network.

[0331] In some example embodiments, the other request may include at least one of the following: the identifier of the device, the access network identifier of the non-3GPP access network.

[0332] In some example embodiments, the network entity may further include a component for receiving authentication information for the device from another network entity. The authentication information for the device is obtained from a Home Subscriber Server (HSS) in a 3GPP network.

[0333] In some example embodiments, the network entity may further include a component for receiving authentication information for the device from another network entity. The authentication information for the device is determined by the other network entity.

[0334] In some example embodiments, the network entity may include an Authentication Server Function (AUSF), the apparatus may include an end device, and the apparatus may include an Evolved Packet Data Gateway (EPDG).

[0335] In some example embodiments, network entities capable of performing any of the methods in method 1800 (e.g., Figure 1B The network entity 160 may include components for performing the corresponding operations of method 1800. These components may be implemented in any suitable form. For example, the components may be implemented in a circuit or software module. The network entity may be implemented as or included in... Figure 1B Among network entities 160.

[0336] In some example embodiments, a network entity may include components for receiving a request from another network entity for authenticating a device to a 3GPP network. The device is in a non-3GPP access network and connected to the device, and both the network entity and the other network entity are in a 3GPP network. The network entity may include components for sending a response to the request to the other network entity, the response including authentication information for the device.

[0337] In some example embodiments, the network entity may further include: a component for receiving a request from another network entity. The request may include at least one of the following: an identifier of the device, an access network identifier of the non-3GPP access network. The network entity may include: a component for determining authentication information for the device based on the request; and a component for sending a response to the request to the other network entity. The response may include authentication information.

[0338] In some example embodiments, the network entity may further include: components for receiving a request from another network entity; and components for sending another request to a 3GPP network authentication device to a Home Subscriber Server (HSS) in the 3GPP network. This other request may include at least one of the following: an identifier of the device, and an access network identifier of the non-3GPP access network.

[0339] In some example embodiments, the network entity may further include a component for receiving another response from the HSS to another request. This other response may include authentication information for the device. The network entity may also include a component for sending a response to the request to the other network entity. This response may include authentication information.

[0340] In some example embodiments, the apparatus may include a terminal device, and the other network entity may include an Authentication Server Function (AUSF).

[0341] Figure 19 A flowchart of an example method 1900 implemented at a device according to some example embodiments of the present disclosure is shown. For the purposes of discussion, [the following will be discussed]. Figure 1A Method 1900 is described by the angle of the device 110 in the middle.

[0342] At block 1910, device 110 receives at least one parameter from the device. The at least one parameter is used by a network entity in a 3GPP network to determine a security key for protecting the data session between the device and the device, and the device is in a non-3GPP access network and connected to the device.

[0343] At box 1920, device 110 determines another security key for protecting the data session based on at least one parameter.

[0344] At box 1930, device 110 performs communication using a data session based on another security key.

[0345] In this way, the security of communication between the device and the 3GPP network is improved.

[0346] In some example embodiments, device 110 may send a request to the device for authenticating the device to the 3GPP network, the request including an encrypted identifier of the device. Therefore, device 110 may trigger data session protection.

[0347] In some example embodiments, the encrypted identifier may include the device's Subscription Hidden Identifier (SUCI). Therefore, the identifier of device 110 is protected based on the SUCI.

[0348] In some example embodiments, device 110 may determine another security key based on at least one of the following: a session key, a device identifier, or at least one parameter.

[0349] In some example embodiments, the security key may be determined based on at least one of the following: a session key, a device identifier, or at least one parameter.

[0350] In some example implementations, a session key can be determined based on a key used to authenticate the 3GPP network.

[0351] In some example embodiments, the session key may include at least one of the following: Master Session Key (MSK) and Extended Master Session Key (EMSK).

[0352] In some example embodiments, at least one parameter may include at least one of the following: a random value, a counter value.

[0353] In some example embodiments, the apparatus may include a terminal device, which may include an evolved packet data gateway (EPDG), and the network entity may include an authentication server function (AUSF).

[0354] Figure 20 A flowchart of an example method 2000 implemented at a device according to some example embodiments of the present disclosure is shown. For the purposes of discussion, [the following will be discussed]. Figure 1A Method 2000 describes the device 120 angle.

[0355] At box 2010, device 120 receives at least one parameter and a security key from a network entity. This security key is used to protect a data session between the device and the network entity. The device is in a non-3GPP access network and connected to the network entity. The at least one parameter is used by the device to determine another security key for protecting the data session, and the security key is determined based on at least one parameter.

[0356] At frame 2020, device 120 sends at least one parameter to the apparatus.

[0357] At box 2030, device 120 performs communication using a data session based on a security key.

[0358] In this way, the security of communication between the device and the 3GPP network can be improved via device 120.

[0359] In some example embodiments, device 120 may receive a request from the device for authenticating the device to the 3GPP network, the request including an encrypted identifier of the device, and device 120 may send a response to the request to the device.

[0360] In some example embodiments, device 120 may send another request to a network entity for authenticating the device to the 3GPP network. This other request may include at least one of the following: an encrypted identifier of the device, a serving network identifier of the 3GPP network configured by the device, and an indication that the other request is associated with the device. Thus, the other request can be used to indicate the network entity associated with the device.

[0361] In some example embodiments, the serving network identifier may include a Public Land Mobile Network (PLMN) identifier for a 3GPP network.

[0362] In some example embodiments, the encrypted identifier may include the device’s Subscription Hidden Identifier (SUCI).

[0363] In some example embodiments, device 120 may store a security key in context information associated with the device. The context information may include at least one of the following: a security key, configuration information for security of the data session, a temporary identifier of the device, and at least one parameter. In this way, the context information can be reused for communication using another data session based on a secure network.

[0364] In some example embodiments, another security key may be determined based on at least one of the following: a session key, a device identifier, or at least one parameter.

[0365] In some example embodiments, the security key may be determined based on at least one of the following: a session key, a device identifier, or at least one parameter.

[0366] In some example implementations, a session key can be determined based on a key used to authenticate the 3GPP network.

[0367] In some example embodiments, the session key may include at least one of the following: Master Session Key (MSK) and Extended Master Session Key (EMSK).

[0368] In some example embodiments, at least one parameter may include at least one of the following: a random value, a counter value.

[0369] In some example embodiments, the apparatus may include a terminal device, which may include an evolved packet data gateway (EPDG), and the network entity may include an authentication server function (AUSF).

[0370] Figure 21 A flowchart of an example method 2100 implemented at a network entity according to some example embodiments of the present disclosure is shown. For discussion purposes, [the following will be discussed]. Figure 1A Method 2100 is described from the perspective of network entity 130.

[0371] At box 2110, network entity 130 determines a security key based on at least one parameter, which is used to protect data sessions between the device and the equipment. The device is in a non-3GPP access network and connected to the equipment, the network entity is in a 3GPP network, and at least one parameter is used by the device to determine another security key for protecting the data session.

[0372] At box 2120, network entity 130 sends a security key and at least one parameter to the device.

[0373] Therefore, the security of communication between devices and equipment can be improved.

[0374] In some example embodiments, network entity 130 may determine the security key based on at least one of the following: a session key, a device identifier, or at least one parameter.

[0375] In some example embodiments, another security key may be determined based on at least one of the following: a session key, a device identifier, or at least one parameter.

[0376] In some example implementations, a session key can be determined based on a key used to authenticate the 3GPP network.

[0377] In some example embodiments, the session key may include at least one of the following: Master Session Key (MSK) and Extended Master Session Key (EMSK).

[0378] In some example embodiments, network entity 130 may receive a request from a device for authenticating a device to a 3GPP network. The request may include at least one of the following: an encrypted identifier of the device, a serving network identifier of the 3GPP network configured by the device, and an indication that the request is associated with the device.

[0379] In some example embodiments, network entity 130 may receive authentication information for a device from another network entity. Network entity 130 may also receive response information from the device that is associated with the authentication information. Network entity 130 may verify the response information based on the authentication information.

[0380] In some example embodiments, network entity 130 may send another request to another network entity in the 3GPP network for authenticating the device with the 3GPP network. Network entity 130 may receive a response to this other request from the other network entity, the response including authentication information for the device. Therefore, the device can be authenticated with the 3GPP network.

[0381] In some example embodiments, the other request may include at least one of the following: an encrypted identifier of the device, a serving network identifier of the 3GPP network configured by the device, and an indication that the other request is associated with the device.

[0382] In some example embodiments, another network entity may include a device that implements unified data management (UDM) functionality.

[0383] In some example embodiments, the serving network identifier may include a Public Land Mobile Network (PLMN) identifier for a 3GPP network.

[0384] In some example embodiments, the encrypted identifier may include the device’s Subscription Hidden Identifier (SUCI).

[0385] In some example embodiments, at least one parameter may include at least one of the following: a random value, a counter value.

[0386] In some example embodiments, the apparatus may include a terminal device, which may include an evolved packet data gateway (EPDG), and the network entity may include an authentication server function (AUSF).

[0387] Figure 22 A flowchart of an example method 2200 implemented at a network entity according to some example embodiments of the present disclosure is shown. For discussion purposes, [the following will be discussed]. Figure 1A Method 2200 describes the network entity 140 from the perspective of network entity 140.

[0388] At box 2210, network entity 140 receives from another network entity a request for authentication of a device in a non-3GPP access network within the 3GPP network. This request includes the serving network identifier of the 3GPP network configured by the device. Both the network entity and the other network entity are in the 3GPP network.

[0389] At box 2220, network entity 140 determines authentication information for the device based on the service network identifier.

[0390] At box 2230, network entity 140 sends a response to the request to another network entity. This response may include authentication information.

[0391] Therefore, the device can be authenticated to the 3GPP network based on the authentication information.

[0392] In some example embodiments, the request may also include at least one of the following: an encrypted identifier of the device, or an indication that the request is associated with a device.

[0393] In some example embodiments, the encrypted identifier may include the device’s Subscription Hidden Identifier (SUCI).

[0394] In some example embodiments, the serving network identifier may include a Public Land Mobile Network (PLMN) identifier for a 3GPP network.

[0395] In some example embodiments, a network entity may include a unified data management (UDM) function, an apparatus may include an end device, an apparatus may include an evolved packet data gateway (EPDG), and another network entity may include an authentication server function (AUSF).

[0396] In some example embodiments, the means capable of performing any of the methods in method 1900 (e.g., Figure 1A The device 110 may include components for performing the corresponding operations of method 1900. These components may be implemented in any suitable form. For example, the components may be implemented in a circuit or software module. The device may be implemented as or included in... Figure 1A In device 110.

[0397] In some example embodiments, the apparatus may include components for receiving at least one parameter from a device, wherein the at least one parameter is used by a network entity in a 3GPP network to determine a security key, the security key being used to protect a data session between the apparatus and the device, and the apparatus is in a non-3GPP access network and connected to a device. The apparatus may include: components for determining another security key for protecting the data session based on at least one parameter; and components for performing communication using the data session based on the other security key.

[0398] In some example embodiments, the apparatus may further include a component for sending a request to the device for authenticating the device to the 3GPP network, the request including an encrypted identifier of the device.

[0399] In some example embodiments, the encrypted identifier may include the device’s Subscription Hidden Identifier (SUCI).

[0400] In some example embodiments, the apparatus may further include a component for determining another security key based on at least one of the following: a session key, an identifier of the apparatus, or at least one parameter.

[0401] In some example embodiments, the security key may be determined based on at least one of the following: a session key, a device identifier, or at least one parameter.

[0402] In some example implementations, a session key can be determined based on a key used to authenticate the 3GPP network.

[0403] In some example embodiments, the session key may include at least one of the following: Master Session Key (MSK) and Extended Master Session Key (EMSK).

[0404] In some example embodiments, at least one parameter may include at least one of the following: a random value, a counter value.

[0405] In some example embodiments, the apparatus may include a terminal device, which may include an evolved packet data gateway (EPDG), and the network entity may include an authentication server function (AUSF).

[0406] In some example embodiments, a device capable of performing any of the methods in method 2000 (e.g., Figure 1A The device 120 may include components for performing corresponding operations of method 2000. These components may be implemented in any suitable form. For example, the components may be implemented in a circuit or software module. The device may be implemented as or included in... Figure 1A Among the equipment 120.

[0407] In some example embodiments, the device may include components for receiving at least one parameter and a security key from the network entity, the security key being used to protect a data session between the device and the network entity. The device is in a non-3GPP access network and connected to the network entity. At least one parameter is used by the device to determine another security key for protecting the data session, and the security key is determined based on at least one parameter. The device may include components for sending at least one parameter to the network entity. The device may also include components for performing communication using the data session based on the security key.

[0408] In some example embodiments, the device may further include: components for receiving from the device a request for authenticating the device to a 3GPP network, the request including an encrypted identifier of the device. The device may also include components for sending a response to the request to the device.

[0409] In some example embodiments, the device may further include a component for sending another request to a network entity for authenticating the device to the 3GPP network. This other request may include at least one of the following: an encrypted identifier of the device, a serving network identifier of the 3GPP network configured by the device, and an indication indicating that the other request is associated with the device.

[0410] In some example embodiments, the serving network identifier may include a Public Land Mobile Network (PLMN) identifier for a 3GPP network.

[0411] In some example embodiments, the encrypted identifier may include the device’s Subscription Hidden Identifier (SUCI).

[0412] In some example embodiments, the device may further include a component for storing a security key in context information associated with the device. The context information may include at least one of the following: a security key, a component for configuration information for the security of data sessions, a temporary identifier of the device, and at least one parameter.

[0413] In some example embodiments, another security key may be determined based on at least one of the following: a session key, a device identifier, or at least one parameter.

[0414] In some example embodiments, the security key may be determined based on at least one of the following: a session key, a device identifier, or at least one parameter.

[0415] In some example implementations, a session key can be determined based on a key used to authenticate the 3GPP network.

[0416] In some example embodiments, the session key may include at least one of the following: Master Session Key (MSK) or Extended Master Session Key (EMSK).

[0417] In some example embodiments, at least one parameter may include at least one of the following: a random value, a counter value.

[0418] In some example embodiments, the apparatus may include a terminal device, which may include an evolved packet data gateway (EPDG), and the network entity may include an authentication server function (AUSF).

[0419] In some example embodiments, network entities capable of performing any of the methods in method 2100 (e.g., Figure 1A The network entity 130 may include a component for performing the corresponding operation of method 2100. This component may be implemented in any suitable form. For example, the component may be implemented in a circuit or software module. The network entity may be implemented as or included in... Figure 1A Among network entities 130.

[0420] In some example embodiments, the network entity may include components for determining a security key based on at least one parameter, the security key being used to protect a data session between the device and the equipment. The device is in a non-3GPP access network and connected to the equipment, the network entity is in a 3GPP network, and at least one parameter is used by the device to determine another security key for protecting the data session. The network entity may include components for sending the security key and the at least one parameter to the equipment.

[0421] In some example embodiments, the network entity may further include a component for determining a security key based on at least one of the following: a session key, a device identifier, or at least one parameter.

[0422] In some example embodiments, another security key may be determined based on at least one of the following: a session key, a device identifier, or at least one parameter.

[0423] In some example implementations, a session key can be determined based on a key used to authenticate the 3GPP network.

[0424] In some example embodiments, the session key may include at least one of the following: Master Session Key (MSK) and Extended Master Session Key (EMSK).

[0425] In some example embodiments, the network entity may further include a component for receiving from the device a request for authenticating the device to the 3GPP network. The request may include at least one of the following: an encrypted identifier of the device, a serving network identifier of the 3GPP network configured by the device, and an indication indicating that the request is associated with the device.

[0426] In some example embodiments, the network entity may further include: a component for receiving authentication information for a device from another network entity; a component for receiving response information of the device from the device, the response information being associated with the authentication information; and a component for verifying the response information based on the authentication information.

[0427] In some example embodiments, the network entity may further include: components for sending another request to another network entity in the 3GPP network for authenticating a device in the 3GPP network; and components for receiving a response to the other request from the other network entity, the response including authentication information for the device.

[0428] In some example embodiments, the other request may include at least one of the following: an encrypted identifier of the device, a serving network identifier of the 3GPP network configured by the device, and an indication that the other request is associated with the device.

[0429] In some example embodiments, another network entity may include a device that implements unified data management (UDM) functionality.

[0430] In some example embodiments, the serving network identifier may include a Public Land Mobile Network (PLMN) identifier for a 3GPP network.

[0431] In some example embodiments, the encrypted identifier may include the device’s Subscription Hidden Identifier (SUCI).

[0432] In some example embodiments, at least one parameter may include at least one of the following: a random value, a counter value.

[0433] In some example embodiments, the apparatus may include a terminal device, which may include an evolved packet data gateway (EPDG), and the network entity may include an authentication server function (AUSF).

[0434] In some example embodiments, network entities capable of performing any of the methods in method 2200 (e.g., Figure 1A The network entity 140 may include components for performing corresponding operations of method 2200. These components may be implemented in any suitable form. For example, the components may be implemented in a circuit or software module. The network entity may be implemented as or included in... Figure 1A Among network entities 140.

[0435] In some example embodiments, a network entity may include components for receiving from another network entity a request to authenticate a device in a non-3GPP access network within a 3GPP network, the request including a serving network identifier of the 3GPP network configured by the device. The network entity and the other network entity are in a 3GPP network. The network entity may include: components for determining authentication information for the device based on the serving network identifier; and components for sending a response to the request to the other network entity, wherein the response may include the authentication information.

[0436] In some example embodiments, the request may also include at least one of the following: an encrypted identifier of the device, or an indication that the request is associated with a device.

[0437] In some example embodiments, the encrypted identifier may include the device’s Subscription Hidden Identifier (SUCI).

[0438] In some example embodiments, the serving network identifier may include a Public Land Mobile Network (PLMN) identifier for a 3GPP network.

[0439] In some example embodiments, a network entity may include a unified data management (UDM) function, an apparatus may include an end device, an apparatus may include an evolved packet data gateway (EPDG), and another network entity may include an authentication server function (AUSF).

[0440] Figure 23 This is a simplified block diagram of a device 2300 suitable for implementing an example embodiment of the present disclosure. Device 2300 may be provided to implement a communication device, such as... Figure 1A The apparatus 110, device 120, network entity 130 and network entity 140 shown, and as such Figure 1B Network entities 150 and 160 are shown. As shown, device 2300 includes one or more processors 2310, one or more memories 2320 coupled to processor 2310, and one or more communication modules 2340 coupled to processor 2310.

[0441] Communication module 2340 is used for bidirectional communication. Communication module 2340 has one or more communication interfaces to facilitate communication with one or more other modules or devices. The communication interface can represent any interface necessary for communication with other network elements. In some example embodiments, communication module 2340 may include at least one antenna.

[0442] As a non-limiting example, processor 2310 can be any type suitable for a local technology network and can include one or more of the following: general-purpose computer, special-purpose computer, microprocessor, digital signal processor (DSP), and processor based on a multi-core processor architecture. Device 2300 can have multiple processors, such as application-specific integrated circuit chips that are time-dependent on a clock that synchronizes with the main processor.

[0443] Memory 2320 may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memories include, but are not limited to, read-only memory (ROM) 2324, electrically programmable read-only memory (EPROM), flash memory, hard disk, compact disc (CD), digital video disc (DVD), optical disc, laser disc, and other magnetic and / or optical storage. Examples of volatile memories include, but are not limited to, random access memory (RAM) 2322 and other volatile memories that will not persist for the duration of a power outage.

[0444] Computer program 2330 includes computer-executable instructions that are executed by an associated processor 2310. The instructions of program 2330 may include instructions for performing operations / actions of some example embodiments of this disclosure. Program 2330 may be stored in memory (e.g., ROM 2324). Processor 2310 can perform any suitable actions and processes by loading program 2330 into RAM 2322.

[0445] Example embodiments of this disclosure can be implemented by program 2330, enabling device 2300 to perform as described in the reference. Figures 5 to 22 Any process discussed in this disclosure. Exemplary embodiments of this disclosure may also be implemented by hardware or a combination of software and hardware.

[0446] In some example embodiments, program 2330 may be tangibly contained in a computer-readable medium, which may be included in device 2300 (such as in memory 2320) or in other storage devices accessible by device 2300. Device 2300 may load program 2330 from the computer-readable medium into RAM 2322 for execution. In some example embodiments, the computer-readable medium may include any type of non-transitory storage medium, such as ROM, EPROM, flash memory, hard disk, CD, DVD, etc. As used herein, the term "non-transitory" is a limitation of the medium itself (i.e., tangible, not tactile), rather than a limitation of the persistence of data storage (e.g., RAM versus ROM).

[0447] Figure 24 An example of a computer-readable medium 2400 is shown, which may be in the form of a CD, DVD, or other optical storage disc. The computer-readable medium 2400 has a program 2330 stored thereon.

[0448] Generally, the various embodiments of this disclosure can be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. Some aspects can be implemented in hardware, and others can be implemented in firmware or software that can be executed by a controller, microprocessor, or other computing device. Although various aspects of the embodiments of this disclosure are shown and described as block diagrams, flowcharts, or using some other graphical representation, it should be understood that the blocks, apparatuses, systems, techniques, or methods described herein can be implemented in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware, or controllers or other computing devices, or some combination thereof, as non-limiting examples.

[0449] Some exemplary embodiments of this disclosure also provide at least one computer program product tangibly stored on a computer-readable medium, such as a non-transitory computer-readable medium. The computer program product includes computer-executable instructions that execute in a device on a target physical or virtual processor, such as those included in a program module, to perform any of the methods described above. Typically, a program module includes routines, programs, libraries, objects, classes, components, data structures, etc., that perform a particular task or implement a particular abstract data type. In various embodiments, the functionality of a program module can be combined or split among program modules as needed. The machine-executable instructions for a program module can execute within a local or distributed device. In a distributed device, the program module can reside on both local and remote storage media.

[0450] Program code used to perform the methods of this disclosure may be written in any combination of one or more programming languages. The program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that, when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a stand-alone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0451] In the context of this disclosure, computer program code or related data may be carried by any suitable carrier wave to enable a device, apparatus, or processor to perform the various processes and operations described above. Examples of carrier waves include signals, computer-readable media, etc.

[0452] Computer-readable media can be computer-readable signal media or computer-readable storage media. Computer-readable media can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any suitable combination thereof. More specific examples of computer-readable storage media will include electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable optical disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0453] Furthermore, although operations are described in a specific order, this should not be construed as requiring that such operations be performed in the specific order shown or sequentially, or requiring that all shown operations be performed to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Similarly, although several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure, but rather as a description of features that may be specific to particular embodiments. Unless explicitly stated otherwise, certain features described in the context of a single embodiment may also be implemented in combination in a single embodiment. Conversely, unless explicitly stated otherwise, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0454] Although this disclosure has been described in language specific to structural features and / or methodological actions, it should be understood that the disclosure as defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are disclosed as exemplary forms for implementing the claims.

[0455] Furthermore, the various implementations of this disclosure can be described with reference to the following terms, and their features can be combined in any reasonable manner.

[0456] Clause 1. An apparatus comprising: At least one processor; and At least one memory, the at least one memory storing instructions, the instructions, when executed by the at least one processor, cause the device to at least: At least based on a session key, a security key is determined, the security key being used to protect a data session between the device and the equipment, wherein the session key is used by a network entity in a 3GPP network to determine another security key for protecting the data session, and wherein the device is in a non-3GPP access network and is connected to the equipment; and Based on the security key, communication is performed using the data session.

[0457] Clause 2. The apparatus according to Clause 1, wherein said apparatus is such that: Send a request to the device for authenticating the device to the 3GPP network, the request including the encrypted identifier of the device.

[0458] Clause 3. The device as described in Clause 2, wherein the encrypted identifier includes the device’s subscription hidden identifier SUCI.

[0459] Clause 4. The apparatus according to Clause 2 or 3, wherein said apparatus is such that: After receiving a response to the request from the device, the security key is determined at least based on the session key.

[0460] Clause 5. An apparatus according to any one of Clauses 1 to 4, wherein the session key is determined based on a key used to authenticate the apparatus to the 3GPP network.

[0461] Clause 6. The apparatus according to any one of Clauses 1 to 5, wherein the session key includes at least one of the following: Master Session Key (MSK) Extend the master session key EMSK.

[0462] Clause 7. An apparatus according to any one of Clauses 1 to 6, wherein the apparatus includes a terminal device, the device includes an evolved packet data gateway (EPDG), and the network entity includes an authentication server function (AUSF).

[0463] Clause 8. An apparatus comprising: At least one processor; and At least one memory, the at least one memory storing instructions, the instructions, when executed by the at least one processor, cause the device to at least: A security key is received from a network entity in a 3GPP network. This security key is used to protect a data session between a device and the device located in a non-3GPP access network. The security key is determined based on a session key, which is used by the device to determine another security key for protecting the data session. Based on the security key, communication is performed using the data session.

[0464] Clause 9. The device as described in Clause 8, wherein said device is configured to: Receive from the device a request for authenticating the device to the 3GPP network, the request including an encrypted identifier of the device; and Send a response to the request to the device.

[0465] Clause 10. The device according to Clause 8 or 9, wherein said device is configured to: Send another request to the network entity for authenticating the device to the 3GPP network, wherein the other request includes at least one of the following: The device's encryption identifier, The 3GPP network's service network identifier configured by the device, An indication used to indicate that the other request is associated with the device.

[0466] Clause 11. The device as described in Clause 10, wherein the serving network identifier includes the Public Land Mobile Network (PLMN) identifier of the 3GPP network.

[0467] Clause 12. The device as described in Clause 9 or 10, wherein the encrypted identifier includes the device’s subscription hidden identifier SUCI.

[0468] Clause 13. The device according to any one of Clauses 8 to 12, wherein the device is such that: The security key is stored in context information associated with the device, wherein the context information includes at least one of the following: The security key, Configuration information for the security of the data session, The temporary identifier of the device.

[0469] Clause 14. The device according to any one of Clauses 8 to 13, wherein the session key is determined based on a key used to authenticate the device to the 3GPP network.

[0470] Clause 15. The device according to any one of Clauses 8 to 14, wherein the session key includes at least one of the following: Master Session Key (MSK) Extend the master session key EMSK.

[0471] Clause 16. The apparatus according to any one of Clauses 8 to 15, wherein the apparatus includes a terminal device, the apparatus includes an evolved packet data gateway (EPDG), and the network entity includes an authentication server function (AUSF).

[0472] Clause 17. A network entity comprising: At least one processor; and At least one memory storing instructions that, when executed by the at least one processor, cause the network entity to at least: At least based on a session key, a security key is determined, the security key being used to protect a data session between a device and a network entity, wherein the device is in a non-3GPP access network and is connected to the network entity, the network entity is in a 3GPP network, and the session key is used by the device to determine another security key for protecting the data session; and Send the security key to the device.

[0473] Clause 18. A network entity as described in Clause 17, wherein said network entity is such that: The session key is determined based on the key, and the key is used to authenticate the device to the 3GPP network.

[0474] Clause 19. A network entity as described in Clause 17 or 18, wherein the session key includes at least one of the following: Master Session Key (MSK) Extend the master session key EMSK.

[0475] Clause 20. A network entity pursuant to any one of Clauses 17 to 19, wherein said network entity is such that: The device receives a request for authenticating the device to a 3GPP network, wherein the request includes at least one of the following: The device's encryption identifier, The 3GPP network's service network identifier configured by the device, An indication used to indicate that the request is associated with the device.

[0476] Clause 21. A network entity pursuant to any one of Clauses 17 to 20, wherein said network entity is such that: Receive authentication information for the device from another network entity; Receive response information from the device, the response information being associated with the authentication information; and Based on the authentication information, verify the response information.

[0477] Clause 22. A network entity as described in Clause 21, wherein said network entity is such that: Send another request to the other network entity in the 3GPP network for authenticating the device in the 3GPP network; and Receive a response to the other request from the other network entity, the response including the authentication information for the device.

[0478] Clause 23. A network entity as described in Clause 22, wherein said other request includes at least one of the following: The device's encryption identifier, The 3GPP network's service network identifier configured by the device, An indication used to indicate that the other request is associated with the device.

[0479] Clause 24. A network entity as described in Clause 22 or 23, wherein the other network entity includes a device that implements Unified Data Management (UDM) functionality.

[0480] Clause 25. A network entity as described in Clause 20 or 23, wherein the serving network identifier includes the Public Land Mobile Network (PLMN) identifier of the 3GPP network.

[0481] Clause 26. A network entity as described in Clause 20 or 23, wherein the encrypted identifier includes the device’s subscription hidden identifier SUCI.

[0482] Clause 27. A network entity pursuant to any one of Clauses 17 to 26, wherein the apparatus includes a terminal device, the device includes an evolved packet data gateway (EPDG), and the network entity includes an authentication server function (AUSF).

[0483] Clause 28. A network entity comprising: At least one processor; and At least one memory storing instructions that, when executed by the at least one processor, cause the network entity to at least: Receive a request from another network entity for authenticating a device in a non-3GPP access network to a 3GPP network, the request including a serving network identifier configured by the device for the 3GPP network, wherein the network entity and the other network entity are in the 3GPP network; Based on the service network identifier, authentication information for the device is determined; and Send a response to the request to the other network entity, wherein the response includes the authentication information.

[0484] Clause 29. The network device as described in Clause 28, wherein the request further includes at least one of the following: an encrypted identifier of the device, and an indication indicating that the request is associated with the device.

[0485] Clause 30. The network device as described in Clause 29, wherein the encrypted identifier includes the device’s subscription hidden identifier SUCI.

[0486] Clause 31. A network entity pursuant to any one of Clauses 28 to 30, wherein the serving network identifier includes the Public Land Mobile Network (PLMN) identifier of the 3GPP network.

[0487] Clause 32. A network device according to any one of Clauses 28 to 31, wherein the network entity includes a Unified Data Management (UDM) function, the device includes a terminal device, the device includes an Evolved Packet Data Gateway (EPDG), and the other network entity includes an Authentication Server (AUSF) function.

[0488] Clause 33. A network entity comprising: At least one processor; and At least one memory storing instructions that, when executed by the at least one processor, cause the network entity to at least: The device receives a request to authenticate a device to a 3GPP network, wherein the device is in a non-3GPP access network and is connected to the device, and the network entity is in the 3GPP network; Send another request to another network entity for authenticating the device in the 3GPP network, wherein the other network entity is in the 3GPP network; Receive authentication information for the device from the other network entity; Receive response information from the device, the response information being associated with the authentication information; and Based on the authentication information, verify the response information.

[0489] Clause 34. A network entity as described in Clause 33, wherein said request includes at least one of the following: The device's identification, The access network identifier of the non-3GPP access network.

[0490] Clause 35. A network entity as described in Clause 33 or 34, wherein said other request includes at least one of the following: The device's identification, The access network identifier of the non-3GPP access network.

[0491] Clause 36. A network entity pursuant to any one of Clauses 33 to 35, wherein the other network entity includes a unified data management (UDM) function, wherein the network entity is configured to: Receive authentication information for the device from the other network entity, wherein the authentication information for the device is obtained from the Home Subscriber Server (HSS) in the 3GPP network.

[0492] Clause 37. A network entity pursuant to any one of Clauses 33 to 36, wherein the other network entity includes a Home Subscriber Server (HSS), wherein the network entity is such that: Receive authentication information for the device from the other network entity, wherein the authentication information for the device is determined by the other network entity.

[0493] Clause 38. A network entity pursuant to any one of Clauses 33 to 37, wherein the network entity includes an Authentication Server Function (AUSF), the apparatus includes a terminal device, and the apparatus includes an Evolved Packet Data Gateway (EPDG).

[0494] Clause 39. A network entity comprising: At least one processor; and At least one memory storing instructions that, when executed by the at least one processor, cause the network entity to at least: Receive a request from another network entity for authenticating a device in a 3GPP network, wherein the device is in a non-3GPP access network and is connected to the device, and both the network entity and the other network entity are in the 3GPP network; and Send a response to the request to the other network entity, the response including authentication information for the device.

[0495] Clause 40. A network entity as described in Clause 39, wherein said network entity includes a Home Subscriber Server (HSS), and said network entity is such that: The request is received from the other network entity, wherein the request includes at least one of the following: The device's identification, The access network identifier of the non-3GPP access network; Based on the request, determine the authentication information for the device; and Send a response to the request to the other network entity, wherein the response includes the authentication information.

[0496] Clause 41. A network entity as described in Clause 39, wherein the network entity includes a unified data management (UDM) function, and the network entity is configured to: Receive the request from the other network entity; and Send another request to the Home Subscriber Server (HSS) in the 3GPP network for authenticating the device with the 3GPP network, wherein the other request includes at least one of the following: The device's identification, The access network identifier of the non-3GPP access network.

[0497] Clause 42. The network entity as described in Clause 41, wherein said network entity is such that: Receive another response from the HSS to the other request, wherein the other response includes the authentication information for the device; and Send a response to the request to the other network entity, wherein the response includes the authentication information.

[0498] Clause 43. A network entity pursuant to any one of Clauses 39 to 42, wherein the means includes a terminal device, and the other network entity includes the authentication server function AUSF.

[0499] Clause 44. A method comprising: At the device, a security key is determined based at least on a session key, the security key being used to protect a data session between the device and the equipment, wherein the session key is used by a network entity in a 3GPP network to determine another security key for protecting the data session, and wherein the device is in a non-3GPP access network and is connected to the equipment; and Based on the security key, communication is performed using the data session.

[0500] Clause 45. A method comprising: The device receives a security key from a network entity in a 3GPP network. This security key is used to protect a data session between the device and the network entity, wherein the device is in a non-3GPP access network and connected to the network entity. The security key is determined based on a session key, and this session key is used by the device to determine another security key for protecting the data session. Based on the security key, communication is performed using the data session.

[0501] Clause 46. A method comprising: At the network entity, at least based on the session key, a security key is determined for protecting a data session between a device and a network entity, wherein the device is in a non-3GPP access network and is connected to the network entity, the session key is used by the device to determine another security key for protecting the data session; and Send the security key to the device.

[0502] Clause 47. A method comprising: At a network entity, a request is received from another network entity for authenticating a device in a non-3GPP access network to a 3GPP network. The request includes a serving network identifier configured by the device for the 3GPP network, wherein the network entity and the other network entity are in the 3GPP network. Based on the service network identifier, authentication information for the device is determined; and Send a response to the request to the other network entity, wherein the response includes the authentication information.

[0503] Clause 48. A method comprising: The network entity receives a request from the device for authenticating a device to a 3GPP network, wherein the device is in a non-3GPP access network and is connected to the device, and the network entity is in the 3GPP network. Send another request to another network entity for authenticating the device in the 3GPP network, wherein the other network entity is in the 3GPP network; Receive authentication information for the device from the other network entity; Receive response information from the device, the response information being associated with the authentication information; and Based on the authentication information, verify the response information.

[0504] Clause 49. A method comprising: At a network entity, a request for authenticating a device to a 3GPP network is received from another network entity, wherein the device is in a non-3GPP access network and is connected to the device, and both the network entity and the other network entity are in the 3GPP network; and Send a response to the request to the other network entity, the response including authentication information for the device.

[0505] Clause 50. An apparatus comprising: Components for determining a security key based at least on a session key, the security key being used to protect a data session between the device and the equipment, wherein the session key is used by a network entity in a 3GPP network to determine another security key for protecting the data session, and wherein the device is in a non-3GPP access network and is connected to the equipment; and A component for performing communication using the data session based on the security key.

[0506] Clause 51. An apparatus comprising: Components for receiving a security key from a network entity in a 3GPP network, the security key being used to protect a data session between a device and a device located in a non-3GPP access network and connected to the device, the security key being determined based on a session key, and the session key being used by the device to determine another security key for protecting the data session; and A component for performing communication using the data session based on the security key.

[0507] Clause 52. A network entity comprising: Components for determining a security key based at least on a session key, the security key being used to protect a data session between a device and a network entity, wherein the device is in a non-3GPP access network and is connected to the network entity, the network entity is in a 3GPP network, and the session key is used by the device to determine another security key for protecting the data session; and A component used to send the security key to the device.

[0508] Clause 53. A network entity comprising: Components for receiving from another network entity a request for authenticating a device in a non-3GPP access network to a 3GPP network, the request including a serving network identifier of the 3GPP network configured by the device, wherein the network entity and the other network entity are in the 3GPP network; Components for determining authentication information for the device based on the service network identifier; and A component for sending a response to the request to the other network entity, wherein the response includes the authentication information.

[0509] Clause 54. A network entity comprising: Components for receiving from a device a request for authentication of a 3GPP network device, wherein the device is in a non-3GPP access network and is connected to the device, and the network entity is in the 3GPP network; Components for sending another request to another network entity for authenticating the device to the 3GPP network, wherein the other network entity is in the 3GPP network; Components for receiving authentication information for the device from the other network entity; Components for receiving response information from the device, the response information being associated with the authentication information; and A component used to verify the response information based on the authentication information.

[0510] Clause 55. A network entity comprising: Components for receiving a request from another network entity for authenticating a device to a 3GPP network, wherein the device is in a non-3GPP access network and is connected to the device, and both the network entity and the other network entity are in the 3GPP network; and A component for sending a response to the request to the other network entity, the response including authentication information for the device.

[0511] Clause 56. A computer-readable medium comprising instructions stored thereon for causing an apparatus to perform at least the method according to any one of Clauses 44 to 49.

Claims

1. A device for communication, comprising: At least one processor; as well as At least one memory, the at least one memory storing instructions, the instructions, when executed by the at least one processor, cause the device to at least: At least based on a session key, a security key is determined, the security key being used to protect a data session between the device and the equipment, wherein the session key is used by a network entity in a 3GPP network to determine another security key for protecting the data session, and wherein the device is in a non-3GPP access network and is connected to the equipment; as well as Based on the security key, communication is performed using the data session.

2. The apparatus of claim 1, wherein the apparatus is configured to: Send a request to the device for authenticating the device to the 3GPP network, the request including the encrypted identifier of the device.

3. The apparatus of claim 2, wherein the encrypted identifier includes the apparatus's subscription hiding identifier SUCI.

4. The apparatus according to claim 2 or 3, wherein the apparatus is configured to: After receiving a response to the request from the device, the security key is determined at least based on the session key.

5. The apparatus of claim 2 or 3, wherein the session key is determined based on a key used to authenticate the apparatus to the 3GPP network.

6. The apparatus of claim 2 or 3, wherein the session key comprises at least one of the following: Master Session Key (MSK) Extend the master session key EMSK.

7. The apparatus of claim 2 or 3, wherein the apparatus includes a terminal device, the device includes an evolved packet data gateway (EPDG), and the network entity includes an authentication server function (AUSF).

8. A device for communication, comprising: At least one processor; as well as At least one memory, the at least one memory storing instructions, the instructions, when executed by the at least one processor, cause the device to at least: A security key is received from a network entity in a 3GPP network. The security key is used to protect a data session between the device and the device, wherein the device is in a non-3GPP access network and is connected to the device. The security key is determined based on a session key, and the session key is used by the device to determine another security key for protecting the data session. as well as Based on the security key, communication is performed using the data session.

9. The apparatus of claim 8, wherein the apparatus is configured to: Receive from the device a request for authenticating the device to the 3GPP network, the request including an encrypted identifier of the device; and Send a response to the request to the device.

10. The device according to claim 8 or 9, wherein the device is configured to: Send another request to the network entity for authenticating the device to the 3GPP network, wherein the other request includes at least one of the following: The device's encryption identifier, The 3GPP network's service network identifier configured by the device, An indication used to indicate that the other request is associated with the device.

Images