User-centric trust authentication for wireless mobile networks

Abstract

This document describes systems, methods, and / or apparatuses associated with user-centric trust authentication. A wireless transmit / receive unit (WTRU) can send 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 transmitting the authentication request to the other device, the WTRU can 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 can access one or more services via the wireless communication network based on the information included in the authentication response.

Description

Cross-reference of related applications

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

[0002] Existing authentication technologies for wireless communication systems can be used to authenticate Wireless Transmit / Receive Units (WTRUs) and build trust in them. However, these technologies cannot be used to establish trust relationships between users and the network or between two network functions. Therefore, user-level or user-centric trust authentication may be required to enable trusted network access for individual users of the WTRU (e.g., including human users of the WTRU, devices connected to the WTRU, and / or applications running on the WTRU). Summary of the Invention

[0003] This document describes systems, methods, and / or apparatuses associated with user-level or user-centric trust authentication. According to embodiments of this disclosure, a Wireless Transmit / Receive Unit (WTRU) can send 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 on the wireless communication network. In response to transmitting the authentication request to the other device, the WTRU can 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 can access at least one of one or more services via the wireless communication network based on the information included in the authentication response.

[0004] In the example, WTRU users may include: human users of the WTRU, devices connected to the WTRU and attempting to access the wireless communication network via the WTRU, or applications running on the WTRU and attempting to access the wireless communication network via the WTRU.

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

[0006] In the example, the device receiving the authentication request can be a core network device in the wireless communication network or another WTRU in the wireless communication network. In the example, the WTRU can receive an instruction from the core network device or another WTRU to perform user-based authentication, and can send an authentication request in response to receiving the instruction.

[0007] In the example, the authentication response could indicate the area where user-based authentication is allowed or the period for updating user authentication requests.

[0008] According to embodiments of this disclosure, a network device (e.g., a core network device) of a wireless communication network can receive an authentication request from a Wireless Transmit / Receive Unit (WTRU) via the wireless communication network. The authentication request may include an indication that the authentication request is for a user of the WTRU, and may further include the user's credentials for accessing one or more services available in the wireless communication network. The network device can determine, based on the authentication request, whether the user is authorized to access one or more services via the wireless communication network, and can send an authentication response to the WTRU via the wireless communication network. The authentication response may include an indication that the user is authorized to access one or more services. If the user is authorized to access one or more services, the network may further include the credentials used to access the one or more services in the authentication response. Attached Figure Description

[0009] Figure 1A This is a system diagram illustrating an example communication system that can implement one or more of the disclosed embodiments.

[0010] Figure 1B This illustrates that, according to an embodiment, it is possible to Figure 1A The diagram shows a system diagram of an example wireless transmit / receive unit (WTRU) used in a communication system.

[0011] Figure 1C This illustrates that, according to an embodiment, it is possible to Figure 1A The diagram shows a sample radio access network (RAN) and a sample core network (CN) used in the communication system.

[0012] Figure 1D This illustrates that, according to an embodiment, it is possible to Figure 1A The system diagram shown is another example RAN and another example CN used in the communication system.

[0013] Figure 2 An example of a security framework is shown.

[0014] Figure 3 An example use case for trust authentication is shown.

[0015] Figure 4 An example of a trust-enabled framework is shown.

[0016] Figure 5 Another example of a trust-enabled framework is shown.

[0017] Figure 6 An example of an in-network trust enabling framework is shown.

[0018] Figure 7 An example of an external trust enabling framework is shown.

[0019] Figure 8 This illustrates another example of an out-of-network trust enabling framework.

[0020] Figure 9 An example of user-centric trust authentication is shown.

[0021] Figure 10 This shows an example of a user-centric trust authentication initiated by WTRU.

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

[0023] Figure 12 An example of user-centric mutual authentication is shown.

[0024] Figure 13 An example of user-centric trust authentication for multiple WTRUs is shown.

[0025] Figure 14 An example process for user-centric trust authentication initiated by WTRU is shown.

[0026] Figure 15 An example process for network-initiated user-centric trust authentication is shown.

[0027] Figure 16 An example process for user-centric mutual authentication is shown.

[0028] Figure 17 An example process for user-centric trust authentication for multiple WTRUs is shown.

[0029] Figure 18 An example of WTRU registration followed by user-level registration is shown.

[0030] Figure 19 An example of user-level registration followed by WTRU registration is shown.

[0031] Figure 20 An example of integrating WTRU registration with user-level registration is shown. Detailed Implementation

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

[0033] Figure 1A This is a system diagram illustrating an example communication system 100 that can implement one or more of the disclosed embodiments. Communication system 100 may be a multiple access system providing content such as voice, data, video, messaging, and broadcasting to multiple wireless users. Communication system 100 enables multiple wireless users to access such content through shared system resources including wireless broadband. For example, communication system 100 may 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 Extended OFDM (ZTUWDTS-sOFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0034] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110, and other networks 112. However, it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d can be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as WTRUs.

[0035] Communication system 100 may include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks such as CN106 / 115, Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be base transceiver stations (BTS), Node-Bs, eNodeBs, home Node-Bs, home eNodeBs, gNBs, NR NodeBs, site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each depicted as a single element, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0036] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a specific geographic area that may be relatively fixed or may change over time. A cell may also be divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In embodiments, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0037] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via 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.). Any suitable radio access technology (RAT) can be used to establish air interface 116.

[0038] More specifically, as described above, the communication 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, etc. For example, base station 114a in RAN 104 / 113 and WTRUs 102a, 102b, 102c can implement wireless technologies, such as using Wideband CDMA (WCDMA) to establish Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA) for air interfaces 115 / 116 / 117. 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 the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement wireless technologies, such as using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-APro) to establish Evolved UMTS Terrestrial Radio Access (E-UTRA) for air interface 116.

[0040] In the embodiments, base station 114a and WTRUs 102a, 102b, 102c can implement wireless technologies, such as using New Radio (NR) to establish NR wireless access for air interface 116.

[0041] In this embodiment, base station 114a and WTRUs 102a, 102b, and 102c can implement various radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can, for instance, use the dual connectivity (DC) principle to jointly implement LTE radio access and NR radio access. Therefore, the air interface used by WTRUs 102a, 102b, and 102c can be characterized by various types of radio access technologies and / or by transmissions sent to / from various types of base stations (e.g., eNBs and gNBs).

[0042] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement wireless technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0043] Figure 1A Base station 114b can be, for example, a wireless router, a home Node-B, a home eNode-B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in localized areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for use by drones), roads, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement wireless technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c, 102d can implement wireless technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can be directly connected to Internet 110. Therefore, base station 114b does not need to access Internet 110 via CN 106 / 115.

[0044] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU 102a, 102b, 102c, and 102d. Data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although Figure 1AAs not shown, but will be understood, RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs using the same RAT as or a different RAT than RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113, which may be utilizing NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) using GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0045] CN 106 / 115 can also serve as a gateway for WTRU 102a, 102b, 102c, 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 / 113 or a different RAT.

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

[0047] Figure 1B This is a system diagram illustrating example WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138, etc. It will be understood that, while remaining consistent with the embodiments, WTRU 102 may include any sub-combination of the foregoing elements.

[0048] Processor 118 can be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 can be coupled to transceiver 120, which can be coupled to transmitting / receiving element 122. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it will be understood that the processor 118 and transceiver 120 can be integrated together in an electronic package or chip.

[0049] Transmitting / receiving element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via air interface 116. For example, in one embodiment, transmitting / receiving element 122 can be an antenna configured to transmit and / or receive RF signals. In embodiments, for example, transmitting / receiving element 122 can be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, transmitting / receiving element 122 can be configured to transmit and / or receive both RF signals and optical signals. It will be understood that transmitting / receiving element 122 can be configured to transmit and / or receive any combination of wireless signals.

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

[0051] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 can have multi-mode capability. Therefore, transceiver 120 can include multiple transceivers for enabling WTRU 102 to communicate via various RATs (e.g., such as NR and IEEE 802.11).

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

[0053] The processor 118 may receive power from the power supply 134 and may be configured to distribute power to other components in the WTRU 102 and / or control power to those other components. The power supply 134 may be any suitable device for powering the WTRU 102. For example, the power supply 134 may 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, etc.

[0054] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or instead of information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that, while remaining consistent with the embodiments, the WTRU 102 may acquire location information using any suitable location determination method.

[0055] The processor 118 can also be connected to other peripheral devices 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or videos), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, FM radio frequency units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

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

[0057] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can employ E-UTRA wireless technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 can also communicate with CN 106.

[0058] RAN 104 may include eNode-Bs 160a, 160b, and 160c, but it will be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, for example, eNode-B 160a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.

[0059] Each of the eNode-B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in the UL and / or DL, etc. Figure 1C As shown, eNode-B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0060] Figure 1C The CN 106 shown may 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 is described as part of CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0061] The MME 162 can connect to each of the eNode-Bs 160a, 160b, and 160c in RAN 104 via the S1 interface and can act as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, activating / deactivating bearers, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0062] The SGW 164 can connect to each of the eNodeBs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 can typically route and forward user data packets to or from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions, such as anchoring the user plane during eNodeB handover, triggering paging when DL data is available to WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0063] SGW 164 can be connected to PGW 166, which can provide WTRU 102a, 102b, 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0064] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to circuit-switched networks (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and traditional terrestrial line communication equipment. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) or be able to communicate with such an IP gateway as an interface between CN 106 and PSTN 108. Additionally, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0065] Despite WTRU in Figures 1A to 1D While described as a wireless terminal, it is envisioned that, in some representative embodiments, such a terminal may (e.g., temporarily or permanently) use a wired communication interface with a communication network.

