Application function based user specific authentication and activation

Abstract

Described herein are systems, methods, and instrumentalities associated with user authentication and / or activation. A wireless transmit / receive unit (WTRU) as described herein may determine a key identifier of the WTRU via a primary authentication procedure. The WTRU may transmit a message associated with an application on the WTRU to an application server, wherein the message may indicate at least the key identifier of the WTRU and an identifier of a user of the application on the WTRU. The WTRU may derive a key for the user based at least on the identifier of the user and perform mutual authentication with the application server for the user based on the derived key.

Description

APPLICATION FUNCTION BASED USER SPECIFIC AUTHENTICATION AND ACTIVATIONCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefits of U.S. Provisional Application No. 63 / 644,790, filed May 9, 2024, the disclosure of which is incorporated by reference herein in its entirety.BACKGROUND

[0002] In the context of evolving communication network architectures, there is a growing demand for robust mechanisms that enable application function (AF) based user-specific authentication and / or activation, while maintaining the integrity and privacy of user identities and network subscription credentials.SUMMARY

[0003] Described herein are systems, methods, and instrumentalities associated with user authentication and / or activation. A wireless transmit / receive unit (WTRU), as described herein, may determine a key identifier of the WTRU via a primary authentication procedure. The WTRU may transmit a message associated with an application on the WTRU to an application server, wherein the message may indicate at least the key identifier of the WTRU and an identifier of a user of the application on the WTRU. The WTRU may derive a key for the user based at least on the identifier of the user and perform mutual authentication with the application server for the user based on the derived key.

[0004] In examples, the key identifier of the WTRU determined via the primary authentication procedure may uniquely identify the WTRU, and the key derived for the user may uniquely identify the user and the WTRU as a combination.

[0005] In examples, the key for the user may be derived based further on an Authentication and Key Management for Applications (AKMA) anchor key. In examples, the key identifier of the WTRU may be associated with a subscription of the WTRU. In examples, the message transmitted to the application server may further indicate a request to perform a user-level authentication for the user. In examples, the mutual authentication with the application server may be performed using the key derived for the user as a shared secret between the WTRU and the application server.

[0006] In examples, the message transmitted to the application server may include a request to establish an application session with the application server, and the WTRU may be further configured to receive a response from the application server indicating to proceed with the mutual authentication. In examples, the WTRU may receive a message indicating that the user has been authenticated. In responseto receiving such a message, the WTRU may transmit a PDU session establishment or modification request comprising the user identifier to a network device. In examples, the WTRU may perform the mutual authentication with the application server based on a transport layer security (TLS) protocol.

[0007] A network device, as described herein, may receive a message from an application server, wherein the message may include a request to authenticate a user of a WTRU and identification information of the user or the WTRU (e.g., the message may include at least one of an identifier of the user or an AKMA key identifier of the WTRU). The network device may determine, based at least on the message received from the application server, whether a subscription of the WTRU is authorized for AKMA and whether the user is authorized to use the subscription. Based on a determination that the subscription of the WTRU is authorized for AKMA and that the user is authorized to use the subscription, the network device may generate a key for the user and send the key to the application server.BRIEF DESCRIPTION OF THE DRAWINGS

[0008] FIG. 1 A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented.

[0009] FIG. 1 B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0010] FIG. 1 C is a system diagram illustrating an example radio access network (RAN) and an example core network (ON) that may be used within the communications system illustrated in FIG. 1 A according to an embodiment.

[0011] FIG. 1 D is a system diagram illustrating a further example RAN and a further example ON that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0012] FIG. 2 may be a diagram illustrating an example procedure of deriving an authentication and key management for applications (AKMA) anchor key.

[0013] FIG. 3 is a diagram illustrating an example procedure of deriving an application function key (KAF).

[0014] FIG. 4 is a diagram illustrating an example procedure of provisioning a user identity profile.

[0015] FIG. 5 is a diagram illustrating an example procedure of AF-based user specific authentication and activation.DETAILED DESCRIPTION

[0016] A more detailed understanding can be had from the following description, given by way of example in conjunction with the accompanying drawings.

[0017] FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments can be implemented. The communications system 100 can be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 can enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 can employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0018] As shown in FIG. 1A, the communications system 100 can include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104 / 113, a ON 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which can be referred to as a “station” and / or a “STA”, can be configured to transmit and / or receive wireless signals and can include a user equipment (WTRU), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d can be interchangeably referred to as a WTRU.

[0019] The communications systems 100 can include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b can be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the I nternet 110, and / or the other networks 112. By way of example, the base stations 114a, 114b can be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a base station, a NR NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will beappreciated that the base stations 114a, 114b can include any number of interconnected base stations and / or network elements.

[0020] The base station 114a can be part of the RAN 104 / 113, which can also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or the base station 114b can be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which can be referred to as a cell (not shown). These frequencies can be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell can provide coverage for a wireless service to a specific geographical area that can be relatively fixed or that can change over time. The cell can further be divided into cell sectors. For example, the cell associated with the base station 114a can be divided into three sectors. Thus, in one embodiment, the base station 114a can include three transceivers, i.e., one for each sector of the cell. In an embodiment, the base station 114a can employ multiple-input multiple output (MIMO) technology and can utilize multiple transceivers for each sector of the cell. For example, beamforming can be used to transmit and / or receive signals in desired spatial directions.

[0021] The base stations 114a, 114b can communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 can be established using any suitable radio access technology (RAT).

[0022] More specifically, as noted above, the communications system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c can implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish the air interface 115 / 116 / 117 using wideband CDMA (WCDMA). WCDMA can include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed Downlink (DL) Packet Access (HSDPA) and / or High-Speed UL Packet Access (HSUPA).

[0023] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can establish the air interface 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro).

[0024] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement a radio technology such as NR Radio Access, which can establish the air interface 116 using New Radio (NR).

[0025] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c can implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., an eNB and a base station).

