Network nodes and methods therein for enhanced authentication

Abstract

The present disclosure provides a method (100) in an Authentication Server Function, AUSF. The method (100) includes receiving (110) an authentication request including a first Identifier, ID, associated with a terminal device and a first Non-Seamless Wireless Local Area Network 'WLAN' Offload, NSWO, indicator; and transmitting (120), in response to a successful authentication of the terminal device or in response to receiving an indication of the successful authentication, a first request to a Unified Data Management, UDM, the first request including a second ID associated with the terminal device, and a second NSWO indicator.

Description

[0001] NETWORK NODES AND METHODS THEREIN FOR ENHANCED AUTHENTICATION

[0002] TECHNICAL FIELD

[0003] The present disclosure relates to communication technology, and more particularly, to network nodes and methods therein for enhanced authentication.

[0004] BACKGROUND

[0005] The 3rd Generation Partnership Project (3GPP) Technical Specification (TS) 33.501 , v18.3.0, which is incorporated herein by reference in its entirety, specifies in Annex I procedures for Non-Public Networks (NPNs), especially Standalone NPNs (SNPNs).

[0006] The main difference between SNPNs and Public Land Mobile Networks (PLMNs) from a security point of view is that for SNPNs, any key-generating Authentication and Key Agreement (Extensible Authentication Protocol) method is allowed to be used for primary authentication, while for PLMNs only 5th Generation (5G) Authentication and Key Agreement (AKA) or Improved EAP Method for 3rd Generation AKA (EAP-AKA1) are allowed.

[0007] Some of key-generating EAP-methods support privacy at the EAP-layer. One example of such method is EAP-Transport Layer Security (TLS). When using the EAP-TLS, it is possible to replace a privacy mechanism defined by the 3GPP (e.g., Subscription Concealed Identifier (SUCI) as defined in clause 5.2.5. of TS 33.501) with a privacy mechanism provided by the EAP mechanism. One such example can be found in Annex B.2.1 .2.2 of TS 33.501 .

[0008] When utilizing the privacy mechanism at the EAP layer, a terminal device, or referred to as User Equipment (UE), sends an anonymous SUCI to an Authentication Server Function (AUSF) and a Unified Data Management (UDM). The real UE ID, e.g., Subscription Permanent Identifier (SUPI), is not revealed to the AUSF until after a successful authentication. This differs from the “normal” case where the UDM finds the SUPI before the actual authentication is performed and can thus verify that the UE has indeed a valid subscription. When using the anonymous SUCI, the UDM instead needs to verify that the UE has a valid subscription after the successful authentication. This is described in steps 11-13 of Annex I.2.2.2.2 of TS 33.501.

[0009] Non-Seamless Wireless Local Area Network (WLAN) Offload (NSWO) is a method for the network to offload some traffic to WLAN access points instead of going through the 5thGeneration Core (5GC). The UE is authenticated using its 3GPP credentials. The UE is however not registered to the home network, only authenticated.

[0010] Security procedures for NSWO in PLMNs are defined in Annex S of TS 33.501 . Security procedures for NSWO for SNPNs are defined in Annex 1.10.5 in TS 33.501.

[0011] Unlike primary authentication, the authentication procedure for NSWO does not generate the master key KAUSF. Neither does the AUSF send an authentication result to the UDM using a Nudm_UEAuthentication_ResultConfirmation service operation. The Nudm_UEAuthentication_ResultConfirmation service operation is used for linking increased home control to subsequent procedures (e.g., UE registration), or used for allowing the UDM to keep track of the AUSF that stores the KAUSF to be used for features, e.g., Steering of Roaming or UE Parameter Update etc., as stated in clause 6.1.4 of TS 33.501.

[0012] SUMMARY

[0013] When an authentication method other than 5G AKA or EAP-AKA is selected for an SNPN, the UDM is not involved in the actual authentication. Instead, another entity, e.g., the AUSF or Credentials Holder (CH) Authentication, Authorization, and Accounting (AAA) server is responsible for authentication of the UE.

[0014] As described above, when the authentication method supporting privacy at the EAP layer is used instead of a 3GPP privacy mechanism, an anonymous SUCI can be used, in which case the UDM cannot verify that the UE has a valid subscription until after the UE has been authenticated.

[0015] In the case of primary authentication, after a successful authentication of the UE, the AUSF informs the UDM of the authentication result for the authenticated SUPI and that the UDM shall verify that there is a valid subscription for the authenticated SUPI. If a valid subscription is found, the UDM shall also store the authentication result. See steps 11-13 in Annex 1.2.2.2.2 and steps 15-17 of Annex 0.3 of TS 33.501 .

[0016] However, in the case of NSWO with an EAP-method supporting privacy at the EAP-layer, e.g., in the case of NSWO in SNPN as specified in Annex 1.10.5.2 of TS 33.501 , there is no such verification that the UE has a valid subscription. It is hence possible that the AUSF may authenticate the UE and send a successful authentication response even if the UE does not have a valid subscription.

[0017] It is an object of the present disclosure to provide network nodes and methods therein, capable of enhancing the authentication process in the above NSWO case.

[0018] According to a first aspect of the present disclosure, a method in an AUSF is provided. The method includes receiving an authentication request including a first ID associated with a terminal device and a first NSWO indicator. The method further includes transmitting, in response to a successful authentication of the terminal device or in response to receiving an indication of the successful authentication, a first request to a UDM. The first request includes a second ID associated with the terminal device, and a second NSWO indicator.

