Roaming with distributed trust for wireless mobile networks

Abstract

NOT VISIBLE DUE TO STATUS OF PATENT

Description

ROAMING WITH DISTRIBUTED TRUST FOR WIRELESS MOBILE NETWORKSCROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Application Number 63 / 553,983, filed on February 15, 2024, the entire contents of which are incorporated by reference as if fully set forth.BACKGROUND

[0002] Existing cellular wireless systems (e.g., 5GS) provide various security functions such as primary authentication during registration, secondary authentication during Protocol Data Unit (PDU) session establishment, network slicing-specific authentication and authorization, network slicing admission control, data plane encryption and integrity protection, etc. Existing 5G primary authentication can be used to authenticate a wireless transmit / receive unit (WTRU) and build the trust for the WTRU. However, 5G primary authentication may not be able to establish the trust relationship between users and network or between two Network Functions (NFs). Existing 5G primary authentication is a centralized solution, which relies on a home network and inherits two shortcomings. First, it cannot be used to build a direct trust relationship between two WTRUs or users of those WTRUs. Second, when a home network becomes unavailable (e.g., due to outage, disaster, the event of many concurrent users), the primary authentication cannot be properly fulfilled.SUMMARY

[0003] A wireless transmit / receive unit (WTRU) may be configured for distributed roaming with distributed trust credentials. A WTRU may send a first registration request to a first network function (e.g., a visited access and mobility function (V-AMF)). The WTRU may receive a first registration update from the first network function. The first registration update may contain a first distributed trust trigger (DTT). The WTRU may prepare a first distributed trust credential (WTRU-DTC or UE-DTC) according to the first DTT. The WTRU may send a second registration request to the first network function(e.g., or another network function that can process the WTRU-DTC and can authenticate the WTRU based on the WTRU-DTC). The second registration request may contain an indication of the WTRU’s identity and / or a WTRU-DTC. The WTRU may receive a first registration response from the first network function. The first registration response may indicate a distributed trust registration area and / or one or more granted services. The WTRU may receive a second registration update from the first network function. The second registration update may contain an indication of one or more updates to the granted services.BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

[0008] FIG. 2 is a system diagram illustrating examples of security functions in a 5G system.

[0009] FIG. 3 is a system diagram illustrating examples of use cases with trust requirements in a 5G system.

[0010] FIG. 4 is a system diagram illustrating an example of a trust enabler framework.

[0011] FIG. 5 is a system diagram illustrating an example of a trust enabler framework implemented in 3GPP Service and System Aspects 2 (SA2).

[0012] FIG. 6 is a system diagram illustrating an example of an on-network trust enabler framework implemented in 3GPP Service System Aspects 6 (SA6).

[0013] FIG. 7 is a system diagram illustrating an example of an off-network trust enabler framework implemented in SA6 wherein a WTRLI2 provides services to a WTRU1 .

[0014] FIG. 8 is a system diagram illustrating an example of an off-network trust enabler framework implemented in a SA6.

[0015] FIG. 9 is a system diagram illustrating an example of advanced roaming in a trust enabler framework.

[0016] FIG. 10 is a logic diagram illustrating an example procedure for distributed roaming with distributed trust credentials.

[0017] FIG. 11 is a logic diagram illustrating an example procedure for decentralized roaming without a home network.

[0018] FIG. 12 is a logic diagram illustrating an example procedure for traffic routing between WTRLIs on different networks.

[0019] FIG. 13 is a logic diagram illustrating an example procedure for switching between Non-Public Networks (NPNs).DETAILED DESCRIPTION

[0020] FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 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, filter bank multicarrier (FBMC), and the like.

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

[0022] The communications systems 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 configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or the 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, a NR NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

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

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

[0025] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 using wideband CDMA (WCDMA). 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).

[0026] 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), which may establish the air interface 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE -A Pro).

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

[0028] 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 implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., an eNB and a gNB).

[0029] 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), GSM EDGE (GERAN), and the like.

[0030] The base station 114b in FIG. 1A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d 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 femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106 / 115.

[0031] 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 varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 / 115 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1 A, 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 be utilizing a NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E- UTRA, or WiFi radio technology.

[0032] The CN 106 / 115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or the other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide 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), user datagram protocol (UDP) and / or the internet protocol (IP) in the TCP / IP internet protocol suite. The networks 112 may include wired and / or wireless communications 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.

[0033] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications 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 over different wireless links). For example, the WTRU 102c shown in FIG. 1 A may be configured to communicate with the base station 114a, which may employ acellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

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

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

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

[0037] Although the transmit / receive element 122 is depicted in FIG. 1 B as a single element, 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.

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

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

[0040] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control the 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, and the like.

[0041] 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 over the air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

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

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

[0044] FIG. 1 C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 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.

[0045] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-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 eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a.

[0046] Each of the eNode-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, scheduling of users in the UL and / or DL, and the like. As shown in FIG. 1 C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0047] The CN 106 shown in FIG. 1 C 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 are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0048] The MME 162 may be connected to each of the eNode-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, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may provide acontrol plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0049] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the 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 user planes during inter-eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

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

[0051] The ON 106 may facilitate communications with other networks. For example, the ON 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 serves 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 the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers.

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

[0053] In representative embodiments, the other network 112 may be a WLAN.

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

[0055] When using the 802.11ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example in in 802.11 systems. For CSMA / CA, the STAs (e.g., every 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.

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

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

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

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

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

[0061] FIG. 1 D is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As noted above, the RAN 113 may employ an 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.

[0062] 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, gNBs 180a, 108b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the 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, the 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).

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

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

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

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

[0067] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, and / or the like. The AMF 162 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.

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

[0069] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an 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, and the like.

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

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

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

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

[0074] 5G systems may include Wireless Transmit / Receive units (WTRUs), Radio Access Networks (RANs), and Core Networks. The 5G System (5GS) is service-centric or service-based. 5G Core Network (5GC) follows Service-Based Architecture (SBA) and contains a variety of Network Functions (NFs), which work together to fulfill and provide needed services to the RAN, WTRUs, and Application Servers / Service Providers. A WTRU may interact with RAN / 5GC via Non-Access Statum (NAS) and Access Stratum (AS) signaling.

[0075] An NF can access other network functions in request / response mode or subscription / notification mode. Before two NFs interact with each other, they first need to register with a Network Repository Function (NRF) so that they can discover each other via the NRF. Among these network functions, the Access, and Mobility Management Function (AMF) is dedicated to managing WTRU access to 5GS and WTRU mobility. The Session Management Function (SMF) is responsible for establishing sessions between a WTRU and 5GC. The Authentication Server Function (AUSF) takes charge of WTRU authentication. In addition, the Policy Control Function (PCF) provides policy rules for other control plane network functions and WTRUs. The PCF assigns an identifier for each created policy rule, which other control plane network functions and WTRUs use to refer to the corresponding policy rule. The User Plane Function (UPF) facilitates monitoring, managing, controlling, and redirecting user plane traffic flows such as between a WTRU and an Application Function (AF). The Network Exposure Function (NEF) enables access to 5G control plane functions to entities such as network applications and AFs which are outside of 5GS and not in the same trusted domain.

[0076] 5GC also provides data storage and analytics services through functions like the Unified Data Management (UDM), the Unified Data Repository (UDR), the Unstructured Data Storage Function (UDSF) and the Network Data Analytics Function (NWDAF). Another critical feature of 5GS is network slicing, which is facilitated by the Network Slice Selection Function (NSSF).

[0077] 5GS introduces a few network functions such as the Location Management Function (LMF) to support location services. The LMF is responsible for calculating, determining, or verifying a final location and any velocity estimation and may estimate the achieved accuracy, based on location information from the target WTRU and / or a RAN node. After the LMF calculates the location of a target WTRU, other entities can access or query its location from the LMF but need to go through a serving AMF.

[0078] Although these network functions are defined as separate logical entities, a particular service scenario may require multiple network functions. For instance, WTRU mobility will need not only an AMF, but also a AUSF and a SMF. For a type of network function, multiple instances could be instantiated and the NRF will maintain the information of each instantiated network function instance. With the emergence of edge computing, some network functions in 5GC, such as the UPF and the NEF, could be deployed and reside in an edge network that is much nearer to and potentially colocated with the RAN.

[0079] FIG. 2 illustrates examples of security functions in a 5G system. 5G security functions cover four different security domains within 5G system: 202 security for network access between WTRU and RAN / 5GC, 204 network domain security between RAN and 5GC, 206 user domain security between Mobile Equipment (ME) and Universal Subscriber Identity Module (USIM), and 208 SBA domain security in 5GC.

[0080] 5G network access security is realized mainly through network access authentication, message encryption, and message integrity protection. Network access authentication includes primary authentication and key agreement, and secondary authentication.

[0081] The primary authentication and key agreement are designed to enable mutual authentication between a WTRU and a network, and agreed keying material (e.g., an anchor key KSEAF) at both network side and WTRU side. The basis behind 5G primaryauthentication and key agreement is that the same long-term key K unique to a WTRU is securely maintained at the US IM and the network. The anchor key KSEAF and other key materials (e.g., keys for encryption and integrity protection for NAS and AS signaling) can independently and identically be derived at the WTRU and at network, without exchanging them over the air, based on the long-term key K. Mutual authentication is established when the WTRU and network prove to each other they know the same long-term key K. Since the primary authentication is based on the longterm key K, it does not consider user-centric aspects (e.g., user behaviors) and cannot authenticate / differentiate users from the same or different WTRUs.

[0082] The secondary authentication is designed as an option to provide security between a WTRU and an external Data Network (DN) as a part of session management. The secondary authentication relies on the SMF to initiate and coordinate the authentication procedure between the WTRU and the DN (e.g., a DN- AAA Server).

