A method and system for managing a connection in cellular networks

Abstract

This invention describes apparatuses / methods for enhanced user authentication in cellular networks wherein the apparatus / method checks for a preferred authentication procedure, performs the preferred authentication procedure with a core network, and sets up a connection. Thereby, authentication challenges (such as retrieving core network data, optimizing resources and strength of authentication) arising from users of one or more devices (e.g., UEs) using multiple / different networks, (e.g., with multiple subscriber identity modules and / or different radio access technologies), avatar-based communication and / or biometrics (e.g., by means of embedded sensors or wireless sensing) can be addressed.

Description

[0001] A METHOD AND SYSTEM FOR MANAGING A CONNECTION IN CELLULAR NETWORKS

[0002] FIELD OF THE INVENTION

[0003] This invention relates to a method and system for managing a connection in cellular networks, in particular where the management of the connection involves enhanced user authentication in cellular networks. The invention can be implemented in (but is not limited to) cellular devices that want to set up a connection with cellular network.

[0004] BACKGROUND OF THE INVENTION

[0005] The 3GPP Technical Specification Group Service and System Aspects (TSG SA) is performing a Study on User Identities and Authentication Architecture in 3GPP TR 23.700-32. One of the goals is to enhance the 5G System to allow for the creation and utilization of user-specific identities, possibly in addition to or instead of device identities. In this way, mobile network operators will be able to provide enhanced user experience, optimized performance, adapt network settings and offer services according to users’ needs, different from the subscription identifier that is used by the user to establish the connection. One of the reasons for utilizing operator user-specific identities in the 3GPP network is to allow the operator to charge and provide service differentiation based on the user identifier. In the context of this work, the user to be identified could be an individual human user using a UE with a certain subscription, an application running on or connecting via a UE, or a device (e.g., a PINE) behind a gateway UE (e.g., a PEGC). Use cases are thoroughly discussed in TR 22.904 and include:

[0006] - One or more users (i.e., humans) sharing one UE, and

[0007] - One or more users (i.e., devices) behind one gateway UE

[0008] It is therefore desirable to offer a way to enhance existing methods, such as authentication methods, to handle the connection of one or more users in cellular networks.

[0009] SUMMARY OF THE INVENTION

[0010] It is an object of the present invention to enable improved / optimized connection establishment and / or authentication procedures for cellular networks using user identities instead or in addition to device identities.

[0011] This object is achieved by a method, a device, or a computer program product as defined in the appended claims. In accordance with a first aspect of the invention, it is proposed a method for connecting a device to a communication network using user-specific authentication, the method comprising: - performing a first authentication procedure using a device identity of the device for registering the device with the communication network;

[0012] - obtaining a user-specific identity of a user of the device, the user-specific identity being different from device identities of the device;

[0013] - performing a second authentication procedure using the obtained user-specific identity to enable data communication between the device and the communication network.

[0014] In accordance with a second aspect of the invention, it is proposed a device comprising: a transmitter; a receiver; a processor; and a storage unit storing instructions which, when executed, cause the device to obtain a user-specific identity of a user of the device, the user-specific identity being different from the device identity of the device; perform a first authentication procedure using a device identity of the device for registering the device with the communication network; perform a second authentication procedure using the obtained user-specific identity to enable data communication between the device and the communication network.

[0015] In accordance with a third aspect of the invention, it is proposed a computer program product comprising instructions for implementing the method of the first aspect when executed on a computer.

[0016] In a first variant, the method further comprises:

[0017] - collecting user authentication information, such as biometric information of a user, by the device or through other devices close or connected to or attached to the device or the user.

[0018] - the device securely sending the user authentication information to the communication network. In a second variant, the second authentication procedure is triggered and / or performed during a Protocol Data Unit, PDU, session establishment, and the PDU session is associated with one or more of: a slice; a Data Network Name, DNN; and a network service.

[0019] In a third variant, the method further comprises:

[0020] - determining the authorization rights to access a first network slice and / or DNN and / or network service related to the user specific identity; and

[0021] - enforcing the authorization rights when accessing the first network slice and / or DNN and / or network service.

[0022] In a fourth variant, the method further comprises: - determining a set X of network slice identifiers related to the user-specific identity, the set X being a subset of a set Y of network slice identifiers related to the device identity;

[0023] - preventing access to network slices with network slice identifiers not being part of the set X.

[0024] In a fifth variant, the method further comprises:

[0025] - determining a set X of DNNs related to a user-specific identity, the set X being a subset of a set of DNNs Y related to the device identity;

[0026] - preventing access to data networks with DNNs not being part of set X.

[0027] In a sixth variant, the method further comprises:

[0028] - determining a set X of network services related to a user-specific identity, the set X being a subset of a set of network services Y related to the device identity;

[0029] - preventing access to network services that are not part of subset X of Y.

[0030] In another variant, the method further comprises storing the set X in

[0031] - a SIM of the device and / or

[0032] - the subscription data of the device and / or

[0033] - a user profile of the respective user.

[0034] In another variant, the first authentication procedure uses credentials stored in a first SIM of the device, and / or the subscription data of the device, and the second authentication procedure uses credentials stored in a second SIM of the device, and / or a user profile of the respective user.

[0035] In another variant, the method further comprises:

[0036] - the device registering to the communication network and indicating its user authentication capabilities to the communication network,

[0037] - the device receiving a user authentication request from the communication network indicating that user-specific authentication is to be used, and wherein the device performing the second authentication procedure comprises:

[0038] - local user authentication, and sending the user authentication result as part of performing the user-specific authentication procedure with or through communication network, or

[0039] - securely sending the collected user authentication information to the communication network for remote user identification and authentication.

[0040] In another variant, the method further comprises:

[0041] - if the user of the device is not linked to the device’s subscription, the device receiving a message from the communication network, said message including one or more of the following:

[0042] - information as to which subscription is to be used as selected by the network, - a request to select which subscription to be used,

[0043] - a request to indicate whether or not the user approves to be linked to the device’s subscription,

[0044] - a request to indicate whether or not the user approves the device to be linked to the user’s subscription,

[0045] - a request to indicate whether or not the user approves updating the user’s user profile with information linking the user to the device;

[0046] - the device sending a response message to the network, said response message including one or more of the following:

[0047] - information about which subscription to use,

[0048] - information to confirm or deny whether the user approves to link the user to the device

[0049] In another variant, the method further comprises:

[0050] - the device performing the second authentication procedure during a PDU session establishment,

[0051] - the device collecting user authentication information, wherein the user authentication information comprises biometric information obtained by the device or by other user devices close or connected to or attached to the device or the user and, wherein the device performing the second authentication procedure comprises: locally checking the user authentication information to perform a local user identification authentication or securely sending the collected user authentication information to the communication network for remote user identification and authentication; and the device setting up a PDU session when the user authentication procedure succeeds.

[0052] In another variant, the method comprises the device performing continuous user-specific authentication at random instants of time, or periodically, wherein the periodicity depends on one or more of: authentication capabilities / procedures supported by the device and / or communication network; network configuration; user preferences, type of service requested, connectivity state of the user equipment, and the number of users associated with a user equipment or subscription.

[0053] In another variant, in case of a failed local user authentication procedure, the device: logs the failed authentication event, and / or sends an authentication error message to the network indicating the failure cause, and / or performs, based on a policy or configuration, one of the following: user authentication using an alternative authentication method using:

[0054] • an alternative local user authentication method, or

[0055] • alternative credentials associated with the user, and / or, establish a different type of PDU session, said different type of PDU session not requiring user identification.

[0056] It shall be understood that a preferred embodiment of the invention can also be any combination of the dependent claims or above embodiments with the respective independent claim.

[0057] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter.

[0058] BRIEF DESCRIPTION OF THE DRAWINGS

[0059] In the following drawings:

[0060] Fig. 1 schematically shows a block diagram of a cellular network involving multiple user equipment devices;

[0061] Fig. 2 schematically shows a procedure of an enhanced primary authentication procedure involving multiple user equipment devices;

[0062] Fig. 3 schematically shows another procedure of an enhanced authentication procedure involving multiple user equipment devices;

[0063] Fig. 4 schematically shows waveforms relating to a similarity check between the measurements of two user equipment devices;

[0064] Fig. 5 schematically shows a procedure of an enhanced authentication procedure Fig. 6 is a communication exchange for user identification and authentication;

[0065] Fig. 7 is a communication exchange for user identification and authentication; and

[0066] Fig. 8 schematically describes a cellular system.

[0067] DETAILED DESCRIPTION OF EMBODIMENTS

[0068] Embodiments of the present invention are now described based on a cellular communication network environment, such as 5G. However, the present invention may also be used in connection with other wireless technologies in which authentication and differentation based on user identities can be introduced. The present invention may also be applicable to other applications such as video streaming services, video broadcasting services, or data storage.

[0069] Throughout the present disclosure, the abbreviation “gNB” (5G terminology) or “BS” (base station) is intended to mean a wireless access device such as a cellular base station or a Wi-Fi access point or a ultrawide band (UWB) personal area network (PAN) coordinator. The gNB may consist of a centralized control plane unit (gNB-CU-CP), multiple centralized user plane units (gNB- CU-UPs) and / or multiple distributed units (gNB-DUs). The gNB is part of a radio access network (RAN), which provides an interface to functions in the core network (CN). The RAN is part of a wireless communication network. It implements radio access technology (RAT). Conceptually, it resides between a communication device such as a mobile phone, a computer, or any remotely controlled machine and provides connection with its CN. The CN is the communication network’s core part, which offers numerous services to customers who are interconnected via the RAN. More specifically, it directs communication streams over the communication network and possibly other networks.

[0070] Furthermore, the terms “base station” (BS) and “network” may be used as synonyms in this disclosure. This means for example that when it is written that the “network” performs a certain operation it may be performed by a CN function of a wireless communication network, or by one or more base stations that are part of such a wireless communication network, and vice versa. It can also mean that part of the functionality is performed by a CN function of the wireless communication network and part of the functionality by the base station.

[0071] Additionally, the term “data” is understood as referring to a representation according to a known or agreed format of information to be stored, transferred or otherwise processed. The information may particularly comprise one or more channels of audio, video, image, haptic, motion or other form of multimedia information that may be synchronized. Such multimedia information may be derived from sensors (e.g., microphones, cameras, motion detectors, etc.) or may be partially or wholly synthesized (e.g., live actor in front of a synthetic background).

[0072] It is noted that throughout the present disclosure only those blocks, components and / or devices that are relevant for the proposed embodiments are shown in the accompanying drawings. Other blocks have been omitted for reasons of brevity. Furthermore, blocks designated by the same reference numbers are intended to have the same or at least a similar function, so that their function is not described again later.

[0073] A cellular system is a wireless communication system that consists of three main components: user equipment (UE), radio access network (RAN), and core network (CN). These components work together to provide voice and data services to mobile users over a large geographic area.

[0074] User equipment (UE) is the device that a user uses to access the cellular system, such as a smartphone, a tablet, a laptop, loT device, or a wearable device. A UE typically may contain the following components:

[0075] - A universal integrated circuit card (UICC), which stores the identification and authentication information, such as the subscription permanent identifier (SUPI) or credentials.

[0076] - A transceiver, which converts the digital signals from the processor into analog signals for transmission and reception over the air interface. The transceiver also performs modulation, demodulation, coding, decoding, and other signal processing functions.

[0077] - A processor, which controls the operation of the UE and executes the applications and services that the user requests. The processor also communicates with the RAN and the CN using various protocols.

[0078] - A display, which shows the user the information and feedback from the UE, such as the signal strength, the battery level, the call status, the messages, the contacts, the menu, etc.

[0079] - A microphone and a speaker, which enable the user to make and receive voice calls, as well as use other audio features, such as voice mail, voice recognition, etc.

[0080] - A keyboard and / or a touch screen, which allow the user to enter and select commands, text, numbers, etc.

[0081] - A camera and / or a video recorder, which enable the user to capture and send images and videos, as well as use other multimedia features, such as video calling, video streaming, etc.

[0082] - A memory, which stores the data and programs that the user needs, such as the phone book, the messages, the photos, the videos, the applications, etc.

[0083] - A battery, which provides the power supply for the UE.

[0084] A UE access the cellular network via the radio access network, as described below. Certain UEs may communicate with each other by using device-to-device communication, also known as sidelink communication using the PC5 interface that may rely on physical sidelink (PS) broadcast channel, PS shared channel, PS control, etc.

[0085] A UE may receive a configuration by means of different procedures:

[0086] Downlink control information (DCI) is a type of control information that is sent from the BS to the UE on the physical downlink control channel (PDCCH). DCI contains various parameters that instruct the UE how / when to decode and transmit data on the physical downlink shared channel (PDSCH) and the physical uplink shared channel (PUSCH), such as the resource allocation, the modulation and coding scheme. The UE needs to monitor the PDCCH in each subframe to detect and decode the DCI that is addressed to it.

[0087] Uplink control information (UCI) is a type of control information that is sent from the UE to the BS on the physical uplink control channel (PUCCH) or the physical uplink shared channel (PUSCH). UCI contains various feedback signals that inform the BS about the status and quality of the downlink transmission, such as the HARQ acknowledgments (ACKs), the channel state information (CSI), and the scheduling requests (SRs). The UE needs to encode and transmit the UCI according to the configuration and timing indicated by the BS.

[0088] Sidelink control information (SCI) is a type of control information that is sent from the UE to another UE on the physical sidelink control channel (PSCCH) in device-to-device (D2D) communication scenarios. The main functions of SCI include resource allocation, synchronization, channel quality reporting, .

[0089] Medium access control (MAC) control element (MAC CE) is a type of control information that is sent from the BS to the UE or vice versa on the MAC layer. MAC CE contains various commands or indications that regulate the MAC layer functions, such as the buffer status report (BSR), the timing advance command (TAC), the discontinuous reception (DRX) command, etc. The UE needs to process the MAC CE according to the MAC protocol and the configuration provided by the BS.

[0090] Radio resource control (RRC) command is a type of control information that is exchanged between the BS and the UE on the RRC layer. RRC Command contains various messages that modify / configure RRC parameters and / or initiate, modify, or release the RRC connection or the radio bearers between the UE and the BS, such as the RRC connection setup, the RRC connection reconfiguration, the RRC connection release, the security mode command, the mobility from E-UTRA command, the handover from E-UTRA preparation request, etc. The UE needs to respond to the RRC Command according to the RRC protocol and the configuration provided by the BS.

[0091] Non-access stratum (NAS) messages are used for signalling between UE and core network (CN) on the non-access stratum (NAS) layer. NAS messages enable functionality such as registration, session establishment, security, and mobility management. The UE needs to respond to the NAS Command according to the NAS protocol and the configuration provided by the CN.

[0092] UE parameter update (UPU) is a procedure between the UE and the home network that enables the home network to update configuration parameters in mobile phones and / or USIM using tthe UDM control plane procedure (TS 23.502). The UE can receive Parameters Update Data from the UDM after the UE has registered in the 5G network.

[0093] Steering of Roaming (SoR) enables the home network to guide the user equipment (UE) when registering on a visited network. For detailed information about the interfaces and registration in the 5G System, refer to 3GPP TS.23.501 (Release 15)

[0017] and 3GPP TS 24.501 (Release 15)

[0018] , The 5G CP-SOR is activated during or after registration to update the UE's "Operator Controlled PLMN Selector with Access Technology" list via secure NAS messages, as directed by the home PLMN based on specific operator policies, such as preferred networks or UE location.

[0094] UE configuration update (UCU) is used to update configuration parameters as per TS 23.502 that may include Access and Mobility Management related parameters decided and provided by the AMF, UE Policy provided by the PCF. When AMF wants to change the UE configuration for access and mobility management related parameters the AMF initiates the procedure defined in clause 4.2.4.2. When the PCF wants to change or provide new UE Policies in the UE, the PCF initiates the procedure defined in clause 4.2.4.3. If the UE Configuration Update procedure requires the UE to initiate a Registration procedure, the AMF indicates this to the UE explicitly. The procedure in clause 4.2.4.2 may be triggered also when the AAA Server that performed Network Slice-Specific Authentication and Authorization for an S-NSSAI revokes the authorization.

[0095] Radio access network (RAN) is the part of the cellular system that connects the UEs to the CN via the air interface. The RAN consists of base stations (BSs). A base station (BS) is a fixed or mobile transceiver that covers a certain geographic area, called a cell. In 5G, a BS is also called a gNB (next generation node B). A BS can serve multiple UEs simultaneously within its cell, by using different frequencies, time slots, codes, or beams. A BS also performs functions such as power control, handover control, channel allocation, interference management, etc. A base station can be divided into two units: a central unit (CU) and a distributed unit (DU). The CU performs the higher layer functions, such as RLC, PDCP, RRC, etc. The DU performs the lower layer functions, such as PHY and MAC. The CU and the DU can be co-located or separated, depending on the network architecture and deployment. In cellular systems, a base station may be denoted, based on context, as a cell, or gNB.

[0096] The cell may also refer to the coverage area of a base station. A BS may have different coverage areas such as a macro cell (e.g. several kilometres wide), a pico cell (e.g., for a given location such as a stadium) or a femto cell for a small location (e.g., a home or part of it).

[0097] A base station may communicate with the core network. Since there can be base stations for different cellular systems, different interfaces are required. For instance, a base station, eNB, in a 4G Long Term Evolution (LTE) system (also known as Evolved Universal Mobile Telecommunications Systems (UMTS) Terrestrial Radio Access Network (E-UTRAN)) may interface with the 4G CN known as EPC through the corresponding interface. For instance, a base station, gNB, in a 5G system (i.e., 5G New Radio or Next Generation RAN) may communicate with the 5GC through a different interface. 4G and 5G base stations may communicate with each other directly or through their corresponding core networks.

[0098] The main protocols used between the UEs and the RAN are:

[0099] - The physical layer (PHY), which defines the characteristics of the air interface, such as the frequency bands, the modulation schemes, the coding rates, the frame structure, the synchronization, etc.