[0026] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0027] The base station 114b in FIG. 1 A can be a wireless router, Home Node B, Home eNode B, or access point, for example, and can utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d can implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106 / 115.

[0028] The RAN 104 / 113 can be in communication with the CN 106 / 115, which can be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data can have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 / 115 can provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 can be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which can beutilizing a NR radio technology, the CN 106 / 115 can also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0029] The CN 106 / 115 can also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or the other networks 112. The PSTN 108 can include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 can include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and / or the internet protocol (IP) in the TCP / IP internet protocol suite. The networks 112 can include wired and / or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 can include another CN connected to one or more RANs, which can employ the same RAT as the RAN 104 / 113 or a different RAT.

[0030] One or more (e.g., all) of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 can include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d can include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in FIG. 1 A can be configured to communicate with the base station 114a, which can employ a cellular-based radio technology, and with the base station 114b, which can employ an IEEE 802 radio technology.

[0031] FIG. 1 B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1 B, the WTRU 102 can include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138, among others. It will be appreciated that the WTRU 102 can include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0032] The processor 118 can be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 can perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to the transceiver 120, which can be coupled to the transmit / receive element 122. While FIG. 1 B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

[0033] The transmit / receive element 122 can be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in one embodiment, the transmit / receive element 122 can be an antenna configured to transmit and / or receive RF signals. In an embodiment, the transmit / receive element 122 can be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit / receive element 122 can be configured to transmit and / or receive both RF and light signals. It will be appreciated that the transmit / receive element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0034] Although the transmit / receive element 122 is depicted in FIG. 1 B as a single element, the WTRU 102 can include any number of transmit / receive elements 122. More specifically, the WTRU 102 can employ MIMO technology. Thus, in one embodiment, the WTRU 102 can include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0035] The transceiver 120 can be configured to modulate the signals that are to be transmitted by the transmit / receive element 122 and to demodulate the signals that are received by the transmit / receive element 122. As noted above, the WTRU 102 can have multi-mode capabilities. Thus, the transceiver 120 can include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and I EEE 802.11 , for example.

[0036] The processor 118 of the WTRU 102 can be coupled to, and can receive user input data from, the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 can also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 can access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and / or the removable memory 132. The non-removable memory 130 can include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 can include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 can access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0037] The processor 118 can receive power from the power source 134, and can be configured to distribute and / or control the power to the other components in the WTRU 102. The power source 134 can be any suitable device for powering the WTRU 102. For example, the power source 134 can include one ormore dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0038] The processor 118 can also be coupled to the GPS chipset 136, which can be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 can receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 can acquire location information by way of any suitable locationdetermination method while remaining consistent with an embodiment.

[0039] The processor 118 can further be coupled to other peripherals 138, which can include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 can include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and / or Augmented Reality (VR / AR) device, an activity tracker, and the like. The peripherals 138 can include one or more sensors, the sensors can be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0040] The WTRU 102 can include a full duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for both the UL (e.g., for transmission) and downlink (e.g., for reception) can be concurrent and / or simultaneous. The full duplex radio can include an interference management unit to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, the WTRU 102 can include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e.g., for transmission) or the downlink (e.g., for reception)).

[0041] FIG. 1 C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 can employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 can also be in communication with the CN 106.

[0042] The RAN 104 can include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 can include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c can each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c can implement MIMO technology. Thus, the eNode-B 160a, for example, can use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a.

[0043] Each of the eNode-Bs 160a, 160b, 160c can be associated with a particular cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, and the like. As shown in FIG. 1 C, the eNode-Bs 160a, 160b, 160c can communicate with one another over an X2 interface.

[0044] The CN 106 shown in FIG. 1 C can include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements can be owned and / or operated by an entity other than the CN operator.

[0045] The MME 162 can be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface and can serve as a control node. For example, the MME 162 can be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 can provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0046] The SGW 164 can be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 can generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 can perform other functions, such as anchoring user planes during inter- eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0047] The SGW 164 can be connected to the PGW 166, which can provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0048] The CN 106 can facilitate communications with other networks. For example, the CN 106 can provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 can include, or can communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. Inaddition, the CN 106 can provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which can include other wired and / or wireless networks that are owned and / or operated by other service providers.

[0049] Although the WTRU is described in FIGS. 1 A-1 D as a wireless terminal, it is contemplated that in certain representative embodiments such a terminal can use (e.g., temporarily or permanently) wired communication interfaces with the communication network.

[0050] In representative embodiments, the other network 112 can be a WLAN.

[0051] A WLAN in Infrastructure Basic Service Set (BSS) mode can have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can have an access or an interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic in to and / or out of the BSS. Traffic to STAs that originates from outside the BSS can arrive through the AP and can be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS can be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS can be sent through the AP, for example, where the source STA can send traffic to the AP and the AP can deliver the traffic to the destination STA. The traffic between STAs within a BSS can be considered and / or referred to as peer-to- peer traffic. The peer-to-peer traffic can be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS can use an 802.11e DLS or an 802.11 z tunneled DLS (TDLS). A WLAN using an Independent BSS (I BSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS can communicate directly with each other. The IBSS mode of communication can sometimes be referred to herein as an “ad-hoc” mode of communication.

[0052] When using the 802.11 ac infrastructure mode of operation or a similar mode of operations, the AP can transmit a beacon on a fixed channel, such as a primary channel. The primary channel can be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling. The primary channel can be the operating channel of the BSS and can be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) can be implemented, for example in in 802.11 systems. For CSMA / CA, the STAs (e.g., every STA), including the AP, can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA can back off. One STA (e.g., only one station) can transmit at any given time in a given BSS.

[0053] High Throughput (HT) STAs can use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

[0054] Very High Throughput (VHT) STAs can support 20MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. The 40 MHz, and / or 80 MHz, channels can be formed by combining contiguous 20 MHz channels. A 160 MHz channel can be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, can be passed through a segment parser that can divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing, and time domain processing, can be done on each stream separately. The streams can be mapped on to the two 80 MHz channels, and the data can be transmitted by a transmitting STA. At the receiver of the receiving STA, the above described operation for the 80+80 configuration can be reversed, and the combined data can be sent to the Medium Access Control (MAC).