[0019] In an embodiment, the first ID may be an anonymous ID.

[0020] In an embodiment, the first ID may be an anonymous SUCI.

[0021] In an embodiment, the second ID may be a SUPI.

[0022] In an embodiment, the authentication of the terminal device may be performed at the AUSF or an AAA server.

[0023] In an embodiment, the first request may be an authentication result confirmation request. In an embodiment, the authentication of the terminal device may be performed based on SNPN credentials.

[0024] In an embodiment, the authentication of the terminal device may be performed using an EAP method that supports privacy at an EAP layer.

[0025] In an embodiment, the method may further include receiving, from the UDM, a first response indicating subscription information corresponding to the second ID, or indicating whether the second ID corresponds to a valid subscription or not.

[0026] In an embodiment, the method may further include transmitting, when the first response indicates the subscription information or indicates that the second ID corresponds to a valid subscription, an authentication response indicating a successful authentication, or transmitting, when the first response indicates that the second ID does not correspond to a valid subscription, an authentication response indicating that the authentication request is rejected.

[0027] In an embodiment, the first response may be an authentication result confirmation response.

[0028] According to a second aspect of the present disclosure, a method in a UDM is provided. The method includes receiving, from an AUSF, a first request including a second ID associated with a terminal device, and an NSWO indicator. The method further includes transmitting, to the AUSF, a first response indicating subscription information corresponding to the second ID or indicating whether the second ID corresponds to a valid subscription or not.

[0029] In an embodiment, the first request may further include an authentication state of a terminal device, and the method may further include: refraining, in response to the NSWO indicator, from storing the authentication state at the UDM.

[0030] In an embodiment, the second ID may be a SUPI.

[0031] In an embodiment, the first request may be an authentication result confirmation request, and the first response may be an authentication result confirmation response. In an embodiment, the method may further include, prior to receiving the first request, receiving, from the AUSF, an authentication request including a first ID associated with the terminal device.

[0032] In an embodiment, the first ID may be an anonymous ID.

[0033] In an embodiment, the first ID may be an anonymous SUCI.

[0034] According to a third aspect of the present disclosure, a network node is provided. The network node includes a communication interface, a processor, and a memory. The memory contains instructions executable by the processor whereby the network node is operative to, when implementing an AUSF, perform the method according to the above first aspect, or when implementing a UDM, perform the method according to the above second aspect.

[0035] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided. The computer-readable storage medium has computer-readable instructions stored thereon. The computer-readable instructions, when executed by a processor of a network node, configure the network node to, when implementing an AUSF, perform the method according to the above first aspect, or when implementing a UDM, perform the method according to the above second aspect.

[0036] With the embodiments of the present disclosure, in an NSWO authentication process, after successful authentication of a terminal device, an AUSF can transmit a request to an UDM, which allows the UDM to verify whether the authenticated terminal device corresponds to a valid subscription. In this way, even though the UDM is not involved in the authentication, e.g., when an EAP method supporting privacy is used (where the privacy may be achieved using an anonymous UE ID), the subscription of the terminal device can be verified by the UDM, such that a terminal device that does not have a valid subscription can be rejected.

[0037] BRIEF DESCRIPTION OF THE DRAWINGS The above and other objects, features and advantages will be more apparent from the following description of embodiments with reference to the figures, in which:

[0038] Fig. 1 is a flowchart illustrating a method in an AUSF according to an embodiment of the present disclosure;

[0039] Fig. 2 is a flowchart illustrating a method in a UDM according to an embodiment of the present disclosure;

[0040] Fig. 3 is a sequence diagram of an example of an authentication process according to an embodiment of the present disclosure;

[0041] Fig. 4 is a block diagram of an AUSF node according to an embodiment of the present disclosure;

[0042] Fig. 5 is a block diagram of a UDM node according to an embodiment of the present disclosure;

[0043] Fig. 6 is a block diagram of a network node according to an embodiment of the present disclosure;

[0044] Fig. 7 schematically illustrates a telecommunication network connected via an intermediate network to a host computer;

[0045] Fig. 8 is a generalized block diagram of a host computer communicating via a base station with a user equipment over a partially wireless connection; and

[0046] Figs. 9 to 12 are flowcharts illustrating methods implemented in a communication system including a host computer, a base station and a user equipment.

[0047] DETAILED DESCRIPTION

[0048] As used herein, the term “network” refers to a network following any suitable communication standards, such as NR, LTE-Advanced (LTE-A), LTE, Wideband Code Division Multiple Access (WCDMA), High-Speed Packet Access (HSPA), and so on. Furthermore, the communications between a terminal device and a network node in the network may be performed according to any suitable generation communication protocols, including, but not limited to, Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), and / or other suitable 1G (the first generation), 2G (the second generation), 2.5G, 2.75G, 3G (the third generation), 4G (the fourth generation), 4.5G, 5G (the fifth generation) communication protocols, wireless local area network (WLAN) standards, such as the IEEE 802.11 standards; and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, and / or Zig Bee standards, and / or any other protocols either currently known or to be developed in the future.

[0049] In the present disclosure, a network function, or NF, can be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g. on a cloud infrastructure. The term “network node” refers to any physical or virtual node configured to implement a network function.

