Method, apparatus and system for user-centric and decentralized roaming

Abstract

A wireless transmit / receive unit (WTRU) may transmit a roaming request to a network. The network may be a visited network. The roaming request may include an address associated with the WTRU roaming attestation transaction. The WTRU may receive an authentication vector dependent on an authentication policy described in the WTRU roaming attestation transaction. The WTRU may generate an authentication response based on the authentication policy. The WTRU may transmit the authentication response to the network. The WTRU may receive a notification from the network. The notification may indicate whether the roaming request has been successful.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This patent application claims the benefit of U.S. Provisional Patent Application No. 63 / 399,115, filed on August 18, 2022, the entire contents of which are incorporated herein by reference. Background Art

[0003] Cellular networks are moving towards complex systems with heterogeneous participants. Reliable wireless communication coverage and service provisioning require uninterrupted connectivity between wireless communication components, including radio cells and core networks. Due to the high mobility of WTRUs, reliable but uninterrupted connectivity remains a challenge. Roaming in wireless communications alleviates the problem of connectivity interruptions and ensures full wireless communication coverage for subscribers accessing other networks (e.g., roaming WTRUs). Roaming extends the coverage of the home network (HN) operator, allowing the mobile WTRUs of the HN operator to use the network and services provided by another network operator, known as the visited network (VN). According to 3GPP, there are two roaming implementations based on the geographic locations of the visited network and the home network. The first roaming implementation is a domestic roaming service, in which a roaming WTRU utilizes the network resources of another network operator within the same geographic location of the HN of the roaming WTRU. Another roaming implementation is international roaming, in which the UE utilizes the network coverage of a VN located in another geographic location of the HN of the WTRU.

[0004] The two roaming models are the home routing (HR) and local breakout (LBO) models. Both models (e.g., HR and LBO) rely on a new network function called the Security Edge Protection Proxy (SEPP). SEPP acts as a service relay between the VN and the HN, thereby providing a secure connection and hiding the complexity of the network topology of both the VN and the HN. In addition, the application function (AF) in the two networks (i.e., HN and VN) interacts with the 5GC to provide the required services, such as traffic routing or policy control. The AUSF within the HN is responsible for performing authentication between the WTRU and the 5GC. It is worth noting that in both models (e.g., LBO and HN), the HN is responsible for authenticating the roaming WTRU and verifying the roaming WTRU to the VN. For example, the HN can use one of the authentication mechanisms such as 5G-AKA to authenticate the roaming WTRU. During the authentication process, the HN reveals a permanent identifier (e.g., SUPI) to the VN to ensure authentication and verification of the roaming WTRU identity to the VN. Summary of the invention

[0005] Methods and apparatus for user-centric decentralized roaming for wireless communications are provided. Methods and apparatus for roaming service enablement are provided. Methods and apparatus for roaming service activation are provided. Methods and apparatus for roaming wireless transmit / receive unit (WTRU) mutual authentication and / or initial access are provided. Methods and apparatus for roaming WTRU temporary visited network (VN) accessibility are provided.

[0006] The WTRU may transmit a roaming request to a network. The network may be a visited network. The roaming request may include an address associated with a WTRU roaming certification transaction. The WTRU may receive an authentication vector depending on an authentication policy described in the WTRU roaming certification transaction. The WTRU may generate an authentication response based on the authentication policy. The WTRU may transmit the authentication response to the network. The WTRU may receive a notification from the network. The notification may indicate whether the roaming request has been successful.

[0007] The WTRU may perform a method in which the WTRU transmits a request to a first network system to request a roaming proof address from the first network system. The first network system includes a home network system through which the WTRU is registered for performing wireless communications. The WTRU may receive a response from the first network system including a roaming proof address, wherein the roaming proof address includes an address to a second network system, wherein roaming proof information can be accessed via the roaming proof address. The WTRU transmits the roaming proof address to a third network system to access the third network system, wherein the third network system is a visited network system. The WTRU receives an authentication request from the third network system, wherein the authentication request includes a request to perform authentication based on the roaming proof information, and transmits an authentication response to the third network system, wherein the authentication response includes a response to the authentication request based on the roaming proof information. The third network system may retrieve the roaming proof information from the second network system according to the roaming proof address. The roaming proof information may be accessible via a distributed ledger, wherein the distributed ledger may include a blockchain.

[0008] The WTRU may access the roaming certification information using a distributed ledger. The distributed ledger may include a blockchain.

[0009] The request transmitted by the WTRU may include an indication of the authentication policies supported by the WTRU. The authentication policies may include an RSA (Rivest-Shamir-Adleman) authentication policy or a Chameleon Hash (CH) authentication policy. The request transmitted by the WTRU may also include an indication of the lifetime of the roaming certification address and the location of the WTRU.

[0010] The WTRU receives an authentication challenge from the third network system, wherein the authentication challenge may be determined based on the authentication policy supported by the WTRU. The authentication policy supported by the WTRU may include RSA or CH authentication policy. The WTRU may also perform an authentication challenge to determine the authentication response.

[0011] The WTRU receives the response from the first network system, wherein the response includes the roaming proof address, authentication parameters (eg, WTRU roaming proof parameters (WTRU-RPP)), and a WTRU proof value that may be used to anonymously authenticate the WTRU.

[0012] The WTRU transmits a request to the blockchain system to obtain one or more public keys of the third network system to verify and authenticate the third network system. The WTRU may receive a response from the third network system including one or more public keys of the third network system.

[0013] The WTRU may receive an indication of the completion of the authentication from the third network system.

[0014] The WTRU may include a processor configured to transmit a request to a first network system to request a roaming proof address from the first network system. The first network system includes a home network system through which the WTRU is registered for performing wireless communications. The one or more processors may also be configured to receive a response including the roaming proof address from the first network system, wherein the roaming proof address includes an address to a second network system, wherein roaming proof information can be accessed via the roaming proof address. The processor may also be configured to transmit the roaming proof address to a third network system to access the third network system, wherein the third network system is a visited network system. The one or more processors may also be configured to receive an authentication request from the third network system, wherein the authentication request includes a request to perform authentication based on the roaming proof information. The processor may also be configured to transmit an authentication response to the third network system, wherein the authentication response includes a response to the authentication request based on the roaming proof information. The roaming proof information may be accessible via a distributed ledger, wherein the distributed ledger may include a blockchain.

[0015] The processor may be configured to transmit an indication of an authentication policy supported by the WTRU. The authentication policy may be an RSA authentication policy or a CH authentication policy.

[0016] The processor is configured to transmit a request to the first network system.The request may include an indication of the lifetime of the roaming proof and the location of the WTRU.

[0017] The processor is configured to receive an authentication challenge from the third network system, wherein the authentication challenge may be determined based on the authentication policy supported by the WTRU. The processor may execute the authentication challenge to determine the authentication response.

[0018] The processor is configured to receive a response from the first network system, wherein the response includes the roaming certification address. The response may also include authentication parameters (e.g., WTRU roaming certification parameters (WTRU-RPP)) and a WTRU certification value for anonymously authenticating the WTRU.

[0019] The processor may be configured to transmit to the blockchain end system a request to obtain one or more public keys of the third network system to verify and authenticate the third network system. The third network system includes the visited network system. The processor is also configured to receive from the third network system a response that may include one or more public keys of the third network system.

[0020] The processor may be further configured to receive an indication from the third network system indicating that the authentication is complete. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented;

[0022] Figure 1B is an example of an embodiment in which Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within an illustrated communication system;

[0023] Figure 1C is an example of an embodiment in which Figure 1A A system diagram of an example Radio Access Network (RAN) and an example Core Network (CN) used within the illustrated communication system;

[0024] Figure 1D is an example of an embodiment in which Figure 1A A system diagram of another example RAN and another example CN used within the illustrated communication system;

[0025] Figure 2 is a diagram illustrating an example of a Chameleon hash function;

[0026] Figure 3 is a diagram illustrating a 5G system architecture;

[0027] Figure 4 is a diagram illustrating an example of a general procedure in a 5G system architecture;

[0028] Figure 5A and Figure 5B is a diagram illustrating an example of a roaming architecture;

[0029] Figure 6 is a diagram illustrating examples of different use cases for a decentralized roaming service;

[0030] Figure 7 is a diagram illustrating an example of an overview of a wireless transmit / receive unit (WTRU)-centric decentralized roaming model that may be provided;

[0031] Figure 8 is a table illustrating an example of a comparison between traditional roaming and WTRU-centric decentralized roaming;

[0032] Fig. 9 is a diagram illustrating an example of main procedures for implementing a WTRU-centric decentralized roaming service;

[0033] Fig.10 is a flow chart illustrating an example of roaming service activation;

[0034] Fig.11 is a flow chart illustrating an example of roaming service activation;

[0035] Fig.12 is a flow chart illustrating an example of an RSA-based authentication strategy;

[0036] Fig.13 is a flow chart illustrating an example of a Chameleon hash (CH) based authentication strategy;

[0037] Fig.14 is a flow chart illustrating an example of a mutual authentication phase;

[0038] Fig.15 is a flow chart illustrating an example of a mutual authentication phase according to an RSA-based authentication strategy;

[0039] Fig.16 is a flowchart illustrating an example of a mutual authentication phase according to a CH-based authentication strategy;

[0040] Fig.17 is a flow chart illustrating an example of an initial access phase;

[0041] Fig.18 is a flow chart illustrating an example of a roaming service agreement taking into account visited network (VN) certification;

[0042] Fig.19A and Fig.19B is a flow chart illustrating an example of a dual authentication phase;

[0043] Fig. 20is a flow chart illustrating an example of temporary VN accessibility for a roaming WTRU;

[0044] Fig.21A and Fig. 21B illustrates an example 3GPP service flow for roaming service enablement policy;

[0045] Fig. 22 is a flow chart illustrating an example of a 3GPP service flow for a roaming service activation level;

[0046] Fig.23A and Fig. 23B illustrates an example 3GPP service flow for a WTRU dual authentication level; and

[0047] Fig.24 is a flow chart illustrating an example of a 3GPP service flow for an initial access level. DETAILED DESCRIPTION

[0048] Figure 1A 1 is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through sharing of system resources (including wireless bandwidth). For example, the 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 spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, and filter bank multi-carrier (FBMC), etc.

[0049] like Figure 1AAs 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, but it should 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, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the UE 102a, 102b, 102c, 102d (any of which WTRUs may be referred to as a “station” and / or “STA”) may be configured to send and / or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain environment), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0050] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device that is configured to interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode B, a Home Node B, a Home eNode B, a gNB, an NR Node B, a site controller, an access point (AP), a wireless router, and the like. Although the base stations 114a, 114b are each depicted as a single element, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0051] 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 (BSC), radio network controllers (RNC), relay nodes, etc. Base station 114a and / or base station 114b may be configured to send and / or receive wireless signals on one or more carrier frequencies (which may be referred to as cells (not shown)). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of a licensed spectrum and an unlicensed spectrum. A cell may provide coverage of wireless services to a specific geographic area, which may be relatively fixed or may change over time. The cell may be further 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 for each sector of the cell. In an embodiment, 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 send and / or receive signals in a desired spatial direction.

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

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

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

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

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

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

[0058] Figure 1AThe base station 114b in may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial venues, homes, vehicles, campuses, industrial facilities, sky corridors (e.g., for use by drones), and roads. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology (such as IEEE 802.11) to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology (such as IEEE 802.15) to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or a femtocell. As Figure 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106 / 115.

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

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

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

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

[0063] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors 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. The processor 118 may perform signal decoding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0064] The send / receive element 122 may be configured to send a signal to a base station (e.g., base station 114a) or receive a signal from a base station via an air interface 116. For example, in one embodiment, the send / receive element 122 may be an antenna configured to send and / or receive an RF signal. In an embodiment, the send / receive element 122 may be a transmitter / detector configured to send and / or receive, for example, an IR, UV or visible light signal. In another embodiment, the send / receive element 122 may be configured to send and / or receive both an RF signal and an optical signal. It should be understood that the send / receive element 122 may be configured to send and / or receive any combination of wireless signals.

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

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

[0067] The processor 118 of the WTRU 102 may be coupled to and may 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) display unit or an organic light emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, and a secure digital (SD) memory card, among others. In other embodiments, the processor 118 may access information from and store data in a memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

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

[0069] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the 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 appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.

[0070] The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, module, FM radio unit, digital music player, media player, video game player module, Internet browser, virtual reality and / or augmented reality (VR / AR) device and activity tracker, etc. Peripheral device 138 may include one or more sensors, which may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, orientation sensor, proximity sensor, temperature sensor, time sensor; geolocation sensor; altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor and / or humidity sensor.

[0071] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for 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 139 for reducing and / or substantially eliminating self-interference via hardware (e.g., a choke) or via signal processing performed by a processor (e.g., a separate processor (not shown) or via the processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for both UL (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

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

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

[0074] Each of the evolved Node Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, and scheduling of users in the UL and / or DL, among other things. Figure 1C As shown, the eNode-Bs 160a, 160b, 160c may communicate with one another via an X2 interface.

[0075] Figure 1C The illustrated CN 106 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 depicted as being part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

[0077] The SGW 164 may be connected to each of the evolved Node-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring the user plane during an inter-evolved Node-B handover, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, and managing and storing the context of the WTRUs 102a, 102b, 102c.

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

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

[0080] Although the WTRU Figures 1A to 1D Although described as wireless terminals, it is contemplated that in certain representative embodiments, such terminals may (eg, temporarily or permanently) use a wired communications interface with a communications network.

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

[0082] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for a BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or carries traffic away from the BSS. Traffic originating from outside the BSS and destined for the STA may be reached by the AP and may be delivered to the STA. Traffic originating from the STA and destined for a target outside the BSS may be transmitted to the AP to be delivered to the corresponding target. Traffic between STAs within the BSS may be transmitted by the AP, for example, wherein the source STA may transmit traffic to the AP, and the AP may deliver traffic to the target STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. Point-to-point traffic may be transmitted between the source STA and the target STA (e.g., directly between them) using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (eg, all STAs in the STA) may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad hoc" communication mode.

[0083] When using the 802.11ac infrastructure operation mode or a similar operation mode, the AP may send beacons on a fixed channel (such as a primary channel). The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a width dynamically set via signaling. The primary channel may be an operating channel of the BSS and may be used by the STA to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access / collision avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. For CSMA / CA, a STA (e.g., each STA) (including the AP) may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0084] High throughput (HT) STAs may communicate using a 40 MHz wide channel (eg, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels) to form a 40 MHz wide channel.

[0085] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz channels and / or 80MHz channels can be formed by combining continuous 20MHz channels. 160MHz channels can be formed by combining 8 continuous 20MHz channels, or by combining two non-continuous 80MHz channels (this can be called 80+80 configuration). For 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be processed by inverse fast Fourier transform (IFFT) and time domain processing separately. These streams can be mapped to two 80MHz channels, and the data can be sent by the transmitter STA. At the receiver of the receiver STA, the above-mentioned operation for the 80+80 configuration can be reversed, and the combined data can be transmitted to the medium access control (MAC).

[0086] 802.11af and 802.11ah support operating modes below 1GHz. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support instrument type control / machine type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only support for) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0087] WLAN systems that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA (which supports the minimum bandwidth operating mode) from all STAs operating in the BSS. In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only support) 1MHz mode, the primary channel may 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 sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, because a STA (supporting only the 1MHz operating mode) is sending to the AP, the entire available band may be considered busy even if most of the band remains idle and may be available.

[0088] 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 bandwidth available for 802.11ah is 6MHz to 26MHz, depending on the country code.

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

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

[0091] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with parameter sets that may be scalable. For example, OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or Transmission Time Intervals (TTIs) of varying or scalable lengths (e.g., including varying numbers of OFDM symbols and / or varying absolute time lengths).

[0092] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c while not accessing other RANs (e.g., such as the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with the gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as the eNodeB 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNodeB 160a, 160b, 160c may act as a mobility anchor for the WTRUs 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0093] Each of the gNBs 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards a user plane function (UPF) 184a, 184b, routing of control plane information towards an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c may communicate with each other via an Xn interface.

[0094] Figure 1DThe illustrated CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possible data networks (DNs) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

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

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

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

[0099] Given that Figures 1A to 1D as well as Figures 1A to 1D , one or more or all of the functions described herein for one or more of the following may be performed by one or more simulation devices (not shown): WTRU 102a-102d, base station 114a-114b, evolved Node B 160a-160c, MME 162, SGW 164, PGW 166, gNB 180a-180c, AMF 182a-182ab, UPF 184a-184b, SMF 183a-183b, DN 185a-185b and / or any other device described herein. The simulation device may be one or more devices configured to mimic one or more or all of the functions described herein. For example, the simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

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

[0101] One or more simulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test scenario in a test laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network to implement testing of one or more components. One or more simulation devices can be test equipment. Direct RF coupling and / or wireless communication via RF circuits (e.g., which can include one or more antennas) can be used by the simulation device to send and / or receive data.

[0102] A blockchain system may be provided. Distributed ledger technology (DLT) generally refers to a shared, immutable and tamper-proof decentralized transaction record maintained across several computers linked in a peer-to-peer network. A distributed ledger (such as a blockchain) may facilitate recording transaction histories between two or more (e.g., multiple) entities that may not trust each other. Interactions between entities within a distributed ledger system (DLS) may be placed in a transaction pool until verified. The verified transactions may then be compressed to form a Merkle tree stored within a cryptographic chained block. In any DLS, network peers may follow a consensus mechanism to manage transaction and block verification. In other words, a consensus mechanism may be one that enables multiple network peers to have the same / consistent view / decision on the state of the ledger (e.g., which new transaction block may be attached to the ledger in each round, etc.). The consensus mechanism employed may vary depending on DLS requirements, type, verification speed, and application. The most common consensus protocols may be proof of work (PoW) and proof of stake (PoS).

[0103] Proof of Work (PoW) consensus protocols may be provided. For example, PoW may be the consensus mechanism adopted by the famous Bitcoin application. Block generation and verification in PoW may include a mining process. During the mining process, network peers (e.g., miners) may solve arbitrary puzzles that may require finding a random number for completing block generation. The motivation of the miner to correctly find the random number may be to win the corresponding block reward. The remaining network peers may then verify the efforts made by the winning miner and broadcast the generated block to other network peers. PoW may be known for exerting computing power in finding a unique random number value that meets the hash criteria of the generated block. Adopting a PoW mechanism can ensure fairness among competing miners and maintain system security; however, the PoW mechanism may require high energy consumption and / or longer processing time. On the other hand, Proof of Stake (PoS) has developed into a low-cost, energy-friendly consensus mechanism. PoS relies on the distribution of responsibilities to maintain the network. Therefore, the selection criteria of the validator may be based on the staked tokens. Staking more cryptocurrency gives the validator more opportunities to have the right to check new transaction blocks and add them to the distributed ledger. However, this also comes with the disadvantage of incentivizing cryptocurrency hoarding rather than spending.