[0066] In a representative embodiment, the other network 112 may be a WLAN.

[0067] A WLAN in Infrastructure Basic Services 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 interface to a Distribution System (DS) or another type of wired / wireless network that loads and / or loads traffic into and / or out of the BSS. Traffic originating outside the BSS destined for a STA can be delivered to the AP via it. Traffic from a STA to a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be transmitted via the AP, for example, where a source STA can transmit traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as point-to-point traffic. Point-to-point traffic can be transmitted between a source STA and a destination STA using a Direct Link Setup (DLS) (e.g., directly between them). In some representative embodiments, the DLS can use 802.11e DLS or 802.11z Tunneled DLS (TDLS). WLANs using the Independent BSS (IBSS) mode can function without access points (APs), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as a "self-organizing" communication mode in this document.

[0068] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of fixed width (e.g., a 20 MHz bandwidth) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. For CSMA / CA, each STA (e.g., every STA), including the AP, can sense the primary channel. If a particular STA senses / detects that the primary signal is busy and / or determines that the primary signal is busy, that particular STA can back off. In a given BSS, at any given time, only one STA (e.g., only one station) can transmit.

[0069] High-throughput (HT) STAs can communicate using a 40MHz wide channel, for example, by combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels.

[0070] Very High Throughput (VHT) STAs can support channels with widths of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels, which can be referred to as an 80+80 configuration. In the 80+80 configuration, data, after channel coding, can be passed through a fragment parser that splits the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed on each stream separately. The streams can be mapped onto the two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0071] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carrier used in 802.11af and 802.11ah are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV Blank (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah can support instrument-type control / machine-type communication, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only) certain and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0072] WLAN systems that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as the primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STAs operating in the BSS that support the minimum bandwidth operating mode. In the 802.11ah example, for STAs that support (e.g., only support) the 1MHz mode (e.g., MTC type devices), the primary channel can be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier Sense 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 STAs (which only support the 1MHz operating mode) transmitting to the AP, the entire available band may be considered busy even if most of the band remains idle and potentially available.

[0073] In the United States, the available frequency band for 802.11ah is 902MHz to 928MHz. In South Korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. The total available bandwidth for 802.11ah is 6MHz to 26MHz, depending on the country code.

[0074] Figure 1D This is a system diagram illustrating RAN 113 and CN 115 according to one embodiment. As described above, RAN 113 can employ NR radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 113 can also communicate with CN 115.

[0075] RAN 113 may include gNBs 180a, 180b, and 180c, but it will be understood that RAN 113 may include any number of gNBs while remaining consistent with the embodiments. gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Thus, for example, gNB 180a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In embodiments, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be located on unlicensed spectrum, while the remaining component carriers may be located on licensed spectrum. In embodiments, gNBs 180a, 180b, and 180c may implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0076] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with a scalable digital architecture. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes of various lengths or scalable lengths, or transmission time intervals (TTIs) (e.g., containing different numbers of OFDM symbols and / or absolute times of varying durations).

[0077] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNodeBs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more of gNBs 180a, 180b, and 180c as mobile anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with gNBs 180a, 180b, and 180c while also communicating / connecting with another RAN (such as eNode-Bs 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c and one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can act as mobile anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput to serve WTRUs 102a, 102b, and 102c.

[0078] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support for network slicing, dual connectivity, interoperability between NR and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB180a, 180b, and 180c can communicate with each other via the Xn interface.

[0079] Figure 1DThe CN 115 shown may 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 is described as part of the CN 115, it will be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0080] AMF 182a and 182b can connect to one or more of the gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting specific SMFs 183a and 183b, managing registration areas, terminating NAS signaling, mobility management, etc. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the service types being utilized by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services dependent on Ultra Reliable Low Latency (URLLC) access, services dependent on Enhanced Massive Mobile Broadband (eMBB) access, services for Machine Type Communication (MTC) access, etc. AMF 162 can provide control plane functions for handover between RAN 113 and other RANs (not shown) that employ other wireless technologies (such as LTE, LTE-A, LTE-APro) and / or non-3GPP access technologies (such as WiFi).

[0081] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 115 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 115 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure traffic routing through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, or Ethernet-based.

[0082] UPF 184a and 184b can connect via the N3 interface to one or more of the gNBs 180a, 180b, and 180c in RAN 113. These gNBs can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as the Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multihomed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0083] CN 115 can facilitate communication with other networks. For example, CN 115 may include or be able to communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 115 and PSTN 108. Additionally, CN 115 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRUs 102a, 102b, and 102c can be connected to DN 185a and 185b via UPF 184a and 184b through the N3 interface to UPF 184a and 184b and the N6 interface between UPF 184a and 184b and local data networks (DNs) 185a and 185b.

[0084] Given Figures 1A to 1D and Figures 1A to 1D The corresponding descriptions can be performed by one or more emulation devices (not shown) that perform one or more of the functions described herein with respect to: WTRU 102a to 102d, base stations 114a to 114b, eNode-B 160a to 160c, MME 162, SGW 164, PGW 166, gNB 180a to 180c, AMF 182a to 182b, UPF 184a to 184b, SMF 183a to 183b, DN 185a to 185b, and / or any other devices described herein. An emulation device can be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device can be used to test other devices and / or simulate network and / or WTRU functions.

[0085] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, one or more simulation devices may perform one or more functions when fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. One or more simulation devices may perform one or more functions when temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices may be directly coupled to another device for testing purposes and / or may use over-the-air wireless communication to perform tests.

[0086] One or more simulation devices may perform one or more functions when implemented / deployed without being part of a wired and / or wireless communication network. For example, simulation devices may be used to test scenarios in a laboratory and / or undeployed (e.g., testing) wired and / or wireless communication networks to perform tests on one or more components. One or more simulation devices may be test rigs. Simulation devices may transmit and / or receive data using direct RF connections and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0087] A communication system (e.g., a 5G system (5GS)) may include a Transmit / Receive Unit (WTRU), a Radio Access Network (RAN), and / or a core network. Such a communication system may be designed as 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 multiple network functions (NFs) that work together to perform and deliver services to the RAN, 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] Network functions (NFs) can access other NFs in a request / response mode or a subscription / notification mode. Before two NFs interact with each other, they can register with a Network Repository Function (NRF) to discover each other via the NRF. Among NFs, the Access and Mobility Management Function (AMF) manages the WTRU's access to the network and its mobility. The Session Management Function (SMF) establishes sessions between the WTRU and the core network. The Authentication Server Function (AUSF) authenticates the WTRU. The Policy Control Function (PCF) provides policy rules to other control plane NFs and / or WTRUs. The PCF can assign identifiers to (e.g., each) the created policy rules, which other control plane NFs and / or WTRUs can use to reference the corresponding policy rules. User Plane Functions (UPFs) can be core network functions in the data plane that help monitor, manage, control, and / or redirect user plane traffic (e.g., traffic between the WTRU and the Application Function (AF)). Network Exposure Function (NEF) enables access to control plane functions through entities that may be located outside the network or not in the same trusted domain, such as web applications and / or AFs.

[0089] The core network (e.g., 5GC) can provide data storage and / or analysis services through one or more functions, such as Unified Data Management (UDM), Unified Data Repository (UDR), Unstructured Data Storage Function (UDSF), and / or Network Data Analysis Function (NWDAF). Communication systems (e.g., 5GS) can provide network slicing, which can be facilitated by the Network Slice Selection Function (NSSF).

[0090] A communication system may incorporate one or more network functions (e.g., Location Management Function (LMF)) to support location services. The LMF can calculate, determine, or verify final location and / or velocity estimates. The LMF can estimate the achieved accuracy based on location information from the target WTRU and / or RAN nodes. After the LMF calculates the location of the target WTRU, other entities can access or query the location from the LMF through the serving AMF.

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

[0092] like Figure 2 As shown, security functions in a communication system (e.g., 5GS) can cover multiple (e.g., four different) security domains within the system. These security domains may include network access security between the WTRU and the RAN / core network, network domain security between the RAN and the core network (e.g., 5GC), user domain security between a mobile equipment (ME) and a Universal Subscriber Identity Module (USIM), and / or SBA domain security in the core network.

[0093] Network access security can be achieved through network access authentication, message encryption, and / or message integrity protection. Network access authentication can include primary authentication, key negotiation, and secondary authentication.

[0094] Master authentication and key negotiation facilitate mutual authentication between the WTRU and the network. Master authentication and key negotiation can be implemented at the network side and / or the WTRU side using negotiated key materials (e.g., anchor key K). SEAF The underlying basis for master authentication and key negotiation can be: the same long-term key K corresponding to the WTRU can be maintained at the USIM and / or by the network. Anchor key K SEAF Other key materials (e.g., keys for encryption and integrity protection of NAS and AS signaling) can be (e.g., independently and / or identically) derived at the WTRU and / or network side. Anchor key K SEAF Other key materials can be exchanged without over the air interface. If the WTRU and / or network recognize the same long-term key K, mutual authentication can be established. Since the primary authentication can be (e.g., only) based on the long-term key K, it may not take into account user-centric aspects (e.g., user behavior) and may not be able to authenticate or differentiate users from the same WTRU or different WTRUs.

[0095] As part of session management, secondary authentication can provide security between the WTRU and the external data network (DN). Secondary authentication can use the SMF to initiate and coordinate the authentication process between the WTRU and the DN (e.g., a Data Network Authentication, Authorization, and Accounting (DN-AAA) server).

[0096] The Zero Trust Architecture (ZTA) principle can be applied to communication systems such as 5GS. Applicability can include continuous security monitoring of NFs, which can be deployed in different environments and scenarios that may be subject to potential errors and / or malicious attacks.

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