[0083] In addition, Zero Trust Architecture (ZTA) principles may be applied in a 5G system. For example, continuous security monitoring of NFs could be deployed in different environments and scenarios with potential errors and malicious attacks.

[0084] A blockchain system could be a permissionless blockchain system (e.g., Bitcoin, Ethereum) where any party or user can use and participate in the blockchain system without pre-granted permissions; or a permissioned blockchain system where access to the blockchain system needs to be permissioned, controlled and / or governed.Permissioned Distributed Ledgers (PDL) as defined by ETSI Industry Specification Group (ISG) on PDL is an example of permissioned blockchain systems.

[0085] PDL can be leveraged and integrated with systems such as 5GS. Examples of functions for provisioning PDL services within a 5GS include the Distributed Ledger Anchor Function (DLAF), the Distributed Ledger Repository Function (DLRF), and the Distributed Ledger Enabler (DLE). The DLAF and the DLRF may be control plane functions for the 5GS. The DLE may be a data plane function. A native Self-Sovereign Identity (SSI) system for telecom networks may enable a user or a network node holding such an identity to access network services among different operators and service providers seamlessly.

[0086] Existing cellular wireless systems (e.g., 5GS) provide various security functions such as primary authentication during registration, secondary authentication during Protocol Data Unit (PDU) session establishment, network slicing-specific authentication and authorization, network slicing admission control, data plane encryption and integrity protection, etc. FIG. 3 illustrates two examples of use cases in mobile networks, which introduce trust requirements different from existing 5G requirements. Use case 1 needs user-level trust between users of a device (302 WTRU1 ) and the network (e.g., 312 3GPP Edge / Core Network). Use case 2 requires trust between users in order to share services across devices (302 WTRU1 and 308 WTRU2). One or both use cases may lead to trust requirements in mobile networks as described below.

[0087] Wireless networks may support user-level trust or user-centric trust. As illustrated in use case 1 in FIG. 3, WTRU-1 302 may be shared by multiple users (e.g., Userl 304 and User2 306) that may change based on location, time, or other factors. For example, a vehicle with an embedded WTRU could be used to offer connectivity and services to passengers (e.g., users who use the embedded WTRU to get access to network).

[0088] Different users show different behaviors; they also may need different network functions, applications functions, and / or services. As such, the trust of these different users, referred to as user-level trust, may be established. In turn, network access requests from different users can be better authenticated and served based on userlevel trust. The network in this use case could be a visited network or a home network (e.g., a Public Land Mobile Network (PLMN) or a Non-Public Network (NPN)). Use case 2 in FIG. 3 may also need user-level trust since multiple users from 302 WTRU1 may attempt to access services from 308 WTRU2 (e.g., used by 310 User3).

[0089] Existing 5G primary authentication can be used to authenticate 302 WTRU1 and build the trust for 302 WTRU1 . However, 5G primary authentication may not be able to establish the trust relationship between users and network or between two NFs. Wireless networks may need user-level trust to enable trustworthy network access for different users.

[0090] Wireless networks may support distributed trust. As illustrated in use case 2 in FIG. 3, a WTRU (e.g., 308 WTRU2) may provide some services (e.g., computingservice, communication relaying service, local functions, local application functions or services), which another WTRU (e.g., 302 WTRU1 ) can request the access to. The service provider (e.g., 308 WTRU2) may authenticate and trust the service consumer (e.g., 302 WTRU1 ). Similarly, the service consumer (e.g., 302 WTRU1 ) may authenticate and trust the service provider (e.g., 308 WTRU2). Such direct trust between two WTRUs (and / or between their users) is referred to as distributed trust.

[0091] Another form of distributed trust is the direct trust between roaming WTRUs and a visited network (e.g., use case 1 ), which can be potentially established without relying on a home network.

[0092] Existing 5G primary authentication is a centralized solution, which relies on a home network and inherits two shortcomings. First, it cannot be used to build a direct trust relationship between two WTRUs or users of those WTRUs. Second, when the home network becomes unavailable (e.g., outage, disaster, the event of many concurrent users), the primary authentication cannot be properly fulfilled. As a result, roaming users (e.g., in use case 1 ) cannot get the access to a visited network or home users cannot get the access to a RAN or edge networks. Wireless networks may benefit from distributed trust that does not rely on a home network so that users can access services from other WTRUs or networks even when the home network becomes unavailable.

[0093] The solutions discussed herein may enable distributed and decentralized roaming in mobile networks.

[0094] A 5GS may support advanced roaming based on distributed and / or user-level trust. In 5GS, roaming can take place from a home public land mobile network (HPLMN) to a visiting PLMN (VPLMN), or from a HPLMN to a Public Network Integrated NPN (PNI-NPN). 5GS specifies a few roaming-related features such as home-routed roaming, local breakout, disaster roaming, Steering of Roaming (SoR), etc. Existing roaming mechanisms have some limitations. Existing roaming mechanisms rely on a home network for primary authentication, which cannot be properly completed when the home network becomes unavailable. This may prevent roaming WTRUs from accessing visited networks when the home network is not accessible. Existing roaming mechanisms may not support trustworthy inter-NPN roaming or switching.

[0095] Mobile networks may provide improved support for trustworthy inter-NPN roaming (e.g., roaming between two standalone NPNs in applications such as smart factories and their supporting supply chain management). Mobile networks may support more advanced roaming (e.g., by leveraging distributed and user-level trust when they are enabled by the wireless system). Mobile networks will be able to support more resilient roaming with higher system performance (e.g., more smooth roaming services).

[0096] The following terms may be of interest to the learned reader.

[0097] The term "Device” may refer to a WTRU and / or a UE (e.g., as defined in 3GPP TR 21 .905). Device, UE and WTRU may be interchangeably used in this disclosure, unless there is an explicit clarification.

[0098] The term “Network Function (NF)” may refer to a processing function in a network (e.g., 5GC). In examples, an NF in this disclosure may be an AF, an edge application or service, a service provided by a device, an application provided at a device, a server, or a service in a data network, etc.

[0099] The term “User” may refer to an entity (e.g., a human, but not necessarily a human) that uses a WTRU. A user may be outside of a WTRU or an entity within the WTRU. In examples, a NF consumer may be a user. In examples, an application running on a WTRU can be regarded as a user too. In examples, a WTRU (e.g., a WTRU without USIM) can also be regarded as a user. In examples, a device that uses a WTRU to get access to 3GPP network may also be a user of this WTRU.

[0100] The term “Distributed Ledger System (DLS)” may refer to a system that includes or uses distributed ledgers and / or distributed repositories. A DLS may include permissioned distributed ledgers / repositories and / or permissionless distributed ledgers / repositories. DLS may refer to trustworthy data storage or repository functions that cannot be attacked by and / or fully dependent on a centralized party.

[0101] The term “Distributed Trust (DT)” may refer to a direct trust relationship between two entities that does not rely on a centralized third party. In examples, those two entities could be a WTRU and a network; a user of a WTRU and a network; two users; two WTRUs; two NFs; two AFs, etc.

[0102] The terms “User-Level Trust (ULT)” or “User-Centric Trust (UCT)” may refer to a trust relationship. In examples, the trust relationship may be between a user of a WTRU and a network, between a user of a WTRU and another WTRU, between a user of a WTRU and a network function, between a user of a WTRU and another user of another WTRU, between a NF consumer and a NF provider, etc. ULT also can be established without relying on a centralized party. In such a case, ULT and DT may be the same. ULT can be referred to as User-Centric Trust (UCT). ULT and UCT may be interchangeably used in this disclosure unless there is an explicit clarification.

[0103] The term “Trusted Device” may refer to a device or WTRU which can be trusted by another Device, entities / users, and / or by a cellular wireless system such as a 6G System (6GS). Trusted Device and Trusted WTRU may be used interchangeably in this disclosure unless there is an explicit clarification.

[0104] The term “Identifier” may refer to the name / identifier / address of an entity (e.g., a device / UE / WTRU, a network function such as 3GPP NFs, the proposed trust enabler client and the proposed trust enabler server, an entity using a WTRU, etc.). In examples, an identifier may be a 3GPP identifier, an IP address, a URL (Uniform Resource Locator), a FQDN (Fully Qualified Domain Name), a blockchain address, etc. The identifier of an entity may enable access and / or give access details based on which other entities can access and interact with this entity.

[0105] The term “Distributed User Identifier (DUID)” may refer to a special type of unique identifier for a user that can be created and owned by the user without relying on a third party. A DUID may be independently formed or established by the user using a DUID generation algorithm or function. Such an algorithm or function may be based on some unique and private information of the user such as a private key, a password, user attributes or properties, and / or user biometrics. Any entity (e.g., a device, an application on the device, a service provided at a device, a NF) can create and possess a DUID as well.

[0106] The term “Distributed Verifiable User Credential (DVUC)” may refer to the credential being created or issued for a user. DVUC can be verified and authenticated in a distributed way without contacting the party that creates or issues DVUC. A user may have one or multiple DVUCs. When an unauthorized user needs to accessservices from an entity such as a NF, the user may present a DVUC to the entity to get the DVUC authenticated and eventually establish ULT / DT with the entity offering services. A DVUC may deprecate an existing DVUC. A DVUC may be dependent on one or multiple existing DVUC.

[0107] The term “Service-Aware User Credential (SAUC)” may refer to a type of DVUC containing target services that DVUC can be applied to and service policies for these target services. SAUC may allow users to choose the right service providers more efficiently without extra steps to consult with other parties. SAUC also may allow service providers to check service policies directly avoiding contacting extra NFs such as PCF. SAUC may make user-centric trust authentication and service access more efficient.