[0104] Other consensus mechanisms (e.g., blockchain consensus mechanisms) may be provided herein. Delegated Proof of Stake (DPoS) and / or Practical Byzantine Fault Tolerance (PBFT) may require lower energy consumption, which may replace the computationally hungry PoW mechanism. DPoS may be a variant of PoS through which higher-staking miners can vote for several representatives who can manage and / or protect the DLS network. The voting and delegation mechanisms incentivize blockchain nodes to protect the network with their pledged collateral. In the PBFT mechanism, any block to be verified may require a certain number of blockchain nodes to agree on its validity. Nodes can reach consensus at a predetermined threshold (e.g., when a hypothetical Byzantine node votes for a particular decision more than three times).

[0105] There may be various types of DLS in this article, including public, private, alliance and licensed DLS. A public DLS may allow anyone to join, participate and access DLS records. The Bitcoin blockchain application may be a well-known example of a public DLS network. A private DLS may be a small-scale DLS that can be hosted within an internal local network governed by one or more (e.g., a single) organization. In a private DLS, there may be restrictions on who will generate transaction blocks and / or how to apply consensus protocols. The organization may oversee the DLS network and / or manage transaction generation, accessibility and / or verification. A licensed DLS may be comparable to a private DLS, where a single / multiple entity may control the network. Under the control of the management entity, any data accessibility can be private or public. A federation DLS may be a network governed by a group of organizations that control the execution of the consensus mechanism and / or maintain a shared ledger using a Byzantine fault-tolerant mechanism. The ruling organization may manage which data is stored in the ledger and / or the accessibility constraints on network transactions. Blockchain systems and DLTs may be used interchangeably in this article.

[0106] Generally speaking, a hash can be defined as a one-way function that accepts any input message of arbitrary length and can generate a unique random output, which can be represented as one or more of the hash values; hash output; fingerprint of the input; or fingerprint. Being a one-way function means that it may not be possible to derive the input message knowing only its hash. Hash schemes are usually characterized as collision-resistant, where any arbitrary change in the input message may result in a completely new hash value. The effectiveness and security of a hash function may be based on the possibility of finding a collision between two different messages (m1, m2). Therefore, in a more robust hash scheme, the possibility of finding a collision between two different input messages is almost negligible. The most well-known hash schemes are SHA256, SHA512, MD5, etc. According to the scheme, the hash output may have the same length. As an example, the length of the hash output of SHA256 can be 256 bits regardless of the length of the input message, and SHA512 can generate a 512-bit hash value. Therefore, any cryptographic hash function may have any of the following properties.

[0107] A cryptographic hash function can accept an input of any arbitrary length and produce an output of a fixed length.

[0108] A cryptographic hash function may include a one-way function such that given only the output, it may not be possible to identify the input.

[0109] Cryptographic hash functions may include collision resistance (or collision-free), where it may be nearly impossible to find two different input messages with the same hash value. Hash schemes can be used in applications that require integrity checks. For example, a backend server may use a hash scheme to store passwords by their hash values ​​to avoid keeping unencrypted data related to the stored passwords. When an online user specifies his password during a service request, the hash value of such a password may be compared with the hash value stored in the backend server database as a user identification and / or authentication check. Blockchain systems may be another example of demonstrating the strength of hash function schemes. The generated blocks in a blockchain system may be linked by their hash values, making the blockchain system immutable and tamper-proof. Although information integrity checks can be effectively obtained, other applications may require some flexibility to change data while keeping the calculated hash value the same. For example, the append-only nature of blockchains may have been abused, resulting in cryptocurrency criminals and hackers successfully injecting arbitrary illegal content into distributed ledgers.

[0110] As an alternative solution to traditional collision-free hashing schemes, Krawczyk and Rabin proposed a hashing scheme called Chameleon hashing (CH) in 2000. CH can provide a one-way function that generates an unpredictable hash value (h) for an input message (m). In theory, it may not be possible to extract the value of m given only the knowledge value of h. In addition, CH can also be a collision-free scheme, in which it may be impossible to find any two messages (m1, m2) that result in an exact hash value (h) unless a collision trapdoor key is employed. The difference between CH and other hashing schemes may be that CH utilizes a secret trapdoor key to enable the trapdoor and cause hash collisions. The owner of the secret trapdoor key may be a person who can cause two or more different input messages (m1, m2, …, m n ) between conflicting (e.g., unique) entities.

[0111] In terms of structure, the Chameleon hashing scheme may include a user-generated key pair, which may be a public key (Y) and / or a private trapdoor key (X). The use of each key may be described as follows:

[0112] The public key (Y) facilitates the computation of a CH hash value or CH value (m1-CH) for a given input message (m1), where m1∈[0,1] * The public key may allow any entity to calculate and / or verify the CH value (m1-CH) corresponding to a given input message (m1).

[0113] The private trapdoor key (X) can trigger the CH trapdoor, resulting in two or more different input messages (m1, m2, …, m nThe term trapdoor key or secret trapdoor key may be used as an alternative abbreviation for the private trapdoor key (X).

[0114] Figure 2 An example Chameleon hash function 200 is illustrated. The CH scheme may define four or more operation functions herein: CH.Gen; CH.Hash; CH.Ver; CH.Col.

[0115] The CH.Gen function may enable the generation of a common (Y WTRU ) / Private(X WTRU ) key pair, where the subscript WTRU refers to the WTRU that generates and / or owns the CH key pair. CH.Hash may be a one-way irreversible hash function that accepts an input message of any arbitrary length and / or computes its corresponding unique and / or non-collision CH value as output. Such a function may include the WTRU's public key (Y WTRU ), some precomputed cryptographic primitives (g, p, q), and / or a minimum randomly generated number (a) called the CH conflict public parameter (CHCPP) when computing the CH value (m1-CH) of the input message (m1) WTRU ,b WTRU ).

[0116] CH.Ver may be a function that verifies equality between a given CH value (m1-CH) of a particular input message (m1) and / or performs a CH.Hash function on the same input message (m1). For example, CH.Ver may indicate that given a public parameter (Y WTRU ,g,p,q) and / or message (m1) and / or corresponding CHCPP (a WTRU ,b WTRU ), whether m1-CH is equal to the result value of executing CH.Hash function.

[0117] CH.Col may be a CH-unique function, which may require a private trapdoor key (X WTRU ) so that the CH value of the input message (m1) can be compared with the CH value of any other input message (m2, m3, ..., m n ) to induce conflicts. In this regard, CH conflicts can be represented by the fact that m1-CH can have n -CH same value.

[0118] Private trapdoor key X WTRU can be a secret value, and the tuple (Y WTRU ,p,q,g,a WTRU ,b WTRU) can be a public value. WTRU ,p,q,g) can be expressed as CH public parameters (CHPP), and CH conflict public parameters (a WTRU ,b WTRU ) may be referred to as CHCPP.

[0119] Figure 3 An example 5G system architecture 300 is illustrated. The 5G system architecture may include a WTRU, a radio access network (RAN), and / or a core network. One of the design principles of the 5G system architecture may be service-centric or service-based. Figure 3 As shown, the 5G core network may include a variety of network functions that can work together to perform and / or provide the required services to the RAN, WTRU and / or application server / service provider. A network function can access another function in a request / response mode or a subscription / notification mode. Before two network functions interact with each other, they may first need to register with the network repository function (NRF) so that they can discover each other from the NRF. Among these network functions, the access and mobility management function (AMF) is dedicated to managing the WTRU's access to the 5G system and its mobility, and the session management function (SMF) is responsible for establishing a session between the WTRU and the 5G core network.

[0120] The authentication server function (AUSF) is responsible for the authentication of the WTRU. Alternatively or additionally, the policy control function (PCF) may provide policy rules to other control plane network functions and the WTRU. The PCF may assign an identifier to each created policy rule, which other control plane network functions and the WTRU may use to reference the corresponding policy rule. The user plane function (UPF) may be the only function of the user plane; the UPF may facilitate monitoring, management, control and / or redirection of user plane traffic flows (such as between the WTRU and the application server). The network open function (NEF) may enable exploration of control plane functions to entities such as network applications that are outside the 5G system and / or not in the same trusted domain. The 5G core network may also provide data storage and analysis services through functions such as unified data management (UDM), unified data repository (UDR), unstructured data storage function (UDSF) and network data analysis function (NWDAF). Another feature of the 5G system may be network slicing facilitated by the network slice selection function (NSSF).

[0121] Although these network functions may be defined as separate logical entities, specific scenarios may require multiple functions; for example, WTRU mobility may require AMF, AUSF, and / or SMF. For a type of network function, multiple instances may be instantiated, and the NRF may maintain information for each instantiated network function instance. Some network functions in the 5G core network, such as UPF and NEF, may be deployed and / or reside in edge networks that may be closer to the RAN and potentially co-located with the RAN. Figure 4 An example procedure 400 in a 5G system architecture is illustrated. The example procedure 400 may be jointly performed sequentially by entities including a WTRU, a RAN node, and / or a 5GC to enable the WTRU to perform the following functions.

[0122] The WTRU may discover and / or select a network (eg, PLMN, RAN, cell) based on a received System Information Block (SIB), which a RAN node broadcasts to one or more (eg, all) WTRUs.

[0123] The WTRU may establish a radio resource control (RRC) connection with the selected RAN (eg, RAN1) so that the WTRU may communicate with the core network via the selected RAN.

[0124] The WTRU may initiate a registration with the serving AMF, which is determined by the selected RAN. The serving AMF may check primary access verification and authentication with the AUSF, request the WTRU's subscription data from the UDM, check access and mobility policies with the PCF, and / or contact the SMF to activate any existing PDU sessions if the WTRU indicates. 5G may introduce the concept of Registration Area (RA), which may include multiple Tracking Areas (TAs). When the WTRU stays within a RA (e.g., RA1), the WTRU may not need to perform a registration update with the serving AMF again to reduce signaling overhead unless the periodic registration timer expires. It is important to note that each TA may cover multiple cells. When the WTRU moves from one RA to another RA (e.g., RA2), the WTRU may need to perform a new registration with the registration type set to Mobility Registration Update. A larger RA may help reduce registration overhead, but it may increase the overhead of paging signaling that the serving AMF can use to page the WTRU.

[0125] The WTRU may then enter the RM registered state and may begin interacting with one or more other control plane NFs via the serving AMF. The serving AMF may be the only entry point for the WTRU to access and / or interact with the core network control plane. It is important to note that the third general procedure, the fifth general procedure, and the seventh general procedure in the 5G system architecture may be related to connection management. Alternatively or additionally, the service request may be completed together with the WTRU registration. As a result, the WTRU may enter CM-CONNECTED. When the WTRU stays in the CM connected state, the WTRU may move within the RA without possibly notifying the serving AMF. But if the WTRU moves out of the RAN notification area (RNA) while still within the RA, the WTRU may need to perform a RAN update to trigger the RAN to update the WTRU context and / or the corresponding RRC connection maintained by the RAN. Importantly, the RNA may be a subset of the RA; for example, TA1, TA2, and TA3 form the RNA.

[0126] Alternatively or additionally, the WTRU may establish a PDU session with the SMF for a specified DN, which may be determined by the serving AMF. The SMF may check the PDU session policy with the PCF, and / or may select the UPF as the PDU Session Anchor (PSA). The PSA may be the entry point for the WTRU to access the data network (DN) or receive packets from the DN. When the SMF checks the session policy with the PCF, the PCF may retrieve the WTRU's subscription data from the UDR.

[0127] Additionally or alternatively, the SMF may perform primary session authentication using the WTRU's subscription data as retrieved from the UDM, and / or optionally perform secondary authentication between the WTRU and the DN-AAA server using the Extensible Authentication Protocol (EAP). It is important to note that this procedure may be performed in conjunction with the fifth general procedure in the 5G system architecture.

[0128] When the WTRU may enter the CM Idle state (e.g., after the WTRU's connection with the serving AMF may be released), the WTRU (e.g., in Mobile Initiated Connection Only (MICO) mode) may proactively initiate a service request procedure to re-establish the connection with the serving AMF and / or enter the CM Connected state. If the WTRU is not in MICO mode and is in the CM Idle state, the serving AMF may page and / or trigger the WTRU to initiate a service request procedure, for example, to receive any downlink packets. As a result of the service request, a non-access stratum (NAS) connection may be established between the WTRU and its serving AMF.

[0129] The WTRU may now start data plane data transmission with the specified DN via the RAN and / or UPF as PSA.It is important to note that each DN may have a Data Network Name (DNN).

[0130] When a WTRU may move from RA1 to RA2, the WTRU may detect this event by checking the TA list of each RA as configured by the serving AMF. The WTRU may then perform a mobility registration update with the new serving AMF. An Xn-based or N2-based inter-RAN handover may be performed between the new RAN and the old RAN. The new serving AMF may contact the old serving AMF to transfer the WTRU's context information. The SMF may contact the PCF and UPF to update the existing PDU session with the WTRU.

[0131] like Figure 4 As shown, multiple TAs may be grouped together as a local area data network (LADN) service area to support LADN services. For example, TA4, TA5, and TA6 may form a LADN service area. If the WTRU stays within TA4, TA5, or TA6, the WTRU may be allowed to access LADN1. Similarly, a group of TAs may be grouped as a service area, based on which the 5GS may specify and / or impose service area restrictions on the WTRU. For example, TA7, TA8, and TA9 may form a service area, which the 5GS may configure with the WTRU for service area restrictions - if the WTRU stays within TA7, TA8, or TA9, the WTRU may be allowed to access the 5GS.

[0132] Figure 4 An example procedure 400 is illustrated. It should be appreciated that the WTRU may perform these procedures in a different order, such as performing the seventh procedure before the sixth procedure and / or skipping the fifth procedure. It should also be appreciated that among these procedures, the sixth procedure may be associated with the data plane, and one or more (e.g., all) of the other procedures may be associated with the control plane.

[0133] 5G roaming may be provided. Cellular networks may include complex systems with heterogeneous participants. Reliable wireless communication coverage and / or service provision may require uninterrupted connectivity between wireless communication components (including radio cells and / or core networks). Due to the high mobility of WTRUs, reliable but uninterrupted connectivity may remain a challenge. Roaming in wireless communications may alleviate the problem of connectivity interruptions and / or ensure (e.g., complete) wireless communication coverage for subscribers accessing other networks (e.g., roaming WTRUs).

[0134] Roaming may extend the coverage of a home network (HN) operator by allowing a mobile WTRU of the HN operator to use the network and / or services provided by another network operator, referred to as a visited network (VN). One or more (e.g., two) roaming implementations may be based on the geographic locations of the visited network and the home network in 3GPP. One roaming implementation may be a domestic roaming service, where a roaming WTRU may utilize network resources of another network operator within the same geographic location of the roaming WTRU's HN. Other roaming implementations may be international roaming, where a WTRU may utilize the network coverage of a visited VN located in another geographic location of the WTRU's HN.

[0135] Roaming models may include a home routing (HR) model and a local breakout (LBO) model. Both roaming models (e.g., HR and LBO) may be based on a network function called a secure edge protection proxy (SEPP). SEPP may act as a service relay between VN and / or HN and / or may provide a secure connection. Alternatively or additionally, this secure connection may hide the complexity of the network topology of both VN and / or HN. In addition, the application function (AF) in the two networks (e.g., HN and VN) may interact with the 5GC to provide the required services, such as traffic routing or policy control. The AUSF within the HN may be responsible for performing authentication between the WTRU and the 5GC. It is worth noting that in both models (LBO and HN), the HN may be responsible for authenticating the roaming WTRU to the VN and / or verifying the roaming WTRU. For example, the HN may use an authentication mechanism such as one of the authentication mechanisms of 5G-AKA to authenticate the roaming WTRU. During the authentication procedure, the HN may reveal a permanent identifier (e.g., SUPI) to the VN to ensure authentication to the VN and verify the identity of the roaming WTRU.

[0136] Figure 5A is a diagram illustrating an example of a home routing (HR) roaming architecture 500a. Figure 5B is a diagram illustrating a local breakout (LBO) roaming architecture 500b. The main differences between HR and LBO may include the way the service data plane of a roaming WTRU is handled. In the HR model, the user plane traffic of a roaming WTRU may be served by the HN, thus potentially giving more control over the user traffic, such as Figure 5A As shown. The roaming WTRU may use the AMF and / or SMF from the VN, and the UPF of the HN may be used to connect the roaming WTRU to the DN. The SMF in the HN may obtain the subscription data directly from the UDM. Figure 5B As shown, LBO may rely on VN to handle user plane traffic of roaming WTRU. HN may be responsible for authentication and / or handling of subscription data of roaming WTRU. Considering basic roaming policy and billing, VN may apply visited PCF according to its roaming agreement with HN.

[0137] The HR model may produce high latency because user plane traffic may pass through a secure channel (tunnel) from VN to HN managed by SEPP. The HR model may be recommended when the relationship between the two operators may not be sufficiently (e.g., no) trust. Mobile network operators may switch to the LBO model to reduce the load from HN to VN. Using the LBO model, control plane signaling data can be routed to HN, which allows more efficient data plane routing in terms of latency, although HN may lose data plane control of its subscribers. Under the LBO model, the IP address of the roaming WTRU can be obtained from the VN. Therefore, the roaming WTRU can use the radio bearers and / or 5GC resources of the VN. LBO can be considered the best architectural option for better service, less latency and / or less overhead. However, an intermediary may be required to handle billing settlements between independent mobile operators, which may raise concerns about security, trust and / or complexity. It is important to note that the terms WTRU and roaming WTRU can be used interchangeably unless otherwise explicitly specified. This article describes some existing HR roaming architecture limitations.

[0138] Limitations of the HR roaming architecture on the control plane may include the participation of the HN in the process of authenticating the roaming WTRU, which may lead to several potential limitations, such as: 1) additional delays in the authentication process due to the HN's participation; 2) additional overhead for the HN to handle authentication-related messages; 3) there is a risk of leaking the roaming WTRU identity when the HN may transmit the roaming WTRU's permanent identifier (e.g., SUPI) to the VN; and / or 4) if the HN becomes congested, inaccessible, etc., the HN becomes a single-point feature and / or the roaming WTRU may be able to access the VN.

[0139] HR roaming architecture limitations on the data plane may include the need for the HN to route and / or manage traffic from / to the roaming WTRU. This may result in limitations such as: 1) additional latency in data plane packet transmission; 2) additional security protection between the HN and the VN; 3) additional transmission overhead between the HN and the VN; and / or 4) additional energy consumption due to home routing transmission.

[0140] Some existing LBO roaming architecture limitations are described herein. LBO roaming architecture limitations may include HN involvement in the process of authenticating roaming WTRUs on the control plane, which may result in several potential limitations, such as: 1) additional delays in the authentication process due to HN involvement; 2) additional overhead for the HN to handle authentication-related messages; 3) when the HN transmits the permanent identifier (e.g., SUPI) of the roaming WTRU to the VN, there is a risk of leaking the roaming WTRU identity; and / or 4) if the HN becomes congested, inaccessible, etc., the HN becomes a single point of failure and / or the roaming WTRU may sometimes be unable (e.g., never) to access the VN.