[0098] PDL can be utilized and integrated with communication systems such as 5GS. PDL services or functions can be provided within communication systems such as 5GS. PDL functions may include Distributed Ledger Anchoring Function (DLAF), Distributed Ledger Repository Function (DLRF), and / or Distributed Ledger Enabler (DLE). DLAF and DLRF can be two control plane functions for the communication system, while DLE can be a data plane function.

[0099] PDL can be used to build native self-sovereign identity (SSI) systems under the constraints of telecommunications networks, enabling users or network nodes holding such SSIs to (e.g., seamlessly) access network services between different operators and service providers.

[0100] Communication systems (such as cellular wireless systems (e.g., 5GS)) can provide a variety of security features, such as primary authentication during registration, secondary authentication during Protocol Data Unit (PDU) session establishment, network slice-specific authentication and authorization, network slice admission control, and / or data plane encryption and integrity protection. Figure 3 Two use cases involving trust authentication in a mobile network are illustrated. In example use case 1, user-level trust can be established between a user of a device (e.g., WTRU1) and the network. In example use case 2, trust can be established between users to share services across devices (e.g., WTRU1 and WTRU2). Both use cases can lead to trust arrangements as described below.

[0101] In the first example of a trust arrangement, user-level trust or user-centric trust can be established. For example... Figure 3As shown in Example Use Case 1, WTRU1 can be shared by multiple users (e.g., User 1 and User 2), who can vary based on location, time, or other factors. For example, a vehicle with an embedded WTRU can be used to provide connectivity and services to (e.g., all) passengers in the vehicle (e.g., passengers can use the embedded WTRU to gain network access). Passengers can exhibit different behaviors, such as using different network functions, application functions, and / or services. Trust can be established between passengers and the network (referred to herein as user-level trust or user-centric trust), which can lead to better authentication and service provisioning (e.g., for network access requests from passengers). The network in this example use case can be a visited network or a home network (e.g., a Public Land Mobile Network (PLMN) or a Non-Public Network (NPN)). Figure 3 Example use case 2 shown can also implement user-level trust when a user of WTRU1 attempts to access a service provided by WTRU2.

[0102] As described above, master authentication can be used to authenticate the WTRU and build trust in it. However, this authentication technique may not be able to establish trust relationships between the user and the network or between two NFs. Therefore, user-level trust is needed to enable trusted network access for different users.

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

[0104] The master authentication technology described in this paper can be a centralized solution that uses a home network and may inherit at least two drawbacks. First, the master authentication technology may fail to establish a direct trust relationship between two WTRUs or between the corresponding users of these WTRUs. For example, if the home network becomes unavailable (e.g., due to failure, disaster, too many concurrent users, etc.), master authentication may fail to complete. Therefore, roaming users (e.g., Figure 3Use case 1) may not be able to access the home network as a visited network, or the home user may not be able to access the RAN or edge network via the home network. In contrast, the distributed trust establishment technique described in this paper can be independent of the home network, so even if the home network is unavailable, users can access services from other WTRUs or networks.

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

[0106] When referred to herein, a device may be a WTRU (e.g., unless explicitly stated otherwise, the two terms may be used interchangeably). When referred to herein, a network function (NF) may include processing functions in a network (e.g., 5GC), AF, edge applications or services, services provided by a device, applications provided at the device, servers or services in a data network, etc. When referred to herein, a user of a WTRU may be an entity using the WTRU (e.g., including humans) (e.g., a user may be an entity located outside or inside the WTRU), an NF consumer, an application running on the WTRU (e.g., an application that may attempt to access a mobile network via the WTRU), another WTRU connected to the WTRU but not having a USIM, or a device attempting to gain access to a mobile network using the WTRU. When referred to herein, a distributed ledger system (DLS) may be a system that includes or uses a distributed ledger or distributed repository. A DLS may include or use a permissioned distributed ledger / repository and / or a permissionless distributed ledger / repository. A DLS may include trusted data storage or repository functionality that may be resistant to malicious attacks and / or may not rely entirely on a centralized entity (e.g., a cloud server).

[0107] When used herein, distributed trust (DT) can refer to a direct trust relationship between two entities that can operate without relying on a centralized third party. These two entities can be a WTRU and a network, a user of a WTRU and a network, two users (e.g., each user on a different WTRU), two WTRUs, two AFs, or two NFs. When used herein, user-level trust (ULT) or user-centric trust (UCT) can 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. ULTs can be established without the use of a centralized entity, in which case the ULT may not be trusted. Unless otherwise explicitly stated, the terms ULT and UCT are used interchangeably in this disclosure.

[0108] When referred to herein, a trusted device can be a device or WTRU trusted by other devices, other entities / users, and / or by a cellular radio system (e.g., a 6G system (6GS)). Unless otherwise expressly stated, the terms trusted device and trusted WTRU are used interchangeably in this disclosure. When referred to herein, an entity's identifier can include the entity's name, alphanumeric identifier, or network address (e.g., an entity can be a device / WTRU, a network function (such as a 3GPP NF), a trust-enabled client as described herein, a trust-enabled server as described herein, an entity using a WTRU, etc.). For example, the identifier can be a 3GPP identifier, an IP address, a Uniform Resource Locator (URL), a Fully Qualified Domain Name (FQDN), a blockchain address, etc. An entity's identifier can convey access details about the entity, which other entities can use to access and / or interact with the entity.

[0109] When used in this document, a Distributed User Identifier (DUID) can be a unique identifier for a user, which can be created and owned by the user without the use of a third party. A DUID can be formed or established by the user (e.g., independently) using a DUID generation algorithm or function, which can be based on the user's unique and / or private information (e.g., private key, password, user attributes or characteristics, and / or user biometrics). Entities (e.g., devices, applications on devices, services provided at the device, and / or NFs) can create and hold DUIDs.

[0110] When used in this document, a Distributed Verifiable User Credential (DVUC) can be a credential created or issued for a user. A DVUC can be verified or authenticated by network devices (e.g., in a distributed manner without contacting the party that created or issued the DVUC). A user can have one or more sets of DVUCs. If an unauthorized user attempts to access a service from an entity (e.g., an NF), the user can present a set of DVUCs to that entity for authentication and can establish a ULT or DT with that entity (e.g., based on that DVUC). A new set of DVUCs can replace an existing set of DVUCs. A new set of DVUCs can depend on an existing set of one or more DVUCs.

[0111] When used herein, a Service-Aware User credential (SAUC) can be a type of DVUC associated with one or more target services to which the DVUC may be applied (e.g., services belonging to a service category or conforming to a specific service policy). The SAUC may indicate the service category and / or service policy of the target service associated with it. 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 allowed bit rates); 2) computing services with certain computational requirements (e.g., computational latency, computational throughput (e.g., the number of requests processed per second), etc.); 3) data services with certain data service requirements (e.g., data type, data processing type / algorithm, data volume, data storage, etc.); 4) AI services with certain artificial intelligence (AI) service requirements (e.g., AI model type, AI model size, AI model accuracy, etc.); 5) proxy or relay services (e.g., services that can relay service requests from a user / WTRU to another user / WTRU or NF). Service requirements may be described as part of a service policy. A service policy may describe or include one or more service requirements and / or one or more service conditions. If all or a subset of the service conditions are met, the service provider may provide the target service to the user / WTRU / NF / AF who requested it. Service conditions may include, but are not limited to: 1) the location of the target service; 2) the location of the entity authorized to access the target service; 3) the trust level (e.g., threshold, scope, etc.) of the user / WTRU / NF / AF authorized to access the target service; 4) the date and / or time on which the target service may be provided to the user / WTRU / NF / AF who requested it; and 5) the priority of the service conditions or service policy. In the example, the SAUC may include information indicating the method used to verify the SAUC. For example, the SAUC may allow a user to select a service provider without involving other parties (e.g., such as a PCF). The SAUC may allow the service provider to (e.g., directly) check the service policy without contacting another party (e.g., an NF, such as a PCF). The SAUC can improve the efficiency of user-centric trust authentication and service access.

[0112] When mentioned herein, a Service Request Credential (SRC) can also be a type of DVUC. For example, after a set of DVUCs or SAUCs is presented by a user to a service provider and authenticated by the service provider, the service provider can issue one or more services to the user. For each authorized service, the service provider can issue a corresponding set of SRCs (e.g., the SRCs can be different for different services), which the user can then present to the service provider when accessing that specific service. The service provider can also issue SRCs for a group of services (e.g., a service group), which the user can then present to the service provider when accessing the service associated with that service group. SRCs can allow for finer granularity (e.g., per service request) to control user-centric trust authentication and / or user access to services.

[0113] When referred to herein, credentials (e.g., such as DVUC, SAUC, or SRC) may include, but are not limited to, certificates, keys, identifiers, and / or the like that can be used to identify and / or authenticate entities (e.g., users such as WTRUs).