[0050] The term "terminal device" or “UE” refers to any end device that can access a wireless communication network and receive services therefrom. By way of example and not limitation, the terminal device refers to a mobile terminal, user equipment (UE), or other suitable devices. The UE may be, for example, a Subscriber Station (SS), a Portable Subscriber Station, a Mobile Station (MS), or an Access Terminal (AT). The terminal device may include, but not limited to, portable computers, desktop computers, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones, tablets, personal digital assistants (PDAs), wearable terminal devices, vehicle-mounted wireless terminal devices, wireless endpoints, mobile stations, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), USB dongles, smart devices, wireless customer-premises equipment (CPE) and the like. In the following description, the terms "terminal device", "terminal", "user equipment" and "UE" may be used interchangeably. As one example, a terminal device may represent a UE configured for communication in accordance with one or more communication standards promulgated by the 3rd Generation Partnership Project (3GPP), such as 3GPP's GSM, UMTS, LTE, and / or 5G standards. As used herein, a "user equipment" or "UE" may not necessarily have a "user" in the sense of a human user who owns and / or operates the relevant device. In some embodiments, a terminal device may be configured to transmit and / or receive information without direct human interaction. For instance, a terminal device may be designed to transmit information to a network on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the wireless communication network. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but that may not initially be associated with a specific human user.

[0051] References in the specification to "one embodiment," "an embodiment," "an example embodiment," and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0052] It shall be understood that although the terms "first" and "second" etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed terms. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises", "comprising", "has", "having", "includes" and / or "including", when used herein, specify the presence of stated features, elements, and / or components etc., but do not preclude the presence or addition of one or more other features, elements, components and / or combinations thereof.

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

[0054] Fig. 1 is a flowchart illustrating a method 100 according to an embodiment of the present disclosure. The method 100 can be performed by an AUSF or a network node implementing the AUSF. At block 110, the AUSF receives an authentication request including a first ID associated with a terminal device and a first NSWO indicator, e.g., from an NSWO Function (NSWOF).

[0055] In an example, the first ID may be an anonymous ID. More generally, the first ID may be an ID that is not usable by a UDM for verifying whether there is a valid subscription corresponding to that ID, or an ID that does not uniquely identifies the terminal device (e.g., a group ID). For example, the first ID may be an anonymous SUCI. The first NSWO indicator may indicate to the AUSF that the authentication request is for NSWO purposes.

[0056] At block 120, in response to a successful authentication of the terminal device (e.g., when the authentication of the terminal device is performed at the AUSF) or in response to receiving an indication of the successful authentication (e.g., when the authentication of the terminal device is performed at an AAA server), the AUSF transmits a first request to a UDM. The first request includes a second ID associated with the terminal device, and a second NSWO indicator.

[0057] Here, the second ID may be a SUPI. The first request may be an authentication result confirmation request. The second NSWO indicator may indicate to the UDM that the first request is for NSWO purposes. The second NSWO indicator may or may not be same as the first NSWO indicator.

[0058] In an example, the authentication of the terminal device may be performed based on SNPN credentials. The authentication of the terminal device may be performed using an EAP method that supports privacy at an EAP layer. As described above, when such EAP method is used, an anonymous SUCI may be used and thus the UDM cannot obtain a SUPI by de-concealing the anonymous SUCI, but can only obtain the SUPI after successful authentication of the terminal device, and can then verify whether there is a valid subscription corresponding to the SUPI.

[0059] In an example, after the block 120, the AUSF may receive, from the UDM, a first response indicating whether the second ID corresponds to a valid subscription or not, or indicating subscription information corresponding to the second ID (e.g., when there is a valid subscription corresponding to the second ID). Here, the first response may be an authentication result confirmation response.

[0060] When the first response indicates the subscription information or indicates that the second ID corresponds to a valid subscription, the AUSF may transmit an authentication response indicating a successful authentication. Alternatively, when the first response indicates that the second ID does not correspond to a valid subscription, the AUSF may transmit an authentication response indicating that the authentication request is rejected. In this case, the authentication request is rejected not because of a failed authentication, but because of lack of a valid subscription. Here, the authentication response may be transmitted, e.g., to the NSWOF.

[0061] Fig. 2 is a flowchart illustrating a method 200 according to an embodiment of the present disclosure. The method 200 can be performed by a UDM or a network node implementing the UDM.

[0062] At block 210, the UDM receives, from an AUSF, a first request including a second ID associated with a terminal device, and an NSWO indicator.

[0063] In an example, the second ID may be a SUPI. The first request may be an authentication result confirmation request. The NSWO indicator may indicate to the UDM that the first request is for NSWO purposes.

[0064] In an example, the first request further includes an authentication state of a terminal device. The authentication state, or referred to as authentication result, may indicate, among others, an indication of authentication success and an ID of the AUSF. For details of the authentication state, reference can be made to the 3GPP TS 29.503, v18.3.0, which is incorporated herein by reference in its entirety, and particularly clauses 5.4.2.3.2 and 6.3.6.2.7.

[0065] In response to the NSWO indicator, the UDM may refrain from storing the authentication state at the UDM. That is, the UDM knows from the NSWO indicator that the authentication is not primary authentication but for NSWO, and thus does not store the authentication state, e.g., does not update or overwrite an authentication state previously stored at the UDM (if any), which may be an authentication state of primary authentication. In this way, the UDM will not lose its track of the AUSF that stores the KAUSF to be used for features, e.g., Steering of Roaming or UE Parameter Update etc.