[0141] Limitations related to both the HR model and the LBO model may be provided. Both the HR model and the LBO model may include the HN, which may be a network-centric architecture design. One limitation is that the HN may be able to track the new location of a roaming WTRU and / or the privacy of the roaming WTRU may not be protected.

[0142] Alternatively or additionally, both models may assume that there is trust between the HN and the VN. However, there may be no immutability guarantee for roaming records, which may cause problems for clearing and / or settlement between the HN and the VN.

[0143] Alternatively or additionally, both models may assume that a roaming WTRU may have a subscription with an HN. However, in future wireless systems, a roaming WTRU may not have any legacy subscription with any mobile operator. In other words, from the perspective of a roaming WTRU, the WTRU may not have any HN, but may select and / or access any available mobile network based on its needs.

[0144] Alternatively or additionally, the VN services that a roaming WTRU may consume may depend on the HN, and / or the roaming WTRU may not be able to freely decide what VN services it wants to use.

[0145] Alternatively or additionally, both models may not support trusted dynamic pricing and / or QoS negotiation between the roaming WTRU and the HN / VN. For example, the QoS control may still be based on the roaming agreement between the HN and the VN, and may not be user-centric QoS control. For example, the roaming solution may rely on the HN to set the service level agreement (SLA) that the roaming WTRU may have on the VN; - if the roaming WTRU may want and may be willing to pay for a higher SLA with the VN, the roaming WTRU may not do so.

[0146] Figure 6600 is a diagram illustrating different use cases for decentralized roaming services. 5G roaming can extend the coverage of network operators and / or enhance network QoS, network reliability and / or user satisfaction. Figure 6 As shown, 5G roaming may be viewed in various scenarios. For example, a roaming WTRU may roam internationally (as illustrated in Use Case 1), such as visiting another country that is different from and far away from the HN coverage. For example, assume that Bob (e.g., a roaming WTRU) is a subscriber to a particular HN (e.g., AT&T) in the United States. Bob decides to visit Toronto, Canada next month. When Bob plans such a visit, he may select an appropriate international roaming plan on the AT&T user portal based on his travel plans, such as how long he will stay in Canada during this trip.

[0147] Another roaming scenario is domestic roaming within the same geographic location of the HN of the roaming WTRU (as illustrated in Use Case 2). In this case, the HN and VN may collaborate to support each other and / or share their resources to potentially ensure better network coverage or use the VN as a backup when the HN may become inaccessible. For example, when a network outage occurs in July 2022, Rogers can use the VN to provide services to its customers. In addition, the VN can enhance the HN coverage in certain locations or places where the VN radio signal may be better. As an example, assume that Alice is a resident of Virginia, where AT&T has the best coverage, Alice needs to go to Florida and stay there for a month to find a job, and T-Mobile has better coverage in Florida than AT&T. Further assume that there is an agreement between AT&T and T-Mobile to support each other and enhance the network coverage of their subscribers. Therefore, when Alice relocates to Florida, considering the agreement between AT&T and T-Mobile, and based on Alice's request to potentially utilize available domestic roaming services, she may have established a seamless connection with T-Mobile as a national roaming subscriber.

[0148] Alternatively or additionally, the roaming service may include services and / or network coverage obtained from an established private 5G network, such as a 5G-enabled non-public network (NPN), as illustrated in Use Case 3. The private 5G network may be dedicated exclusively to a specific enterprise or organization, and / or the private 5G network may include private cell sites and private core network servers, which may eliminate reliance on public cellular networks. When a roaming WTRU may enter the coverage of a private network, the roaming WTRU may request to utilize private network resources to obtain better QoS and / or network coverage. As an example, assume that a top company such as Google has created a new data center on a Caribbean island. Therefore, in order to communicate with employees within the scope of the data center project, Google established a local private 5G network. A few months later, Google hosted a conference on the Caribbean island to announce the new technologies utilized by the project. Kate is one of the visitors invited to the Google event. In order to ensure good coverage and / or better QoS on the Caribbean island, Kate asks her HN to enable roaming services on the private network provided by Google on the Caribbean island.

[0149] Alternatively or additionally, roaming services may be witnessed by accessing an established ad hoc network (e.g., as illustrated in Use Case 4). An ad hoc network may be viewed as a small-scale local area network managed by cooperating network subscribers (e.g., WTRUs, IoT nodes, vehicles) to provide services, data transfer, and / or local network coverage to at least each other. A group of edge nodes and / or network subscribers that join such an ad hoc network may be delegated to manage the control plane of the ad hoc network under the management of the core network without overwhelming the HN. In this case, the roaming WTRU may be another network subscriber located in the vicinity of the established ad hoc network.

[0150] It can be assumed that a roaming WTRU has limited connectivity to the HN, which is sufficient for it to obtain some information about nearby ad hoc networks. Therefore, one way to obtain moderate connectivity may be to join a nearby ad hoc network. For example, in an emergency situation in which a large-scale hurricane occurs in Miami, Florida, network coverage may become very limited, and one or more (e.g., most) network base stations may become unavailable. In this case, a limited number (e.g., only a few) of IoT gateways and / or subscribing WTRUs may still have good connectivity to the HN, through which they (gateways and / or WTRUs) may be entrusted to establish an emergency ad hoc network. The established ad hoc network can be used to ensure good coverage of one or more other network subscribers within the limited network coverage. Sam may have very limited connectivity to his HN, but he may be able to find an ad hoc network established near his location. At this point, Sam decides to join the ad hoc network and / or take advantage of the connectivity provided. In view of this situation, Sam requests to join a nearby ad hoc network as a roaming WTRU, and may be able to enjoy sufficient network coverage to survive.

[0151] Roaming implementations may require the HN to manage one or more (e.g., all) of the relevant information and / or even the requirements of the roaming WTRU. These roaming models limit the ability of the roaming WTRU to determine roaming service quality, billing standards, and / or other network services because the HN controls the WTRU's activities within the VN (e.g., in the case of the HR). In other words, the roaming solution can be a network-centric design rather than a WTRU-centric design.

[0152] In roaming mode, when the HN may become unreachable (e.g., Rogers network outage in July 2022), the roaming WTRU may not be able to obtain service from the VN. Similarly, when the HN becomes unavailable, the non-roaming WTRU of the HN may not be able to switch to using other networks. When the HN becomes unreachable, there may be questions about how the roaming WTRU can still access the VN.

[0153] The roaming model may require a lot of interaction between the visited VN and HN operators to 1) authenticate the roaming WTRU, 2) manage the activities of the roaming WTRU, 3) control the WTRU billing and / or billing settlement, and / or 4) ensure service continuity and / or reasonable network coverage for roaming. In order to handle the WTRU roaming process, the VN and / or HN may need to exchange multiple records and / or information about the roaming WTRU, which may introduce a lot of communication overhead, delay and / or extensive security protection.

[0154] Some embodiments may include a WTRU-centric roaming solution that may provide more flexibility and / or controllability to a roaming WTRU while potentially leveraging VN resources. The WTRU-centric solution may provide a roaming WTRU with the ability and / or more freedom to control and / or manage roaming-related decisions, data, authentications, and / or agreements based on the desired QoS of the WTRU from the VN, potentially without any interaction or intervention from the HN of the roaming WTRU. A proposed WTRU-centric solution may utilize blockchain to potentially ensure mutual trust between interacting entities (e.g., in this case, the roaming WTRU and / or the VN). To ensure mutual trust, the roaming WTRU may authenticate the VN before attaching to the VN, and further, the VN may authenticate the roaming WTRU before accepting roaming services to the roaming WTRU.

[0155] Described herein are two methods for potentially achieving mutual authentication. One mutual authentication scheme may rely on the simple assumption that the roaming WTRU can authenticate the VN through digital signature verification, while the main focus may be on authenticating the roaming WTRU using an issuance certificate issued by the HN. Alternatively or additionally, in order to enhance the introduced mutual authentication and / or increase the level of security, a dual authentication mechanism may be introduced. The dual authentication mechanism may include the VN and / or the roaming WTRU, wherein both the VN and / or the roaming WTRU may authenticate each other through 1) a digital signature and / or 2) a certificate issued from a trusted authority or from the HN. It is important to note that this document describes the requirements and preparation procedures for achieving WTRU-centric roaming. It is also important to note that this document describes the interactions required for mutual authentication between the roaming WTRU and / or VN, without potentially requiring any interactions from the HN side.

[0156] Some embodiments may include reducing the load from the HN by adopting a decentralized blockchain-enabled WTRU-centric roaming solution, which may alleviate at least some (e.g., a large amount) of communication overhead and / or delay that may be required to manage WTRU activities during roaming. Blockchain technology may be used to attach at least some (e.g., all) public information (e.g., roaming agreements, WTRU authentication public parameters, VN authentication public parameters, billing policies, etc.) in a blockchain or distributed ledger managed by multiple entities (e.g., multiple network operators). Therefore, since those key parameters or information stored in the blockchain may be immutable, transparent and / or available to various NFs in the VN, one or more (e.g., all) necessary network operations may be performed directly by the VN, and may no longer require interaction with the NFs in the HN. As a result, adopting a blockchain-based roaming service may reduce the communication and / or delay required to manage WTRU roaming requests between the HN and the VN. Alternatively or additionally, enabling a WTRU-centric roaming solution may also overcome or alleviate at least some (e.g., a large amount) of communication interactions required between the VN and the HN to potentially authenticate the WTRU to the VN.

[0157] For example, a WTRU-centric decentralized roaming solution may be provided to reduce resource burden and / or reduce HN interactions with the VN to manage roaming services and / or the authentication process of the roaming WTRU. WTRU-centric may be defined as the ability of the WTRU to control roaming services, VN selection and / or billing settlement options. Alternatively or additionally, the WTRU may receive a temporary identifier (WTRU certificate) from the HN. The received WTRU certificate may be used to introduce a flexible WTRU-centric authentication scheme, for example, to verify the WTRU identity to the VN without any assistance from the HN.

[0158] In order to implement a WTRU-centric decentralized roaming model, a blockchain network may be used as a decentralized infrastructure to maintain and / or manage any public / permissioned information about interacting entities (e.g., HN, VN, and / or roaming WTRU) during the roaming process. For example, a blockchain may store transactions including some agreements between an HN and a VN, which may indicate possible services provided by the VN, the billing costs of each service, and / or public key credentials that can be used to authenticate the VN. In addition, the blockchain ledger may maintain public transactions between the roaming WTRU and the HN, which may show the VN, for example, how to verify and / or authenticate the roaming WTRU without requesting any information from the HN. Therefore, both the VN and the HN can provide roaming services without overwhelming communication resources and / or facing too much delay (e.g., delay greater than a predefined threshold).

[0159] Utilizing a blockchain system (e.g., a consortium blockchain distributed ledger system, a private blockchain, and / or a distributed ledger system) to host or store public information (e.g., all public information) and any information required to authenticate a roaming WTRU can help mitigate ineffective and / or expensive interactions between the HN and the VN to manage roaming services, because any information stored in the blockchain system can be transparent, immutable, and / or non-repudiable. As a result, blockchain can be a good candidate for providing third-party services. In other words, the blockchain can be viewed as a trusted system for preserving public required parameters for managing roaming services (e.g., authentication, service requests, billing settlement, etc.) without requiring additional interactions from one or more (e.g., all) system entities (e.g., from WTRUs, HNs, and / or VNs at the same time).

[0160] Figure 7 FIG. 7 is a diagram illustrating an example of an overview of a wireless transmit / receive unit (WTRU)-centric decentralized roaming model that may be provided. Figure 7 As shown, the proposed WTRU-centric decentralized roaming scenario may include one or more (e.g., three) levels. The WTRU-centric decentralized roaming scenario may be based on direct interaction between the HN and the VN to negotiate and / or publish blockchain transactions (e.g., VN-Roaming-Key-Repo), which service transactions show the VN's requirements for handling roaming requests, for example, without requesting any help from the HN. The VN-Roaming-Key-Repo can be a public repository in the form of a blockchain smart contract for maintaining parameters such as, but not limited to: the VN's public key; the agreement with the HN; and other authentication-related public parameters.

[0161] A WTRU-centric decentralized roaming scenario may issue a WTRU certificate to the VN to help authenticate and / or verify the roaming WTRU based on direct interaction between the HN and the roaming WTRU, for example, without requiring interaction from the HN side. A third component may include roaming services in a decentralized and / or WTRU-centric manner. A WTRU-centric decentralized roaming scenario may include the roaming WTRU interacting with the VN to handle roaming services and / or WTRU authentication, for example, without requiring any interaction from the HN side. Both the roaming WTRU and the VN may authenticate each other and / or determine service requirements (e.g., subscription requirements, billing standards, access time, etc.) to achieve decentralized and / or trusted roaming service provision.

[0162] A WTRU-centric decentralized roaming scenario can reduce the load from the HN and / or VN, which can alleviate at least some (e.g., a large amount) of communication overhead and / or latency required to manage WTRU activities during roaming. Compared to traditional roaming models, blockchain technology can be used to attach one or more (e.g., all) public data (e.g., roaming agreements, WTRU authentication public parameters, VN authentication public parameters, billing policies, etc.) in a blockchain ledger, where one or more (e.g., all) of these processes may need to be managed when a roaming WTRU may need to attach itself to a VN one or more times (e.g., each time).

[0163] Figure 8 An example comparison 800 is illustrated between the interactions required between the VN, HN, and a roaming WTRU during management of a roaming request.

[0164] As a result, the use of blockchain-based roaming services can reduce the communication and / or latency required to manage WTRU roaming requests between HN and VN. Alternatively or additionally, enabling a WTRU-centric roaming solution can also overcome or mitigate the large amount of communication interactions required between VN and HN in order to authenticate WTRU to VN.

[0165] Fig. 9 An example procedure 900 for implementing a user-centric decentralized roaming service is illustrated. A WTRU-centric decentralized roaming solution may be proposed herein. A roaming WTRU may control (e.g., have full control) its roaming service and / or data management to achieve the best network service and / or requirements. A solution may utilize one or more (e.g., four) procedures (e.g., main procedures) including 1) roaming service enablement, 2) roaming service activation, 3) roaming WTRU mutual authentication and initial access, and / or 4) roaming WTRU temporary VN accessibility. Fig. 9 As shown, each of the proposed procedures may implement steps towards WTRU-centric decentralized roaming and / or may pave the way for subsequent procedures.

[0166] The WTRU-centric model may include the HN and / or VN setting a decentralized agreement that shows the provisions and / or policies that may be applied to the roaming WTRU when requesting roaming services (e.g., connecting the WTRU to the VN to potentially use its resources and / or network services). A decentralized agreement between the HN and the VN (e.g., roaming service enablement) is described herein. In roaming service enablement, the VN and the HN may collaborate to determine a roaming service agreement to be published as a blockchain transaction represented as "VN-Roaming-Key-Repo". Alternatively or additionally, the VN may generate its own authentication credentials so that the roaming WTRU can obtain such authentication parameters to authenticate the VN before accessing VN resources. The generated authentication parameters representing the VN may be published as part of the VN-Roaming-Key-Repo transaction obtained between the VN and the HN.

[0167] In this second procedure (Roaming Service Activation), the HN issues an identity certificate (e.g., WTRU certificate) to the roaming WTRU, which will be used to identify the roaming WTRU to the VN and authenticate the roaming WTRU to the VN without any interaction from the HN. A blockchain transaction will then be generated for the roaming WTRU, which includes details about the WTRU certificate issued for the roaming WTRU. After the WTRU receives the WTRU certificate from the HN, the roaming WTRU may use this WTRU certificate to authenticate itself to the VN, which is explained in detail in the third procedure ("Roaming WTRU Mutual Authentication and Initial Access"). When the roaming WTRU can authenticate itself to the VN, the roaming WTRU may use one of two proposed authentication strategies, which may include a Rivest-Shamir-Adleman (RSA)-based authentication strategy or a CH-based authentication strategy. The roaming WTRU may authenticate itself to the VN using the issued WTRU certificate, and may negotiate with the VN for VN resource accessibility, required services and / or billing policies.

[0168] After the WTRU has negotiated WTRU mutual authentication and initial access with the VN, the VN may provide the roaming WTRU with a temporary registration access (WTRU-TmpID) which may be used in the future to authenticate the roaming WTRU to the VN in a potentially more efficient manner, which may simplify the roaming WTRU authentication and / or accessibility to VN resources without repeating the entire process explained in the roaming WTRU mutual authentication and initial access procedure. Roaming WTRU temporary VN accessibility is a way in which the roaming WTRU can use the WTRU-TmpID to authenticate itself (the WTRU) to the VN, which serves the same purpose as "WTRU mutual authentication and initial access", but may be more efficient than "WTRU mutual authentication and initial access".

[0169] In the proposed user-centric decentralized roaming, the HN may not be completely removed. For example, the HN may interact with the VN during the roaming service activation procedure to negotiate roaming services with the VN. Alternatively or additionally, during the roaming service activation procedure, the HN may determine the roaming policy for the roaming WTRU. The involvement of the HN may be kept at a low level to reduce additional roaming delays and / or overhead. In other words, the HN may not participate in mutual authentication and / or initial access, which may only occur directly between the roaming WTRU and the VN in a decentralized manner.

[0170] Fig.10 An example roaming service enabling procedure 1000 is depicted. The HN may negotiate and / or interact with the VN to determine general provisions for roaming services and / or announce the VN public key credentials that the WTRU may use to authenticate the VN to any potential roaming WTRU. Fig.10 As shown, roaming service activation may include a decentralized agreement between the HN and the VN, which is published as a public transaction in the blockchain system. Fig.10 The following procedures depicted in may be included in an implementation related to roaming service enablement.

[0171] At 1001, the VN and the HN may exchange, for example, potential roaming agreements, policies, and / or roaming service enablement criteria to standardize the roaming services provided by the VN to potential roaming WTRUs subscribed to the HN. For example, a roaming agreement may indicate that a roaming WTRU may be authenticated by a predetermined authentication policy, and that the VN should provide a minimum QoS, a minimum charging policy, an additional charging policy, etc. to a roaming WTRU (e.g., a home subscriber). Such an agreement between the VN and the HN may be represented as a roaming service and / or charging policy agreement.

[0172] Once the HN receives confirmation from the VN regarding the roaming service and / or charging policy agreement, at 1002, the HN may deploy the VN-Roaming-Key-Repo smart contract. The VN-Roaming-Key-Repo smart contract may be included in a public or licensed transaction that may prove the roaming service and / or charging policy agreement with the VN. A public transaction may refer to a transaction that can be accessed by anyone at any time. A licensed transaction may require permission from the HN and / or VN so that certain entities (e.g., roaming WTRUs) can access the contents of these VN-Roaming-Key-Repo smart contract transactions. Based on the agreement between the VN and the HN, an accessibility policy for the VN-Roaming-Key-Repo smart contract may be determined (published / permitted). For example, the VN and the HN may agree that the contents of the VN-Roaming-Key-Repo can be accessed by a roaming WTRU that requests roaming service activation from the HN.

