User-centric trust authentication for wireless mobile networks

Abstract

Described herein are systems, methods, and / or instrumentalities associated with user-centric trust authentication. A wireless transmit / receive unit (WTRU) may transmit an authentication request to another device via a wireless communication network, wherein the authentication request may include an indication that the authentication request is for a user of the WTRU, and the authentication request may further include user credentials for one or more services available in the wireless communication network. In response to sending the authentication request to the other device, the WTRU may receive an authentication response via the wireless communication network, wherein the authentication response may include an indication of whether the user has been authenticated. If the authentication response indicates that the user has been authenticated, the WTRU may access the one or more services via the wireless communication network based on information included in the authentication response.

Description

USER-CENTRIC TRUST AUTHENTICATION FOR WIRELESS MOBILE NETWORKSCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefits of U.S. Provisional Patent Application No. 63 / 553,786, filed February 15, 2024, the contents of which are incorporated by reference herein.BACKGROUND

[0002] Existing authentication techniques for wireless communication system may be used to authenticate a wireless transmit / receive unit (WTRU) and build the trust for WTRU. These authentication techniques, however, cannot be used to establish a trust relationship between a user and a network, or between two network functions. Accordingly, user-level or user-centric trust authentication may be desired to enable trustworthy network access for individual users of a WTRU (e.g., including human users of the WTRU, devices connected to the WTRU, and / or applications running on the WTRU).SUMMARY

[0003] Described herein are systems, methods, and / or instrumentalities associated with user-level or user-centric trust authentication. According to embodiments of the present disclosure, a wireless transmit / receive unit (WTRU) may transmit an authentication request to another device via a wireless communication network, wherein the authentication request may include an indication that the authentication request is for a user of the WTRU, and the authentication request may further include credentials of the user for one or more services available in the wireless communication network. In response to sending the authentication request to the other device, the WTRU may receive an authentication response via the wireless communication network, wherein the authentication response may include an indication of whether the user has been authenticated. If the authentication response indicates that the user has been authenticated, the WTRU may access at least one of the one or more services via the wireless communication network based on information included in the authentication response.

[0004] In examples, the user of the WTRU may include a human user of the WTRU, a device connected to the WTRU and attempting to access the wireless communication network via the WTRU, or an application running on the WTRU and attempting to access the wireless communication network via the WTRU.

[0005] In examples, the authentication request may further include one or more identifiers that identify the user or the WTRU, and the credentials of the user may be specific to the one or more services. In examples, the authentication request may further indicate a service category or a service policy associated with the one or more services, and the authentication response received by the WTRU may indicate a service group associated with the service category or the service policy. In examples, the authentication response may further include credentials for accessing the service group, and the WTRU may include those credentials in a subsequent request to access a service made available via the wireless communication network.

[0006] In examples, the device that receives the authentication request may be a core network device of the wireless communication network or another WTRU in the wireless communication network. In examples, the WTRU may receive an indication from the core network device or the other WTRU to perform user-based authentication, and may transmit the authentication request in response to receiving the indication.

[0007] In examples, the authentication response may indicate an area in which user-based authentication is permitted or a periodicity for renewing the authentication request for the user.

[0008] According to embodiments of the present disclosure, a network device (e.g., a core network device) of a wireless communication network may receive an authentication request from a wireless transmit / receive unit (WTRU) via the wireless communication network, wherein the authentication request may include an indication that the authentication request is for a user of the WTRU, and the authentication request may further include credentials of the user for one or more services available in the wireless communication network. The network device may determine, based on the authentication request, whether the user is authorized to access the one or more services via the wireless communication network, and may transmit an authentication response to the WTRU via the wireless communication network, wherein the authentication response may include an indication of whether the user is authorized to access the one or more services. If the user is authorized to access the one or more services, the network may further include credentials for accessing the one or more services in the authentication response.BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

[0013] FIG. 2 illustrates an example of a security framework.

[0014] FIG. 3 illustrates example use cases for trust authentication.

[0015] FIG. 4 illustrates an example of a trust enabler framework.

[0016] FIG. 5 illustrates another example of a trust enabler framework.

[0017] FIG. 6 illustrates an example of an on-network trust enabler framework.

[0018] FIG. 7 illustrates an example of an off-network trust enabler framework.

[0019] FIG. 8 illustrates another example of an off-network trust enabler framework.

[0020] FIG. 9 illustrates an example of user-centric trust authentication.

[0021] FIG. 10 illustrates an example of WTRU-initiated user-centric trust authentication.

[0022] FIG. 11 illustrates an example of network-initiated user-centric trust authentication.

[0023] FIG. 12 illustrates an example of user-centric mutual authentication.

[0024] FIG. 13 illustrates an example of user-centric trust authentication for multiple WTRUs.

[0025] FIG. 14 illustrates an example procedure for WTRU-initiated user-centric trust authentication.

[0026] FIG. 15 illustrates an example procedure for network-initiated user-centric trust authentication.

[0027] FIG. 16 illustrates an example procedure for user-centric mutual authentication.

[0028] FIG. 17 illustrates an example procedure of user-centric trust authentication for multiple WTRUs.

[0029] FIG. 18 illustrates an example of WTRU registration followed by user-level registration.

[0030] FIG. 19 illustrates an example of user-level registration followed by WTRU registration.

[0031] FIG. 20 illustrates an example of integrating WTRU registration with user level registration.DETAILED DESCRIPTION

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

[0033] 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 wirelessusers. 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.

[0034] 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.

[0035] 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 gNB, 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 be appreciated that the base stations 114a, 114b can include any number of interconnected base stations and / or network elements.

[0036] 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.

[0037] 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).

[0038] 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).

[0039] 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).

[0040] 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).

[0041] 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, 102ccan 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 gNB).

[0042] 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.

[0043] 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.

[0044] 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 be utilizing 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.

[0045] 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.

[0046] 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.

[0047] 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.

[0048] 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.

[0049] 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 oneembodiment, 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.

[0050] 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.

[0051] 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 IEEE 802.11, for example.

[0052] 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).

[0053] 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 or more 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.

[0054] 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.

[0055] 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.

[0056] 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)).

[0057] 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.

[0058] 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 theWTRUs 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.

[0059] 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.

[0060] 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.

[0061] 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.

[0062] 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.

[0063] 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.

[0064] 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. In addition, 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.

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

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

[0067] 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.

[0068] 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.

[0069] 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.

[0070] 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 bycombining 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).

[0071] 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, and802.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).

[0072] 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 ST As in the BSS. The bandwidth of the primary channel can be set and / or limited by a STA, from among all ST As in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of802.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.

[0073] 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. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for802.11 ah is 6 MHz to 26 MHz depending on the country code.

[0074] 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.

[0075] The RAN 113 can include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 can include any number of gNBs while remaining consistent with an embodiment. The gNBs 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 gNBs 180a, 180b, 180c can implement MIMO technology. For example, gNBs 180a, 108b can utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 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 gNBs 180a, 180b, 180c can implement carrier aggregation technology. For example, the gNB 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 gNBs 180a, 180b, 180c can implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0076] The WTRUs 102a, 102b, 102c can communicate with gNBs 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 gNBs 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).

[0077] The gNBs 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 gNBs 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 gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c can communicate with / connect to gNBs 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 gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160csubstantially simultaneously. In the non-standalone configuration, eNode-Bs 160a, 160b, 160c can serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c can provide additional coverage and / or throughput for servicing WTRUs 102a, 102b, 102c.

[0078] Each of the gNBs 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 gNBs 180a, 180b, 180c can communicate with one another over an Xn interface.

[0079] 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.

[0080] The AMF 182a, 182b can be connected to one or more of the gNBs 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 162 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.

[0081] 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 of traffic 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.

[0082] The UPF 184a, 184b can be connected to one or more of the gNBs 180a, 180b, 180c in theRAN 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.

[0083] 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.

[0084] 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, gNB 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.

[0085] 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 performing testing using over-the-air wireless communications.

[0086] 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 morecomponents. 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.

[0087] A communication system (e.g., a 5G system (5GS)) may include a wireless transmit / receive unit (WTRU), a radio access network (RAN), and / or a core network. The design of such a communication system may be service-centric or service-based. The core network of the communication system (e.g., a 5G core network (5GC)) may follow a service-based architecture (SBA) and may include a variety of network functions (NFs) that may work together to fulfill and provide services to the RAN, the WTRU, and / or one or more application servers or service providers. The WTRU may interact with the RAN or 5GC via non-access stratum (NAS) and / or access stratum (AS) signaling.

[0088] A network function may access other network functions in a request / response mode or in a subscription / notification mode. Before two network functions (NFs) interact with each other, the NFs may register with a network repository function (NRF) to discover each other via the NRF. Among the network functions, an access and mobility management function (AMF) may manage a WTRU’s access to the network and the WTRU’s mobility. A session management function (SMF) may establish sessions between a WTRU and the core network. An authentication server function (AUSF) may authenticate a WTRU. A policy control function (PCF) may provide policy rules for other control plane network functions and / or a WTRU. The PCF may assign an identifier to a (e.g., each) created policy rule, which other control plane network functions and / or WTRUs may use to refer to the corresponding policy rule. A user plane function (UPF) may be a core network function in the data plane that may facilitate the monitoring, managing, controlling, and / or redirecting of user plane traffic flows (e.g., between a WTRU and an application function (AF)). A network exposure function (NEF) may enable access to control plane functions by entities such as network applications and / or AFs, which may be outside of the network or may not be in the same trusted domain.

[0089] A core network (e.g., 5GC) may provide data storage and / or analytics services through one or more functions (e.g., unified data management (UDM), unified data repository (UDR), unstructured data storage function (UDSF) and / or network data analytics function (NWDAF)). A communication system (e.g., a 5GS) may provide network slicing, which may be facilitated by a network slice selection function (NSSF).