[0055] Sub 1 GHz modes of operation are supported by 802.11af and 802.11 ah. The channel operating bandwidths, and carriers, are reduced in 802.11 af and 802.11 ah relative to those used in 802.11 n, and 802.11 ac. 802.11 af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11 ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non- TVWS spectrum. According to a representative embodiment, 802.11 ah can support Meter Type Control / Machine-Type Communications, such as MTC devices in a macro coverage area. MTC devices can have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and / or limited bandwidths. The MTC devices can include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0056] WLAN systems, which can support multiple channels, and channel bandwidths, such as 802.11 n, 802.11 ac, 802.11 af, and 802.11 ah, include a channel which can be designated as the primary channel.The primary channel can have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11 ah, the primary channel can be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands can be considered busy even though a majority of the frequency bands remains idle and can be available.

[0057] In the United States, the available frequency bands, which can be used by 802.11 ah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. InJapan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11 ah is 6 MHz to 26 MHz depending on the country code.

[0058] FIG. 1 D is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As noted above, the RAN 113 can employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 can also be in communication with the CN 115.

[0059] The RAN 113 can include base stations 180a, 180b, 180c, though it will be appreciated that theRAN 113 can include any number of base stations while remaining consistent with an embodiment. The base stations 180a, 180b, 180c can each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the base stations 180a, 180b, 180c can implement MIMO technology. For example, base stations 180a, 108b can utilize beamforming to transmit signals to and / or receive signals from the base stations 180a, 180b, 180c. Thus, the base station 180a, for example, can use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a. In an embodiment, the base stations 180a, 180b, 180c can implement carrier aggregation technology. For example, the base station 180a can transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers can be on unlicensed spectrum while the remaining component carriers can be on licensed spectrum. In an embodiment, the base stations 180a, 180b, 180c can implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from base station 180a and base station 180b (and / or base station 180c).

[0060] The WTRUs 102a, 102b, 102c can communicate with base stations 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c can communicate with base stations 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing varying number of OFDM symbols and / or lasting varying lengths of absolute time).

[0061] The base stations 180a, 180b, 180c can be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In the standalone configuration, WTRUs 102a, 102b, 102c can communicate with base stations 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c can utilize one or more of base stations 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c can communicate with base stations 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a,102b, 102c can communicate with / connect to base stations 180a, 180b, 180c while also communicating with / connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c can implement DC principles to communicate with one or more base stations 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In the non-standalone configuration, eNode-Bs 160a, 160b, 160c can serve as a mobility anchor for WTRUs 102a, 102b, 102c and base stations 180a, 180b, 180c can provide additional coverage and / or throughput for servicing WTRUs 102a, 102b, 102c.

[0062] Each of the base stations 180a, 180b, 180c can be associated with a particular cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E- UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1 D, the base stations 180a, 180b, 180c can communicate with one another over an Xn interface.

[0063] The CN 115 shown in FIG. 1 D can include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the foregoing elements are depicted as part of the CN 115, it will be appreciated that any of these elements can be owned and / or operated by an entity other than the CN operator.

[0064] The AMF 182a, 182b can be connected to one or more of the base stations 180a, 180b, 180c in the RAN 113 via an N2 interface and can serve as a control node. For example, the AMF 182a, 182b can be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, and the like. Network slicing can be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c. For example, different network slices can be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, and / or the like. The AMF 182 can provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0065] The SMF 183a, 183b can be connected to an AMF 182a, 182b in the CN 115 via an N11 interface. The SMF 183a, 183b can also be connected to a UPF 184a, 184b in the CN 115 via an N4 interface. The SMF 183a, 183b can select and control the UPF 184a, 184b and configure the routing oftraffic through the UPF 184a, 184b. The SMF 183a, 183b can perform other functions, such as managing and allocating WTRU IP address, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and the like. A PDU session type can be IP-based, non-IP based, Ethernet-based, and the like.

[0066] The UPF 184a, 184b can be connected to one or more of the base stations 180a, 180b, 180c in the RAN 113 via an N3 interface, which can provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b can perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and the like.

[0067] The CN 115 can facilitate communications with other networks. For example, the CN 115 can include, or can communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 can provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which can include other wired and / or wireless networks that are owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c can be connected to a local Data Network (DN) 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0068] In view of Figures 1 A-1 D, and the corresponding description of Figures 1 A-1 D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, base station 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device(s) described herein, can be performed by one or more emulation devices (not shown). The emulation devices can be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices can be used to test other devices and / or to simulate network and / or WTRU functions.

[0069] The emulation devices can be designed to implement one or more tests of other devices in a lab environment and / or in an operator network environment. For example, the one or more emulation devices can perform the one or more, or all, functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. The one or more emulation devices can perform the one or more, or all, functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device can be directly coupled to another device for purposes of testing and / or can perform testing using over-the-air wireless communications.

[0070] The one or more emulation devices can perform the one or more, including all, functions while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices can be utilized in a testing scenario in a testing laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network in order to implement testing of one or more components. The one or more emulation devices can be testing equipment. Direct RF coupling and / or wireless communications via RF circuitry (e.g., which can include one or more antennas) can be used by the emulation devices to transmit and / or receive data.

[0071] Application function (AF) (which may be interchangeably referred to herein as an application server (AS)) based user specific authentication and / or activation may be implemented based on authentication and key management for applications (AKMA).

[0072] One or more of the following may be applicable to a WTRU based on certain pre-conditions. An example of such a pre-condition may be that an AKMA capable WTRU has registered with a network and established an AKMA key and / or an AKMA key identifier (A-KID), for example, via a primary authentication procedure. Another example of such a pre-condition may be that a user (e.g., a human user) has requested a linkage of a user identity (user ID) with a WTRU subscription from an AF (e.g., via an application layer).