[0173] Once the HN completes the deployment of the VN-Roaming-Key-Repo smart contract, at 1003, the HN may request the VN to generate a PKI key pair. Alternatively or additionally, the HN may notify the VN of the VN-Roaming-Key-Repo smart contract address, where the VN may publish the generated public key certificate to the blockchain system in the form of a smart contract (e.g., included in the VN-Roaming-Key-Repo smart contract). The generated PKI key pair of the VN (especially the public key certificate) may be used by any roaming WTRU: 1) to authenticate the VN before the roaming WTRU is attached to the VN (e.g., VN); and / or 2) to verify any digital signature provided by the VN during interaction with the roaming WTRU.

[0174] At 1004, the VN may generate a PKI key pair. A PKI key may be a private key (Sk VN ), which can be a secret key that no one except the VN should know. Another corresponding key can be a public key (Pk VN ), which can be reversed by its corresponding private key (Sk VN ) to obtain any operation. VN can use VN private key (Sk VN ) to digitally sign any information provided by VN and decrypt the information provided by the corresponding public key (Pk VN ) encrypted. In other words, whenever the private key (Sk VN ), the public key generated by VN can be verified by (Sk VN ) or encrypt any data that should not be known to anyone except the VN.

[0175] Once the VN completes the generation of the PKI key pair, at 1005, the VN may digitally sign the roaming service and / or charging policy agreement to confirm that the VN agrees to the terms and / or conditions mentioned in the roaming service and / or charging policy agreement.

[0176] Then, at 1006, the VN may call the VN-Roaming-Key-Repo smart contract to publish its public key (Pk VN Alternatively or additionally, the VN may use a VN private key (Sk VN ) to digitally sign the roaming service and / or charging policy agreement. Alternatively or additionally, the HN may use the private key (Sk HN ) digitally signs the VN-Roaming-Key-Repo and publishes the signed agreement in the VN-Roaming-Key-Repo smart contract.

[0177] Once the blockchain system verifies the VN-Roaming-Key-Repo smart contract, at 1007, a confirmation may be transmitted to both the VN and / or HN such that the transaction is verified.

[0178] Fig.11 An example roaming service activation 1100 is depicted. When a WTRU may decide to leave the perimeter of the HN coverage f, the WTRU may request roaming service activation from the HN at 1101. Roaming service activation may include the HN generating a temporary decentralized proof (WTRU proof) to the roaming WTRU; the HN may issue a blockchain transaction with public authentication parameters representing the issued WTRU proof, so that the VN may use this transaction to potentially authenticate the roaming WTRU without any interaction from the HN; and / or the roaming WTRU may obtain a copy of the blockchain transaction "VN-Roaming-Key-Repo", which may include required public information about the VN.

[0179] This procedure may occur in, but is not limited to, the following scenarios. This procedure may occur before the roaming WTRU may move to the VN, and the roaming WTRU may initiate the execution of this procedure. Alternatively or additionally, this procedure may occur before the roaming WTRU moves to the VN, and the HN may instruct / notify the roaming WTRU (e.g., via a WTRU configuration update command) to execute this procedure.

[0180] Alternatively or additionally, this procedure may occur after the roaming WTRU may move to a location outside of the coverage of the HN and the roaming WTRU may use non-cellular connectivity (eg, Wi-Fi, Internet) to access the HN to perform this procedure.

[0181] Alternatively or additionally, this procedure may occur after the roaming WTRU may move to a location outside the coverage of the HN, and the VN may allow the roaming WTRU to access the HN using the VN's network to perform this procedure. Described herein are examples of solutions proposed to handle the roaming service activation procedure, such as Fig.11 shown.

[0182] In some embodiments, the roaming WTRU may transmit a request to activate roaming services to the HN. This request may include the following parameters: WTRU-ID, WTRU certification lifetime, authentication policy, WTRU location and / or request type.

[0183] The WTRU-ID may represent an identifier of the WTRU (e.g., the WTRU's SUCI, the WTRU's decentralized identifier, the WTRU's blockchain address, and / or the WTRU's public key). The WTRU Attestation Lifetime may represent the requested lifetime of the WTRU attestation to be generated by the HN. The Authentication Policy may represent the authentication policy that the WTRU may support and / or prefer (e.g., RSA-based, CH-based). The WTRU Location may represent the current location of the WTRU. This parameter may not be required if the WTRU may have location-based services enabled and / or the HN may (e.g., always) know the location of the WTRU. The Request Type may indicate the type of this request (e.g., a request to activate roaming services).

[0184] Once the HN receives the roaming WTRU request for roaming service activation, the HN may begin negotiating a roaming service agreement at 1102. For example, the roaming service agreement may include costs and / or fees that the roaming WTRU may pay to the HN for issuing a roaming WTRU certificate (WTRU certificate), the time when the WTRU certificate expires (if any), the possibility of using the WTRU certificate one or more times, etc.

[0185] Once the roaming WTRU and the HN reach an agreement on roaming service activation, the HN may initiate a session to issue a WTRU certificate for the roaming WTRU at 1103. The WTRU certificate may be used to authenticate the roaming WTRU and verify the roaming WTRU subscription status to the VN without revealing any information about the WTRU identity and potentially without requiring any interaction with the HN side. The manner in which the WTRU certificate may be issued may include an authentication policy that may be determined by the WTRU and the HN, such as Fig.11 As depicted in .

[0186] exist Fig.11 In the present invention, a general authentication policy model is depicted to express at a high level the basic interactions required to issue WTRU credentials between the HN and the roaming WTRU. Thus, the HN and the roaming WTRU may negotiate to determine an authentication policy that is suitable for the WTRU's capabilities. For example, the WTRU may be optimized to perform certain encryption methods, such as CH or RSA, in an efficient manner without consuming too much computing power. Another example may include the ability of the WTRU to store more parameters and multiple private keys (e.g., CH trapdoor keys and RSA private keys) for different needs.

[0187] Two authentication strategies may be proposed (e.g., Authentication Strategy 1 and / or Authentication Strategy 2). One authentication strategy (Authentication Strategy 1) may include RSA homomorphic operations to manage roaming WTRU authentication, while the other authentication strategy (Authentication Strategy 2) may include CH functions to authenticate the roaming WTRU to the VN. Each of the proposed authentication strategies may have the same goal, i.e., to authenticate the roaming WTRU without revealing the roaming WTRU identity or any relevant information. The details of the mechanisms of Authentication Strategy 1 and / or Authentication Strategy 2 are described in Fig.12 and Fig.13 Depicted in.

[0188] Once the roaming WTRU and the HN determine the best authentication strategy suitable for the roaming WTRU's capabilities, the HN may begin generating WTRU credentials and authentication parameters required to verify the WTRU credentials given the selected authentication, at 1104. The generated authentication parameters may be determined based on the selected authentication strategy determined by the HN and / or the roaming WTRU.

[0189] Once the WTRU attestation parameters are generated, the HN may create a WTRU Roaming Attestation Transaction (WTRU-RPT) at 1105. The HN may publish the WTRU-RPT in the blockchain ledger (e.g., the contents of the WTRU-RPT may be determined based on the authentication-based policy employed, such as Fig.12 and Fig.13 The WTRU-RPT content may include the public key (Pk WTRU ), the determined authentication policy for the roaming WTRU, the calculated authentication parameters for the determined authentication policy, the HN identifier and / or any other relevant information to simplify the roaming WTRU authentication process. After creating the WTRU-RPT content, the HN may broadcast such WTRU-RPT content as a blockchain transaction in the blockchain system).

[0190] Once the blockchain system validates the WTRU-RPT, at 1106, a confirmation with the WTRU-RPT address (or the sequence number of the transaction, or the sequence number of the block including the transaction) may be transmitted to the HN.

[0191] After successfully generating the WTRU attestation, at 1107, the HN may transmit a response to the roaming service activation request 1 to the WTRU. The response may include the WTRU-RPT address in the blockchain network, the calculated authentication parameters (e.g., WTRU roaming attestation parameters (WTRU-RPP)) and / or the generated WTRU attestation value, such as Fig.12 and Fig.13 shown.

[0192] Once the WTRU receives the WTRU-RPP and WTRU-RPT, the roaming WTRU may transmit a check to the blockchain system at 1108. Fig.10 The roaming WTRU may invoke the VN-Roaming-Key-Repo smart contract from the blockchain to obtain the required information about the VN and / or the public key of the VN to verify and / or authenticate the VN. The information extracted from the VN-Roaming-Key-Repo may be stored locally with the roaming UE so that the roaming WTRU may use the information extracted from the VN-Roaming-Key-Repo to authenticate the VN during roaming mutual authentication and / or initial access level.

[0193] Once the blockchain system (e.g., a blockchain node) receives the request to obtain the VN-Roaming-Key-Repo transmitted by the roaming WTRU, the blockchain system may obtain the VN-Roaming-Key-Repo transaction from the blockchain ledger. At 1109, the blockchain system may transmit a response with the contents of the VN-Roaming-Key-Repo transaction to the WTRU.

[0194] Described herein is a roaming WTRU mutual authentication and initial access implementation scheme. It may be assumed that the roaming WTRU has received a WTRU certificate from the HN. The WTRU certificate may have a representation similar to a SUPI identifier. However, the WTRU certificate may not be a private permanent identifier such as a SUPI. In other words, the WTRU certificate may be represented as a string of 15 decimal digits, such as the SUPI value determined by the 3GPP specification. One or more of the first few (e.g., the first two or three) digits may represent the mobile network code (VN-MNC) of the VN, and the next two or three digits may form the mobile network code (HN-MNC) of the HN. The remaining (e.g., nine or eleven) digits may represent a temporary roaming mobile subscriber identification number (TR-MSIN). The exact value of the WTRU certificate may be known only to the roaming WTRU and the HN.

[0195] The VN may not have any accessibility to the WTRU credentials. The VN may verify and authenticate the roaming WTRU in an anonymous manner without revealing the WTRU credentials value. In the event that the roaming WTRU abuses VN resources or does not comply with VN regulations and policies, the VN may contact the HN to check the records of the roaming WTRU. The VN may identify the roaming WTRU to the HN via a WTRU-RPT created by the HN. The HN may identify the roaming WTRU from the generated WTRU credentials, which may be known to the HN.

[0196] The WTRU credential may be a secret identifier or random number issued by the HN to the roaming WTRU, such as Fig.11 The WTRU credential value may be known only to the roaming WTRU and the HN. The WTRU credential may be used anonymously to authenticate the roaming WTRU to the VN without requiring any interaction from the HN, e.g. Fig.14 In order for the VN to authenticate the roaming WTRU through WTRU certification, the VN may need to obtain information about the WTRU certification (e.g., authentication policy, public key of the roaming WTRU, etc.), which may be published as a blockchain transaction represented as WTRU-RPT, such as Fig.11 shown.

[0197] The VN may initiate the authentication procedure. Instead of requesting the required parameters and information about WTRU certification from the HN, the VN may obtain the required parameters from the blockchain, such as Fig.14 The HN may publish a WTRU roaming proof transaction (e.g., WTRU-RPT) in the blockchain ledger to initiate roaming WTRU authentication and / or verify the authenticity of the WTRU proof with reference to the required parameters, such as Fig.11 As depicted in (and Fig.12 and Fig.13 ).

[0198] The issued WTRU credentials may be used to authenticate the roaming WTRU to the VN without requesting any interaction from the HN.The method of issuing and authenticating WTRU credentials may follow the following considerations to achieve a WTRU-centric decentralized roaming solution.

[0199] The method of issuing WTRU credentials may assure the VN of the authenticity and verifiability of the roaming WTRU without revealing any pertinent information about the permanent identity of the roaming WTRU (eg, SUPI or even WTRU credentials).

[0200] The method of issuing WTRU credentials may assure the VN of the authenticity and / or verifiability of the roaming WTRU without requiring any interaction or reaction from the HN side.

[0201] Any authentication mechanism or strategy that can ensure the aforementioned WTRU credential issuance considerations may be adopted. Alternatively or additionally, the authentication mechanism may ensure mutual authentication between the VN and the roaming WTRU without relying on the HN as an intermediary to handle the authentication and verification process. One or more (e.g., two) methods of generating WTRU credentials are provided herein. The method of generating WTRU credentials may be referred to as an authentication strategy. Fig.12 and Fig.13As shown, the method of determining authentication policy and / or issuing WTRU credentials may depend on the interaction between the roaming WTRU and the HN and / or result in the creation of a blockchain transaction that is publicly published in the blockchain system. Fig.12 and Fig.13 The procedures in describe the interactions that may be required between a roaming WTRU and the roaming WTRU's HN to issue WTRU credentials, given a determined authentication policy.

[0202] Fig.12 An example RSA-based authentication policy 1200 is depicted. Fig.12 As shown, authentication strategy 1 may rely on an RSA-based authentication mechanism. A basic homomorphic encryption method may be used, where RSA encryption may have multiplication homomorphism. The RSA encryption scheme can be implemented by first selecting two large prime numbers (p RSA and q RSA ) and the set n WTRU =q RSA .p RSA To work. You can choose public key and private key (Pk for RSA encryption scheme WTRU and Sk WTRU )), so that Pk WTRU .Sk WTRU =1modn WTRU The generated prime numbers (p RSA and q RSA ) and Sk WTRU ) may be considered private values ​​and no one other than the originating WTRU (eg, a roaming WTRU) may be aware of them. WTRU ) and n WTRU ) may be a public value known to anyone interacting with the generating WTRU (e.g., a roaming WTRU). The encryption function may then be expressed as Info may be an encrypted message or information.

[0203] On the other hand, the decryption function can be expressed as In order to prove the homomorphism of the RSA encryption scheme, assume that Info1 and Info2 can be two plaintext messages, then therefore

[0204] The first authentication strategy 1 may depend on an RSA-based authentication mechanism. Fig.12 The execution procedure can be given as follows.

[0205] At 1201, the HN and the roaming WTRU may initiate the generation of WTRU credentials and determine the authentication policy. For example, according to the RSA-based authentication policy, the steps at 1201 may be similar to those described in reference Fig.11 The steps described in 1103 are similar. For example, Fig.11 As shown, the roaming WTRU may transmit a request to the HN to activate roaming services, such as Fig.11 As depicted in 1101 in . Thus, the roaming WTRU and the HN may negotiate which authentication policy to use when issuing WTRU credentials. Fig.11 The procedure may begin by showing the roaming WTRU and the HN negotiating a method for issuing WTRU credentials, and / or may determine an authentication policy that may be used to authenticate and / or verify the roaming WTRU with the VN.

[0206] When the HN and the roaming WTRU determine an authentication policy method (which may be "Authentication Policy 1"), at 1202, the HN may begin to generate a corresponding WTRU certificate for the roaming WTRU. Authentication Policy 1 may refer to an RSA-based authentication model, which may include an RSA-based homomorphic encryption method. In view of this, the HN will generate a WTRU certificate, which may be a roaming identifier. After generating the WTRU certificate, the HN may split the WTRU certificate into at least several (e.g., two) secret values ​​or shares (e.g., S1 as a first share and S2 as a second share) in a manner such that no share can individually reveal or point to any intelligible information about the secret (WTRU certificate), but when a sufficient number of shares (e.g., S1 and S2) can be combined, the secret (WTRU certificate) can be reconstructed.

[0207] After generating shares (eg, S1 and S2) for the generated WTRU credentials, at 1203, the HN may use the WTRU public key (Pk WTRU ) to compute an encrypted version of one or more of these shares (e.g., S2). The HN can then use the HN private key (Sk HN ) digitally signs one or more of these shares, for example, Alternatively or additionally, the HN may generate an encrypted version of the generated WTRU credential using the WTRU public key and / or calculate a hash value (fingerprint) of the encrypted version of the WTRU credential, e.g.

[0208] At 1204, the HN may generate a WTRU roaming authentication parameter (WTRU-RPP) and may transmit the WTRU-RPP to the roaming WTRU. In this context, the WTRU-RPP may include a value for the WTRU authentication and a first share S1 of the WTRU authentication.

[0209] At 1205, the HN may generate a WTRU roaming proof transaction (WTRU-RPT). The HN may issue the WTRU-RPT to the blockchain system. The WTRU-RPT may include any of the following: an HN identifier, an applicable authentication policy, a public key of the HN, a public key of the roaming WTRU, a WTRU proof fingerprint, and / or an encrypted version of a second share of the WTRU proof (S2). The WTRU-RPT may include the HN identifier, which may allow the VN to identify which network the roaming WTRU is subscribed to. The WTRU-RPT may include an applicable authentication policy (e.g., authentication policy 1), such as described herein. The WTRU-RPT may include the public key (Pk 1) of the HN. HN ), VN can use the public key to verify HN's digital signature.

[0210] The WTRU-RPT may include the public key (Pk WTRU ), the VN can use the public key to verify the digital signature of the roaming WTRU or decrypt any encrypted data that may be received from the roaming WTRU.

[0211] The WTRU-RPT may include a WTRU authentication fingerprint The WTRU-RPT may include an encrypted version of the second share (S2) of the WTRU certificate encrypted using the roaming WTRU's public key and / or digitally signed by the HN's private key.

[0212] When the HN generates a WTRU-RPT and publishes the WTRU-RPT in the blockchain system, the HN may transmit the generated WTRU-RPT and / or WTRU-RPP to the roaming WTRU at 1206. The roaming WTRU may use the WTRU-RPT and / or WTRU-RPP to authenticate itself to the VN during roaming service.

[0213] Fig.13 An example CH-based authentication policy 1300 is depicted. Fig.13 As shown, authentication strategy 2 may depend on a CH-based authentication mechanism. The main concept may include a chameleon hash collision attribute. This attribute may depend on the ability of the roaming WTRU to cause a hash collision between the hash value of the generated WTRU certificate and the value transmitted in the challenge generated by the VN when the roaming WTRU requests roaming service. This can be achieved by the HN issuing a WTRU certificate to the roaming WTRU in a manner that allows the WTRU to cause such a hash collision. The second authentication strategy may depend on a CH-based authentication mechanism, the procedure of which may be given as follows.

[0214] At 1301, the HN may initiate the generation of WTRU credentials and determine the authentication policy (2). For example, the roaming WTRU and the HN may negotiate a method for issuing WTRU credentials and / or determine an authentication policy to be used to authenticate and verify the roaming WTRU to the VN. The determined authentication policy may be authentication policy 2. When the authentication policy is determined, at 1302, the HN may transmit a request to the roaming WTRU to generate the required CH public parameters (CHPP), which in this case are (Y WTRU ,g,p,q).

[0215] When the roaming WTRU receives the HN request, at 1303, the roaming WTRU may start generating a CHPP by executing a CH.Gen function, such as Figure 2 After executing the CH.Gen function, at 1304, the roaming WTRU may respond to the HN request and / or may submit the generated CHPP to the HN.

[0216] At 1305, the HN may generate a WTRU credential, which may be a roaming identifier as described herein. At 1306, the HN may generate any two random numbers to represent a CH conflict common parameter (CHCPP) value (a WTRU ,b WTRU ), which values ​​may be used to calculate the CH hash value of the generated WTRU certificate.