[0108] The solutions discussed herein may be consistent with certain design principles. In examples, such design principles may include avoiding single point of failure (SPOF) in trust authentication; flexible and applicable for different use cases (e.g., use cases in FIG. 3); avoiding introducing high communication or computation overhead to devices; compatibility with 3GPP architecture; and / or easy integration with 3GPP SA2 or SA6 procedures. The solutions discussed herein may provide benefits including, in examples, enabling efficient user-level trust establishment for roaming WTRUs without reliance on a centralized party; and / or enabling efficient distributed trust establishment for roaming WTRUs without reliance on a home network.

[0109] One or more of the solutions herein may utilize a basic trust enabler framework. FIG. 4 illustrates an example of a trust enabler framework for realizing distributed and user-level trust in wireless networks. In some embodiments, a trust enabler framework may include one or more logical entities, such as: a Trust Enabler Client (TEC); a Trust Enabler Server (TES); and a Service Provider.

[0110] The TEC may be a client that can be located within WTRUs. A WTRU may have multiple TECs serving different users or applications. A user may be outside of a WTRU or an entity within the WTRU. A TEC may also be implemented as a function, which can interact with a TES on behalf of one or multiple WTRUs and / or users. A WTRU can be regarded as a special user from TEC’s perspective.

[0111] The TES may be a server that provides a list of functions to TECs and other NFs (e.g., distributed trust authentication, function exposure, interface to 3GPP NFs). A TES can be deployed at Edge / Core Network or even at another WTRU.

[0112] The Service Provider may be an entity or a domain providing services to users / WTRUs. A TES may be a part of a service provider. A service provider and a TES may trust each other. A TES also may be outside of a service provider. In such a case, it may be assumed that the service provider trusts the TES. A service provider may provide its service through other NFs, which the TES can expose itself to or leverage for itself.

[0113] The proposed trust enabler framework has, but is not limited to, the following functions.

[0114] The proposed trust enabler framework may support Distributed Trust Authentication. The WTRU may trust the TEC hosted at the WTRU. The TEC may have been registered to a TES (e.g., registered-to TES) of a service provider. When the WTRU (or a user) needs to access services from the serviced provider, the TEC at the WTRU may present a DTC to the registered-to TES on behalf of the WTRU (or the user). The registered-to TES may authenticate the WTRU’s DTC using a distributed approach and establish distributed trust with the WTRU, on behalf of the service provider. As a result, the target WTRU may be allowed to access services from the service provider.

[0115] The proposed trust enabler framework may support Exposure to Other NFs. A TES may expose its functions to other NFs. In other words, other NFs can request to access functionality and information provided by TES. In examples, a NF can discover roaming WTRUs that have established distributed trust with the TES. NFs also can configure and write information to a TES. For example, an NF can request the TES to trigger a WTRU to conduct distributed trust registration with the TES.

[0116] The proposed trust enabler framework may support Leveraging Other NFs. A TES may also leverage and interact with other NFs. The TES may interact with the Security Anchor Function (SEAF) to check if a WTRU has successfully passed through primary authentication.

[0117] In some examples, there may be 3GPP service and system aspects 2 (SA2) Embodiments for the Trust Enabler Framework. The proposed trust enabler framework can be implemented as 3GPP NFs. FIG. 5 illustrates a 3GPP SA2 embodiment that integrates the proposed trust enabler framework with 3GPP network system.

[0118] TES may be implemented as a control plane function, which can interact with other NFs (e.g., via SBI). TEC may be implemented as a function embedded at the WTRLI. Interactions between the TEC and the TES may take place in the control plane via NAS signaling and be relayed by AMF. In some cases, interactions between the TEC and the TES may be through data plane. For such cases, a PDU session may need to be established between the TEC and the TES for transmitting messages between the TEC and the TES. In some cases, interactions between the TEC and the TES may be through SBI directly. For such cases, the TEC and the TES may access each other’s services (e.g., provided functions) through SBI. In some cases, the TES also may be integrated into an existing 3GPP NF (e.g., SEAF, AMF).

[0119] In some cases, there may be 3GPP service and system aspect 6 (SA6) Embodiments for the Trust Enabler Framework. The proposed trust enabler framework also can be implemented as service layer functions. Although the examples in FIG. 6, FIG. 7 and FIG. 8 describe embodiments within the 3GPP Service Enabler Architecture Layer (SEAL), these solutions could also be realized as a dedicated service enabler framework, which interacts with SEAL.

[0120] FIG. 6 illustrates an example of a 3GPP SA6 embodiment that integrates the proposed trust enabler framework with the 3GPP SEAL on-network functional model. The TEC may be implemented as a part of SEAL clients to serve one or multiple Vertical Application Layer (VAL) clients. The TES may be implemented as a part of SEAL servers, which can be accessed by one or multiple VAL servers.

[0121] A VAL client may be implemented for a user, which will use services provided by a VAL server. The VAL client may have a DU ID and / or a DVUC. The VAL client may present its DVUC to the TES via the TEC, so that the TES can perform distributed trust authentication on the VAL client’s DVUC on behalf of the corresponding VAL server. The TES can interact with NFs in 3GPP Network System via a network interface (e.g., NEF).

[0122] FIG. 7 illustrates an example of a 3GPP SA6 embodiment that integrates the proposed trust enabler framework with the 3GPP SEAL off-network functional model. In some embodiments (e.g., as illustrated in FIG. 7), a WTRU, WTRU2, may have SEAL servers and / or VAL servers. WTRU2 may provide services to another WTRU, WTRU1 . In other words, VAL clients at WTRU1 may request to access information and services provided by WTRU2.

[0123] A TEC may be implemented as a part of SEAL clients at WTRU1 to serve one or multiple VAL clients. A TES may be implemented as a part of SEAL clients at WTRU2, which can be accessed by one or multiple VAL clients.

[0124] A VAL client user may use services provided by a VAL server. The VAL client at WTRU1 may present its DVUC to the TES via the TEC, so that the TES can perform distributed trust authentication on the VAL client’s DVUC on behalf of the corresponding VAL client at WTRU2.

[0125] FIG. 8 illustrates an example of a 3GPP SA6 embodiment that integrates the proposed trust enabler framework with the 3GPP SEAL off-network functional model. In some embodiments (e.g., as illustrated in FIG. 8), one or both of a first WTRU, WTRU1 , and a second WTRU, WTRU2, may have SEAL clients and / or VAL clients. A TEC, TEC1 , may be implemented as a part of SEAL clients at WTRU1 to serve one or multiple VAL clients.

[0126] Similarly, WTRU2 may have a TEC, TEC2, as a part of its SEAL clients, which can be accessed by one or multiple VAL clients. TEC1 and TEC2 may exchange some information such as their distributed trust authentication status (e.g., when a TEC completed distributed trust registration / authorization with a TES for which roaming WTRU).

[0127] The trust enabler framework may support advanced roaming enabled by distributed trust. The proposed trust enabler framework may be used to solve roaming limitations as described previously. FIG. 9 illustrates an example of an advanced roaming architecture based on the proposed trust enabler framework.

[0128] A serving AMF in a visited network may have an embedded TES. The Visited Network (VN) could be a VPLMN, a Public Network Integrated NPN (PNI-NPN), or aStandalone NPN (SNPN). This TES may also be implemented as a standalone NF that the serving AMF can directly interact with.

[0129] When a roaming WTRU contacts the serving AMF, the serving AMF may interact with TES or leverage the embedded TES to perform user-level trust authentication on the roaming WTRU, which will not rely on home network. The serving AMF may or may not perform primary authentication. If primary authentication is performed, the serving AMF may perform distributed trust authentication after primary authentication. If the roaming WTRU is subscription-less, there may be no home network for the roaming WTRU. Thus, primary authentication may not be performed. If distributed trust authentication fails, the serving AMF may reject the roaming WTRU for its access request to the visited network.

[0130] Several advanced roaming schemes are proposed herein. Distributed trust may be leveraged by a Visited Network (VN) to directly authenticate a roaming WTRU in a distributed fashion by the VN. In examples, this may be done without fully relying on the Home Network (HN) or when the HN becomes unreachable.

[0131] In some examples, Distributed Roaming with Distributed Trust Credentials may be used (e.g., as shown in FIG. 10). When the HN becomes unreachable, the roaming WTRU can present its Distributed Trust Credential (DTC) to the VN. The DTC may be a type of DVUC / SAUC, which can be used for authenticating a roaming WTRU. The VN can authenticate the DTC and the roaming WTRU without contacting the HN. In some cases, the VN may authenticate the DTC by leveraging a Distributed Ledger System (DLS). The roaming WTRU can start to access services from the VN. After the HN becomes reachable, the HN may be notified of the roaming WTRU from the VN and the primary authentication for the roaming WTRU can be resumed. If the primary authentication is successful, the VN may adjust, and / or upgrade services being granted to the roaming WTRU. In other words, primary authentication and DTC-based distributed trust can be jointly leveraged, either sequentially or in parallel.

[0132] In some examples, Decentralized Roaming without a Home Network may be used (e.g., as shown in FIG. 11 ). There may be no HN. Each available network such as a Standalone Non-Public Network (SNPN) may be a VN for roaming WTRUs. A roaming WTRU may receive System Information Blocks (SIBs) from available VNs andmay select one appropriate VN to join. The WTRUs selection of a VN to join may be dependent on if the VN supports decentralized roaming and / or if the roaming WTRU meets decentralized roaming requirements (e.g., on distributed trust credentials of roaming WTRUs). Additionally, or alternatively, such information (e.g., if the VN supports decentralized roaming and the corresponding roaming requirements on roaming WTRUs) can be transmitted from the VN to roaming WTRUs using other advertisement or broadcast mechanisms before a roaming WTRU is connected to the VN. The roaming WTRU may initiate a decentralized roaming registration to the selected VN by presenting its decentralized identifier, its credentials, and / or its smart contract information to the VN. The VN and the roaming WTRU can trigger each other’s smart contact to negotiate services that the VN can grant to the roaming WTRU. When the VN changes its smart contract on service offerings, the VN may instruct the roaming WTRU to adjust previously granted services and / or grant services to the roaming WTRU.