[0073] The WTRU may send a message the AF to establish an application session, for example, by providing the A-KID, an indication of user specific authentication, and / or the user ID to the AF. The WTRU may derive an AKMA application key for user identity (KAF-UI) for the user of the WTRU (e.g., for a subscription of the WTRU). The KAF-UI may include a security key that may be used by the WTRU to connect with an application (e.g., for the user of the WTRU identified by the user ID). The KAF-UI (e.g., a security key) may be used by the AF to authenticate the user identity and may be generated based on the following: KAF-UI = KDF (KAKMA, S), where S=AF_ID|user ID, KAKMA may correspond to an ‘AKMA anchor key,” and KDF may correspond to a “key derivation function.” The key derivation function may be based on various techniques including, for example, a hash-based cryptographic algorithm. When used herein, an AFJ D may refer to an ID of an AF or an application, and a user ID may refer to an ID of a user. The WTRU may receive a response message from the AF and perform mutual authentication with the AF (e.g., based on a transport layer security (TLS) protocol) using the KAF-UI, the A-KID, and / or the user ID. The WTRU may receive a message from a network device (e.g., during a registration procedure and / or a UE configuration update (UCU) procedure with the network device) and / or from the AF that may indicate a successful (or unsuccessful) status of the authentication and / or activation of the user ID for the WTRU subscription.

[0074] In examples, a WTRU may establish a PDU session based on (e.g., by providing) a user ID with limited connectivity and / or basic quality of services (QoS) for purposes of performing an AF-based user specific authentication. Such a PDU session may be (e.g., automatically) updated by a network device after a user identity associated with the user ID is activated by the AF.

[0075] In examples, a WTRU may have an existing or regular PDU session (e.g., not tied to a user). Once an application session with an AF is established (e.g., upon confirming activation of a user ID or user identity with a network device), the WTRU may establish another PDU session based on a user ID (e.g., the existing PDU session may be automatically released by the network following the user ID activation).

[0076] One or more of the following may be applicable to an AKMA anchor function (AAnF) based on certain pre-conditions. An example of such a pre-condition may be that a WTRU has initiated, with an AF, the establishment of an application session for a user. The AAnF may receive a message from the AF, wherein the message may indicate a request for a KAF-UI (e.g., a security key) of the user, an indication of performing user-specific authentication, a user ID, an A-KID, and / or an AFJD. In response to receiving such a message, the AAnF may locate a subscription identifier (SUPI) from a local AKMA context (e.g., by using the A-KID to verify that the subscription is authorized for AKMA operations). The AAnF may query a unified data management (UDM) function or a unified data repository (UDR) to verify whether the user ID is authorized for the subscription. This may be done, for example, by verifying the linkage of the user ID to the subscription in the UDM or the UDR. The linkage may be initiated by the AF via a network exposure function (NEF), and the AAnF may verify whether the user ID is authorized for AKMA based on an indication in the user profile and / or the presence of an existing KAF-UI.

[0077] The AAnF may derive a KAF-UI (e.g., a security key) for the user of the WTRU / subscription based on the user ID if no existing KAF-UI is available in the user profile. The derivation may be done based on KAF-UI = KDF (KAKMA, S) and S=AF_ID|user ID, and / or in response to determining that the user ID is authorized for the subscription and / or AKMA.

[0078] The AAnF may update the user profile in the UDR with the derived KAF-UI (e.g., to include the KAF-UI as part of the user profile). The AAnF may send information regarding the user identity (e.g., the KAF-UI for the user) to the AF, along with other information such as an external subscription ID (e.g., a Generic Public Subscription Identifier (GPSI)) or the relevant SUPI. The AAnF may reject the request from the AF if the user is not authorized for the subscription and / or AKMA operations. In response to receiving the KAF-UI, the AF may send a request to activate the user ID. The request may be sent to the UDM (e.g., via an NEF), which may notify one or more other network functions (NFs) about the activation of the user ID and / or the deactivation of an old user ID.

[0079] Security features and mechanisms (e.g., such as AKMA) may be employed to support the authentication and key management of applications based on the subscription credentials of a WTRU in a communication system. An AKMA key (KAKMA) may be derived by the network (e.g., via an authentication server function (AUSF)) and / or by a WTRU based on an access key (KAUSF) (e.g., following a primary authentication procedure). In example implementations, a single KAKMA key, which may be identified by an AKMA Key Identifier (A-KID), may be established per WTRU. The A-KID may be in a network access identifier (NAI) format such as “username@realm,” in which the username part may include a routing indicator (RID) and / or an AKMA temporary WTRU identifier (A-TID), and the realm part may include a home network identifier. The A-TID may be derived from a SUPI, for example, by using KAUSF to preserve SUPI privacy. FIG. 2 illustrates an example procedure for KAKMA generation in these example implementations.

[0080] An AF key (KAF) may be derived from a KAKMA by a WTRU and / or a network (e.g., via an AKMA anchor function (AAnF)). The KAF may be provided by the network to an AF for secure application layer communication (e.g., including mutual authentication) between the WTRU and the AF. A KAF (e.g., a single KAF) may be derived per application by binding the KAF to an AF fully qualified domain name (FQDN) (e.g., AFJD), which may be used as an input of a key derivation function. FIG. 3 illustrates an example procedure for KAF generation.

[0081] An application specific interface between a WTRU and an AF, referred to herein as Ua*, may use various authentication protocols, one or more (e.g., each) of which may be defined by a specific normative (e.g., AKMA profiles).

[0082] User identifiers may be used in a communication system such as a 5G system. System operators may utilize user-specific identities in a network, facilitating service delivery that may be tailored based on a user identity. The user identity may belong to a human user of a WTRU, an application running on a WTRU, or a device behind a WTRU gateway. The user identity may be linked to a subscription prior to being used in the communication system. FIG. 4 illustrates an example procedure for linking a user identity profile to a subscription.