[0217] After determining the CHCPP and generating the WTRU certificate, at 1307, the HN may perform a CH.Hash function, such as Figure 2 As depicted in . For example, the HN may obtain a CH hash value of the WTRU certificate (eg, or a WTRU certificate fingerprint). Alternatively or additionally, the HN may encrypt the generated CH hash value of the WTRU certificate using the WTRU public key.

[0218] The HN may generate a WTRU-RPP at 1308. The WTRU-RPP may include the value of the WTRU credentials.

[0219] At 1309, the HN may generate a WTRU-RPT that may include any combination of the following parameters. The HN may publish the WTRU-RPT to the blockchain system. The WTRU-RPT may include any of the following: an HN identifier, an applicable authentication policy, a public key of the HN, a public key of the roaming WTRU, a CH value of the generated WTRU certificate (CHPP), and / or an encrypted version of the CH hash value of the generated WTRU certificate (WTRU certificate fingerprint). The WTRU-RPT may include the HN identifier by which the VN may identify to which network the roaming WTRU is subscribed. The WTRU-RPT may include an applicable authentication policy (e.g., authentication policy 2), such as determined herein. The WTRU-RPT may include the public key of the HN (Pk HN ), which the VN can use to verify the digital signature of the HN. The WTRU-RPT may include the public key (Pk WTRU ), which the VN may use to verify the digital signature of the roaming WTRU or to decrypt any encrypted data that may be received from the roaming WTRU. The WTRU-RPT may include the CH value, CHPP, and CHCPP of the generated WTRU credential. The WTRU-RPT may include an encrypted version of the CH hash value of the generated WTRU credential (or WTRU credential fingerprint) encrypted using the public key of the roaming WTRU and digitally signed by the private key of the HN.

[0220] When the HN generates a WTRU-RPT and publishes the WTRU-RPT in the blockchain system, at 1310, the HN may transmit the generated WTRU-RPT and WTRU-RPP to the roaming WTRU, for example, to authenticate the roaming WTRU to the VN during roaming service.

[0221] Mutual authentication and initial access of the roaming WTRU with the VN may be provided without HN interaction. Once the roaming WTRU receives the WTRU certification from the HN, the roaming WTRU may begin requesting roaming services from the VN. Roaming services may be obtained in two complementary phases. One phase may require the roaming WTRU and the VN to mutually authenticate each other (e.g., a mutual authentication phase). Once the roaming WTRU and the VN have mutually authenticated each other, the VN may authorize the roaming WTRU's accessibility to the VN resources through a decentralized agreement (e.g., an initial access phase).

[0222] Fig.14 An example mutual authentication phase procedure 1400 is depicted. Fig.14 and Fig.17 2 and 3 show examples of any required interactions between the VN and the roaming WTRU that may not require any assistance from the HN for the mutual authentication phase and / or the initial access phase, respectively. Fig.14As depicted in , the mutual authentication phase may include the following procedures to enable the roaming WTRU and VN to authenticate each other.

[0223] When the roaming WTRU reaches the VN coverage, at 1401, the roaming WTRU may transmit a roaming connection request to the VN, which may include, for example, a WTRU-RPT address in the blockchain (e.g., a transaction sequence number of the WTRU-RPT and / or a sequence number of a block including the WTRU-RPT). The WTRU-RPT address may be identified by the VN's public key (e.g., )encryption.

[0224] When the VN receives a request from a roaming WTRU, at 1402, the VN may calculate The VN may use its private key to decrypt the encrypted WTRU-RPT address to obtain the WTRU-RPT address. When the VN is able to decrypt and / or recover the original WTRU-RPT address, at 1403, the VN may transmit a request to the blockchain system to pull the WTRU Roaming Proof Transaction (WTRU-RPT) content. The blockchain system may look up and check the WTRU-RPT based on the WTRU-RPT address. At 1404, the blockchain system may respond to the VN request by transmitting the WTRU-RPT content to the VN.

[0225] When the VN receives the WTRU-RPT content from the blockchain system, the VN may extract the required information about the roaming WTRU at 1405. The VN may check the HN identifier to obtain sufficient information about the network to which the WTRU subscribes. The VN may then extract the roaming WTRU public key and / or identify the WTRU authentication policy to begin authenticating and / or verifying the roaming WTRU.

[0226] When the VN extracts one or more (e.g., all) required information from the WTRU-RPT content, the VN may authenticate the roaming WTRU according to the determined authentication policy as indicated in the WTRU-RPT content. It is important to note that the authentication procedure may differ depending on the specific authentication policy and / or its requirements. Fig.14 Depicted are examples of steps that may be performed regardless of the determined authentication policy. Fig.15 and Fig.16 The RSA-based authentication strategy and the CH-based authentication strategy are depicted respectively.

[0227] At 1406, the VN may generate an authentication vector (Auth-Vec) and / or may calculate a hash value of an expected response from the roaming WTRU (HRES). The HRES may refer to an expected hash value of a generated RND value calculated by the VN and expected to be extracted by the roaming WTRU when calculating the Auth-Res. The Auth-Vec may be used to transmit an authentication challenge to the roaming WTRU according to the authentication policy determined in the WTRU-RPT context. At 1407, the VN may transmit an authentication request to the roaming WTRU to begin the authentication process. The authentication request may include the generated Auth-Vec.

[0228] At 1408, the roaming WTRU may extract the authentication challenge from the Auth-Vec received from the VN and / or may begin generating a response to the received authentication challenge. The roaming WTRU may calculate the required parameters to form an authentication response (Auth-Res), which may be transmitted to the VN as a response to the authentication request. For example, according to Fig.15 and Fig.16 , the content of the Auth-Res may depend on which authentication policy is used to authenticate the roaming WTRU. After generating the Auth-Res, the roaming WTRU may transmit a response to the authentication request to the VN at 1409. The roaming WTRU may append the obtained constructed Auth-Res to the response.

[0229] When the VN receives the Auth-Res from the roaming WTRU, at 1410, the VN may verify the received Auth-Res, including the parameters included in the Auth-Res. Fig.15 and 16 , the VN may verify whether the hash value of the actually received Auth-Res is equal to the HRES (the hash value of the expected response). At 1411, the VN may transmit a notification to the roaming WTRU indicating that the authentication phase was successfully completed.

[0230] exist Fig.15 and Fig.16 The details of the mutual authentication process between the VN and / or the roaming WTRU may be interpreted according to the authentication policy indicated in the WTRU-RPT, such as Fig.14 As depicted in . Fig.15 An example of an authentication process according to an RSA-based authentication policy is shown.

[0231] Described herein is a mutual authentication phase implementation scheme. The following procedure may illustrate the required interaction between the VN and the roaming WTRU to obtain the required authentication process.

[0232] At 1501, the VN may generate a random number (RND). This random number (RND) may be used to form an authentication challenge for the roaming WTRU to resolve as part of the authentication process. The VN may generate an Auth-Vec, which may include a timestamp and / or a signature of the VN. The timestamp (TS) may be the time at which the Auth-Vec was determined. The signature of the VN may be generated, for example, by the VN calculating the TS concatenated with the generated RND and then digitally signing the pair (RND||TS) using the VN secret key. The VN may then encrypt the result using the roaming WTRU public key. Thus, the VN may calculate

[0233] Therefore, Auth-Vec can include Alternatively or additionally, the VN may calculate a hash value of the generated RND (eg, HRES) as an expected response to a challenge transmitted to a roaming WTRU.The VN may maintain the HRES locally.

[0234] After generating the Auth-Vec, the VN may transmit an authentication request to the roaming WTRU at 1502 and / or may attach the constructed Auth-Vec. When the roaming WTRU receives the VN authentication request, the roaming WTRU may begin extracting Auth-Vec parameters and / or may verify the signature of the VN at 1503, for example as follows. The roaming WTRU may extract the TS from the received Auth-Vec and / or may then verify the TS by performing a D to decrypt the rest of the received Auth-Vec.

[0235] When the roaming WTRU decrypts The roaming WTRU may start verifying the signature of the VN. The roaming WTRU may know the public key of the VN from the roaming agreement (VN-Roaming-Key-Repo) between the HN and the VN, which may be stored in the blockchain system and / or the roaming WTRU may obtain the public key before roaming. The roaming WTRU may include the following The ability of the VN to correctly decrypt the received WTRU-RPT, extract WTRU information and / or digitally sign the received (RNDTS) may prove to the WTRU that the VN may be legitimate. Therefore, the roaming WTRU may be able to authenticate the VN at this time.

[0236] After obtaining the (RND||TS) value, the roaming WTRU may extract the RND value and may multiply the RND value with the value of S1 (e.g., the first share of the WTRU certification value). Alternatively or additionally, once the roaming WTRU obtains (S1.RND), the roaming WTRU may calculate the encrypted value Alternatively or additionally, the roaming WTRU may compute a hash value of the RND (SHA256(RND)), which may be used as proof to the VN that the roaming WTRU may be able to correctly extract the transmitted RND.

[0237] When the roaming WTRU completes one or more (e.g., all) of the aforementioned calculations, at 1504, the roaming WTRU may begin to construct an Auth-Res, which may, for example, include a hash value of the extracted RND (e.g., SHA256(RND)) and / or an encrypted value of the first WTRU proof share (S1) multiplied by the RND, wherein one or more (e.g., all) of the calculations may use the roaming WTRU public key At 1505, the roaming WTRU may respond to the authentication request transmitted by the VN. The roaming WTRU's response to the authentication request may include the calculated Auth-Res.

[0238] When the VN receives the Auth-Res from the roaming WTRU, the VN may begin to perform the following procedures at 1506. The VN may extract the calculated hash value (SHA256(RND)) of the RND received from the roaming WTRU and / or may compare its value with the RND received from the roaming WTRU according to the SHA256(RND) algorithm. Fig.15 If the HRES is equal to the SHA256(RND) received from the roaming WTRU, the VN may continue with the remainder of the authentication process; otherwise, the VN may terminate the process and reject the transmitted roaming connection request, for example, based on Fig.14 as described.

[0239] The VN can then use the roaming WTRU public key to calculate the encrypted value of the generated RND When VN is calculated The VN may receive the Auth-Res received in the roaming WTRU by Divide by to extract the value of VN can be obtained from Fig.11 and Fig.14 The WTRU-RPT obtained is known VN can obtain the value of The value of and / or VN can be calculated VN can be computed by following the homomorphic encryption properties described in this paper In other words,

[0240] VN can verify Auth-Res and / or can verify the calculated The hash value of Is it consistent with, for example, the WTRU-RPT that may be issued and based on Fig.14 Obtained The roaming WTRU is authenticated by matching the hash value of the WTRU.

[0241] Described herein are embodiments related to a mutual authentication process according to a CH-based authentication strategy. Fig.16 An example of a mutual authentication process 1600 according to a CH-based authentication strategy is depicted. The following procedure illustrates, for example, Fig.14 An example of the interactions required between a VN and a roaming WTRU to mutually authenticate each other.

[0242] At 1601, the VN may generate a random number (RND). This random number (RND) may be used to form an authentication challenge for the roaming WTRU to resolve as part of the authentication process. Thereafter, the VN may generate an Auth-Vec that includes a timestamp and / or a signature of the VN. The timestamp (TS) may be the time at which the Auth-Vec was determined. To generate the VN's signature, the VN may calculate the TS concatenated with the generated RND, and / or may then digitally sign the (RND||TS) using the VN's secret key pair, and / or may then encrypt the result using the roaming WTRU's public key. Thus, the VN may calculate

[0243] Therefore, Auth-Vec can include The VN may calculate a hash value of the generated RND (eg, HRES) as an expected response to the challenge transmitted to the roaming WTRU. The VN may maintain the HRES locally. Can be equivalent to This means that the RSA operation may be an associative operation. In some examples, unless otherwise specified, the two expressions may be identical. After generating the Auth-Vec, at 1602, the VN may transmit an authentication request to the roaming WTRU. The VN may append the constructed Auth-Vec to the authentication request.

[0244] When the roaming WTRU receives the VN authentication request, at 1603, the roaming WTRU may begin extracting parameters that may be included in the Auth-Vec and / or may verify the signature of the VN. The signature verification of the VN may include the roaming WTRU extracting the TS from the received Auth-Vec and / or then performing to decrypt the rest of the received Auth-Vec.

[0245] Once the roaming WTRU decrypts The roaming WTRU may then start verifying the VN's signature. The roaming WTRU may know the VN's public key from the roaming agreement between the HN and the VN (VN-Roaming-Key-Repo), which may be stored in the blockchain system and / or the roaming WTRU may obtain the public key before roaming. Therefore, the roaming WTRU may calculate the following (RND||TS). The ability of the VN to correctly decrypt the received WTRU-RPT, extract WTRU information and / or digitally sign the received (RND TS) may prove to the WTRU that the VN may be legitimate. Therefore, a roaming WTRU may be able to authenticate the VN.

[0246] After obtaining the (RND||TS) value, the roaming WTRU may extract the RND value. The roaming WTRU may cause a hash collision between the CH hash value of the extracted RND and / or the CH hash value of the WTRU attestation included in the WTRU-RPT. The collision caused between the WTRU attestation and the RND received from the VN may result in obtaining a new CHCPP value (a' WTRU ,b' WTRU ), the new CHCPP value causes a conflict between the CH value of the RND received from the VN and the CH value verified by the WTRU. In other words, the roaming WTRU may be able to run CH.Col such that (a' WTRU ,b' WTRU )=CH.Col(X WTRU ,WTRU proof fingerprint,RND,q,p,g). Alternatively or additionally, the roaming WTRU may compute a hash value (SHA256(RND)) which may be used as proof of the VN that the roaming WTRU was able to correctly extract the transmitted RND.

[0247] When the roaming WTRU completes one or more (e.g., all) of the aforementioned calculations, the roaming WTRU may construct an Auth-Res at 1604. The Auth-Res may include a hash value of the extracted RND (SHA256(RND)) and / or a calculated new CHCPP (a') corresponding to the CH value of the RND received from the VN. WTRU ,b' WTRU At 1605, the roaming WTRU may respond to the authentication request transmitted by the VN. The roaming WTRU's response to the authentication request may include: Fig.15 The calculated Auth-Res.

[0248] After the VN receives the Auth-Res from the roaming WTRU, the VN may perform one or more procedures at 1606. The VN may extract the hash value (SHA256(RND)) of the RND received from the roaming WTRU and / or compare the hash value (SHA256(RND)) of the RND to, for example, Fig.15 If the HRES is equal to the SHA256(RND) received from the roaming WTRU, the VN may continue with the remainder of the authentication process; otherwise, the VN may terminate the process and reject the transmitted roaming connection request, e.g. Fig.14 shown.

[0249] VN can use the received CHCPP(a' WTRU ,b' WTRU ) to calculate the CH hash value of the generated RND. In other words, VN can calculate (CH.Hash(RND,Y WTRU ,p,q,g,a' WTRU ,b' WTRU ), therefore, CHPP(Y WTRU ,p,q,g) may have been published in the WTRU-RPT (e.g., as Fig.13 shown) and / or CHCPP (a' WTRU ,b' WTRU ) may be received from the roaming WTRU as part of the Auth-Res.

[0250] The VN can then use the roaming WTRU public key to calculate (CH.Hash(RND,Y WTRU ,p,q,g,a' WTRU ,b' WTRU )) and / or then verifiably may be equivalent to that already included in the WTRU-RPT (For example, Fig.13 ). Can be equivalent to In the case of a roaming WTRU, the VN may verify and / or authenticate the roaming WTRU; otherwise, the VN may reject the roaming request received from the roaming WTRU (e.g., based on Fig.14 ) and / or terminate the authentication process.

[0251] After verifying and / or authenticating the roaming WTRU to the VN, the VN may begin to initiate the initial network access phase. At this stage, the VN may deploy a decentralized smart contract in the blockchain system to represent the WTRU Charging Policy and Access Agreement (WTRUCPAA). The deployed WTRUCPAA smart contract may indicate the negotiation and / or agreement between the VN and the roaming WTRU regarding, but not limited to, charging standards, the expected QoS that the roaming WTRU can receive, the restrictions and / or regulations that the roaming WTRU can comply with, the method by which the roaming WTRU can prefer payment services, and / or the expected access time of the roaming WTRU.

[0252] Described herein is an initial access implementation. Fig.17 is a flow chart illustrating an example of an initial access procedure 1700. At 1701, the VN may generate a WTRU Charging Policy and Access Agreement (WTRUCPAA). The generated WTRUCPAA may indicate the negotiation and / or agreement between the VN and the roaming WTRU regarding, but not limited to, charging standards, expected QoS that the roaming WTRU may receive, restrictions and / or regulations that the roaming WTRU may comply with, methods that the roaming WTRU may prefer to pay for services, and / or an estimated visit time of the roaming WTRU (e.g., expiration time of the WTRU access).

[0253] After generating the WTRUCPAA, the VN may transmit the WTRUCPAA to the roaming WTRU for confirmation and / or signing at 1702. When the roaming WTRU receives the WTRUCPAA, the roaming WTRU may check the parameters and / or items included in the WTRUCPAA, add any additional items if preferred, and / or then digitally sign the received WTRUCPAA using the roaming WTRU's private key. Then, at 1703, the roaming WTRU may transmit the digitally signed version of the WTRUCPAA to the VN.

[0254] When the VN receives the digitally signed version of the WTRUCPAA, at 1704, the VN may request that the WTRUCPAA be deployed to the blockchain ledger. For example, the WTRUCPAA may convert the WTRUCPAA into a smart contract, create a WTRUCPAA transaction that includes this VN smart contract, and / or transmit this transaction to a blockchain end system (e.g., a blockchain end node) for deployment and / or verification. The VN may also store a copy of the WTRUCPAA transaction in its local database storage device, however this may result in storage overhead. As an alternative, the VN may continue to include a blockchain capability to store the WTRUCPAA smart contract content in a decentralized manner, thereby potentially reducing any possibility of using excessive local storage resources.

[0255] When the blockchain system receives the WTRUCPAA smart contract content, the WTRUCPAA smart contract may be broadcast within the blockchain system and / or may be verified by the blockchain system. After verification of the WTRUCPAA smart contract, at 1705, the blockchain system may transmit a response to the VN indicating that the WTRUCPAA smart contract may have been successfully verified and / or stored in the blockchain ledger. This response may include the address of the WTRUCPAA smart contract stored in the blockchain system and / or any additional information that may be required to access the WTRUCPAA smart contract from the blockchain system.

[0256] At 1706, the VN may generate a temporary identifier (WTRU-TmpID), for example, for the roaming WTRU to represent the temporary SUPI. In this manner, the VN may treat the roaming WTRU as a temporary subscriber so that the roaming WTRU may be authenticated, accessed and / or utilize VN resources similarly to any other WTRU subscribed to the VN as a HN. This WTRU-TmpID may be used temporarily during the roaming WTRU's visit. Thus, the WTRU-TmpID may have a predetermined expiration date determined in the WTRUCPAA transaction.

[0257] In the event that a roaming WTRU may prefer to extend access to the VN coverage, the WTRU may transmit a notification to the VN indicating that the roaming WTRU may want to increase the visited time period. The WTRU-TmpID may be represented as a set of structured numbers (e.g., similar to the SUPI structure defined in 3GPP specification TS23.501). As an example, the first three digits may represent the Mobile Country Code (MCC) of the VN, and the last two or three digits form the Mobile Network Code (MNC) that identifies the VN; and / or the remaining (nine or ten) digits may be referred to as a Roaming Mobile Subscriber Identification Number (R-MSIN) and may represent a roaming WTRU within the VN, which may be generated as a unique random number to identify the roaming WTRU.

[0258] The VN may accept the received roaming connection request transmitted by the roaming WTRU. At 1707, the VN may transmit a roaming connection response to the roaming WTRU. The VN may append the WTRUCPAA address in the roaming connection response as a confirmation that the WTRUCPAA smart contract may have been successfully deployed in the blockchain. Alternatively or additionally, the VN may append an encrypted version of the generated WTRU-TmpID using the roaming WTRU's public key and / or digitally signed by the VN's private key.

[0259] Dual authentication between a roaming WTRU and a VN may be performed. In order to improve roaming security and allow the same level of mutual authentication between the VN and the roaming WTRU, a dual authentication mechanism may be provided. Dual authentication in this context refers to obtaining two authentication levels to ensure authenticity and / or verifiability between the VN and the roaming WTRU. This means: 1) the roaming WTRU may authenticate the VN at least several times (e.g., twice); and / or 2) the VN may also authenticate the roaming WTRU at least several times (e.g., twice). More precisely, the VN may authenticate the roaming WTRU by verifying the roaming WTRU digital signature, followed by a second authentication through WTRU attestation using one of the proposed authentication-based strategies described herein. Similarly, the roaming WTRU may authenticate the VN by verifying the digital signature obtained by the VN, and / or may then authenticate the VN through a certificate similar to the WTRU attestation, which is represented as a VN attestation. In this regard, the roaming service mutual authentication phase may consider that the roaming WTRU and the VN respectively maintain a decentralized WTRU attestation and / or a decentralized VN attestation, which is a process represented as dual authentication. To achieve this, the VN may need to simultaneously request the issuance of a VN certificate from one or more (eg, multiple) trusted authorities that the VN, HN, and / or roaming WTRU can trust.