[0133] In some examples, traffic routing between two WTRUs on different networks may be used (e.g., as shown in FIG. 12). Roaming WTRUs may be registered to different VNs (e.g., different SNPNs) and may not know each other’s VN. Each VN can publish its registered roaming WTRUs to a DLS, from which other VNs can find currently registered roaming WTRUs. A VN and / or DLS can control which VN / roaming WTRUs can discover or can be discovered by which VN / roaming WTRUs. A VN and / or DLS can also control if the VN of a roaming WTRU (e.g., its location) can be disclosed to other roaming WTRUs from a different VN. A source roaming WTRU can rely on its VN to discover and route traffic to the destination WTRU. A source roaming WTRU itself may discover the destination WTRU. A source roaming WTRU can register itself to the VN of the destination roaming WTRU if the source roaming WTRU is covered by the VN. A destination roaming WTRU can register itself to the VN of the source roaming WTRU if the destination roaming WTRU is covered by the VN. The source roaming WTRU can send traffic to the destination roaming WTRU directly if they both are in the same VN.

[0134] In some cases, distributed roaming with distributed trust credentials may be used. An example procedure for roaming with distributed trust credentials is illustrated in FIG. 10 at 1000 and may include one or more of the operations discussed herein.

[0135] A roaming WTRU may send an existing 3GPP 1002 registration request to the V- AMF, the serving AMF in the VN. This 1002 registration request may contain a WTRU- DTS (Distributed Trust Support) parameter.

[0136] A WTRU-DTS parameter may indicate if the roaming WTRLI supports distributed trust. For example, the WTRU-DTS may indicate one or more of the following. The WTRU-DTS may indicate if the roaming WTRU may have a decentralized identifier, WTRU-DUID. The WTRU-DTS may indicate the type of WTRU-DUID. The WTRU- DUID type may indicate the name or identifier of the underlying trustworthy distributed system (e.g., DLS) that can be used to verify WTRU-DUID. For example, a type may be “Name-of-DLS-Example.” The WTRU-DTS may indicate if the roaming WTRU may have a Distributed Trust Credential, WTRU-DTC. The WTRU-DTS may indicate the type of DTC. An example type could be “A credential for requesting roaming service and this credential can be authenticated in a distributed way without contacting a DTC issuer.” The WTRU-DTS may indicate if the roaming WTRU is able to request DTCs from a DTC issuer. The WTRU-DTS may indicate if the roaming WTRU is able to send its WTRU-DUID and WTRU-DTC to V-AMF.

[0137] The V-AMF may receive the 1002 registration request from the roaming WTRU. The V-AMF may store the WTRU-DTS locally for the roaming WTRU. The V-AMF may start to perform an existing (e.g., 3GPP) WTRU registration procedure. If there are standalone TESs, the V-AMF may select a standalone TES for the WTRU and send WTRU-DTS and the WTRU identifier (WTRU-ID) to the selected TES, which will store WTRU-DTS and WTRU-ID for the WTRU. The registration procedure may include primary authentication, which requires V-AMF to contact the roaming WTRU’s HN (e.g., H-AMF, H-PCF). For the example procedure illustrated in FIG. 10, the HN is unreachable.

[0138] In some cases, as shown at 1004, the V-AMF cannot successfully complete primary authentication for the roaming WTRU since its HN cannot be contacted. If this occurs, V-AMF may send a message (e.g., a 1006 registration update) to the roamingWTRU. The 1006 registration update may contain the following information if the roaming WTRU supports distributed trust as indicated by DTS in step 1 .

[0139] The 1006 registration update may contain a DTT (Distributed Trust Trigger). The DTT may indicate that the HN is unavailable. Thus, the roaming WTRU may need to perform another type of registration with V-AMF, referred to as Distributed Trust Registration (DTR) using its WTRU-DTC, if the roaming WTRU still wants to access services from the VN. DTT may also indicate the following information: The type of WTRU-DTC that the roaming WTRU should be sent to V-AMF (e.g., or the selected TES), and / or the type of WTRU-DUID. The DTT may also indicate the identifier of selected TES (TES-ID), which the roaming WTRU may send a registration request with DTC to.

[0140] At 1008, the roaming WTRU may prepare a WTRU-DTC and / or a WTRU-DUID according to the DTT.

[0141] The roaming WTRU may send a 1010 registration request to the V-AMF to perform DTR. This 1010 registration request may contain one or more of the following parameters. This 1010 registration request may contain the WTRU-DTC. The WTRU- DTC may be the roaming WTRU’s distributed trust credential. This 1010 registration request may contain the WTRU-DUID. The WTRU-DUID may be the roaming WTRU’s decentralized identifier. This 1010 registration request may contain the WTRU-ID. The WTRU-ID may be the roaming WTRU’s 3GPP identifier (e g., SUCI). This 1010 registration request may contain the Primary-Auth-Flag. The Primary-Auth-Flag may indicate the roaming WTRU’s willingness (e.g., Primary-Auth-Flag = “TRUE”) for the VN to perform primary authentication for the roaming WTRU after the HN becomes reachable. Additionally, or alternatively, this 1010 registration request may be sent from the roaming WTRU to the selected TES directly.

[0142] The V-AMF may receive the 1010 registration request. As shown at 1012, it may start to authenticate the WTRU-DTC and / or the WTRU-DUID. For 1012 authenticating the WTRU-DTC, the V-AMF may identify the DTC issuer that has issued and signed WTRU-DTC, retrieve the DTC issuer’s public key and the used signature scheme (e.g., from DLS), and verify the DTC issuer’s signature contained in the WTRU-DTC using the retrieved public key and signature scheme. Similarly, the V-AMF may check with theDLS if WTRU-DUID has been registered or published to the DLS by the same WTRU (e.g., by confirming WTRU-DUID). If (e.g., only if) both WTRU-DTC and WTRU-DUID are successfully verified and authenticated, the registration request from the roaming WTRU may be approved. Otherwise, it may be rejected. If the registration request is rejected, the V-AMF may send a rejection response to the roaming WTRU. If this occurs, one or more (e.g., all) other steps will be skipped. In some examples, this step may be performed by the selected TES rather than the V-AMF.

[0143] The V-AMF may send a 1014 registration response to the roaming WTRU. If the registration request was approved, this response may indicate one or more of the following parameters that should have been previously determined by V-AMF. The response may indicate a DTR area parameter, for example, DTRArea. The DTRArea parameter may refer to the service area under which the roaming WTRU should or should not perform DTR. The response may indicate a DTR time parameter, for example, DTRUpdateTimer. The DTRUpdateTimer may be a timer, during which the DTR is valid. Upon the expiration of the DTRUpdateTimer, the roaming WTRU may perform the next DTR. The response may indicate an approved services parameter, for example, ApprovedServices. The ApprovedServices parameter may refer to a set of services that the V-AMF determines and approves for the roaming WTRU.ApprovedServices may be based on or dependent on WTRU-DTC. For example, if the WTRU-DTC was issued by the HN and there was an agreement between the HN and the VN, the V-AMF may approve services as described by the agreement and / or by WTRU-DTC. In examples, if WTRU-DTC was not issued by the HN, the V-AMF may approve some basic connectivity services (e.g., even with a time limitation) to the roaming WTRU. This may allow the roaming WTRU to get DTCs and present the DTCs to the V-AMF in order to access more advanced services from the VN. The response may indicate a WTRU-NewDUID parameter, a DUID for the roaming WTRU that may be generated by the V-AMF. The V-AMF may create / assign a WTRU-NewDUID for the roaming WTRU, which could be based on one or more or the WTRU-DTC, the WTRU- DUID, the WTRU-ID, and / or the Primary-Auth-Flag. Additionally, or alternatively, the WTRU-NewDUID may be based on other parameters (e.g., the identifier of V-AMF, the registration status of WTRU-DUID). The 1014 registration response may be generatedby the selected TES, which may send the registration response to the V-AMF or send it directly to the roaming WTRU.

[0144] The V-AMF may generate a Distributed Trust Registration Record (DTRR) and may 1016 publish the DTRR to DLS, so that DTRR can be retrieved by other parties (e.g., the roaming WTRU’s HN). Additionally, or alternatively, DLS may send an automatic notification of the DTRR to designated parties (e.g., the roaming WTRU’s HN). The DTRR may contain some or all of the following information. The DTRR may contain the WTRU-DUID. The DTRR may contain the WTRU-ID. The DTRR may contain a V-AMF-ID. The V-AMF-ID may be an identifier of the V-AMF. The DTRR may contain a VN-ID. The VN-ID may be an identifier of the VN that V-AMF belongs to. The DTRR may contain a CreationTime. The CreationTime may indicate the time when this DTRR was created. The DTRR may contain a RegExpirationTime. The RegExpirationTime may indicate the expiration time of this successful DTR. The RegExpirationTime may be set to DTRUpdateTimer. The DTRR may contain a WTRU- DTC-ID. The WTRU-DTC-ID may be an identifier of the roaming WTRU’s DTC being authorized.

[0145] After some time, as shown at 1018, the HN may become available. The VN may know this by periodically sending a ping message to the HN or the HN may periodically send a ping message to the VN.