[0100] - The medium access control (MAC) layer, which regulates the access of the UEs to the shared radio channel, by using techniques such as orthogonal frequency division multiple access (OFDMA), time division duplex (TDD), frequency division duplex (FDD), etc.

[0101] - The radio link control (RLC) layer, which provides reliable data transmission over the radio channel, by using techniques such as segmentation, reassembly, error detection, error correction, retransmission, etc.

[0102] - The packet data convergence protocol (PDCP) layer, which compresses and decompresses the headers of the data packets, encrypts and decrypts the data, and performs data integrity protection.

[0103] - The radio resource control (RRC) layer, which establishes, maintains, and releases the radio bearers between the UEs and the RAN, as well as exchanges the signaling messages for functions such as connection setup, handover, measurement reporting, security activation, etc.

[0104] A transmission / reception communication unit or transceiver may be used by BS and UE to transmit / receive data. Control data may be required for a physical broadcast channel, physical downlink control channel, etc. Data may be for the physical downlink shared channel.

[0105] Data may be encoded by the UE and / or BS to obtain data symbols and / or control symbols that may be exchanged over the wireless interface. The conversion from digital data into analog symbols may be done by the transmission / reception communication unit

[0106] A medium access control control-element (MAC-CE) is a MAC layer communication element that is used to control the communication between wireless devices. A MAC-CE may be exchanged in a shared channel, e.g., the physical downlink / uplink / sidelink shared channel.

[0107] The communication between a UE and a base station or the communication between UEs (when side link is used) may involve the exchange of reference signals. Reference signals may include primary synchronization signal (PSS), a secondary synchronization signal (SSS), a physical broadcast channel demodulation reference signal (DMRS), a channel state information reference signal (CSI-RS). Core network (CN) is the part of the cellular system that connects the RAN to other networks, such as the Internet, or other cellular systems. The CN consists of two main (control / user) domains. The control domain is responsible for providing signalling and control functions for the UEs, such as authentication, authorization, mobility management, session management, etc. The control plane consists of several network functions (NFs), such as the access and mobility management function (AMF), the session management function (SMF), the unified data management (UDM), the policy control function (PCF), the network exposure function (NEF), and the authentication server function (AUSF). The access and mobility management function (AMF) is a NF that handles the registration, deregistration, connection management, and mobility management for the UEs. The session management function (SMF) is a NF that handles the establishment, modification, and release of the sessions for the UEs. The SMF also communicates with the user plane devices to perform functions such as IP address allocation, tunneling, QoS, etc. The unified data management (UDM) is a NF that stores and manages the user data, such as the SUPI, the service profile, the subscription status, etc. The policy control function (PCF) is a NF that provides the policy rules and charging information for the UEs, such as the access type, the service level, the data rate, the quota, etc. The network exposure function (NEF) is a NF that exposes the network capabilities and services to external applications and devices, such as the IMS, the Internet of Things (loT), etc. The authentication server function (AUSF) is a NF that performs the primary authentication with the by using credentials and the SUPI. The user domain is responsible for providing data and multimedia services to the UEs, by using packets and IP addresses. The user plane consists of two main functions: the user plane function (UPF) and the data network (DN). The user plane function (UPF) is a device that forwards the data packets between the UEs and the DNs, as well as performs functions such as tunneling, firewall, QoS, charging, etc. The data network (DN) is a network that provides access to the services and applications that the UEs request, such as the Internet, the IMS, etc.

[0108] A residential gateway (RG) is a device that connects a home network to an external network, such as the Internet or a cellular system. An RG typically provides functions such as routing, switching, firewall, NAT, DHCP, DNS, VPN, etc. An RG can also support various types of interfaces, such as Ethernet, Wi-Fi, Bluetooth, USB, etc. A cellular-capable RG is an RG that has a cellular interface, such as a UICC slot, a cellular modem, or an antenna, that enables it to access the cellular system as a backup or an alternative to the wired or wireless broadband connection. A cellular-capable RG can provide benefits such as: (1) Enhanced reliability, by switching to the cellular connection in case of a failure or a degradation of the broadband connection; (2) Increased bandwidth, by aggregating the cellular connection and the broadband connection to achieve higher data rates or QoS.

[0109] A multi-SIM subscription is a subscription that allows a user to have multiple SIMs (or eSIMs) that are linked to the same account and service profile. A user can use the multi-SIM subscription to access the cellular system from different devices, such as a smartphone, a tablet, a laptop, or a wearable device, without having to switch the SIM card or the device.

[0110] In reference to Fig. 8, devices 100, 102, and 128 can play the role of UEs. Device 102 is part of a cellular-capable RG providing connectivity to a home network 129 e.g., by means of a local area network and / or wireless local area network. Device 102 is served by base station 104.

[0111] The RAN 127 comprises base station 103 and serves UE 128. UE 128 may also be a UE to Network relay given access to remote UE 136 that is out of coverage of base station 103. UEs 134 and 136 also communicate with each other via a UE-to-UE relay 135. Within the RAN, the range of base station 103 is extended via smart repeater 137 and reflective intelligent surface (RIS) 138. Smart repeater 137 and RIS 138 give access to UE 142.

[0112] The RAN 143 includes base station 104 that serves as wireless access infrastructure for the home network. Base station 104 also serves a mobile access device and / or UE as a UAV 139. UAV 139 may provide connectivity to remote UE 136.

[0113] Furthermore, a satellite gateway 141 is shown that connects to satellite 140 and may provide connectivity services to remote UE 136 or UE 100.

[0114] In Fig. 8, the 5G core network 133 may include one or more an AMF 121, SMF 123, UPF 122, AUSF 124, UDM 125, PCF 131, NEF 132 and allows the connection to a data network 130.

[0115] In Fig. 8, a second core network 142, e.g., a legacy core network as a 4G core network, is also shown that may interface with the 5G core network 133, interface with base stations denoted eNB in 4G, and provide a connection to the data network 130. The legacy 4G core network is denoted EPC and may include one or more mobility management entities (MME), a serving gateway, a multimedia broadcast multicast service gateway, a broadcast multicast service center, a packet data network gateway, etc. The mobility management entity may handle the signalling between UE and the 4G CN and may interact with the home subscriber server (HSS) in charge of the storage and management of subscriber data and secrets. The MME may provide connection management, similar to the AMF in 5G. The serving gateway may be used to exchange user internet protocol messages whereby the serving gateway may interact with the packet data network gateway that is connected to IP services. Multiple protocols in 4G and 5G have similar features. For example, the 5G network registration and 4G attach registration message are initially sent by the UE to establish a connection between the UE and the CN, which involves sending an initial request from the UE with its identity and capabilities, receiving an authentication request from the CN with a challenge, sending an authentication response from the UE with a response, receiving an authentication result from the CN with an indication of success or failure, and sending a security mode command from the CN with the selected security algorithms. As a result of this connection establishment procedure, NAS and AS keys are derived from the K_AMF (5G) and K_ASME (4G) where K_AMF is managed by the AMF and K_ASME is managed by the MME.

[0116] A UE may connect to a serving network or serving Public Land Mobile Network (PLMN). A UE may have a subscription with a home PLMN, and during the registration procedure, the (AMF of the) serving PLMN may forward the registration request to the (AUSF of the) home PLMN that may perform an initial authentication procedure between home PLMN and UE. If the authentication procedure is successful, keys are derived and the home PLMN may share derived credentials with the serving PLMN, including K_SEAF, that may be used to derive K_AMF, from which NAS keys and AS keys are derived. The registration request sent by the UE includes an identifier that can be used by the home PLMN to identify the UE. To prevent privacy vulnerabilities, the long-term subscriber’s identifier known as Subscriber Permanent Identifier (SUPI) may not be exchanged in the clear, but instead, either a Subscription Concealed Identifier (SUCI) or a pseudonym known as GUTI are exchanged with the AMF of the serving PLMN. The AMF of the PLMN may then forward the SUCI to the home PLMN so that the home PLMN decrypts / verifies it.

[0117] The following embodiment is directed to enhanced user and / or device authentication in cellular networks. It is noted that this embodiment can be combined with the other embodiments.

[0118] Fig. 1 schematically shows a block diagram of a cellular network involving multiple user equipment devices. The network architecture of Fig. 1 comprises a first user equipment (UE1) 100, in which a first SIM 101 and optionally a second (or zero, one or more than two) SIMs 102 are installed. Additionally, a second user equipment (UE2) 103 is provided, in which first SIM 104 and optionally a second (or zero, one or more than two) SIMs 105 are installed.

[0119] The first and second UEs 100, 103 may comprise respective sensors 126, 127 that may be used for biometric-enhanced authentication / authorization (e.g. fingerprint sensor to obtain biometric information related to fingerprint).

[0120] A communication interface 120 may be configured to allow direct communication between the first and second UEs 100, 103, e.g., a PC5 interface in 5G.

[0121] Furthermore, the network architecture comprises a radio access network (RAN) 106 which may comprise one or more access devices (e.g., gNBs) 107, 108 of a cellular network, wherein a first access device 107 may be configured to serve the first SIM 101 of the first UE 100 (or the first SIM 104 of the second UE 103) and the second access device 108 may be configured to serve the second SIM 102 of the first UE 100 (or the second SIM 105 of the second UE 103). Standard communication interfaces 121, 122 (e.g., Uu interfaces in 5G) are provided between the RAN 106 and the first and second UEs 100, 103.

[0122] Additionally, a first core network 109 of the cellular network may comprise network functions 110 to 113, e.g., an access and mobility management function (AMF), an authentication server function (AUSF), a unified data repository (UDR), an AKMA anchor function AAnF, a network exposure function (NEF), a location management function (LMF), and the like.

[0123] Moreover, a second core network 114 of the cellular network may be provided, which may comprise network functions 115 to 118, e.g., an access and mobility management function (AMF), an authentication server function (AUSF), a unified data repository (UDR), an AKMA anchor function (AAnF), a network exposure function (NEF), a location management function (LMF), and the like.

[0124] Further, an application function (AF) 119 may be provided, which is a function that provides application services to subscribers, e.g., for video streaming service. If the AF 119 is trusted, it can interact directly with above core network functions or if it is a third party, then it could interact with an NEF.

[0125] In addition, the network architecture of Fig. 1 may comprise a different type of device 123 (e.g., an unmanned aerial vehicle (UAV) such as a satellite) that is configured to provide connectivity to one or more UEs, e.g., the first UE 100 and / or the second UE 103. The different type of device 123 may be configured to use a different type of RAT, wherein a first communication interface 124 may be provided between the RAN 106 or a local gateway towards the different type of device 123. Furthermore, a second communication interface 125 may be provided between the different type of device 123 and the first UE 100. In an option, both first and second UEs 100 and 103 may be present, wherein the first UE

[0126] 100 includes its first SIM 101 and the second UE 103 includes its first SIM 104, and both SIMs 101, 104 are associated to the same or different networks.

[0127] Additionally or alternatively, in another option the first UE 100 comprises both SIMs

[0128] 101 and 102.

[0129] The SIMs 101, 102, 104, 105 may be physical SIMs or eSIMs that may be installed in an embedded universal smart circuit card (USCC). An eSIM is an industry-standard digital SIM that allows to activate a mobile plan from a network provider without having to use a physical SIM. Given the above system architecture of Fig. 1, different embodiments are proposed to improve authentication and authorization procedures in cellular networks for different scenarios.

[0130] Optimized primary authentication over multiple networks and / or for multiple UEs

[0131] In a scenario that relates to optimized primary authentication over multiple networks and / or for multiple UEs, a UE may have zero, one or multiple SIMs and it is desired to optimize the network access / primary authentication procedure. In a further scenario, it is further desired to optimize network access / primary authentication based on two or more UEs (where zero, one, two or more SIMs are installed in the UEs).

[0132] Network access is a process that allows a UE to connect to the radio access network (RAN) and core network. Primary authentication / network access is a process that allows a UE to register / connect to the network, establish a security context, and authenticate. Such a primary authentication process is, e.g., described in 3GPP specification TS 33.501.

[0133] The first and second UEs 100, 103 that may use SIMs 101 and 104, respectively, may perform a step of connecting to the RAN 106 (network access). The first and second UEs 100, 103 may then require to receive a Master Information Block (MIB) and / or a System Information Block (SIB) as broadcasted by the RAN 106 and perform a random access procedure (e.g., a sequence of processes between the UEs 100, 103 and one of the access devices (e.g., gNBs) 107, 108 of the RAN 106 to acquire uplink synchronization and obtain a specific ID for radio access communications). The MIB carries information about reference subcarrier spacing, control channel for SIB PDSCH, DMRS position etc. and the SIB carries basic information for the UEs to perform the initial attachment procedure at least up to the RRC setup. Furthermore, the SIB may also carry scheduling information for other SIBs. Further details may be gathered from 3GPP 38.331 (5.2 System information).

[0134] The first and second UEs 100, 103 may however not be aware in an initial step that they are bound together, and thus, in an initial process, the first and second UEs 100, 103 may both perform the network access / primary authentication procedure independently of each other. The first and second UEs 100, 103 may connect to the same core network (e.g., the first core network 109). In this case, the core network may store configuration information stating that both UEs 100, 103 are bound to each other, e.g., in the UDM / UDR, PCF, or in any other network function in charge of keeping track of subscriptions / policies. Examples of devices that may be bound together are phone and smartwatch, phone and tracker, phone and smartwatch and AR / VR glasses, etc. This configuration information may have been or be stored as a part of the user subscription. The storage of this configuration information may be triggered by an AF (e.g., the AF 119). This configuration information may be inferred by the network through the authentication response of at least one of the UEs (e.g., the first UE 100 and / or the second UE 103), which could indicate that they are paired. Upon successful primary authentication, the core network (e.g., first core network 109) may then store the configuration information in the UEs, e.g., in their SIMs, indicating that they are bounded / coupled. This configuration information may indicate that subsequent network access and / or network registration and / or primary authentication procedures can be performed in a combined manner, if possible.

[0135] In an example, the first and second UEs 100, 103 may disconnect and reattempt connecting to the RAN 106. In this case, the first and second UEs 100, 103 may store the configuration information, and thus, before attempting to perform the network access / primary authentication independently of each other, the first and second UEs 100, 103 may search each other, and if found, they may choose one of them as master / coordinator in charge of coordinating (e.g., (dis)aggregating) the network access / primary authentication messages for the disconnecting or connecting procedure.

[0136] In a further example, the choice of the master / coordinator may have been done in an initial step by the core network (e.g., first core network 109) and stored in the first and second UEs 100, 103.

[0137] In a further example, the first and second UEs 100, 103 may discover each other over a local communication interface such as the PC5 interface, e.g., the master / coordinator (e.g., the first UE 100) may broadcast its presence, e.g., by means of discovery messages similar to, e.g., Step 1 in Clause 6.3.3.3.2 in TS 33.503. In a following step, the other UE (e.g., the second UE 103) may reply with its initial network access message, e.g., encapsulated / transported in a direct communication request (DCR) message. The following steps may be such that the master / coordinator (first UE 100) combines the initial network access message received from the second UE 103 and its own network access message in a combined network access message for both UEs (first UE 100 and second UE 103).

[0138] In a further example, the second UE 103 may not be a user equipment or may not have a SIM, but it may just be a device (e.g., smart watch or the like) bound to the first UE 100. The presence of the second UE 103 or measurements by the second UE 103 may be used to improve the authentication procedure of the first UE 100 (and the second UE 103). For example, the second UE 103 may perform measurements of the radio environment and send them to the first UE 100, which may use them to adjust its transmit power and / or select a suitable carrier frequency. Alternatively, the second UE 103 may send a signal to the first UE 100 to indicate that it is in proximity and that the first UE 100 can initiate the network access / primary authentication procedure. The first UE 100 may then use the identity of the second UE 103 or a derived value as part of its network access message, e.g., as a device group identifier. The core network (e.g., first core network) 109 may verify the binding between the first UE 100 and the second UE 103 based on the received information and may grant or deny the network access / primary authentication for the first UE 100 accordingly.

[0139] In a further example, the network access / primary authentication of the bound first and second UEs 100, 103 may only be successful if the / all individual primary authentication(s) succeed.

[0140] In another example, the first UE 100 may have the two SIMs 101 and 102 available and may perform a combined network access / primary authentication procedure.

[0141] Fig. 2 schematically shows a procedure of an enhanced primary authentication procedure involving multiple user equipment devices. The system entities involved in Fig. 2 are those described in connection with Fig. 1 and the following messages may be used, wherein not all steps may always be required and / or some steps may be performed in a different order or more than once.

[0142] The diagram of Fig. 2 indicates the involved network entities (i.e., the second UE 103, the first UE 100, the RAN 106 and the first core network 109) at the top, wherein the arrows below indicate successive message flows in time-dependent order with time passing from the top to the bottom of Fig. 2.

[0143] In step 200, the RAN 106 distributes synchronization signals, e.g., MIB / SIB, which are received by the first UE 100 and / or the second UE 103.

[0144] In step 201, the first UE 100 distributes communication beacons (e.g., PC5 synchronization signals) that are received by the second UE 103 to establish a communication link (e.g., 3GPP based, Wi-Fi based, Bluetooth based, etc).

[0145] In step 202, the first UE 100 performs a random -access procedure with the RAN 106.

[0146] In step 203, the first and second UEs 100, 103 discover each other over the communication interface (e.g., PC5 discovery).

[0147] In step 204, the second UE 103 provides information for network access to the first UE 100 over the communication interface, e.g., PC5 interface, e.g., in a direct communication request. In particular, this may include contents of the 5G Registration Request (e.g., RRCSetupComplete message) including Registration Type, 5G-Guti, Last TAI, Requested NSSAI, UE capabilities, List of PDU sessions). This may include the contents for a registration request of a more resource-constraint device such as an (ambient) loT device.

[0148] In step 205, the first UE 100 sends a similar network access request including its own information and the information received from the second UE 103 in previous step 203. In step 206, the RAN 106 sends a message towards the first core network 109 for the registration request and / or authentication request etc.

[0149] In step 207, the first core network 109 replies to the registration request of the RAN 106 with (an) aggregated authentication request(s).