[0260] HN is a trusted authority that issues VN certificates and / or WTRU certificates for VN and / or roaming WTRU, respectively. HN may not be considered the only trusted authority. In other words, any other trusted entity may be considered a viable issuer of VN certificates and / or WTRU certificates. For example, a trusted third party identified as a trusted authority by the blockchain system may replace HN to issue VN certificates, WTRU certificates, or both. In this case, the concepts of VN and HN may be replaced with only a network (NW).

[0261] The HN may be considered as the issuer of the VN certificate. The VN and the HN may agree on the manner of issuing the VN certificate during the roaming service activation process (e.g., according to Fig.10). Two proposed authentication strategies (e.g., the RSA-based authentication strategy and the CH-based authentication strategy described herein) may be used to issue VN certificates. The HN may use these two authentication strategies to issue VN certificates for the VN, which may enable enhanced flexibility for the VN to select a better (e.g., optimal) authentication strategy that matches the roaming WTRU capabilities and / or the authentication strategy method used to issue WTRU certificates for the roaming WTRU. For example, a particular roaming WTRU may be able to perform or calculate CH functions in a fast manner; therefore, given an issued VN certificate, the CH-based authentication strategy may be a better (e.g., optimal) option for the particular roaming WTRU employed during the VN authentication process. In contrast, other roaming WTRUs may be able to perform or calculate RSA-based calculations, and therefore, if the VN certificate is issued according to the RSA-based authentication strategy, the RSA-based authentication strategy may be a better (e.g., optimal) choice for these other roaming WTRUs.

[0262] Fig.18 An example roaming service agreement 1800 is depicted that takes into account VN certification. At 1801, the VN and HN may exchange potential roaming agreements, policies, and / or roaming service enablement criteria to determine roaming service and charging policy agreements. At 1802, the HN may request the VN to generate a PKI key pair. At 1803, the VN may generate a PKI key pair (e.g., Pk VN As the public key of VN and Sk VN as the private / secret key of the VN).

[0263] When the VN completes the generation of the PKI key pair, at 1804, the VN can use its private key Sk VN Digitally sign roaming service and / or charging policy agreements At 1805, the VN may send a signed version of the roaming service and charging policy agreement and a public key (Pk VN ) is transmitted to HN.

[0264] When the HN receives the response from the VN, at 1806, the HN may initiate a process of issuing a VN certificate for the VN. In view of this, the HN may use the proposed authentication strategy (e.g., CH-based and / or RSA-based) to issue the VN certificate. The HN may transmit a request to the VN to provide the required parameters to the HN in order to issue the VN certificate accordingly. The RSA-based authentication strategy may require the VN's public key, which may have been previously transmitted to the HN. For the CH-based authentication strategy, the HN may require the CH public parameters associated with the VN (e.g., CHPP VN ). Therefore, the HN may transmit a request to the VN so that the VN may transmit the generated CHPPVN Submit to HN.

[0265] When the VN receives the HN request, at 1087, the VN may start generating CHPP by executing the CH.Gen function. VN , for example as described herein. As a result, VN may obtain the following parameters after executing CH.Gen. VN may obtain the private trapdoor key (X VN ), the private trapdoor key can be considered as a secret known only to VN. VN can obtain CHPP VN A tuple that can represent the public value of a CH public parameter. VN Can include CH public key (Y VN ) and / or CH cryptographic primitives (g VN ,p VN ,q VN ). In generating CHPP VN Thereafter, at 1808, the VN may respond to the HN's request and / or send the generated CHPP VN Teleport to HN.

[0266] At 1809, the HN may begin issuing a VN certificate. The HN may generate a VN certificate. The VN certificate content may be represented as a unique identifier representing the relationship between the HN and the VN. The HN may generate authentication parameters associated with a first authentication policy (e.g., an RSA-based authentication policy). In view of this, the HN may split the VN certificate into at least several (e.g., two) secret values ​​or shares (e.g., S VN1 As the first share of VN proof and S VN2 as a second share), in such a way that no share alone can reveal or point to any intelligible information about the secret (VN attestation), as described herein in the context of WTRU attestation.

[0267] In generating a share of VN proof (for example, S VN1 and S VN2 ) then HN can use the VN public key (Pk VN ) to compute an encrypted version of one or more of these shares (e.g., S VN2 ) and / or can then use the private key (Sk HN ) to digitally sign one or more of these shares, such as HN may use VN's public key to generate an encrypted version of the generated VN certificate (e.g., S VN1 and S VN2 The product of ) and / or a hash value (fingerprint) of an encrypted version of the VN certificate can be calculated, such as

[0268] Then, at 1810, the HN may start generating authentication parameters associated with a second authentication policy (eg, a CH-based authentication policy). In this case, the HN may pick any two random numbers to represent the CH conflict common parameters (CHCPP). VN ) value (a VN ,b VN ), these values ​​can be used to calculate the CH hash value of the generated VN certificate. VN Afterwards, HN may execute the CH.Hash function (e.g., Figure 2 ), which may, for example, result in obtaining a CH hash value of the VN certificate (eg, or a VN certificate fingerprint). Alternatively or additionally, the HN may encrypt the generated CH hash value of the VN certificate using the VN public key.

[0269] At 1811, the HN may deploy the VN-Roaming-Key-Repo smart contract and / or determine its attributes, which may include, but are not limited to, any combination of the following. Attributes may include an HN identifier that may identify the issuer of the VN certificate. Attributes may include the public key (Pk HN ), which the roaming WTRU can use to verify the digital signature of the HN. The attributes may include the public key of the VN (Pk VN ), the roaming WTRU can use the public key to verify the VN's digital signature or decrypt any encrypted data that may be received from the VN.

[0270] The attributes may include roaming service and charging policy agreements that may have been digitally signed by the VN and / or may have been received by the HN. Alternatively or additionally, the HN may digitally sign the roaming service and / or charging policy agreements using its secret key. In other words, the HN may calculate

[0271] Attributes may include authentication public parameters related to RSA-based authentication policies. Attributes may include VN certification fingerprints Attributes may include using the public key of the roaming VN The encrypted version of the second share of the encrypted VN certificate (S VN2 ). The attributes may include authentication public parameters related to the CH-based authentication policy. The attributes may include CHPP VN and / or CHCPP VN The attributes may include an encrypted version of the CH hash value of the generated VN certificate (or VN certificate fingerprint) encrypted using the VN's public key and digitally signed by the HN's private key.

[0272] Once the HN completes the composition of the VN-Roaming-Key-Repo smart contract, at 1812, the HN may begin deploying the VN-Roaming-Key-Repo smart contract in the blockchain system (e.g., to publish its contents). The blockchain system may process the received VN-Roaming-Key-Repo smart contract. At 1813, the blockchain system may transmit to the HN a confirmation that the received VN-Roaming-Key-Repo smart contract has been verified. The confirmation may include the address of the VN-Roaming-Key-Repo smart contract deployed and / or verified in the blockchain system.

[0273] Once the HN receives confirmation from the blockchain system that the VN-Roaming-Key-Repo smart contract has been verified, the HN may begin preparing the VN Roaming Public Parameters (VN-RPP). The VN-RPP may be composed of the generated VN certificate and / or the first share of the VN certificate (which is S VN1 At 1814, the HN may send a deployment of the VN-Roaming-Key-Repo smart contract to the VN and a confirmation of the VN-Roaming-Key-Repo smart contract address in the blockchain system and / or the generated VN-RPP.

[0274] The VN may be ready to receive a roaming WTRU request. As explained previously, the roaming WTRU may first request roaming service activation from the HN (e.g., Fig.11 ). In other words, the roaming WTRU may have requested WTRU certification from the HN in preparation for requesting roaming services. Once the roaming WTRU receives the WTRU certification from the HN, the roaming WTRU may begin requesting roaming services from the VN, as described herein. In this regard, roaming services may be obtained in two stages: 1) The first stage may require the roaming WTRU and the VN to mutually authenticate each other. In this context, the roaming WTRU and the VN may initiate a mutual authentication process, wherein the VN and the roaming WTRU may authenticate each other based on a selected authentication policy; and / or 2) Once the roaming WTRU and the VN have mutually authenticated each other, the VN may authenticate each other through a decentralized agreement (e.g., as described in accordance with Fig.17 described) to authorize roaming WTRU access to VN resources.

[0275] In order to obtain dual authentication, where the WTRU and VN can authenticate each other through WTRU certification and / or VN certification, respectively, it may be necessary to incorporate the mutual authentication process (e.g., Fig.14 ) is replaced by a two-factor authentication process (e.g., FIG. 19A to FIG. 19B ). Thus, changes applied to the mutual authentication process may include replacing the mutual authentication process with a dual authentication mechanism.

[0276] As described herein, a roaming WTRU may issue WTRU credentials using either an RSA-based authentication policy (Authentication Policy (1)) or a CH-based authentication policy (Authentication Policy (2)). In view of this, it may be assumed that a roaming WTRU issues roaming WTRU credentials using an RSA-based authentication policy. If a WTRU credentials are issued using a CH authentication policy that allows for CH-based authentication (e.g., according to Fig.16 ), the same procedure applies.

[0277] This article describes the FIG. 19A to FIG. 19B Two-factor authentication implementation. FIG. 19A to FIG. 19B 1900 is a flow chart illustrating an example of a dual authentication procedure. One embodiment may include the WTRU locally storing a copy of the VN-Roaming-Key-Repo smart contract, which may include one or more (e.g., all) required public authentication parameters related to the VN. Before the roaming WTRU requests any roaming services, at 1901, the roaming WTRU may extract the required information about the VN (e.g., the public key of the VN, the hash value of the VN certificate, and / or the S VN2 An encrypted version of the hash value is used by the roaming WTRU to authenticate the VN according to the RSA-based authentication policy).

[0278] The roaming WTRU may start preparing the Auth-Vec-WTRU2VN, which may be sent to the VN as a challenge to authenticate the VN using the selected authentication strategy (RSA-based). Given that the authentication strategy is RSA, the same authentication strategy as described herein may be applied. Fig.15 At 1902, the roaming WTRU may generate a random number (RND WTRU2VN ). This random number (RND WTRU2VN ) may be used to form an authentication challenge to be resolved by the VN as part of the authentication process. The roaming WTRU may generate an Auth-Vec-WTRU2VN, which may include, for example, the following parameters. When determining the Auth-Vec-WTRU2VN, the roaming WTRU may include a timestamp (TS1). The roaming WTRU may include a signature of the roaming WTRU. The roaming WTRU may compare TS1 with the generated RND WTRU2VN Cascade, and then use the roaming WTRU's secret key pair (RND WTRU2VN ||TS1) and / or the result can then be encrypted using the VN's public key. Thus, the roaming WTRU can calculate

[0279] Auth-Vec-WTRU2VN may be calculated as: The roaming WTRU may calculate the generated RND WTRU2VN The hash value (for example, HRES WTRU2VN ) as an expected response to a query sent to the VN. A roaming WTRU may maintain the HRES locally WTRU2VN and / or may not share the expected response (e.g., HRES WTRU2VN ).

[0280] When the roaming WTRU reaches the VN coverage, at 1903, the roaming WTRU may transmit a roaming connection request to the VN, which may include, for example, a WTRU-RPT address in the blockchain system. The WTRU-RPT address may be obtained by using the VN's public key (e.g., ) encryption. Alternatively or additionally, the roaming WTRU may request a dual authentication process to authenticate the VN and / or append the calculated Auth-Vec-WTRU2VN to the request.

[0281] When the VN receives the request from the roaming VTRU, at 1904, the VN may extract the encrypted WTRU-RPT address. The VN may calculate to decrypt the encrypted WTRU-RPT address using its private key to obtain the WTRU-RPT address. Once the VN is able to decrypt and recover the original WTRU-RPT address, at 1905, the VN may transmit a request to the blockchain system to retrieve the WTRU Roaming Proof Transaction (WTRU-RPT) content. At 1906, the blockchain system may inspect the WTRU-RPT and / or may respond to the VN request by transmitting the WTRU-RPT content to the VN.

[0282] At 1907, the VN may generate an Auth-Vec-VN2WTRU. The VN may begin by extracting WTRU authentication parameters and / or roaming WTRU authentication policies from the WTRU-RPT received from the blockchain system. The VN may obtain the required information about the roaming WTRU to begin forming an Auth-Vec-VN2WTRU. The VN may generate an Auth-Vec-VN2WTRU, which may be transmitted as a challenge to the roaming WTRU to authenticate the roaming WTRU using the selected authentication policy (RSA-based) determined in the WTRU-RPT. Given that the authentication policy is an RSA-based authentication policy, the same authentication policy may be applied. Fig.15 A similar approach is shown in .

[0283] The VN may then generate a random number (eg, RND VN2WTRU ). This random number (for example, RND VN2WTRU) may be used to form an authentication challenge for the roaming WTRU to resolve as part of the authentication process. The VN may generate an Auth-Vec-VN2WTRU. When determining the Auth-Vec-VN2WTRU, the Auth-Vec-VN2WTRU may include a timestamp (TS2). The Auth-Vec-VN2WTRU may include the VN may compare TS2 with the generated RND VN2WTRU Concatenated and / or may then be encrypted using the roaming WTRU's public key (RND VN2WTRU TS2), and / or the encrypted version may then be digitally signed using the VN's private key. Thus, the VN will calculate Therefore, the Auth-Vec-VN2WTRU may include VN can calculate the generated RND VN2WTRU The hash value (for example, HRES VN2WTRU ). HRES VN2WTRU A hash value that may represent an expected response that may be received by the VN from a roaming WTRU as part of resolving an Auth_Vec_VN2WTRU challenge transmitted to the roaming WTRU. The VN may maintain locally the expected response (e.g., HRES VN2WTRU ) and / or may not share the expected response (e.g., HRES WTRU2VN ).

[0284] The VN may extract the Auth-Vec-WTRU2VN parameter and / or may then authenticate the signature of the roaming WTRU. The VN may extract the TS1 from the received Auth-Vec-WTRU2VN and / or may then authenticate the signature of the roaming WTRU by performing To decrypt the remaining part of the received Auth-Vec-WTRU2VN.

[0285] Once the VN is decrypted The VN can then start to authenticate the signature of the roaming WTRU. The VN can know the public key of the roaming WTRU from the WTRU-RPT content, so the VN can calculate the following

[0286] In obtaining (RND WTRU2VN ||TS1) value, VN can extract RND WTRU2VN value and / or can be RND WTRU2VN Multiply the value by S VN1 The value of (the first share of VN proof value). Once VN obtains (S VN1 .RND WTRU2VN ), then VN can calculate the encrypted value VN can calculate RND WTRU2VNThe hash value (for example, SHA256 (RND WTRU2VN )), which can be used as proof to the roaming WTRU that the VN may have been able to correctly extract the transmitted RND WTRU2VN Once the VN completes one or more (eg, all) of the foregoing calculations, the VN may construct an Auth-Res-WTRU2VN that may include the extracted RND WTRU2VN The hash value (for example, SHA256 (RND WTRU2VN ) and / or the first VN certification share (S VN1 ) is multiplied by RND WTRU2VN , at least some (e.g., all) computations use the VN public key (e.g., ) to encrypt.

[0287] At 1908, the VN may respond to the authentication request transmitted by the roaming WTRU. The VN response to the authentication request may include the calculated Auth-Res-WTRU2VN. The VN may transmit the calculated Auth-Vec-VN2WTRU as a dual authentication request to the roaming WTRU.

[0288] Once the roaming WTRU receives the Auth-Res-WTRU2VN and / or Auth-Vec-VN2WTRU from the VN, the roaming WTRU may perform the following procedures at 1909. The roaming WTRU may extract the calculated RND from the Auth-Res-WTRU2VN WTRU2VN The hash value, such as SHA256(RND WTRU2VN ). The roaming WTRU can use SHA256 (RND WTRU2VN ) value is similar to the HRES calculated in this paper. WTRU2VN If HRES WTRU2VN Equal to the SHA256(RND received from VN WTRU2VN ), the roaming WTRU may continue with the remainder of the authentication process; otherwise, the roaming WTRU may terminate the process and / or refuse to attach itself to the VN service.

[0289] The roaming WTRU may then use the VN public key to calculate the generated RND WTRU2VN The encrypted value of ). Once the roaming WTRU calculates ), the roaming WTRU may receive the Auth-Res-WTRU2VN received in the Auth-Res-WTRU2VN transmitted by the VN ) divided by ) to extract the value ). The roaming WTRU can obtain the VN-Roaming-Key-Repo The roaming WTRU can know the value of The roaming WTRU can now calculate the value of A roaming WTRU may calculate In other words, The roaming WTRU may verify the Auth-Res-WTRU2VN and / or may verify the calculated The hash value of Published in VN-Roaming-Key-Repo The VN is verified by matching the hash value of