[0083] Service level requirements and / or definitions related to user profiles and / or user identities may be specified as follows. AF-based user identity authentication and / or activation may be performed. For example, an AF may identify, based on an A-KID, a user identifier linked to a subscription in a communication system. The AF may interact with an AAnF to request the activation or deactivation of a user ID, for example, by locating a linked subscription based on an associated A-KID. AKMA based authentication between the WTRU and the AF (e.g., using a KAF over a user plane (UP)) may be performed prior to the AF activating or deactivating a user ID in the communication system.

[0084] A user ID may be in the form of a network access identifier (NAI) and may correspond to an email address (e.g., john@FQDN) of the user for accessing an application. The user ID may be assigned by an operator or a third party (e.g., including the user themselves and / or an AF).

[0085] In some implementations of an AKMA-based authentication mechanism, a KAF key (e.g., a single KAF key) may be established per WTRU for a given application based on the WTRU’s subscription credentials. This may mean that multiple users of an application sharing the WTRU may use a common KAF key and therefore an AF may not be able to authenticate a particular user of the WTRU with a certain subscription using these implementations of the AKMA-based mechanism. For example, if one of two users (e.g., Userl , User2) sharing the WTRU tries to access an application, the AF may not be able to determine which of Userl or User2 is being authenticated using the aforementioned implementations. This difficulty may arise because the WTRU may use the same KAF key for both users, and the AF may be configured to authenticate the WTRU based on a certain subscription and thus may not be able to distinguish between the two users of the WTRU, both associated with the subscription.

[0086] Without support for user-specific authentication, an attacker may impersonate a user associated with a subscription and gain unauthorized access to services reserved for that subscription and / or the user associated with the subscription. For instance, in the example given above, Userl may impersonate User2 and obtain unauthorized access to the service reserved for User2 (and vice-versa).

[0087] AF-based, user specific authentication may be implemented, which may consider application layer authentication protocols as well as the privacy of a user (e.g., identified by a user ID). For example, an AF may authenticate a user of a WTRU over an application layer (e.g., over a user plane) by leveraging user credentials and an enhanced AKMA mechanism that may support user specific authentication based on network subscription credentials and / or a primary authentication of the WTRU. An AAnF may generate and maintain network subscription-based user credentials, where a user identifier may be linked to a network subscription. Upon successful user-specific authentication of the WTRU for a subscription, the AF may request activation of a user identifier linked to the subscription from a communication network (e.g., a core network). Such an approach may enhance existing application layer authentication protocols while ensuring user privacy. The approach may enable the AF to provide robust authentication of a user of the WTRU utilizing credentials generated based on (e.g., cryptographically bound to) network subscription credentials of the WTRU that may be stored in a universal subscriber identity module (USIM), and / or based on a primary authentication procedure of the WTRU. A network operator may rely on a trusted AF to perform user specific authentication with a level of security equivalent to that of a WTRU-network primary authentication procedure, enabling the authorization of identity activation or deactivation based on the WTRU’s subscription.

[0088] User authentication by an AF over a user plane may simplify roaming deployment scenarios with reduced or minimal impact to a serving network (e.g., a visited public land mobile network (VPLMN)). For example, upon a successful user authentication by the AF, the AF may request the activation of the user for a subscription (e.g., in a UDM) via a home public land mobile network (HPLMN). The HPLMN may notify the VPLMN of a related subscription information update, which the VPLMN may propagate to one or more other network functions (e.g., an AMF, an SMF, and / or a PCF) so as to perform a relevant action (e.g., to update or release a PDU session).

[0089] User-specific authentication, which may also be referred to herein as user-level authentication, may be different than a WTRU or subscription-level authentication supported by an AKMA framework. Examples described herein in the context of a human user may be applicable to cases where a user ID represents the identifier of a device (e.g., a non-3GPP device) connected to a WTRU.

[0090] FIG. 5 illustrates an example procedure for AF-based user specific authentication and activation based on subscription credentials. As shown in FIG. 5, a WTRU may initiate application layer communication with an AF for user specific authentication. The type of messages exchanged between the WTRU and the AF may depend on the protocol (e.g., a transport layer security protocol) used to perform the mutual authentication. The messages may be generated or enhanced based on the authentication method supported by the WTRU and AF. An AAnF (e.g., which may reside on a core network device) may generate user credentials (e.g., KAF-UI) based on an AKMA key (KAKMA) associated with a certain subscription in response to receiving a request from the AF to authenticate a user of the WTRU with that subscription. The AAnF may update user profile information in a UDR with the KAF-UI (e.g., a security key) and may send the KAF-UI to the AF. The AF may (e.g., subsequently) request, from the network, activation of the user for the subscription after successfully authenticating the user using the KAF-UI. As a precondition of this procedure, a user identity profile for the user ID may be linked to the subscription by the AF (e.g., using a procedure shown in FIG. 4).

[0091] As shown at 0 of FIG. 5, the WTRU may perform a primary authentication (e.g., during a registration procedure) and may derive a KAKMA key, KAKMA (e.g., as shown in FIG. 2). The AAnF may store an AKMA context that may include the KAKMA key and / or a subscription identifier (SUPI). Upon registration with the network, the WTRU may send an indication of its capabilities to support an AF-based user specific authentication.

[0092] As shown at 1 of FIG. 5, the WTRU may send a message to the AF (e.g., to establish an application session). In the message, the WTRU may, for example, provide an A-KID (e.g., an AKMA key identifier), an indication of user specific authentication (e.g., a request to perform user-level authentication), and / or a user ID. The application layer message used to transport one or more of these data elements maydepend on the authentication protocol used. The WTRU may derive a KAF-UI for the user of the WTRU / subscription to connect with the application using the user ID as an input, where KAF-UI = KDF (KAKMA, S) and S=AF_ID|user ID. The KAF-UI may be (e.g., cryptographically) bound to a specific user of a particular application. The WTRU may be triggered to send the message to the AF if the WTRU detects that a new user may be using the WTRU. For example, the WTRU may detect the new user if the WTRU is unlocked with a credential such as a password, a face image, or a fingerprint. The WTRU may be preconfigured with a mapping between the credential used to unlock the WTRU and a user identity.