[0066] At block 220, the UDM transmits, to the AUSF, a first response indicating whether the second ID corresponds to a valid subscription or not, or indicating subscription information corresponding to the second ID (e.g., when there is a valid subscription corresponding to the second ID).

[0067] Here, the first response may be an authentication result confirmation response.

[0068] In an example, before the block 210, the UDM may receive, from the AUSF, an authentication request including a first ID associated with the terminal device. Here, the first ID may be an anonymous ID. More generally, the first ID may be an ID that is not usable by the UDM for verifying whether there is a valid subscription corresponding to that ID, or an ID that does not uniquely identifies the terminal device (e.g., a group ID). For example, the first ID may be an anonymous SUCI. The UDM cannot verify whether there is a valid subscription corresponding to the anonymous SUCI, but can only verify whether there is a valid subscription corresponding to the SUPI as received later in the block 210.

[0069] The methods 100 and 200 will be further explained below with reference to Fig. 3, which shows an example of an authentication process.

[0070] As shown in Fig. 3, at Step 1 , a UE sends an NSWO Request to an NSWOF. The NSWO Request includes an anonymous SUCI.

[0071] At Step 2, the NSWOF sends a Nausf_UEAuthentication_Authenticate Request with the anonymous SUCI and an NSWO indicator towards an AUSF. The NSWO indicator is used to indicate to the AUSF that the authentication request is for NSWO purposes.

[0072] At Step 3, the AUSF sends a Nudm_UEAuthentication_Get Request to a UDM, including the anonymous SUCI and the NSWO indicator. At Step 4, the UDM decides to run authentication with another entity, e.g., the AUSF or an AAA server.

[0073] At Step 5, the UDM sends a Nudm_UEAuthentication_Get Response to the AUSF, the Response including an anonymous SUPI.

[0074] At Step 6, EAP authentication of the UE is performed, with the AUSF or the AAA server as an EAP authentication server. From the successful EAP authentication process, the AUSF obtains a (real) SUPI of the UE.

[0075] At Step 7, the AUSF sends a Nudm_UEAU_ResultConfirmation Request to the UDM. The Request includes the SUPI and an NSWO indicator. The NSWO indicator is used to indicate to the UDM that the Request is for NSWO purposes.

[0076] At Step 8, the UDM verifies whether the SUPI corresponds to a valid subscription. The UDM does not store the authentication state of the SUPI.

[0077] At Step 9, the UDM sends a Nudm_UEAU_ResultConfirmation Response to the AUSF. If the SUPI corresponds to a valid subscription, the Response indicates verification success or subscription information corresponding to the SUPI. If there is no valid subscription corresponding to the SUPI, the Response indicates an error.

[0078] At Step 10, the AUSF sends a Nausf_UEAuthentication_Authenticate Response to the NSWOF. If the Response received at Step 9 indicates success (or subscription information), the Response at Step 10 indicates a successful authentication (EAP success). If Response received at Step 9 indicates error, the Response at Step 10 indicates that the authentication request is rejected.

[0079] At Step 11 , the NSWOF sends an NSWO response to the UE, indicating EAP success.

[0080] For further details of the above Steps 1 ~6 and 9~11 , reference can be made to Annex S.3.2 and Annex 1.10.5.2 of TS 33.501. Correspondingly to the method 100 as described above, an AUSF node is provided. Fig. 4 is a block diagram of a network node 400 according to an embodiment of the present disclosure. The network node 400 is configured to implement an AUSF.

[0081] As shown in Fig. 4, the network node 400 includes a receiving unit 410 configured to receiving an authentication request including a first ID associated with a terminal device and a first NSWO indicator. The network node 400 further includes a transmitting unit 420 configured to transmit, in response to a successful authentication of the terminal device or in response to receiving an indication of the successful authentication, a first request to a UDM. The first request includes a second ID associated with the terminal device, and a second NSWO indicator.

[0082] In an embodiment, the first ID may be an anonymous ID.

[0083] In an embodiment, the first ID may be an anonymous SUCI.

[0084] In an embodiment, the second ID may be a SUPI.

[0085] In an embodiment, the authentication of the terminal device may be performed at the AUSF or an AAA server.

[0086] In an embodiment, the first request may be an authentication result confirmation request.

[0087] In an embodiment, the authentication of the terminal device may be performed based on SNPN credentials.

[0088] In an embodiment, the authentication of the terminal device may be performed using an EAP method that supports privacy at an EAP layer.

[0089] In an embodiment, the receiving unit 410 may be further configured to receive, from the UDM, a first response indicating subscription information corresponding to the second ID, or indicating whether the second ID corresponds to a valid subscription or not. In an embodiment, the transmitting unit 420 may be further configured to transmit, when the first response indicates the subscription information or indicates that the second ID corresponds to a valid subscription, an authentication response indicating a successful authentication, or transmit, when the first response indicates that the second ID does not correspond to a valid subscription, an authentication response indicating that the authentication request is rejected.

[0090] In an embodiment, the first response may be an authentication result confirmation response.

[0091] The units 410 and 420 can be implemented as a pure hardware solution or as a combination of software and hardware, e.g., by one or more of: a processor or a micro-processor and adequate software and memory for storing of the software, a Programmable Logic Device (PLD) or other electronic component(s) or processing circuitry configured to perform the actions described above, and illustrated, e.g., in Fig. 1 .