[0290] Once the roaming WTRU authenticates the VN, the roaming WTRU may perform a similar process to authenticate itself to the VN. This may be achieved by calculating the Auth-Res-VN2WTRU that may match the request transmitted by the VN in the Auth-Vec-VN2WTRU. The calculation of the Auth-Res-VN2WTRU may follow the following procedure. The roaming WTRU may extract the TS2 from the received Auth-Vec-VN2WTRU and / or may then perform to decrypt the remaining portion of the received Auth-Vec-VN2WTRU. Once the roaming WTRU decrypts The roaming WTRU may then start by calculating To verify the VN's signature.

[0291] In obtaining (RND VN2WTRU || TS2) value, the roaming WTRU can extract the RND VN2WTRU value and / or can be RND VN2WTRU The value is multiplied by the value of S1 (the first share of the WTRU certification value). Once the roaming WTRU obtains (S1.RND VN2WTRU ), the roaming WTRU may calculate the encrypted value A roaming WTRU may calculate RND VN2WTRU The hash value (for example, SHA256 (RND VN2WTRU )), which serves as proof to the VN that the roaming WTRU has been able to correctly extract the transmitted RND VN2WTRU .

[0292] Once the roaming WTRU completes one or more (eg, all) of the foregoing calculations, the roaming WTRU may construct an Auth-Res-VN2WTRU. The Auth-Res-VN2WTRU may include the extracted RND VN2WTRU The hash value (for example, SHA256 (RND VN2WTRU ) and / or the encrypted value of the first WTRU proof share (S1) multiplied by RND VN2WTRU , where one or more (eg, all) of the computations may use the roaming WTRU's public key (eg, To encrypt.

[0293] Once the roaming WTRU completes the calculation of Auth-Res-VN2WTRU, the roaming WTRU may transmit a response to the dual authentication request to the VN and / or append the value of Auth-Res-VN2WTRU value to the message at 1910. Once the VN receives the Auth-Res-VN2WTRU from the roaming WTRU, the VN may begin to perform the following procedures at 1911. The VN may extract the RND received from the roaming WTRU VN2WTRU The calculated hash value (e.g., SHA256(RND VN2WTRU )), and / or the calculated hash value (e.g., SHA256(RND VN2WTRU )) and the calculated HRES VN2WTRU If HRES VN2WTRU Equal to the SHA256(RND received from the roaming WTRU VN2WTRU ), the roaming VN may continue with the remainder of the authentication process; otherwise, the VN may terminate the process and / or may reject the roaming connection request.

[0294] The VN can then use the roaming WTRU's public key to calculate the generated RND VN2WTRU The encrypted value of Once VN calculates The VN can then receive the Auth-Res-VN2 received by the WTRU in the Auth-Res-VN2 sent by the roaming WTRU. Divide by to extract the value of

[0295] The VN may be learned from the acquired WTRU-RPT VN can obtain the value of VN can be calculated VN can be computed by following the homomorphic encryption property In other words,

[0296] The VN may verify the Auth-Res-VN2WTRU and / or may verify the calculated The hash value of Compared to the WTRU-RPT The hash value matches to verify the roaming WTRU. At 1912, the VN may transmit a notification to the roaming WTRU indicating that the authentication phase was successfully completed.

[0297] Given that after the VN and the roaming WTRU successfully authenticate each other using the dual authentication mechanism, the VN may start initiating the roaming WTRU initial access phase to issue a WTRU-TmpID to the roaming WTRU (e.g., based on Fig.17 ). Once the roaming WTRU has the UE-TmpID, the roaming WTRU may, for example, initiate a roaming WTRU temporary VN accessibility procedure to access VN resources within the roaming WTRU access as agreed upon in the WTRUCPAA transaction.

[0298] Described herein are embodiments related to temporary VN accessibility for a roaming WTRU. It may be assumed that the roaming WTRU and the VN have negotiated accessibility of the roaming WTRU to VN resources. In addition, the VN may have determined the WTRU-TmpID as a temporary identifier for the roaming WTRU to access VN resources. The VN may generate a temporary identifier (WTRU-TmpID) for the roaming WTRU to simplify accessibility of the roaming WTRU to VN resources without the need to re-initiate mutual authentication and / or initial access phase (e.g., as described herein and in accordance with Fig.14 and Fig.17 described above).

[0299] Fig. 20 2000 is a flow chart illustrating an example of temporary VN accessibility for a roaming WTRU. Some embodiments may utilize the same authentication model specified in the 3GPP standards by replacing the network subscriber's SUPI identifier with the WTRU-TmpID generated for the roaming WTRU. Thus, Fig. 20 As shown, the following procedure illustrates any interactions required to authenticate a roaming WTRU using the generated WTRU-TmpID issued by the VN.

[0300] When a roaming WTRU re-accesses a VN, the roaming WTRU may need to re-authenticate itself with the VN. It may be assumed that the roaming WTRU may attempt to access VN resources within the negotiated access time, as described herein. The roaming WTRU may use the WTRU-TmpID obtained from the VN as if it were a roaming WTRU temporary SUPI (e.g., Fig.17For example, similar to how a WTRU generates a SUCI from a SUPI, a roaming WTRU may generate a roaming subscription hidden identifier (R-SUPI) at 2001.

[0301] Once the roaming WTRU generates the R-SUCI from the WTRU-TmpID, the roaming WTRU may transmit a connection request to the VN to re-access the VN resources at 2002. With the connection request, the roaming WTRU may attach the calculated R-SUCI and / or WTRUCPAA (e.g., which may have been previously generated between the roaming WTRU and the VN).

[0302] Once the VN receives the connection request from the roaming WTRU, at 2003, the VN may transmit a request to the blockchain system to retrieve the corresponding WTRUCPAA using the WTRUCPAA address. Once the blockchain system receives the blockchain request, at 2004, the blockchain node may pull the requested WTRUCPAA transaction from the blockchain ledger and / or may transmit the requested WTRUCPAA transaction from the blockchain ledger to the VN as a response.

[0303] Once the VN receives the WTRUCPAA from the blockchain system, then at 2005, the VN may begin extracting the required information to re-authenticate the roaming WTRU using the received R-SUCI. The parameters extracted from the WTRUCPAA transaction may include, but are not limited to, the agreement previously obtained between the VN and the roaming WTRU during the initial access phase, as described herein. The VN may check the expiration time of the roaming WTRU's visited period to ensure the validity of the WTRU-TmpID. The expiration time of the roaming WTRU's visited period may have been determined by the VN (e.g., based on the received R-SUCI). Fig.17 ).

[0304] At 2006, given the provided R-SUCI, the VN may begin authenticating the roaming WTRU. The standard specifications provided by 3GPP for authenticating network subscribers may be considered a perfect fit for the VN to authenticate the roaming WTRU. Alternatively or additionally, the VN may use any standard authentication scheme (e.g., 5G-AKA) to authenticate the roaming WTRU by replacing the WTRU SUPI used in the standard 3GPP authentication scheme with the WTRU-TmpID.

[0305] A WTRU-centric decentralized roaming model may be provided. Described herein is an update or roaming service enablement. In some embodiments, the VN network functions that may be used to manage the roaming service enablement level may be PCF and AUSF network functions. The VN-PCF may be responsible for negotiating roaming services and / or charging policy agreements with the HN network functions (e.g., HN-PCF). The VN-AUSF may be responsible for handling one or more (e.g., all) security-related requests. For example, the VN-AUSF may be responsible for generating public key / private key pairs for authentication, digital signature, encryption, and / or decryption purposes.

[0306] The HN network functions that can be used to handle the roaming service enablement level with the VN can be PCF and AUSF network functions. The HN-PCF may be responsible for negotiating roaming services and / or charging policy agreements with the VN network functions (e.g., VN-PCF). Alternatively or additionally, the HN-PCF may also be responsible for interacting with blockchain nodes to deploy the VN-Roaming-Key-Repo or obtain any information from the blockchain ledger. The HN-AUSF may be responsible for handling all security-related requests. For example, the HN-AUSF may be responsible for verifying the digital signature of the VN and generating a VN-proof for the VN using the proposed authentication strategy (e.g., RSA-based and CH-based).

[0307] A roaming service activation level may be provided. The following HN functions may support a roaming service activation level. The HN-AMF and HN-PCF may be responsible for managing roaming service activation requests. The HN-AMF and HN-PCF may be responsible for negotiating roaming service agreements with roaming WTRUs. The HN-AMF and HN-PCF may be responsible for handling the deployment of UE-RPT transactions in the blockchain network. The HN-AMF and HN-PCF may be responsible for interacting with blockchain nodes to extract certain transactions or receive notifications about transactions deployed in the blockchain network.

[0308] The HN-AUSF and HN-UDM may be responsible for generating the WTRU credentials and / or corresponding RPP that may be transmitted to the roaming WTRU. The HN-AUSF may be responsible for generating the corresponding public authentication parameters that may be issued within the WTRU-RPT transaction.

[0309] Roaming WTRU mutual authentication and initial access level may be provided. The following functions from the 3GPP 5G service architecture may be considered. In an example, the VN functions that support WTRU mutual authentication and / or initial access level may be summarized as follows. The VN-AMF may be responsible for receiving roaming service requests from roaming WTRUs. The VN-AMF may also be responsible for requesting the content of any transaction from the blockchain ledger. For example, the VN-AMF may be responsible for requesting a WTRU-RPT that may be published by the HN in the blockchain ledger.

[0310] The VN-AUSF may be responsible for handling one or more (e.g., all) security-related requests. For example, the VN-AUSF may be responsible for generating an Auth-Vec-VN2WTRU Challenge for a roaming WTRU according to the roaming WTRU authentication policy. The VN-AUSF may also be responsible for authenticating the VN to the roaming WTRU by generating an Auth-Res-WTRU2VN corresponding to the received Auth-Vec-WTRU2VN received from the roaming WTRU.

[0311] A temporary VN accessibility level may be provided for roaming WTRUs. The following network functions may handle interactions with roaming WTRUs to generate WTRU-TmpIDs. The VN functions that support WTRU mutual authentication and / or initial access level may be summarized as follows. The VN-AMF and / or VN-PCF may be responsible for handling negotiations with roaming WTRUs to determine the WTRUCPAA smart contract agreement. The VN-PCF may be responsible for deploying the WTRUCPAA smart contract in the blockchain network or extracting any transaction content from the blockchain ledger.

[0312] The VN-AUSF may be responsible for handling one or more (eg, all) security-related procedures associated with issuing a temporary identifier (WTRU-TmpID) for a roaming WTRU.

[0313] The roaming WTRU may be a HN subscriber. During the period when the roaming WTRU may access HN resources, the roaming WTRU may extract any transaction content (e.g., transactions including VN-Roaming-Key-Repo) from the blockchain ledger and / or store the transaction content locally. In this regard, the roaming WTRU may also extract the VN-Roaming-Key-Repo content offline from the locally stored transaction content during the roaming service request so that the roaming WTRU can authenticate the VN during the roaming process.

[0314] FIG. 21 depicts an example service flow 2100 for roaming service enablement. In an example, the VN and the HN may negotiate a roaming service and / or charging policy agreement. The HN may issue a VN certificate to the VN so that the roaming WTRU may authenticate the VN using one of the determined authentication policies. The HN may issue a VN certificate to the HN using two authentication policies (e.g., an RSA-based authentication policy and / or a CH-based authentication policy) so that the best authentication policy suitable for the roaming WTRU capabilities may be selected to authenticate the VN.

[0315] At 2101, the VN-PCF and / or HN-PCF may, for example, exchange potential roaming service and / or charging policy agreements (which include roaming agreements, policies, and / or roaming service enabling standards) to standardize roaming services provided by the VN to potential roaming WTRUs subscribed to the HN, as described herein. At 2102, the HN-PCF may request the VN-PCF to generate a PKI key pair.

[0316] At 2103, the VN-PCF may transmit a request to the VN-AUSF to generate a VN representative PKI (public / private) key pair. The VN-PCF may attach the roaming service and / or charging policy agreement obtained with the HN-PCF to digitally sign the roaming service and / or charging policy agreement using the generated private key. At 2104, the VN-AUSF may generate a PKI key pair (Pk VN and Sk VN ). When the VN-AUSF completes the generation of the PKI key pair, at 2105, the VN may digitally sign the roaming service and billing agreement.

[0317] When the VN-AUSF completes the digital signature of the roaming service and / or charging policy agreement, at 2106, the VN-AUSF may transmit the generated public key (Pk VN )and At 2107, the VN-PCF may send a signed version of the roaming service and charging agreement and the VN-generated public key (Pk VN ) are transmitted to HN-PCF together.

[0318] When the HN-PCF receives the response from the VN-PCF, at 2108, the HN-PCF may initiate a session to issue a VN certificate for the VN. The HN-PCF may transmit a request to the VN-PCF to provide the parameters required to issue the VN certificate accordingly. An RSA-based authentication strategy may require the VN public key, which may have been previously transmitted to the HN-PCF. For a CH-based authentication strategy, the HN may require the CH public parameters (CHPP) associated with the VN. VN ). Therefore, at 2109, the HN-PCF may transmit the CHPP generated by the submission to the VN-PCF. VN Request.

[0319] When the VN-PCF receives the HN-PCF request, the VN-PCF may forward the request to the VN-AUSF to start generating the CHPP VN When the VN-AUSF receives the VN-PCF request, the VN-AUSF may generate a CHPP by executing the CH.Gen function at 2110. VNAs a result, VN-AUSF can obtain the private trapdoor key (X) after executing CH.Gen. VN ) and / or CHPP VN Tuple. Private trapdoor key (X VN ) can be considered as a secret known to (eg, only to) VN-AUSF. VN The tuple may be a public value representing a CH public parameter. VN Can include CH public key (Y VN ) and / or CH cryptographic primitives (g VN ,p VN ,q VN ).

[0320] At 2111, VN-AUSF may generate CHPP VN The value is transmitted to the VN-PCF as a response to the request transmitted by the VN-PCF. VN At 2112, the VN-PCF may respond to the HN-PCF request sent and / or may attach the generated CHPP VN .

[0321] At 2113, the HN-PCF may transmit a request to the HN-AUSF to start generating the VN certificate and / or its corresponding authentication parameters. The HN-PCF may receive the CHPP received from the VN-PCF. VN With VN public key (Pk VN ) is attached to the request. When the HN-AUSF receives the HN-PCF request to generate the VN certificate, the HN-AUSF may begin issuing the VN certificate at 2114. As described herein, the HN-AUSF may generate authentication parameters associated with the first authentication policy (RSA-based authentication policy). In view of this, the HN-AUSF may split the VN certificate into two secret values ​​or shares (e.g., S VN1 and S VN2 ). In generating a share of VN proof (e.g., S VN1 and S VN2 ) then HN-AUSF can use the VN public key (Pk VN ) to compute an encrypted version of one or more of these shares (e.g., S VN2 ) and / or can then use the HN private key (Sk HN ) to digitally sign one or more of these shares, such as As described herein. For example, the HN-AUSF may generate an encrypted version of the generated VN certificate using the VN public key and / or calculate a hash value (fingerprint) of the encrypted version of the VN certificate, e.g., The HN-AUSF may then start generating authentication parameters associated with the CH-based authentication policy as described herein. The HN-AUSF may pick any two random numbers to represent the CH conflict common parameters (CHCPP VN ) value (a VN ,b VN ), which can be used to calculate the CH hash value of the generated VN proof.

[0322] In determining CHCPP VN Afterwards, HN-AUSF may execute the CH.Hash function (e.g., Figure 2 ) to obtain the CH hash value of the VN certificate (or VN certificate fingerprint) (for example, as shown Fig.18 ). The HN may use the VN's public key to encrypt the CH hash value of the generated VN certificate, as described herein.

[0323] The HN-AUSF may generate a VN-RPP which may include a VN certificate and / or an S VN1 , S VN1 Secret parameters that may be known to the VN and / or HN. The HN-AUSF may generate public authentication parameters that may be constituted in the VN-Roaming-Key-Repo smart contract. At 2115, the HN-AUSF may transmit the VN-RPP and the generated authentication parameters to the HN-PCF as a response to the transmitted request.

[0324] When the HN-PCF receives the reply from the HN-AUSF, the HN-PCF may deploy the VN-Roaming-Key-Repo smart contract at 2116 and / or determine its properties, which may include, for example, Fig.18 The one or more parameters shown below may include an HN identifier, which may be used to identify which network issued the VN certificate. The one or more parameters may include the public key (Pk HN ), which the roaming WTRU can use to verify the digital signature of the HN. The one or more parameters may include the public key (Pk VN ), which the roaming WTRU may use to verify the VN's digital signature or to decrypt any encrypted data that may be received from the VN. The one or more parameters may include a roaming service and / or charging agreement digitally signed by both the VN and / or HN secret keys (e.g., Fig.18 shown).

[0325] The one or more parameters may include authentication public parameters associated with an RSA-based authentication strategy. The public parameters may include a VN certification fingerprint The public parameters may also include an encrypted version of the second share of the VN certificate encrypted using the public key of the roaming VN The one or more parameters may include authentication public parameters related to the CH-based authentication policy. The public parameters may include the generated VN certificate, CHPP VN and CHCPP VN The public parameters may also include an encrypted version of the CH hash value of the generated VN certificate (or VN certificate fingerprint) encrypted using the public key of the roaming VN and / or digitally signed by the private key of the HN.

[0326] When the HN-PCF completes the composition of the VN-Roaming-Key-Repo smart contract, at 2117, the HN may deploy the VN-Roaming-Key-Repo smart contract content in the blockchain network. The blockchain node may process the received VN-Roaming-Key-Repo smart contract, and / or may then transmit to the HN at 2118 a confirmation of the transaction that can verify the received VN-Roaming-Key-Repo smart contract. When the HN-PCF receives a confirmation from the blockchain that can verify the VN-Roaming-Key-Repo smart contract, at 2119, the HN may transmit to the VN-PCF the deployment of the VN-Roaming-Key-Repo smart contract and the VN-Roaming-Key-Repo address in the blockchain network and / or the confirmation of the generated VN-RPP. Then, at 2120, the VN-PCF may forward the received VN-RPP value to the VN-AUSF for later use during any future authentication request.

[0327] This document describes a service flow implementation for roaming service activation, such as Fig. 22 Described in. Fig. 22 An example service flow 2200 for a roaming service activation level is depicted. The example service flow 2200 may include one or more (e.g., all) interactions required to obtain a roaming service activation process between a roaming WTRU, an HN-AMF and an HN-PCF, an HN-AUSF+UDM, and a blockchain system.

[0328] The roaming WTRU may negotiate with the HN to issue a WTRU certificate so that the roaming WTRU can use it to authenticate itself to the VN without any assistance from the HN side. At 2201, the roaming WTRU may transmit a request to the HN-AMF, which may be forwarded to the HN-PCF to activate the roaming service. This request may include the following parameters: WTRU-ID, WTRU certificate lifetime and / or authentication policy. The WTRU-ID may represent an identifier of the WTRU (e.g., the WTRU's SUCI, the WTRU's decentralized identifier, the WTRU's blockchain address and / or the WTRU's public key). The WTRU certificate lifetime may represent the requested lifetime of the WTRU certificate to be generated by the HN. The authentication policy may represent the authentication strategy supported and / or preferred by the WTRU (e.g., RSA-based, CH-based).