[0146] V-AMF may send a 1020 registration notification to the HN (e.g., H-AMF in the HN) after the HN becomes reachable. This 1020 notification may contain some or all of the following information. The 1020 registration notification may contain a VN-ID: The VN-ID (e.g., a PLMN-ID) may be an identifier of the VN that V-AMF belongs to. The 1020 registration notification may contain a WTRU-ID, as discussed herein. The 1020 registration notification may contain a DTRR-ID. The DTRR-ID may indicate the address of and / or an identifier of the DTRR, through which the HN (e.g., H-AMF) can retrieve DTRR from DLS. Additionally, or alternatively, the whole DTRR may be contained in this notification.

[0147] The HN (e.g., H-AMF) may send a 1022 registration confirmation to V-AMF. The HN (e.g., H-AMF) may request the V-AMF to perform primary authentication for the roaming WTRU. In examples, when Primary-Auth-Flag = “TRUE” was set previously,the V-AMF may start to perform primary authentication for the roaming WTRU. In some cases, even if Primary-Auth-Flag = “FALSE,” the VN may want to protect itself and may still perform primary authentication for the roaming WTRU.

[0148] If the HN (e.g., H-AMF) indicated a need for primary authentication or if Primary- Auth-Flag = “TRUE” was set previously, the V-AMF may conduct any necessary steps of (e.g., 3GPP) 1024 WTRU registration including primary authentication. If the primary authentication is successful, V-AMF may adjust or upgrade any ApprovedServices for the roaming WTRU.

[0149] If the WTRU 1024 registration was successful, the V-AMF may send an (e.g., 3GPP) 1026 registration update to the roaming WTRU. The updated ApprovedServices may be sent to the roaming WTRU via this step. If the 1024 primary authentication was unsuccessful, the V-AMF may terminate services being previously approved to the roaming WTRU.

[0150] Mobile networks may support decentralized roaming without a home network. An example of a procedure of decentralized roaming without a home network is illustrated in FIG. 11 at 1100 and may include one or more of the operations discussed herein.

[0151] At 1102, a roaming WTRU may discover and select VNs. At 1104, the roaming WTRU may receive one or more System Information Blocks (SIBs) broadcasted by VNs with the coverage of the roaming WTRU. Each received SIB may contain some or all of the following information to enable decentralized roaming. Each received SIB may contain a VN-ID. The VN-ID may be an identifier of the VN that broadcasts the SIB. In examples, the VN-ID may be a PLMN-ID, an NPN-ID, or a decentralized identifier that has been registered to DLS and can be retrieved by roaming WTRUs and other parties. Each received SIB may contain a DRS (Decentralized Roaming Support). The DRS may indicate if the VN (e.g., as denoted by VN-ID) supports decentralized roaming. Each received SIB may contain a SDUIDT (Supported DUID Type). The SDUIDT may indicate the type of roaming WTRU’s DUID that the VN may support.

[0152] Each received SIB may contain a SDTCT (Supported Distributed Trust Credential Type). The SDTCT may indicate the type of roaming WTRU’s distributed trust credential that the VN may support. Each received SIB may contain an SSL(Supported Service List). The SSL may be a list of services that the VN supports.Various granularities of services may be indicated by SSL. For example, an SSL may indicate the VN may support connectivity service, data storage service, data analytics service, location services, sensing services, Al service, etc. In examples, an SSL may indicate various categories of connectivity service varying in term of offered bandwidth, the number of allowed PDU sessions, guaranteed latency in the data plane, etc. Each received SIB may contain a DTCI-Addr. The DTCI-Addr may indicate the address or the identifier of DTC Issuers (DTCI) that can issue DTCs matching SDTCT. Each received SIB may contain a DLS-ID. The DLS-ID may be an identifier or the address of DLSs that the VN supports and can interact with.

[0153] Additionally, or alternatively, the information can be transmitted from the VN to the roaming WTRU using other advertisement or broadcast mechanisms before a roaming WTRU is connected to the VN.

[0154] At 1106, the roaming WTRU may select a VN based on the received SIBs. For example, the roaming WTRU may check the SSL and select the VN that can offer expected services to the roaming WTRU.

[0155] If the selected VN does not support (e.g., its DRS = “FALSE”) decentralized roaming, the roaming WTRU may simply 1108 perform existing (e.g., 3GPP) procedures with the VN. Thus, one or more (e.g., all) other steps may be skipped.

[0156] The roaming WTRU may 1106 select a VN that supports decentralized roaming. If the roaming WTRU does not have a required DTC, it may send a request to a DTC Issuer (e.g., from DTCI-Addr) to obtain one or multiple DTCs. The VN may offer the roaming WTRU with minimum connectivity only for requesting DTCs. Additionally, or alternatively, (e.g., at 1110, via a request for a new DTC) the roaming WTRU can reach to the DTC Issuer through other connectivity (e.g., a Wi-Fi Network, a Fixed / Wired Network). This 1110 request may contain some or all of the following information.

[0157] The 1110 request may contain a WTRU-DUID. The WTRU-DUID may indicate the decentralized identifier of the roaming WTRU. The request may contain a DTCT. The DTCT may indicate the type of DTCs that the roaming WTRU requests. The request may contain a VN-ID. The VN-ID may indicate the identifier of the selected VN. The DTC Issuer may know more information about how to generate DTCs that will bepresented to the VN. For example, the VN may require that a DTC include certain fields (e.g., the scope (e.g., a list of VNs) of each issued DTC). The 1110 request may include a WTRU-Info. The WTRU-Info may indicate the extra information that the roaming WTRLI needs to present to the DTC Issuer. The DTC Issuer may rely on WTRU-Info (e.g., another credential that the roaming WTRU may have) to authenticate if a DTC can be issued for the roaming WTRU.

[0158] The DTC Issuer may first authenticate the request according to WTRU-Info. Then, it may generate one or multiple DTC as requested by the roaming WTRU. The DTC Issuer may 1112 send a response comprising one or more generated DTCs to the roaming WTRU.

[0159] Note that the VN may provide basic connectivity to the roaming WTRU for supporting it to communicate with the DTC Issuer. Additionally, or alternatively, the roaming WTRU may use other connectivity (e.g., WiFi, a fixed network, etc.) to interact with the DTC Issuer. If the roaming WTRU already has a DTC, this step may be skipped.

[0160] At 1114, the roaming WTRU may perform distributed registration. The roaming WTRU may 1116 send a decentralized roaming registration request to the VN. This 1116 request may contain some or all of the following information.

[0161] The 1116 decentralized roaming registration request may contain a WTRU- DUID. The WTRU-DUID may be a decentralized identifier of the roaming WTRU.

[0162] The 1116 decentralized roaming registration request may contain a WTRU-DTC. The WTRU-DTC may be a distributed trust credential of the roaming WTRU which may have been received in an earlier step.

[0163] The 1116 decentralized roaming registration request may contain a DLS-ID. The DLS-ID may be an identifier of or the address of the DLSs from which WTRU-DUID and WTRU-DTC may be verified and authenticated, and / or from which the roaming WTRU’s smart contract can be retrieved and / or triggered.

[0164] The 1116 decentralized roaming registration request may contain a WTRU- ContractAddr. The WTRU-ContractAddr may be an identifier of or the address of the roaming WTRU’s smart contract, which has been stored to the DLS. The VN may use WTRU-ContractAddr to retrieve or trigger the roaming WTRU’s smart contract from theDLS. In examples, the smart contract may describe some or all of the following service information. The smart contract may describe how the roaming WTRU is willing to pay services from general VNs or some specific VNs. The smart contract may describe the current balance that the roaming WTRU has already deposited to and / or been subtracted from previous services. The smart contract may describe service requirements of the roaming WTRU.

[0165] Additionally, or alternatively, the roaming WTRU may directly indicate its service request information (e.g., WTRU-Service-Req-Info) in this decentralized roaming registration request. The WTRU-Service-Req-Info may contain the similar service information as described by the smart contract.

[0166] At 1118, the VN may interact with the DLS to authenticate the WTRU-DTC and WTRU-DUID in a distributed fashion without relying on a centralized third party. Note that the identifier of the DLS may be received or the VN can derive the DLS name from WTRU-DUID. Then, the VN can use the DLS name to find its address and / or identifier from the list of DLSs that the VN may support. If the VN trusts the DTC Issuer (e.g., if the VN can authenticate that a DTC was issued / generated / created by a trusted DTC Issuer), the DTC may be authenticated and the roaming WTRU that the DTC was issued / generated / created for can be trusted. For authenticating WTRU-DTC, the VN may identify the DTC Issuer from WTRU-DTC that has issued and signed WTRU-DTC, retrieve the DTC Issuer’s public key and the used signature scheme (e.g., from DLS), and verify the DTC Issuer’s signature contained in WTRU-DTC using the retrieved public key and signature scheme. Similarly, the VN may check with the DLS if WTRU- DUID has been registered or published to the DLS by the same WTRU (WTRU-DUID). The VN may also retrieve the roaming WTRU’s smart contract from the DLS to check if the roaming WTRU has sufficient balance and / or if the VN can provide services as required by the roaming WTRU. If (e.g., only if) both the WTRU-DTC and the WTRU- DUID are successfully verified and authenticated, and the VN accepts the roaming WTRU’s smart contract (e.g., indicated by writing “registration OK” to the WTRU’s smart contract, as shown at 1120), then the registration request may be approved. Otherwise, it may be rejected. If the registration request is rejected, the VN may send a rejectionresponse to the roaming WTRU. If this occurs, one or more (e.g., all) other steps may be skipped.

[0167] At 1120, the VN may write “Successful Registration” or “Registration OK” to the roaming WTRU’s smart contract. Additionally, or alternatively, the VN may write a successful registration record for the roaming WTRU to the DLS. The registration record may contain VN-ID, WTRU-DUID, WTRU-ID, etc.