[0093] As shown at 2 of FIG. 5, the AF may determine that a request is being made for user level authentication based on the indication and / or the user ID included in the message received from the WTRU. If the AF lacks a valid security association (e.g., a KAF or KAF-UI) with the received A-KID (e.g., which may be for a particular subscription), the AF may send a request to the AAnF (e.g., directly or via a NEF) for a new key KAF-UI or KAF, for example, by providing the A-KID, the AF-ID, the indication of userspecific authentication, and / or the user ID received from the WTRU to the AAnF.

[0094] As shown at 3 of FIG. 5, the AAnF may locate a SUPI from a locally stored AKMA context using the provided A-KID to verify that the relevant subscription is authorized for AKMA operations. The AAnF may query a UDM and / or a UDR to determine whether the user ID may be authorized to use the subscription (e.g., by verifying whether the received user ID is linked to the subscription). The AAnF may check with the UDR whether the user ID is authorized for AF-based user specific authentication with a given application (e.g., as indicated by the AFJD) based on an indication in the user profile and / or the presence of existing credentials (e.g., KAF-UI). The AAnF may retrieve from the UDM and / or the UDR information regarding whether the user may be active on the subscription (e.g., due to a previous AF-based user specific authentication and / or an activation procedure from the current application or a different application).

[0095] As shown at 4 of FIG. 5, upon determining that the user ID is authorized for the subscription and / or the AKMA, and / or that no valid KAF-UI is available in the user profile, the AAnF may derive a KAF- UI for the user of the WTRU / subscription using the user ID (e.g., following a similar procedure as the derivation procedure performed by the WTRU at 1 of FIG. 5). The AAnF may derive a KAF for multiple (e.g., all) users of an application, in which case the AF may be responsible for deriving a per-user key to perform user-specific authentication as described herein.

[0096] As shown at 5 of FIG. 5, the AAnF may request the UDR to store the newly generated user credentials in a user profile. The AAnF may provide the SUPI, the user id, the AF-ID, and / or the KAF-UI to the UDR. Since the user may use one or more applications, the user credentials stored in the user profile may be associated with and valid for a particular application identified by the AFJ D. For example, if asecond application (e.g., identified by AFJD2) requests a KAF-UI as illustrated by 2 of FIG. 5, a second KAF-UI may be generated and stored in the user profile with AFJ D2, in addition to the first KAF-UI information.

[0097] As shown at 6 of FIG. 5, the AAnF may send to the AF the KAF-UI with an expiration time (e.g., an indication of an expiration time), along with an external ID (e.g., an external subscription ID), the SUPI, and / or a user status (e.g., whether the user is active or inactive with the subscription). The AAnF may send a reject response to the AF if a user is not authorized for the subscription and / or AF-based (e.g., AKMA- based) user specific authentication. If the AAnF returns a KAF that applies to multiple (e.g., all) users of the application, the AF may derive a KAF-UI for the particular user of the WTRU / subscription based on the user ID of that user (e.g., in a similar manner as the WTRU illustrated by 1 of FIG. 5).

[0098] As shown at 7 of FIG. 5, the AF may send a response message (e.g., at the application layer) to the WTRU that may be associated with the establishment of the application session. The application layer message used to transport one or more data elements associated with the application session may depend on the authentication protocol being used.

[0099] As shown at 8 of FIG. 5, the WTRU and the AF may perform mutual authentication using KAF-UI within a protocol (e.g., a TLS protocol), which may include one or more of a Generic Bootstrapping Architecture (GBA) digest, a TLS 1 .2 protocol, or a TLS 1 .3 protocol, for example.

[0100] As shown at 9 of FIG. 5, upon successful user specific authentication, the AF may request the UDM (e.g., directly or via NEF) to activate the user for the relevant subscription (e.g., by providing an external identifier associated with the subscription, such as a GPSI or an A-KID, an AFJD, a user ID, and / or an activation indication to the UDM). The AF may skip this operation if the user ID was already indicated as being active at 6. The UDM may update the subscription data to indicate the user ID as an active user for the subscription. The UDM may notify one or more subscribed network functions (e.g., an AMF, an SMF, and / or a PCF) of the change in the subscription data. As a result of the notification or change, an existing PDU session for the WTRU may be updated or released. For example, the notification from the UDM may instruct the SMF to release a PDU session, with a cause code indicating that the reason for releasing the PDU session is that the current user may not be permitted to send and receive data to and from a DNN / S-NSSAI combination associated with the PDU session. As another example, the notification from the UDM may provide QoS parameters (e.g., new QoS parameters) to the SMF for a PDU session, with one or more QoS rules (e.g., new QoS rules) based on the user identity. As yet another example, the notification from the UDM may instruct the AMF to disable SMS over an NAS, with a cause code indicating that the reason for disabling SMS over the NAS is that the current user may not be permitted to send and receive SMS. The notification from the UDM to the AMF may indicate that a user hasbecome active with the subscription. The WTRU may be informed by the network (e.g., by the AMF or the UDM) about the activation of a user ID. For example, the WTRU may be informed in an NAS message about a new user ID activation and / or an old user deactivation. The NAS message may be an NAS transport message. The NAS message may be a WTRU configuration update message. The UDM may inform the WTRU about the user ID activation / deactivation during a WTRU parameter update procedure such that the AMF may (e.g., transparently) send information related to the user ID activation / deactivation from the UDM to the WTRU. The UDM may request the UDR to update its data to indicate that a user ID is active for a subscription. The UDM may send a response message to the AF (e.g., directly or via an NEF) confirming the user ID activation in the subscription.

[0101] As shown at 10 of FIG. 5, the WTRU may determine that a user ID has been activated based on a message received from the network as described above or by completing a user specific authentication procedure with the AF.