[0092] Correspondingly to the method 200 as described above, a UDM node is provided. Fig. 5 is a block diagram of a network node 500 according to an embodiment of the present disclosure. The network node 500 is configured to implement a UDM.

[0093] As shown in Fig. 5, the network node 500 includes a receiving unit 510 configured to receive, from an AUSF, a first request including a second ID associated with a terminal device, and an NSWO indicator. The network node 500 further includes a transmitting unit 520 configured to transmit, to the AUSF, a first response indicating subscription information corresponding to the second ID or indicating whether the second ID corresponds to a valid subscription or not.

[0094] In an embodiment, the first request may further include an authentication state of a terminal device, and the network node 500 may further include a unit configured to refrain, in response to the NSWO indicator, from storing the authentication state at the UDM.

[0095] In an embodiment, the second ID may be a SUPI. In an embodiment, the first request may be an authentication result confirmation request, and the first response may be an authentication result confirmation response.

[0096] In an embodiment, the receiving unit 510 may be further configured to, prior to receiving the first request, receive, from the AUSF, an authentication request including a first ID associated with the terminal device.

[0097] In an embodiment, the first ID may be an anonymous ID.

[0098] In an embodiment, the first ID may be an anonymous SUCI.

[0099] The units 510 and 520 can be implemented as a pure hardware solution or as a combination of software and hardware, e.g., by one or more of: a processor or a micro-processor and adequate software and memory for storing of the software, a Programmable Logic Device (PLD) or other electronic component(s) or processing circuitry configured to perform the actions described above, and illustrated, e.g., in Fig. 2.

[0100] Fig. 6 is a block diagram of a network node 600 according to an embodiment of the present disclosure.

[0101] The network node 600 includes a communication interface 610, a processor 620 and a memory 630.

[0102] The memory 630 may contain instructions executable by the processor 620 whereby the network node 600 is operative to, when implementing an AUSF, perform the actions, e.g., of the procedure described earlier in conjunction with Fig. 1. Particularly, the memory 630 may contain instructions executable by the processor 620 whereby the network node 600 is operative to, when implementing an AUSF: receive an authentication request including a first ID associated with a terminal device and a first NSWO indicator; and transmit, in response to a successful authentication of the terminal device or in response to receiving an indication of the successful authentication, a first request to a UDM. The first request includes a second ID associated with the terminal device, and a second NSWO indicator. In an embodiment, the first ID may be an anonymous ID.

[0103] In an embodiment, the first ID may be an anonymous SUCI.

[0104] In an embodiment, the second ID may be a SUPI.

[0105] In an embodiment, the authentication of the terminal device may be performed at the AUSF or an AAA server.

[0106] In an embodiment, the first request may be an authentication result confirmation request.

[0107] In an embodiment, the authentication of the terminal device may be performed based on SNPN credentials.

[0108] In an embodiment, the authentication of the terminal device may be performed using an EAP method that supports privacy at an EAP layer.

[0109] In an embodiment, the memory 630 may further contain instructions executable by the processor 620 whereby the network node 600 is operative to, when implementing the AUSF: receive, from the UDM, a first response indicating subscription information corresponding to the second ID, or indicating whether the second ID corresponds to a valid subscription or not.

[0110] In an embodiment, the memory 630 may further contain instructions executable by the processor 620 whereby the network node 600 is operative to, when implementing the AUSF: transmit, when the first response indicates the subscription information or indicates that the second ID corresponds to a valid subscription, an authentication response indicating a successful authentication, or transmit, when the first response indicates that the second ID does not correspond to a valid subscription, an authentication response indicating that the authentication request is rejected.

[0111] In an embodiment, the first response may be an authentication result confirmation response. Alternatively, the memory 630 may contain instructions executable by the processor 620 whereby the network node 600 is operative to, when implementing a UDM, perform the actions, e.g., of the procedure described earlier in conjunction with Fig. 2. Particularly, the memory 630 may contain instructions executable by the processor 620 whereby the network node 600 is operative to, when implementing a UDM: receive, from an AUSF, a first request including a second ID associated with a terminal device, and an NSWO indicator; and transmit, to the AUSF, a first response indicating subscription information corresponding to the second ID or indicating whether the second ID corresponds to a valid subscription or not.

[0112] In an embodiment, the first request may further include an authentication state of a terminal device, and the memory 630 may further contain instructions executable by the processor 620 whereby the network node 600 is operative to, when implementing the UDM: refrain, in response to the NSWO indicator, from storing the authentication state at the UDM.

[0113] In an embodiment, the second ID may be a SUPI.

[0114] In an embodiment, the first request may be an authentication result confirmation request, and the first response may be an authentication result confirmation response.

[0115] In an embodiment, the memory 630 may further contain instructions executable by the processor 620 whereby the network node 600 is operative to, when implementing the UDM: prior to receiving the first request, receive, from the AUSF, an authentication request including a first ID associated with the terminal device.

[0116] In an embodiment, the first ID may be an anonymous ID.

[0117] In an embodiment, the first ID may be an anonymous SUCI.

[0118] The present disclosure also provides at least one computer program product in the form of a non-volatile or volatile memory, e.g., a non-transitory computer readable storage medium, an Electrically Erasable Programmable Read-Only Memory (EEPROM), a flash memory and a hard drive. The computer program product includes a computer program. The computer program includes: code / computer readable instructions, which when executed by the processor 620 causes the network node 600 to perform the actions, e.g., of the procedure described earlier in conjunction with Fig. 1 or 2.