[0090] A communication system may introduce one or more network functions (e.g., location management function (LMF)) to support location services. The LMF may calculate, determine, or verify a final location and / or a velocity estimation. The LMF may estimate an achieved accuracy based on location information from a target WTRU and / or a RAN node. After the LMF calculates the location of the target WTRU, other entities may access or query the location from the LMF through a serving AMF.

[0091] Although the aforementioned network functions may be defined as separate logical entities, a particular service scenario may use multiple network functions. For example, operations associated with a WTRU’s mobility may involve not only an AMF but also an AUSF and / or an SMF. For a type of network function, multiple instances of the network function may be instantiated, and an NRF may maintain information on each instantiated network function instance. With the emergence of edge computing, one or more network functions in a core network (e.g., UPF and / or NEF) may be deployed and resided in an edge network closer to and / or co-located with a RAN.

[0092] As illustrated in FIG. 2, security functions in a communication system (e.g., a 5GS) may cover multiple (e.g., four different) security domains within the system. These security domains may include security for network access between a WTRU and a RAN / core network, network domain security between a RAN and a core network (e.g., a 5GC), user domain security between a piece of mobile equipment (ME) and a universal subscriber identity module (USIM), and / or SBA domain security in a core network.

[0093] Network access security may be realized through network access authentication, message encryption, and / or message integrity protection. The network access authentication may include a primary authentication, a key agreement, a secondary authentication, etc.

[0094] The primary authentication and key agreement may facilitate mutual authentication between a WTRU and a network. The primary authentication and key agreement may enable agreed keying material (e.g., an anchor key KSEAF) at the network side and / or the WTRU side. The basis behind the primary authentication and key agreement may be that a same long-term key, K, corresponding to the WTRU may be maintained at a USIM and / or by the network. The anchor key KSEAF and other key materials (e.g., keys for encryption and integrity protection for NAS and AS signaling) may (e.g., independently and / or identically) be derived at the WTRU and / or the network sides. The anchor key KSEAF and other key materials may not be exchanged over the air. A mutual authentication may be established if the WTRU and / or the network recognize the same long-term key, K. Because the primary authentication may be (e.g., solely) based on the long-term key, K, it may not consider user-centric aspects (e.g., user behaviors) and may not authenticate or differentiate users from the same WTRU or different WTRUs.

[0095] The secondary authentication may provide security between a WTRU and an external data network (DN) as a part of session management. The secondary authentication may use an SMF to initiate and coordinate an authentication procedure between the WTRU and the DN (e.g., a data network authentication, authorization, and accounting (DN-AAA) server).

[0096] Zero trust architecture (ZTA) principles may be applicable to a communication system such as a 5GS. The applicability may include continuous security monitoring of NFs, which may be deployed in different environments and scenarios subject to potential errors and / or malicious attacks.

[0097] A blockchain system may include a permissionless blockchain system (e.g., Bitcoin, Ethereum, etc.), where a party or user may use and participate in the blockchain system without pre-granted permissions. A blockchain system may include a permissioned (e.g., permission-based) blockchain system, where access to the blockchain system may be permissioned, controlled and / or governed. A permissioned distributed ledger (PDL) may be an example of a permissioned blockchain system.

[0098] A PDL may be leveraged and integrated with a communication system such as a 5GS. PDL services or functions may be provided in a communication system such as a 5GS. The PDL functions may include a distributed ledger anchor function (DLAF), a distributed ledger repository function (DLRF), and / or a distributed ledger enabler (DLE). The DLAF and DLRF may be two control plane functions for a communication system, while the DLE may be a data plane function.

[0099] A PDL may be used to build a native self-sovereign identity (SSI) system under the constraints of telecommunication networks so that a user or a network node holding such an SSI may (e.g., seamlessly) access network services among different operators and service providers.

[0100] A communication system such as a cellular wireless system (e.g., a 5GS) may provide various security functions such as a primary authentication during registration, a secondary authentication during protocol data unit (PDU) session establishment, network slicing-specific authentication and authorization, network slicing admission control, and / or data plane encryption and integrity protection, etc. FIG. 3 illustrates two use cases in a mobile network involving trust authentication. In example use case 1 , userlevel trust between the users of a device (e.g., WTRU1) and a network may be established. In example use case 2, trust between users may be established to share services across devices (e.g., WTRU1 and WTRU2). Both use cases may lead to trust arrangements as described below.

[0101] In a first example of trust arrangement, user-level trust or user-centric trust may be established. As illustrated in example use case 1 in FIG. 3, WTRU1 may be shared by multiple users (e.g., Userl and User2) that may change based on location, time, or other factors. For example, a vehicle with an embedded WTRU may be used to offer connectivity and services to (e.g., all) passengers in the vehicle (e.g., the passengers may use the embedded WTRU to get access to a network). The passengers may have different behaviors, such as using different network functions, application functions, and / or services. A trust between the passengers and the network, referred to herein as a user-level trust or user-centric trust, may be established, which may lead to better authentication and service provisioning (e.g., for network access requests from the passengers). The network in this example use case may be a visited network or a home network (e.g., a public land mobile network (PLMN) or a non-public network (NPN)). Example use case 2 shown in FIG. 3 may also implement user-level trust when the users of WTRU1 attempt to access services provided by WTRU2.

[0102] As described above, a primary authentication may be used to authenticate a WTRU and build trust for the WTRU. Such an authentication technique, however, may not be able to establish a trust relationship between a user and a network, or between two NFs. Therefore, there is a need to establish user-level trust to enable trustworthy network access for different users.

[0103] In a second example of trust arrangement, distributed trust may be established. As illustrated by use case 2 of FIG. 3, WTRU2 may provide multiple services (e.g., computing service, communication relaying service, local functions, local application functions or services, etc.) and WTRU1 may request access to those services. As a service provider, WTRU2 may authenticate and determine whether to trust WTRU1 . As a service consumer, WTRU1 may also authenticate and determine whether to trust WTRU2. Trust (e.g., direct trust) between these two WTRUs (and / or between their respective users) may be referred to as distributed trust. Another form of distributed trust may be the trust (e.g., direct trust) between a roaming WTRU and a visited network, as shown in use case 1 of FIG. 3, which may be established without using a home network.

[0104] The primary authentication techniques described herein may be a centralized solution, which may use a home network and may inherit at least two shortcomings. First, the primary authentication techniques may not be able to build a direct trust relationship between two WTRUs or the respective users of those WTRUs. For example, if a home network becomes unavailable (e.g., due to outage, disaster, having too many concurrent users, etc.), the primary authentication may not be fulfilled. As a result, roaming users (e.g., use case 1 of FIG. 3) may not be able to access the home network as a visited network, or home users may not be able to access a RAN or an edge network via the home network. In contrast, the distributed trust establishment techniques described herein may not rely on a home network, so users may access services from other WTRUs or networks even if the home network is unavailable.

[0105] One or more technical issues may be addressed in order to implement the trust arrangements described herein (e.g., to enable distributed and / or user-centric trust). For example, a communication system (e.g., a 5GS) may support a USIM-based primary authentication between a WTRU and a core network, and / or secondary authentication between a WTRU and a DN, which may not consider or support user-based trust (e.g., user credentials). User-centric trust authentication may be used to authenticate different users including those associated with the same WTRU. The user-centric trust authentication may enable a mobile network to authenticate different users and / or identify unauthorized users. Ony the authorized users may access services via the mobile network and / or an AF, or services in a DN (e.g., via the mobile network), which may make the mobile network more secure.

[0106] When referred to herein, a device may be a WTRU (e.g., the two terms may be used interchangeably unless explicitly stated otherwise). When referred to herein, a network function (NF) mayinclude a processing function in a network (e.g., a 5GC), an AF, an edge application or service, a service provided by a device, an application provided at a device, a server or service in a data network, etc. When referred to herein, a user of a WTRU may be an entity (e.g., including a human being) that uses the WTRU (e.g., the user may be an entity outside or within the WTRU), an NF consumer, an application running on the WTRU (e.g., the application may attempt to access a mobile network via the WTRU), another WTRU connected to the WTRU and without an USIM, or a device that attempts to use a WTRU to get access to a mobile network. When referred to herein, a distributed ledger system (DLS) may be a system that includes or uses distributed ledgers or distributed repositories. The DLS may include or use permissioned distributed ledgers / repositories and / or permissionless distributed ledgers / repositories. The DLS may include a trustworthy data storage or repository function that may not be vulnerable to malicious attacks and / or may not fully depend on a centralized entity (e.g., a cloud server).

[0107] When referred to herein, distributed trust (DT) may refer to a direct trust relationship between two entities that may not rely on a centralized third party. The two entities may be a WTRU and a network, a user of a WTRU and a network, two users (e.g., each on a different WTRU), two WTRUs, two AFs, or two NFs. When referred to herein, user-level trust (ULT) or user-centric-trust (UCT) may refer to a trust relationship between different entities such as between a user of a WTRU and a network, between a user of a WTRU and another WTRU, between a user of a WTRU and a network function, between a user of a WTRU and another user of another WTRU, or between an NF consumer and an NF provider. The ULT may be established without using a centralized entity, in which case the ULT may also be distrusted. The terms ULT and UCT may be used interchangeably in this disclosure unless explicitly stated otherwise.

[0108] When referred to herein, a trusted device may be a device or WTRU trusted by other devices, by other entities / users, and / or by a cellular wireless system (e.g., a 6G system (6GS)). The terms trusted device and trusted WTRU may be used interchangeably in this disclosure unless explicitly stated otherwise. When referred to herein, an identifier of an entity may include a name, an alphanumeric identifier, or a network address of the entity (e.g., the entity may be a device / WTRU, a network function such as a 3GPP NF, a trust enabler client described herein, a trust enabler server described herein, an entity using a WTRU, etc.). For example, the identifier may be a 3GPP identifier, an IP address, a uniform resource locator (URL), a fully qualified domain name (FQDN), a blockchain address, etc. The identifier of an entity may convey access details regarding the entity, based on which other entities may access and / or interact with the entity.