[0168] If the decentralized roaming registration request did not include WTRU- ContractAddr, but included WTRU-Service-Req-Info, the VN may not write Successful Registration to the WTRU’s smart contract or to the DLS. The VN may obtain the roaming WTRU’s service information directly from the parameter WTRU-Service-Req- Info.

[0169] The VN may generate a DUID for the roaming WTRU (e g., New-WTRU-DUID1 ). Then, at 1122, the VN may send a decentralized roaming registration response to the roaming WTRU. This 1122 decentralized roaming registration response may include some or all of the following information.

[0170] The 1122 registration response may contain a VN-Contract. In some cases, the 1122 decentralized roaming registration response may include the whole content of the VN’s smart contract. Additionally, or alternatively, the VN may just send the address of its smart contract, based on which the roaming WTRU can retrieve the VN’s smart contract from DLS assuming it has been stored to DLS. The VN’s smart contract may describe some or all of the following information. The VN’s smart contract may indicate a VN-ID. The VN-ID may be an identifier of the VN. The VN’s smart contract may indicate the services including their price that the VN can offer to roaming WTRUs. The VN’s smart contract may indicate a VN-DTC. The VN-DTC may be a distributed trust credential of the VN, which the roaming WTRU can use to authenticate the VN.

[0171] The 1122 decentralized roaming registration response may contain a New- WTRU-DUID1 . The New-WTRU-DUID1 may be a DUID that the VN generated for the roaming WTRU.

[0172] The roaming WTRU may 1124 request and / or negotiate services. At 1126, the roaming WTRU may process the VN-Contract as received. If the VN only sent the address of its smart contract, the roaming WTRU may first retrieve the VN’s smartcontract from the DLS using the address. For example, the roaming WTRU may check the services and their price that the VN can offer. The roaming WTRU may also interact with DLS to authenticate VN-DTC.

[0173] At 1128, the roaming WTRU may select a list of required services (e.g., RequiredServices) from the services that the VN can offer. In examples, the roaming WTRU may consider the roaming WTRU’s balance in its smart contract and / or the price the VN may demand.

[0174] At 1130, the roaming WTRU may send a request with the VN’s smart contract address as the destination address to the DLS to trigger the VN’s smart contract. To trigger the VN’s smart contract, this request may include some or all of the following information. The request may include a VN-ContractAddr. The VN-ContractAddr may be the address of the VN’s smart contract. The request may include a New-WTRU- DUID1 . The New-WTRU-DUID1 may be a DUID that the VN generated for the roaming WTRU. The request may include a RequiredServices. The RequiredServices may indicate required services that the roaming WTRU determined previously. The request may include a WTRU-ContractAddr. The WTRU-ContractAddr may be the address of the roaming WTRU’s smart contract.

[0175] After receiving the request from, the DLS may automatically create a smart contact for the roaming WTRU and the VN which may be referred to as a VN-WTRU- Contract. The VN-WTRU-Contract may include some or all of the information as received in the request.

[0176] The VN’s smart contract may be automatically executed. The execution result may include a list of approved services (e.g., an ApprovedServices parameter, which may be the same as RequiredServices). The execution result may be generated as a transaction and be stored in DLS. The balance of the roaming WTRU’s smart contract (e.g., WTRU-Contract-Balance) may be subtracted automatically. The DLS may 1132 send an automatic notification to the VN, which may include one or more of the following: New-WTRU-DUID1 , RequiredServices, ApprovedServices, WTRU- ContractAddr, VN-ContractAddr, etc.

[0177] The DLS may also 1134 send a response to the roaming WTRU including the generated smart contract execution result. This response may include one or more of aVN-ID, a ApprovedServices, a WTRU-ContractAddr, a VN-ContractAddr, a WTRU- Contract-Balance, etc.

[0178] After receiving the notification from the DLS, the VN may 1136 prepare the list of approved services (e.g., similar to or a subset of ApprovedServices) to be offered to the roaming WTRU.

[0179] The VN may 1138 send a notification to the roaming WTRU. This notification may include some or all of the following information. The notification may include a New-WTRU-DUID2. The VN may generate another DUID for the roaming WTRU, which can be used when the roaming WTRU starts to access any approved services from the VN. The notification may contain a ApprovedServices. The notification may include an Other-VN-ID. The VN may suggest other VNs to the roaming WTRU (e.g., if ApprovedServices cannot match RequiredServices from the roaming WTRU). After the roaming WTRU knows other VNs, it may retrieve their information (e.g., their smart contracts) from DLS, select one of them, and register with the selected VN as described herein.

[0180] The roaming WTRU may use the New-WTRU-DUID2 as its identity to access services granted by the VN.

[0181] The roaming WTRU may receive a service adjustment, for example, as shown at 1140. The VN may change its service offers through a smart contract. The VN may 1142 send a service adjustment request to the roaming WTRU. This request may include some or all of the following information.

[0182] The service adjustment request may include a VN-NewContract. The VN- NewContract may be the VN’s smart contract (e.g., its content or its address).

[0183] The roaming WTRU may 1144 send a request to trigger the VN’s smart contract or just send a response to the service adjustment request to the VN. This request may include some or all of the following information. The request may include a VN- NewContractAddr as received from the service adjustment request. The VN- NewContractAddr may indicate the address of the VN’s smart contract stored in DLS. The request may include a New-WTRU-DUID2, as discussed herein. The request may include a RequiredServices. The roaming WTRU may require different services from the VN, based on the VN’s smart contract. The request may include a WTRU-ContractAddr. The WTRU-ContractAddr may indicate the address of the roaming WTRU’s smart contract stored in DLS.

[0184] The DLS may automatically execute the VN’s smart contract and generate an execution result, which may be stored to the DLS. The DLS may 1146 send a response to the WTRU. The execution result may be included in the response being 1146 sent to the roaming WTRU. The DLS may also send an automatic notification containing the execution result to the VN. If the roaming WTRU sent a response to the service adjustment request to the VN as an alternative, the VN will process this response and may approve services as included in RequiredServices. Then, the VN may send the list of approved services to the roaming WTRU.

[0185] The roaming WTRU may 1148 send a service adjustment response to the VN, which may include the execution result.

[0186] A mobile network may support traffic routing between two or more WTRUs on different networks. An example of a procedure for traffic routing in decentralized roaming without a home network is illustrated in FIG. 12 at 1200. There are two roaming WTRUs in FIG. 12: WTRU1 and WTRU2. At 1202a, a first roaming WTRU, WTRU1 may register to a first VN, VN1 (e.g., a SNPN). At 1202b, a second roaming WTRU, WTRU2 may register to a second VN, VN2 (e.g., another SNPN). There may not be any home network. Roaming WTRU1 may originate traffic to be sent to roaming WTRU2. Roaming WTRU1 may not know where roaming WTRU2 is currently registered since there might be no home network.

[0187] The procedure in FIG. 12 is an example of how to efficiently route traffic from roaming WTRU1 to roaming WTRU2. Without this solution, WTRU1 could broadcast its traffic for WTRU2 to one or more (e.g., all) other VNs or search each available VN one by one using a brute-force approach. Eventually one of the other VNs can forward the traffic to WTRU2, but this approach may cause high communication overhead and become inefficient. Another advantage of the proposed solution is that a roaming WTRU can control and change the parties (e.g., other VNs and / or other roaming WTRUs) that can discover the roaming WTRU. This may help to protect its privacy.

[0188] The example procedure in FIG. 12 may include one or more of the following operations.

[0189] Both VN1 and VN2 may register their identifiers (e.g., VN1-ID and VN2-ID) to a DLS at 1202a and 1202b. In examples, VN1 may send VN1 -ID and its public key to the DLS VN2 may send VN2-ID and its public key to the same DLS. VN2 may send its VN discovery policies to the DLS indicating which VN (e.g., VN1 ) is allowed to discover roaming WTRUs which have been registered to VN2. This may enable VN1 and VN2 to search for and find each other using the DLS.

[0190] Roaming WTRUs may register to VNs. For example, roaming WTRU1 may complete distributed registration with VN1 at 1204a and roaming WTRU2 may complete distributed trust registration with VN2 at 1204b, (e.g., using distributed trust registration procedures discussed herein and / or illustrated in FIG. 10). Roaming WTRU2 may send information to VN2 including but not limited to one or more of the following.

[0191] WTRU2 may send a WTRU2-DUID. The WTRU2-DUID may be a globally unique decentralized identifier of roaming WTRU2, which roaming WTRU2 may use to access any VN.

[0192] WTRU2 may send a WTRU2-DTC. The WTRU2-DTC may be a distributed trust credential of roaming WTRU2.

[0193] WTRU2 may send a Discovery-Policies. The Discovery-Policies may indicate the policies or rules to describe if the roaming WTRU2 (e.g., or roaming WTRU1 ) is willing to be discovered by any other VNs, by one or multiple specific VNs, and / or by one or multiple specific roaming WTRUs. The Discovery-Policies may describe specific VNs by their identifiers, and specific WTRUs by their DUIDs.

[0194] Roaming WTRU2 and VN2 may exchange and agree on Discovery-Policies.VN2 may suggest and send some Discovery-Policies to the roaming WTRU2.Roaming WTRU2 may check these Discovery-Policies and send an acknowledge to VN2 if roaming WTRU2 agrees with them. VN2 may store these Discovery-Policies and apply them for roaming WTRU2.

[0195] Roaming WTRU1 may complete distributed trust registration with VN1 using a similar procedure.

[0196] VN1 may generate a Distributed Trust Registration Record (DTRR1 ) for roaming WTRU1 and 1206a store DTRR1 to the DLS. VN2 may generate a Distributed Trust Registration Record (DTRR2) for roaming WTRU2 and 1206b store DTRR2 to the DLS.

[0197] The DTRR1 may include some or all of the following information.