[0119] The computer program product may be configured as a computer program code structured in computer program modules. The computer program modules could essentially perform the actions of the flow illustrated in Fig. 1 or 2.

[0120] The processor may be a single CPU (Central Processing Unit), but could also comprise two or more processing units. For example, the processor may include general purpose microprocessors; instruction set processors and / or related chips sets and / or special purpose microprocessors such as Application Specific Integrated Circuits (ASICs). The processor may also comprise board memory for caching purposes. The computer program may be carried in a computer program product connected to the processor. The computer program product may comprise a non-transitory computer readable storage medium on which the computer program is stored. For example, the computer program product may be a flash memory, a Random Access Memory (RAM), a Read-Only Memory (ROM), or an EEPROM, and the computer program modules described above could in alternative embodiments be distributed on different computer program products in the form of memories.

[0121] With reference to Fig. 7, in accordance with an embodiment, a communication system includes a telecommunication network 710, such as a 3GPP-type cellular network, which comprises an access network 711 , such as a radio access network, and a core network 714. The access network 711 comprises a plurality of base stations 712a, 712b, 712c, such as NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 713a, 713b, 713c. Each base station 712a, 712b, 712c is connectable to the core network 714 over a wired or wireless connection 715. Afirst user equipment (UE) 771 located in coverage area 713c is configured to wirelessly connect to, or be paged by, the corresponding base station 712c. A second UE 772 in coverage area 713a is wirelessly connectable to the corresponding base station 712a. While a plurality of UEs 771 , 772 are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station 712.

[0122] The telecommunication network 710 is itself connected to a host computer 730, which may be embodied in the hardware and / or software of a standalone server, a cloud-implemented server, a distributed server or as processing resources in a server farm. The host computer 730 may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. The connections 721 , 722 between the telecommunication network 710 and the host computer 730 may extend directly from the core network 714 to the host computer 730 or may go via an optional intermediate network 720. The intermediate network 720 may be one of, or a combination of more than one of, a public, private or hosted network; the intermediate network 720, if any, may be a backbone network or the Internet; in particular, the intermediate network 720 may comprise two or more sub-networks (not shown).

[0123] The communication system of Fig. 7 as a whole enables connectivity between one of the connected UEs 771 , 772 and the host computer 730. The connectivity may be described as an over-the-top (OTT) connection 750. The host computer 730 and the connected UEs 771 , 772 are configured to communicate data and / or signaling via the OTT connection 750, using the access network 711 , the core network 714, any intermediate network 720 and possible further infrastructure (not shown) as intermediaries. The OTT connection 750 may be transparent in the sense that the participating communication devices through which the OTT connection 750 passes are unaware of routing of uplink and downlink communications. For example, a base station 712 may not or need not be informed about the past routing of an incoming downlink communication with data originating from a host computer 730 to be forwarded (e.g., handed over) to a connected UE 771. Similarly, the base station 712 need not be aware of the future routing of an outgoing uplink communication originating from the UE 771 towards the host computer 730.

[0124] Example implementations, in accordance with an embodiment, of the UE, base station and host computer discussed in the preceding paragraphs will now be described with reference to Fig. 8. In a communication system 800, a host computer 810 comprises hardware 815 including a communication interface 816 configured to set up and maintain a wired or wireless connection with an interface of a different communication device of the communication system 800. The host computer 810 further comprises processing circuitry 818, which may have storage and / or processing capabilities. In particular, the processing circuitry 818 may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The host computer 810 further comprises software 811 , which is stored in or accessible by the host computer 810 and executable by the processing circuitry 818. The software 811 includes a host application 812. The host application 812 may be operable to provide a service to a remote user, such as a UE 830 connecting via an OTT connection 850 terminating at the UE 830 and the host computer 810. In providing the service to the remote user, the host application 812 may provide user data which is transmitted using the OTT connection 850.

[0125] The communication system 800 further includes a base station 820 provided in a telecommunication system and comprising hardware 825 enabling it to communicate with the host computer 810 and with the UE 830. The hardware 825 may include a communication interface 826 for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system 800, as well as a radio interface 827 for setting up and maintaining at least a wireless connection 870 with a UE 830 located in a coverage area (not shown in Fig. 8) served by the base station 820. The communication interface 826 may be configured to facilitate a connection 860 to the host computer 810. The connection 860 may be direct or it may pass through a core network (not shown in Fig. 8) of the telecommunication system and / or through one or more intermediate networks outside the telecommunication system. In the embodiment shown, the hardware 825 of the base station 820 further includes processing circuitry 828, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The base station 820 further has software 821 stored internally or accessible via an external connection.

[0126] The communication system 800 further includes the UE 830 already referred to. Its hardware 835 may include a radio interface 837 configured to set up and maintain a wireless connection 870 with a base station serving a coverage area in which the UE 830 is currently located. The hardware 835 of the UE 830 further includes processing circuitry 838, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The UE 830 further comprises software 831 , which is stored in or accessible by the UE 830 and executable by the processing circuitry 838. The software 831 includes a client application 832. The client application 832 may be operable to provide a service to a human or non-human user via the UE 830, with the support of the host computer 810. In the host computer 810, an executing host application 812 may communicate with the executing client application 832 via the OTT connection 850 terminating at the UE 830 and the host computer 810. In providing the service to the user, the client application 832 may receive request data from the host application 812 and provide user data in response to the request data. The OTT connection 850 may transfer both the request data and the user data. The client application 832 may interact with the user to generate the user data that it provides.