[0109] When referred to herein, a distributed user identifier (DUID) may be a unique identifier for a user that may be created and owned by the user without using a third party. The DUID may be (e.g., independently) formed or established by the user using a DUID generation algorithm or function, whichmay be based on the unique and / or private information of the user (e.g., a private key, a password, user attributes or properties, and / or user biometrics). An entity (e.g., a device, an application on the device, a service provided at a device, and / or a NF) may create and possess a DUID.

[0110] When referred to herein, distributed verifiable user credentials (DVUC) may be credentials created or issued for a user. The DVUC may be verified or authenticated by a network device (e.g., in a distributed manner without contacting the party that has created or issued the DVUC). A user may have one or multiple sets of DVUC. If an unauthorized user seeks access to services from an entity (e.g., an NF), the user may present a set of DVUC to the entity for authentication and may establish ULT or DT with the entity (e.g., based on the DVUC). A new set of DVUC may replace an existing set of DVUC. A new set of DVUC may be dependent on one or multiple existing sets of DVUC.

[0111] When referred to herein, service-aware user credentials (SAUC) may be a type of DVUC that are associated with one or more target services (e.g., services belonging to a service category or complying with a specific service policy) to which the DVUC may be applicable. The SAUC may indicate the service category and / or service policy for the target service(s) associated with the SAUC. Examples of service categories may include but are not limited to 1) connectivity / communication services with certain communication service requirements (e.g., QoS such as an allowed bit rate); 2) computing services with certain computing requirements (e.g., computing delay, computing throughput such as the number of requests processed per second, etc.); 3) data services with certain data service requirements (e.g., data types, data processing types / algorithms, data volumes, data storage, etc.); 4) artificial intelligence (Al) services with certain Al service requirements (e.g., Al model types, Al model sizes, Al model accuracy, etc.); 5) proxying or relaying services (e.g., which may relay a service request from a user / WTRU to another user / WTRU or an NF). The service requirements may be described as a part of a service policy. A service policy may describe or include one or more service requirements and / or one or multiple service conditions. If all or a subset of the service conditions is satisfied, a service provider may provide a target service to a user / WTRU / NF / AF that requests the target service. The service conditions may include but are not limited to 1) the location of a target service; 2) the location of an entity that is allowed to access a target service; 3) the trustworthiness level (e.g., a threshold, a range, etc.) of a user / WTRU / NF / AF that is allowed to access a target service; 4) the date and / or time when a target service may be provided to a user / WTRU / NF / AF that requests the target service; 5) the priority of a service condition or a service policy. In examples, SAUC may include information that indicates methods for verifying the SAUC. For instance, the SAUC may allow users to choose a service provider without involving other parties (e.g., such as a PCF). The SAUC may allow service providers to (e.g., directly) check service policies without contactinganother party (e.g., an NF such as a PCF). The SAUC may enhance the efficiency of user-centric trust authentication and service access.

[0112] When referred to herein, service request credentials (SRC) may also be a type of DVUC. For example, after a set of DVUC or SAUC is presented by a user to a service provider and is authenticated by the service provider, the service provider may grant one or more services to the user. For a (e.g., each) granted service, the service provider may issue a respective set of SRC (e.g., the SRC may be different for different services), which the user may subsequently present to the service provider when accessing that specific service. The service provider may also issue SRC for a group of services (e.g., for a service group), which the user may subsequently present to the service provider when accessing that service(s) associated with the service group. The SRC may allow for finer granularity (e.g., per service request) for controlling the user-centric trust authentication and / or a user’s access to services.

[0113] When referred to herein, credentials (e.g., as a DVUC, SAUC or SRC) may include but are limited to certificates, keys, identifiers, and / or the like that may be used to identify and / or authenticate an entity (e.g., such as a user of a WTRU).

[0114] The design of a trust authentication mechanism may aim at avoiding a point of failure in the trust authentication, providing flexibility and applicability for different use cases (e.g., the use cases in FIG. 3), minimizing or reducing communication or computation overhead on devices, ensuring compatibility with a 3GPP architecture, and / or facilitating integration with 3GPP SA2 or SA6 procedures.

[0115] Using the techniques described herein, efficient user-level trust establishment may be accomplished without using a centralized party, and efficient distributed trust establishment may be accomplished without relying on a specific network (e.g., a home network).

[0116] FIG. 4 illustrates an example of a trust enabler framework for realizing distributed and / or userlevel trust in a wireless network. The framework may include one or more of the following logical entities.

[0117] The trust enabler framework may include a trust enabler client (TEC), which may be a component or entity located within a WTRU. The WTRU may have one or more TECs configured to serve different users or applications (e.g., a user may include an entity outside of the WTRU or an entity within the WTRU). The TEC may be implemented as a function, which may interact with a TES on behalf of one or multiple WTRUs and / or users. The WTRU may be regarded as a special user from the TEC’s perspective.

[0118] The trust enabler framework may include a trust enabler server (TES), which may be a server configured to provide one or more functions to the TECs and other NFs (e.g., such as user-centric trust authentication, function exposure, and / or an interface to 3GPP NFs). The TES may be deployed / hosted on an edge network device, a core network device, or another WTRU.

[0119] The trust enabler framework may include a service provider, which may be an entity or domain configured to provide services to a user or a WTRU. A TES may be a part of the service provider, and the two entities may trust each other. A TES may also be separated from (e.g., outside of) the service provider, in which case the service provider may trust the TES and the TES may perform user-centric trust authentication on behalf of the service provider. The service provider may provide services through one or more NFs. The TES may expose itself to the NFs or use the NFs for its own operations.

[0120] The trust enabler framework may perform one or more of the following functions. The trust enabler framework may perform user-centric trust authentication. For example, the users of a WTRU and the WTRU may trust a TEC hosted at the WTRU. The TEC may be registered to a TES (e.g., referred to as a registered-to TES) of a service provider. If the WTRU (or a user of the WTRU) accesses services from the serviced provider, the TEC at the WTRU may present a DVUC to the registered-to TES on behalf of a user. The registered-to TES may authenticate the user’s DVUC (e.g., using a distributed approach) and may establish a user-level trust with the user on behalf of the service provider. As a result of the DVUC authentication, if the service provider trusts the TES (e.g., the TES may be deployed as a standalone trusted NF in the service provider domain, or be deployed as a part of another trusted NF in the service provider domain), the TES may grant a set of services to the user on behalf of the service provider. The TES may generate one or multiple service request credentials (SRCs) for the user, each of which may correspond to and / or be used to access a type of granted service. The TES may send the authentication result to an NF (e.g., a security anchor function (SEAF) and / or a UDM), which may store the authentication result.

[0121] The trust enabler framework may expose a TES to other NFs (e.g., the TES may expose its functions to the other NFs / AFs). The other NFs / AFs may request access to the functionality and information provided by the TES. For example, an NF or an AF may discover if a WTRU and / or its users have successfully performed user-centric trust authentication with the TES. The NF / AF may configure and / or transmit information to the TES. The NF / AF may request the TES to initiate user-centric trust authentication for a specific WTRU and / or its users.

[0122] The trust enabler framework may leverage other NFs. For example, a TES may leverage and interact with other NFs. The TES may retrieve ULT-related policies from a PCF, which may be used during a user-centric trust authentication. The TES may retrieve ULT-related subscription data from a UDM, which may be used during a user-centric trust authentication. The TES may interact with a SEAF to determine if a WTRU has passed a primary authentication.

[0123] The trust enabler framework may be implemented as a network function (e.g., a 3GPP NF). FIG. 5 illustrates an example of a 3GPP SA2 that may integrate the user-centric enabler framework described herein with a 3GPP network system.

[0124] As shown in FIG. 5, a TES may be implemented as a control plane function, which may interact with other 3GPP NFs via a service-based interface (SBI). A TEC may be implemented as a function embedded at a WTRU. Interactions between the TEC and the TES may occur in the control plane via NAS signaling and / or relayed by an AMF. The interactions between the TEC and the TES may be through a data plane. A PDU session may be established between the TEC and the TES for transmitting messages between the TEC and the TES. The interactions between the TEC and the TES may be through an SBI. For example, the TEC and the TES may access each other’s services (e.g., functions) through the SBI. The TES may be integrated into an existing 3GPP NF (e.g., into a SEAF and / or an AMF).

[0125] The user-centric trust enabler framework described herein may be implemented as one or more service layer functions. FIGs. 6-8 illustrate example ways to implement the trust enabler framework. It should be noted that, although FIGs. 6-8 illustrate implementations within a 3GPP service enabler architecture layer (SEAL), the implementations may also be realized as a dedicated service enabler framework, which may interact with the SEAL.

[0126] FIG. 6 illustrates a 3GPP SA6 example for integrating the proposed trust enabler framework with a 3GPP SEAL on-network functional model. As shown in FIG. 6, a TEC may be implemented as a part of a SEAL client to serve one or multiple vertical application layer (VAL) clients. A TES may be implemented as a part of a SEAL server, which may be accessed by one or multiple VAL servers. A VAL client may be implemented for a user, which may use services provided by a VAL server. The VAL client may have a DUID and / or a DVUC, which may be presented by the VAL client to the TES via the TEC. The TES may perform user-centric trust authentication on the VAL client’s DVUC on behalf of the corresponding VAL server. The TES may interact with one or more NFs in a 3GPP network system via a network interface (e.g., an NEF).