[0150] In step 208, the aggregated NAS authentication request(s) (e.g., an NAS Authentication Request) including the information of the NAS authentication request messages for both first UE 100 and second UE 103 are forwarded by the RAN 106 to the first UE 100.

[0151] In step 209, that the first UE 100 sends the contents of the NAS authentication request to the second UE 103 e.g. over the PC5 interface. Note that the first UE 100 may not just forward in step 208 but may first extract its own part of the NAS authentication request and may then only forward the part of the NAS authentication request addressed to the second UE 103.

[0152] In step 210, that the second UE 103 extracts and checks sequence number (SQN) and message authentication code (MAC); if successful, the second UE 103 computes RES*2 and sends the content of the NAS authentication response, i.e., RES*2 to the first UE 100 over the PC5 interface.

[0153] In step 211, the first UE 100 aggregates the authentication responses (own information and data from the second UE 103 as received in step 210) and sends the content of the aggregated NAS authentication response (RES* and RES *2) to the RAN 106.

[0154] In step 212, the RAN 106 forwards the message received in step 211 to the first core network 109 so that the first core network 109 can check the UE’s NAS authentication responses and authenticate both first and second UEs 100, 103.

[0155] In step 213, the first core network 109 confirms to the RAN 106 that the authentication procedure for the first and second UEs 100, 103 was successful. If so, the RAN 106 can allocate at this state RAN identifiers associated to the first and second UEs 100, 103 and can derive the AS security context.

[0156] An advantage of the message flow described in Fig. 2 is that it reduces the signaling required by the RAN 106, e.g., to perform the random -access procedure, as well as, the number of interactions with the first core network 109 when performing the initial authentication of devices.

[0157] The procedure described in Fig. 2 performs the primary authentication of the first UE 100 and the second UE 103 independently of each other. This means that even if the primary authentication of the second UE 103 fails, the primary authentication of the first UE 100 may still succeed and the first UE 100 may successfully connect to the network. However, in such a case, the device (first UE, second UE or a device combining both the first and second UE) may only get access to a subset of services and / or applications and / or a reduced QoS.

[0158] Fig. 5 schematically shows a procedure of an enhanced authentication procedure.

[0159] The exemplary procedure of Fig. 5 for a combined authentication for multiple UEs may be useful to reduce overhead and / or in cases in which all involved UEs need to be present to be accepted in the network. Similar to Fig. 2, the involved system entities are those described in Fig. 1 and the following messages are used, wherein not all steps may be required and / or some steps may be performed more than once and / or in a different order. The diagram of Fig. 5 indicates the involved network entities (i.e., the second UE 103, the first UE 100, the RAN 106 and the first core network 109) at the top, wherein the arrows below indicate successive message flows in time-dependent order with time passing from the top to the bottom of Fig. 5.

[0160] In step 600, UEs (e.g., the first UE 100 and the second UE 103) establish or have already established a (secure) communication link (e.g., PC5 link).

[0161] In another step 601, the RAN 106 broadcasts synchronization signals, comprising e.g., MIB / SIB, which are received by the first UE 100 and optionally the second UE 103.

[0162] In another step 602, that the first UE 100 performs a random -access procedure with the RAN 106, taking into account the other UEs (e.g., the second UE 103) which require RAN identifiers (e.g., a cell radio network temporary identifier (such as C-RNTI)) or network access. In other words, this random-access procedure may indicate that it is a combined random-access procedure for more than a single UE.

[0163] In another step 603, the first UE 100 may assign identifiers, e.g, temporary identifiers, to the other UEs (e.g., the second UE 103), and may request information required for the registration request (e.g., SUCI derived from SUPI, a globally unique temporary identifier (such as 5G-GUTI), security capabilities, registration type, etc). Such temporary identifiers may be used as a mapping for information that is forwarded between the second UE 103 and the first CN 109 or the AF 119. Alternatively, these temporary identifiers may be based on an identifier for the second UE 103, e.g., a layer 2 identity (L2 ID). The request from the first UE 100 to the second UE 103 may include information related to the PLMN / NPN (e.g. PLMN ID or in case of SNPN: PLMN ID + NID) as broadcasted by the RAN 106, and / or may include information related to which PLMN / NPN the first UE 100 is subscribed.

[0164] In another step 604, the second UE 103 provides the first UE 100 with the requested information for a registration request, e.g., the 5G registration request. For example, the information provided by the second UE 103 to the first UE 100 may include a SUCI of the second UE 103 and / or may include information related to which PLMN / NPN the first UE 100 is subscribed. It may also comprise information required for an application layer registration request that the first UE 100 may need to forward to provide access to the second UE 103. It may also comprise uplink information that needs to be transmitted by the first UE 100 on behalf of the second UE 103 (e.g. sensor data, location information, transparent payload) to the network.

[0165] In another step 605, the first UE 100 bundles the registration request information from the second UE 103 with its own and sends it to the RAN 106, while indicating which identifiers correspond to which UE. In another step 606, the RAN 106 forwards the registration request to the serving network (SN) (e.g., the AMF of the first CN 109), which, if required, may send a non-access stratum (NAS) identity request to retrieve the identity of one or more UEs. The UEs may have agreed on a master / coordinator (e.g., the first UE 100) to aggregate and send subscription concealed identifiers (SUCIs). The SUCI-based approach prevents direct and unprotected transmission of the international mobile subscriber identity (IMSI) to protect the anonymity of the end user. Each other UE (e.g., the second UE 103) conceals its subscription permanent identifier (SUPI) and transmits it to the first UE 100, which then aggregates SUCIs based on the home network identifier (e.g., if the first SIMs 104, 101 of the first and second UEs 100, 103 correspond to the same public land mobile network (PLMN), they are bundled together). Once received, the AMF forwards the identities and serving network's name to the corresponding unified data management entities (UDM(s)) to trigger primary authentication(s). The UDM is configured to manage network user data in a single, centralized element. It can be paired with a UDRthat stores user data such as customer profile information, customer authentication information, and encryption keys for the information. The UDM may reside on the control plane and may utilize microservices to communicate between the user plane and the control plane.

[0166] In another step 607, the first CN 109 (e.g., the UDM) de-conceals the SUCIs and retrieves the permanent keys which correspond to the SUPIs retrieved. The UDM then generates a multi-UE authentication vector taking into account the identity of the master / coordinator (e.g., the first UE 100) which will perform the verification e.g., of authentication token (AUTN), MAC, and expected result (XRES*), which may be computed based on the master UE's (e.g., the first UE 100) permanent key K, and subsequent keys derived from it (i.e., anonymity kex (AK), integrity key (IK), and cipher key (CK)). To achieve this, an authentication management field (AMF), K, SQN and random challenge (RAND) values may be fed into an algorithm (e.g., Milenage algorithm) which generates responses for AUTN, AK, CK, IK and XRES*.

[0167] To ensure the other UEs (e.g., the second UE 103) are also authenticated, XRES* takes into consideration the XRES(s) computed based on the other UEs permanent keys, such that XRES* is computed as a cryptographic function that depends on XRES of the different UEs, e.g. as:

[0168] • XRES* = KDF (CKm||IKm, SNN||SQN © XRESm © XRES2 © XRES3 ... XRESi). In the example, XRES* = KDF (CKm||IKm, SNN||SQN © XRESm © XRES2), where XRES2 corresponds to the second UE 103; or

[0169] • XRES* = KDF (CKm||IKm, SNN||SQNm © XRESm ||SQN2 © XRES2 || . . . ||SQNi © XRESi). In the example, XRES* = KDF (CKm||IKm, SNN||SQN © XRESm | |SQN2 © XRES2), where SQN2 and XRES2 corresponds to the second UE 103.

[0170] In another step 608, the first CN 109 generates the authentication vector and sends a NAS authentication request to the first UE 100 through the SN and RAN 106. In another step 609, the first UE 100 verifies the authentication vector (e.g., checks MAC and SQN), and if successful, sends the parameters (e.g., RAND, AUTNi), required to compute RES(s) and verify the authentication vector, to the other UEs (e.g., the second UE 103).

[0171] In another step 610, each UE computes RES using its permanent key and sends the result back to the master / coordinator UE (e.g., the first UE 100), which computes RES* similarly to the first CN 109 in step 207 of Fig. 2 (i.e., in this example: RES* = KDF (CKm||IKm, SNN||SQN © RESm © RES2) or RES* = KDF (CKm||IKm, SNN||SQN © RESm ||SQN2 © RES2)).

[0172] Note that in the first option, the CN is authenticated solely by the master / coordinator UE (e.g., the first UE 100) and hence the authentication vector includes only one AUTN (and subsequently, one SQN / MAC). In the second option, the CN is authenticated by all UEs, which entails that the CN sends an authentication vector containing an AUTNs container that includes X- number of AUTNs, where X is the number of UEs to be authenticated (e.g., two AUTNs in the example, for the first UE 100 and the second UE 103). Each UE (e.g., ith UE) extracts SQNi, computes and verifies MACi, and, if successful, computes SQNi © XRESi and sends the result to the master / coordinator UE to compute a combined RES*, e.g., RES* = KDF (CKm||IKm, SNN||SQNm © RESm ||SQN2 © RES2).

[0173] In another step 611, the first UE 100 sends the NAS authentication response (i.e., RES*) to the RAN 106.

[0174] In another step 612, the RAN 106 forwards the NAS authentication response to the SN which computes and verifies HRES*=SHA256(RAND||RES*) against HXRES*=SHA256(RAND||XRES*) received from the AUSF, and deems the multi-UE authentication successful from the SN's point of view if they match. It then forwards RES* to the AUSF of the first CN 109 which compares it to XRES*, deeming the multi-UE authentication successful from the CN's point of view if they match.

[0175] An advantage of the procedure / message flow described in Fig. 5 is that it reduces the signaling messages required by the RAN 106 and the first CN 109 to perform primary authentication for multiple UEs by leveraging the credentials of a master / coordinator UE (e.g., the first UE 100) to authenticate the network, and combine message authentication codes computed by all UEs requiring authentication to produce one authentication response. Another advantage is that UEs do not have to share or disclose any of their permanent keys, while also establishing separate security contexts, one each.

[0176] In a related example, the procedure described related to Fig. 5 may be performed as default, and only if it fails, the procedure described related to Fig. 2 may be performed. This may be done based on a policy configured in the first UE 100.

[0177] In reference to Fig. 2, it is to be noted that in the above procedures, the first UE 100 may receive synchronization signals and system information (e.g., in step 200) from one or multiple access devices. The first UE 100 may then perform a selection of the access device (e.g., RAN 106). The first UE 100 may perform the selection of the access device (e.g., RAN 106) on behalf of the second UE 103 wherein the first UE 100 may announce, e.g., in step 201 or 203, the selected access device as well as measurements performed when making this selection. This information may be used by the second UE 103 to determine whether to further connect to the RAN 106 through the first UE 100 or directly. This information may also be used by the second UE 103 to acquire synchronization signals and / or system information of the RAN 106 in a better way (e.g., faster or more efficiently because the timing of the signals is known).

[0178] In an example, the registration request may combine the SUCIs / GUTIs of two or more UEs (SIMs) as described in Step 605 of Fig. 5, but the primary authentication procedures may be performed independently of each other as in Fig. 2.

[0179] It is to be noted that UE 100 may contain two SIMs 101 and 102. Thus, the procedure in Fig. 2 and Fig. 5 may be performed a similar way for UE 100 and its two SIMs.

[0180] Additional details on multi-factor authentication (e.g. based on biometrics).

[0181] The following embodiments relate to enhanced identification and / or authentication and / or authorization and home-network triggered multi-factor identification and / or authentication.

[0182] Existing methods for (primary) authentication in cellular networks are solely based on cryptographic keys stored in the UE / SIM and core network. However, these keys may not be sufficient in some scenarios, e.g., when a user wants to access specific resources of a network. E.g., in a non-public network, it may be beneficial to enhance such authentication procedure with additional information, e.g., biometrics as a service or multi-factor authentication as a service. For instance, such additional information can allow identifying specific users (e.g. if same device can be shared by multiple users). For instance, this information may be biometric information, but it may also be a user-specific PIN, password, or cryptographic key. For instance, it may allow for user identification and / or also for user authentication or authorization.

[0183] In the system described in Fig. 1, we observe that the first UE 100 (e.g., a standard smart phone) may rely on own sensors or on sensors of a close-by device, e.g., the second UE 103 (e.g., a smart watch) to obtain some biometric information. Note also that the fact that the second UE 103 is close to the first UE 100 can be considered as a multi -factor authentication procedure. For instance, a camera in the first UE 100, which may be used to obtain the biometrics of the user, and / or sensors in the second UE 103, which may be used to obtain features of heart rate and / or movement of the user and / or the fact that the first UE 100 and the second UE 103 are close together, can be considered a multi-factor authentication. In the system described in Fig. 1, the first UE 100 and / or the second UE 103 may be capable of sensing, e.g., wireless sensing, to obtain biometrics of the user, e.g., heart rate and / or breathing rate of the user. In the system described in Fig. 1, the authentication procedures of the first and second UEs 100, 103 may be performed in a combined manner as described in other parts of this document (e.g., related to Fig. 5).

[0184] The scenario and the system described in Fig. 1 may also refer to a first device 100 (e.g., a UE or a gateway) that provides access to another device, e.g., the second device 103. It may be needed to determine what kind of device the second device 103 is, e.g., to provide a better service, e.g., identifying the second device 103 as AR / VR glasses may allow for optimization of the user experience.

[0185] The scenario and the system of Fig. 1 may also refer to a combination of both. For instance, multiple users may access the system by means of second device(s) 103 that connect(s) to the first device 100 (e.g., a UE or a residential gateway, RG). It may therefore be needed to identify both second device 103 and the user making use of it. For instance, the second device 103 may be AR / VR glasses or a tablet used by multiple users.

[0186] Fig. 3 schematically shows another procedure of an enhanced authentication procedure involving multiple user equipment devices.

[0187] In the embodiment of Fig. 3, that may be combined with other embodiments or used independently, a first UE 100 (e.g., the first UE 100 of Fig. 1 with the first SIM 101 and which may have second SIM 102) may use sensing means 126, e.g., wireless sensor to sense the presence of a user 402 holding the phone and / or a camera to obtain an image of the user 402 holding the first UE 100 (e.g., a phone). This is, e.g., illustrated by means of Fig. 3 where the sensing means 126 may refer to those sensors (wireless sensor and / or camera). The fact that the first UE 100 can sense the user 402 allows to confirm that the user 402 is present. In particular, since the user 402 is holding the phone or is standing / sitting next to the phone, the phone may sense (e.g., wirelessly sense) the distance to the user’s face and this distance may not be static but may vary over time due to the movements (head, hand, etc.) of the user 402. Similarly, the camera of the UE may capture the head / face of the user 402. Similarly, the camera may extract biometrics of the face, but may also keep track of the relative distance between face and camera, while as per the same reasons as above, the distance face-camera may change over time. The phone may then check that the real-time distance between the first UE 100 and the user 402 as measured through the sensing means 126, e.g., wireless sensor and / or camera, are correlated / identical so that the first UE 100 can verify that the user 402 is actually next to the first UE 100.

[0188] The same sensing capability may be provided at a second UE 103 (e.g., the second UE

[0189] 103 of Fig. 1 with the first SIM 104 and which may have second SIM 105) with sensing means 127 and a second user 403. The RAN 106 and the core network 109 with their components 107, 108 and 110 to 113 correspond to those of Fig. 1 and are not explained again here.

[0190] Exemplary sensing results are illustrated in time diagrams of Fig. 4 where the top diagram represents, e.g., the distance d between the first UE 100 and the user 402 overtime t, as measured by means of wireless sensing, while the bottom diagram represents, e.g., the distance d between the first UE 100 and the user 402 over time t, as measured by means of a camera. Since both measurements are correlated over time, it can be concluded that the user 402 is present and operating the first UE 100.

[0191] Thus, the waveforms of Fig. 4 can be used to perform a similarity check between measurements of two different sensing means on a single device (e.g., the first UE 100) or on respective different devices (e.g., the first and second UEs 100, 103).

[0192] When wireless sensing is not available, other sensors in the first UE 100 or the second UE 103 may be used to perform a similar correlation check, e.g., accelerometers of the first and second UEs 100, 103 may be used to check a correlation in the user hand / body movement comparable to an estimated user hand / body movement as measured when recording the user’s face and / or body with e.g. a camera of the first UE 100. Other biometric parameters may also be measured by the sensing means 126, 127, e.g., both camera and wireless sensing making the verification stronger (examples of those parameters may include heart rate or breathing). This ensures that an actual user 402, 403 is in front of the respective first / second UE 100 / 103 (e.g., phone) (and not a picture of the user).

[0193] In an embodiment that may be combined with other embodiments or used independently, sensors of different devices are used to perform the biometric verification. For instance, if the first user 402 is holding the first UE (e.g., phone) 100 and also wearing a smart watch (e.g., the second device 103 of Fig. 3), and the smart watch is monitoring certain features (e.g., sound and / or health features of the user with biometric properties), the system may check whether: a) The biometric features measured by the smart watch match biometric features stored in the core network, and / or b) The measurements (e.g., sound, movement (when the user is holding both devices for the call), etc.) of the smart watch and the first UE 100 are correlated.

[0194] This allows using multiple devices bound to or associated with a user to provide enhanced user authentication.

[0195] In an embodiment that may be combined with other embodiments or used independently, the first UE 100 and the second UE 103 may be connected through a wireless communication link, e.g., a PC5 link. The fact that the first and second UEs 100, 103 are connected serves as proof that they are close together, e.g., if the first UE can manage to establish a secure direct PC5 connection with the second UE. This proof can be further enhanced if the first and second UEs 100, 103 are both able to sense a correlated measurement, e.g., the ECG or heart / breathing rate of the user.

[0196] In an embodiment that may be combined with other embodiments or used independently, the first UE 100 and the second UE 103 may wish to perform a biometric measurement and this may require a user action to allow for it. For instance, the user may need to first enable or confirm the feature in the UE options. The UEs 100 and 103 may also record the confirmation as a proof of consent and the proof of consent may be uploaded to the core network 109, e.g., to a NF in charge of identification and sensing.