[0114] The goal of designing a trust authentication mechanism can be to avoid points of failure in trust authentication and to cater to different use cases (e.g., Figure 3 (In the use cases) it provides flexibility and applicability, minimizes or reduces communication or computing overhead on the device, ensures compatibility with the 3GPP architecture, and / or facilitates integration with the 3GPP SA2 or SA6 process.

[0115] Using the techniques described in this paper, efficient user-level trust establishment can be achieved without the use of a centralized party, and efficient distributed trust establishment can be achieved without relying on a specific network (e.g., a home network).

[0116] Figure 4 An example of a trust enabling framework for implementing distributed and / or user-level trust in a wireless network is shown. This framework may include one or more of the following logical entities.

[0117] The trust enabling framework can include a trust enabling client (TEC), which can be a component or entity located within a WTRU. A WTRU can have one or more TECs configured to serve different users or applications (e.g., users can include entities located outside or inside the WTRU). A TEC can be implemented as a function that can interact with the TES on behalf of one or more WTRUs and / or users. From the TEC's perspective, the WTRU can be considered a special user.

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

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

[0120] Trust enabling frameworks can perform one or more of the following functions. A trust enabling framework can perform user-centric trust authentication. For example, a user of a WTRU and the WTRU can trust a TEC hosted at the WTRU. The TEC can be registered with a service provider's TES (e.g., referred to as a registered TES). If the WTRU (or a user of the WTRU) accesses a service from a service provider, the TEC at the WTRU can present a DVUC to the registered TES on behalf of the user. The registered TES can authenticate the user's DVUC (e.g., using a distributed approach) and can establish user-level trust with the user on behalf of the service provider. As a result of DVUC authentication, if the service provider trusts the TES (e.g., the TES can be deployed as a standalone trusted NF in the service provider's domain, or as part of another trusted NF in the service provider's domain), the TES can authorize a set of services to the user on behalf of the service provider. The TES can generate one or more Service Request Credentials (SRCs) for the user, each of which can correspond to a type of authorized service and can be used to access services of that type. TES can transmit the authentication result to an NF (e.g., a Secure Anchoring Function (SEAF) and / or a UDM), which can store the authentication result.

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

[0122] Trust-enabled frameworks can leverage other functional areas (NFs). For example, TES can utilize and interact with other NFs. TES can retrieve ULT-related policies from the PCF, which can be used during user-centric trust authentication. TES can retrieve ULT-related subscription data from the UDM, which can also be used during user-centric trust authentication. TES can interact with SEAF to determine if the WTRU has passed master authentication.

[0123] Trust enablement frameworks can be implemented as network functions (e.g., 3GPP NF). Figure 5 A 3GPP SA2 example is shown that can integrate the user-centric enabling framework described in this paper with a 3GPP network system.

[0124] like Figure 5 As shown, the TES can be implemented as a control plane function that can interact with other 3GPP NFs via a service-based interface (SBI). The TEC can be implemented as a function embedded at the WTRU. Interaction between the TEC and TES can occur in the control plane via NAS signaling and / or via AMF relay. Interaction between the TEC and TES can be performed via the data plane. A PDU session can be established between the TEC and TES for sending messages between them. Interaction between the TEC and TES can be performed via the SBI. For example, the TEC and TES can access each other's services (e.g., functions) via the SBI. The TES can be integrated into existing 3GPP NFs (e.g., into SEAF and / or AMF).

[0125] The user-centric trust enablement framework described in this paper can be implemented as one or more service layer functions. Figures 6 to 8 An example approach for implementing a trust-enabled framework is shown. It should be noted that, although... Figures 6 to 8 The implementations shown are within the 3GPP Service Enablement Architecture Layer (SEAL), but these implementations can also be implemented as dedicated service enablement frameworks that can interact with SEAL.

[0126] Figure 6 A 3GPP SA6 example is shown for integrating the proposed trust enabling framework with the 3GPP SEAL network in-network functional model. Figure 6 As shown, the TEC can be implemented as part of a SEAL client to serve one or more Vertical Application Layer (VAL) clients. The TES can be implemented as part of a SEAL server, which can be accessed by one or more VAL servers. A VAL client can be implemented for a user who can use services provided by the VAL server. The VAL client can have a DUID and / or DVUC, which can be presented to the TES by the VAL client via the TEC. The TES can perform user-centric trust authentication on behalf of the corresponding VAL server for the VAL client's DVUC. The TES can interact with one or more NFs in a 3GPP network system via a network interface (e.g., NEF).

[0127] Figure 7 A 3GPP SA6 example is shown for integrating the proposed trust enabling framework with the 3GPP SEAL network-outside functional model (e.g., "network-outside" can mean not involving 3GPP network systems). Figure 7 As shown, WTRU2 can communicate with one or more SEAL servers and / or VAL servers. WTRU2 can provide services to WTRU1. VAL clients at WTRU1 can request access to information and / or services provided by WTRU2. TEC can be implemented as part of a SEAL client at WTRU1 (e.g., such a SEAL client can serve one or more VAL clients and / or be accessed by them). TES can be implemented as part of a SEAL client at WTRU2 (e.g., such a SEAL client can also serve one or more VAL clients and / or be accessed by one or more VAL clients). VAL client users can use services provided by the VAL server. VAL clients at WTRU1 can present their DVUC to TES via TEC, allowing TES to perform user-centric trust authentication based on the VAL client's DVUC (e.g., representing the corresponding VAL client at WTRU2).

[0128] Figure 8Another 3GPP SA6 example for integrating the proposed trust enabling framework with the 3GPP SEAL network external function model is shown. In this example, both WTRU1 and WTRU2 can have SEAL clients and VAL clients. TEC1 can be implemented as part of the SEAL client at WTRU1 (e.g., such SEAL client can serve one or more VAL clients and / or be accessed by one or more VAL clients). WTRU2 can have TEC2 as part of the SEAL client on WTRU2 (e.g., such SEAL client can also serve one or more VAL clients and / or be accessed by one or more VAL clients). TEC1 and TEC2 can exchange information, such as information about the VAL clients being served and / or the user-centric trust authentication status (e.g., whether / when the TEC completes user-centric trust authorization with a specific TES, and for which specific users, etc.).

[0129] User-centric trust authentication can be used to authenticate WTRUs and / or users based on Service-Aware User Credentials (SAUCs) (e.g., user credentials associated with one or more specific services). The TEC can present such credentials on behalf of the WTRU and / or user to the TES associated with the network device (or another WTRU). After the WTRU and / or user is authenticated (e.g., after the SAUC is approved), the WTRU and / or user can begin using the services provided by the network device (or by other WTRUs). A WTRU can have multiple users, all of whom can be authenticated using the user-centric techniques described herein.

[0130] User-centric trust authentication can include multiple (e.g., four) features, which can be implemented based on the interaction between TEC and TES, such as... Figure 9 As shown. It should be noted that even if the user is... Figure 9 The user is shown as an entity located outside the WTRU, but the user can also be an entity located inside the WTRU. A device that uses the WTRU to gain access to the communication network (e.g., another WTRU) can also be considered a user of the WTRU.

[0131] like Figure 9 As shown, user-centric trust authentication can be initiated by WTRU (e.g., example in...). Figure 10 Provided in (and network-initiated) (e.g., example in) Figure 11 (provided in) and mutual authentication (e.g., example in) Figure 12 (provided in), or for multiple WTRUs (e.g., example in) Figure 13 (Provided by China).

[0132] Figure 10 This illustrates an example of user-centric trust authentication initiated by WTRU. For example... Figure 10 As shown, a user of the target WTRU (or the target WTRU itself) may attempt to establish a user-centric trust relationship with a network (e.g., a wireless communication network) at point 1 to access services from a service provider associated with that network (e.g., from a network device or another WTRU). The user can be an entity located outside or within the target WTRU. A device using the target WTRU to gain access to a network (e.g., a 3GPP network) can also be a user of the target WTRU. At point 2, the TEC on the target WTRU may transmit a SAUC to the TES on behalf of the WTRU or the user. The SAUC may be transmitted as part of an authentication request, registration request, or service request (e.g., via a wireless communication network) 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 one or more specific WTRUs, or by one or more specific WTRUs). The TES may use a distributed method (e.g., a distributed ledger system (DLS)) to authenticate the received SAUC (e.g., without the need for a centralized party). Following authentication, the TES can assign one or more service groups (SGs) to the WTRU and / or user, for example, based on the service description included in the authenticated SAUC. An SG may include a set of network functions, a set of services, one or more network slices, etc. For each assigned SG, the TES can generate a corresponding Service Request Credentials (SRC), which can be used by the WTRU and / or user to access the SG. For example, the WTRU and / or user can include the corresponding SRC for that SG in subsequent access requests for that SG (e.g., for one or more services within the SG), thereby enabling trust authentication at a more granular level (e.g., at the service request level). At point 3, the TES can transmit information about one or more assigned SGs and / or their associated SRCs to the TEC, WTRU, and / or user (as part of the authentication response). At point 4, the user can present the SRC associated with the assigned SG to access services from that SG. Further details regarding the operations at points 2 and 3 will be provided in [reference needed]. Figure 14 supply.

[0133] Figure 11 This illustrates another example of network-initiated, user-centric trust authentication. For example... Figure 11As shown, an application or network can trigger user-centric trust authentication for a target WTRU or a user. The user can be an entity located outside or inside the target WTRU. A device using the target WTRU to gain access to the communication network can also be a user of that WTRU. Figure 11 At point 1, the TES, AF, or NF can send a request to the TEC, instructing it to perform user-centric trust authentication for one or more WTRUs / users. This request can trigger the TEC to perform WTRU-initiated user-centric trust authentication, which can be similar to... Figure 10 Operations at points 2 to 4. Regarding... Figure 11 More details on the operations at points 1 to 3 will be available in the reference section. Figure 15 describe.