[0127] FIG. 7 illustrates a 3GPP SA6 example for integrating the proposed trust enabler framework with a 3GPP SEAL off-network functional model (e.g., “off-network” may mean without involving a 3GPP network system). As shown in FIG. 7, WTRU2 may communicate with one or more SEAL servers and / or VAL servers. WTRU2 may provide services to WTRU1 . A VAL client at WTRU1 may request access to information and / or services provided by WTRU2. A TEC may be implemented as a part of a SEAL client at WTRU1 (e.g., such a SEAL client may serve and / or be accessed by one or multiple VAL clients). A TES may be implemented as a part of a SEAL client at WTRU2 (e.g., such a SEAL client may also serve and / or be accessed by one or multiple VAL clients). A VAL client user may use services provided by a VAL server.The VAL client at WTRU1 may present its DVUC to the TES via TEC, so that the TES may perform usercentric trust authentication based on the VAL client’s DVUC (e.g., on behalf of the corresponding VAL client at WTRU2).

[0128] FIG. 8 illustrates another 3GPP SA6 example for integrating the proposed trust enabler framework with a 3GPP SEAL off-network functional model. In this example, both WTRU1 and WTRU2 may have SEAL clients and VAL clients. TEC1 may be implemented as a part of a SEAL client at WTRU1 (e.g., such a SEAL client may serve and / or be accessed by one or multiple VAL clients). WTRU2 may have TEC2 as a part of a SEAL client on WTRU2 (e.g., such a SEAL client may also serve and / or be accessed by one or multiple VAL clients). TEC1 and TEC2 may exchange information such as information regarding the VAL clients being served and / or a user-centric trust authentication status (e.g., whether / when the TEC completed user-centric trust authorization with a specific TES, for which particular users, etc.).

[0129] User-centric trust authentication may be used to authenticate a WTRU and / or a user based on service-aware user credentials (SAUC) (e.g., user credentials associated with one or more specific services). A TEC may present such credentials on behalf of a WTRU and / or a user to a TES associated with a network device (or with another WTRU). After the WTRU and / or user is authenticated (e.g., after the SAUC are approved), the WTRU and / or user may start to use services provided by the network device (or by the other WTRU). The WTRU may have multiple users, all of which may be authenticated using the user-centric techniques described herein.

[0130] The user-centric trust authentication may include multiple (e.g., four) features that may be implemented based on the interactions between a TEC and a TES, for example, as illustrated in FIG. 9. It should be noted that even though a user is shown in FIG. 9 as being an entity outside of a WTRU, the user may also be an entity within the WTRU. A device (e.g., another WTRU) that uses the WTRU to get access to a communication network may also be considered as a user of the WTRU.

[0131] As shown in FIG. 9, user-centric trust authentication may be WTRU-initiated (e.g., an example is provided in FIG. 10), network-initiated (e.g., an example is provided in FIG. 11), mutual authentication (e.g., an example is provided in FIG. 12), or for multiple WTRUs (e.g., an example is provided in FIG. 13).

[0132] FIG. 10 shows an example of WTRU-initiated user-centric trust authentication. As shown in FIG. 10, a user of a target WTRU (or the target WTRU itself) may, at 1 , attempt to establish a user-centric trust relationship with a network (e.g., a wireless communication network) in order to access services from a service provider (e.g., from a network device or another WTRU) associated with the network. The user may be an entity outside of the target WTRU or an entity within the target WTRU. A device that uses the target WTRU to get access to the network (e.g., a 3GPP network) may also be a user of the target WTRU. At 2, a TEC on the target WTRU may send SAUC to a TES on behalf of the WTRU or the user. The SAUC may besent (e.g., over the wireless communication network) as part of an authentication request, a registration request or a service request, and may include a description of one or more services that the WTRU or the user may be requesting. The service description may indicate one or more service categories (e.g., a list of network functions) and / or one or more service policies (e.g., services may be accessible only at certain locations or times, via or by one or more specific WTRUs, etc.). The TES may authenticate the received SAUC using a distributed approach such as, for example, a distributed ledger system (DLS) (e.g., without using a centralized party). After the authentication, the TES may assign one or multiple service groups (SGs) to the WTRU and / or the user, for example, according to the service description included in the authenticated SAUC. A SG may include a set of network functions, a set of services, one or more network slices, etc. For an (e.g., each) assigned SG, the TES may generate corresponding service request credentials (SRC), which may be used by the WTRU and / or the user to access the SG. For example, the WTRU and / or the user may include the corresponding SRC for a SG in a subsequent access request for the SG (e.g., for one or more services in the SG), which may enable trust authentication at a more granular level (e.g., at a service request level). At 3, the TES may send information (e.g., as part of an authentication response) regarding one or more assigned SGs and / or their associated SRC to the TEC, the WTRU, and / or the user. At 4, the user may present the SRC associated with an assigned SG to access a service from the SG. More details about the operations at 2 and 3 will be provided with reference to FIG. 14.

[0133] FIG. 11 shows another example of network-initiated user-centric trust authentication. As shown in FIG. 11 , an application or a network may trigger user-centric trust authentication for a target WTRU or a user. The user may be an entity outside of the target WTRU or an entity within the target WTRU. A device that uses the target WTRU to get access to a communication network may also be a user of this WTRU. At 1 of FIG. 11 , a TES, an AF or an NF may send a request to a TEC to instruct it to perform user-centric trust authentication for one or multiple WTRUs / users. This request may trigger the TEC to perform WTRU- initiated user-centric trust authentication, which may be similar to the operations at 2-4 of FIG. 10. More details about the operations at 1 -3 of FIG. 11 will be described with reference to FIG. 15.

[0134] FIG. 12 shows an example of user-centric mutual authentication. As shown in FIG. 12, a WTRU or a user associated with the WTRU may authenticate a network (e.g., in addition to the network authenticating the WTRU / user, as illustrated in FIG. 10 and FIG. 11). Such authentication may be referred to herein as user-centric mutual authentication. At 1 of FIG. 12, a user of a target WTRU (or the target WTRU itself) may trigger the establishment of a user-centric trust relationship with a network, for example, to access services provided by a service provider (e.g., such as a network device or another WTRU). The user may be an entity outside of the target WTRU or an entity within the target WTRU. A device that usesthe target WTRU to get access to the communication network may also be a user of the WTRU. At 2 of FIG. 12, a TEC associated with the target WTRU may send (e.g., as part of an authentication request) SAUC associated with a user to a TES, which may authenticate the SAUC, assign SGs to the target WTRU or the user, and / or generate respective SRC for the SGs (e.g., for each SG). At 3 of FIG. 12, the TES may (e.g., for the purpose of mutual authentication) send service provider credentials (SPC) to the TEC (e.g., in addition to the SRC and the assigned SGs). The SPC may belong to the service provider that provides the services or service groups to the target WTRU or the user. Each SG may be associated with respective SPC or the same SPC may be applicable to multiple (e.g., all) assigned SGs. At 4 of FIG. 12, the TEC may authenticate the SPC and send an authentication confirmation to the TES. At 5 of FIG. 12, the target WTRU or the user may use the SRC to access services from the assigned SGs. The user-centric mutual authentication described herein may be initiated by the target WTRU or the user (e.g., as shown in FIG.12), or by a network device or an application (e.g., an application server). More details about the operations at 2-4 of FIG. 12 will be provided with reference to FIG. 16.

[0135] The SPC described herein may include information (e.g., statements, claims, certifications, etc.) that proves that a service provider may provide certain services. The SPC may be a type of DVUC or SAUC (e.g., a service provider may be considered a user). In examples, the SPC generated for a service provider may include one or more of the following pieces of information. The SPC may include an SPC-ID, which may be an identifier of the SPC. The SPC may include an SPC-lssuer-ID, which may be an identifier (e.g., a DUID) of the SPC issuer (e.g., some entity outside of the service provider) that may generate or issue the SPC for the service provider as denoted by an SPC-Owner-ID. The SPC may include an SPC- Owner-ID, which may be an identifier of the service provider that the SPC is generated for or belongs to. For mobile networks, the SPC-Owner-ID may be a PLMN-ID, an NPN-ID, or a DUID. If the SPC-Owner-ID is a DUID, the DUID may be generated based on the PLMN-ID of the mobile network. The SPC may include information (e.g., statements) indicating attributes, properties, and / or abilities of the service provider denoted by the SPC-Owner-ID. Examples of such information may include “the service provider supports 5G standalone,” “the service provider supports data storage service,” “the service provider supports satellite communications as a service,” “the service provider supports artificial intelligence as a service,” “the service provider supports roaming services with a list of other mobile operators (e.g., their PLMN-IDs),” and / or “the service provide supports digital twin and metaverse service.” For a (e.g., each) supported service, the service provider may have a contract that describes policies and / or charging rules for the service. The address (e.g., storage location) of the contract and / or the contract content may be included as a claim of the SPC. The SPC may include a public key of an SPC issuer. The SPC may include a signature of the SPC issuer, which may be generated based on the SPC issuer’s private key (e.g., using a hashing and / or a cryptography algorithm, which may also be included in the same SPC).

[0136] FIG. 13 shows an example of user-centric trust authentication for multiple WTRUs. As shown in FIG. 13, TEC1 and a TES may, at 1, perform user-centric trust authentication (e.g., the operations shown in FIGs. 10-12) to establish trust for Userl on WTRU1. The TES may (e.g., during the user-centric trust authentication) inform Userl that it may access assigned SGs via WTRU2. The TES may include WTRU2’s identifier in the SRC that may be generated by the TES and sent to Userl via TEC1 . Userl may be a device that uses WTRU1 and / or WTRU2 to get access to a communication network. At 2 of FIG. 13, Userl may switch to using WTRU2 and may leverage the same SRCs to access services from the network. Using this approach, TEC2 may not send Userl ’s SAUC to the TES and may skip user-centric trust authentication (e.g., as shown at 3 of FIG. 13). TEC2 may retrieve SRC from TEC1 , or TECI may push the SRC to TEC2. In examples, TEC2 may retrieve the identifier of SRC from TEC1 , or TECI may push the identifier of the same SRC to TEC2. At 4 of FIG. 13, User l may use previously established trust to access services via WTRU2 (e.g., TEC2 at WTRU2 may present the same SRC or the identifier of the same SRC to the TES).