[0197] In an embodiment that may be combined with other embodiments or used independently, one of the first and second UEs 100, 103 may record biometric features of a user such as face or perform an iris scan and check it against a fingerprint in the core network 109. This action may be performed during an initial user configuration of the device / UE. This may be an optional authentication layer that may be offered by the cellular system to enhance the authentication procedures.

[0198] In an embodiment that may be combined with other embodiments or used independently, the core network 109 (e.g., AUSF / UDM / UDR / PCF) may store a configuration / policy determining whether biometric -enhanced authentication is supported and / or required when performing the initial primary authentication of a UE 100, 103 and / or user 402, 403.

[0199] In an embodiment that may be combined with other embodiments or used independently, the user 402, 403 may indicate and / or configure through the UE 100, 103 whether biometric-enhanced authentication is required in subsequent (e.g. secondary) authentication and / or communication and / or sensing procedures when using the UE(s) 100, 103.

[0200] In an embodiment that may be combined with other embodiments or used independently, the user 402, 403 may indicate and / or configure through the respective UE 100, 103 whether biometric -enhanced authentication is used in subsequent (e.g. secondary) authentication, communication and / or sensing procedures when using different UE(s) 100, 103. This can allow a user to use his subscription even if he is not using his own UE. The user may need to select a network when using the phone so that the phone can use the correct public key of the network (e.g., PLMN) to protect (e.g., encrypt) the biometric information. If the biometric information matches with the biometric information stored in the network, the user is authenticated and the network may check whether its user profile allows for the usage of the network. If allowed, the network may allow access.

[0201] In a related embodiment that may be combined with other embodiments or used independently, since access is required and allowed, a root key may be derived from the secret biometric information, e.g., by applying a key derivation function. This root key can be used to derive other keys in the key hierarchy (such as K_SEAF, K_AMF, or K gNB as described in TS 33.501). In a related embodiment that may be combined with other embodiments or used independently, since access is required and allowed, a user identifier or pseudo-identifier may be derived from the secret biometric information, e.g., by applying a key derivation function. This user identifier may play the role of a SUPI, although in this case, it may be called biometric-based subscription permanent identifier (Bio-SUPI) or user-based subscription permanent identifier (USUPI).

[0202] In a related embodiment that may be combined with other embodiments or used independently, a user may have a subscription allowing for the usage of a number of UEs, e.g., two UEs (such a smart phone and a smart watch). In an example, the user may then access a first UE with the profile of a smart phone and authenticate with the core network through the smart phone so that that smart phone is then linked to the user’s subscription. The user may then access a second UE with the profile of a smart watch and authenticate with the core network through the smart watch so that the smart watch is then linked to the user’s subscription. The authentication through a smart device may be based on the user’s credentials such as the biometric data of the user. If the user then tries to use a third smart device, e.g., a second smart watch, the network detects that a device is already active, and it will not allow the usage of the second smart watch. Alternatively, the network may allow access to the third smart device e.g., a second smart watch, provided that the user’s credentials (i.e., biometric data provided through the third smart device) matches the user’s biometric credentials stored by the network. The network may set as part of the user’s subscription the number of devices that a user is allowed access from and under which conditions (e.g., device types, number of concurrent / simultaneous links); furthermore, the network may verify, as described in previous embodiments, how correlated are different sensing data from the different devices, and / or whether the devices were part of a multi-authentication procedure or were authenticated separately, and / or whether devices are co-located, such that the network ensures that the third smart device (e.g., the second smart watch) is handled by the user itself.

[0203] In a related embodiment that may be combined with other embodiments or used independently, this option may also be applicable to emergency situations wherein a UE may scan the biometrics of a user, protect them (encrypt them) with a public key of the home network, and transfer them to the network. This can allow identifying the user performing the emergency call. The user may have the option to select the network before performing the emergency call so that his biometric information is encrypted with the corresponding public key, and it can be decrypted and matched. This has the advantage of facilitating the match, although it may not always be feasible in emergency situations. Additionally or alternatively, biometric information may be protected with a key of the serving network. The serving network may decrypt and encrypt the received data with a key of other networks so that it can be securely exchanged. The protected biometric information may be routed to multiple networks (e.g., by the serving network) so that a potential match is established. The message including the protected biometric data and emergency request may include a field indicating whether the data needs to be routed to one or multiple home networks (e.g., PLMNs). The serving network may route the biometric information to other networks if it cannot find a match. Finding a match serves the purpose of identifying the user who is performing the emergency call.

[0204] In a related embodiment that may be combined with other embodiments or used independently, the device / user may encrypt the biometric data and may send the encrypted data to the core network. The verification of the biometric data may happen in the encrypted domain, i.e., it may be performed homomorphically similar to “Hyunmin Choi et al., Blind-Touch: Homomorphic Encryption-Based Distributed Neural Network Inference for Privacy-Preserving Fingerprint Authentication” (available online at https: / / arxiv.org / pdf / 2312.11575.pdf). To achieve this, the UE may need to be configured with a public key to encrypt the biometric data. Furthermore, the entity performing the matching may need to be configured with an evaluation key that allows performing the matching or comparison of the biometric data in the encrypted domain. The UE may share the evaluation key with the entity performing the matching as well as a list of potential reference protected biometric data. This can allow a less trusted party, e.g., a serving PLMN or an AF or a sensing NF, to perform the matching of the biometric data in the encrypted domain. The encrypted biometric data provided by the UE to the entity performing the evaluation may include an identifier of the encryption algorithm used, and / or a key identifier used.

[0205] In an embodiment that may be combined with other embodiments or used independently, the goal may not be to uniquely identify a user, but to just identify users using a UE without needing to know the actual identity of the user. For instance, the goal may be to ensure that the user is authorized to use the UE and / or particular service(s) and / or to identify the user to optimize the service. This may be considered a user profiling and may be used to learn which type of services the user requires and optimize the provisioning of services. A service may refer to the type of traffic the user requires (e.g., accessing small or big websites, gaming, streaming, emails, VR / AR communication etc.). Given the knowledge of the user behind the UE, the network can optimize the provisioning of services. For instance, two users using the same UE for the same service (e.g., IMSbased VR / AR services extending TS 23.228 Annex AC.9) may typically communicate with other users that are closer or farther away. Thus, if the network is informed about or is aware of the user ID, the network can provide a better parameter configuration, e.g., an initial predicted end-to-end communication latency that can be used to optimize the user experience by means of predictive models that take into account this latency. From this point of view, a UE may gather biometric information of a user, e.g., by means of the camera, or by means of how the user handles the UE (e.g., based on accelerometer data, or how the user touches the touchscreen), or the type of applications or services used by the user. Once the UE has determined the user behind the UE at a given instant of time, the UE may provide a NF (e.g., AMF or AUSF or session management function (SMF)) in the CN with such information. The network may also provide this information to an AF so that the AF may adapt its operation, e.g., select a user account based on the identified user. In the case of the SMF, the SMF may then adapt the service provisioning and resource provisioning based on the user. The AMF may also provide the gNB providing access to the network with a user profile configuration to optimize the traffic. The UE may generate and assign a pseudonym to the user and use it to identify the user over a period of time / session.

[0206] It is to be noted that in the above embodiment as well as other embodiments, a pseudonym or biometric data or other user specific credentials may be used as part of an authentication procedure. This authentication procedure can also be considered as an identification procedure that allows identifying a given user.

[0207] It is to be noted that the identifier assigned to an identified user may be generated at random and may be rotated and / or changed according to a policy to avoid tracking, e.g., tracking by the serving network.

[0208] It is to be noted that a UE may keep a record of users that used the UE and the way the UE was used. This information may be kept locally or may be shared with the core network in a secure way. Each of these users may be assigned a pseudo-identifier. Additionally, the home network may be enabled to link users’ pseudo-identifiers to users’ subscriptions e.g., for billing purposes. Note that a user may not have a subscription with the network providing connectivity services to the UE, in which case the network may charge the user associated with the UE according to the subscription profile maintained by the network.

[0209] In a further embodiment that may be combined with other embodiments or used independently, the UE / device manufacturer may be able to determine the user accessing the UE, e.g., in a way as an iPhone can be unlocked with the biometrics of the face. This information may be kept local in the phone, or it may be shared with the backend / service of the device manufacturer. The UE / device manufacturer may also profile the user and the type of networking / communication needs. However,

[0210] - the UE may be able to send an indication to the network about the type of user who is currently using the network. This indication may be sent to the network, AMF / SMF, that may then use this information to optimize the service, additionally or alternatively,

[0211] - the UE may also provide a pseudo-identifier so that the network, e.g., AMF / SMF, can profile the current user, and use this information to, e.g., optimize the service.

[0212] This indication or pseudo-identifier may be exchanged in a NAS message. Additionally or alternatively, it may be shared securely end to end with the home network, e.g., protected with a key derived from a root key shared between UE and the authentication function in the home network. The home network may then decide whether the identity / profile of the user managing the phone / UE may be shared with the serving network or not. In a further embodiment that may be combined with other embodiments or used independently, a user’s biometric data or pseudonym may be exchanged with the AMF via NAS communication. Alternatively, it may be exchanged with the home network e.g., with the UDM, end- to-end protected. The procedure may be similar to Clause 6.15.2 in TS 33.501 (Procedure for UE Parameters Up-date), but the procedure could rather be from UE to UDM, i.e., information flows from the UE to the UDM, so that only the UDM can determine the user behind the UE, and based on the user, optimize the provisioning of services, e.g., as in previous embodiment.

[0213] After primary authentication, the home network may share with the AMF the identity (e.g., SUPI) of the device used for primary authentication. In a further embodiment, if user identification is feasible, the identity of the user and / or a user profile may be shared with the AMF (e.g., in a serving network) so that the AMF, interacting with the SMF, can optimize the service, e.g., by provisioning sufficient resources. The user profile allows decoupling a given user identity from the traffic features that are required for the user, for instance, a user may be identified as a first user and the home network may know that this user usually visits social media and watches videos between e.g. 7 and 8 pm, and thus, it may provide the AMF with a user profile related to social media video so that the communication network is optimized for it.

[0214] In a further embodiment that may be combined with other embodiments or used independently, the user identification may be done locally at the UE. Once a user is identified, the profiling may also be done locally, e.g., based on historical data or and / an artificial intelligence (Al) or machine learning (ML) model that allows predicting the type of traffic that the identified user will likely generate. Afterwards, the UE may inform the network (e.g., AMF via NAS) about the user / traffic profile that is required. This embodiment is advantageous because it does not require the UE to keep sending the identity of the identified user to the home network, but it allows more local operation. Furthermore, it does not require sharing the identity of the user. For instance, if user 1 is using the phone, the phone may determine that the user will be using social media with video streaming for 15’ and then user_l will do web browsing for 1 h whereas if user 2 is using the phone, the phone may determine / predict that the user will be reading for 30’ before watching a movie for 45’. The phone may then share the user / traffic profile, namely:

[0215] 15’ video streaming, Ih web browsing

[0216] 30’ reading, 45’ movie watching

[0217] This allows the network to provide a better service by tailoring it to users’ needs and enables better resource management.

[0218] In a further related embodiment that may be combined with other embodiments or used independently, a UE may provide the network (e.g., home network) with information regarding the usage of a UE by an identified user. This allows the network to gather usage statistics related to the identified user and may allow obtaining a user profile model, e.g., an AI / ML model capable of predicting future usage of the UE and UE services / network services by the user. The network may provide the UE with the determined user profde model that the UE may then use to obtain a user profde / predict the required UE / network services when the user is identified. Additionally, or alternatively, the user profile model may be provided to a network function (e.g., AMF or SMF) so that the network function can predict the user profile / the required UE / network services for the identified user. In this case, the UE may need to provide the identity (or pseudo-identity) of the identified user to the network function (e.g., via NAS communication).

[0219] In a further embodiment that may be a variant of previous embodiments or combined with them, a device (e.g., the first UE 100 in Fig.3, that may be a UE or residential gateway) may provide the network with an identity of a device (e.g., the second UE 103 in Fig. 3) connected to it. A residential gateway, RG, may be a device located somewhere, e.g., at a home, and configured to provide access to one or more devices in the deployed location. The identity may be based on an identity of a wireless interface between e.g. the first UE 100 and the second UE 103 in Fig. 3. This identity may be similar to the identity of the identified user in previous embodiments since depending on the identified device (e.g., AR / VR glasses, TV, smart phone, or smart speaker) the provided service can be adapted or optimized, e.g., in terms of latency, bandwidth, or Quality of Service. Therefore, this embodiment can be considered as a variant of or addition to previous embodiments related to device identification.

[0220] In a further embodiment that may be a variant of previous embodiments or combined with them, a device (e.g., the first UE 100 of Fig. 3, that may be a UE or residential gateway) may provide the network with an identify of a device (e.g., the second UE 103 in Fig. 3) connected to it plus the identity of the user (e.g., the user 403 of Fig. 3) using the device. For instance, the first UE 100 may use e.g. wireless sensing or a camera to identify the user 403 and may identify the second UE 103 by means of e.g. the identity of a wireless link or by extracting it from the signature of the wireless interface with the second UE 103. The pair of identifiers (i.e., of the second UE 103 and the user 403) may be used to adapt or optimize the service to the identified user 403 via the second UE 103. For example, the first UE 100 may determine that a first user (e.g., Bob) is using AR / VR glasses and share (pseudo)identifiers linked to that user and / or device, and / or user and / or device profiles to the core network to adapt and / or optimize the provided services.

[0221] In an embodiment which may be combined with other embodiments, the user may indicate / configure through the UE whether a joint authentication procedure is required when connecting to the network or using a service of the network (e.g., IP multimedia system (IMS) communication) wherein multiple UEs may need to be connected to provide the user with all (a subset of the) requested services. For instance, a metaverse session may involve multiple devices (e.g., glasses, sensors attached to the body, etc). The process to join the network may be by means of a joint authentication procedure as described in previous embodiments. In an embodiment, the network or an application may indicate and / or configure whether biometric -enhanced and / or multi-factor authentication is required in subsequent authentication and / or communication and / or sensing procedures and the procedures that may be used to enable it.

[0222] In an embodiment, the network and / or UE may trigger a configuration step in which the biometrics and / or multi -factor authentication settings of the user are scanned and / or obtained (e.g., by means of wireless sensing or other sensors) by the first UE 100 and / or the second UE 103 of Fig. 3, and securely retrieved and stored in a database 401 (e.g., UDM / UDR) in the core network 109 and / or in a database 404 (e.g., UDM / UDR) of the first UE 100 and / or in a database 405 (e.g., UDM / UDR) of the second UE 103. This information may include a duration for which such biometric information and / or multi-factor authentication settings are valid, e.g., biometrics extracted from the face may be valid for a longer period of time, and / or biometrics related to the current heart rate may be valid for a limited amount of time, or may be context dependent. This information may also indicate whether such biometric information may be used standalone to enable user access through a different UE, or a UE without a SIM. This information may also indicate whether such a biometric information may be used for identification in a wireless sensing system, and the context (e.g., time, location, etc.) where such information may be used with this purpose.

[0223] In an embodiment variant, where multi-factor authentication based on multiple (biometric and / or sensed) information elements is performed, the core network and / or UE may perform initial (or extra) checks to verify whether the information elements match and are consistent with a given context. For instance, a user that is performing a demanding physical activity may have an elevated heart rate. This (sensed) biometric information may be matched against data from device sensors (e.g., gyroscope sensor data over a period of time) and the multi-factor authentication information may only be verified upon passing such initial consistency and / or matching checks.

[0224] In an embodiment variant, the network and / or UE may look up a local configuration (e.g., from the databases 401 or 404 or 405 in Fig. 3) to verify whether a biometric-enhanced primary authentication / procedure is required, and if so: first, once the normal primary authentication procedure is performed, the network may optionally request from the UE(s) 100, 103 and / or RAN 106 the performance of biometric scanning, the UE(s) 100, 103 and / or 106 RAN may then perform the biometric scanning, and the UEs 100, 103 and / or RAN 106 may send the biometric data to the core network for validation against the stored and / or authorized biometric data, and / or second, the UE(s) 100, 103 may trigger a biometric-enhanced authentication and / or authorization process and share the authentication data as soon as the primary authentication process is successful and a secure channel has been established.

[0225] Note that the biometric data may also be shared earlier, e.g., if protected with the publickey of the network (e.g., PLMN). This sharing may be done, e.g., during the primary authentication. Note that multiple UEs (e.g., the first and second UEs 100, 103) may cooperate to perform the biometric scanning.

[0226] Note also that the biometric data may include raw (e.g. picture of face) and / or processed sensor data (e.g. facial recognition pattem / point cloud) and / or a resulting identifier of the user matching a user authentication method based on biometric scanning locally performed at the UE.

[0227] Note also that the same biometric scanning may be used for both local user authentication at the UE and for user authentication with the network. For example, the camera for face recognition could be used to unlock the phone and then whilst camera still on use face recognition e.g. after primary authentication or after specific time period (e.g. 2 seconds later) again to generate key or provide biometric data to authenticate to the network.

[0228] In an embodiment, the network and / or UE may look up a local configuration (e.g., from the databases 401 or 404 or 405 in Fig. 3) to verify whether a multi-factor authentication-enhanced primary authentication / procedure is required, and if so: perform a multi-factor enhanced primary authentication procedure, e.g., similar to Fig. 5, wherein the multi-factor may refer to the fact of using two or more devices in the primary authentication procedure, and / or the network may trigger a network-triggered multi-factor authentication procedure where the network requires the first and / or second UEs 100, 103 to reauthenticate as a means to revalidate the user by using a multiple-factor authentication procedure and / or biometric information.

[0229] In an embodiment which may be combined with other embodiments or used independently, the biometric -enhanced and / or multi-factor enhanced primary authentication (e.g., as in previous embodiments) or user identification / authentication may be required to be executed in a periodic or random manner, e.g., every 15 minutes, or once per time interval (e.g., 1 h) at random points of time, wherein this configuration may be stored in the network, e.g., in the database 401 of Fig. 3 which may be a 5G UDM, or every time the UE(s) are used and / or touched. This ensures that the network knows which user is handling the UE.