[0198] The DTRR1 may include a WTRU1-DUID. The WTRU1 -DUID may be a globally unique decentralized identifier of roaming WTRU1 .

[0199] The DTRR1 may include a VN1-ID. The VN1 -ID may be the globally unique identifier of VN1 , which has been registered to VN1 .

[0200] The DTRR1 may include a Discovery-Policy. The Discovery-Policy may indicate the policies or rules to describe which VN and its registered roaming WTRUs can discover VN1 and their registered roaming WTRUs (e.g., roaming WTRU1 ).

[0201] If the DTRR1 includes no discovery policies (e.g., no Discovery-Policies or Discovery-Policies is empty), it may imply that DTRR1 can be discovered and used by any other parties. As such, in some examples, VN1 may send the whole DTRR1 to permissionless ledgers in the DLS, for everyone to access.

[0202] If the DTRR1 includes any discovery policies in Discovery-Policies, VN1 may send the whole DTRR1 to permissioned distributed ledgers in the DLS, which only permissioned parties (e.g., as allowed by Discovery-Policies) can access.

[0203] Similar to the DTRR1 , the DTRR2 may include some or all of the following information.

[0204] The DTRR2 may include a WTRU2-DUID. The WTRU2-DUID may be a globally unique decentralized identifier of roaming WTRU2.

[0205] The DTRR2 may include a VN2-ID. The VN2-ID may be a globally unique identifier of VN1 , which has been registered to VN2.

[0206] The DTRR2 may include a Discovery-Policy. The Discovery-Policy may indicate the policies or rules to describe which VN and its registered roaming WTRUs can discover VN2 and their registered roaming WTRUs (e.g., roaming WTRU2). Discovery- Policies may be used to control privacy and security in discovery VN2 and their registered roaming WTRUs.

[0207] If DTRR2 contains no discovery policies (e.g., no Discovery-Policies or Discovery-Policies is empty), it may imply DTRR2 can be discovered and used by any other parties. As such, in some cases, VN2 may send the whole DTRR2 to permissionless ledgers in the DLS, for everyone to access.

[0208] If the DTRR2 includes any discovery policies in Discovery-Policies, VN2 may send the whole DTRR2 to permissioned distributed ledgers in the DLS, which only permissioned parties (e.g., as allowed by Discovery-Policies) can access.

[0209] Roaming WTRII2 may send Discovery-Policies to VN2. For example, roaming WTRLI2 may not want to receive any traffic from other WTRUs. As such, it may have indicated that it cannot be discovered by any other VNs and / or their registered WTRUs. In such cases, roaming WTRU2 may decide to receive WTRU-terminated traffic and inform VN2 that it can be discovered by VN1 , but it cannot be exposed to other roaming WTRU registered to VN1 . For this purpose, VN2 and Roaming WTRU2 may change discovery policies for Roaming WTRU2. WTRU2 may send a discovery policy update request to VN2. This request may contain additional and / or updated Discovery- Policies. VN2 may receive and store the additional and / or updated Discovery-Policies. VN2 may send a discovery policy update response to Roaming WTRU2 indicating the successful update to roaming WTRU2’s Discovery-Policies as stored in VN2. VN2 may send a notification to the DLS to inform the DLS of roaming WTRU2’s additional and / or updated Discovery Policies.

[0210] Roaming WTRU1 may generate one or more messages that need to be sent to roaming WTRU2. Roaming WTRU1 may know the decentralized identifier of roaming WTRU2 (e.g., WTRU2-DUID). But, in some cases, Roaming WTRU1 may not know where roaming WTRU2 is currently registered to. There are multiple options for roaming WTRU1 to route traffic to roaming WTRU2.

[0211] In some cases, routing may be transparent to roaming WTRU1.

[0212] At 1210, Roaming WTRU1 may send traffic for roaming WTRU2 to VN1.Roaming WTRU1 may send a request to VN1 . This request may contain some or all of the following information. The request may include a WTRU1-DUID. The WTRUI - DUID may be the globally unique decentralized identifier of roaming WTRU1 . The request may include a WTRU2-DUID. The WTRU2-DUID may be the globally unique decentralized identifier of roaming WTRU2. The request may include a Msg. The Msg may include the message that roaming WTRU1 wants to send to roaming WTRU2.

[0213] The VN1 may receive the request. VN1 may 1212 send a discovery request to the DLS. This discovery request may aim to discover the VN that roaming WTRU2 iscurrently registered to. This discovery request may include some or all of the following information. The discovery request may include a WTRU1-DUID. The WTRU1-DUID may be a globally unique decentralized identifier of roaming WTRU1 that needs to discover roaming WTRII2. The discovery request may include a VN1-ID. The VN1 -ID may be an identifier of VN1 that roaming WTRII1 is currently registered to. The discovery request may include a WTRU2-DUID. The WTRU2-DUID may be a globally unique decentralized identifier of roaming WTRLI2 to be discovered.

[0214] At 1214, the DLS may authenticate if the discovery request is allowed to discover other roaming WTRUs (e.g., based on Discovery-Policies contained in the stored DTRRs). In some cases, VN1 may be allowed to discover VN2 and VN2’s registered roaming WTRUs may include roaming WTRU2.

[0215] At 1216, the DLS may look up WTRU2-DUID from the stored DTRRs and find DTRR2, which indicates that WTRU2-DUID is currently registered to VN2.

[0216] Additionally, or alternatively, to strengthen discovery authentication, or if DTRR2 does not include any Discovery-Policies, the DLS may 1218 send a discovery authentication request to VN2. VN2 can perform further authentication on if VN1 and / or roaming WTRU1 is allowed to discover roaming WTRU2, based on its policies. This step may be useful especially when DLS cannot find Discovery-Policy in DTRR2. If VN2 has authenticated that VN1 and / or roaming WTRU1 can discover roaming WTRU2, one or more of the steps discussed herein may be skipped. If VN2 has authenticated that VN1 / roaming WTRU1 can discover roaming WTRU2 but VN2 wants to notify WTRU2 that WTRU1 and / or VN1 is discovering WTRU2, VN2 may send a discovery notification to Roaming WTRU2.

[0217] VN2 may send a 1220 discovery notification to Roaming WTRU2. This notification may include WTRU1-DUID and / or VN1-ID. lf VN2 cannot authenticate VN1 / roaming WTRUTs discovery request, this notification may need roaming WTRU2’s approval on if it agrees to be discovered by VN1 and if it is willing to be exposed to roaming WTRU1.

[0218] Roaming WTRU2 may receive the discovery notification. It may decide if it agrees to be discovered by VN1 and if it is willing to be exposed to roaming WTRU1 . Roaming WTRU2 may 1222 send its decision in a notification confirmation to VN2.

[0219] VN2 may 1224 send a discovery authentication response to DLS. This response may indicate some or all of the following information. The response may indicate a VN2-ID if VN1 is allowed to discover VN2 and / or roaming WTRU2. The VN2-ID may be an identifier of VN2. The response may indicate if VN1 is allowed to discover VN2 and / or roaming WTRU2. For example, the response may indicate if VN2-ID can be disclosed from DLS to VN1 and / or roaming WTRU1 . The response may include nothing or a rejection if VN2 and / or roaming WTRU2 did not approve or agree the discovery request from VN1 .

[0220] The DLS may receive the discovery authorization response. The DLS may 1226 send a discovery response to VN1. In some cases, as shown in Fig. 12, VN2 may 1226 send the discovery response directly to VN1 . This discovery response may include the same information as included in the received discovery authorization response. VN1 may receive the discovery response and may store the pair (VN2-ID, WTRU2-DUID) locally assuming VN1 ’s discovery request has been approved.

[0221] In some cases, as shown at 1228, VN1 may forward traffic to roaming WTRU2 via VN2. VN1 may add its identifier VN1 -ID to the request as received in a prior step from WTRU1 and forward the request to VN2. VN2 may receive the request. It may store the pair (e.g., VN1 -ID, WTRU1 -DUID) locally. VN2 may remove VN1-ID from the received request. At 1230, VN2 may forward the received request to roaming WTRU2. Roaming WTRU2 may send a response to VN2 indicating that the request containing Msg has been successfully received. VN2 may forward the response to VN1 , which may forward the response again to roaming WTRU1 .

[0222] In some cases, as shown at 1234, VN1 may forward traffic to roaming WTRU2 directly. If roaming WTRU2 is also in the coverage of VN1 , roaming WTRU2 may 1232 register itself to VN1 by sending its identifier WTRU2-DUID and distributed trust credential (WTRU2-DTC) to VN1 . Roaming WTRU2 may also send VN2-ID to VN1 . After successful registration with VN1 , VN1 may 1234 forward the request (e.g., as received in a prior step from the roaming WTRU) containing Msg directly to roaming WTRU2. In other words, WTRU1 and WTRU2 can have normal communication on VN1.

[0223] In some cases, roaming WTRU1 may discover roaming WTRU2 and then subsequently route traffic to WTRU2. At 1236, Roaming WTRU1 may send a discovery request to VN1 . This discovery request may include WTRU1 -DUID (e.g., the roaming WTRII1 to discover) and / or WTRU2-DUID (e.g., the roaming WTRU2 to be discovered).

[0224] At 1238, VN1 may perform one or more of the discovery procedures discussed herein (e.g., including one or more, or all, of the steps from 1212 to 1226). If VN2-ID is allowed to be exposed to roaming WTRII1 , VN1 may include VN2-ID in a discovery response and 1240 send it to Roaming WTRII1 . To hide VN2-ID from roaming WTRU- 1 , roaming WTRU2’s current location and related privacy may be protected. VN2-ID may be included in this discovery response. There are options for roaming WTRLI1 to send traffic to Roaming WTRU2.