[0137] With respect to WTRU-initiated user-centric trust authentication, when a requester WTRU and / or its user(s) need to build a trust relationship with a service provider (e.g., a network device or NF, another WTRU, etc.), the requester WTRU and / or its user may leverage a TEC to present its SAUC to a TES, which may be a part of a service provider. The TES may, on behalf of the service provider, verify and authenticate the SAUC in a distributed manner without contacting the entity that generated the SAUC. If the SAUC are authenticated, the trust relationship between the requester WTRU / user and the service provider may be established. As a result, the requester WTRU may be authorized to access services provided by the service provider. FIG. 14 illustrates an example procedure for user-centric trust authentication. As an example, NFy shown in FIG. 14 may be a network function (e.g., a SEAF), which may provide information about the primary authentication status of a requester WTRU.

[0138] The example procedure shown in FIG. 14 may include one or more of the following operations. A TEC at a requester WTRU may obtain or have been provisioned with the address of a TES (e.g., the TES may be hosted on a core network device). The TEC may obtain WTRU-SAUC for a user of the requester WTRU. The TEC may know its identifier (TEC-ID). The TEC may know the DUID of the requester WTRU (e.g., WTRU-DUID) and / or its users.

[0139] At 1 of FIG. 14, the requester WTRU or its user may trigger the TEC to send a user authentication request to the TES associated with a service provider (e.g., in order to access services provided by the service provider such as a visited network). The request may include one or more of the following parameters or information. The request may include a TEC-ID, which may be the identifier of the TEC. The request may include a WTRU-ID, which may be the identifier of the requester WTRU. Therequest may include a WTRU-DUID, which may be the DUID of the requester WTRU and / or the user. The request may include WTRU-SAUC, which may be the SAUC of the requester WTRU and / or the user to be authenticated by the TES (e.g., the SAUC may include one or more of the IDs described herein). If the WTRU-SAUC are successfully authenticated, the requester WTRU and / or the user may use services provided by the service provider. The request may include a WTRU-Public-Key, which may be the public key of the requester WTRU and / or the user. This key may not be included in the request if the TES has maintained the WTRU-Public-Key or is able to find it from other network devices or functions (e.g., based on the WTRU-ID or WTRU-DUID). The request may include a DLS-ID, which may be the identifier of a distributed ledger system (e.g., the distributed ledger system may store some public information that can be used to verify the SAUC). In examples, the DLS-ID may not be included in the request, and the TES may select a DLS at 3 of FIG. 14. The request may include an indication of a service category or a service policy for one or more services desired by the request WTRU or the user.

[0140] At 2 of FIG. 14, the TES may send a request to an NFy to check the primary authorization status of the requester WTRU. If the status shows that the requester WTRU has not successfully performed the primary authentication, the TES may reject the user authentication request from 1. In some examples, the operation at 2 may be omitted.

[0141] At 3 of FIG. 14, the TES may select an appropriate DLS according to the WTRU-DUID. The WTRU-DUID may indicate (e.g., via a field in the WTRU-DUID) the name, type, or identifier of an DLS, where public information (e.g., WTRU-Public-Key) corresponding to the WTRU-DUID may be stored and retrieved.

[0142] At 4 of FIG. 14, the TES may send a request to the DLS to retrieve public information about the user (e.g., from a storage location of the DLS). The location may be resolved by the TES (e.g., based on the WTRU-DUID) or by the DLS. In the latter case, the TES may include the WTRU-DUID in the request and the DLS may send the public information about the user (e.g., User-Public-Info) to the TES.

[0143] The User-Public-Info described herein may include the WTRU-DUID and / or the signature of the entity that has created and / or published the user public information to the DLS (e.g., the requester WTRU in the example of FIG. 14). At 5 of FIG. 14, the TES may verify if the signature of the User-Public-Info is valid, for example, using a public key of the requester WTRU. If the signature is valid, the content of the User-Public-Info including the WTRU-DUID may be deemed valid. If the WTRU-DUID is invalid, the TES may send a rejection to the TEC and may skip the other operations shown in FIG. 14.

[0144] At 6 of FIG. 14, the TES may, from the WTRU-SAUC, extract the identifier of the WTRU-SAUC creator that generated the WTRU-SAUC. The TES may then send a request to the DLS to retrieve the WTRU-SAUC creator information (e.g., WTRU-SAUC-Creator-Info) such as the creator’s public key, thecreator’s identifier, and / or the signature authentication scheme of the creator, which the DLS may find and send back to the TES.

[0145] The WTRU-SAUC-Creator-Info may include the public key of the WTRU-SAUC creator. At 7 of FIG. 14, the TES may use this public key to verify the WTRU-SAUC creator’s signature in the WTRU- SAUC. If the signature is valid, the WTRU-SAUC may be deemed valid, and the requested user authentication may be considered successful.

[0146] At 8 of FIG. 14, the TES may store the WTRU-SAUC. Subsequently, if the TEC sends another user authentication request to the TES, the TEC may send the identifier of the WTRU-SAUC (WTRU- SAUC-ID) (e.g., instead of the WTRU-SAUC itself), which may be used by the TES to find the stored WTRU-SAUC. This approach may reduce communication overhead from the TEC to the TES.

[0147] At 9 of FIG. 14, the TES may (e.g., after the WTRU-SAUC is verified) determine one or more service groups (SGs) for the requester denoted by the WTRU-DUID. The TES may do so based on service policies included in the verified WTRU-SAUC so that the TES may not need to retrieve the service policies from other network functions (e.g., from a PCF). For a (e.g., each) determined SG, the TES may create corresponding service request credentials (SRC). Such SRC may be presented by the requester (e.g., subsequent to receiving the SRC) to accesses services from the SG (e.g., the SRC may be used by the service provider to authenticate the requester). In examples, the TES may determine and assign multiple types of services for the requester (e.g., a WTRU or a user of the WTRU). The TES may create respective SRC for one or more types of services (e.g., for each type of services). The services may be provided by other NFs and / or WTRUs. After the WTRU-SAUC are verified and / or if the WTRU-SAUC are for the requester WTRU (e.g., not for the user), the TES may determine a maximum number of users (Max-User- Num) that may access the services (e.g., including the associated communication network) through the requester WTRU. The TES may obtain the Max-User-Num from the WTRU’s subscription data (e.g., provided by an NF or network device such as the UDM). An AF or an NF may pre-configure the Max-User- Num for the WTRU and notify the TES about the pre-config uration. The TES may send the Max-User-Num the TEC (e.g., at 13 of FIG. 14). The TEC may limit the number of users allowed to use the WTRU so that the number does not exceed the Max-User-Num (e.g., assuming the requester WTRU has one TEC). The TES may maintain a user authentication record, which may indicate how many different users (e.g., different DUIDs) from the same TEC and / or the same WTRU have been authenticated by the TES. If the number of already-authenticated users exceeds the Max-User-Num, the TES may not allow an (e.g., any) authentication request about a user from the same TEC (e.g., unless the TES increases the Max-User- Num).

[0148] The SRC described herein may include one or more of the following pieces of information. The SRC may include a Credential-Type, which may indicate whether or not the SRC are associated with a service request. The SRC may include an SRC-Creator, which may be the identifier of an SRC creator (e.g., the identifier may be a TES-ID, which may identify the TES). The SRC may include a SAUC-ID, which may be the identifier of the authorized SAUC that have led to the creation of this SRC (e.g., the identifier of the WTRU-SAUC transmitted at 1 of FIG. 14). The SRC may include an SG-ID, which may be the name or the identifier of the SG that are associated with the SRC. The SRC may include one or more SG-Services, which may indicate the respective names / types / identifiers of a list of services belonging to the SG denoted by SG-ID. The SRC may include a Service-Provider, which may be the identifier of the service provider that may provide the services described in SG-Services. In examples, the Service-Provider may be set to the identifier of a visited network (e.g., PLMN-ID) where the services in SG-Services may be hosted. The SRC may include a Service-Requester, which may be the identifier of the service requester that the SG is assigned to (e.g., a WTRU-DUID).

[0149] The SRC may include one or more WTRU-Anchors, which may be a list of WTRUs through which the Service-Requester may be allowed to present the SRC in order to access the services described in SG- Services. A user (e.g., as denoted by WTRU-DUID) may request access to the services via different WTRUs at different times. The TES may determine and select additional WTRUs (e.g., in addition to the WTRU-ID provided at 1) as the WTRU-Anchors for the user. In examples, multiple WTRU-IDs may be provided at 1 of FIG. 14, and the TES may check with other network functions (e.g., a SEAF, a UDM, etc.) about whether those WTRU-IDs may be used by the user to request services from a network after the usercentric trust authentication. Those WTRU-IDs may be included in WTRU-Anchors.

[0150] In examples, the SRC may include a set of service policies (e.g., constraints, rules, and / or policies) that may describe the conditions for a Service-Requester to use the SRC to access the services described by SG-Services. For example, a condition may indicate that the Service-Requestor can only access services using the SRC at a certain time, at a certain location, and / or from a certain WTRU anchor.

[0151] The SRC may include an SRC-Expiration-Time, which may be the expiration time of the SRC. For example, at the expiration of the SRC-Expiration-Time, the SRC may be regarded as expired or invalid, and the Service-Requestor may no longer use the SRC to access SG-Services.

[0152] The SRC may include an SRC-Signature-Scheme, which may be the scheme used to generate an SRC-Signature and / or the scheme used to verify the SRC-Signature.

[0153] The SRC may include an SRC-Signature, which may be the signature of the SRC that the TES may generate using the scheme described in SRC-Signature-Scheme (e.g., generated using the TES’s private key).