[0230] In another embodiment that may be combined with other embodiments or used independently, the periodicity of re-authentication / re-identification may be based on the user’s preference. For instance, a user with a UE / subscription that is associated with one user identity (i.e., belonging to said user) may not require user re-authentication / re-identification during a connectivity session, whereas a user with a UE / subscription that may be associated with multiple user identities may require re-authentication / re-identification more frequently. This may be configurable by an AF or the core network. It may be configurable as part of a configuration, policy, rules, etc.

[0231] In another embodiment that may be combined with other embodiments or used independently, the periodicity of re-authentication may further depend on the UE’s local authentication capabilities / method. For instance, a UE performing local user authentication through biometrics e.g., using facial recognition, does not require an action to be performed by the user and reauthentication may be performed much more frequently, whereas fingerprint-based biometric authentication or credentials (usemame / password) based authentication require the user to provide its fingerprint / credentials, in which case re-authentication may be performed less frequently.

[0232] In another embodiment that may be combined with other embodiments or used independently, in the event that a re-authentication / re-identification of a user fails (e.g., due to user change), the UE may send an authentication error message to the network indicating user change e.g., that the authenticated (e.g., through biometrics) user is different from the user for which the connectivity session was established. Additionally, or alternatively, in the event that a re- authentication / re-identification of a user fails due to UE malfunction (e.g., fingerprint sensor / facial recognition malfunction), the UE may send an authentication error message to the network indicating that the UE no longer supports the local (biometric) user authentication capability which malfunctioned. Additionally, or alternatively, in case of failure / malfunction of a local authentication method, the UE may perform re -authentication using an alternative local authentication method (e.g., based on credentials) and provide the authentication result to the network, in addition to an indication of the switch from one local authentication method to another (e.g., instead of sending an authentication error message). Additionally or alternatively, a failure of local identification / authentication may also trigger an identification / authorization procedure in which the core network and / or AF are involved. Additionally or alternatively, the identification / authentication may also be performed with a NF in the core network and / or AF (e.g., an AAA server). In case that the identification / authentication succeeds, the AF may provide the NF with the corresponding identity. However, if the identification / authentication fails, the AF may provide a failure message. The core network and / or UE and / or UE may log the event. The core network may have a policy determining the actions to perform, e.g., request the re-identification of the user, fall back to a generic user profile, etc

[0233] In an embodiment, which may be combined with other embodiments or used independently, that aims at avoiding periodic enhanced user re-identification re -authentication, the network may configure the UE with a policy to perform a local check based on biometric data that was used in the last successful biometric-enhanced authentication procedure. In case of a local check, the user data may be stored in a secure manner in the UE, e.g., protecting it with a key, e.g., derived from a PIN configured by the user after the last successful biometric-enhanced authentication procedure. The user may then need to enter this PIN to re-perform the local -enhanced authentication procedure (e.g., based on the PIN, the stored user biometrics may be decrypted and the stored user biometrics may be compared with the currently measured user biometrics).

[0234] In a related embodiment that may be combined with other embodiments or used independently, this policy may determine one or more of how many attempts may be allowed, how long that data can be stored on the UE with the purpose of this local check, or a context the UE needs to be in to avoid the (local or not) enhanced user authentication. In some cases, the context the UE needs to be in may refer to measurements that are indicative that the same user is using the UE, e.g., if sensor (e.g, accelerometer) measurements at the UE are indicative that the same user is or keeps using the UE.

[0235] In general, it is described a method for user re-identification and / or re -authentication that can be implemented in a user equipment wherein the method is adapted to:

[0236] - monitor an event that may trigger the (re ^identification and / or (re-)authentication of the user, obtain information to (re-)identify and / or (re-)authenticate the user,

[0237] - perform a local (re-)identification and / or (re-)authentication of the user based on: o a local procedure wherein the obtained information is checked against a local data base; o a remote procedure with a core network or application wherein the obtained information is shared with the core network or application.

[0238] In a related embodiment which may be combined with other embodiments or used independently, the UE may perform primary authentication with the core network and depending on, e.g., the outcome of the primary authentication and / or the user subscription in the UDM and / or information gathered from the UE (e.g., UE capabilities) and / or information about the trust level on the UE (e.g., based on device attestation as per other embodiments), the core network or application function may determine whether it may trust a user identity or user authentication result provided by the UE (based on local operation) or whether it requires an additional identification / authentication / authorization procedure through and / or with the core network and / or AF. In this second case it may trigger the identification / authentication / authorization procedure that may be based, e.g., on the Extensible Authentication Protocol (EAP), and run between UE and a network function in the core network or an application function.

[0239] In an embodiment which may be combined with other embodiments or used independently, user identification / authentication, e.g., biometric-enhanced authentication, may be required (e.g., triggered by an end user and or by an entity in the core network, e.g., the database 401 of Fig. 3, based on a policy) before / while providing a given service, e.g., performing a call over a cellular system between a local user and a remote user (e.g., the local user 402 using the first UE 100 and the remote user 403 using the second UE 103 as per Fig. 3). The user identification / authentication may also be done periodically based on a network policy. In a particular example, if the call is avatar- enhanced so that local user 402 and the remote user 403 only see / observe their avatar representations, and not their physical presence, the users may lack means to actually verify the other user as it is done in standard video / calls, i.e., by seeing the other person or by listening to the voice of the other person. This embodiment is therefore advantageous to ensure / provide a means to verify that the local user 402 and the remote user 403 are who they claimed to be, and not a different user (or attacker) faking one of them. In this embodiment, the provided service may refer to an IMS-based call or a call based on a real-time communication service, e.g., using an avatar, e.g., extending the AR / VR framework in TS 23.228 Annex AC.9. In this embodiment, a user (e.g., the local user 402 or the remote user 403) may request the core network 109 (e.g., based on information (a policy) stored in the database 401) to perform the biometric-enhanced authentication of the remote user before / while performing the call, or the core network 109 may trigger such a verification process based on a configuration. The following steps may apply: in a step, the local user 402 may receive an incoming call from the remote user 403.

[0240] In an additional step, the local user 402 (and / or the remote user 403) may have subscribed to a service for biometric user verification, so that the core network 109 (e.g., based on information stored in the database 401) triggers the biometric-enhanced authentication by requesting the remote UE (e.g., the second UE 103) to perform such biometric-enhanced authentication, wherein the handling of such a biometric-enhanced authentication may be done locally, e.g., based on information stored in the database 405, e.g., as described in above embodiments. Note that multiple UEs may also be involved in the biometric user verification as explained in other embodiments.

[0241] In an additional step, the remote UE (e.g., the second UE 103) may then securely share the biometric data of the remote user 403, e.g., through the database 405, with the core network 109, e.g., with the database 401 which can then analyze whether there is a biometric match and perform one or more actions based on a policy, e.g.: (1) provide the local user 402 with feedback with regard to the biometric verification, and / or (2) control the connection, e.g., drop the connection if the biometric authentication fails, and the policy requires it.

[0242] It is to be noted that the above procedure enabling an avatar-based communication may refer to AR / VR communication or metaverse communications. This may also apply to the provisioning of other services, e.g., establishment of a given data communication.

[0243] In a further embodiment, the user identification and / or authentication procedure may be performed every time the UE gets in a given state (e.g., a connected state) or is about to perform a given action (e.g., start transmitting data for a new data session). This may be based on a configuration selected by the user (e.g., dependent on the user subscription) and / or network. This may be a configuration stored locally in the UE. This may also be done on request by the network (e.g., the AMF) when the network detects that the UE becomes active and / or starts transmitting data.

[0244] In a further embodiment that may be used independently or combined with other embodiments, the user identification may also be enhanced with user authentication to further increase the security level of a UE. For instance, the home network may request a UE to lock itself if the user handling the UE is not recognized. The home network may also request capturing user data, e.g., biometric data such as a picture of the user face, in case that a user cannot be identified.

[0245] In a further embodiment that may be used independently or combined with other embodiments, the user identification may also be enhanced with user authorization to further increase the security level of a UE. For instance, the home network may request a UE or network function (SMF) to only allow certain actions by certain users. For instance, a user identified as a kid may not be allowed to make usage of certain services or access data from certain websites.

[0246] In an embodiment, the user biometric authentication of a first user using a first UE may be performed by a second user using a second UE. However, in this case, the second user and / or UE needs to have access to the actual information of the first user, e.g., the actual image of the user’s face to perform facial recognition. Thus, the second user may request the first user and / or UE to perform the encoding of the first user’s biometrics’ information, e.g., face, in a way suitable for biometric recognition, e.g., it may not apply any type of encoding or compressing, e.g., AI / ML based, e.g., generative Al based, approach to the face. This may imply a request sent by the second user and / or UE to the first user and / or UE and / or the core network. This may require the configuration of a policy in / for the first user and / or UE specifying which information should be exchanged in a biometrics friendly manner, when, and how, i.e., which information should be exchanged to enable the biometric verification of the user.

[0247] Some of the embodiments and embodiment variants show that the authentication and / or authorization capabilities go beyond what is feasible in current cellular networks where multiple types of authentication / authorization procedures are performed including one or more of:

[0248] - subscription authentication (e.g., the serving network shall authenticate the subscription permanent identifier (SUPI) in the process of authentication and key agreement between UE and network),

[0249] - serving network authentication (e.g., the UE shall implicitly authenticate the serving network identifier where the meaning of ‘implicit’ here is that authentication is provided through successful use of keys resulting from authentication and / or key agreement in subsequent procedures),

[0250] - UE authentication (e.g., the serving network shall authorize the UE through the subscription profile obtained from the home network and UE authorization is based on the authenticated SUPI),

[0251] - serving network authorization (e.g., assurance shall be provided to the UE that it is connected to a serving network that is authorized by the home network to provide services to the UE), or

[0252] - access network authorization (e.g., assurance shall be provided to the UE that it is connected to an access network that is authorized by the serving network to provide services to the UE). In particular, the user identification and / or authentication, e.g., biometric based user identification and / or authentication, may be used to enable user authentication and / or authorization when using one or more services. Which services may be allowed may depend on a policy configured in the core network, wherein the policy may be bound to the subscription or may be configurable by the user. A user may for instance configure which services may be accessible to anyone using the UE (e.g., emergency services, phone calls in the city, etc.) and which services may not be accessible to certain users using the UE (e.g., internet access or IMS calls to kids disallowed).

[0253] In a further related embodiment that may be combined with other embodiments or used independently, a UE and / or a user using the UE may have been identified and / or authenticated and / or authorized as a specific device and / or user, and / or specific device and / or user type. For instance, a user / UE may have been identified as a user requiring a specific type of service, and the service being in the user subscription. In this event, the core network may inform the service network (e.g., a network function such as AMF or SMF or UPF) about the specific type of device / user and a specific service profile that should be enabled or provided. For instance, the AMF may receive the user identity or device type or service profile, e.g., after successful primary authentication and user identification as in other embodiments. This can be used by a network function to adapt the service and optimize the service. For instance, the AMF may share this information with the SMF. Similarly, the access network may also be informed about the user / device and the specific service profile that should be enabled or provided. For instance, the AMF may inform the RAN that about the current service profile. The RAN may use this information to optimize the RAN services (e.g., communication or sensing services, e.g., to optimize the communication service to guarantee very low latency for a user). For instance, the RAN may store a mapping between the UE (used by the user) identity (e.g., RNTI) and the service profile. The service profile may then be used to optimize radio resource allocation to fulfil the service requirements. For instance, the service profile may be used to set a specific target Quality of Service in the RAN. For example, if the user is profiled as usually keeping his phone at a fixed position, RAN may use it to optimize how beam management is performed. Similarly, a UE may be informed about the user profile. The UE may use this information to optimize its performance, e.g., RAN communication such as beam management. The reason is that once users are identified, it is possible to analyze how the users use their mobile devices (e.g., how static the devices remain, where and for how long they are likely to be located, etc). This information that can be considered as a “UE usage profile” can be used to adapt communication parameters, e.g., how frequently measurements reports are performed and / or behavior e.g., a phone that is usually kept in a fixed position, if moved, may be triggered to send a message (or several (periodic) messages) to provide the network with supplementary information e.g., about its movement and / or location information. For instance, given the “UE usage profile” it may be possible to use it together with an AI / ML model and / or other techniques to predict how the UE will be used, and which RAN actions may be needed. For instance, if a UE (e.g., car) is being used by User 1, and User 1 usually goes to work by car, a paging message may be routed to a base station close to the work of User 1.

[0254] In general, it is described an apparatus for managing a connection, wherein the apparatus is configured to:

[0255] - select one of a plurality of authentication procedures;

[0256] - perform the selected authentication procedure with a core network; and

[0257] - set up the connection when the selected authentication procedure succeeds.

[0258] In general, the apparatus for managing a connection is adapted to:

[0259] - receive a configuration, from a network function, in a configuration message indicating a user profile and optionally a UE usage profile,

[0260] - store the user profile and optionally the UE usage profile and a RAN identity,

[0261] - adapt, based on the configuration, the selection of communication parameters associated to the RAN identity wherein the communication parameters are used in a communication link between RAN and UE.

[0262] In a related embodiment that may be combined with other embodiments or used independently, the user identification and / or authentication and / or authorization may be linked to the usage of a given service (e.g., IMS), or it may be provided as a service to a function, e.g., an application function.

[0263] For instance, an architecture for authentication and key management for applications (AKMA) (such as the one described in TS 33.535) may be extended to request guarantees on enhanced user identification / authentication (e.g., biometric-based user authentication). For instance, when an AF, e.g., a bank, uses such an AKMA, the AF may request performing enhanced user authentication to the core network, e.g., an AKMA anchor function (AAnF). The AAnF may then either retrieve the current user using the UE and / or trigger / reque st an enhanced user authentication procedure to verify that the “target” user is currently using the UE. The AAnF may eventually provide a user confirmation to the AF (in the case of AKMA, together with the corresponding K_AF as per TS 33.535). When the AAnF triggers or requests a user authentication procedure, this process may signal a request to trigger the authentication information of the current user. This authentication information may be related to the biometrics of the user (e.g., face, way of handling the UE, etc.) or may be based on something known to the users (e.g., a password) or may be based on something owned by the user (e.g., another UE such as an ambient loT tag or a smart watch). This provides enhanced guarantees on the user that is using the UE when a specific application is used.

[0264] For instance, a service, e.g., IMS, may involve a UE sending a message such as the SIP INVITE message may include a request for remote user identification. This message may also include information (biometrics, password, etc) about the current user handling the UE / using the service / requesting the service. This information may facilitate the identification of the user. This information may be used by the service (e.g., IMS network) to negotiate and / or facilitate the user identification whereby information used to verify / authenticate the user identity. The service may request the core network to validate / authenticate the user identity, e.g., may share information received in the message to validate it. For instance, it may request an AF / identity provider (e.g., Google, Apple, etc) to support the validation of the user identity. Once user identities are validated, the service may progress or other actions may be taken, e.g., the authorization of the storage or usage of Avatar models in the IMS communication as described in other embodiments.

[0265] In a related embodiment, the user may also trigger the enhanced user identification / authentication. For instance, an initial AKMA message (e.g., an application session establishment request, such as the one defined in Clause 6.2. 1 in TS 33.535) may be sent by the UE to the AF and may include either a request for the enhanced user authentication or data that may allow for the enhanced user authentication. In other words, the initial service request may include some user specific identification information (e.g., biometrics captured by the UE or a user PIN), e.g., if the UE allows it (e.g., based on a policy) and / or the application / service requires it. This allows performing the user identification / authentication check as soon as the request is received without involving any later protocol interactions.

[0266] Some scenarios may involve a multi-user authentication scenario, in which two or more users need to communicate with each other and verify their identities, e.g., biometric identities, to access a shared resource or service. For example, a bank account may require the biometric authentication of both the account holder and the authorized user to perform a transaction. In this case, the first user and / or UE may encode and transmit the biometric information of the first user to the second user and / or UE, and the second user and / or UE may perform the biometric authentication of the first user using the received information. Alternatively, or additionally, the second user and / or UE may encode and transmit the biometric information of the second user to the first user and / or UE, and the first user and / or UE may perform the biometric authentication of the second user using the received information. Additionally, or alternatively, both users and / or UEs may encode and transmit their identification information, e.g., biometric information to, e.g., a NF in the core network that may perform the identity verification, e.g., biometric authentication, and if successful, give an indication to, e.g., the users or a network function, or an application function (e.g., representing the bank service in this example). In either case, the biometric authentication of both users may be performed locally or remotely, depending on the policy and the availability of the network.

[0267] In some scenarios, a user receives a one-time authentication code via SMS to have access to some resources. For instance, a UE may unlock when the face of a user registered by the camera of the UE is detected. However, this is not sufficient when multiple users need to be authenticated to perform an action or when the security requirements need to increase. In a related multi-user authentication, multiple UEs may be required to be involved in an authentication procedure to perform an action. This multiple user and / or UE authentication procedure may be coordinated and / or signaled by the communication network. For instance, a real time communication (e.g., IMS call) between multiple users may only start once all users are (biometrically) authenticated. For instance, in a multiple-user real-time communication (e.g., IMS call) when two or more users are collocated, their biometrics may be jointly verified to reduce the risk of user impersonation or misuse of resources.

[0268] In an embodiment that may be combined with other embodiments or used independently, a UE may have a (U)SIM that may contain UE information related to the credentials required for the UE to register in the network (e.g., SUPI) and User information required to determine how the user can be identified, authenticated, and authorized. A user may unlock a SIM card / USIM with a first PIN code that may be provided by the user or stored in a user equipment (UE) and may access certain user specific information in the SIM card with a second PIN code that may be different from the first PIN code and may be provided by the user. This may enable the user to use the same SIM card for different purposes without compromising the security or privacy of the information stored in the SIM card. In some cases, the UE information may be in a UE SIM and the user information may be in a User SIM. For example, the user may insert the SIM card into the UE and power on the UE. The UE may then request the user to enter the first PIN code or may retrieve the first PIN code from its memory, and may send the first PIN code to the SIM card. The SIM card may compare the received PIN code with the one that is stored in the SIM card and, if they match, unlock the SIM card and UE information and allow the UE to access the basic services of the network, such as voice calls, SMS, or data connection. The UE may store the first PIN code securely in its memory, e.g., using encryption or hashing techniques, or may not store it at all and may request it from the user every time the UE is powered on, or the SIM card is inserted. The user may wish to access some additional User information or enable user specific functionalities (e.g., optimize traffic based on the user identify) by means of user information that is stored in the SIM card, such as user credentials, biometrics, or certificates. This user information may be sensitive or confidential, and may be used for an user authentication and authorization procedure with / through the core network, and the user may not want to share it with anyone else who may use the same UE or SIM card. Therefore, the user may set / use a second PIN code, which may be different from the first PIN code, and associate it with the User information that the user wants to protect, such user specific identification, authentication, and / or authorization information. The user may also specify the conditions under which the second PIN code is required, e.g., every time the user accesses the information, after a certain period of inactivity, or when the UE or SIM card is changed. This User information may also be in a different User SIM.

[0269] When the user tries to access or use the protected user information, e.g., to enable a given user specific service, the UE may prompt the user to enter the second PIN code that is associated with the information. The UE may then send the entered PIN code to the SIM card, which may compare it with the one that is stored in the SIM card and, if they match, allow the UE to access the information instead of a PIN, the SIM card may unlock itself based on the biometrics of the user. Alternatively, the second PIN may be based on the biometrics of the user (e.g., a function of the biometric data), such that upon UE successfully checking the biometric data (e.g., fingerprint, face, etc.) to the stored user biometric data in the UE, the UE may generate the second PIN and then send it to the SIM which compares it with the one it has in store. The UE may not store the second PIN code that is entered by the user or generated based on the biometrics of the user and may erase it from its memory as soon as the transaction is completed. Alternatively, or additionally, the UE may encrypt the second PIN code that is entered by the user and store it temporarily in its memory and decrypt it only when it is needed to access the information.

[0270] The User information in the SIM may also be stored in a database in a cellular system such as the UDR.

[0271] A UE may for instance have a UE SIM having UE credentials, e.g., SUPI and related keying materials, and one or more user SIMs (including eSIMs), each of them having user credentials, e.g., user identity, user identifier, user identification profile, and / or keying materials and / or biometrics associated to a user.

[0272] When a UE is powered on, the UE may check for the presence of a UE SIM, and if available, ask the user to unlock it, and perform the network registration, and primary authentication. Furthermore, the UE may check for the presence of a User SIM, and if available, ask the user to unlock it, and perform the corresponding user identification, authentication, and / or authorization procedure.

[0273] In some cases, the UE SIM may only be unlocked and / or certain functionalities may be available, if the user SIM is available and / or unlocked.

[0274] In some cases, the user SIM may only be unlocked and / or certain functionalities may be available, if the UE SIM is available and / or unlocked.

[0275] In some cases, if a cellular subscription is extended with a new user, a new User SIM may be configured in the UE, and / or the SIM may be updated to contain information about the new added user.

[0276] In some cases, the User SIM may lock itself if it detects that the user handling the UE has changed and / or some time has elapsed. This locking action may lock information, e.g., secrets, that may be required to control the connection.

[0277] In some cases, when the User SIM is unlocked, the unlocking procedure triggers an identification / authentication / authorization procedure with the core network to authenticate the user. The authentication procedure may be:

[0278] - A normal authentication procedure in which the User SIM needs to authenticate itself and authenticate the core network when no security context is present. For instance, it may perform an authentication procedure similar to primary authentication; and / or - A fast authentication procedure in which the User SIM / UE identifies / authenticates itself when a security context is present. For instance, the user may be identified by a temporary identifier (e.g., GUTI) that may be stored at the AMF. The User SIM may send the current GUTI to the AMF.

[0279] Which identification / authentication / authorization procedure is performed depends on the available (e.g., security) context available / stored in the User SIM / UE.

[0280] In some cases, the user identity may be a SUPI. The User SIM may include an indication, e.g., a flag, indicating that it is a user identity and / or a UE. The User SIM may only be unlocked if it is used in a specific device or in combination with a specific UE SIM. Thus, the User SIM may include the identity of the UE SIM (e.g. SUPI) it is allowed to be used with and the User SIM may check whether an allowed UE SIM is in the same mobile equipment before performing the User identification / authentication / authorization procedure.

[0281] In an embodiment aimed at enhancing Emergency services that may be combined with other embodiments or used independently, a UE capable of taking biometric measurements (e.g., fingerprint, face, heart / breathing rate, etc) and / or supports a User SIM, may provide user information to the network during an emergency session to assist emergency services providers (e.g., dispatchers / rescuers) in identifying the person in need of help and / or provide them with emergency supplementary information (e.g, medical information such as blood type, allergies, etc). Such information may be provided by the user to the network during a setup stage (e.g., configuration of the User SIM), and preferences for when such information, or which type of information may be used (e.g., sent to the emergency services providers) may also be indicated by the user as part of their preference and / or upon request (e.g., during emergency communication establishment). Upon receiving an emergency request, which may contain protected user information and / or protected user identity and / or protected emergency supplementary information, the network may try to retrieve the emergency supplementary information (e.g., medication information such as blood type, allergies, etc), if any and if not provided in the request, and include it in the emergency message sent to the emergency services providers (e.g., emergency responders).

[0282] In an embodiment that may be combined with other embodiments or used independently, the UE may be (pre-)configured (e.g., by the User and / or the network) to attach the User Identity of the user requesting emergency services to the emergency request by default, or under certain conditions. For instance, the UE may perform biometric measurements (e.g., face) to try and identify the user requesting emergency services, and depending on an emergency policy e.g., only if the biometric check is successful (e.g., against biometric data stored on the UE and / or on the USIM, the UE may include the User Identity in the emergency request. For instance, the UE may be configured to perform biometric measurements and try to identify the user, but regardless of whether the biometric check is successful or not, the UE may still include the biometric measurement, or a function thereof, in the emergency request, such that when received by the network, this latter attempts to identify the user to whom the biometric measurements may belong. This has the advantage of making it possible to identify the User requesting emergency services regardless of whether the device used to request emergency services belongs to them or not.

[0283] In an embodiment that may be combined with other embodiments or used independently, the User Identity and / or biometric measurements, if included in the emergency request, may be protected using the Home Network’s public key, or a long-term key associated with the User SIM, or a key derived from it, or an emergency specific key (pre-)configured / provisioned at the UE. In case the UE has neither a User SIM, nor a UE SIM, nor an emergency specific key, it may be left to an emergency policy and / or user preferences whether it is allowed to send the User Identity and / or biometric measurements with null ciphering / integrity protection. For instance, during emergency communication link establishment, the user may be prompted with a message which asks for the user’s permission to share the User Identity and / or biometric information / measurements with the network unprotected. If the user permits it, said information may be sent unprotected, and if not, the emergency request may be a generic one (i.e., user agnostic).

[0284] In an embodiment that may be combined with other embodiments or used independently, the User SIM may store user specific emergency information for emergency situations, e.g., emergency contact or medical data. This specific emergency information may be shared in emergency situations. Additionally or alternatively, the User SIM may store information (e.g., a secret or an identifier) that may allow accessing certain specific emergency information that may be stored on the mobile equipment where the User SIM is installed. For instance, the User SIM may include a secret that can be used to decrypt certain specific emergency information such as the medical history stored in the mobile equipment. For instance, the User SIM may include the identify of an emergency contact whose information is located on the mobile equipment.

[0285] In general, it is described an apparatus for managing a connection, wherein the apparatus is configured to:

[0286] - select one of a plurality of authentication procedures;

[0287] - perform the selected authentication procedure with a core network; and

[0288] - set up the connection when the selected authentication procedure succeeds.

[0289] Above apparatus is further adapted to identifying and authenticating a user by:

[0290] - receiving a SIM, prior to the selection of one of a plurality of authentication procedures, wherein the SIM is adapted to store user identification and authentication information, - supporting, prior to the selection of one of a plurality of authentication procedures, the unlocking of the SIM using a user specific PIN and / or user specific biological measurements or physical characteristics (e.g., biometrics), and

[0291] - using the user identification and authentication information, when performing the selected authentication procedure, to identity and authenticate the user with a core network.

[0292] In some scenarios, the core network and / or an AF may rely on the UE to perform the identification / authentication / authorization of a user, e.g., as in other embodiments. However, the UE may be compromised (e.g., hacked) and thus the core network or an AF may not fully trust it. To address this problem, in an embodiment that may be combined with other embodiments or used independently, the core network and / or AF may rely on device attestation techniques to evaluate whether:

[0293] - the core network and / or AF may rely on the result of a local identification / authentication / authorization procedure performed by the UE, or

[0294] - the core network and / or AF may not rely on the result of a local identification / authentication / authorization procedure performed by the UE, or the core network and / or AF may rely on a combined identification / authentication / authorization procedure performed by both the UE and core network / application function.

[0295] In a related embodiment that may be combined with other embodiments or used independently, a UE may include a module to allow performing device attestation. This module may be a hardware secure module that may be embedded in the UE hardware, e.g., an embedded Universal integrated circuit card capable of storing an eSIM or a secure element that may be able to store credentials or applications in a secure manner. This module may be a CPU that may have a trusted environment such as Arm TrustZone technology that provides hardware-enforced isolation and security. An application may be an application that computes the fingerprint (e.g., the hash function) of certain memory areas storing the code used to obtain the identity of the user and / or authenticate the user, e.g., when such identification or authentication is done locally. The fingerprint may be computed on demand, e.g., when requested by the core network and / or application function, or regularly or according to a policy / configuration. The fingerprint may be compared with a second fingerprint of the memory areas storing the correct / trusted code, wherein the second fingerprint may be securely stored in the hardware secure module. Additionally, or alternatively, the core network or application function may send a request to the hardware secure module to obtain the fingerprint of certain memory areas that need to be verified. The hardware secure module may obtain the fingerprint and return it to the core network and / or application function for verification. In a related embodiment, an application may be installed / configured on the device (e.g. by the manufacturer or the MNO before the device is deployed in the field or may be installed by the user later) that will be executed in the hardware secure module, whereby the application may be able to securely communicate the fingerprint related to device attestation or other data (e.g. result of a user authentication or a key derivation performed by the hardware secure module) to the network.

[0296] Additionally or alternatively, the USIM has a secure interface with the hardware secure module, e.g. to securely exchange messages, to enable that a USIM application can obtain the fingerprint related to device attestation or other data (e.g. result of a user authentication or a key derivation performed by the hardware secure module), so that the USIM application can use this information in a secure capability exchange with the network and / or in a user authentication procedure with the network, and / or whereby the USIM application may be used to relay traffic between the hardware secure module and the core network or to determine further actions locally (e.g., if the device attestation result fails, the USIM may lock itself).

[0297] Additionally or alternatively, the USIM may trigger / perform the device attestation step. Additionally or alternatively, before transmitting the fingerprint and / or other results of the device attestation performed at the device to the core network and / or application function, the fingerprint and / or other results of the device attestation may be protected (e.g., encrypted and / or integrity protected) by a key, e.g., a pre-shared key (or derived from it) stored in a device’s hardware secure module or the device’s USIM, whereby the pre-shared key may be provided and / or stored by a certificate authority responsible for the initial device attestation (e.g. device manufacturer and / or certified test center).

[0298] Additionally or alternatively, a certificate authority may provide a private key and / or a public / private key pair to be stored in a device’s hardware secure module or the device’s USIM, and may also issue a client certificate (e.g. using ACME protocol). These private key and / or public / private key pair and client certificate can be used to cryptographically verify the device is genuine during an authentication procedure. The pre-shared key or private / public key may not be provided, signed and / or stored unless the device has passed a set of tests to confirm that the device performs the security protocols and other protocols to connect to the 5G core network properly as required by the MNO and / or that the device is properly hardened against attacks and / or that one or more of its user authentication methods (e.g. fingerprint recognition, face recognition) works properly and can be trusted. The device may only transmit the fingerprint and / or other results of the device attestation if the receiving party (e.g. core network) can be properly authenticated by the device (e.g. by using a key, e.g., based on 5G Kausf and / or by performing mutual public key-based authentication). Based on the received device attestation fingerprint and / or other results of the device attestation, the core network and / or application can retrieve the device’s capabilities, e.g. from a database. In a related embodiment (UIA 1) that may be combined with other embodiments or used independently, the core network and / or AF retrieves information about the UE, e.g., UE capabilities, to assess whether the UE is trusted or not. The UE may include its capability for user identification / authentication as part of the UE capabilities in a message, e.g., registration request. The UE capabilities for user authentication / identification may include the local authentication methods supported by the device e.g., biometric -based such as fingerprint identification or facial recognition, credentials-based such as PIN or password lock, graphical password-based such as pattern lock, or support for re- authentication / re-identification via a secondary UE (e.g., wearable) such as a smart watch / ring that is associated with the first UE.

[0299] In a further related embodiment, the set of capabilities may also include information about the user authentication method used for unlocking the device and / or the device’s SIM. Additionally or alternatively, the device may inform the network (e.g. through updated UE capabilities or separate message or via an AF / NEF) if the user changes the user authentication method used for unlocking the device and / or the device’s SIM (e.g. in case the registration of the user that is using the device or the user authentication method relies on the device’s local authentication to unlock the device and / or the device’s SIM, e.g. if the UE only includes the resulting user identity from a local user authentication method in a registration request).

[0300] Additionally or alternatively, the set of capabilities may include information about user consent to use a particular user authentication method by the core network and / or application function, whereby the user consent may be provided / configured differently for different PLMNs, different network services or different applications. The user consent settings / configuration may include a flag whether or not notification to the user is required / requested, whereby if required / requested the user may be shown a notification to confirm that the respective user authentication method can be used, before the respective user authentication method is invoked. The user consent settings / configuration may be part of a privacy profile that may be stored in the UDM / UDR, i.e. as part of a UE’s subscription and / or may be stored per user as part of a user database or as part of user information linked to a set of subscriptions in the UDM / UDR. The core network and / or application function may retrieve the privacy profile and / or received user consent information and apply the user consent settings / configuration related to the user authentication methods to determine which user authentication methods it may use and which ones it may not. The user consent may also include whether the user authorizes sharing his (fully) identity with third parties, e.g., with the serving network or rather a user profile.

[0301] As mentioned, the core network may apply a user authentication policy that may include amongst others user authentication methods applicable or required to access different services and / or a user consent to use a predetermined authentication method. The core network and / or application function may use the retrieved / received UE capabilities to determine if the device has sufficient capabilities to perform user identification to access the services available to a particular user and / or make use of the differentiated handling per user (e.g. QoS settings applied per user) offered by the core network and / or application function and / or whether or not it has user consent to use a particular user authentication method. If not, only the default services and / or default QoS (e.g. for all devices or for a particular device, but not per user) may be made available, or a message (e.g. error message) may be provided to the device upon device registration, or when starting a PDU session or when accessing a particular service and / or application.

[0302] Additionally or alternatively, the core network may provide a similar user authentication policy to the device (e.g. upon device registration or starting a PDU session), based on which the device may determine which service s / applications the device is able to access and / or which ones not. The policy may also be used by the device to determine which user identification method to use for each service or application, since some service s / applications may require more advanced user identification methods than others. The user identification methods may be prioritized as part of such user authentication policy on the device and / or core network.

[0303] Additionally or alternatively, a combination of user identification methods may be required (e.g. fingerprint and RF based sensing) to gain access to a set of service s / applications. Combinations of user methods may also be prioritized. Additionally or alternatively, the core network and / or device selects / configures one of the user identification methods or a minimum user identification method (e.g. supporting fingerprint recognition at a certain resolution or having a certain confidence level, as minimum level) or a combination of user authentication methods, that is required to enable access to all or an identifiable subset of services and / or applications (e.g. based on a prioritized list of user authentication methods).

[0304] Additionally or alternatively, an application function may determine also some of the actions (e.g., the user identification methods used) and may communicate them to a core network / UE, either directly or indirectly. For instance, an application function in charge of identity management may be able to steer the identification / authentication capabilities of a UE, and may communicate / configure them according to the needs of a core network and the requirements of the core network that may have been communicated to the UE and / or application function.

[0305] Furthermore, in the core network each service or application function (or set of services / applications) may be registered / configured with or may configure a set of acceptable user identification methods and / or a minimum user identification method that the device has to support in order to gain access to the respective service and / or application function.

[0306] Additionally or alternatively, each service or application function (or set of services / applications) may require (e.g. as part of their configuration or configured as part of the user authentication policy in the core network and / or the device) additional security measures to be supported, e.g. by requiring the use of device attestation, by requiring periodic authentication or verification of the user and / or by indicating whether device unlocking or SIM unlocking using a user authentication method is sufficient or insufficient (whereby in case it is insufficient, the user may be required / requested to authenticate again or with a different authentication method). Furthermore, each service or application function (or set of service s / applications) may be configured as part of the user authentication policy or require as part of their configuration whether primary authentication of the device using a UE’s USIM credentials (i.e. as in legacy 5G primary authentication) is required or not in addition to one or more or minimum user authentication methods (whereby the user authentication methods may be applied during an authentication exchange (e.g. in addition / subsequent to primary authentication) or be part of biometric -enhanced primary authentication procedure).

[0307] In an embodiment that may be combined with other embodiments or used independently, if the above is configured as part of a user authentication policy on the device, then the device may skip primary device authentication and / or may include a parameter that indicates that it can / will skip primary device authentication in the initial message exchange with the core network (e.g. as part of registration request message) or during the security exchange with the core network (e.g. as part of the identity response message or authentication response). Skipping primary authentication may also be done based on the configuration of the core network and when a user keeps using a UE. In this case, the re-authentication of the UE by means of primary authentication may not be required, and only the user may be re-authenticated. The re-authentication of the user by means of the same UE serves as a proof of the usage of the same UE and user. This couple of UE / user may be stored in a data function in the core network and when the primary authentication is skipped, the user authentication procedure may be accepted if it matches the pair of UE / user. For instance, a security context based on a previous primary authentication may be available (e.g., a security context in which a root key such as 5G K_AUSF is derived from which the AS / NAS security contexts are derived). When re-identifying / re-authenticating the user, the user identification / authentication information is protected with said security context (e.g., in a NAS message or in a message sent to an authentication function such as AUSF protected with a key derived from K_AUSF). If user can be re-identified / re-authenticated, then the pair of UE / user remain active. If the re-identification / re-authentication fail, then further steps of the overall authentication procedure may need to be executed again, e.g., primary authentication.

[0308] Additionally or alternatively, in these messages the device may directly proceed with including the user authentication results based on the configured / selected user authentication method. If this is not (yet) configured as part of a user authentication policy on the device, then the core network may provide a (similar) user authentication policy to the device upon device registration and / or it may include a parameter in its security related message exchange with the device (e.g. as part of the identity request message or authentication request message) whether or not primary device authentication is required and / or whether the device can immediately proceed with user authentication instead. Additionally or alternatively, based on the selected / required / minimum user authentication method (e.g. selected by the core network and / or application function based on the above mentioned user authentication policy in the network and / or based on the configured / provided service / application authentication requirements and / or privacy profile), the core network may include information about the selected / required / minimum user authentication method as part of the security related message exchange with the device (e.g. as part of the identity request message or authentication request message), based on which the device will trigger and perform the selected / required / minimum user authentication method based on the available user authentication methods at the device. If the selected / required / minimum authentication method is (temporarily) not available (e.g. camera in use), the device may show an error message to the user and / or provide an error message to the network indicating that the user authentication method is (temporarily) not available and / or that the related services / applications are not available.

[0309] Fig. 6 shows an overall procedure for the identification / authentication / authorization of a user according to various embodiments. Entities 1100, 1101, 1102, 1103, 1104, 1105, 1106, 1107, 1108, and 1109 may refer to a user, a UE, RAN, AMF, SMF, PCF, AUSF, UDM, 3rdparty ID provider, and AF, respectively. Subsequent steps refer to potential phases of the communication procedure. These steps may be performed in the sequential order described here, or in a different order. Some steps may be performed multiple times. In particular:

[0310] Step 1110 may refer to an initial access to the UE by the user, a step in which the user may unlock the SIM card including user information. In this step the user may also unlock the ME and / or SIM including the UE information.

[0311] Step 1111 may refer to an initial UE registration procedure and authentication procedure. In this step, the user specific credentials (e.g., a user identity, biometric information, etc) may be transferred in a secure manner to the home network, e.g., by protecting (e.g., encrypting and integrity protecting) this information using the public-key of the home network. The AUSF / UDM may receive this information and may require the UDM to process (e.g., decrypt and integrity verify) it.

[0312] Step 1112 may refer to a request by the core network requesting the user specific credentials for identification of the user. This request may be triggered based on the type of service a user wants to access.

[0313] Step 1113 may refer to an answer by the UE, upon confirmation by the user, providing further user identification information, e.g., the user identity or profile based on local UE verification, e.g., as indicated in other embodiments.

[0314] Step 1114 may refer to an authentication protocol certifying the identity of the user. This protocol may be between UE and core network (e.g., AUSF / UDM) and / or AF and may consist in checking the biometric information of the user, or user credentials (e.g., a password). This protocol may also rely on a third-party ID provider that may be in charge of performing the user authentication, and upon successful authentication, provide the user identity. This protocol may only be executed when required (e.g., when the user identity provided in Step 1113 (that may have been obtained based on local verification) cannot be fully trusted, as described in other embodiments). For instance, the UE may send a user identifier, e.g., stored in the user SIM, introduced in the screen by the user, or derived from the user biometrics (e.g, face). The receiving party (e.g., AUSF, UDM, UDR, or a user identification NF) may look up specific credentials, and it may trigger an authentication protocol between, e.g., User SIM / UE and e, g., AUSF. For instance, the UE / User SIM may also protect said user identity and / or credentials (e.g., a key / password) with the public key of the home network and send this information to the home network. For instance, the user identity may be an identifier derived from the user biometrics (e.g., face). The message may also include a value (e.g., nonce, UTC time) so that the freshness of the message can be verified. The message may also include an identifier of the current UE or UE registration. The message may be:

[0315] Protection(Public_key_home_network, User_Identity, User_Credentials, freshness value, SUPI)

[0316] The above message may allow for one-way authentication, where (CN / AF) identifies / authenticates the user. For instance, upon reception, the receiving party may decrypt / integrity verify the message, it may use the User_Identity to look up credentials and may check whether the credentials match. Furthermore, it may check whether the message is fresh (recent) e.g., based on a UTC-based value. Furthermore, it may check that the message is associated to a user / UE with the indicated SUPI. Furthermore, it may check whether the User identity is associated with the SUPI included. It is to be noted that the key pair used for the encryption of the User identity, User_Credentials may be different than the key pair used for the encryption of the SUPI. An example of Public_Key_Encryption() may be Elliptic Curve Integrated Encryption Scheme. Other fields that may be required in this message may include the type of User Identity, the Home Network Identifier, a Routing Indicator, a Protection Scheme, a public key identifier. The receiving entity (e.g., AUSF, UDM) may then check the subscription and user profile and verify which services the user is entitled / authorized to and how they may be provided / optimized. Additionally, or alternatively, the message may also include a 3rdparty identity provider identifier, and the credentials may be protected with cryptographic keys issued or associated to the 3rdparty identity provider. The 3rdparty identity provider may then verify the identity of the user and authenticate the user, and the authenticated identity may be provided to the core network (e.g., AUSF / UDM / UDR) that may authorize the user based on the identity provided and the service(s) requested by the user.

[0317] In Steps 1115 and 1116, upon successful identification, authentication and authorization of a user, the AMF / SMF may be provided with user information, e.g., the user identity and / or identifier (e.g. to AMF) and / or information about the type of traffic the user consumes / produces (e.g., to SMF). The PCF may also be requested to provide the UE with user specific policies fitting its user profile and / or UE usage profile (as described in previous embodiments). Furthermore, the serving network may need the user identity, identifier, and identification profile, which may need to be provided to Lawful Interception entities.

[0318] In step 1117, the AMF may configure the RAN / UE with information about the user, UE usage, the type of traffic the user provides / consumes, and specific data about how the user is expected to use the UE for communicating, e.g., keeping it at a fixed position, moving it frequently, etc. This user information and UE usage information may be used to improve the communication between RAN and UE.

[0319] Fig. 7 shows an overall procedure for the identification / authentication / authorization of a user. Entities 1400, 1401, 1402, 1403, 1404, and 1405 may refer to a user, a UE, RAN, AMF, AUSF / UDM, and a 3rd party User Identity Management Server (UIMS), respectively. Subsequent steps refer to potential phases of the communication procedure. These steps may be performed in the sequential order described here, or in a different order. Some steps may be performed multiple times or may be skipped. In particular:

[0320] In step 1410, 1400 accesses the UE 1401 e.g., by unlocking the ME and / or SIM(s).

[0321] In step 1411, 1401 performs initial registration and primary authentication with 1404. 1401 may include an indication for its capability for user identification if available. Additionally or alternatively, the user identification capability may be part of the subscription details associated with UE 1401. Additionally or alternatively, the user identification / authentication information may be sent already at this stage.

[0322] In step 1412, based on one or more of the type of services requested / to be provided, the UE subscription details, and if any, the indication for user identification capability, 1404 may trigger a User Identification / authentication / authorization procedure whereby a User Identity Request is sent to 1401, in particular, if Step 1411 did not include any user identification / authentication information.

[0323] In step 1413, upon receiving the User Identity Request, 1400 may be prompted (e.g., through the user interface) to provide its User Identity and authentication information. If 1400 approves the request (e.g., by locally (re-)authenticating itself using biometrics e.g., face, fingerprint, etc, the User Identity and authentication information (e.g., User identifier, user biometric data) are sent protected to 1404 in the User Identity Response message. In case 1405 (a 3rd party User Identity Management Server (UIMS) is used for user identification / authentication, the user specific credentials (e.g., User Identity) may be protected by 1401, first, based on security materials (pre-)shared between the UE and the 3rd party UIMS, and then protected using the security materials associated with the established NAS security context (e.g., if NAS context has been established). Otherwise, the User Identity response message may be protected using the home network’s public key, as described in the previous embodiment.

[0324] In step 1414, 1404 processes the protected User Identity and authentication information received in step 4, and authenticates the User based on whether the User Identity is associated with a UE subscription or a user profde / subscription, as stored in 5GC (e.g., UDR). Alternatively, if the User Identity is managed by 1405, the User identification and authentication is performed by 1405 and the identification and authentication result, along with the User Identity may then be provided to 1404, which may subsequently check whether the identified and authenticated User is associated with a UE subscription or a user profile / subscription, as stored in the 5GC (e.g., UDR).

[0325] In step 1415, based on whether the User Identity authentication is successful, and the type of services requested by the user, the 5GC (e.g., PCF) determines whether the User is authorized for such services. If the identification / authentication of the User fails (e.g., at the user’s home network, or at the 3rd party identity provider e.g., UIMS in step 1414, or, if the user is not authorized for the type of services they have requested, the home network may send a reject message (e.g., in a NAS message) to 1401, which may indicate the failure cause (e.g., unauthorized service), or the failure may be indicated implicitly, e.g., by only providing services which do not require user authentication / authorization .

[0326] PDU-specific user authentication after registration

[0327] In some situations, it may be preferable to perform authentication of the user-specific identity during PDU session establishment or during network slice specific authentication and authorization rather during during initial registration.

[0328] A PDU session is a type of connection that allows a device to send data (typically user data (but also possibly control data) at the OSI network layer or above) to a communication network. In 3GPP, a PDU session can have the following types: a) IPv4; b) IPv6; c) IPv4v6; d) Ethernet (EtherType as defined in IEEE Std 802.3 [31 A]); and e) Unstructured