[0134] Figure 12 An example of user-centric mutual authentication is shown. Figure 12 As shown, a WTRU or a user associated with a WTRU can authenticate the network (e.g., in addition to the network authenticating the WTRU / user, such as...). Figure 10 and Figure 11 (As shown). This authentication can be referred to in this article as user-centric mutual authentication. Figure 12 At point 1, a user of the target WTRU (or the target WTRU itself) can trigger the establishment of a user-centric trust relationship with the network, for example, to access services provided by a service provider (e.g., a network device or another WTRU). The user can be an entity located outside or inside the target WTRU. A device using the target WTRU to gain access to the communication network can also be a user of the WTRU. Figure 12 At point 2, the TEC associated with the target WTRU can transmit the user-associated SAUC to the TES (e.g., as part of an authentication request). The TES can then authenticate the SAUC, assign an SG to the target WTRU or user, and / or generate a corresponding SRC for each SG. Figure 12 At point 3, the TES may (e.g., for mutual authentication purposes) transmit Service Provider Credentials (SPCs) to the TEC (e.g., in addition to the SRC and the assigned SG). The SPC may belong to a service provider offering or a group of services to the target WTRU or user. Each SG may be associated with a corresponding SPC, or the same SPC may apply to multiple (e.g., all) assigned SGs. Figure 12 At four points, TEC can certify SPC and send certification confirmation to TES. Figure 12At point 5, the target WTRU or user can use the SRC to access services from the assigned SG. The user-centric mutual authentication described herein can be initiated by the target WTRU or user (e.g., as...). Figure 12 (as shown), or initiated by a network device or application (e.g., an application server). Regarding Figure 12 More details on the operations at points 2 to 4 will be available in the reference section. Figure 16 supply.

[0135] The SPC described herein may include information proving that a service provider can offer certain services (e.g., statements, claims, certificates, etc.). The SPC may be a type of DVUC or SAUC (e.g., the service provider may be considered a user). In the examples, an SPC generated for a service provider may include one or more of the following: The SPC may include an SPC-ID, which may be an identifier for the SPC. The SPC may include an SPC-Issuer-ID, which may be an identifier (e.g., a DUID) for an SPC issuer (e.g., an entity outside the service provider) that can generate or issue the SPC for a service provider such as represented by an SPC-Owner-ID. The SPC may include an SPC-Owner-ID, which may be an identifier for the service provider to which it generated the SPC or to which the SPC belongs. For mobile networks, the SPC-Owner-ID may be a PLMN-ID, NPN-ID, or DUID. If the SPC-Owner-ID is a DUID, then the DUID may be generated based on the PLMN-ID of the mobile network. The SPC may include information (e.g., claims) indicating the attributes, characteristics, and / or capabilities of the service provider represented by the SPC-Owner-ID. Examples of such information may include “the service provider supports 5G standalone,” “the service provider supports data storage services,” “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 range of other mobile operators (e.g., their PLMN-IDs),” and / or “the service provider supports digital twin and metaverse services.” For each supported service, the service provider may have a contract describing the policies and / or billing rules for that service. The address (e.g., storage location) and / or the content of the contract may be included as a claim in the SPC. The SPC may include the public key of the SPC issuer. The SPC may include the signature of the SPC issuer, which may be generated based on the SPC issuer's private key (e.g., using hashing and / or encryption algorithms, which may also be included in the same SPC).