[0154] At 10 of FIG. 14, the TES may (e.g., if the WTRU-SAUC is valid) generate a User Authentication Record (UAR), which may include one or more of the following. The UAR may include a WTRU-ID, which may be the identifier of the requester WTRU. The UAR may include a TEC-ID, which may be the identifier of the TEC. The UAR may include a TES-ID, which may be the identifier of the TES. The UAR may include a WTRU-DUID, which may be the DUID of the requester WTRU and / or its user. The UAR may include a SAUC-ID, which may be the identifier of the verified SAUC. The UAR may include one or more SGs, which may be a list of SGs assigned and determined by the TES. The UAR may include an SRC-ID, which may be the identifier of the generated SRC.

[0155] At 11 of FIG. 14, the TES may store the UAR in the DLS or other distributed data repositories.

[0156] At 12 of FIG. 14, the TES may send a user authentication notification (e.g., comprising the UAR) to NFy and / or other network functions (e.g., a UDSF).

[0157] At 13 of FIG. 14, the TES may send a user authentication response to the TEC. In examples, the response may include a WTRU-DUID (e.g., for which a WTRU-SAUC has been authenticated as valid), the SGs determined at 9, and / or one or more SRCs. In examples, the response may include a UAR and / or one or more SRCs.

[0158] At 14 of FIG. 14, the requester WTRU and / or its users may start to access services from the service provider (e.g., an NF or another WTRU) using the SRC(s) received from 13. The requester WTRU or its users may send a service request including the SRC(s) to the service provider for accessing the services.

[0159] FIG. 15 illustrates an example of network-initiated user-centric trust authentication. As shown in FIG. 15, a User-Centric Trust Authentication Initiator (UCTAI) may trigger user authorization for a requester WTRU and / or its user(s). The UCTAI may be an AF, an NF, or a network device. The UCTAI may leverage UCT authentication function / service provided by a TES to authenticate a target WTRU and / or its user(s). In an example, an AF may know that a user is currently attempting to access services in a network from a requester WTRU, but the user may not have been authorized, or a previous authorization may have expired. As a result, the AF may act as the UCTAI and request the TES to authenticate this user. In examples, this operation may take place if the UCTAI receives a service request from an unauthorized requester WTRU and / or an unauthorized user.

[0160] At 1 of FIG. 15, the UCTAI may determine to perform user authentication for the requester WTRU and / or its user(s). The UCTAI may be a function on another WTRU providing services to the requester WTRU and / or its user(s). The UCTAI may send a user authentication notification to the TES, which may include one or more of the following pieces of information. The authorization notification may include a WTRU-ID, which may be an identifier of the requester WTRU. The authorization notification may include aWTRU-DUID, which may identify the requester WTRU and one or more users of the requester WTRU. The WTRU-DUID may include a list of DUIDs (e.g., one for each user). The authorization notification may include a UCTAI-ID, which may be the identifier of the UCTAI (e.g., an AF identifier, an NF identifier, etc.).

[0161] At 2 of FIG. 15, the TES may receive the notification from 1. The TES may check if the UCTAI is allowed to trigger UCT authentication for the requester WTRU and / or its user(s) (e.g., based on policies and subscription data of the requester WTRU and / or its user(s), which the TES may retrieve from other NFs such as a PCF and / or a UDM). If the UCTAI is not allowed to trigger the UCT authentication, the TES may send a rejection response to the UCTAI, and other authentication related actions / operations may be skipped. If the UCTAI is allowed to trigger the UCT authentication, the TES may use the WTRU-ID and / or WTRU-DUID included in the notification to find a corresponding TEC (e.g., which may be hosted on the requester WTRU).

[0162] At 3 of FIG. 15, the TES may determine one or more SAUC requirements (SAUC-REQ) for the requester WTRU according to the WTRU-DUID and / or policies that the TES may retrieve from a network device (e.g., the PCF). For example, SAUC-REQ may specify a SAUC-Type (e.g., SAUC for a service consumer), which may indicate the type of SAUC that the TEC may send at 6 below.

[0163] At 4 of FIG. 15, the TES may send a user authentication notification to the TEC, which may include one or more of the following pieces of information. The authorization notification may include a WTRU-ID, which may be received at 1. The authorization notification may include a WTRU-DUID, which may be received at 1. The authorization notification may include a UCTAI-ID, which may be received at 1. The authorization notification may include one or more SAUC-REQ, which may be determined at 3. The authorization notification may include a TES-ID, which may be the identifier of the TES for receiving a user authentication request at 6.

[0164] In examples, the UCTAI may (e.g., as an alternative approach to the operations at 1-4 of FIG. 15) send the same user authentication notification described at 4 to the requester WTRU directly (e.g., using 3GPP NAS signaling, data plane signaling, or SBI-based messaging). The requester WTRU may then inform its TEC to execute 5 and / or the other operations described below.

[0165] At 5 of FIG. 15, the TEC may receive the notification from 4. The TEC may determine if the UCTAI is allowed to trigger UCT authentication. If the UCTAI is not allowed to trigger the UCT authentication, the TEC may send a rejection response to the TES and / or the UCTAI, and other authentication related actions / operations may be skipped. In examples, the TEC may provide the received user authentication notification to the corresponding user (e.g., as indicated by WTRU-DUID at 4) for the user’s approval. The user may approve the user authentication notification and send an approve message to the TEC. In response, the TEC may use the WTRU-DUID and / or the WTRU-ID included in thenotification to find (or request from the requester WTRU and / or its users) the appropriate SAUC that meets the requirements described by SAUC-REQ.

[0166] At 6 of FIG. 15, operations similar to 1 of FIG. 14 may be performed. A user authentication request at 6 may include the identifier of the UCTAI (i.e., UCTAI-ID).

[0167] At 7 of FIG. 15, operations similar to those shown by 2-12 of FIG. 14 may be performed and a UAR may be generated as a result.

[0168] At 8 of FIG. 15, operations similar to 13 of FIG. 14 may be performed.

[0169] At 9 of FIG. 15, the TES may send a user authentication confirmation to the UCTAI (e.g., as denoted by UCTAI-ID), which may include the UAR generated at 7.

[0170] At 10 of FIG. 15, operations similar to 14 of FIG. 14 may be performed. If the UCTAI is a function at another WTRU providing services to the requester WTRU, the requester WTRU and / or its user(s) may also send a service request including relevant SRC to the other WTRU.

[0171] FIG. 16 illustrates an example procedure for user-centric mutual authentication, with which a requester WTRU (as a consumer) and a service provider (e.g., NFs in a mobile network, a DN, or on another WTRU) may leverage the interactions between a TEC and a TES to authenticate each other (e.g., directly without using a centralized third party). In the example of FIG. 16, the TEC may be a part of the requester WTRU, and the two entities (e.g., the TEC and the requester WTRU) may trust each other. Further, the TES may be a part of the service provider and may be trusted by the service provider.

[0172] At 1 FIG. 16, operations similar to 1 of FIG. 14 may be performed. A user authentication request sent during the operations may include a parameter (e.g., Mutual-Auth-REQ) that may indicate that the WTRU, a user of the WTRU, and / or the TEC may desire to authenticate the network that provides services to the WTRU / user / TEC. The request may also indicate the type of network credentials that the TES may send to the TEC at 3.

[0173] At 2 of FIG. 16, operations similar to those at 2-1 O of FIG. 14 may be performed. For example, the TES may authenticate WTRU-SAUC at 2 of FIG. 16.

[0174] At 3 of FIG. 16, the TES may send a user authentication response to the TEC. This response may include one or more of a WTRU-DUID, a list of SGs, an SRC, a UAR, and / or an SPC, similar to that sent at 13 of FIG. 14. The response may also include SPC that meet the conditions described in the Mutual-Auth-REQ received at 1.

[0175] At 4 of FIG. 16, the TEC may authenticate the SPC included in the user authentication response from the TES. The SPC may include the SPC issuer’s signature, and the TEC may authenticate the SPC by verifying if the signature is indeed from the SPC issuer. For this purpose, the TEC may retrieve the SPCissuer’s public key and other related information (e.g., the scheme that the SPC issuer may have used to generate the signature) from a DLS or other distributed entities.

[0176] At 5 of FIG. 16, the TEC may send a user authentication confirmation to the TES. If the SPC was not authenticated at 4, this confirmation may include an “Invalid SPC” indication indicating that the SPC is invalid or cannot be authenticated. Otherwise, the confirmation may include a “Valid SPC” indication confirming the successful mutual authentication.

[0177] At 6 of FIG. 16, the TES may add an SPC-ID (e.g., the identifier of the SPC authenticated by the TEC) to the generated UAR.

[0178] At 7 of FIG. 16, operations similar to those at 11 of FIG. 14 may be performed.

[0179] At 8 of FIG. 16, operations similar to those at 12 of FIG. 14 may be performed.

[0180] At 9 of FIG. 16, operations similar to those at 14 of FIG. 14 may be performed.

[0181] Established trust for a user based on authorized SAUC may enable the user to use multipleWTRUs at different times and / or locations. This approach may avoid having the user present the same SAUC to a TES from different WTRUs. FIG. 17 illustrates an example procedure for user-centric trust authentication for multiple WTRUs, where Userl may use WTRU1 at time T1 and switch to use WTRU2 at time T2. The example procedure may include one or more of the following operations.

[0182] At 1 of FIG. 17, operations similar to 1 of FIG. 14 may be performed. A user authentication request sent during the operations may include one or multiple of the following parameters. The user authentication request may include a Userl -DUID, which may be the DUID of Userl . The user authentication request may include a WTRU2-ID, which may be the identifier of WTRU2. WTRU1 or TEC1 may obtain WTRU2-ID via various approaches. In examples, WTRU1 / TEC1 may discover WTRU2-ID through direct device discovery (e.g., as a part of proximity service). In examples, TEC1 may be configured with the WTRU2-ID when TEC1 is registered to the TES. In examples, WTRU2-ID may be pre-configured in WTRU1 / TEC1 or may be configured via a device management function.