[0127] It is noted that the host computer 810, base station 820 and UE 830 illustrated in Fig. 8 may be identical to the host computer 730, one of the base stations 712a, 712b, 712c and one of the UEs 771 , 772 of Fig. 7, respectively. This is to say, the inner workings of these entities may be as shown in Fig. 8 and independently, the surrounding network topology may be that of Fig. 7.

[0128] In Fig. 8, the OTT connection 850 has been drawn abstractly to illustrate the communication between the host computer 810 and the use equipment 830 via the base station 820, without explicit reference to any intermediary devices and the precise routing of messages via these devices. Network infrastructure may determine the routing, which it may be configured to hide from the UE 830 or from the service provider operating the host computer 810, or both. While the OTT connection 850 is active, the network infrastructure may further take decisions by which it dynamically changes the routing (e.g., on the basis of load balancing consideration or reconfiguration of the network).

[0129] The wireless connection 870 between the UE 830 and the base station 820 is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to the UE 830 using the OTT connection 850, in which the wireless connection 870 forms the last segment. More precisely, the teachings of these embodiments may improve the network security and thereby provide benefits such as improved user data rate.

[0130] A measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 850 between the host computer 810 and UE 830, in response to variations in the measurement results. The measurement procedure and / or the network functionality for reconfiguring the OTT connection 850 may be implemented in the software 811 of the host computer 810 or in the software 831 of the UE 830, or both. In embodiments, sensors (not shown) may be deployed in or in association with communication devices through which the OTT connection 850 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software 811, 831 may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 850 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not affect the base station 820, and it may be unknown or imperceptible to the base station 820. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling facilitating the host computer’s 810 measurements of throughput, propagation times, latency and the like. The measurements may be implemented in that the software 811 , 831 causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 850 while it monitors propagation times, errors etc.

[0131] Fig. 9 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Figs. 7 and 8. For simplicity of the present disclosure, only drawing references to Fig. 9 will be included in this section. In a first step 910 of the method, the host computer provides user data. In an optional substep 911 of the first step 910, the host computer provides the user data by executing a host application. In a second step 920, the host computer initiates a transmission carrying the user data to the UE. In an optional third step 930, the base station transmits to the UE the user data which was carried in the transmission that the host computer initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional fourth step 940, the UE executes a client application associated with the host application executed by the host computer.

[0132] Fig. 10 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Fig. 7 and 8. For simplicity of the present disclosure, only drawing references to Fig. 10 will be included in this section. In a first step 1010 of the method, the host computer provides user data. In an optional substep (not shown) the host computer provides the user data by executing a host application. In a second step 1020, the host computer initiates a transmission carrying the user data to the UE. The transmission may pass via the base station, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional third step 1030, the UE receives the user data carried in the transmission.

[0133] Fig. 11 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Figs. 7 and 8. For simplicity of the present disclosure, only drawing references to Fig. 11 will be included in this section. In an optional first step 1110 of the method, the UE receives input data provided by the host computer. Additionally or alternatively, in an optional second step 1120, the UE provides user data. In an optional substep 1121 of the second step 1120, the UE provides the user data by executing a client application. In a further optional substep 1111 of the first step 1110, the UE executes a client application which provides the user data in reaction to the received input data provided by the host computer. In providing the user data, the executed client application may further consider user input received from the user. Regardless of the specific manner in which the user data was provided, the UE initiates, in an optional third substep 1130, transmission of the user data to the host computer. In a fourth step 1140 of the method, the host computer receives the user data transmitted from the UE, in accordance with the teachings of the embodiments described throughout this disclosure.

[0134] Fig. 12 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Figs. 7 and 8. For simplicity of the present disclosure, only drawing references to Fig. 12 will be included in this section. In an optional first step 1210 of the method, in accordance with the teachings of the embodiments described throughout this disclosure, the base station receives user data from the UE. In an optional second step 1220, the base station initiates transmission of the received user data to the host computer. In a third step 1230, the host computer receives the user data carried in the transmission initiated by the base station. The disclosure has been described above with reference to embodiments thereof. It should be understood that various modifications, alternations and additions can be made by those skilled in the art without departing from the spirits and scope of the disclosure. Therefore, the scope of the disclosure is not limited to the above particular embodiments but only defined by the claims as attached.

[0135] The present disclosure further provides the following changes to TS 33.501 , V18.3.0.

[0136] 1.10.5.2 NSWO support in SNPN without CH

[0137] 5G NSWO procedures are defined in Annex S.3.2. For SNPN the procedures are extended to usage of any key-generating EAP-method as follows:

[0138] Steps 1-2 are performed as described in Annex S.3.2.

[0139] In step 3, the SUCI can be of type anonymous SUCI if the construction of SUCI as described in clause 6.12 cannot be used and if the employed EAP method supports SUPI privacy.

[0140] Steps 4-6 are performed as described in Annex S.3.2.

[0141] 7. Upon reception of the Nudm_UEAuthentication_Get Request, the UDM invokes SIDF to de-conceal SUCI to gain SUPI if the received SUCI is not an anonymous SUCI. For selection of authentication methods, the statements in Annex 1.2.2.1 apply. In case of SNPN, the UDM selects authentication method based on the NSWO indicator, subscription data and / or local configuration. The authentication method may include EAP-AKA or any other key-generating EAP authentication method. The UDM returns the selected authentication method to the AUSF.