[0329] Fig. 22 In an example, when a roaming WTRU transmits a registration request (e.g., initial registration, mobility registration, periodic registration update, emergency registration, disaster roaming initial registration, and / or disaster roaming registration update) to the RAN and / or HN-AMF, the registration request may include: Fig. 22 One or more (e.g., all) parameters included in or Fig.11 Then, the HN-AMF may follow the following procedure: Fig. 22 One or more of the procedures depicted in .

[0330] When a roaming WTRU transmits a service request to the RAN and / or HN-AMF, the service request may include: Fig. 22 One or more (e.g., all) parameters included in or Fig.11 Then, the HN-AMF may follow the following procedure: Fig. 22 One or more of the procedures depicted in .

[0331] When the HN-PCF receives a roaming service activation request from a roaming WTRU through the HN-AMF, the HN-PCF may begin negotiating a roaming service agreement at 2202. When the roaming WTRU and / or the HN reach an agreement on roaming service activation, at 2203, the HN-PCF may initiate a session to issue a WTRU certificate for the roaming WTRU using one or more of the authentication policies described herein.

[0332] As described herein, after determining which authentication policy is appropriate for the roaming WTRU to issue a roaming WTRU credential (WTRU credential), at 2204, the HN-PCF may transmit a request to the HN-AUSF to begin generating WTRU credential given the determined authentication policy (RSA-based or CH-based authentication policy). At 2205, the HN-AUSF may begin generating authentication parameters required for WTRU credential and / or verifying WTRU credential. The generated authentication parameters may be determined based on the selected authentication policy determined by the HN and / or the roaming WTRU, such as Fig.12 and Fig.13 At 2206, the HN-AUSF may transmit the calculated WTRU credentials, WTRU-RPP, and / or authentication parameters to the HN-PCF as a reply to the request.

[0333] Once the reply is received, the HN-PCF may create a WTRU roaming proof transaction (WTRU-RPT) context at 2207. The WTRU-RPT context may include a public key (Pk WTRU ), the determined authentication policy for the roaming WTRU, the calculated authentication parameters for the determined authentication policy, the HN identifier and / or any other relevant information to simplify the roaming WTRU authentication process as described herein.

[0334] After creating the WTRU-RPT content, the HN-PCF may broadcast the WTRU-RPT content as a blockchain transaction in the blockchain network at 2208. When the blockchain system verifies the WTRU-RPT, the blockchain system may transmit an acknowledgement with the WTRU-RPT address (e.g., either the sequence number of the transaction, or the sequence number of the block including the transaction) to the HN-PCF at 2209. At 2210, the HN-PCF may send a response to the roaming service activation request to the roaming WTRU via the HN-AMF. The response may include the WTRU-RPT address in the blockchain network, the calculated authentication parameters (WTRU roaming attestation parameters (WTRU-RPP)), and / or the generated WTRU attestation value.

[0335] like Fig. 22 As described in the above, one or more procedures may be implemented by extending the WTRU configuration update procedure. In an example, when the HN-AMF transmits a WTRU configuration update command to a roaming WTRU, the WTRU configuration update command may include the following: Fig. 22 One or more (e.g., all) of the parameters described in Fig.11 One or more (e.g., all) parameters depicted in .

[0336] When the WTRU receives the WTRU-RPP and / or the WTRU-RPT, the roaming WTRU may transmit a request to the blockchain system to obtain the VN-Roaming-Key-Repo smart contract issued by the HN and / or the VN at 2211. When the blockchain system (e.g., a blockchain node) receives the request to obtain the VN-Roaming-Key-Repo smart contract transmitted by the roaming WTRU, at 2212, the blockchain system may obtain the VN-Roaming-Key-Repo from the blockchain ledger and / or transmit a response with the content of the VN-Roaming-Key-Repo transaction to the WTRU.

[0337] Described herein are service flow implementations and initial access implementations for WTRU mutual authentication, such as FIG. 23A to FIG. 23B and Fig.24 As depicted in . FIG. 23A to FIG. 23B One or more (e.g., all) interactions required to obtain a dual authentication procedure between a VN and a roaming WTRU are depicted. Fig.24 One or more interactions between the VN and the roaming WTRU are depicted to handle the initial access process and / or issue a temporary identifier (WTRU-TmpID) to the roaming WTRU.

[0338] The roaming WTRU may transmit a request to the VN to use VN resources during the roaming process. The roaming WTRU and the VN may run a dual authentication mechanism as described herein. After the dual authentication process, the VN may begin to negotiate with the roaming WTRU to generate a temporary identifier (WTRU-TmpID) for the roaming WTRU. One or more of the following assumptions may be considered. It may be assumed that the roaming WTRU may have obtained a WTRU certificate from the HN, as described herein. It may be assumed that the HN and the VN may already have a decentralized agreement and / or have published a Roaming-VN-Key-Repo as described herein. It may be assumed that the roaming WTRU may have obtained the Roaming-VN-Key-Repo from the blockchain network and / or has stored the Roaming-VN-Key-Repo locally in the roaming WTRU storage unit, as described herein.

[0339] FIG. 23A to FIG. 23B An example service flow 2300 for a WTRU dual authentication level is depicted. In the example, Fig. 22 As shown, the WTRU may locally store a copy of the VN-Roaming-Key-Repo smart contract, which may include one or more (e.g., all) required public authentication parameters related to the VN. Before the roaming WTRU requests any roaming services, at 2301, the roaming WTRU may extract the required information about the VN (e.g., the VN public key, the hash value of the VN certificate, and / or the SVN2 hash value for VN authentication according to RSA-based authentication policy).

[0340] The roaming WTRU may begin preparing an Auth-Vec-WTRU2VN, which may be transmitted to the VN as a challenge to authenticate the VN using the selected authentication policy (e.g., RSA-based or CH-based authentication policy). For example, at 2302, the WTRU may generate an Auth-Vec-WTRU2VN, for example, based on an RSA-based authentication policy.

[0341] When the roaming WTRU reaches the VN coverage, at 2303, the roaming WTRU may transmit a roaming connection request to the VN-AMF, which may include the WTRU-RPT address in the blockchain. The WTRU-RPT address may be accessed through the VN's public key (e.g., ) encryption. The roaming WTRU may request dual authentication from the VN and / or append the calculated Auth-Vec-WTRU2VN to the request.

[0342] The roaming connection request procedure may be implemented by extending one or more registration management procedures. At 2303, the roaming WTRU may transmit a registration request (e.g., initial registration, mobility registration, periodic registration update, emergency registration, disaster roaming initial registration, or disaster roaming registration update) to the RAN and / or VN-AMF (e.g., new AMF). The registration request may include, for example, FIG. 23A to FIG. 23B one or more (e.g., all) parameters shown in (e.g., WTRU-RPT address) and / or Fig.14 One or more (eg, all) parameters shown in .

[0343] When the VN-AMF receives the registration request, the VN-AMF may, for example, decide to use one of the following two authentication options based on its local policy. For example, the VN-AMF may first use authentication option 2; when there may not be any response from the HN including the HN-AMF (e.g., the old AMF), the VN-AMF may continue to use authentication option 1; in another example, the VN-AMF may first use authentication option 1, and when authentication option 1 may not work (e.g., the blockchain system may become congested and / or the WTRU-RPT may not be retrieved from the blockchain system in a timely manner), the VN-AMF may change to use authentication option 2.

[0344] In an example, the roaming WTRU may include an authentication indicator in the registration request to indicate which authentication option the VN-AMF may use. The authentication indicator may indicate "use authentication option 1", "use authentication option 2", "use authentication option 2 first, otherwise use authentication option 1", "use authentication option 1 first, otherwise use authentication option 2", or "use both authentication option 1 and authentication option 2". It is important to note that even though the VN-AMF may decide or may be instructed to use authentication option 2, the VN-AMF may use the WTRU-RPT address to retrieve the contents of the WTRU-RPT from the blockchain system to further verify that the authentication-related parameters returned from the HN including the HN-AMF are correct and / or valid. Authentication option 1 continues to be used as FIG. 23A to FIG. 23B Authentication Option 2 may fall back to using one or more existing registration request procedures to contact the HN including the HN-AMF (eg, old AMF) to register and / or authenticate the roaming WTRU.

[0345] The roaming connection request procedure may also be implemented by extending one or more service request procedures. In an example, when the roaming WTRU transmits a service request to the RAN and / or VN-AMF (e.g., a new AMF), the service request may include: FIG. 23A to FIG. 23B One or more (e.g., all) parameters shown in (e.g., WTRU-RPT address) and / or as shown in Fig.14 Alternatively or additionally, when the VN-AMF receives the service request, the VN-AMF may use FIG. 23A to FIG. 23B Alternatively or additionally, the VN-AMF may use one or more procedures to achieve authentication purposes. Alternatively or additionally, the roaming may include an authentication indicator to notify the VN-AMF to use such as FIG. 23A to FIG. 23B One or more programs (e.g., remaining programs) of the programs depicted in .

[0346] When the VN-AMF receives the request from the roaming WTRU, at 2304, the VN-AMF may calculate to decrypt the encrypted WTRU-RPT using its private key to obtain the WTRU-RPT address. When the VN-AMF decrypts and / or recovers the original WTRU-RPT address, at 2305, the VN-AMF may transmit a request to pull the WTRU Roaming Proof Transaction (WTRU-RPT) content to the blockchain system. At 2306, the blockchain system may check the WTRU-RPT and / or may respond to the VN-AMF request by transmitting the WTRU-RPT content to the VN-AMF.

[0347] When the VN-AMF receives the WTRU-RPT content from one or more blockchain nodes, the VN-AMF may transmit a request to the VN-AUSF to start performing a dual authentication process, such as by generating an Auth-Vec-VN2WTRU and / or obtaining an Auth-Res-WTRU2VN, at 2307. The VN-AMF may append to the dual authentication request transmitted to the VN-AUSF, the UR-RPT content, and / or the received Auth-Vec-WTRU2VN.

[0348] When the VN-AUSF receives the roaming WTRU dual authentication request from the VN-AMF, at 2308, the VN-AUSF may begin to extract one or more authentication parameters from the WTRU-RPT, check the authentication policy, and / or check the HN information. At 2309, based on the RSA-based authentication policy, the VN-AUSF may generate the RND VN2WTRU , Auth-Vec-VN2WTRU, calculate the expected hash response (HRES VN2WTRU ) and / or extract the Auth-Vec-WTRU2VN parameter. If a CH-based authentication strategy is selected, a similar approach may be used. Fig.16 A procedure similar to the one shown in .

[0349] Then at 2310, the VN-AUSF may generate the Auth-Vec-VN2WTRU and / or HRES VN2WTRU 2311, the VN-AMF may transmit the calculated Auth-Vec-VN2WTRU as a dual authentication request to the roaming WTRU.

[0350] When the roaming WTRU receives Auth-Res-WTRU2VN and / or Auth-Vec-VN2WTRU from the VN-AMF, the roaming WTRU may start executing FIG. 19A to FIG. 19B At 2312, the roaming WTRU may authenticate the VN, for example, by verifying the parameters received in Auth-Res-WTRU2VN. FIG. 19A to FIG. 19B Similar to the process described in , the roaming WTRU may generate an Auth-Res-VN2WTRU in order to authenticate itself to the VN considering that the authentication policy is RSA based. A similar approach may be taken if a CH based authentication policy is selected. Thus, Fig.16One or more of the programs shown.

[0351] When the roaming WTRU completes the calculation of Auth-Res-VN2WTRU, the roaming WTRU may transmit a response to the dual authentication request and / or append the value of the Auth-Res-VN2WTRU value to the message to the VN-AMF at 2313. When the VN-AMF receives the Auth-Res-VN2WTRU from the roaming WTRU, the VN-AMF may verify the Auth-Res-VN2WTRU at 2314. At 2315, the VN may transmit a notification to the roaming WTRU indicating the successful completion of the authentication phase.

[0352] Fig.24 2400 for an initial access level. After obtaining the dual authentication process, the VN may negotiate with the roaming WTRU to create a WTRUCPAA and / or generate a WTRU-TmpID (e.g., Fig. 20 ). At 2401, the VN-PCF may generate a WTRU Charging Policy and Access Agreement (WTRUCPAA). The generated WTRUCPAA may indicate the negotiation and agreement between the VN and the roaming WTRU regarding, but not limited to, charging standards, expected QoS that the roaming WTRU should receive, restrictions and regulations that the roaming WTRU may comply with, methods that the roaming WTRU may prefer to pay for services, and / or an estimated visit time of the roaming WTRU (e.g., expiration date of the WTRU access), etc.

[0353] After generating the WTRUCPAA, the VN-PCF may transmit the WTRUCPAA to the roaming WTRU via the VN-AMF for confirmation and / or signing at 2402. When the roaming WTRU receives the WTRUCPAA, the roaming WTRU may check the parameters and / or items included in the WTRUCPAA and add any additional items if preferred. The roaming WTRU may then digitally sign the received WTRUCPAA using the roaming WTRU's private key at 2403, and / or may then transmit the digitally signed version of the WTRUCPAA to the VN-PCF via the VN-AMF.

[0354] When the VN receives the digitally signed version of the WTRUCPAA, at 2404, the VN-PCF may request that the WTRUCPAA be deployed to the blockchain ledger. When the blockchain system receives the WTRUCPAA smart contract content, the WTRUCPAA smart contract may be broadcast within the blockchain system and / or may be verified by the blockchain system. After verification of the WTRUCPAA smart contract, at 2405, the blockchain system may transmit a response to the VN-PCF indicating that the WTRUCPAA smart contract may have been successfully verified and / or has been stored in the blockchain ledger.

[0355] At 2406, the VN-PCF may transmit a request to the VN-AUSF to generate a WTRU-TmpID for the roaming WTRU. When the VN-AUSF receives the VN-PCF request, at 2407, the VN-AUSF may generate a temporary identifier (WTRU-TmpID) for the roaming WTRU to represent the temporary SUPI. When the VN-AUSF completes generating the WTRU-TmpID, at 2408, the VN-AUSF may transmit the generated WTRU-TmpID to the VN-PCF.

[0356] When the VN-PCF receives the WTRU-TmpID from the VN-AUSF, the VN-PCF may accept the received roaming connection request transmitted by the roaming WTRU. Then, at 2409, the VN-PCF may transmit a roaming connection response to the roaming WTRU via the VN-AMF, while attaching, for example, the WTRUCPAA address as a confirmation that the WTRUCPAA smart contract may have been successfully deployed in the blockchain. The VN-PCF may attach an encrypted version of the generated WTRU-TmpID using the public key of the roaming WTRU and digitally signed by the private key of the VN

Claims

1. A method performed by a wireless transmit receive unit (WTRU), the method comprising: transmitting, to a first network system, a request for a roaming certification address from the first network system, wherein the first network system comprises a home network system with which the WTRU is registered for performing wireless communications; receiving a response including the roaming certification address from the first network system, wherein the roaming certification address includes an address to a second network system, wherein roaming certification information is accessible via the roaming certification address; transmitting the roaming certification address to a third network system to access the third network system, wherein the third network system is a visited network system; receiving an authentication request from the third network system, wherein the authentication request includes a request to perform authentication based on the roaming certification information; as well as An authentication response is transmitted to the third network system, wherein the authentication response includes a response to the authentication request based on the roaming certification information.

2. The method of claim 1, wherein the roaming proof information is accessible via a distributed ledger.

3. The method of claim 2, wherein the distributed ledger comprises a blockchain.

4. The method of any one of claims 1 to 3, wherein the request transmitted to the first network system includes an indication of an authentication policy supported by the WTRU.

5. The method according to claim 4, wherein the authentication strategy is a Rivest-Shamir-Adleman (RSA) authentication strategy or a Chameleon hash (CH) authentication strategy.

6. The method according to claim 4 or 5, wherein the request transmitted to the first network system comprises: an indication of the lifespan of the roaming proof address; and The location of the WTRU.

7. The method according to any one of claims 4 to 6, further comprising: receiving an authentication challenge from the third network system, wherein the authentication challenge is determined based on the authentication policy supported by the WTRU; as well as The authentication challenge is executed to determine the authentication response.

8. The method according to any one of claims 1 to 7, wherein the response from the first network system also includes authentication parameters and a WTRU proof value for anonymously authenticating the WTRU.

9. The method according to any one of claims 1 to 8, further comprising: Transmitting a request to the blockchain end system to obtain one or more public keys of the third network system to verify and authenticate the third network system; as well as A response including the one or more public keys of the third network system is received from the blockchain system.

10. The method according to any one of claims 1 to 9, further comprising: An indication indicating completion of the authentication is received from the third network system.

11. A wireless transmit receive unit (WTRU), the wireless transmit receive unit comprising: A processor, the processor being configured to: transmitting, to a first network system, a request for a roaming certification address from the first network system, wherein the first network system comprises a home network system with which the WTRU is registered for performing wireless communications; receiving a response including the roaming certification address from the first network system, wherein the roaming certification address includes an address to a second network system, wherein roaming certification information is accessible via the roaming certification address; transmitting the roaming certification address to a third network system to access the third network system, wherein the third network system is a visited network system; receiving an authentication request from the third network system, wherein the authentication request includes a request to perform authentication based on the roaming certification information; as well as An authentication response is transmitted to the third network system, wherein the authentication response includes a response to the authentication request based on the roaming certification information.

12. The WTRU of claim 11, wherein the roaming certification information is accessible via a distributed ledger.

13. The WTRU of claim 12, wherein the distributed ledger comprises a blockchain.

14. The WTRU of any one of claims 1 to 3, wherein the request transmitted to the first network system includes an indication of an authentication policy supported by the WTRU.

15. The WTRU of claim 14, wherein the authentication policy executed by the at least one processor is a Rivest-Shamir-Adleman (RSA) authentication policy or a Chameleon Hash (CH) authentication policy.

16. The WTRU of claim 14 or 15, wherein the request transmitted by the at least one processor to the first network system further comprises: an indication of the lifespan of the roaming proof address; and The location of the WTRU.

17. The WTRU of any one of claims 14 to 16, wherein the processor is configured to: receiving an authentication challenge from the third network system, wherein the authentication challenge is determined based on the authentication policy supported by the WTRU; and The authentication challenge is executed to determine the authentication response.

18. The WTRU of any one of claims 11 to 17, wherein the response from the first network system executed by at least one processor further comprises an authentication parameter and a WTRU proof value for anonymously authenticating the WTRU.

19. The WTRU of any one of claims 11 to 18, wherein the processor is configured to: Transmitting a request to the blockchain end system to obtain one or more public keys of the third network system to verify and authenticate the third network system; and A response including the one or more public keys of the third network system is received from the blockchain system.

20. The WTRU of any one of claims 11 to 19, wherein the processor is configured to: An indication indicating completion of the authentication is received from the third network system.

Images