[0183] The user authentication request sent at 1 of FIG. 17 may include a WTRU2-DUID, which may be the DUID of WTRU2. WTRU1 or TECI may obtain WTRU2-DUID via various approaches. In examples, TEC1 may discover WTRU2-DUID through direct device discovery (e.g., as a part of proximity service). In examples, TEC1 may be configured with the WTRU2-DUID when TEC1 is registered to the TES. In examples, WTRU2-DUID may be pre-configured in WTRU1 / TEC1 or may be configured via a device management function.

[0184] The user authentication request sent at 1 of FIG. 17 may include a TEC2-ID, which may be the identifier of TEC2. WTRU1 or TEC1 may obtain TEC2-ID via various approaches. In examples, TEC1 maydiscover the TEC2-ID through direct device discovery (e.g., as a part of proximity service. In examples, TEC1 may be configured with the TEC2-ID when TEC1 is registered to the TES. In examples, TEC2-ID may be pre-configured in WTRU1 / TEC1 or may be configured via a device management function.

[0185] At 2 of FIG. 17, operations similar to those at 2-12 of FIG. 14 may be performed. The TES may select WTRU2 and / or TEC2, which Userl may use in the future, if WTRU2 / TEC2 were not included at 1 . For example, the TES may check Userl ’s subscription data (e.g., stored on a UDM), which may indicate a list of subscribed WTRUs that Userl is allowed to use. The TES may use the respective WTRU-IDs of these subscribed WTRUs to find the corresponding TEC for each subscribed WTRU (e.g., assuming that each TEC has been registered to the TES). If WTRU2-ID, WTRU2-DUID, and TEC2-ID were provided at 1 , the TES may not select additional WTRUs / TECs for Userl . In examples, before 3 and after 2, the TES may send the list of selected WTRUs (e.g., WTRU2-ID or WTRU2-DUID) to TEC1, which may provide the list to Userl for Userl ’s approval. If Userl approves the list, TEC1 may send a confirmation to the TES, which may continue to perform the operations described below. If Userl does not approve the list, TEC1 may send a “Selected WTRUs Not Approved by Userl” to the TES, which may not contact WTRU2 / REC2 and may perform (e.g., only perform) 6 and 7 of FIG. 17.

[0186] At 3 of FIG. 17, the TES may send a user notification to TEC2. This user notification may include one or more of the following parameters. The user notification may include a Userl -DUID, which may be the DUID of Userl . The user notification may include a TEC1-ID, which may be the identifier of TEC1. The user notification may include a WTRU1-DUID, which may be the DUID of WTRU1. The user notification may include a WTRU1 -ID, which may be the 3GPP identifier of WTRU1. The user notification may include a Userl -SRC-ID, which may be the identifier of the SRC that the TES generated for Userl as part of operation at 2.

[0187] At 4 of FIG. 17, TEC2 may verify User1-DUID as received from step 3. According to User1-SRC- ID as received from step 3, TEC2 may retrieve the corresponding SRC of Userl from TEC1 if TEC1 has stored it locally or from the TES. This step is similar to step 5 in Figure 13. If Userl -DUID is valid, TEC2 / WTRU2 may accept Userl to use WTRU2 optionally according to some local policies.

[0188] At 5 of FIG. 17, TEC2 may send a user confirmation to the TES indicating if TEC2 / WTRU2 accepts Userl to use WTRU2.

[0189] At 6 of FIG. 17, operations similar to those at 13 of FIG. 14 may be performed. A user authentication response sent during the operations may include one or more of the following parameters. The user authentication response may include a TEC2-ID, which may be the identifier of TEC2. The user authentication response may include a WTRU2-ID, which may be the identifier of WTRU2. The user authentication response may include a WTRU2-DUID, which may be the DUID of WTRU2.

[0190] At 7 of FIG. 17, the TES may send a user authentication notification to one or multiple services provided by a network, which Userl may access. This user authorization notification may include the same (e.g., substantially similar) information as the user authentication response sent at 6 of FIG. 17.

[0191] At 8 of FIG. 17, Userl may (e.g., after some time of using WTRU1) switch to using WTRU2. Since Userl may have been authenticated to use WTRU2 and TEC2 may know this via the operations at 3, TEC2 may not initiate user-centric trust authentication for Userl . TEC2 may send a service request to the services at the Network. The service request may include one or more of the following parameters. The service request may include a TEC2-ID, which may be the identifier of TEC2. The service request may include a WTRU2-DUID, which may be the DUID of WTRU2. The service request may include a WTRU2- ID, which may be the identifier of WTRU2. The service request may include a Use1-SRC-ID, which may be the identifier of the SRC that the TES generated for Userl as part of the operation at 2. If TEC2 has retrieved the corresponding SRC at 4 from TEC1 or the TES, Use1-SRC-ID may include the SRC. The service request may include a Userl -DUID, which may be the DUID of Userl . The service request may include a Userl -DUID-Signature, which may be the signature of User1-DUID. In examples, this signature may be generated by real Userl using its private key over Userl -DUID.

[0192] After receiving the service request, the Services at Network may check if Userl -DUID-Signature was generated by real Userl using Userl ’s public key. The Services may check if the information provided at 8 matches the information received at 7. If the information matches, the requested services may be provided to Userl via WTRU2.

[0193] User-level registration may be performed in a cellular communication network (e.g., a 5G or 6G network). The techniques described herein for user-centric trust authentication (e.g., WTRU-initiated usercentric trust authentication) may be implemented via a cellular communication network (e.g., 5G or 6G network) in several ways. One or more TEC functions may be embedded in a WTRU. One or more TES functions may be implemented as a part of an AMF. The NFy described herein may be a SEAF. WTRU registration based on primary authentication and WTRU subscription data may be regarded as subscription-level registration. User-centric trust authentication may be used to realize user-level registration (ULR) for a WTRU and / or its user to a cellular network. WTRU registration and ULR may be jointly implemented in (but not limited to) one or more of the following ways.

[0194] In an example, WTRU registration may be followed with ULR, as illustrated by FIG. 18, in which a WTRU may perform WTRU registration with an AMF and the AMF may instruct the WTRU to perform ULR.

[0195] In an example, ULR may be followed with WTRU registration, as illustrated by FIG. 19, in which a WTRU may perform ULR with an AMF, which may be followed by WTRU registration.

[0196] In an example, WTRU registration and ULR may be integrated, as illustrated by FIG. 20, in which a WTRU may use a registration request to trigger both WTRU registration and ULR with an AMF.

[0197] FIG. 18 illustrates an example of performing WTRU registration followed by ULR, which may include one or more of the following operations.

[0198] At 1 of FIG. 18, a WTRU may perform a WTRU registration, which may be based on primary authentication and interactions among several NFs such as an AMF, a SEAF, and a UDM.

[0199] At 2 of FIG. 18, if the primary authentication is successful and WTRU registration is accepted, the AMF may send a registration accept message to the WTRU. This message may include one or more of the following parameters related to ULR. The message may include a ULRIndicator, which may indicate (e.g., via ULRIndicator = “TRUE”) that WTRU may perform ULR using credentials supported by the AMF (e.g., as indicated in a supported credential type (SGT)). The message may include an SGT, which may indicate the type of credentials that the AMF may support for ULR.

[0200] At 3 of FIG. 18, the WTRU may indicate the SGT to its user(s). The user(s) may prepare its DUID and / or SAUC matching the SGT. An example of a SGT may be “Credential issued by any of the following Mobile Operators: Mobile Operator A, Mobile Operator B, etc.” As another example, the SCT may be “Driver license credential,” “Employment credential,” “Membership with an Organization,” etc.

[0201] At 4 of FIG. 18, the WTRU may receive the SAUC and the DUID of the user(s).

[0202] At 5 of FIG. 18, the WTRU may send a ULR request to the AMF. The ULR request may include one or more of the following parameters. The ULR request may include a RegLevel, which may indicate that the ULR is a user-level registration. The ULR request may include a SAUC, which may be the user’s SAUC matching the SCT. The ULR request may include a DUID, which may be the user’s DUID. The ULR request may include a DLS-ID, which may be the same as the DLS-ID provided at 1 of FIG. 14.

[0203] At 6 of FIG. 18, the AMF may receive the ULR request and may perform user-centric trust authentication (e.g., similar to 2-12 of FIG. 14). The AMF may leverage a TES to perform the user-centric trust authentication (e.g., similar to 2-12 of FIG. 14). A UAR may be created as a result of the user-centric trust authentication. The AMF (or the TES that the AMF may have leveraged) may determine one or more of the following parameters for the WTRU.

[0204] The AMF may determine an AcceptedRegistrationLevel, which may indicate the registration level accepted (e.g., user-level registration). The AMF may determine a time duration (e.g., indicated by UserLevelPeriodicalRegistrationUpdateTimer), which may indicate a time period for the WTRU to perform periodical ULRs. This timer may be the same as or different than the timer used for periodic WTRU registrations. The AMF may determine a ULRArea, which may indicate location-related areas. If WTRU moves to these areas (e.g., out of state or out of country) or moves out of these areas (e.g., the user’shome), the WTRU may perform periodic ULR. In examples, ULRArea may be set to one or multiple specific service areas. The AMF may determine a NolILRArea, which may indicate location-related areas. If the WTRU moves to these areas (e.g., the user’s home), the WTRU may not perform periodic ULR. In examples, NoULRArea may be set to one or multiple specific service areas.

[0205] At 7 of FIG. 18, the AMF may send the user’s SAUC and / or DUID to a UDM and associate them with the WTRU’s identifier (e.g., SUPI, SUCI, GUTI, etc.). The AMF may also send ULRArea and / or NoULRArea to the UDM. The AMF may also store the user’s SAUC and / or DUID, and the WTRU’s identifier.

[0206] At 8 of FIG. 18, the AMF may send a ULR accept message to the WTRU. This message may include one or more of the following parameters. The message may include an AcceptedRegistrationLevel, as determined at 6. The message may include a UserLevelPeriodicalRegistrationUpdateTimer, as determined at 6. The message may include a ULRArea, as determined at 6. The message may include an NoULRArea, as determined at 6. The message may include an UAR, which may be a user authentication record as determined at 6. The message may include an SG-Services, which indicates a list of service groups that the AMF may have created for and assigned to the WTRU / user at 6. The message may include an SRC, which may include service request credentials that the AMF may have generated for the WTRU / user at 6 or that the AMF may receive from a TES for the WTRU / user at 6. The WTRU / user may use SRC to access services described in SG-Services.

[0207] At 9 of FIG. 18, the WTRU may send a registration complete message to the AMF indicating the completion of WTRU registration and ULR registration. The WTRU / user may use an SRC to access services as described in SG-Services from the network. The WTRU / user may re-perform the ULR according to conditions described in UserLevelPeriodicalRegistrationUpdateTimer and / or ULRArea.

[0208] FIG. 19 illustrates an example procedure for performing ULR followed with WTRU registration, which may include one or more of the following operations.

[0209] At 1 of FIG. 19, operations similar to those at 5 of FIG. 18 may be performed. A WTRU may send a ULR request to an AMF, which may be triggered by a user. The user may have passed its SAUC and / or DUID to the WTRU.

[0210] At 2 of FIG. 19, operations similar to those at 6 of FIG. 18 may be performed.

[0211] At 3 of FIG. 19, operations similar to those at 7 of FIG. 18 may be performed.

[0212] At 4 of FIG. 19, operations similar to 8 of FIG. 18 may be performed. This ULR accept may also contain WTRUReglndicator (= “TRUE”) to request WTRU to perform WTRU registration in subsequent steps.

[0213] At 5 of FIG. 19. operations similar to those at 1 of FIG. 18 may be performed. The AM F may adjust the values of one or more of an SRC, SG-Services, ULRArea, NolILRArea, or UserLevelPeriodicRegistrationUpdateTimer determined at 2 based on the WTRU’s registration result. The AMF may send the adjusted values to the UDM.

[0214] At 6 of FIG. 19, the AMF may send a registration accept message to the WTRU. This message may include one or more of an SRC, SG-Services, ULRArea, NoULRArea, or UserLevelPeriodicRegistrationUpdateTimer, if they were adjusted at 5.

[0215] At 7 of FIG. 19, operations similar to those at 9 of FIG. 18 may be performed. The WTRU may use an SRC to access services as described in SG-Services from the network. The WTRU may re-perform the ULR according to conditions described in UserLevelPeriodicalRegistrationUpdateTimer and / or ULRArea.

[0216] FIG. 20 illustrates an example procedure for performing integrated ULR registration and WTRU registration, which may include one or more of the following operations.

[0217] At 1 of FIG. 20, a WTRU may send a registration request to an AMF (e.g., the registration request may be triggered by a user of the WTRU, who may have passed its SAUC and / or DUID to the WTRU). This registration request may include one or more of the following (e.g., similar to those described at 5 of FIG. 18). The registration request may include a RegLevel, which may Indicate that the registration request is associated with both WTRU registration and ULR registration. The registration request may include a SAUC, which may be same as described at 5 of FIG. 18. The registration request may include a DUID, which may be same as described at 5 of FIG. 18. The registration request may include a DLS-ID, which may be same as described at 5 of FIG. 18.

[0218] At 2 of FIG. 20, the AMF may perform operations associated with WTRU registration and / or primary authentication, which may be based on interactions of multiple NFs such as an AMF, a SEAF, and / or a UDM.

[0219] At 3 of FIG. 20, operations similar to those at 6 of FIG. 18 may be performed. Dependent on the policies that the AMF may retrieve from a PCF, the AMF may or may not perform user-centric trust authentication if the primary authentication is not successful.

[0220] In examples, the AMF may swap the operations at 2 with those at 3 (e.g., the AMF may perform user-centric trust authentication first). If the user-centric trust authentication is not successful, the AMF may continue to perform the WTRU registration.

[0221] At 4 of FIG. 20, operations similar to those at 7 of FIG. 18 may be performed.

[0222] At 5 of FIG. 20, the AMF may send a registration accept message to the WTRU, which may include one or more of the following parameters. The registration accept message may include an AcceptedRegistrationLevel, which may indicate if the WTRU registration at 2 and / or the user-centric trust authentication at 3 were successful. The registration accept message may include one or more of a UAR, an SRC, SG-Services, ULRArea, NoULRArea, or UserLevelPeriodicRegistrationUpdateTimer, as described at 8 of FIG. 18.

[0223] At 6 of FIG. 20, operations similar to those at 9 of FIG. 18 may be performed. The WTRU may use an SRC to access services described in SG-Services from the network. The WTRU may re-perform the ULR according to conditions described in UserLevelPeriodicalRegistrationUpdateTimer and / or ULRArea.

[0224] In examples, a WTRU may receive a first user authentication notification from a network device or function (e.g., a TES). The notification may include a DUID of the WTRU and / or SAUC requirements associated with generating a SAUC. The WTRU may prepare a SAUC according to the SAUC requirements and further prepare a user authentication request that may include an identifier of the WTRU and / or the SAUC. The WTRU may send the user authentication request to the network device or function, and may receive a user authentication response from the network device or function. The response may include a user authentication record, information regarding one or more granted services, and / or service request credentials for the WTRU. The WTRU may access the one or more granted services using the service request credentials.

[0225] 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.

[0226] 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 suchas 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: transmit an authentication request to another device via a wireless communication network, wherein the authentication request includes an indication that the authentication request is for a user of the WTRU, the authentication request further including credentials of the user related to one or more services available via the wireless communication network; receive an authentication response from the other device via the wireless communication network, wherein the authentication response includes an indication of whether the user has been authenticated; and if the authentication response indicates that the user has been authenticated, access at least one of the one or more services via the wireless communication network based on information included in the authentication response.

2. The WTRU of claim 1 , wherein the user of the WTRU includes a human user of the WTRU, a device connected to the WTRU and attempting to access the wireless communication network via the WTRU, or an application running on the WTRU and attempting to access the wireless communication network via the WTRU.

3. The WTRU of claim 1 , wherein the authentication request further includes one or more identifiers that identify the user or the WTRU.

4. The WTRU of claim 1 , wherein the credentials of the user are specific to the one or more services.

5. The WTRU of claim 1 , wherein the authentication request further indicates a service category or a service policy associated with the one or more services.

6. The WTRU of claim 1 , wherein the authentication response received by the WTRU further indicates a service group associated with a service category or a service policy.

7. The WTRU of claim 6, wherein the authentication response further includes credentials for accessing the service group.

8. The WTRU of claim 7, wherein the processor being configured to access the at least one of the one or more services based on the information included in the authentication response comprises the processor being configured to include the credentials for accessing the service group in a request to access the at least one service.

9. The WTRU of claim 1 , wherein the other device is a core network device of the wireless communication network or another WTRU in the wireless communication network.

10. The WTRU of claim 1 , wherein the processor is further configured to receive an indication from the other device to perform user-based authentication, and wherein the authentication request is transmitted in response to receiving the indication.

11. The WTRU of claim 1 , wherein the authentication response indicates an area in which user-based authentication is permitted or a periodicity for renewing the authentication request for the user.

12. A method implemented by a wireless transmit / receive unit (WTRU), the method comprising: transmitting an authentication request to another device via a wireless communication network, wherein the authentication request includes an indication that the authentication request is for a user of the WTRU, the authentication request further including credentials of the user related to one or more services available via the wireless communication network; receiving an authentication response from the other device via the wireless communication network, wherein the authentication response includes an indication of whether the user has been authenticated; and if the authentication response indicates that the user has been authenticated, accessing at least one of the one or more services via the wireless communication network based on information included in the authentication response.

13. The method of claim 12, wherein the user of the WTRU includes a human user of the WTRU, a device connected to the WTRU and attempting to access the wireless communication network via the WTRU, or an application running on the WTRU and attempting to access the wireless communication network via the WTRU.

14. The method of claim 12, wherein the authentication request further includes one or more identifiers that identify the user or the WTRU.

15. The method of claim 12, wherein the credentials of the user are specific to the one or more services.

16. The method of claim 12, wherein the authentication request further indicates a service category or a service policy associated with the one or more services.

17. The method of claim 12, wherein the authentication response received by the WTRU further indicates a service group associated with a service category or a service policy.

18. The method of claim 17, wherein the authentication response further includes credentials for accessing the service group.

19. The method of claim 18, wherein accessing the at least one of the one or more services based on the information included in the authentication response comprises sending the credentials for accessing the service group in a request to access the at least one service.

20. The method of claim 12, wherein the other device is a core network device of the wireless communication network or another WTRU in the wireless communication network.21 . The method of claim 12, further comprising receiving an indication from the other device to perform user-based authentication, wherein the authentication request is transmitted in response to receiving the indication.

22. The method of claim 12, wherein the authentication response indicates an area in which userbased authentication is permitted or a periodicity for renewing the authentication request for the user.

23. A network device associated with a wireless communication network, wherein the network device comprises a processor configured to: receive an authentication request from a wireless transmit / receive unit (WTRU) via the wireless communication network, wherein the authentication request includes an indication that the authentication request is for a user of the WTRU, the authentication request further including credentials of the user related to one or more services available via the wireless communication network;determine, based on the authentication request, whether the user is authorized to access the one or more services via the wireless communication network; and transmit an authentication response to the WTRU via the wireless communication network, wherein the authentication response includes an indication of whether the user is authorized to access the one or more services.

24. The network device of claim 23, wherein, based on a determination that the user is authorized to access the service, the processor is further configured to include credentials for accessing the one or more services in the authentication response.

Images