[0142] 8—15. Authentication is performed between the AUSF and UE using the selected EAP method. After a successful authentication the AUSF derives the MSK key and does not generate the KAUSF, as indicated by the NSWO indicator and as described for the PLMN case in Annex S.3.2.

[0143] In case the SUCI received in step 5 was anonymous, the AUSF verifies that the authenticated SUPI corresponds to a valid subscription in the SNPN by informing the UDM about the authentication result for the authenticated SUPI using a Nudm UE Authentication Resultconfirmation service operation. The AUSF shall include an indicator in the

[0144] Nudm UEAuthentication Resultconfirmation to inform the UDM that the authentication was for NSWO (and not primary authentication). The UDM shall verify that the authenticated SUPI corresponds to a valid subscription.

[0145] The UDM shall not store the authentication state for the SUPI based on the indication that the authentication was not primary authentication but for NSWO.

[0146] If there is not a subscription corresponding to the SUPI, the UDM shall return an error.

[0147] If the verification of the SUPI / subscription is not successful, then the AUSF rejects the authentication request for NSWO. NOTE : If the above failure happens, the error is no failed authentication but lacking subscription in the SNPN.

Claims

CLAIMS1 . A method (100) in an Authentication Server Function, AUSF, comprising: receiving (110) an authentication request including a first Identifier, ID, associated with a terminal device and a first Non-Seamless Wireless Local Area Network ‘WLAN’ Offload, NSWO, indicator; and transmitting (120), in response to a successful authentication of the terminal device or in response to receiving an indication of the successful authentication, a first request to a Unified Data Management, UDM, the first request including a second ID associated with the terminal device, and a second NSWO indicator.

2. The method (100) of claim 1 , wherein the first ID is an anonymous ID.

3. The method (100) of claim 1 or 2, wherein the first ID is an anonymous Subscription Concealed Identifier, SUCI.

4. The method (100) of any of claims 1-3, wherein the second ID is a Subscription Permanent Identifier, SUPI.

5. The method (100) of any of claims 1 -4, wherein the authentication of the terminal device is performed at the AUSF or an Authentication, Authorization, and Accounting, AAA, server.

6. The method (100) of any of claims 1-5, wherein the first request is an authentication result confirmation request.

7. The method (100) of any of claims 1 -6, wherein the authentication of the terminal device is performed based on Standalone Non-Public Network, SNPN, credentials.

8. The method (100) of any of claims 1 -7, wherein the authentication of the terminal device is performed using an Extensible Authentication Protocol, EAP, method that supports privacy at an EAP layer.

9. The method (100) of any of claims 1 -8, further comprising:receiving, from the UDM, a first response indicating subscription information corresponding to the second ID, or indicating whether the second ID corresponds to a valid subscription or not.

10. The method (100) of claim 9, further comprising: transmitting, when the first response indicates the subscription information or indicates that the second ID corresponds to a valid subscription, an authentication response indicating a successful authentication, or transmitting, when the first response indicates that the second ID does not correspond to a valid subscription, an authentication response indicating that the authentication request is rejected.11 . The method (100) of claim 9 or 10, wherein the first response is an authentication result confirmation response.

12. A method (200) in a Unified Data Management, UDM, comprising: receiving (210), from an Authentication Server Function, AUSF, a first request including a second ID associated with a terminal device, and a Non-Seamless Wireless Local Area Network ‘WLAN’ Offload, NSWO, indicator; and transmitting (220), to the AUSF, a first response indicating subscription information corresponding to the second ID or indicating whether the second ID corresponds to a valid subscription or not.

13. The method (200) of claim 12, wherein the first request further includes an authentication state of a terminal device, and wherein the method (200) further comprises: refraining, in response to the NSWO indicator, from storing the authentication state at the UDM.

14. The method (200) of claim 12 or 13, wherein the second ID is a Subscription Permanent Identifier, SUPI.

15. The method (200) of any of claims 12-14, wherein the first request is an authentication result confirmation request, and the first response is an authentication result confirmation response.

16. The method (200) of any of claims 12-15, further comprising, prior to receiving (210) the first request: receiving, from the AUSF, an authentication request including a first ID associated with the terminal device.

17. The method (200) of claim 16, wherein the first ID is an anonymous ID.

18. The method (200) of claim 16 or 17, wherein the first ID is an anonymous Subscription Concealed Identifier, SUCI.

19. A network node (600), comprising a communication interface (610), a processor (620), and a memory (630), the memory (630) comprising instructions executable by the processor (620) whereby the network node (600) is operative to, when implementing an Authentication Server Function, AUSF, perform the method according to any of claims 1-11 , or when implementing a Unified Data Management, UDM, perform the method according to any of claims 12-18.

20. A computer-readable storage medium having computer-readable instructions stored thereon, the computer-readable instructions, when executed by a processor of a network node, configure the network node to, when implementing an Authentication Server Function, AUSF, perform the method according to any of claims 1-11 , or when implementing a Unified Data Management, UDM, perform the method according to any of claims 12-18.

21. A computer program product comprising a computer program which includes code / computer readable instructions, which when executed by the processor of a network node, configure the network node to, when implementing an Authentication Server Function, AUSF, perform the method according to any of claims 1-11 , or when implementing a Unified Data Management, UDM, perform the method according to any of claims 12-18.

Images