[0225] In some cases, Roaming WTRII1 may 1242 send traffic to Roaming WTRII2 using VN1 as a relay. Roaming WTRU1 may 1242 send a traffic request to VN1 as discussed herein. The traffic request may contain the message Msg to be sent to roaming WTRII2. The VN1 may add its identifier to the request and 1244 forward the request to VN2.

[0226] As discussed herein, the VN2 may receive the request and 1246 forward it to roaming WTRU2. Roaming WTRU2 may send a response to VN2 indicating that Msg has been successfully received; then, VN2 may forward the response to VN1 , which may forward the response again to roaming WTRII1 .

[0227] In some cases, for example, as shown at 1248, Roaming WTRU1 may send traffic to Roaming WTRU2 by registering to VN2. If roaming WTRU1 is also in the coverage of VN2, it may 1252 register itself to VN2 by sending its identifier WTRLI1- DllID and distributed trust credential (WTRU1 -DTC) to VN2. Roaming WTRU1 may also send VN1-ID to VN2.

[0228] After successful registration with VN2, roaming WTRLI1 may 1250 send a request (e.g., traffic for Roaming WTRU2), as discussed herein, to VN2. In examples, this request may include one or more of a WTRU1-DUID, a WTRU2-DUID, and / or a Msg to be sent to the roaming WTRLI, as denoted by WTRU2-DUID.

[0229] VN2 may receive the request and may 1252 forward the request to the roaming WTRU as denoted by WTRU2-DUID (e.g., roaming WTRII2). Roaming WTRII2 maysend a response to VN2 indicating the request containing Msg has been successfully received. VN2 may forward the response to roaming WTRU1 . In other words, WTRU1 and WTRU2 can have normal communication on VN2.

[0230] A WTRLI may be configured for switching between two 3GPP NPNs. As an embodiment of the examples in FIG. 10 and FIG. 11 , FIG. 13 illustrates an example procedure where a roaming WTRU switches from NPN1 to NPN2 at 1300.

[0231] At 1302, a DTC Issuer may publish its public information (e.g., its public key, the signature scheme that the DTC Issuer may use to sign any DTC it generates) to DLS.

[0232] As illustrated in FIG. 11 and described in more detail above, a roaming WTRU may select a VN that supports decentralized roaming and 1304 obtain a DTC from a DTC issuer. The roaming WTRU may request a DTC from a DTC issuer. The DTC issuer may authenticate the request, generate, and send one or multiple DTCs to the roaming WTRU. When the DTC Issuer sends a response to the roaming WTRU, the response may additionally include a list of NPNs (e.g., NPN1 and NPN2 such as their names, their identifiers, and / or their contact addresses) that the roaming WTRU can connect to.

[0233] As illustrated in FIG. 10 and described in more detail above, the roaming WTRU may 1306 send a registration request including a DTC to a first NPN, NPN1. NPN1 may 1308 authenticate the registration request with a DLS. NPN1 may then 1310 send a registration response to the roaming WTRU. NPN1 may include the identifier of another NPN2 (e.g., NPN2-ID) in this response to indicate one or more of the following scenarios.

[0234] In some scenarios, the roaming WTRU may need to switch to NPN2 after a certain time T 1 and / or when the roaming WTRU moves to a location Loci . T 1 and / Loc1 may also be included in this response. In some scenarios, the roaming WTRU can use NPN2 as a backup or as a NPN to connect to if NPN1 becomes unreachable in the future. In some scenarios, the roaming WTRU can connect to NPN2 simultaneously while maintaining the connection with NPN1.

[0235] Optionally, NPN1 may send a 1312 NPN switching request to the roaming WTRU to instruct the roaming WTRU to switching to NPN2. This request may contain some or all of the following information. The request may contain a NPN2-ID. The NPN2-IDmay be an identifier of NPN2 that the roaming WTRU needs to switch to and connect to. The request may contain a Confirm-Model. The Confirm-Model may indicate the model for NPN1 to receive NPN switching confirmation. If Confirm-Model = “From WTRU,” the roaming WTRU should send a NPN switching confirmation to NPN1 after the roaming WTRU is successfully registered to and connect to NPN2 (e.g., as discussed herein). If Confirm-Model = “From NPN,” NPN2 should send a NPN switching confirmation to NPN1 after the roaming WTRU is successfully registered to connects to NPN2 (e.g., as discussed herein).

[0236] As discussed more fully herein and illustrated in FIG. 10, the roaming WTRU may 1314 send a registration request including one or more DTCs to a second NPN, NPN2. This step may be triggered by the information contained in the registration response (e.g., NPN2-ID, T1 , Loci ) (e.g., from NPN1 ). This step may also be triggered by the NPN switching request (e.g., from NPN1 ). This registration request may additionally include some or all of the following information, in addition to parameters including but not limited to WTRU-DTC, WTRU-DUID, WTRU-ID, and / or Primary-Auth- Flag. The registration request may include a NPN1-ID. The NPN1 -ID may be an identifier of NPN1 that NPN switching confirmation shall be sent to. The registration request may include a Confirm-Model, as discussed more fully above.

[0237] As discussed more fully herein, and illustrated in FIG. 10, NPN2 may 1316 use a DLS to authenticate the WTRU-DTC and / or the WTRU-DUID from the Registration Request sent by the roaming WTRU. NPN2 may 1318 send a Registration Response to the roaming WTRU. If Confirm-Model = “From WTRU,” the roaming WTRU may send a 1320 NPN switching confirmation to NPN1. Some information received in this Registration Response from NPN2 may be included in the NPN switching confirmation. The NPN switching confirmation may also include the identifier of NPN2 (e.g., NPN2-ID) and / or the identifier of the roaming WTRU (e.g., WTRU-ID and / or WTRU-DUID).

[0238] If Confirm-Model = “From NPN,” NPN2 may 1322 send a NPN switching confirmation to NPN1 . Some information included in the Registration Response may be included in this NPN switching confirmation. This NPN switching confirmation may also include the identifier of NPN2 (e.g., NPN2-ID) and the identifier of the roaming WTRU (e.g., WTRU-ID and / or WTRU-DUID). Before sending the NPN switching confirmationto NPN1 , NPN2 may need to establish a secure communication connection or link with NPN1.

[0239] After receiving the NPN switching confirmation, NPN1 may 1324 identify some information (e.g., buffered packets for the roaming WTRLI, some context or statistic information about the roaming WTRU) and forward such information to NPN2. The forwarded information may also include the identifier of the roaming WTRU (e.g., WTRU-ID and / or WTRU-DUID), which NPN2 should furthermore forward such information to.

[0240] NPN2 may receive the forwarded information. NPN2 may 1326 forward such information to the roaming WTRU.

Claims

CLAIMS:1 . A wireless transmit / receive unit (WTRU) comprising: a processor and a memory, wherein the processor and memory are configured to: send a first registration request to a network function (NF); receive a registration update from the NF, wherein the registration update comprises a distributed trust trigger (DTT); determine a distributed trust credential based on the DTT; send a second registration request to the NF, wherein the second registration request includes an indication of the distributed trust credential; and receive a registration response from the NF, wherein the registration response comprises an indication of a distributed trust registration area and an indication of one or more granted services.

2. The WTRU of claim 1 , wherein the DTT indicates that a home network that is associated with the WTRU is unreachable.

3. The WTRU of claim 1 , wherein the DTT indicates a type of distributed user identification for the WTRU.

4. The WTRU of claim 1 , wherein the first registration request includes a distributed trust credential associated with the WTRU.

5. The WTRU of claim 1 , wherein the registration response comprises an indication of a distributed trust time period.

6. The WTRU of claim 5, wherein the processor and the memory are configured to: determine to perform a distributed trust registration procedure based on the distributed trust time period expiring.

7. The WTRU of claim 1 , wherein the processor and the memory are configured to:receive a distributed trust registration record, wherein the distributed trust registration record indicates an identity of the WTRU, an identity of the NF, a creation time, or an expiration time.

8. The WTRU of claim 1 , wherein the processor and the memory are configured to: receive an indication that a home network associated with the WTRU has become available.

9. The WTRU of claim 8, wherein the processor and the memory are configured to: receive a second registration update from the NF, wherein the second registration update indicates one or more additional granted services.

10. The WTRU of claim 1 , wherein the distributed trust registration area indicates an area where the WTRU should or should not perform distributed trust registration.

11. A method to be performed by a wireless transmit / receive unit (WTRU), the method comprising: sending a first registration request to a network function (NF); receiving a registration update from the NF, wherein the registration update comprises a distributed trust trigger (DTT); determining a distributed trust credential based on the DTT; sending a second registration request to the NF, wherein the second registration request includes an indication of the distributed trust credential; and receiving a registration response from the NF, wherein the registration response comprises an indication of a distributed trust registration area and an indication of one or more granted services.

12. The method of claim 11 , wherein the DTT indicates that a home network that is associated with the WTRU is unreachable.

13. The method of claim 11 , wherein the DTT indicates a type of a distributed user identification for the WTRU.

14. The method of claim 11 , wherein the first registration request includes the distributed trust credential.

15. The method of claim 11 , wherein the registration response comprises an indication of a distributed trust time period.

16. The method of claim 15, further comprising: determining to perform a distributed trust registration procedure based on the distributed trust time period expiring.

17. The method of claim 11 , further comprising: receiving a distributed trust registration record, wherein the distributed trust registration record indicates an identity of the WTRU, an identity of the NF, a creation time, or an expiration time.

18. The method of claim 11 , further comprising: receiving an indication that a home network associated with the WTRU has become available.

19. The method of claim 18, further comprising: receiving a second registration update from the NF, wherein the second registration update indicates one or more additional granted services.

20. The method of claim 11 , wherein the distributed trust registration area indicates an area where the WTRU should or should not perform distributed trust registration.