[0136] Figure 13An example of user-centric trust authentication for multiple WTRUs is shown. Figure 13 As shown, TEC1 and TES can perform user-centric trust authentication at one point (e.g., Figures 10 to 12 The operation shown establishes trust for User 1 on WTRU1. The TES can (e.g., during user-centric trust authentication) inform User 1 that they can access the assigned SG via WTRU2. The TES can include the identifier of WTRU2 in the SRC, which can be generated by the TES and transmitted to User 1 via TEC1. User 1 can be a device that uses WTRU1 and / or WTRU2 to gain access to the communication network. Figure 13 At point 2, User 1 can switch to using WTRU2 and access services from the network using the same SRC. Using this method, TEC2 can avoid transmitting User 1's SAUC to the TES and can skip user-centric trust authentication (e.g., as in...). Figure 13 (As shown in point 3). TEC2 can retrieve the SRC from TEC1, or TEC1 can push the SRC to TEC2. In the example, TEC2 can retrieve the identifier of the SRC from TEC1, or TEC1 can push the identifier of the same SRC to TEC2. Figure 13 At point 4, user 1 can use the previously established trust to access the service via WTRU2 (for example, TEC2 at WTRU2 can present the same SRC or the identifier of the same SRC to TES).

[0137] Regarding user-centric trust authentication initiated by a WTRU, when a requesting WTRU and / or its users need to establish a trust relationship with a service provider (e.g., a network device or NF, another WTRU, etc.), the requesting WTRU and / or its users can utilize a TEC to present their SAUC to a TES, which can be part of the service provider. The TES can verify and authenticate the SAUC on behalf of the service provider in a distributed manner without contacting the entity that generated the SAUC. If the SAUC is authenticated, a trust relationship can be established between the requesting WTRU / user and the service provider. Therefore, the requesting WTRU can be authorized to access services provided by the service provider. Figure 14 A sample process for user-centric trust authentication is shown. As an example, Figure 14 The NFy shown can be a network function (e.g., SEAF) that can provide information about the primary authentication status of the requester's WTRU.

[0138] Figure 14The example process shown may include one or more of the following operations: The TEC at the requesting WTRU can obtain or has been configured with the address of the TES (e.g., the TES may be hosted on a core network device). The TEC can obtain the WTRU-SAUC of the user of the requesting WTRU. The TEC can know its identifier (TEC-ID). The TEC can know the DUID of the requesting WTRU (e.g., WTRU-DUID) and / or the DUID of its user.

[0139] exist Figure 14 At point 1, the requester WTRU or its user can trigger the TEC to send a user authentication request to the TES associated with the service provider (e.g., to access services provided by a service provider such as VisitNet). This request may include one or more of the following parameters or information: The request may include a TEC-ID, which may be an identifier of the TEC. The request may include a WTRU-ID, which may be an identifier of the requester WTRU. The request may include a WTRU-DUID, which may be the DUID of the requester WTRU and / or the user. The request may include a 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 is successfully authenticated, the requester WTRU and / or the user can use the 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. If the TES already maintains the WTRU-Public-Key or can find it from other network devices or functions (e.g., based on WTRU-ID or WTRU-DUID), then the key may not be included in the request. The request may include a DLS-ID, which can be an identifier of a distributed ledger system (e.g., a distributed ledger system that stores some public information that can be used to verify the SAUC). In the example, the DLS-ID may not be included in the request, and the TES can... Figure 14 The request may include instructions on the service category or service policy for one or more services as desired by the requester's WTRU or the user.

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

[0141] exist Figure 14 At point 3, TES can select the appropriate DLS based on WTRU-DUID. WTRU-DUID can (e.g., via fields in WTRU-DUID) indicate the name, type, or identifier of the DLS, and public information corresponding to WTRU-DUID (e.g., WTRU-Public-Key) can be stored and retrieved in that DLS.

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

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

[0144] exist Figure 14 At point 6, TES can extract the identifier of the WTRU-SAUC creator that generated the WTRU-SAUC from the WTRU-SAUC. TES can then send a request to DLS to retrieve WTRU-SAUC creator information (e.g., WTRU-SAUC-Creator-Info), such as the creator's public key, the creator's identifier, and / or the creator's signature authentication scheme. DLS can find this information and send it back to TES.

[0145] WTRU-SAUC-Creator-Info can include the public key of the WTRU-SAUC creator. Figure 14At point 7, TES can use this public key to verify the signature of the WTRU-SAUC creator within the WTRU-SAUC. If the signature is valid, the WTRU-SAUC can be considered valid, and the requested user authentication can be considered successful.

[0146] exist Figure 14 At point 8, the TES can store the WTRU-SAUC. Subsequently, if the TEC sends another user authentication request to the TES, the TEC can send the identifier of the WTRU-SAUC (WTRU-SAUC-ID) (for example, instead of the WTRU-SAUC itself), which the TES can use to locate the stored WTRU-SAUC. This method can reduce the communication overhead from the TEC to the TES.

[0147] exist Figure 14 At point 9, the TES can (e.g., after the WTRU-SAUC is verified) determine one or more service groups (SGs) for a requester represented by the WTRU-DUID. The TES can do this based on the service policies included in the verified WTRU-SAUC, eliminating the need to retrieve service policies from other network functions (e.g., from the PCF). For each determined SG, the TES can create a corresponding Service Request Credential (SRC). This SRC can be presented by the requester (e.g., after receiving the SRC) to access services from the SG (e.g., the SRC can be used by the service provider to authenticate the requester). In the example, the TES can determine and assign multiple types of services for a requester (e.g., a WTRU or a user of a WTRU). The TES can create corresponding SRCs for one or more types of services (e.g., for each type of service). These services can be provided by other NFs and / or WTRUs. After the WTRU-SAUC is verified and / or if the WTRU-SAUC is for the requesting WTRU (e.g., not for the user), the TES can determine the maximum number (Max-User-Num) of users who can access the service (e.g., including the associated communication network) through the requesting WTRU. The TES can obtain Max-User-Num from the WTRU's subscription data (e.g., provided by the NF or network device such as a UDM). The AF or NF can pre-configure the WTRU's Max-User-Num and notify the TES of the pre-configuration. The TES can transmit Max-User-Num to the TEC (e.g., in...). Figure 14(13 locations). The TEC can limit the number of users allowed to use the WTRU so that this number does not exceed Max-User-Num (e.g., assuming the requesting WTRU has one TEC). The TES can maintain a user authentication record that indicates 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 authenticated users exceeds Max-User-Num, the TES may disallow any authentication requests for users from the same TEC (e.g., unless the TES increments Max-User-Num).

[0148] The SRC described herein may include one or more of the following: The SRC may include a credential-type that indicates whether the SRC is associated with a service request. The SRC may include an SRC-Creator, which may be an identifier of the SRC creator (e.g., the identifier may be a TES-ID that identifies the TES). The SRC may include a SAUC-ID, which may be an identifier of the authorized SAUC that caused the creation of the SRC (e.g., in...). Figure 14 The SRC may include an SG-ID, which can be the name or identifier of the SG associated with the SRC. The SRC may include one or more SG-Services, which can indicate the corresponding name / type / identifier of a list of services belonging to the SG represented by the SG-ID. The SRC may include a Service-Provider, which can be an identifier of a service provider that can provide the services described in the SG-Services. In the example, the Service-Provider may be set to the identifier of the visited network (e.g., PLMN-ID), where the services in the SG-Services can be hosted. The SRC may include a Service-Requester, which can be an identifier of the service requester to whom the SG is assigned (e.g., WTRU-DUID).

[0149] An SRC can include one or more WTRU-Anchors, which can be a list of WTRUs. A service requester can be allowed to present the SRC through this list of WTRUs to access the service described in the SG-Services. Users (e.g., represented by WTRU-DUID) can request access to the service at different times via different WTRUs. The TES can determine and select additional WTRUs (e.g., in addition to the WTRU-ID provided at point 1) as the user's WTRU-Anchors. In the example, it can be... Figure 14 A single point provides multiple WTRU-IDs, and the TES can use other network functions (e.g., SEAF, UDM, etc.) to check whether a user can use those WTRU-IDs to request services from the network after user-centric trust authentication. Those WTRU-IDs can be included in WTRU-Anchors.

[0150] In the example, an SRC may include a set of service policies (e.g., constraints, rules, and / or policies) that describe the conditions under which a Service-Requester uses an SRC to access a service described by an SG-Services. For example, conditions may instruct a Service-Requester to use an SRC to access a service only at a specific time, at a specific location, and / or from a specific WTRU anchor.

[0151] The Service Requestor (SRC) can include an Expiration Time (SRC-Expiration-Time), which can be the expiration date of the SRC. For example, when the SRC-Expiration-Time expires, the SRC can be considered expired or invalid, and the Service Requestor can no longer use the SRC to access the SG service.

[0152] An SRC may include an SRC-Signature-Scheme, which may be a scheme for generating an SRC-signature and / or a scheme for verifying an SRC-Signature.

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

[0154] exist Figure 14At point 10, the TES can (e.g., if 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 an identifier of the requesting WTRU. The UAR may include a TEC-ID, which may be an identifier of a TEC. The UAR may include a TES-ID, which may be an identifier of the TES. The UAR may include a WTRU-DUID, which may be a DUID of the requesting WTRU and / or its users. The UAR may include a SAUC-ID, which may be an 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 an identifier of the generated SRC.

[0155] exist Figure 14 At point 11, TES can store UAR in DLS or other distributed data repositories.

[0156] exist Figure 14 At point 12, TES can send user authentication notifications (e.g., including UAR) to NFy and / or other network functions (e.g., UDSF).

[0157] exist Figure 14 At point 13, TES can send a user authentication response to TEC. In the example, this response may include: WTRU-DUID (e.g., WTRU-SAUC has been authenticated as a valid WTRU-DUID), the SG determined at point 9, and / or one or more SRCs. In the example, this response may include UAR and / or one or more SRCs.

[0158] exist Figure 14 At point 14, the requester WTRU and / or its users can begin using the SRC received from point 13 to access services from a service provider (e.g., NF or another WTRU). The requester WTRU or its users can transmit a service request, including the SRC, to the service provider for access to the service.

[0159] Figure 15 This illustrates an example of network-initiated, user-centric trust authentication. For example... Figure 15As shown, a User-Centric Trust Authentication Initiator (UCTAI) can trigger user authorization for a requester WTRU and / or its users. The UCTAI can be an AF, NF, or network device. The UCTAI can utilize the UCT authentication functionality / service provided by the TES to authenticate the target WTRU and / or its users. In the example, the AF may know that a user is currently attempting to access a service on the network from the requester WTRU, but the user may not yet be authorized, or a previous authorization may have expired. Therefore, the AF can act as the UCTAI and request the TES to authenticate the user. In the example, this operation can occur if the UCTAI receives a service request from an unauthorized requester WTRU and / or an unauthorized user.

[0160] exist Figure 15 At point 1, UCTAI can determine whether to perform user authentication for the requesting WTRU and / or its users. UCTAI can be a function on another WTRU that provides services to the requesting WTRU and / or its users. UCTAI can transmit a user authentication notification to the TES, which may include one or more of the following: The authorization notification may include a WTRU-ID, which may be an identifier of the requesting WTRU. The authorization notification may include a WTRU-DUID, which may identify the requesting WTRU and one or more users of the requesting WTRU. The WTRU-DUID may include a list of DUIDs (e.g., one DUID per user). The authorization notification may include a UCTAI-ID, which may be an identifier of the UCTAI (e.g., an AF identifier, an NF identifier, etc.).

[0161] exist Figure 15 At point 2, the TES can receive a notification from point 1. The TES can check whether the UCTAI is allowed to trigger UCT authentication against the requester WTRU and / or its users (e.g., based on the policy and subscription data of the requester WTRU and / or its users, the TES can retrieve policy and subscription data from other NFs (such as PCF and / or UDM). If the UCTAI is not allowed to trigger UCT authentication, the TES can send a denial response to the UCTAI and can skip other authentication-related actions / operations. If the UCTAI is allowed to trigger UCT authentication, the TES can use the WTRU-ID and / or WTRU-DUID included in the notification to find the corresponding TEC (e.g., the TEC can be hosted on the requester WTRU).

[0162] exist Figure 15At point 3, the TES can determine one or more SAUC requests (SAUC-REQs) for the requesting WTRU based on the WTRU-DUID and / or policies that the TES can retrieve from network devices (e.g., PCFs). For example, the SAUC-REQ can specify the SAUC-Type (e.g., the SAUC for the service consumer), which can indicate the type of SAUC that the TEC can transmit at point 6 below.

[0163] exist Figure 15 At point 4, UCTAI can transmit a user authentication notification to TEC, which may include one or more of the following: Authorization notification may include a WTRU-ID, which can be received at point 1. Authorization notification may include a WTRU-DUID, which can be received at point 1. Authorization notification may include a UCTAI-ID, which can be received at point 1. Authorization notification may include one or more SAUC-REQs, which can be determined at point 3. Authorization notification may include a TES-ID, which may be an identifier for the TES used to receive the user authentication request at point 6.

[0164] In the example, UCTAI can (e.g., as) Figure 15 An alternative method to the operations described in points 1 through 4 will be to directly transmit the same user authentication notification described in point 4 to the requesting WTRU (e.g., using 3GPP NAS signaling, data plane signaling, or SBI-based messaging). The requesting WTRU can then instruct its TEC to perform operation 5 and / or other operations described below.

[0165] exist Figure 15 At point 5, the TEC can receive a notification from point 4. The TEC can determine whether the UCTAI is permitted to trigger UCT authentication. If the UCTAI is not permitted to trigger UCT authentication, the TEC can send a rejection response to the TES and / or the UCTAI, and can skip other authentication-related actions / operations. In the example, the TEC can provide the received user authentication notification to the corresponding user (e.g., as indicated by WTRU-DUID at point 4) for user approval. The user can approve the user authentication notification and send an approval message to the TEC. In response, the TEC can use the WTRU-DUID and / or WTRU-ID included in the notification to find (or from the requester WTRU and / or its user request) the appropriate SAUC that meets the requirements described by the SAUC-REQ.

[0166] exist Figure 15 At the six locations, something similar can be executed. Figure 14Operation 1. The user authentication request at point 6 may include the identifier of UCTAI (i.e., UCTAI-ID).

[0167] exist Figure 15 At the 7 locations, similar actions can be performed. Figure 14 The operations shown in 2 to 12 can be performed and a UAR can be generated as a result.

[0168] exist Figure 15 At the 8 locations, similar actions can be performed. Figure 14 Operation 13.

[0169] exist Figure 15 At point 9, TES can send a user authentication confirmation to UCTAI (e.g., represented by UCTAI-ID), which may include the UAR generated at point 7.

[0170] exist Figure 15 At 10 locations, similar actions can be performed. Figure 14 Operation 14. If UCTAI is a function at another WTRU that provides services to the requesting WTRU, the requesting WTRU and / or its users may also transmit a service request, including the relevant SRC, to the other WTRU.

[0171] Figure 16 An example process for user-centric mutual authentication is shown, where the requesting WTRU (as a consumer) and the service provider (e.g., an NF, DN, or another WTRU in a mobile network) can authenticate each other using the interaction between the TEC and the TES (e.g., direct authentication without the use of a centralized third party). Figure 16 In the example, the TEC can be part of the requester WTRU, and the two entities (e.g., the TEC and the requester WTRU) can trust each other. Furthermore, the TES can be part of the service provider and can be trusted by the service provider.

[0172] exist Figure 16 At point 1, something similar can be executed. Figure 14 The operation of step 1. The user authentication request transmitted during the operation may include parameters (e.g., Mutual-Auth-REQ) that may indicate to the WTRU, the WTRU user, and / or the TEC the network that might expect to authenticate to the WTRU / user / TEC. The request may also indicate the type of network credentials that the TES can transmit to the TEC at step 3.

[0173] exist Figure 16 At the two locations, something similar can be executed. Figure 14 The operations at positions 2 to 10. For example, TES can... Figure 16Two points are used to certify WTRU-SAUC.

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

[0175] exist Figure 16 At four points, TEC can authenticate the SPC included in the user authentication response from TES. The SPC may include the signature of the SPC issuer, and TEC can authenticate the SPC by verifying that the signature indeed comes from the SPC issuer. To do this, TEC can retrieve the SPC issuer's public key and other relevant information (e.g., the scheme the SPC issuer can use to generate the signature) from DLS or other distributed entities.

[0176] exist Figure 16 At point 5, the TEC can send a user authentication confirmation to the TES. If the SPC is not authenticated at point 4, the 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 successful mutual authentication.

[0177] exist Figure 16 At point 6, TES can add the SPC-ID (e.g., the identifier of an SPC certified by TEC) to the generated UAR.

[0178] exist Figure 16 At these 7 locations, similar actions can be performed. Figure 14 The operations at position 11.

[0179] exist Figure 16 At the 8 locations, similar actions can be performed. Figure 14 The operations at position 12.

[0180] exist Figure 16 At 9 locations, similar actions can be performed. Figure 14 The operations at position 14.

[0181] User trust established based on authorized SAUCs allows users to use multiple WTRUs at different times and / or locations. This approach avoids users presenting the same SAUC to the TES from different WTRUs. Figure 17An example process for user-centric trust authentication for multiple WTRUs is shown, where user 1 can use WTRU1 at time T1 and switch to using WTRU2 at time T2. This example process may include one or more of the following operations.

[0182] exist Figure 17 At point 1, something similar can be executed. Figure 14 The operation of 1. The user authentication request transmitted during the operation may include one or more of the following parameters: The user authentication request may include User1-DUID, which may be the DUID of User 1. The user authentication request may include WTRU2-ID, which may be an identifier of WTRU2. WTRU1 or TEC1 can obtain the WTRU2-ID via various methods. In the example, WTRU1 / TEC1 can discover the WTRU2-ID through direct device discovery (e.g., as part of a proximity service). In the example, TEC1 may be configured with a WTRU2-ID when it is registered to the TES. In the example, the WTRU2-ID may be pre-configured in WTRU1 / TEC1 or may be configured via device management functions.

[0183] exist Figure 17 The user authentication request transmitted at point 1 may include a WTRU2-DUID, which can be the DUID of WTRU2. WTRU1 or TEC1 can obtain the WTRU2-DUID through various methods. In the example, TEC1 can discover the WTRU2-DUID through direct device discovery (e.g., as part of a proximity service). In the example, TEC1 can be configured with a WTRU2-DUID when it is registered to the TES. In the example, the WTRU2-DUID can be pre-configured in WTRU1 / TEC1, or it can be configured via device management functions.

[0184] exist Figure 17 The user authentication request transmitted at point 1 may include a TEC2-ID, which can be an identifier for TEC2. WTRU1 or TEC1 can obtain the TEC2-ID via various methods. In the example, TEC1 can discover the TEC2-ID through direct device discovery (e.g., as part of a proximity service). In the example, TEC1 can be configured with a TEC2-ID when it is registered to the TES. In the example, the TEC2-ID can be pre-configured in WTRU1 / TEC1, or it can be configured via device management functions.

[0185] exist Figure 17 At the two locations, something similar can be executed. Figure 14 The operations at points 2 through 12 are as follows. If WTRU2 / TEC2 is not included at point 1, the TES can select WTRU2 and / or TEC2 that User 1 can use in the future. For example, the TES can examine User 1's subscription data (e.g., stored on the UDM) which indicates a list of WTRUs for which User 1 is allowed to use a subscription. The TES can use the corresponding WTRU-ID of these subscription WTRUs to find the corresponding TEC for each subscription WTRU (e.g., assuming each TEC has been registered to the TES). If WTRU2-ID, WTRU2-DUID, and TEC2-ID are provided at point 1, the TES may not select additional WTRUs / TECs for User 1. In the example, before point 3 and after point 2, the TES can transmit the list of selected WTRUs (e.g., WTRU2-ID or WTRU2-DUID) to TEC1, which can then provide the list to User 1 for approval. If User 1 approves the list, TEC1 can transmit confirmation to the TES, which can then proceed with the operations described below. If User 1 has not approved the list, TEC1 can send a message to TES stating "The selected WTRU has not been approved by User 1". TES can then proceed without contacting WTRU2 / REC2 and may execute (e.g., simply execute). Figure 17 6 and 7.

[0186] exist Figure 17 At point 3, TES can transmit user notifications to TEC2. These user notifications may include one or more of the following parameters: User notification may include User1-DUID, which can be the DUID of User 1. User notification may include TEC1-ID, which can be the identifier of TEC1. User notification may include WTRU1-DUID, which can be the DUID of WTRU1. User notification may include WTRU1-ID, which can be the 3GPP identifier of WTRU1. User notification may include User1-SRC-ID, which can be the identifier of the SRC generated by TES for User 1 as part of the operation at point 2.

[0187] exist Figure 17 At point 4, TEC2 can verify the User1-DUID received in step 3. Based on the User1-SRC-ID received in step 3, TEC2 can retrieve the corresponding SRC for User1 from TEC1 (if TEC1 has stored the corresponding SRC for User1 locally) or from TES. This step is similar to... Figure 13Step 5. If User1-DUID is valid, TEC2 / WTRU2 can optionally accept User1's use of WTRU2 based on some local policies.

[0188] exist Figure 17 At point 5, TEC2 can send a user confirmation to TES, which indicates whether TEC2 / WTRU2 accepts user 1's use of WTRU2.

[0189] exist Figure 17 At the six locations, something similar can be executed. Figure 14 The operations at point 13. The user authentication response transmitted during the operation may include one or more of the following parameters: The user authentication response may include a TEC2-ID, which may be an identifier of a TEC2. The user authentication response may include a WTRU2-ID, which may be an identifier of a WTRU2. The user authentication response may include a WTRU2-DUID, which may be a DUID of a WTRU2.

[0190] exist Figure 17 At point 7, the TES can transmit user authentication notifications to one or more services provided by the network that user 1 can access. This user authorization notification may include information related to... Figure 17 The six user authentication responses sent contained the same (e.g., essentially similar) information.

[0191] exist Figure 17At point 8, User 1 (e.g., after using WTRU1 for some time) can switch to using WTRU2. Since User 1 may have already been authenticated to use WTRU2, and TEC2 can know this via the operation at point 3, TEC2 can avoid initiating user-centric trust authentication for User 1. TEC2 can send a service request to the service at the network. The service request may include one or more of the following parameters: The service request may include TEC2-ID, which may be an identifier of TEC2. The service request may include WTRU2-DUID, which may be a DUID of WTRU2. The service request may include WTRU2-ID, which may be an identifier of WTRU2. The service request may include User1-SRC-ID, which may be an identifier of the SRC generated by TES for User 1 as part of the operation at point 2. If TEC2 has already retrieved the corresponding SRC from TEC1 or TES at point 4, then User1-SRC-ID may include that SRC. The service request may include User1-DUID, which can be the DUID of user 1. The service request may also include User1-DUID-Signature, which can be a signature of User1-DUID. In the example, this signature can be generated by the real user 1 using their private key through User1-DUID.

[0192] Upon receiving a service request, the service at the network can check whether the User1-DUID-signature was generated by the real User1 using User1's public key. The service can also check whether the information provided at point 8 matches the information received at point 7. If the information matches, the requested service can be provided to User1 via WTRU2.

[0193] User-level registration can 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., user-centric trust authentication initiated by a WTRU) can be implemented via a cellular communication network (e.g., a 5G or 6G network) in several ways. One or more TEC functions can be embedded in the WTRU. One or more TES functions can be implemented as part of the AMF. The NFy described herein can be a SEAF. WTRU registration based on primary authentication and WTRU subscription data can be considered as subscription-level registration. User-centric trust authentication can be used to implement user-level registration (ULR) of the WTRU and / or its users to the cellular network. WTRU registration and ULR can be jointly implemented through one or more of the following methods (but not limited to):

[0194] In the example, such as Figure 18 As shown, after WTRU registration, ULR can be performed, whereby WTRU can perform WTRU registration with AMF, and AMF can instruct WTRU to perform ULR.

[0195] In the example, such as Figure 19 As shown, WTRU registration can be performed after ULR, whereby WTRU can execute ULR to AMF, after which WTRU registration can be performed.

[0196] In the example, such as Figure 20 As shown, WTRU registration and ULR can be integrated, where WTRU can use a registration request to trigger both WTRU registration and ULR to the AMF.

[0197] Figure 18 An example of performing WTRU registration followed by ULR is shown, which may include one or more of the following operations.

[0198] exist Figure 18 At point 1, the WTRU can perform WTRU registration, which can be based on the master authentication and interactions between several NFs (such as AMF, SEAF, and UDM).

[0199] exist Figure 18 At point 2, if primary authentication is successful and WTRU registration is accepted, the AMF may send a registration acceptance message to the WTRU. This message may include one or more of the following parameters related to the ULR: The message may include a ULRIndicator, which may indicate (e.g., via ULRIndicator="True") that the WTRU can perform the ULR using credentials supported by the AMF (e.g., as indicated in the Supported Credential Type (SCT)). The message may include an SCT, which may indicate the types of credentials the AMF can support for the ULR.

[0200] exist Figure 18 At point 3, the WTRU can instruct its users on the SCT. Users can prepare their DUID and / or SAUC that match the SCT. An example of an SCT could be "a credential issued by any of the following mobile operators: Mobile Operator A, Mobile Operator B, etc." As another example, an SCT could be "a driver's license credential," "a work permit credential," "organizational membership," etc.

[0201] exist Figure 18 At the four locations, WTRU can receive the user's SAUC and DUID.

[0202] exist Figure 18At point 5, the WTRU can send a ULR request to the AMF. The ULR request can include one or more of the following parameters: The ULR request can include a RegLevel, which can indicate that the ULR is a user-level registration. The ULR request can include an SAUC, which can be the SAUC of a user matching the SCT. The ULR request can include a DUID, which can be the user's DUID. The ULR request can include a DLS-ID, which can be associated with... Figure 14 The DLS-ID provided at point 1 is the same.

[0203] exist Figure 18 At point 6, the AMF can receive ULR requests and perform user-centric trust authentication (e.g., similar to...). Figure 14 (2 to 12). AMF can utilize TES to perform user-centric trust authentication (e.g., similar to...). Figure 14 (2 to 12). As a result of user-centric trust authentication, a UAR can be created. The AMF (or the TES that the AMF may utilize) can determine one or more of the following parameters for the WTRU.

[0204] The AMF can determine the AcceptedRegistrationLevel, which indicates the accepted registration level (e.g., user-level registration). The AMF can determine the duration (e.g., indicated by UserLevelPeriodicalRegistrationUpdateTimer), which indicates the period during which the WTRU performs a periodic ULR. This timer can be the same as or different from the timer used for periodic WTRU registration. The AMF can determine the ULRArea, which indicates a location-related area. If the WTRU moves to or out of these areas (e.g., across state or country), the WTRU may perform a periodic ULR. In the example, the ULRArea can be set to one or more specific service areas. The AMF can determine the NoULRArea, which indicates a location-related area. If the WTRU moves to or out of these areas (e.g., a user's residence), the WTRU may not perform a periodic ULR. In the example, the NoULRArea can be set to one or more specific service areas.

[0205] exist Figure 18At point 7, the AMF can transmit the user's SAUC and / or DUID to the UDM and associate them with the WTRU identifier (e.g., SUPI, SUCI, GUTI, etc.). The AMF can also transmit ULRArea and / or NoULRArea to the UDM. The AMF can also store the user's SAUC and / or DUID, as well as the WTRU identifier.

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

[0207] exist Figure 18 At point 9, the WTRU can send a registration completion message to the AMF, indicating the completion of both WTRU and ULR registration. The WTRU / user can use the SRC to access services as described in the SG-Services from the network. The WTRU / user can re-execute the ULR based on the conditions described in UserLevelPeriodicalRegistrationUpdateTimer and / or ULRArea.

[0208] Figure 19 An example procedure for performing a ULR followed by WTRU registration is shown, which may include one or more of the following operations.

[0209] exist Figure 19 At point 1, something similar can be executed. Figure 18 The operations at point 5. WTRU can send a ULR request to AMF, which can be triggered by the user. The user can pass their SAUC and / or DUID to WTRU.

[0210] exist Figure 19 At the two locations, something similar can be executed. Figure 18 The operations at point 6.

[0211] exist Figure 19 At these three locations, something similar can be executed. Figure 18 The operations at point 7.

[0212] exist Figure 19 At the four locations, something similar can be executed. Figure 18 Operation 8. The ULR may also include WTRURegIndicator (="true") to request WTRU to perform WTRU registration in subsequent steps.

[0213] exist Figure 19 At the 5 locations, something similar can be executed. Figure 18 The operations at point 1. AMF can adjust the values ​​of one or more of the SRC, SG-Services, ULRArea, NoULRArea, or UserLevelPeriodicRegistrationUpdateTimer determined at point 2 based on the WTRU registration results. AMF can then transmit the adjusted values ​​to UDM.

[0214] exist Figure 19 At point 6, the AMF can send a registration acceptance message to the WTRU. This message can include any of the following if one or more of the SRC, SG-Services, ULRArea, NoULRArea, or UserLevelPeriodicRegistrationUpdateTimer are modified at point 5.

[0215] exist Figure 19 At these 7 locations, similar actions can be performed. Figure 18 The operations at point 9. WTRU can use SRC to access services as described in SG-Services from the network. WTRU can re-execute ULR based on conditions described in UserLevelPeriodicalRegistrationUpdateTimer and / or ULRArea.

[0216] Figure 20 An example procedure for performing integrated ULR registration and WTRU registration is shown, which may include one or more of the following operations.

[0217] exist Figure 20At point 1, the WTRU can transmit a registration request to the AMF (e.g., the registration request can be triggered by a WTRU user who has passed their SAUC and / or DUID to the WTRU). The registration request can include one or more of the following (e.g., similar to...). Figure 18 (Those described in the 5 places). The registration request may include a RegLevel, which can indicate that the registration request is associated with both WTRU registration and ULR registration. The registration request may include an SAUC, which can be associated with... Figure 18 The five descriptions of SAUC are identical. The registration request may include a DUID, which can be related to... Figure 18 The DUID described in the five places is the same. The registration request may include a DLS-ID, which can be the same as the one described in [the original text]. Figure 18 The five descriptions of the DLS-ID are the same.

[0218] exist Figure 20 At point 2, the AMF can perform operations associated with WTRU registration and / or master authentication, which can be based on the interaction of multiple NFs (such as AMF, SEAF, and / or UDM).

[0219] exist Figure 20 At these three locations, something similar can be executed. Figure 18 The operations at point 6. Based on the policies that the AMF can retrieve from the PCF, if primary authentication fails, the AMF may or may not perform user-centric trust authentication.

[0220] In the example, AMF can interchange the operations at point 2 with those at point 3 (for example, AMF can perform user-centric trust authentication first). If user-centric trust authentication fails, AMF can proceed with WTRU registration.

[0221] exist Figure 20 At the four locations, something similar can be executed. Figure 18 The operations at point 7.

[0222] exist Figure 20At point 5, the AMF can send a registration acceptance message to the WTRU. This registration acceptance message can include one or more of the following parameters: The registration acceptance message can include AcceptedRegistrationLevel, which can indicate whether the WTRU registration at point 2 and / or the user-centric trust authentication at point 3 were successful. The registration acceptance message can include one or more of UAR, SRC, SG-Services, ULRArea, NoULRArea, or UserLevelPeriodicRegistrationUpdateTimer, as shown in... Figure 18 The 8 descriptions.

[0223] exist Figure 20 At the six locations, something similar can be executed. Figure 18 The operations at point 9. WTRU can use SRC to access services described in SG-Services from the network. WTRU can re-execute ULR based on conditions described in UserLevelPeriodicalRegistrationUpdateTimer and / or ULRArea.

[0224] In the example, the WTRU can receive a first user authentication notification from a network device or function (e.g., TES). This notification may include the WTRU's DUID and / or an SAUC requirement associated with generating the SAUC. The WTRU can prepare the SAUC based on the SAUC requirement and further prepare a user authentication request, which may include identifiers of the WTRU and / or the SAUC. The WTRU can transmit the user authentication request to the network device or function and can receive a user authentication response from the network device or function. This response may include a user authentication record, information about one or more authorized services, and / or service request credentials for the WTRU. The WTRU can use the service request credentials to access one or more authorized services.

[0225] Although the features and elements described above are given in specific combinations, each feature or element may be used alone without the other features and elements of the preferred embodiment, or in various combinations with or without the other features and elements. While the embodiments described herein may be contemplated for 3GPP-specific protocols, it should be understood that the embodiments described herein are not limited to this and may be applicable to other wireless systems. For example, although the solutions described herein contemplate LTE, LTE-A, New Radio (NR), or 5G-specific protocols, it should be understood that the solutions described herein are not limited to this and may also be applicable to other wireless systems.

[0226] The processes described herein can be implemented in computer programs, software, and / or firmware incorporated into computer-readable media for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as, but not limited to, internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM discs and / or digital versatile disks (DVDs). The processor associated with the software can be used to implement a radio frequency transceiver for WTRUs, terminals, base stations, RNCs, and / or any host computer.

Claims

1. A wireless transmit / receive unit (WTRU), comprising: Processor, the processor being configured to: Sending an authentication request to another device via a wireless communication network, wherein the authentication request includes: the authentication request is an indication to a user of the WTRU, and the authentication request further includes: credentials of the user associated with one or more services available via the wireless communication network; Receive an authentication response from another 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, then at least one of the one or more services can be accessed via the wireless communication network based on the information included in the authentication response.

2. The WTRU of claim 1, wherein the user of the WTRU includes: The WTRU is a human user, 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 comprises: One or more identifiers that identify the user or the WTRU.

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

5. The WTRU of claim 1, wherein the authentication request further indicates a service category or 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 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 is configured to access at least one of the one or more services based on the information included in the authentication response, comprising: The processor is configured to include the credentials used to access the service group in the 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 instruction from the other device to perform user-based authentication, and wherein the authentication request is sent in response to receiving the instruction.

11. The WTRU of claim 1, wherein the authentication response indicates a region in which user-based authentication is permitted or a period for updating the authentication request for the user.

12. A method implemented by a wireless transmit / receive unit (WTRU), the method comprising: Sending an authentication request to another device via a wireless communication network, wherein the authentication request includes: the authentication request is an indication to a user of the WTRU, and the authentication request further includes: credentials of the user associated with one or more services available via the wireless communication network; Receive an authentication response from another 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, then at least one of the one or more services can be accessed via the wireless communication network based on the information included in the authentication response.

13. The method of claim 12, wherein the user of the WTRU comprises: The WTRU is a human user, 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 comprises: One or more identifiers that identify the user or the WTRU.

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

16. The method of claim 12, wherein the authentication request further indicates a service category or 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 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 at least one of the one or more services based on the information included in the authentication response comprises: The credentials for accessing the service group are transmitted in the 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: Receive an instruction from the other device to perform user-based authentication, wherein the authentication request is sent in response to receiving the instruction.

22. The method of claim 12, wherein the authentication response indicates a region in which user-based authentication is permitted or a period for updating the authentication request for the user.

23. A network device associated with a wireless communication network, wherein the network device includes 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: The authentication request is an instruction to the user of the WTRU, and the authentication request further includes: credentials of the user associated with one or more services available via the wireless communication network; Based on the authentication request, it is determined whether the user is authorized to access the one or more services via the wireless communication network; and An authentication response is sent 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 the processor is further configured to include credentials for accessing the one or more services in the authentication response based on a determination that the user is authorized to access the service.

Images