[0102] As shown at 11 of FIG. 5, the WTRU may proceed with using a network service for an activated user ID. For example, the WTRU may establish a new PDU session, and the user ID may be used during the session establishment procedure. The WTRU may also use an existing PDU session that may have been modified by the network following the actions at 9.

[0103] If a KAF-UI (or KAF) expires, the AF may reject a user’s access to the WTRU (e.g., to an application on the WTRU). The AF may request a network device to deactivate the user using a request as described at 9 (e.g., with a deactivation indication). In such a case, the WTRU may attempt to access the application for that user again after a new round of primary authentication and / or with a new KAKMA / A-KID generated from a KAUSF. The AF may perform a refresh of the KAF-UI over an application layer in a protocol-specific manner (e.g., via a Ua* interface) to enable continued application access for the user.

[0104] The WTRU may detect or determine that a user may no longer access the WTRU. For example, the determination may occur if the WTRU is locked and / or after a certain amount of time has elapsed since any user activity. This determination or detection may trigger the WTRU to send a message or release a connection to the AF, which may indicate that the user is logged out of the WTRU. Upon determining that the user has been logged out of the WTRU and / or detecting that the WTRU has disconnected from the AF, the AF may ask a network device to deactivate the user as described above. In such a case, if the user was connected to one or more applications, the network (e.g., a UDM) may refrain from deactivating the user until the user is disconnected from all of the applications. The UDM may determine that the WTRU has been deactivated when requests to deactivate the user have been made by all applications to which the user was connected. The information about which applications are used by a user (e.g., a number of actively used applications) may be stored in a user identity profile (e.g., in the UDR), and such informationmay be updated by the UDM or the UDR after an (e.g., every) activation / deactivation request from the AF. The UDM or the UDR may keep track of the information to ensure that no more applications are in use, so that the UDM or the UDR may initiate a deactivation of the user as described herein.

[0105] An application layer protocol message (e.g., sent at 1, 7 and / or 8 of FIG. 5) corresponding to a Ua* interface may be enhanced to support AF-based user specific authentication. The following examples illustrate how a WTRU may transmit an A-KID and / or a user ID to an AF in a protocol specific message (e.g., which may be sent at 1 of FIG. 5). The following examples may also illustrate a response that may be sent by an AF (e.g., at 7 of FIG. 5) and / or how a KAF-UI may be used as part of a TLS-based authentication protocol (e.g., at 9 of FIG. 5).

[0106] When using shared key-based WTRU authentication with certificate-based AF authentication, a WTRU may indicate "3gpp-akma-ui" in a "User-Agent" HTTP header. An AF may reply with "3GPP- bootstrapping-akma-ui" within a WWW-Authenticate header field. The WTRU may respond to the AF with an authorization header field, where a digest may be inserted using a username that may include an A-KID and / or a user ID. The KAF-UI may be used by the AF as a password in digest calculation.

[0107] When using shared key-based mutual authentication between a WTRU and an AF (e.g., with TLS 1 .2 protocol), the WTRU may derive a TLS premaster secret based on a KAF-UI. A ClientKeyExchange message (e.g., including a PSK identity comprising "3GPP-AKMA-UI", an A-KID and / or a user ID) may be sent. The KAF-UI may be used by the AF as a user specific shared secret to derive the TLS premaster secret.

[0108] When using a shared key-based mutual authentication between a WTRU and an AF (e.g., with a TLS 1.3 protocol), the WTRU may include, as part of PSK identities in ClientHello, a prefix indicating a PSK-identity name space (e.g., "3GPP-AKMA-UI"), along with an A-KID and / or a user ID. The WTRU and an NAF may derive a TLS external PSK from a KAF-UI.

[0109] A user ID may be exchanged in a privacy-preserving form since the user ID may be exposed (e.g., during exchanges between a WTRU and an AF, between the WTRU and a network device, between the AF and a network device, etc.). A WTRU may derive a user temporary ID (U-TID) using a user ID as an input and one or more key derivation functions (KDFs) to conceal the user ID. For example, the WTRU may conceal a user ID according to U-TID = KDF (KEY, S), where KEY may represent an input key, and S may represent the user ID. The input key (KEY) may be any of a KAUSF, a KAKMA, a KAF, or a KAF-UI. If a KAUSF is used, the AAnF may invoke an AUSF for U-TID processing (e.g., given that the KAUSF may be stored at the AUSF).

[0110] AF based user specific authentication and activation based on subscription credentials may be performed with user ID privacy preservation. For example, at 1 of FIG. 5, the WTRU may send a messageto the AF to establish an application session by providing an A-KID, an indication of user specific authentication, and / or a U-TID. The U-TID may form part of the username of an A-KID* (e.g., the A-KID* may include the U-TID and the username portion of the A-KID), as follows: A-KID* = U-TID.A-KID = U- TID.RID.A-TID@MCC.MNC, where MCC and MNC may identify a home network of the WTRU.

[0111] At 3 of FIG. 5, the AAnF may extract the A-KID from the A-KID* to locate a corresponding SUPI (e.g., for a subscription). The AAnF may query the UDM and / or the UDR for a user identity profile linked to the subscription. The AAnF may verify whether the U-TID corresponds to a user ID that is authorized for the subscription. To resolve the user ID corresponding to the received U-TID and perform the authorization verification, the AAnF may verify if a user identity profile is already configured with the U-TID. If the user identity profile is not configured with the U-TID, for a (e.g., each) user ID linked to the subscription, the AAnF may generate a corresponding U-TID to locate a possible match with the received U-TID. The AAnF may use one or more of a KAUSF, a KAKMA, a KAF or a KAF-UI in the process depending on the KDF used for U-TID generation as described herein.

[0112] At 5 of FIG. 5, the AAnF may request the UDR (or the UDM) to store the U-TID along with other parameters. At 6 of FIG. 5, the AAnF may send the resolved user ID along with other parameters to the AF. The AAnF may send a reject response to the AF if the U-TID is not authorized (e.g., not found or not matching an authorized user ID).