[0329] As indicated in 3GPP TS 23.501 and TS 23.502, a PDU session can be established after a device has registered and authenticated itself onto the network. Establishing a PDU session may require a second authentication procedure to be performed after primary authentication was performed during initial registration. As per current 3GPP TS 23.501, TS 23.502, TS 24.501 and TS 33.501, the second authentication procedure may involve the UE performing DN specific authentication towards a AAA-server (e.g. DN-AAA Server). Similarly, in order to gain access to a network slice, after primary authentication the UE may need to perform a Network Slice-Specific Authentication and Authorization procedure towards a AAA-Server or AAA-Proxy or Network Slice -specific and SNPN Authentication and Authorization Function (NSSAAF), as described in more detail in 3GPP TS 23.502, TS 24.501 and TS 33.501. Similarly, in order to gain access to a specific network service, after primary authentication the UE may need to perform network service specific authentication procedure. Currently, as per e.g. 3GPP TS 23.501, TS 23.502, TS 24.501 and TS 33.501, DN specific authentication is performed using a DN-specific identity of the UE. This identity is typically linked to the identity of the UE or subscription with a one-to-one relationship between the UE (identity) and a subscriber (which may be a human, but not necessarily the user of the UE, in particular for UEs that allow multiple users to make use of such UE), and / or may not be linked to an (e.g. separate / independent) user-specific identity or identity information, in particular biometric identity or biometric identity information. Hence, this second authentication procedure may not succeed if the identity used as DN-specific identity is from a user that is not registered as part of the UE subscription information. Also, currently, as per e.g. 3GPP TS 23.501, TS 23.502, TS 24.501 and TS 33.501, network slice specific authentication is performed using a network slice specific identity. Although this may use a User ID and credentials that are different from the 3GPP subscription credentials (e.g. SUPI and credentials used for PLMN access), this identity (and credentials) is typically linked to the identity (and credentials) of the UE or subscription with a one-to-one relationship between the UE (identity) and a subscriber (which may be a human, but not necessarily the user of the UE, in particular for UEs that allow multiple users to make use of such UE), and / or may not be linked to an (e.g. separate / independent) user-specific identity or identity information, in particular biometric identity or biometric identity information. Hence, this second authentication procedure may not succeed if the identity used as network slice specific identity is from a user that is not registered as part of the UE subscription information. Similarly, the identity used for authenticating with a particular network service is typically linked to the identity (and credentials) of the UE or subscription with a one-to-one relationship between the UE (identity) and a subscriber (which may be a human, but not necessarily the user of the UE, in particular for UEs that allow multiple users to make use of such UE), and / or may not be linked to an (e.g. separate / independent) user-specific identity or identity information, in particular biometric identity or biometric identity information. Hence, this second authentication procedure may not succeed if the identity used as network service specific identity is from a user that is not registered as part of the UE subscription information. By combining authentication of the user-specific identity with PDU session establishment, this allows the UE / network to only perform user-specific authentication when a given type of PDU session needs to be established and / or the user using the UE (next to other potential users of the UE) wishes to establish a specific PDU session. This may have some further advantages, e.g., the UE may be roaming and still support user authentication even if the VPLMN does not support anything regarding user authentication, e.g, any user authentication related capabilities. However, this (performing user-specific authenticated linked to the PDU session establishment) requires additional mechanism to allow for PDU-specific user authentication and authorization after registration.

[0330] In an embodiment that may be combined with other embodiments or used independently, the UE and / or network may be configured with a set of slice identifiers available to a user, which may be a subset X of the set Y of slice identifiers (e.g. NSSAI) allowed for that UE, whereby the subset X may be determined per the user’s user profile stored in the UDM / UDR and the set Y may be determined per the UE’s subscription, whereby the user profile information and the UE subscription may be combined in the subscription data stored in the network for a particular user and / or device. Furthermore, information about the subset X of Y may be stored in (the SIM of) the UE. The configuration may be further extended with information on Data Network Names (DNN)s available to the user and / or combinations of DNN / NSSAI.

[0331] In an embodiment that may be combined with other embodiments or used independently, the UE and / or network may be configured with a set of DNNs available to a user, which may be subset X of the set Y of DNNs allowed for that UE, whereby the subset X may be determined per the user’s user profile stored in the UDM / UDR and the set Y may be determined per the UE’s subscription, whereby the user profile information and the UE subscription may be combined in the subscription data stored in the network for a particular user or device. Furthermore, information about the subset X of Y may be stored in the SIM of the UE. For practical understanding, consider the following examples of DNNs (Data Network Names) that may be available to a user or defined in the subscription or user profile: internet - provides general internet access for web browsing, email, and typical data traffic. ims - supports IP Multimedia Subsystem services such as Voice over LTE (VoLTE) and video calls. private-enterprise - connects the device to a secure enterprise or corporate network, enabling access to internal resources. iot-sensor - allocates connectivity for Internet of Things (loT) sensors, optimizing for low data rates and power consumption. streaming-hd - designates a high-throughput network slice optimized for HD video streaming services.

[0332] These DNNs illustrate how different types of connectivity can be defined and controlled according to user roles / identities, device subscriptions, and / or network policies. By associating users and / or devices with specific DNNs, the network can ensure that only authorized users obtain access to the appropriate data services, slices, and network resources. The enforcement of permitted DNNs may rely on a combination of local configuration within the UE and centralized policy within the core network, with the possibility to update or restrict available DNNs in real time as user profiles or service needs evolve.

[0333] In an embodiment that may be combined with other embodiments or used independently, the UE and / or network may be configured with a set of services offered by the cellular network available to a user, which may be subset X of the set Y of services allowed for that UE, whereby the subset X may be determined per the user’s user profile stored in the UDM / UDR and the set Y may be determined per the UE’s subscription, whereby the user profile information and the UE subscription may be combined in the subscription data stored in the network for a particular user or device. Furthermore, information about the subset X of Y may be stored in the SIM of the UE. As 6G systems emerge, an even broader array of advanced services will be available, each requiring nuanced authentication, authorization, and user / service mapping. Examples of 6G services include:

[0334] Holographic Communication: Enabling real-time, high-fidelity 3D holographic calls and immersive telepresence experiences, holographic services will require extremely low latency and massive bandwidth, demanding sophisticated user authentication and fine-tuned access control to ensure privacy and service quality.

[0335] Integrated Sensing and Communication (IS AC): 6G networks may simultaneously support data transmission and environment sensing, offering services such as remote health monitoring, smart city infrastructure management, and gesture -based device control. Such convergence will introduce new requirements for secure identity linkage between user profiles and sensing data streams.

[0336] Intelligent Edge Services: Advanced edge computing within 6G will enable ultra-low- latency applications, including distributed Al-powered robotics, collaborative augmented reality, and time -sensitive industrial automation. These services will require dynamic user-to-device and device- to-service authentication at the network edge, often spanning multiple network slices and data networks (DNNs).

[0337] Personalized Al-as-a-Service (AlaaS): 6G will enable real-time access to Al resources on demand, such as personal digital assistants, emotion-aware content recommendation, and privacypreserving federated learning. These services necessitate user-centric, context-aware authentication and authorization, potentially leveraging biometric or behavioral identity information for seamless, secure user interaction.

[0338] Each of these service categories is expected to leverage the flexible architecture of 6G, with dynamic assignment of network slices, DNNs, and specialized authentication procedures tailored to the specific user, device, and service context. By aligning the subset of authorized services, slices, or DNNs to the user’s identity and profile, the network can ensure secure, policy-compliant access to the broad spectrum of next-generation services envisioned for 6G systems. In an embodiment that may be combined with other embodiments or used independently, the UE and / or the network perform an identification and / or authentication and / or authorization procedure related to a PDU session, a user and a given slide (and / or DNN and / or service). In particular, the procedure may be triggered during PDU session establishment.

[0339] In an embodiment that may be combined with other embodiments or used independently, the UE and / or the network enforce that a PDU session (1) cannot be established and / or (2) can be established and / or (3) can be used and / or (4) how it can be used and / or (5) the conditions under which it can be used, etc on a slice (or DNN or service) that is not part of subset X.

[0340] For instance:

[0341] Once the UE knows which user identity to use (e.g. after UE identifies the user), the UE and / or network need to enforce that the subset X of slices (or DNNs or services) configured for that user are the only slices (or DNNs or services) that are available to the user. In some cases, this “configuration” may be performed on the fly, wherein a user may attempt to use a given PDU session, and the UE and / or network perform an authorization procedure to determine whether the user is allowed to establish it, use it, how to use it, or the conditions to use it. This may be done by performing a local user identification / authentication and applying authorization rules or by implementing / enforcing restrictions to the UE operation. This may involve:

[0342] - not performing registration with / to the slices (or DNNs or services) that are not in subset X and / or not performing network slice specific authentication (or secondary DN specific authentication or service specific authentication) to the slices (or DNN or services) that are not in subset X, in particular the slices (or DNNs or services) in set Y, but that are not in subset X that the UE would normally be configured to use (e.g. include during registration) and / or perform network slice specific authentication (or secondary DN specific authentication or service specific authentication) with; and / or

[0343] - deregistering from the slices (or DNs or services) that are in not in subset X, in particular the slices (or DNNs or services) in set Y, but that are not in subset X.

[0344] - not performing PDU session establishment procedures on slices (or DNNs or services) that are not in subset X, in particular the slices (or DNNs or services) in set Y, but that are not in subset X.

[0345] Additionally or alternatively, the authorization and / or enforcement of restrictions may also be done by the network. For example, by including the user identification / authentication information in a registration message and / or PDU session establishment message, the network can identify / authenticate the user using the user identification / authentication information, and authorize / deny the establishment / usage of said PDU session. During registration and / or PDU session establishment, and / or during or after authenticating the user identity provided during registration and / or PDU establishment, the network may use the provided user identity to fetch / determine / check his / her authorization rights, e.g., by fetching / determining / checking the set X of slices (or DNNs or services) configured / authorized for that user in the user profile e.g. stored in the UDM / UDR, and if the PDU session is requested on a slice (or DNN or service) or the UE requests access to a slice (or DNN or service) that is in not in set X, PDU session establishment or the UE request to access a slice (or DNN or service) fails. Additionally or alternatively, the network may tear down previously established PDU sessions by the UE and / or connections / registrations to slice instances (or DNs or services) by the UE for the slices (or DNNs or services) that are not in set X, in particular for slices (or DNNs or services) that in set Y that the UE may already have registered / authenticated with, but that are not in a subset X of set Y. If this is not done, this may allow the user to potentially make use of slices (or DNs or services) that it is not allowed to use per the user’s user profile.

[0346] In an embodiment that may be combined with other embodiments or used independently, a UE may send a PDU session establishment request, whereby the PDU session establishment request may include an indication is requested / required (e.g. flag or a type field that indicates a (legacy) device specific PDU session or a user-specific PDU session is requested / required) that a user-specific identity (e.g. based on biometrics) and which may contain an indication of the supported or required type(s) of user identification to be performed (e.g. fingerprint, iris scan, facial recognition, PIN) and which may contain an indication of whether: a) a local user authentication procedure is to be performed by the device (e.g. checking fingerprint with a fingerprint stored in the SIM of the device) whereby the outcome of that local user authentication procedure is to be provided to the network as described in other embodiments, or b) the device is to securely send the collected user authentication information (e.g. userspecific identity information, such as biometrics) to the communication network for remote user identification and authentication as described in other embodiments.

[0347] Additionally or alternatively, the UE may perform a local user authentication procedure or may collect user authentication information (e.g. biometrics) before a PDU session setup procedure, and include in the PDU session establishment request: a) the outcome of the local user authentication procedure b) send the collected user authentication information (e.g. user-specific identity information, such as biometrics) to the communication network for remote user identification and authentication.

[0348] Additionally or alternatively, the network (e.g. based on network configuration or network policies) may require user identification for the usage of said PDU session / PDU session type in the current context (e.g., for the current UE subscription). The PDU session establishment message is sent from the UE to the network function responsible for handling PDU sessions (e.g. the SMF (e.g. indirectly via the AMF)), so the PDU session establishment may trigger an authentication procedure and / or authorization procedure, e.g., using the Extensible Authentication Protocol (EAP) wherein the UE acts as supplicant, the network function responsible for handling PDU sessions (e.g. the SMF) may act as authenticator, and another entity (e.g., AUSF / UDM in the home PLMN) as authentication server. The authenticator (e.g. SMF) may have been configured previously with a policy determining when a user authentication procedure needs to be triggered, e.g., when a specific type of PDU session is requested. For instance, if the authenticator (e.g. SMF) determines that user authentication is required for the usage of a given PDU session or a given QoS after the reception of a PDU session establishment, the authenticator (e.g. SMF) may send an authentication request e.g. EAP (identity) request) to the UE that may contain an indication (e.g. a flag) that a user-specific identity (e.g. based on biometrics) is required and which may contain an indication of the supported (e.g. by the network and / or UE) or required type(s) of user identification to be performed (e.g. fingerprint, iris scan, facial recognition, PIN) and which may contain an indication of whether: a) a local user authentication procedure is to be performed by the device (e.g. checking fingerprint with a fingerprint stored in the SIM of the device) whereby the outcome of that local user authentication procedure is to be provided to the network as described in other embodiments, or b) the device is to securely send the collected user authentication information to the communication network for remote user identification and authentication as described in other embodiments.

[0349] Upon reception of such user authentication request, the user may need to include / provide his / her identification / authentication information (e.g., biometrics) that may trigger the subsequent authentication procedure between UE (user) and the authentication server through the authenticator (e.g. SMF). The authentication server will provide the authentication and authorization result to authenticator and / or supplicant. If the user is authenticated and authorized, the authenticator (e.g. SMF) will allow the user / UE to setup the PDU session.

[0350] Note that in case the PDU session requested is of type indicating "Emergency Request" or "Existing Emergency PDU Session", the UE and / or authenticator (e.g. SMF) may not perform a user-specific second authentication / authorization procedure. In general, it may perform the userspecific authentication / authorization procedure according to a predefined policy that may allow adapting the standard settings, e.g., may not perform the user specific second authentication.

[0351] In an embodiment that may be combined with other embodiments or used independently, the user-specific authentication procedure is performed in addition and / or separately from: network slice specific authentication procedures based on (legacy) slice specific identities and / or credentials, and / or, secondary authentication towards a DN based on (legacy) DN specific identity.

[0352] In an embodiment that may be combined with other embodiments or used independently, the user-specific authentication procedure is performed together with: network slice specific authentication procedures based on (legacy) slice specific identities and / or credentials, and / or, secondary authentication towards a DN based on (legacy) DN specific identity and / or credentials. This may be done e.g. by the network sending an authentication request with a combined request for one or more / multiple identities to be authenticated (e.g. EAP identity request with a request for user-specific identity (e.g. based on biometrics) and a request for DN-specific identity (e.g. based on a DN-specific identity stored e.g. in the UE’s SIM for (legacy) DN access for the UE)), and the device sending multiple response messages or a single combined response message related to the multiple identities being requested.

[0353] In an embodiment that may be combined with other embodiments or used independently, a UE may contain multiple SIMs, each SIM may contain different types of credentials, e.g., a device credential, user credential, etc. Credentials of several SIMs may be combined in different authentication procedures, e.g., the credentials for the first authentication may be based on the (device) credentials in a first SIM and the credentials for the second authentication procedure may be based on the (user) credentials in a second SIM. A user may request the installation of a user SIM in a device. The installation may require the authentication / authorization by the device, and the (main) device owner. In general, in embodiments in which a single SIM is indicated, it may also imply that the device has one or more SIMs.

[0354] In an embodiment that may be combined with other embodiments or used independently, if the UE performs a user-specific second authentication procedure after primary authentication of the UE to register to the network (e.g. during PDU session establishment procedure) or a user-specific authentication procedure as part of or combined with a primary authentication procedure, whereby the UE provides user identity information (e.g. biometrics or username (possibly together with password)) of a user that is not currently linked to the UE’s subscription and / or user profiles related to that UE, then the network may search in its user profile database or subscription database if the user has a subscription to the network (e.g. for another UE). If so, the network may charge the respective user via its respective subscription (i.e. of that registered user and / or the user’s main UE) and / or may charge the UE subscription of the UE that the user is currently using whilst performing the user- specific authentication procedure. Which subscription to be charged can be based on network configuration or policy, and / or may be based on information stored in the subscription of the respective user (i.e. of that registered user and / or the user’s main UE) and / or the UE subscription of the UE that the user is currently using whilst performing the user-specific authentication procedure, and / or may be based on information stored in the user profile or database of user profiles. If the user is not known to the network (e.g. cannot be found after searching in its user profile database or subscription database for user identity information that matches the user identity information provided by the UE), then the network may send an error message to the UE (that may indicate that the user is not known) and / or may disconnect the UE from the network. If the user is known to the network (e.g. (e.g. can be found after searching in its user profile database or subscription database for user identity information that matches the user identity information provided by the UE), but not linked to the UE the user is currently using whilst performing the user-specific authentication procedure, then the network may send a message to the UE that may include: information as to which subscription is used (the subscription of the UE that it is currently using or the user’s own subscription (e.g. linked to user’s main UE), as selected by the network e.g. based on policy), a request to select which subscription to use (e.g. the subscription of the UE that it is currently using or the user’s own subscription (e.g. linked to the user’s main UE), a request whether or not the user wishes or approves to be linked to the UE’s subscription that the user is currently using, a request whether or not the user wishes or approves the UE that the user is currently using to be linked to the user’s own subscription (e.g. linked to the user’s main UE), and / or A request whether or not the user wishes or approves updating the user’s user profile with information that links the user to the UE that the user is currently using.

[0355] As a response, the UE may send a message to the network that includes information as to which subscription to use and / or to confirm or deny whether it wishes or approves to link the user to this UE (e.g. as part of the UEs’s subscription, the user’s own subscription or as part of the user profile information of user).

[0356] In another embodiment that may be combined with other embodiments or used independently, UE 100 possibly together with UE 103 obtain user identification information (e.g. biometrics) as described in embodiments of Fig.3, after receiving an authentication EAP (identity) request from the authenticator (e.g. SMF) that may contain an indication (e.g. a flag) that a userspecific identity (e.g. based on biometrics) is required and which may contain an indication of the supported or required type(s) of user identification to be performed (e.g. fingerprint, iris scan, facial recognition, PIN). After obtaining the user identification information (e.g. biometrics), the UE 100 and / or UE 103 may send a response based on the user identification information to the authenticator (e.g. SMF). If the UE 100 and / or UE 103 fail to acquire the user identification information and / or the user identification that matches indicated supported or required type(s) of user identification information, the UE 100 and / or UE 103 may send an error message to the authenticator and / or stop or retry the authentication procedure. Upon such authentication failure, the UE 100 and / or UE 103 may establish another type of PDU session that does not require user identification and / or may deregister from the network.

[0357] In another embodiment that may be combined with other embodiments or used independently, the user involved in the user-specific authentication procedures may be an application (e.g. a messaging application, AR / VR application, banking application) or a service (e.g. a user agent) running on the device, or may be an application specific user (e.g. user logged into a messaging application), in which case the user-specific identity information may include information related to the application and / or its user (e.g. unique application identifier, for example based on AppID used for URSP rules, and / or username in the context of the specific application), and / or user agent specific identity information. To this end, the user-specific identity information may include information element to indicate the type of user or user identity that is included during the user-specific authentication procedures and may use a different message or information element format depending on the type of user or user identity being used.

[0358] To summarize, apparatuses / methods for enhanced authentication in cellular networks have been described, wherein the apparatus / method checks for a preferred authentication procedure, performs the preferred authentication procedure with a core network, and sets up a connection. Thereby, authentication challenges (such as retrieving core network data, optimizing resources and strength of authentication) arising from users of one or more devices (e.g., UEs) using multiple / different networks, (e.g., with multiple subscriber identity modules and / or different radio access technologies) and / or biometrics (e.g., by means of embedded sensors or wireless sensing) can be addressed.

[0359] The invention can be applied to various types of UEs or terminal devices, such as mobile phone, vital signs monitoring / telemetry devices, smartwatches, detectors, vehicles (for vehicle-to- vehicle (V2V) communication or more general vehicle-to-everything (V2X) communication), V2X devices, Internet of Things (loT) hubs, loT devices, including low-power medical sensors for health monitoring, medical (emergency) diagnosis and treatment devices, for hospital use or first-responder use, virtual reality (VR) headsets, etc. Other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed invention, from a study of the drawings, the disclosure and the appended claims. In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. A single processor or other unit may fulfil the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. The foregoing description details certain embodiments of the invention. It will be evident, however, that no matter how detailed the foregoing appears in the text, the invention may be practiced in many ways, and is therefore not limited to the embodiments disclosed. It should be noted that the use of particular terminology when describing certain features or aspects of the invention should not be taken to imply that the terminology is being re-defined herein to be restricted to include any specific characteristics of the features or aspects of the invention with which that terminology is associated. Additionally, the expression “at least one of A, B, and C” is to be understood as disjunctive, i.e., as “A and / or B and / or C”.

[0360] A single unit or device may fulfil the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

[0361] The described operations like those indicated in the above embodiments may be implemented as program code means of a computer program and / or as dedicated hardware of the related network device or function, respectively. The computer program may be stored and / or distributed on a suitable medium, such as an optical storage medium or a solid-state medium, supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems.

Claims

62CLAIMS:

1. A method for connecting a device to a communication network using user-specific authentication, the method comprising:- performing a first authentication procedure using a device identity of the device for registering the device with the communication network;- obtaining a user-specific identity of a user of the device, the user-specific identity being different from device identities of the device;- performing a second authentication procedure using the obtained user-specific identity to enable data communication between the device and the communication network.

2. The method of claim 1, further comprising:- collecting user authentication information, such as biometric information of a user, by the device or through other devices close or connected to or attached to the device or the user.- the device securely sending the user authentication information to the communication network.

3. The method of any of the previous claims, wherein the second authentication procedure is triggered and / or performed during a Protocol Data Unit, PDU, session establishment, and the PDU session is associated with one or more of: a slice; a Data Network Name, DNN; and a network service.

4. The method of any of the previous claims, further comprising:- determining the authorization rights to access a first network slice and / or DNN and / or network service related to the user specific identity; and- enforcing the authorization rights when accessing the first network slice and / or DNN and / or network service.

5. The method of any of the preceding claims, further comprising:- determining a set X of network slice identifiers related to the user-specific identity, the set X being a subset of a set Y of network slice identifiers related to the device identity;- preventing access to network slices with network slice identifiers not being part of the set X.

6. The method of any of claims 1-4, further comprising:63- determining a set X of DNNs related to a user-specific identity, the set X being a subset of a set of DNNs Y related to the device identity;- preventing access to data networks with DNNs not being part of set X.

7. The method of any of claims 1-4, further comprising:- determining a set X of network services related to a user-specific identity, the set X being a subset of a set of network services Y related to the device identity;- preventing access to network services that are not part of subset X of Y.

8. The method of claim 5 or 6 or 7, further comprising storing the set X in- a SIM of the device and / or- the subscription data of the device and / or- a user profile of the respective user.

9. The method of any of the previous claims, wherein the first authentication procedure uses credentials stored in a first SIM of the device, and / or the subscription data of the device, and wherein the second authentication procedure uses credentials stored in a second SIM of the device, and / or a user profile of the respective user.

10. The method of any of the preceding claims, further comprising:- the device registering to the communication network and indicating its user authentication capabilities to the communication network,- the device receiving a user authentication request from the communication network indicating that user-specific authentication is to be used, and wherein the device performing the second authentication procedure comprises:- local user authentication, and sending the user authentication result as part of performing the user-specific authentication procedure with or through communication network, or- securely sending the collected user authentication information to the communication network for remote user identification and authentication.

11. The method of claim 10, further comprising:64- if the user of the device is not linked to the device’s subscription, the device receiving a message from the communication network, said message including one or more of the following:- information as to which subscription is to be used as selected by the network,- a request to select which subscription to be used,- a request to indicate whether or not the user approves to be linked to the device’s subscription,- a request to indicate whether or not the user approves the device to be linked to the user’s subscription,- a request to indicate whether or not the user approves updating the user’s user profile with information linking the user to the device;- the device sending a response message to the network, said response message including one or more of the following:- information about which subscription to use,- information to confirm or deny whether the user approves to link the user to the device12. The method of any of the preceding claims, further comprising:- the device performing the second authentication procedure during a PDU session establishment,- the device collecting user authentication information, wherein the user authentication information comprises biometric information obtained by the device or by other user devices close or connected to or attached to the device or the user and, wherein the device performing the second authentication procedure comprises: locally checking the user authentication information to perform a local user identification authentication or securely sending the collected user authentication information to the communication network for remote user identification and authentication; and the device setting up a PDU session when the user authentication procedure succeeds.

13. The method of any of the previous claims, comprising the device performing continuous userspecific authentication at random instants of time, or periodically, wherein the periodicity depends on one or more of: authentication capabilities / procedures supported by the device and / or communication network; network configuration;65 user preferences, type of service requested, connectivity state of the user equipment, and the number of users associated with a user equipment or subscription.

14. The method of any of claims 10 or 12, wherein, in case of a failed local user authentication procedure, the device: logs the failed authentication event, and / or sends an authentication error message to the network indicating the failure cause, and / or performs, based on a policy or configuration, one of the following: user authentication using an alternative authentication method using:• an alternative local user authentication method, or• alternative credentials associated with the user, and / or, establish a different type of PDU session, said different type of PDU session not requiring user identification.

15. A device comprising: a transmitter; a receiver; a processor; and a storage unit storing instructions which, when executed, cause the device to obtain a user-specific identity of a user of the device, the user-specific identity being different from the device identity of the device; perform a first authentication procedure using a device identity of the device for registering the device with the communication network; perform a second authentication procedure using the obtained user-specific identity to enable data communication between the device and the communication network.

16. The device of claim 15, further comprising the transmitter, receiver and / or processor to be adapted to perform the methods of claims 2-14.

17. A computer program product comprising instructions for implementing the method of claims 1-14 when executed on a computer.

Images