[0113] The techniques described herein may allow for an AF-based user specific authentication and / or activation using 3GPP credentials. An AF may authenticate a user of a WTRU over an application layer (e.g., a user plane) using user credentials that may be generated based on an enhanced AKMA-based authentication mechanism (e.g., which may support authenticating a user on a WTRU based on network subscription credentials) and / or a primary authentication of the WTRU. An AAnF may be responsible for generating and / or maintaining network subscription-based user credentials for the AF, where a user identifier may be linked to a network subscription. The AF may request that a network (e.g., a core network) activate a user identifier linked to a subscription, following a successful user specific authentication on the WTRU with that subscription. The techniques described herein may enhance application layer authentication protocols as well as the privacy of a user.

[0114] Although features and elements described above are described in particular combinations, each feature or element may be used alone without the other features and elements of the preferred embodiments, or in various combinations with or without other features and elements. Although the implementations described herein may consider 3GPP specific protocols, it is understood that the implementations described herein are not restricted to this scenario and may be applicable to other wireless systems. For example, although the solutions described herein consider LTE, LTE-A, New Radio(NR) or 5G specific protocols, it is understood that the solutions described herein are not restricted to this scenario and are applicable to other wireless systems as well.

[0115] The processes described above may be implemented in a computer program, software, and / or firmware incorporated in a computer-readable medium for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted over wired and / or wireless connections) and / or computer-readable storage media. Examples of computer- readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as, but not limited to, internal hard disks and removable disks, magneto-optical media, and / or optical media such as compact disc (CD)-ROM disks, and / or digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, terminal, base station, RNC, and / or any host computer.

Claims

CLAIMS1 . A wireless transmit / receive unit (WTRU), comprising: a processor configured to: determine a key identifier of the WTRU via a primary authentication procedure; transmit a message associated with an application on the WTRU to an application server, wherein the message indicates at least the key identifier of the WTRU and an identifier of a user of the application on the WTRU; derive a key for the user based at least on the identifier of the user; and perform mutual authentication with the application server for the user based on the derived key.

2. The WTRU of claim 1 , wherein the key identifier of the WTRU determined via the primary authentication procedure uniquely identifies the WTRU, and wherein the key derived for the user uniquely identifies the user and the WTRU as a combination.

3. The WTRU of claim 1 or 2, wherein the processor is configured to derive the key for the user based further on an Authentication and Key Management for Applications (AKMA) anchor key.

4. The WTRU of any of claims 1 -3, wherein the key identifier of the WTRU is associated with a subscription of the WTRU.

5. The WTRU of any of claims 1 -4, wherein the message transmitted to the application server further indicates a request to perform a user-level authentication for the user.

6. The WTRU of any of claims 1 -5, wherein the processor is configured to perform the mutual authentication with the application server by using the key derived for the user as a shared secret between the WTRU and the application server.

7. The WTRU of any of claims 1 -6, wherein the message transmitted to the application server includes a request to establish an application session with the application server, and wherein the processor is further configured to receive a response from the application server regarding the request, the response including an indication to proceed with the mutual authentication.

8. The WTRU of any of claims 1 -7, wherein the processor is further configured to receive a message indicating that the user has been authenticated.

9. The WTRU of claim 8, wherein, in response to receiving the message indicating that the user has been authenticated, the processor is further configured to transmit a PDU session establishment or modification request comprising the user identifier to a network device.

10. The WTRU of any of claims 1 -9, wherein the processor is configured to perform the mutual authentication with the application server based on a transport layer security (TLS) protocol.11 . A method implemented by a wireless transmit / receive unit (WTRU), the method comprising: determining a key identifier of the WTRU via a primary authentication procedure; transmitting a message associated with an application on the WTRU to an application server, wherein the message indicates at least the key identifier of the WTRU and an identifier of a user of the application on the WTRU; deriving a key for the user based at least on the identifier of the user; and performing mutual authentication with the application server for the user based on the derived key.

12. The method of claim 11 , wherein the key identifier of the WTRU determined via the primary authentication procedure uniquely identifies the WTRU, and wherein the key derived for the user uniquely identifies the user and the WTRU as a combination.

13. The method of claim 11 or 12, wherein the key for the user is derived based further on an Authentication and Key Management for Applications (AKMA) anchor key.

14. The method of any of claims 11-13, wherein the key identifier of the WTRU is associated with a subscription of the WTRU.

15. The method of any of claims 11-14, wherein the message transmitted to the application server further indicates a request to perform a user-level authentication for the user.

16. The method of any of claims 11-15, wherein the mutual authentication with the application server is performed using the key derived for the user as a shared secret between the WTRU and the application server.

17. The method of any of claims 11-16, wherein the message transmitted to the application server includes a request to establish an application session with the application server, and wherein the method further comprises receiving a response from the application server regarding the request, the response including an indication to proceed with the mutual authentication.

18. The method of any of claims 11-17, further comprising receiving a message indicating that the user has been authenticated.

19. The method of claim 18, further comprising transmitting a PDU session establishment or modification request comprising the user identifier to a network device in response to receiving the message indicating that the user has been authenticated.

20. The method of any of claims 11-19, wherein the mutual authentication with the application server is performed based on a transport layer security (TLS) protocol.

21. A network device, comprising: a processor configured to: receive a message from an application server, wherein the message includes a request to authenticate a user of a wireless transmit / receive unit (WTRU), the message further including identification information of the user or the WTRU; determine, based at least on the message received from the application server, whether a subscription of the WTRU is authorized for authentication and key management for applications (AKMA) and whether the user is authorized to use the subscription; and based on a determination that the subscription of the WTRU is authorized for AKMA and that the user is authorized to use the subscription: generate a key for the user; and send the key to the application server.

22. The network device of claim 21 , wherein the message received from the application server includes at least one of an identifier of the user or an AKMA key identifier of the WTRU.

Images