Methods for onboarding devices to a wireless blockchain system

Abstract

Methods are described for wireless transmit receive unit (WTRU)-Side Configuration of Blockchain Key Derivation Functions. Methods are also described for WTRU-Side Configuration Device Selection. Methods are also described for WTRU-Side Configuration Notification for Wireless Blockchain Onboarding and Wireless Blockchain Onboarding. WTRUs are also described for performing the methods as described herein.

Description

METHODS FOR ONBOARDING DEVICES TO A WIRELESS BLOCKCHAIN SYSTEMCROSS REFERENCE TO RELATED APPLICATION

[0001] This application claims the benefit of U.S. Provisional Application Serial No 63 / 538,943, filed September 18, 2023, the contents of which are hereby incorporated by reference herein.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. Future cellular wireless systems such as 6G Systems (6GS) will feature a broad range of heterogeneous devices and networks with an expected expansion of the supported verticals (e.g., mission critical) and thus need to be more trustworthy than 5G Systems. For example, devices and their interactions with wireless systems should be trustable by core network functions, application functions (in the cloud or at the edge), and other devices, referred to as trusted devices or trusted WTRUs, which are not supported in 5G. Existing security functions provided in 5G lack the support for assessing or enforcing the trustworthiness of a given WTRU. For instance, whether a device is trustable could be dynamic and timechanging, while existing 5G primary authentication or secondary authentication do not consider nor support such dynamic device trust.

[0003] Blockchain and distributed ledger technologies have been regarded as a promising enabler to make future 6G devices and systems trustworthy. As an example, a device and / or an authorized party could record the device behaviors and any necessary data to distributed ledgers, which is transparent to and accountable by other devices and network nodes and in turn enable decentralized trust. To this end, devices need to be able to access distributed ledgers via the 6GS for both reading data from and / or writing data to the distributed ledgers. Furthermore, data stored in distributed ledgers may need to be modified or removed if it turns out be outdated, misinformation, and / or impacting user privacy, which is possible using redactable distributed ledgers.

[0004] To leverage blockchain technologies for enabling future trustworthy system, the 6GS needs to integrate blockchain capabilities (e.g., as network functions) with 6GS as integral functions, referred to as native wireless blockchain. It is expected that native wireless blockchain will be a permissioned blockchain system such as ETSI PDL. For a device to efficiently interact with such a native wireless blockchain, the device first needs to be properly onboarded to the native blockchain and be provisioned with necessary configuration information for interacting with it, referred to as device onboarding to native wireless blockchain or wireless blockchain onboarding for simplicity.SUMMARY

[0005] In embodiments, a method implemented in a WTRU may include: receiving blockchain onboarding information from a first network function; generating a first blockchain address of the WTRU based on the onboarding information; preparing a first request for wireless blockchain onboarding; transmitting the first request to a first network function; receiving from the first network function a first response comprising a first information element; storing the first information element; and interacting with a native wireless blockchain based on the first information element. Additionally / alternatively, the blockchain onboarding information may include a function for generating the first blockchain address of the WTRU. Additionally / alterna

[0006] tively, the first blockchain address may be based on a security key derived by the WTRU. Additionally / alternatively, the WTRU may determine to log data to the native wireless blockchain. Additionally / alternatively, the WTRU may receive an instruction to log data to the native wireless blockchain. Additionally / alternatively, the first request for wireless blockchain onboarding may be transmitted via a control plane. Additionally / alternatively, the first request for wireless blockchain onboarding may be transmitted via a user plane. Additionally / alternatively, first request for wireless blockchain onboarding may include a blockchain node type of the WTRU. Additionally / alternatively, the first request for wireless blockchain onboarding may include a public key of the WTRU. Additionally / alternatively, the first request for wireless blockchain onboarding may include an indication of how the first blockchain address was generated.

[0007] In further embodiments, a WTRU may include: a processor and a transceiver, wherein the processor is configured to: cause the transceiver to receive blockchain onboarding information from a first network function; generate a first blockchain address of the WTRU based on the onboarding information; prepare a first request for wireless blockchain onboarding; cause the transceiver to transmit the first request to a first network function; cause the transceiver to receive from the first network function a first response comprising a first information element; store the first information element; and interact with a native wireless blockchain based on the first information element. Additionally / alternatively, the blockchain onboarding information may include a function for generating the first blockchain address of the WTRU. Additionally / alternatively, the first blockchain address may be based on a security key derived by the WTRU. Additionally / alternatively, the processor determines to log data to the native wireless blockchain. Additionally / alternatively, the processor may be further configured to cause the transceiver to receive an instruction to log data to the native wireless blockchain. Additionally / alternatively, the processor may be further configured to cause the transceiver to transmit the first request for wireless blockchain via a control plane. Additionally / alternatively, the processor may be further configured to cause the transceiver to transmit the first request for wireless blockchain via a user plane. Additionally / alternatively, the first request for wireless blockchain onboarding may include a blockchain node type of the WTRU. Additionally / alternatively, the first request for wireless blockchain onboarding may include a public key of the WTRU. Additionally / alternatively, the first request for wireless blockchain onboarding may include an indication of how the first blockchain address was generated.BRIEF DESCRIPTION OF THE DRAWINGS

[0008] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, wherein like reference numerals in the figures indicate like elements, and wherein:

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

[0010] 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;

[0011] FIG. 1C 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;

[0012] FIG. 1D 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;

[0013] FIG. 2 is an example diagram of native wireless blockchain system functions;

[0014] FIG. 3 is an example diagram of blockchain key material generation at a core network with BCGF;

[0015] FIG. 4 is an example diagram of blockchain key material generation at a WTRU with BCGF at a core network;

[0016] FIG. 5 is an example diagram of blockchain key material generation at a core network without BCGF;

[0017] FIG. 6 is an example diagram of blockchain key material generation at a WTRU without BCGF

[0018] FIG. 7 is an example flow diagram of BCGF requesting blockchain key derivation functions from the core network;

[0019] FIG. 8 is an example flow diagram of configuring blockchain key derivation functions to BCGF;

[0020] FIG. 9 is an example flow diagram of exchanging blockchain key functions between a WTRU and a core network via AMF;

[0021] FIG. 10 is an example flow diagram of exchanging blockchain key functions between a WTRU and a core network during PDU session establishment;

[0022] FIG. 11 is an example flow diagram of a UDM pushing blockchain specific parameters to a WTRU;

[0023] FIG. 12 is an example flow diagram of Initiation of wireless blockchain onboarding by BCGF;

[0024] FIG. 13 is an example flow diagram of device selection and notification for wireless blockchain onboarding by BCAF and through BCCF;

[0025] FIG. 14 is an example flow diagram of device selection and notification for wireless blockchain onboarding by BCAF and through BCGF;

[0026] FIG. 15 is an example flow diagram of Device-A as discoverer initiating wireless blockchain onboarding for Device-B as discoveree;

[0027] FIG. 16 is an example flow diagram of Device-B as discoveree Initiating wireless blockchain onboarding for Device-A as discoverer;

[0028] FIG. 17 is an example flow diagram of Device-A initiating wireless blockchain onboarding assisted by device-B;

[0029] FIG. 18 is an example block diagram of implementation of device selection and notification for wireless blockchain onboarding in 3GPP;

[0030] FIG. 19 is an example flow diagram of wireless blockchain onboarding initiation embedded in 3GPP registration;

[0031] FIG. 20 is an example flow diagram of wireless blockchain onboarding initiation using 3GPP registration accept to notify a WTRU of BCCF;

[0032] FIG. 21 is an example flow diagram of wireless blockchain onboarding initiation by AMF after 3GPP registration;

[0033] FIG. 22 is an example flow diagram of wireless blockchain onboarding initiation by 3GPP NWDAF;

[0034] FIG. 23 is an example flow diagram of wireless blockchain onboarding initiation by 3GPP AF;

[0035] FIG. 24 is an example flow diagram of wireless blockchain onboarding with BCGF for device blockchain address authentication;

[0036] FIG. 25 is an example flow diagram of wireless blockchain onboarding with blockchain address being generated by a network;

[0037] FIG. 26 is an example flow diagram of wireless blockchain onboarding with a random device blockchain address;

[0038] FIG. 27 is an example flow diagram of wireless blockchain onboarding for WTRU assisted by AUSF and AMF;

[0039] FIG. 28 is an example flow diagram of wireless blockchain onboarding for WTRU assisted by SEAF and AMF;

[0040] FIG. 29 is an example flow diagram of wireless blockchain onboarding with WTRU blockchain address being generated by AUSF; and

[0041] FIG. 30 is an example flow diagram of a procedure for provisioning BCEF.DETAILED DESCRIPTION

[0042] 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), singlecarrier FDMA (SC-FDMA), zero-tail unique-word discrete Fourier transform Spread OFDM (ZT-UW-DFT-S- OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0043] As shown in FIG. 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (ON) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though itwill 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 (STA), may be configured to transmit and / or receive wireless signals and may include a user equipment (WTRU), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a WTRU.

[0044] 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, 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 NodeB, an eNode B (eNB), a Home Node B, a Home eNode B, a next generation NodeB, such as a gNode B (gNB), a new radio (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.

[0045] The base station 114a may be part of the RAN 104, 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, and the like. 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 licensedand 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 multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

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

[0047] 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 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 116 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 Uplink (UL) Packet Access (HSUPA).

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

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

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

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

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

[0053] The RAN 104 may be in communication with the CN 106, 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 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. 1A, it will be appreciated that the RAN 104 and / or the CN 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may be utilizing a NR radio technology, the CN 106 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0054] The CN 106 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 or a different RAT.

[0055] 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 a cellularbased radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0056] 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 sub-combination of the foregoing elements while remaining consistent with an embodiment.

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

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

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

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

[0061] 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 light-emitting diode (OLED) display unit) The processor 118 may also output user datato 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).

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

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

[0064] 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, a humidity sensor and the like.

[0065] 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 DL (e.g., for reception) may be concurrent and / or simultaneous. The full duplex radio may include an interference management unit to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). In anembodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e g., for transmission) or the DL (e g., for reception)).

[0066] FIG. 1C 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 ON 106.

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

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

[0069] The CN 106 shown in FIG. 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. While 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.

[0070] 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 a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA

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

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

[0073] The CN 106 may facilitate communications with other networks For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that 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.

[0074] Although the WTRU is described in FIGS. 1A-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.

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

[0076] 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 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 to the 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.11e DLS or an 802.11z 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.

[0077] When using the 802.11 ac 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. 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 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.

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

[0079] 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 noncontiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, 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).

[0080] 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.11 af and 802.11ah relative to those used in 802.11n, 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 (MTC), 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).

[0081] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802 11 n, 802.11ac, 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, all available frequency bands may be considered busy even though a majority of the available frequency bands remains idle.

[0082] 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, theavailable 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.

[0083] FIG. 1 D is a system diagram illustrating the RAN 104 and the GN 106 according to an embodiment. As noted above, the RAN 104 may employ an NR 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.

[0084] The RAN 104 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 104 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).

[0085] 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. The WTRUs 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 a varying number of OFDM symbols and / or lasting varying lengths of absolute time).

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

[0087] 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, DC, 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. 1D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0088] The CN 106 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 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.

[0089] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 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 protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of non-access stratum (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 MTC access, and the like The AMF 182a, 182b may provide a control plane function for switching between the RAN 104 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.

[0090] The SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 106 via an N11 interface. The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 106 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 DL data notifications, and the like. A PDU session type may be IP-based, non-IP based, Ethernet-based, and the like.

[0091] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 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 DL packets, providing mobility anchoring, and the like.

[0092] The CN 106 may facilitate communications with other networks 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 In one embodiment, the WTRUs 102a, 102b, 102c may be connected to a local 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.

[0093] In view of FIGs. 1A-1 D, and the corresponding description of FIGs. 1A-1 D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device(s) described herein, 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.

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

[0095] 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 wireless communication 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.

[0096] The following acronyms as may be used herein:3GPP 3rd Generation Partnership Project5G 5th Generation5GC 5G Core Network5GS 5G System5G-GUTI 5G Globally Unique Temporary Identity6G 6th Generation6GC 6G Core Network6GS 6G SystemAddr AddressAF Application FunctionAMF Access and Mobility Management FunctionARPF Authentication Repository and Processing FunctionAUSF Authentication Server FunctionBC BlockchainBCAF Blockchain Application FunctionBCCCF Blockchain Client and Consumer FunctionBCCF Blockchain Control FunctionBCCGF Blockchain Control and Governance FunctionBCEF Blockchain Enabler FunctionBCGF Blockchain Governance FunctionBCN Blockchain Client NodeBCRF Blockchain Repository FunctionBCSF Blockchain Service FunctionBSN Blockchain Service NodeDN Data NetworkEAS Edge Application ServerETSI European Telecommunications Standards InstituteGR Group ReportGS Group SpecificationID IdentifierISG Industry Specification GroupLAF Ledger Anchor FunctionLMF Location Management FunctionNAS Non-Access StratumNEF Network Exposure FunctionNF Network FunctionNRF Network Repository FunctionNWDAF Network Data Analytics FunctionPCF Policy Control FunctionPDL Permissioned Distributed LedgerPDU Protocol Data UnitPLMN Public Land Mobile NetworkSA Service ArchitectureSEAF Security Anchor FunctionSIDF Subscription Identifier De-concealing FunctionSIM Subscriber Identity ModuleSUCI Subscription Concealed IdentifierSUPI Subscription Permanent IdentifierTLS T ransport Layer SecurityUDM Unified Data ManagementUDR Unified Data RepositoryUDSF Unstructured Data Storage FunctionWTRU Wireless Transmit / Receive UnitUICC Universal Integrated Circuit CardURSP WTRU Route Selection Policy

[0097] 5G system architecture consists of Wireless Transmit / Receive Units (WTRUs), Radio Access Network (RAN), and Core Network. One of the design principles for the 5G System (5GS) is that it is servicecentric or service-based. A 5G Core Network (5GC) contains a variety of network functions, which work together to fulfill and provide needed services to the RAN, WTRUs, and Application Servers / Service Providers. A network function can access other network functions in request / response mode or subscription / notification mode. Before two network functions 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, Access and Mobility Management Function (AMF) is dedicated to managing WTRUs’ access to 5GS and its mobility, Session Management Function (SMF) is responsible for establishing sessions between a WTRU and 5GC, and Authentication Server Function (AUSF) takes charge of WTRU authentication. In addition, Policy Control Function (PCF) provides policy rules for other control plane network functions and of WTRUs; PCF assigns an identifier for each created policy rule, which other control plane network functions and of WTRUs use to refer to the corresponding policy rule. User Plane Function (UPF) is the only core network function in the data plane that facilitates monitoring, managing, controlling, and redirecting user plane traffic flows such asbetween a of WTRU and an Application Function (AF). 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. 5GC also provides data storage and analytics services through functions like Unified Data Management (UDM), Unified Data Repository (UDR), Unstructured Data Storage Function (UDSF) and Network Data Analytics Function (NWDAF). Another critical feature of 5GS is network slicing, which is facilitated by Network Slice Selection Function (NSSF). Although these network functions are defined as separate logical entities, a particular service scenario may require multiple network functions; for instance, of WTRU mobility will need not only AMF, but also AUSF and SMF. For a type of network function, multiple instances could be instantiated and NRF will maintain the information of each instantiated network function instance. With the emergence of edge computing, some network functions in 5GC such as UPF and NEF could be deployed and resided in an edge network that is much nearer to and potentially co-located with the RAN. 5GS introduces a few network functions such as Location Management Function (LMF) to support location services. 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 LMF calculates the location of a target of WTRU, other entities can access or query its location from LMF but need to go through a serving AMF.

[0098] A blockchain system is described herein. A blockchain system consists of two general types of blockchain nodes: Full Blockchain Node - A full blockchain node has all blockchain functions (e.g., host and maintain ledgers, participate in consensus protocols to generate new blocks, and validate received blocks); and Light Blockchain Node - A light blockchain node acts as a blockchain client node such as digital wallets that sends transactions to the blockchain system via one or multiple full blockchain nodes.

[0099] Full blockchain nodes connect to each other via a peer-to-peer network; any new transaction or block will be propagated within the peer-to-peer network according to certain routing protocols (e.g., gossipbased routing) so that each full blockchain node will have the same copy of all unprocessed or uncommitted transactions (e.g., unspent transactions) and all blocks containing committed transactions (e.g., spent transactions). A blockchain client node has a unique blockchain address as its identifier that is usually generated by the blockchain client node itself, for example, based on cryptography and hashing techniques. For example, a blockchain client node may have a pair of a private key and a public key; the public key can be used to generate its blockchain address, while the private key can be used to sign any transaction that the blockchain client node will send to the blockchain system.

[0100] Although a blockchain ledger is usually append-only and immutable due to the use of hash-based chain structure to link blocks together, there are some techniques to enable mutable or redactable blockchain, where a committed block could be modified or even removed without breaking the hash-based chain structure. Most of those techniques rely on one or multiple security keys, referred to as blockchain redaction keys, to enable hash collisions so that any party with the access to blockchain redaction keys can redact or modifyexisting blocks while maintaining the hash-based ledger structure due to the leveraging of hash collisions. Blockchain redaction keys could be generated or provisioned when the blockchain system is initiated.

[0101] A full blockchain node is referred to herein as Blockchain Service Node (BSN), while a light blockchain node is referred to as Blockchain Client Node (BCN). In embodiments a device or a WTRU may be a BCN (if it only uses blockchain ledgers as a client) or a BSN (if it maintains blockchain ledgers and supports full blockchain functions). Since BCN and BSN are logical entities, a physical device or WTRU may host one or multiple instances of BCN and / or BSN if the physical device has sufficient resources to support

[0102] In embodiments, a blockchain system may be: 1) 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 2) 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.

[0103] Blockchain Key Material Generation for Native Wireless Blockchain is discussed herein. To interact with native wireless blockchain, a device needs to obtain the proper authorization to access the blockchain (e g., permissioned blockchain system) and support the appropriate cryptography (e g., generate a blockchain address, sign transactions, etc.), which relies on security keys. Since native wireless blockchain is native (i.e., fully integrated into the wireless systems such as 5GS, 6GS, etc.), it is viable to consider and leverage existing key materials (e.g., KAUSF, KSEAF) in 5GS to generate those blockchain security keys. Blockchain security key and blockchain key are two terms interchangeably used in this disclosure. The issue is to how to leverage 5G key materials to generate blockchain security keys which are needed for native wireless blockchain. Procedures that leverage 5G key materials to generate blockchain security keys may, for example, make use of the security keys, or credentials, that are already provisioned in the WTRU (e.g., in the Subscriber Identity Module (SIM) card) and therefore avoid the need to provision new key material, or credentials, to support blockchain access.

[0104] Device Selection and Notification for Wireless Blockchain Onboarding are discussed herein. For onboarding a device to native wireless blockchain, a device needs to be selected and notified, although the device itself may actively start wireless blockchain onboarding for some cases. The issue is which devices to be selected for wireless blockchain onboarding and how to efficiently notify the selected devices. 5GC does not have native wireless blockchain capability and existing network functions in 5GC do not include a method to initiate wireless blockchain onboarding. An onboarding procedure is needed to send the device information about the blockchain capabilities of the network and information about how the device may contact the blockchain system. Without such a procedure, the device would not be able to establish contact with the blockchain system, or services, without being pre-configured with the information. In some scenarios preconfiguration of the data is not possible because the necessary data is not known at a time when preconfiguration is possible.

[0105] Wireless Blockchain Onboarding is discussed herein. To onboard a device to native wireless blockchain, the device blockchain address needs to be authenticated and the device needs to be provisioned with some blockchain configuration information (e.g., the address of blockchain service nodes that the device can send transactions to, the constraints (e.g., transaction templates, allowed maximum transactions within a time period) on generating on-chain transactions). A device needs one or multiple blockchain addresses in order to interact with one or multiple native wireless blockchains. Since native wireless blockchain likely will be a permissioned blockchain system such as ETSI PDL, device blockchain addresses need to be authenticated, permissioned and managed. The issue of device blockchain address authentication has at least these two aspects: 1) efficient generation and authentication of a device blockchain address in the context of native wireless blockchain; 2) deciding blockchain configuration information for a device with an authenticated blockchain address. Existing primary authentication and secondary authentication in 5GS do not support blockchain address authentication.

[0106] The following terms may be used herein

[0107] Device: a WTRU WTRU and WTRU may be interchangeably used in this disclosure unless there is an explicit clarification.

[0108] Network Function: A processing function in a network (e.g., 5GC).

[0109] Trusted Device: refers to a device or WTRU which can be trusted by future cellular wireless system such as 6GS. Trusted Device and Trusted WTRU are used interchangeably in this disclosure unless there is an explicit clarification.

[0110] Blockchain Client Node (BCN): It is a light blockchain node which only interacts with blockchain service nodes to send transactions to or retrieve transactions / blocks from. An example of blockchain client node is digital wallet. A blockchain application function within network is another example of BCN. Blockchain client node and blockchain client are interchangeable in this disclosure unless there is an explicit clarification. A BCN may have a BCAF such as a BCCCF. A BCN may have multiple BCAFs or BCCCFs.

[0111] Blockchain Service Node (BSN): It is a full blockchain node which implements all functions of blockchain technology (e g., maintain a blockchain ledger, participate in consensus protocols). A BSN may have a BCSF. A BSN may have multiple BSNs.

[0112] Blockchain Control Function (BCCF): A logical entity or a network function acting as the entry point for devices or applications to interaction with native wireless blockchain for control plane purposes such as managing BCNs and BSNs.

[0113] Blockchain Service Function (BCSF): A logical entity or a network function acting as the entry point for devices or applications to interaction with native wireless blockchain for data plane purposes such as creating / sending new transactions. BCSF may be a part of a BSN.

[0114] Blockchain Governance Function (BCGF): A logical entity or a network function acting for coordinating, governing, and managing the whole native wireless blockchain. BCGF may interact with BCCF, BCSF, and optionally other application functions or network functions (e.g, a system management application).

[0115] Blockchain Application Function (BCAF): A logical entity or an application function which can act as a BCN to interact with BSNs (e.g., BCSFs) for generating and retrieving transactions. A BCAF may also only interact with other blockchain functions (BCCF, BCGF and BCSF) for controlling and managing the native wireless blockchain, but not necessarily generate any transaction to a blockchain ledger. A BCAF may need to have a blockchain address.

[0116] Blockchain Client and Consumer Function (BCCCF): A BCAF on a BCN node. A BCCCF may also reside in the network or a part of a BSN; when a BSN has a BCCCF, this BCCCF may only be used by the BSN to perform transactions-based management purposes (e.g., the BSN may need to record its behaviors to blockchain ledgers); in this case, the BCCCF on the BSN can generate new transactions and send them to another BSN. A BCCCF may need to have a blockchain address, which may be assigned or authorized by BCCF / BCGF; after that, a BCCCF may use its authorized blockchain address to consumer the services provided by a BCSN.

[0117] Identifier: The name / identifier / address of an entity (e.g., a device / WTRU, a network function such as 3GPP NFs and BCCCF, BCCF, BCSF, BCGF, BCCGF, etc.). 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 enables or gives access details based on which other entities can access and interact with this entity.

[0118] Blockchain Address: The address or identifier that uniquely identifies a blockchain entity (BCN, BSN, BCAF, BCSF, or other blockchain function) within a blockchain system. A blockchain address could be a sender or a recipient of a blockchain transaction A blockchain service node also could have a blockchain address which can be used for sending special transactions (e.g., transactions for managing the corresponding blockchain system). A blockchain application function may have a blockchain address. If a BCCF (or a BCGF) needs to send a transaction to blockchain ledger (e.g, for a management purpose, to record its behavior data to blockchain ledger), the BCCF (or the BCGF) can have a blockchain address or have an embedded BCN or BCAF.

[0119] Blockchain Address Signature: A blockchain address in a permissioned blockchain system may need to be authenticated and authorized. Before a blockchain address is authorized, it may only consist of a raw blockchain address, which usually is generated based on a public key. After a blockchain address is authorized by an authorizing party (e.g, by a BCGF, a BCCF, and / or an AUSF), it becomes an authorized blockchain address, which may consist of two parts: the raw blockchain address and a blockchain address signature; the blockchain address signature may be generated by the authorizing party using a private key.Any party (e.g., devices, BCSFs, BCCF) knowing the corresponding public key (associate with the private key for generating the blockchain address signature) can validate the blockchain address signature.

[0120] Device Blockchain Address: The blockchain address for a device in a blockchain system.

[0121] Blockchain Ledger: A ledger storing transactions and blocks and related system status in a hash- connected chained structure. Each full blockchain node needs to maintain a blockchain ledger. Blockchain ledger, distributed ledger, and ledger are interchangeably used in this disclosure unless there is an explicit clarification

[0122] Blockchain Technology: A set of technologies used in a blockchain system such as consensus protocols, transaction generation and validation, block generation and validation, blockchain ledgers, etc. In this disclosure, blockchain technology and distributed ledger technology are interchangeably used unless there is an explicit clarification.

[0123] Blockchain System: The system implementing or using blockchain technology. In this disclosure, blockchain system is equivalent to distributed ledger system unless there is an explicit clarification. A blockchain system usually consists of many light blockchain nodes and a group of full blockchain nodes.

[0124] Native Wireless Blockchain: A blockchain system integrated with and implemented as an integral part of future cellular wireless system such as 6GS. Native wireless blockchain has a set of blockchain-related functions such as, but not limited to, BCCCF, BCCF, BCGF, BCSF, and BCAF; those blockchain-related functions can be deployed in core network, edge networks, and even co-located with some powerful devices.

[0125] Transaction: A message that is usually sent from a sender (e.g., BCN-A, a BSN) and a recipient (e g., BCN-B, a BSN). The message may contain some information (e.g., digital currency, data, token) exchanged from the sender to the recipient.

[0126] Block: A data structure that may contain a block header and a block body. The block body may contain a set of transactions. A block is usually generated by a BSN as a result of executing a blockchain consensus protocol.

[0127] Wireless Blockchain Onboarding: A process to onboard devices to a native wireless blockchain (e.g., generate blockchain security keys for devices, initiate wireless blockchain onboarding, authenticate device blockchain address, provision devices with blockchain redaction capability, publish device public information to native wireless blockchain).

[0128] Permissioned Blockchain System: A blockchain system where the access to blockchain ledger (e.g., write data to blockchain ledger, read data from blockchain ledger, update / remove data in blockchain ledger) is only available to permissioned or authorized parties, which usually are governed by a BCGF.

[0129] Native Wireless Blockchain System Functions are described herein FIG. 2 illustrates an example native wireless blockchain system and its functions in the context of a 3GPP system. A blockchain ledger is shown as 250, 252 and 254. WTRUs may be a light blockchain node (shown e g., WTRU-1 220) hosting a BCAF or a full blockchain node (shown e.g., WTRU-2222) hosting a BCSN. In blockchain control plane, thoseblockchain-related functions (i.e., BCCCF 220, BCCF 224, BCGF 232, BCSF 222, 226,2 36, 240, and BCAF 242) may interact to perform tasks related to but not limited to provisioning and managing the native wireless blockchain system. For example, BCGF 232 may coordinate blockchain security key derivation and distribute the derived blockchain security keys to BCCF 230 and BCSF 240. In embodiments, BCGF 232 may need to interact with AUSF or be implemented as a part of AUSF to derive blockchain security key based on existing 3GPP key materials. 3GPP network functions 228 and 234 are shown in this example. m

[0130] In the example system of FIG. 2. first WTRU, WTRU-1 220 may be a BCCCF. A second WTRU, WTRU-2, 222, MAY be a BCSF. A BCCF 224 may map to LAF in 5G systems. For example, a BCCF 230 in a core network may map to a centralized LAF; a BCCF 230 in RAN / Edge may map to distributed LAF A BCGF 232 may map to BCRF. Alternatively, BCGF may be implemented as a new network function BCCCF may map to BCEF within WTRU. A BCSF 226 may map to BCEF with afull blockchain node. In further embodiments, a BCCF 224 may map to distributed LAF. In embodiments a BCGF 232 may map to centralized LAF. Alternatively, a BCGF 232 may be implemented as a new network function. A BCCCF 220 may map to BCEF within WTRU. A BCSF (226, 236, 240) may map to BCEF with a full blockchain node.

[0131] BCGF and BCCF may determine and select WTRUs, which need to be onboarded to the native wireless blockchain system. BCAF can also trigger BCGF to select WTRUs for wireless blockchain onboarding as described further herein below.

[0132] In embodiments, when a WTRU starts to onboard to the native wireless blockchain system, it may only interact with BCCF, which is the entry point for the WTRU. BCCF may be implemented as a part of AMF or a standalone NF in 3GPP core network. During the wireless onboarding process, BCCF will check with BCGF to determine if the WTRU is authorized to be onboarded. For this purpose, BCGF may need to interact with 3GPP NFs (e.g., UDM) to retrieve the WTRU’s subscription data as described further herein below.

[0133] In blockchain user plane, BCCCF, BCAF, and / or 3GPP NFs may send transactions to blockchain ledgers via a BCSF or retrieve transactions from blockchain ledgers via a BCSF. Transactions and blocks will be propagated and exchanged among BCSFs, for example, via underlying peer-to-peer network, which connects all BCSFs. Each BCSF may interface to a blockchain ledger directly. Blockchain ledgers could be deployed at a powerful WTRU, in a Data Network (DN) at the edge, and / or in a DN in the cloud.

[0134] A 3GPP Network (e.g., a Public Land Mobile Network (PLMN), a Non-Public Network (NPN)) as identified by 3GPP-NWK-ID may deploy and operate multiple native wireless blockchains. 3GPP-NWK-ID could be a PLMN-ID. The same set of physical blockchain nodes and physical network nodes / links may be leveraged by the 3GPP network to create multiple virtual native wireless blockchains. Each native wireless blockchain may be deployed in different locations, may be used to support different WTRUs and / or applications, and / or may provide different services. A native wireless blockchain may be identified and assigned by the 3GPP network with an identifier or a name (Native-BC-ID), which may be unique within the 3GPP Network or globally unique

[0135] Native-BC-ID may consist of the information related to: 3GPP-NWK-ID: The identifier of the 3GPP Network, which may be a PLMN-ID; Context-ID: The hashed value of the context information of the native wireless blockchain (e.g., the location where the native wireless blockchain is deployed); Consensus-Protocol- Type: The type of consensus protocol used in the native wireless blockchain; and Unique-BC-Seq: A sequence number or a name that identifies the native wireless blockchain uniquely within the 3GPP Network.

[0136] Blockchain Key Material Generation for Native Wireless Blockchain is discussed herein.

[0137] The following blockchain security keys or blockchain key material embodiments are described, which may be independently generated at both WTRU and core network without being exchanged between WTRU and core network:

[0138] KBCGF is the primary security key for native wireless blockchain All other blockchain security keys may be derived based on KBCGF. KBCGF can be derived from existing 5G key material (e.g., KSEAF, KAUSF, or KAMF). In core network, KBCGF is maintained and used by Blockchain Governance Function (BCGF), which governs the whole native wireless blockchain such as authenticating blockchain client nodes and blockchain service nodes. BCGF is responsible for deriving other blockchain security keys from KBCGF; KBCGF may be used as a blockchain anchor key, based on which all other blockchain security key will be derived; if native wireless blockchain does not have BCGF, KBCGF will not be needed and other blockchain security keys may be derived directly from existing 5G key material (e.g., KSEAF, KAUSF, or KAMF).

[0139] KBCCF is maintained and used by WTRU and Blockchain Control Function (BCCF). BCCF is the entry point for control plane functions of native wireless blockchain (e.g., onboarding devices to native wireless blockchain) In embodiments, KBCCF may be derived from KBCGF or existing 5G key material (e.g., KSEAF, KAUSF, or K MF). KBCCF may be used for providing security for control plane function of native wireless blockchain; for example, one symmetry key for encryption and / or another symmetry key for integrity protection could be derived from KBCCF. In other words, KBCCF is the primary key between a WTRU and a BCCF, based on which multiple other keys could be derived and used for interactions between the WTRU and the BCCF. As another example, a WTRU and a BCCF may derive one-time pad from KBCCF each time when they need to interact (e g., an one-time pad is a function of KBCCF and addition information such as the time when both parties interact or a random number both parties know). In another example, a WTRU and a BCCF may simply use KBCCF as an encryption / decryption key to securely exchange other security keys or information.

[0140] KBCSF is maintained by WTRU and Blockchain Service Function (BCSF). BCSF is the logical entity for data plane functions of native wireless blockchain (e.g., send transactions to native wireless blockchain). KBCSF may be derived from KBCGF or existing 5G key material (e.g., KSEAF, KAUSF, or KA F). Note that subscripted terms [e.g. KSEAF] may appear without subscripts [e.g. KSEAF], interchangeably throughout this document. KBCSF may be used for providing security for data plane function of native wireless blockchain; for example, one symmetry key for encryption and / or another symmetry key for integrity protection could be derived from KBCSF. KBCSF is the primary key between a WTRU and a BCSF, based on which multiple other keys could be derivedand used for interactions between the WTRU and the BCSF. As another example, a WTRU and a BCSF may derive one-time pads from KBCSF each time when they need to interact (e g., an one-time pad is a function of KBCSF and addition information such as the time when both parties interact or a random number both parties know). In another example, a WTRU and a BCSF may simply use KBCSF as an encryption / decryption key to securely exchange other security keys or information.

[0141] KBCRD is maintained by WTRU and Blockchain Control Function (BCCF). KBCRD will be used for Blockchain Redaction (BCRD). KBCRD could be derived from KBccpor existing 5G key material (e.g., KSEAF, KAUSF, or KAMF). Alternatively, KBCRD also may be maintained by BCGF, BCSF, and other NFs that coordinate blockchain redaction.

[0142] In further embodiments, a flatter blockchain security key hierarchy may be used as described below.

[0143] BC-Key-Derivation #1: A blockchain anchor key (KBCA) may be derived from existing 5G key material (e g., KSEAF, KAUSF, or KAME) for a WTRU which is authorized for using the native wireless blockchain; KBCA may be the same as KBCGF and stored at BCGF and a WTRU. KBCA may be the same as KSEAF or KAUSF

[0144] BC-Key-Derivation #2: One or multiple other blockchain security keys for protecting integrity and confidentiality of blockchain user plane operations (e.g., read / write data to / from blockchain ledger) may be derived from KBCA for a WTRU which is authorized for using the native wireless blockchain.

[0145] Secure interactions on blockchain control plane including interactions with 3GPP NFs may reuse existing 3GPP security mechanisms (e.g., network access security via Non-Access Stratum (NAS) signaling, Transport Layer Security (TLS), etc.J.The derived blockchain security keys including KBCA may be done on a per native wireless blockchain system. For example, different native wireless blockchain systems may be used for different services such as NPN and PLMN. Such necessary derivation operations (i.e., BC-Key-Derivation #1 and BC-Key-Derivation #2) may be done at a WTRU side and its Home PLMN (HPLMN) side. As a result, two sets of derived blockchain security keys may be stored, respectively, at the WTRU and at the BCGF (or AUSF / SEAF). A third party (e.g., an AF) may provide blockchain key derivation services to derive blockchain security keys (e.g., BC-Key-Derivation #2) and securely share the derived blockchain security keys with a Visited PLMN (VPLMN), so that it is not necessarily involving the VPLMN in blockchain security key derivation

[0146] Blockchain Key Material Generation with BCGF is described herein. When a native wireless blockchain and / or 3GPP system has a BCGF, the BCGF may be responsible for generating blockchain key material within the core network using some blockchain key derivation functions, by leveraging existing 5G key material (See FIGS). Independently, a WTRU may derive blockchain key material using the same blockchain key derivation functions (See FIG. 4), so that the blockchain key material generated by the WTRU will be equal to the blockchain key material generated by the BCGF for the WTRU. This procedure may be enabled by the fact that the WTRU is provisioned with keys in the SIM card and the core network is also provisioned with the same keys.

[0147] Blockchain Key Material Generation at Core Network with BCGF is described herein As illustrated in FIG. 3, blockchain key material generation at core network is mainly handled by BCGF. First, at 310 a network function such as Security Anchor Function (SEAF) receives KSEAF and ad 312 derives KBCGF using a function FBCGF and shares it at 314 with BCGF; then, at 321 , 323 and 325 BCGF derives other blockchain security keys based on KBCGF; then at 322, 324 an 326, BCGF shares derived blockchain security keys with other blockchain- related network functions such as BCCF and BCSF, which are shown receiving the security keys at 340 and 342, respectively. In addition to KSEAF, the input to FBCGF may include Native-BC-ID, the identifier of the target native wireless blockchain that the WTRU will be interacting with.

[0148] FIG. 4 illustrates an example process to generate blockchain key material at a WTRU assuming core network has BCGF. A WTRU may perform the following operations, forexample, when a WTRU completes primary authentication and is registered to the core network, when the WTRU receives wireless onboarding instructions for a network function (e.g., BCCF, AMF). At 410 the WTRU derives KSEAF from KAUSF; If blockchain key derivation functions have not been standardized, the WTRU may send a request to the core network (e.g., BCGF, BCCF, and / or AMF) to retrieve at 412 the same blockchain key derivation functions (i.e., FBCGF, FBCCF, FBCRD, and FBCSF). Alternatively, core network (e.g., BCGF, BCCF, and / or AMF) could configure or install the same blockchain key derivation functions to the WTRU during or after the WTRU is registered with core network; At 414, the WTRU derives KBCGF from KSEAF according to the blockchain key derivation function FBCGF, KBCGF = FBCGF(KSEAF). In addition to KSEAF, the input to FBCGF may include Native-BC-ID, the identifier of the target native wireless blockchain that the WTRU will be interacting with Alternatively, the WTRU may derive KBCGF directly from KAUSF, KA F, or other 5G key material. At 420, the WTRU derives KBCCF from KBCGF according to the blockchain key derivation function FBCCF, KBCCF = FBCCF(KBCGF). At 422, the WTRU derives KBCRD from KBCGF according to the blockchain key derivation function FBCRD, KBCRD = FBCRD(KBCGF). At 424, the WTRU derives KBCSF from KBCGF according to the blockchain key derivation function FBCSF, KBCSF - FBCSF(KBCGF).

[0149] In an example embodiment, a WTRU may use KBCCF (or KBCGF) to furthermore derive a blockchain private key (WTRU-BC-Private-Key); then, the WTRU may derive or determine a blockchain public key (WTRU- BC-Public-Key) from WTRU-BC-Private-Key; at the last, the WTRU may generate its raw blockchain address based on WTRU-BC-Public-Key according to a blockchain address generation function as defined by a blockchain address scheme (BC-Addr-Scheme), which the WTRU may retrieve from the core network or the core network may assign to the WTRU. If the WTRU needs to generate multiple blockchain addresses (WTRU- BC-Addr), the WTRU could derive multiple WTRU-BC-Private-Keys from KBCCF (or KBCGF), which will lead to multiple WTRU-BC-Public-Keys (i.e., one WTRU-BC-Private-Key for one WTRU-BC-Public-Key) and multiple blockchain addresses (e.g., one WTRU-BC-Public-Key for one WTRU-BC-Addr) lf KBCGF at the core network was derived based on another 5G security key Kx (e.g., KAUSF, KAMF or other 5G key material) instead of KSEAF, KBCGF at the WTRU will be derived using the method in Figure 3, however, using the same Kx as well.

[0150] Blockchain Key Material Generation without BCGF is described herein. When a native wireless blockchain does not has a BCGF, an existing 5G network function (e.g., SEAF, AUSF, or AMF) may beresponsible for generating blockchain key material using some blockchain key derivation functions, by leveraging existing 5G System key material (See FIG. 5). Independently, a WTRU may derive blockchain key material using the same blockchain key derivation functions (See FIG. 6), so that the blockchain key material generated by the WTRU will be equal to the blockchain key material generated by the 5G network function. This procedure may be enabled by the fact that the WTRU is provisioned with keys in the SIM card and the core network is also provisioned with the same keys.

[0151] Blockchain Key Material Generation at Core Network without BCGF is described herein. As illustrated in FIG. 5, blockchain key material generation at the core network is mainly handled by SEAF. First, SEAF derives KBCCF, KBCSF, and KBCRD based on KSEAF; then it may share KBCCF and KBCRD with BCCF; it may also share KBCSF and KBCRD with BCSF. Alternatively, BCCF may share KBCRD with BCSF.

[0152] The example process illustrated in FIG 5 for generating blockchain key material in core network without BCGF consists of the following operations at SEAF, BCCF, and BCSF, respectively. In embodiments, SEAF may perform the following operations to derive KBCCF for BCCF: At 510 the SEAF receives KSEAF from AUSF. At 511 , the SEAF derives KBCCF from KSEAF according to a blockchain key derivation function FBCCF, KBCCF = FBCCF(KSEAF). In addition to KSEAF, the input to FBCCF may include Native-BC-ID, the identifier of the target native wireless blockchain that the WTRU will be interacting with. The function FBCCF may be a standardized function (e.g., a hashing function). Alternatively, FBCCF may be configured differently for different WTRUs or different groups of WTRUs as a part of WTRU subscription data; in this case, SEAF may retrieve FBCCF from WTRU subscription data stored at UDM in order to derive KBCCF according to KBCCF = FBCCF(KSEAF). At 512, the SEAF sends KBCCF to BCCF. Alternatively, BCCF may request KBCCF from SEAF; after receiving the request from BCCF, SEAF derives KBCCF and send it back to BCCF. At 520, the BCCF receives KBCCF

[0153] In embodiments SEAF may perform the following operations to derive KBC D for BCCF and optionally for BCSF as well. At 513, the SEAF derives KBCRD from KSEAF according to a blockchain key derivation function FBCRD, KBCRD = FBCRD(KSEAF). In addition to KSEAF, the input to FBCRD may include Native-BC-ID, the identifier of the target native wireless blockchain that the WTRU will be interacting with. The function FBCRD may be a standardized function (e.g., a hashing function). Alternatively, FBCRD may be configured differently for different WTRUs or different groups of WTRUs as a part of WTRU subscription data; in this case, SEAF may retrieve FBCRD from WTRU subscription data stored at UDM in order to derive K= according to KBCRD = FBCRD(KSEAF); At 514, the SEAF sends KBCRD to BCCF. Alternatively, BCCF may request KBCRD from SEAF; after receiving the request from BCCF, SEAF derives KBCRD and send it back to BCCF; and optionally, at 514 sends KBCRD to BCSF, which receives KBCRD at 522. Alternatively, BCSF may request KBCRD from SEAF; after receiving the request from BCSF, SEAF derives KBCRD and send it back to BCSF.

[0154] In embodiments, SEAF may perform the following operations to derive KBCSF for BCSF: at 515, the SEAF derives KBCSF from KSEAF according to a blockchain key derivation function FBCSF, KBCSF = FBCSF(KSEAF). In addition to KSEAF, the input to FBCSF may include Native-BC-ID, the identifier of the target native wireless blockchain that the WTRU will be interacting with. The function FBCSF may be a standardized function (e.g., ahashing function). Alternatively, FBCSF may be configured differently for different WTRUs or different groups of WTRUs as a part of WTRU subscription data; in this case, SEAF may retrieve FBCSF from WTRU subscription data stored at UDM in order to derive KBCSF according to KBCSF = F=(KSEAF) At 516, the SEAF may send KBCSF to BCSF, which receives KBCSF at 522. Alternatively, BCSF may request KBCSF from SEAF; after receiving the request from BCSF, SEAF may derive KBCSF and send it back to BCSF.

[0155] In embodiments, the BCCF may perform similar operations as shown being performed by the BCGF in FIG. 3 with the difference that the BCCF may receive K= and KBCRD from SEAF directly In embodiments, the BCSF may perform similar operations as shown being performed by the BCGF in FIG. 3 with the difference that the BCSF may receive KBCSF and KBCRD from SEAF directly.

[0156] In further embodiments, alternative to those shown by FIG. 5, another network function NFx(e.g., AUSF, AMF) that owns key Kxmay replace SEAF, but perform the same operations as SEAF does to derive KBCCF, KBCRD, and KBCSF, directly from Kx.

[0157] Embodiments for Blockchain Key Material Generation at a WTRU without BCGF at a Core Network are described herein, with reference to FIG. 6. At 610, the WTRU may derive KSEAF from KAUSF. In cases where blockchain key derivation functions have not been standardized, the WTRU may send a request to core network (e g., BCCF, AMF) to retrieve the same blockchain key derivation functions (i.e., FBCCF, FBCRD, and FBCSF). Alternatively, the core network (e.g., BCCF, AMF) may configure or install the same blockchain key derivation functions to the WTRU during or after the WTRU is registered with the core network; At 612 a WTRU may receive blockchain key derivation functions from the core network (e.g., BCCF, AMF, or SEAF). Then, using those blockchain key derivation functions, at 620, 622 and 624, as described below, the WTRU may derive blockchain security keys (e.g., KBCCF, KBCSF, and KBCRD) based on existing 5G key material (e.g., KSEAF). The WTRU will not exchange any blockchain security key with the core network. In embodiments, such blockchain key material generation may be done by a BCCCF at the WTRU.

[0158] At 620, the WTRU may derive KBCCF from KSEAF according to the blockchain key derivation function FBCCF, KBCCF = FBCCF(KSEAF). In addition to KSEAF, the input to FBCCF may include Native-BC-ID, the identifier of the target native wireless blockchain that the WTRU will be interacting with. At 622, the WTRU may derive KBCRD from KSEAF according to the blockchain key derivation function FBCRD, KBC D = FBCRD(KSEAF). In addition to KSEAF, the input to FBCRD may include Native-BC-ID, the identifier of the target native wireless blockchain that the WTRU will be interacting with. At 624, the WTRU may derive KBCSF from KSEAF according to the blockchain key derivation function FBCSF, KBCSF = FBCSF(KSEAF). In addition to KSEAF, the input to FBCSF may include Native- BC-ID, the identifier of the target native wireless blockchain that the WTRU will be interacting with. If KBCCF, KBCRD, and KBCSF at the core network are derived from another security Kx(e.g., KAUSF, KAME or other 5G key material) instead of KSEAF, blockchain security key (e.g., KBCCF, KBCRD, and KBCSF) at the WTRU may be derived using the method FIG. 6, however, using the same Kx as well.

[0159] Embodiments for Configuration of Blockchain Key Derivation Functions are described herein. 6GS may configure or designate different blockchain key derivation functions (e.g., FBCGF, FBCCF, FBCSF, FBCRD) for different native wireless blockchains. Different WTRUs within 6GS and / or within a native wireless blockchain may be configured or designated with different blockchain key derivation functions (e.g , FBCGF, FBCCF, FBCSF, FBCRD). The same set of blockchain key derivation functions could be applied to a group of WTRUs. Those blockchain key derivation functions may be stored as a part of WTRU subscription data at a UDM / ARPF (Authentication Repository and Processing Function). Those functions may be exchanged between two network functions (e.g., between BCGF and UDM / ARPF); they may also be exchanged between the WTRU and network function. Each blockchain key derivation function may describe or specify its input parameters, which may include Native-BC-ID

[0160] Embodiments for Network-Side Configuration of Blockchain Key Derivation Functions are described herein. FIG 7 illustrates an example procedure where a BCGF (or other network functions such as a BCCF and an AMF) may request one or multiple blockchain key derivation function from a UDM / ARPF. At 720 the BCGF 710 may send a request to the 714 UDM / ARPF to obtain blockchain key derivation functions that can be applicable to one or multiple WTRUs for a target native wireless blockchain In embodiments, this request may contain the following parameters: Native-BC-ID: The identifier of the target native wireless blockchain If this parameter is not included, UDM / ARPF may indicate to the BCGF the identifier of the target native wireless blockchain. WTRU-ID: The identifier of a WTRU (e.g., SUCI, 5G-GUTI, SUPI). This parameter is optional if blockchain key derivation functions are applicable in the same way for all WTRUs or the BCGF does not have WTRU-ID. If the corresponding WTRU currently has a blockchain address and the BCGF know it, WTRU-ID may also indicate the blockchain address of the WTRU BCGF-ID: The identifier of the BCGF. BC-Key-Derv- Func-Names: Indicates the name of blockchain key derivation functions being requested. It could be FBCGF, FBCCF, FBCSF, and / or FBCRD. This parameter may also indicate other key derivation functions, which can be used to derive other blockchain keys from KBCGF, KBCCF, KBCSF, and / or KBCRD. This parameter may indicate “ALL” and / or “ANY”, which mean to request all and / or any available blockchain key derivation functions.

[0161] In embodiments, the request sent at 720 may be triggered by another network function. For example, when a WTRU registers to the core network the first time, the WTRU’s serving AMF may send a message to the BCGF to trigger the BCGF to initiate step 1, once 3GPP primary authentication for the WTRU is successful; this message from the serving AMF to the BCGF 710 may indicate WTUR-ID, the identifier of AUSF or UDM / ARPF and the purpose of this message (i.e., to request blockchain key derivation functions for the WTRU).

[0162] The request at 720 may first be sent to an AUSF 712, which may then retrieve blockchain key derivation functions from the UDM / ARPF for the BCGF. The UDM / ARPF 714 for the BCGF may be a UDM / ARPF that is deployed by the same network (i.e., PLMN) that deploys the BCGF

[0163] The request at 720 may first be sent to an NRF, which may then determine the blockchain key derivation functions based on information that the NRF receives from a PCF (or a UDM) that serves the WTRU.

[0164] At 722 the UDM / ARPF 714 may receive the request and process it. If the request contains WTRU- ID and it is a SUCI, UDM / ARPF may first use Subscription Identifier De-Concealing Function (SIDF) to translate the SUCI to its corresponding Subscription Permanent Identifier (SUPI). Then, the UDM / ARPF uses the SUPI to find and determine the appropriate blockchain key derivation functions for the WTRU as denoted by WTRU- ID, assuming those functions have been stored in the WTRU’s subscription data. The UDM / ARPF may also use other formats of WTRU-IF (e.g., SUCI) the SUPI to find and determine the appropriate blockchain key derivation functions for the WTRU. The determined blockchain key derivation functions may only be applicable to one or multiple target native wireless blockchain networks, which may be determined by the UDM / ARPF especially if Native-BC-ID was not included in the request sent at 720.

[0165] At 724, the UDM / ARPF 714 may prepare a response containing the determined blockchain key derivation functions made at 722. The UDM / ARPF may send the response to the BCGF. This response may be first sent to the AUSF, which will forward the response to the BCGF. If the request sent at 720 was sent to an AUSF, then the response sent at 724 may be sent by the AUSF to the BCGF If the request sent at 720 was sent to an NRF, then the response sent at 724 may be sent by the NRF to the BCGF. This response may contain Native-BC-ID, the target native wireless blockchains as determined by the UDM / ARPF at 722.

[0166] FIG. 8 illustrates an example procedure where an AMF 812 or an AUSF requests to configure blockchain key derivation functions to a BCGF 810. At 820 the AMF or the AUSF may send a request to a UDM / ARPF 814 requesting to configure / provision blockchain key derivation functions to the BCGF 810. This request may contain the following parameters: Native-BC-ID: The identifier of the target native wireless blockchain. If this parameter is not included, the UDM / ARPF may indicate to the BCGF the identifier of the target native wireless blockchain at 824. AMF-ID (or AUSF-ID): The identifier of the AMF (or the AUSF). WTRU- ID: The identifier of WTRU (e.g., SUCI, 5G-GUTI, SUPI). If the corresponding WTRU currently has a blockchain address and the AMF / AUSF know it, WTRU-ID may also indicate the blockchain address of the WTRU. BCGF- ID: The identifier of the BCGF to receive the response at 824. BC-Key-Derv-Func-Names: Equivalent to BC- Key-Derv-Func-Names as descried in Figure 6 at 610.

[0167] At 822, the UDM / ARPF may use the SUPI (which may be equal to or can be derived from WTRU- ID) or other format of WTRU-ID to find and determine the appropriate blockchain key derivation functions for the WTRU as denoted by WTRU-ID, assuming those functions have been stored in WTRU subscription data.

[0168] The response at 824 may contain the identifier of the AMF (or the AUSF) to indicate the entity which sent the request made at 820. Alternatively, this response may be first sent to the AMF / AUSF, which will forward the response to the BCGF or forward information from the response to the BCGF. This response may response contain the determined blockchain key derivation functions made at 822. This response may contain Native- BC-ID, the target native wireless blockchains as determined by the UDM / ARPF at 822

[0169] Embodiments for WTRU-Side Configuration of Blockchain Key Derivation Functions are described herein. FIG 9 illustrates an example procedure for exchanging blockchain key derivation functions between aWTRU (e.g , a BCCCF within the WTRU) and the core network via an AMF. FIG. 9 may be summarized as follows: sending a first request by a WTRU to a first network function (e g., AMF / SEAF) for retrieving blockchain derivation functions; receiving a first response which may contain one or multiple blockchain key derivation functions from a first network function (e.g., AMF / SEAF); storing blockchain key derivation functions; using the first blockchain derivation function to derive a first blockchain key based on a first 3GPP key material (e.g., KSEAF); storing the first blockchain key; using the second blockchain derivation function to derive a second blockchain key based on the first blockchain key; store the second blockchain key; using the third blockchain derivation function to derive a third blockchain key based on the first blockchain key; and storing the third blockchain key.

[0170] Details of embodiments, examples of which are illustrated in FIG. 9 follow. At 920, a WTRU 910 may send a request to its serving AMF 912. In embodiments, this request may contain the following parameters: Native-BC-ID: The identifier of the target native wireless blockchain. If this parameter is not included (e.g., when the WTRU does not know the target native wireless blockchain), the UDM / ARPF may indicate to the WTRU the identifier of the target native wireless blockchain at 927, 928, 929. WTRU-ID: The identifier of the WTRU (e g., SUCI, 5G-GUTI) If the WTRU currently has a blockchain address, WTRU-ID may also indicate the blockchain address of the WTRU. BCGF-ID: The identifier of the BCGF if the WTRU has obtained this identifier. BC-Key-Derv-Func-Names: Indicates the name of blockchain key derivation functions being requested. It could be FBCGF, FBCCF, FBCSF, and / or FBCRD. This parameter may also indicate other key derivation functions, which can be used to derive other blockchain keys from KBCGF, KBCCF, KBCSF, and / or KBCRD. This parameter may indicate “ALL” and / or “ANY”, which mean to request all and / or any available blockchain key derivation functions.

[0171] The information in the request from made at 920 may be embedded in other non-access stratum (NAS) signaling messages to be exchanged between the WTRU and the AMF (e g., Registration Request, Registration Update, PDU Session Establishment Request). The AMF may receive the request made at 920, and may select a BCGF for the WTRU according to WTRU-ID if BCGF-ID was not included in the request made at 920. At 922, the AMF may request blockchain key derivation functions from the BCGF 914.

[0172] At 924, a request from the BCGF 914 to the UDM / ARPF 918 may additionally contain the identifier of the AMF (AMF-ID) If the BCGF has already contained or configured with blockchain key derivation functions applicable for the WTRU, for example, using the procedure in FIG. 7, may be skipped; instead, the BCGF may determine the appropriate blockchain key derivation functions for the WTRU from those ones configured and stored locally and contain them in a response to be sent at 928; this response may contain Native-BC-ID, the target native wireless blockchains as determined by the BCGF for the WTRU.

[0173] At 926, the UDM / ARPF 918 may use the SUPI (which may be equal to or can be derived from WTRU-ID) or other formats of WTRU-ID to find and determine the appropriate blockchain key derivation functions for the WTRU to interact with the target native wireless blockchain, assuming those functions have been stored in WTRU subscription data. If Native-BC-ID was not included in the request sent at 920 or if theNative-BC-ID included in the request sent at 920 is incorrect, the UDM / ARPF may also determine a target native wireless blockchain for the WTRU, for example, based on WTRU subscription data.

[0174] The response sent at 927 by the UDM / ARPF to the BCGF may contain Native-BC-ID, the target native wireless blockchains as determined by the UDM / ARPF at 926. Interaction between the BCGF and the UDM / ARPF is shown aty 924, 926 and 927. In alternative embodiments, the interaction may take place between the BCGF and a PCF. The PCF may use WTRU-ID to determine the target native wireless blockchain and the blockchain key derivation function for the WTRU; the PCF then may send the determined target native wireless blockchain and corresponding blockchain key derivation function to the BCGF.

[0175] At 928, the BCGF may send a response to the AMF. This response may be the one received 1927 or one that the BCGF generated. At 929, the AMF may receive the response from the BCGF and may forward it to the WTRU. At 930 the WTRU may receive the response sent by the AMF at 929 and may start to use the determined blockchain key derivation functions to derive its blockchain keys. Then, the WTRU may use the derived security keys to generate its blockchain address. Then, the WTRU may use its blockchain address to interact with the designated target native wireless blockchain as denoted by Native-BC-ID.

[0176] The WTRU may use the process described with respect to FIG. 9 (920-929) to retrieve a first blockchain key derivation function (e.g., FBCGF) and derive the first blockchain key (e.g., KBCGF) using the first blockchain key derivation function; then, the WTRU may repeat steps 920 to 929 of FIG 9, as described above, to retrieve the second blockchain key derivation function (e g., FBCCF) and derive the second blockchain key (e g., KBCCF) using the first blockchain key and the second blockchain key derivation function. The WTRU may continue steps 920 to 929 of FIG. 9 to retrieve other blockchain key derivation functions and derive other blockchain keys. Alternatively, the WTRU may retrieve all blockchain key derivation functions using steps 920- 928 of FIG. 9 once and derive all blockchain keys at 930 only once

[0177] FIG. 10 illustrates an example procedure for exchanging blockchain key derivation functions between a WTRU and the core network during the procedure of PDU Session Establishment. When a WTRU needs to establish a PDU session for blockchain user plane (e.g., sending a transaction to blockchain ledgers) but needs to derive blockchain security keys to secure the transmission of transactions, in embodiments the WTRU may use the example procedure described below with respect to FIG. 10.

[0178] At 1020, the WTRU 1010 may send a PDU Session Establishment Request to its serving AMF 1012. In embodiments, this request may contain the following parameters: Native-BC-ID: The identifier of the target native wireless blockchain. If this parameter is not included (e g., when the WTRU does not know the target native wireless blockchain), the UDM / ARPF may indicate to the WTRU the identifier of the target native wireless blockchain shown at 1030, 1032 1034. WTRU -ID: The identifier of WTRU (e.g., SUCI, 5G-GUTI). If the corresponding WTRU currently has a blockchain address, WTRU-ID may also indicate the blockchain address of the WTRU BC-Key-Derv-Func-Names: Indicates the name of blockchain key derivation functions being requested, which could be FBCGF, FBCCF, FBCSF, and / or FBCRD. This parameter may also indicate other keyderivation functions, which can be used to derive other blockchain keys from KBCGF, KBCCF, K=, and / or KBCRD. This parameter may indicate “ALL” and / or “ANY”, which mean to request all and / or any available blockchain key derivation functions.

[0179] At 1022, the AMF may receive the request made at 1020 Since the request is for PDU Session Establishment, the AMF may select an SMF. Because the request made at 1020 contains “BC-Key-Derv-Func- Names”, the AMF may select an SMF that can retrieve blockchain key derivation functions from a UDM / ARPF. At 1024, the AMF may send a Nsmf_PDUSesson_CreateSMContext Request to the selected SMF 1014. In addition to contain the parameters as defined in existing 3GPP specifications on PDU Session Establishment, this request may contain BC-Key-Derv-Func-Names as received from the request made at 1020. In addition, Data Network Name (DNN) in this request may be set to “NATIVE WIRELESS BLOCKCHAIN” or a BC-Name, which stands for the name of the native wireless blockchain. At 1026, the SMF requests blockchain key derivation functions from the UDM / ARPF 1016. The request may contain BC-Key-Derv-Func-Names.

[0180] At 1028, the UDM / ARPF may determine the blockchain key derivation functions for the WTRU according to BC-Key-Derv-Func-Names, which is applicable to the target native wireless blockchain. If Native- BC-ID was not included in the request made at 1020 or if Native-BC-ID included in the request made at 1020 is incorrect, the UDM / ARPF may also determine a target native wireless blockchain for the WTRU, for example, based on WTRU subscription data. At 1030, th UDM / ARPF sends a response to the SMF with blockchain key derivation functions. This response may contain the blockchain key derivation function determined at 1028. This response may contain Native-BC-ID, the target native wireless blockchains as determined by the UDM / ARPF at 1028.

[0181] Interaction between the SMF and the UDM / ARPF is shown at 1026, 1028 and 1030 Alternatively, the interaction may take place between the SMF and a PCF, when the SMF establishes a Policy Association with the PCF for the PDU Session. The PCF may use the DNN (which may be set to “NATIVE WIRELESS BLOCKCHAIN” or a BC-Name) and S-NSSAI of the PDU Session to determine the target native wireless blockchain and the blockchain key derivation function

[0182] At 1024, the SMF 1014 may send a Nsmf_PDUSesson_CreateSMContext Response to the AMF. This response may contain the determined blockchain key derivation functions and Native-BC-ID. At 1034, the AMF may receive the response from the SMF and may forward it to the WTRU. At 1036 the WTRU may receive the response sent at 1034 and may start to use the determined blockchain key derivation functions to derive its blockchain keys. Then, the WTRU may use the derived blockchain keys to generate its blockchain address. Then, the WTRU may use its blockchain address to interact with the designated target native wireless blockchain as denoted by Native-BC-ID.

[0183] The WTRU may use the procedure described with respect FIG. 10 (1020-1034) to retrieve a first blockchain key derivation function (e.g., FBCGF) and derive the first blockchain key (e.g., KBCGF) using the first function; then, the WTRU may repeat the procedure described with respect to FIG. 10 (1020-1036) to retrievethe second blockchain key derivation function (e.g., FBCCF) and derive the second blockchain key (e.g., KBCCF) using the first blockchain key and the second function. The WTRU may continue the procedure described with respect to FIG. 10 (1020-1036) to retrieve other blockchain key derivation functions and derive other blockchain keys. Alternatively, the WTRU may retrieve all blockchain key derivation functions using the procedure described with respect to FIG. 10 (1020-1034) once and derive all blockchain keys, as described with respect to FIG. 10 1036, once.

[0184] Embodiments for UDM Pushes of Blockchain Specific Parameters to a WTRU are described herein. As an alternative approach illustrated in FIG. 11 , a UDM / ARPF may use a 3GPP WTRU Parameters Update via UDM Control Plane Procedure to push blockchain specific parameters (e.g , BC address (es), BC access credentials, BC key derivation functions (BC-Key-Derv-Func)) to a WTRU. Those blockchain specific parameters may be contained in a blockchain information element (BC-IE).

[0185] In embodiments, at 1120, the UDM 1114 may determine to perform WTRU Parameter Update for the WTRU 1110 (e.g., update the Steering of Roaming (SoR) information stored at the WTRU). In embodiments, this determination may be triggered by a PCF based on some policies; for example, a policy may describe when the trust index of the WTRU is below a threshold, the WTRU needs to join a native wireless blockchain and thus the WTRU first needs to be configured with blockchain derivation functions. In embodiments, this determination also may be triggered when a new native wireless blockchain is set up and the WTRU needs to join this new or a different native wireless blockchain. In embodiments, this determination also may be triggered by Mobile Network Operator (MNO) following a subscription data update for the WTRU (e g., blockchain-enabled operations is being authorized). In embodiments, this determination also may be triggered by an AF following a blockchain configuration update (e.g., blockchain address information update). At 1122, the UDM may notify the AMF 1112 of the new blockchain specific parameters by invoking NudmJSDM_Notification service operation to the AMF. This notification message transmitted through Nudm_SDM_Notification service operation may contain the following parameters: WTRU -ID: The identifier of the WTRU (e g., SUCI, SUPI). BC-IE: The blockchain information element to be configured / updated to the WTRU BC-IE may contain the following parameters: Native-BC-ID: The name or identifier of the target native wireless blockchain that the WTRU may interact with. BC-Security-Para: The parameters related to generating and managing blockchain security related information (e.g., blockchain security keys at the WTRU, blockchain address of the WTRU, etc.). For example, BC-Security-Para may include: BC-Key-Derv-Func: The blockchain key derivation functions that were determined for the WTRU and that applies to the target native wireless blockchain as denoted by Native-BC-ID This parameter BC-Key-Derv-Func may also contain other necessary input parameters which are required in order to run the corresponding blockchain key derivation functions. WTRU-BC-Addr-Scheme: The blockchain address scheme that the WTRU may follow to generate its blockchain address. For example, WTRU-BC-Addr-Scheme may be set to “Generate Blockchain Address Using Security Keys Derived by BC-Key-Derv-Func”; in this case, the WTRU may first derive blockchain security keys (e.g., a pair of WTRU’s private key ad public key) according to BC-Key-Derv-Func and thengenerate its blockchain address using the derived blockchain security keys (e.g., a WTRU’s public key). In another example, WTRU-BC-Addr-Scheme may be set to “Generate Blockchain Address Using Random Security Keys”; in this case, the WTRU may generate its blockchain address using its own private / public key pair without deriving any blockchain security keys. In another example, WTRU-BC-Addr-Scheme may be set to “Blockchain Address Assigned by Network” which means the blockchain address of the WTRU may be assigned by an NF (e.g., by a BCGF); in this case, the identifier of the NF may additionally be included in WTRU-BC-Addr-Scheme WTRU-BC-Addr: The blockchain address that the network may have generated and is assigning to the WTRU. If this parameter is included, WTRU-BC-Addr-Scheme may not be needed.

[0186] Para-for-BC-Control-Plane: Indicates necessary parameters to enable the WTRU to interact with control plane of the native wireless blockchain as denoted by Native-BC-ID, such as: BCCF-ID: The identifier or the address of a designated BCCF that the WTRU can contact. BC-Addr-Registration-Mode: Indicates how the WTRU should register its blockchain address and get it authorized by the network (e.g., a BCGF). This parameter may indicate one of the following modes: The WTRU may include its blockchain address in the first WTRU Registration request to be sent to its serving AMF. The WTRU may include its blockchain address in a WTRU Registration Update request to be sent to its serving AMF. The WTRU may send its blockchain address in a separate NAS message to its serving AMF after a successful WTRU registration or a successful primary authentication. Para-for-BC-User-Plane: Indicates necessary parameters to enable the WTRU to interact with user plane of the target native wireless blockchain as denoted by Native-BC-ID, such as: BCSF-ID: The identifier or the address of one or multiple designated BCSF that the WTRU can contact to write transactions to or retrieve transactions from the target native wireless blockchain. CP-or-UP: Indicate if the WTRU should contact BCSFs using 3GPP control plane (CP) or 3GPP user plane (UP). DNN-for-BC: The name of data network(s) that host the designated BCSFs. The WTRU may include DNN-for-BC when it requests to establish a PDU session in order to interact with a designated BCSF. The network may assign different DNN-for-BC for different native wireless blockchains. This parameter may be skipped if CP-or-UP = “CP”. WTRU-BC-URSP- ID: The identifier of the UE Route Selection Policy (URSP) that applies to the PDU session that the WTRU may use to contact the designated BCSFs. The UDM also may use this parameter to update the WTRU with new URSP to be applied for blockchain user plane. This parameter WTRU-BC-URSP-ID may be skipped if CP-or- UP = “CP”. Each BC-IE may correspond to a native wireless blockchain. UPU container may contain one or multiple BC-IE as described above

[0187] At 1124, the AMF 1112 may send a DL NAS TRANSPORT message to the WTRU 1110. This message may contain a UPU container, which may include BC-IE as received at 1122. At 1126, the WTRU may store the UPU container. In embodiment, the WTRU may extract any BC-IE from the UPU container. In embodiments, the WTRU may store extracted BC-IEs. At 1128, the WTRU may perform local blockchain related operations according to BC-IEs. For example, the WTRU may create a local BC-IE to store each received BC-IE for the target native wireless blockchain as denoted by Native-BC-ID. The WTRU may derive blockchain security keys according to BC-Key-Derv-Func. The WTRU may record whether each blockchainkey function can be successfully executed. If WTRU-BC-Addr is contained in BC-IE, the WTRU may store it; otherwise, the WTRU may generate a blockchain address according to WTRU-BC-Addr-Scheme. The WTRU may use WTRU-BC-URSP-ID to locate the URSP locally stored at the WTRU At1128, in embodiments, the WTRU may also establish a PDU session with a designated BCSF, e.g., according to WTRU-BC-URSP-ID.

[0188] At 1130, the WTRU may send an UL NAS TRANSPORT message to AMF. This message may contain an UPU ACK, which may indicate the result (e.g., success or failure) of local blockchain related operations performed by the WTRUI at 1128 (WTRU-BC-OP-Results), for example, to indicate whether each blockchain derivation function was successfully executed at 1128. At 1132, the AMF 1112 may use Nudm_SDM_lnfo to send the UPU ACK received at 1130 to the UDM 1114. The UPU ACK may contain WTRU- BC-OP-Results. The UDM may perform additional actions, dependent on WTRU-BC-OP-Results. For example: If the received WTRU-BC-OP-Results indicate some blockchain key derivation functions could not be successfully executed, the UDM may send new blockchain key derivation functions to the WTRU as shown and described with respect to 1122. If the received WTRU-BC-OP-Results show that the WTRU cannot find corresponding URSP as denoted by WTRU-BC-URSP-ID, the UDM may trigger to send new URSP for blockchain user plane to the WTRU. At 1134, the WTRU may contact the designated BCCF and / or the designated BCSFs according to what the received BC-IEs specify and the results of local blockchain related operations at 1128. For example, the WTRU may contact the designated BCCF to register its blockchain address according to BC-Addr-Registration-Mode and have it authenticated by the target native wireless blockchain system. The WTRU may contact the designated BCSF using the PDU session established at 1128 according to the designated URSP as denoted by WTRU-BC-URSP-ID.

[0189] Embodiments for Device Selection and Notification for Wireless Blockchain Onboarding are discussed herein.

[0190] Design principles of the embodiments described herein include: 1) consider various needs of initiating wireless blockchain onboarding; and 2) allow only authorized parties to select and notify devices for wireless blockchain onboarding. Benefits of the embodiments described herein include: 1 ) workable for different scenarios; 2) avoid unnecessarily repeated device selection and notification for wireless blockchain onboarding; and 3) more secure device selection and notification for wireless blockchain onboarding compared to the scenario where any party may perform device selection and notification.

[0191] In order to onboard a device to a native wireless blockchain, the device may initiate an onboarding process by itself. However, the device first may need to get some initial information (e.g., the address or the identifier of a BCCF or a BCGF) in order to start the onboarding process. Logical entities such as BCGF and BCAF can initiate wireless blockchain onboarding and send such initial information (e.g., in the form of wireless blockchain onboarding instructions) to the device; in the context of 3GPP, a UDM may leverage existing 3GPP “WTRU Parameters Update via UDM Control Plane Procedure” to push such initial information to the device / WTRU by containing the initial information in a UPU container, which will be sent from the UDM to anAMF and be forwarded from the AMF to the

[0192] Several embodiments for initiating wireless blockchain onboarding are discussed herein In a first approach, as illustrated FIG. 12 and described below, a BCGF may first select and determine devices to be onboarded to a native wireless blockchain Then, the BCGF may prepare onboarding instructions for the selected devices. Finally, the BCGF (and / or a BCCF) may send the onboarding instructions to the selected devices to initiate wireless blockchain onboarding.

[0193] FIG. 13 illustrates the second approach, as described below, where a BCAF (e g., a management or an administration application) may request to onboard one or multiple devices. The BCAF first may prepare onboarding instructions; then, the BCAF may send them to a BCCF. The BCCF may ask a BCGF to authorize the request from the BCAF. After the authorization, the BCCF may send the onboarding instructions to devices to initiate wireless blockchain onboarding procedure. Alternatively, another device / WTRU also can perform the same operations as the BCAF.

[0194] The third approach, as illustrated in FIG. 14 and described below, is similar to the second approach. The difference is the BCAF will send onboarding instructions to the BCGF instead of the BCCF in the second approach.

[0195] A device can also trigger to initiate wireless blockchain onboarding for another device. Several procedures are described herein.

[0196] A device can actively and independently initiates / determines to have itself to be onboarded to the native wireless blockchain. In this case, there is no need for an initiation procedure between the device and network; instead, the device may use procedures discussed herein below to perform wireless blockchain onboarding

[0197] Embodiments for Device Selection and Notification for Wireless Blockchain Onboarding by BCGF are discussed herein.

[0198] FIG. 12 illustrates an example procedure of wireless blockchain onboarding initiated by a BCGF. There are three logical entities in this procedure: 1) a BCGF 1214 having an identifier or an address BCGF-ID; 2) a BCCF 1212 having an identifier or an address BCCF-ID; and 3) a Device 1210 having an identifier or an address Dev-ID. While FIG. 12 shows only one device 1210, the same procedure may be applied to initiate wireless blockchain onboarding for multiple devices. In embodiments of the procedure described with respect to FIG. 12, a BCCCF within the device may perform all required operations on behalf of the device.

[0199] At 1221 , the BCGF 1214 may select one or multiple devices to be onboarded to a target native wireless blockchain as denoted by Native-BC-ID. There may be various scenarios for such device selection. Location-based: The BCGF may decide to onboard devices around a specific physical location. In embodiments, the BCGF may obtain those devices around the physical location from the core network (e.g., LMF or AMF). Context-based: The core network maintains context information for devices (e.g., WTRU context in 5GS), based on which the core network may decide to use a target native wireless blockchain for some WTRUs to enable or improve their trustworthiness. The core network (e.g., AMF, SMF) may send a list of thoseWTRUs to the BCGF; the BCGF may select WTRUs / devices from the list for initiating wireless blockchain onboarding Service-based: The BCGF may decide to add some new BSNs to the target native wireless blockchain to offer blockchain functions nearer to existing BCNs and / or to replace some existing BSNs for better performance. To host a new BSN, a device (or an AF / NF / Edge Application Server) needs to be selected and onboarded to the target native wireless blockchain. Address-based: Some existing BCNs may need to be re-onboarded to obtain a new or an additional blockchain address. The BCGF can decide those devices which have hosted BCNs and need to be re-onboarded.

[0200] Also at 1221 , a list of devices may be determined by the BCGF for (re-)onboarding. For each selected device, the BCGF may obtain its identifier in wireless system such as 5GS (e g., Subscription Concealed Identifier (SUCI), Subscription Permanent Identifier (SUPI), 5G Globally Unique Temporary Identity (5G-GUTI)) from the core network. Also at 1220, , the BCGF may know the device’s blockchain address if the selected device is already a BCN or a BSN.

[0201] In embodiments, the selection at 1221 may be triggered by a request from an AF. The request from the AF may request that the onboarding process be triggered, and the request may include one or more device identifiers, and / or identifiers of groups of devices, that the request applies to. In embodiments, the selection at 1221 may be triggered by a 3GPP NF (e.g., an AMF, an AUSF, a UDM) during or after the Device is registered with the 3GPP network with a successful primary authentication. Step 1 might be triggered by a 3GPP NF (e.g., an AMF, an SMF) during or after the Device 1210 establishes a PDU session with a successful secondary authentication.

[0202] At 1222, for each selected device, the BCGF 1214 may select a BCCF 1212 as the device’s entry point to the target native wireless blockchain. In embodiments, a selected BCCF may serve multiple devices. The target native wireless blockchain may have multiple BCCFs, which may have registered to a repository (e g., an NRF in 5GC); then, the BCGF may discover BCCFs from the repository. For example, the discovery operation may be performed with an NRF. Alternatively, BCCFs may have registered with the BCGF; the BCGF may maintain a list of registered BCCFs and can select BCCFs directly from this list. Each BCCF may be assigned to serve devices from different locations; then, the BCGF can assign a BCCF to devices according to their location. In another example, the BCGF may monitor the load of each BCCF (e.g., the number of onboarded devices via each BCCF) and select a BCCF with the least load. In another example, the BCGF may select a BCCF that is closer to selected devices and / or a BCCF that has better communication channel (e.g., higher capacity) to the serving AMF of selected devices. The BCGF could re-use previously selected BCCF for new devices; thus, the selection at 1222 may be optional.

[0203] At 1222, the BCGF may generate an authorized blockchain address (Authorized-Dev-BC-Addr) for each selected device; the BCGF may also determine “Dev-BC-lnit-Config” for each selected device; “Dev-BC- Init-Config” is described herein, below.

[0204] At 1224, the BCGF may send a wireless blockchain onboarding initiation request to the selected BCCF(s). This request may contain the following information: Native-BC-ID: The identifier of the target native wireless blockchain which the device needs to be onboarded to. Dev-ID(s): The identifiers (e.g , 5G-GUTI, SUCI, SUPI) of selected devices which will be onboarded to native wireless blockchain through the selected BCCF.BCGF-ID: The identifier of the BCGF, through which the BCCF and devices can contact the BCGF. BCGF-ID may be an IP address, an IP address with an TCP / UDP port, a Uniform Resource Locator (URL), a Fully Qualified Domain Name (FQDN), a blockchain address, etc. BC-Addr-Scheme: Indicates scheme(s) or algorithm(s) for devices contained in Dev-ID to generate its blockchain address BC-Addr-Scheme could indicate multiple schemes or algorithms, each of which may be applied to different devices contained in Dev- ID. This parameter BC-Addr-Scheme may not be needed if the BCGF generated Authorized-Dev-BC-Addr at 1222.

[0205] BC-Onboarding-lnstructions: Contains the instructions on when / how devices should start wireless blockchain onboarding. BC-Onboarding-lnstructions may contain the following parameters: BC-Onboarding- Addr: Indicates the address or identifier of a BCCF that devices should later contact for wireless blockchain onboarding BC-Onboarding-Role: Indicates whether a device should be onboarded as a BCN or a BSN. BC- Onboarding-Path: Indicates whether a device should use control plane (e.g., Non-Access-Stratum (NAS) signaling) or user plane (e.g., via a PDU session) to contact the BCCF as indicated by BC-Onboarding-Addr. BC-Onboarding-Policies: Indicate when and / or under which conditions the device may start onboarding. The policies could be based on, but not limited to, one, multiple, and / or a combination of the following conditions / parameters: 1)BC-Onboarding-Delay: Indicates if a device should perform wireless blockchain onboarding immediately after receiving BC-Onboarding-lnstructions (e.g., BC-Onboarding-Delay=0) or wait for a fixed or a random time internal; 2) When the device successfully generates its blockchain address; 3) When the derive enters certain area (e.g., a new service area, a new registration area); 4) When the device receives new Steering of Roaming (SoR) information from a UDM; 5) When the trust index of the device received from network is below a threshold; and 6) When the device receives a local request from the user of the device or a local application on the device.

[0206] If the BCGF determined Authorized-Dev-BC-Addr and Dev-BC-lnit-Config at 1222, both parameters may be contained in the request made at 1224.

[0207] At 1226, the BCCF 1212 may process the wireless blockchain onboarding initiation request. The BCCF may buffer wireless blockchain onboarding initiation requests for some time indicated by the BCGF or decided by the BCCF. By buffering such onboarding initiation requests, the BCCF could (re-)group devices and use one request (in step 5) to instruct multiple devices to start wireless blockchain onboarding. At 1226, the BCCF may also update Dev-BC-lnit-Config to generate Dev-BC-Final-Config for each device according to the details described herein, below.

[0208] At 1228, the BCCF 1212 may send wireless blockchain onboarding initiation request to the Device1210. This request may contain parameters from the request made at 1224 such as Native-BC-ID, Dev-ID, BC-Addr-Scheme, BCGF-ID, and BC-Onboarding-lnstructions. This request may also contain the BCCF-ID. The BCCF may send this request in a 3GPP N1 (NAS) message to the Device via its serving AMF; the BCCF can use Dev-ID to find the serving AMF. Alternatively, the Device may be triggered to establish a PDU session; for this purpose, the core network may need to send a downlink trigger message to the Device; then, this message can contain the blockchain onboarding initiation information as received at 1224. This request may be broadcasted to multiple devices; for example, a 5G messaging service may be used to broadcast this request. After the Device receives this request, the Device may send a response to the BCCF to indicate the successful receipt of this request. The request made at 1228 may contain Authorized-Dev-BC-Addr and Dev-BC-Final- Config. Right after the request made at 1228, the Device 1210 may send a confirmation (not shown) to the BCCF indicating the successful receipt of the request.

[0209] At 1230 the BCCF may send a wireless blockchain onboarding initiation response to the BCGF. This response may contain a list of devices which have been successfully notified of onboarding initiation at 1228. The BCCF and / or the BCGF may maintain a list of devices that have been successfully notified of onboarding initiation. In embodiments, the response made at 1230 may contain Dev-BC-Final-Config.

[0210] At 1232, as an alternative approach (labeled Option 2) the BCGF may send the same wireless blockchain onboarding initiation request made at 1224 to the Device directly. After the Device receives this request from the BCGF, the Device may send a response to the BCGF to indicate the successful receipt of this request.

[0211] Right after the request made at 1232, the Device may send a confirmation to the BCCF (not shown)indicating the successful receipt of the request made at 1232.

[0212] After the request made at 1228 (Option 1) or at 1232 (Option 2), the Device may store BC- Onboarding-lnstructions and other parameters as contained in the request received at 1228 (Option 1) or at 1232 (Option 2); then, the Device may generate its blockchain address according to BC-Addr-Scheme designated by the request received at 1228 (Option 1) or at 1232 (Option 2); after that, the Device may contact the BCCF as denoted by BC-Onboarding-Addr as a part of blockchain onboarding instructions to start wireless blockchain onboarding process, for example, by sending a wireless blockchain onboarding request to the BCCF, as described herein with respect to Wireless Blockchain Onboarding. The information that is received by the Device’s modem in the request made at 1228 (Option 1) or at 1232 (Option 2) may be sent to a device application that is hosted on the Device; the information may be sent by invoking an API or AT Command; the information by then may be used by the device application to initiate contacting the BCCF. If the request made at 1228 contains Dev-BC-Final-Config, the Device may start to interact with the target native wireless blockchain according to what Dev-BC-Final-Config describes; if the request made at 1232 contains Dev-BC- Init-Config, the Device may start to interact with the target native wireless blockchain according to what Dev- BC-lnit-Config describes.

[0213] Device Selection and Notification for Wireless Blockchain Onboarding by BCAF and through BCCF are described herein.

[0214] FIG. 13 illustrates embodiments for a procedure where a BCAF 1316 such as a management application or a 3GPP NF (e.g., an AMF, an AUSF, a UDM, an SMF) or another Device-B may initiate wireless blockchain onboarding through a BCCF 1312. In embodiments, the BCCF may need a BCGF 1314 to authorize the onboarding initiation request the BCCF receives from the BCAF. In this approach, it is assumed that the BCCF has obtained the contact information of the BCGF from a repository (e.g., NRF) or is configured with the contact information of the BCGF. In embodiments, a BCCCF within Device-A may perform all required operations on behalf of Device-A.

[0215] At 1320 (similar to step 1220 of FIG. 12), the BCAF 1316 (or even another Device-B) may select one or multiple devices (e g., Device-A 1310) to be onboarded to a target native wireless blockchain. The BCAF may use the same approaches as described in with respect to FIG. 12 to select devices.

[0216] At 1322, the BCAF may obtain the contact information of a BCCF 1312. In one example, the BCAF 1316 may be provisioned or configured with the BCCF 1312. In another example, the BCAF could discover BCCFs from a repository (e.g., NRF in 5GC); when the BCAF discovers BCCFs from the repository (or another network function in the core network), it may need to indicate the identifiers of selected devices at 1320 and / or the identifier of the target native wireless blockchain if the BCAF knows it to the repository; then, the repository can find appropriate BCCFs that can handle those selected devices assuming each BCCF has been registered to the repository.

[0217] At 1324, (similar to FIG. 12, 1224), the BCAF may send a wireless blockchain onboarding initiation request to the BCCF This request may contain the identifier of the BCAF (BCAF-ID) but may not include BC- Addr-Scheme since the BCAF may not know it or may not be able to decide it. This request may contain the identifier of the target native wireless blockchain if the BCAF knows it; the target native wireless blockchain for selected devices (e.g., Device-A) may be (re)determined by the BCGF (1328) or by the BCCF (1332). This request may contain Dev-ID which is the same as that contained of FIG. 12 at 1224. This request may not contain BC-Onboarding-lnstructions. If this request contains BC-Onboarding-lnstructions, it may indicate a subset of parameters of BC-Onboarding-lnstructions (e.g., BC-Onboarding-Delay.

[0218] At 1326, the BCCF may receive the wireless blockchain onboarding initiation request from the BCAF and may forward it to the BCGF for authorization In embodiments, this request may also contain the identifier of the BCCF (BCCF-ID).

[0219] At 1328, the BCGF may receive the wireless blockchain onboarding initiation request made at 1326 and may authorize it. For example, the BCGF may reject to initiate blockchain onboarding for some or all devices contained in the request (e.g., if the target native wireless blockchain currently has too many onboarded devices). In another example, the BCGF may decide that some devices can be onboarded but should not be onboarded through this BCCF (e.g., if this BCCF was assigned to only handle devices around a specificphysical location); those devices may be marked as partially approved devices. For each device that the BCGF approves for wireless blockchain onboarding initiation, the BCGF may determine the appropriate Native-BC- ID, BC-Addr-Scheme, and BC-Onboarding-lnstructions for onboarding them.

[0220] At 1328, the BCGF may also generate an authorized blockchain address (Authorized-Dev-BC-Addr) for Device-A; the BCGF may also determine “Dev-BC-lnit-Config” for Device-A; “Dev-BC-lnit-Config” is described herein, below.

[0221] At 1330: The BCGF may send a response to the BCCF. This response may contain: The identifier of the (re)determined target native wireless blockchain (Native-BC-ID) The list of devices approved in at 1328 (Approved-Dev). the list of devices rejected in step 5 (Rejected-Dev). The list of devices partially approved at 1328 (Partially-Approved-Dev). BC-Addr-Scheme for each approved device as determined at 1328. BC- Onboarding-lnstructions for each approved device as determined at 1328 New-BCCF that indicates another new BCCF (New-BCCF-ID) which can handle the list of partially approved devices.

[0222] If the BCGF determined Authorized-Dev-BC-Addr and Dev-BC-lnit-Config at 1328, both parameters may be contained the response made at 1330.

[0223] At 1332, the BCCF may prepare a new wireless blockchain onboarding initiation request according to the original request received at 1334 and the response received at 1330. The BCCF may (re)determine the target native wireless blockchain for the approved devices This new request may only contain necessary information about and for the devices approved at 1328 such as Native-BC-ID, Dev-ID, BC-Addr-Scheme, BC- Onboarding-lnstructions, BCCF-ID, and BCAF-ID. The BCCF may need to (re)determine BC-Addr-Scheme and BC-Onboarding-lnstructions for each approved device, especially if BC-Addr-Scheme and BC- Onboarding-lnstructions were not contained in the response sent at 1330.

[0224] At 1332 7, the BCCF may also update Dev-BC-lnit-Config to generate Dev-BC-Final-Config for Device-A according to the details described herein, below.

[0225] At 1334, the BCCF may send the new wireless blockchain onboarding initiation request to each approved device (e.g., Device-A); each approved device may send a response back to the BCCF to indicate the successful receipt of this onboarding initiation request Optionally, the BCCF may also send a notification for each partially approved device to inform them of New-BCCF-ID and BCAF-ID; then each partially approved device may actively contact New-BCCF-ID or the BCAF to initiate wireless blockchain onboarding. The request made at 1334 may contain Authorized-Dev-BC-Addr and Dev-BC-Final-Config.

[0226] After the request made at 1334, the Device may send a confirmation to the BCCF indicating the successful receipt of the request

[0227] At 1336, the BCCF may send a response to the BCAF. This response may indicate (re)determined Native-BC-ID, Approved-Dev, Partially-Approved-Dev, Rejected-Dev, and New-BCCF-ID. After the BCAF receives this response, it may continue to contact the new BCCF as denoted by New-BCCF-ID to initiate wireless blockchain onboarding for partially approved devices contained in Partially-Approved-Dev.

[0228] After the request made at 1334, the Device-A may store BC-Onboarding-lnstructions and other parameters as contained in the request; then, the Device-A may generate its blockchain address according to BC-Addr-Scheme designated in the request made at 1334; after that, the Device-A may contact the BCCF as denoted by BC-Onboarding-Addr as a part of blockchain onboarding instructions to start wireless blockchain onboarding process, for example, by sending a wireless blockchain onboarding request to the BCCF, as described herein below regarding Wireless Blockchain Onboarding. The information that is received by the Device-A’s modem at 1334 may be sent to a device application that is hosted on the Device-A; the information may be sent by invoking an API or AT Command; the information by then may be used by the device application to initiate contacting the BCCF. If the request made at 1334 contains Dev-BC-Final-Config (or Dev-BC-lnit- Config), Device-A may start to interact with the target native wireless blockchain according to what Dev-BC- Final-Config (or Dev-BC-lnit-Config) describes

[0229] Embodiments for Device Selection and Notification for Wireless Blockchain Onboarding Initiation by BCAF 1416 and through BCGF 1414 are described herein. FIG. 14 illustrates a further example procedure where a BCAF or a 3GPP NF (e.g., an AMF, an AUSF, a UDM, an SMF) or another Device-B may initiate wireless blockchain onboarding through a BCGF. The BCGF may authorize the request from the BCAF and may decide onboarding instructions for devices to be onboarded Then, the BCGF may send the onboarding instructions to devices via a BCCF 1412 In embodiments as described with respect to FIG. 14, a BCCCF within Device-A 1410 may perform all required operations on behalf of Device-A.

[0230] The selection of devices made at 1420 is similar to that made at 1320 of FIG. 13. At 1422, the BCAF may obtain the contact information of a BCGF. In one example, the BCAF may have been provisioned with the contact information of the BCGF. In another example, the BCAF may discover the BCGF from a repository (e g., NRF or another core network function) optionally by indicating its application type (BCAF-Type), which could be a blockchain management application, a blockchain application for a vertical domain, etc; when the BCAF discovers the BCGF from the repository (e.g., NRF or another core network function), it may need to indicate the identifiers of selected devices made at 1420 to the repository and / or the identifier of the target native wireless blockchain if the BCAF knows it to the repository; then, the repository can find appropriate BCGFs that can handle those selected devices assuming each BCGF had been registered to the repository; the repository may determine the appropriate BCGF for the BCAF using certain criteria (e.g , a BCGF for different BCAF-Type(s)).

[0231] The request made at 1424 is similar to that made at 1324 of FIG. 13. In this embodiment, the BCAF may send the wireless blockchain onboarding initiation request to the BCGF.

[0232] The authorization made at 1426 is similar to that made at 1328 of FIG. 13. In embodiments, the BCGF may authorize wireless blockchain onboarding initiation request received at 1424. In one example, some devices may not be allowed to be initiated by the BCAF. In another example, if the target native wireless blockchain currently has too many onboarded devices, the BCGF may reject to initiate some or all devices contained in the request. For each device that the BCGF approves for wireless blockchain onboarding initiation,the BCGF may determine the target native wireless blockchain (Native-BC-ID), BC-Addr-Scheme, and BC- Onboarding-lnstructions.

[0233] The selection of BCCF made at 1428 is similar to that made in FIG. 12 at 1222. The BCGF may select the BCCF. As a part of this step, the BCGF may generate an authorized blockchain address (Authorized- Dev-BC-Addr) for Device-A; the BCGF may also determine “Dev-BC-lnit-Config” for Device-A; “Dev-BC-lnit- Config” is described herein, below.

[0234] At 1430, the BCGF may send a response to the BCAF. This response may contain: The identifier of the (re)determined target native wireless blockchain (Native-BC-ID).A list of devices being approved at 1426 (Approved-Dev). A list of any devices being rejected at 1426 (Rejected-Dev). A list of devices being partially approved at 1426 (Partially-Approved-Dev). New-BCGF-ID (determined at 1426 or 1428) that indicates another new BCGF which can handle the list of partially approved devices.

[0235] If the BCGF determined Authorized-Dev-BC-Addr and Dev-BC-lnit-Config at 1428, both parameters may be contained in the response made at 1430. The request of 1432 is similar to that made at 1332 of FIG. 13. The request made at 1434 is similar to that made at 1224 of FIG. 12. The processing made at 1436 is similar to that made at 1226 of FIG. 12. The request made at 1438 is similar to that made at 1128 of FIG. 11. After Device-A receives this request in made at 1438, the Device may send a response to the BCCF to indicate the successful receipt of this request; the BCCF may forward this response to the BCGF; the BCGF may forward this response to the BCAF.

[0236] After receipt of the request at 1438, the Device may send a confirmation to the BCCF indicating the successful receipt of the request

[0237] After the receipt of the request at 1438, the Device-A may store BC-Onboarding-lnstructions and other parameters as contained in the request received; then, the Device-A may generate its blockchain address according to BC-Addr-Scheme designated by the request made at 1438; after that, the Device-A may contact the BCCF as denoted by BC-Onboarding-Addr as a part of blockchain onboarding instructions to start wireless blockchain onboarding process, for example, by sending a wireless blockchain onboarding request to the BCCF, as described herein below regarding Wireless Blockchain Onboarding. The information that is received by the Device-A’s modem at 1438 may be sent to a device application that is hosted on the Device-A; the information may be sent by invoking an API or AT Command; the information by then may be used by the device application to initiate contacting the BCCF. If the request made at 1438 contains Dev-BC-Final-Config, Device-A may start to interact with the target native wireless blockchain using Authorized-Dev-BC-Addr, according to what Dev-BC-Final-Config describes.

[0238] Embodiments for Device Selection and Notification for Wireless Blockchain Onboarding Initiation by Other Devices are described herein.

[0239] FIG. 15 illustrates embodiments of a procedure for Device-A 1512 as a discoverer to initiate wireless blockchain onboarding for Device-B 1510 as a discoveree. Device-B may be discovered by Device-A. Duringthe discovery process, Device-B may inform Device-A of its need for onboarding to a target native wireless blockchain. Then, Device-A may contact a BCCF 1514 to request BC-Onboarding-lnstructions for Device-B. After receiving BC-Onboarding-lnstructions from the BCCF, Device-A may forward BC-Onboarding-lnstructions to Device-B. On FIG. 15, a BCCCF within Device-A may perform all required operations on behalf of Device- A. In embodiments described in FIG. 15, a BCCCF within Device-B may perform all required operations on behalf of Device-B.

[0240] Embodiments desorbed below with respect to FIG. 15 may be summarized as follows: Broadcast, by a WTRU a discovery solicitation request, which may indicate the first node's capability in onboarding other nodes to the native wireless blockchain; Receive a discovery response from the second node, which may indicate the second node's need on onboarding to the native wireless blockchain (BC-Onboarding-lndicator); Send a wireless blockchain onboarding initiation request to the third node (e.g., BCCF) which may indicate the second node as the target node to be onboarded to the native wireless blockchain; Receive a wireless blockchain onboarding initiation response from the third node, which may indicate blockchain onboarding instructions for the second node; and Forward the wireless blockchain onboarding initiation response to the second node.

[0241] At 1520, Device-A 1512 may broadcast a discovery solicitation request to its neighboring devices. This request may contain the following parameters: Dev-A-ID: The identifier (e.g., 5G-GUTI, SUCI) of Device- A. Native-BC-ID: The identifier or the name of the native wireless blockchain that Device-A can request BC- Onboarding-lnstructions for other devices BC-Onboarding-Capability: This parameter may be a binary flag. If this parameter is “TRUE”, it indicates that Device-A is able to contact a BCCF of the native wireless blockchain as denoted by Native-BC-ID for requesting BC-Onboarding-lnstructions for other devices.

[0242] At 1522, Device-B 1510 may receive the requestfrom Device-A. Device-B may accept the discovery solicitation and agree to be discovered by Device-A Device-B may also decide to ask Device-A to request BC- Onboarding-lnstructions. Device-B may send a discovery response to Device-A. This response may contain the following parameters: BC-Onboarding-lndicator: This parameter may be a binary flag. If this parameter is “TRUE”, it indicates that Device-B agrees to ask Device-A to request BC-Onboarding-lnstructions. Dev-B-ID: The identifier (e.g., 5G-GUTI, SUCI) of Device-B. Native-BC-ID: The identifier or the name of the native wireless blockchain that Device-B needs to request BC-Onboarding-lnstructions for

[0243] In an alternative embodiment to 1522, 1524, as described above (Option 1), at 1524 (Option 2) Device-B may broadcast a discovery announcement to its neighboring devices, so that it can be discovered by other devices such as Device-A. This discovery announcement may contain the following parameters: BC- Onboarding-lndicator: This parameter may be a binary flag. If this parameter is “TRUE”, it indicates that Device- B agrees to ask Device-A to request BC-Onboarding-lnstructions. Dev-B-ID: The identifier (e.g , 5G-GUTI, SUCI) of Device-A. If Device-A has maintained some BC-Onboarding-lnstructions that may be applicable to Device-B, the procedures described below as 1526, 1528, 1530, 1532, 1534 and 1536 may be skipped; instead,Device-A may instead cholse some maintained BC-Onboarding-lnstructions for Device-B and send them to Device-B at 1538.

[0244] At 1526, Device-A may receive the discovery response from Device-B (1522) or the discovery announcement from Device-B (1524). Device-A may decide to request BC-Onboarding-lnstructions for Device- B based on some local policies. An example local policy could contain a list of device identifiers, which Device- A can request BC-Onboarding-lnstructions for. Then, Device-A may send a wireless blockchain onboarding initiation request to a BCCF assuming Device-A has obtained the contact information of the BCCF (e.g., Device- A has already been onboarded to the native wireless blockchain and thus knows the BCCF). This request may contain the following parameters: Dev-A-ID: The identifier (e.g., 5G-GUTI, SUCI) of Device-A. Onboarding- Target-Dev-ID: The identifier (e.g., 5G-GUTI, SUCI) of the device, which BC-Onboarding-lnstructions will be requested for. In this case, Onboarding-Target-Dev-ID may be set to the identifier of Device-B (i.e , Dev-B-ID) and the identifier of other devices that Device-A may have already discovered and / or may have already been discovered by. Native-BC-ID: The identifier or the name of the native wireless blockchain that Device-A may receive from Device-B or determine for Device-B

[0245] At 1526, the BCCF may receive the request from Device-A. At 1528, the BCCF may forward the request to a BCGF assuming the BCCF has obtained or known the address or the identifier of the BCGF. This request may contain the following parameters: Dev-A-ID: Same as in 1526 Onboarding-Target-Dev-ID: Same as in 1526 Native-BC-ID: Same as in 1526 or the BCCF may (re)determine the target native wireless blockchain for devices in Onboarding-Target-Dev-ID. BCCF-ID: The identifier of the BCCF.

[0246] At 1530, the BCGF may receive the request from the BCCF. The BCGF may (re)determine the target native wireless blockchain for devices in Onboarding-Target-Dev-ID. The BCGF may authorize: 1) if Device-A is allowed to request BC-Onboarding-lnstructions for devices in Onboarding-Target-Dev-ID for the target native wireless blockchain; 2) if devices in Onboarding-Target-Dev-ID are allowed to receive BC-Onboarding- lnstructions; and 3) if devices in Onboarding-Target-Dev-ID are allowed to access or interact with the target native wireless blockchain as denoted by Native-BC-ID. Then, the BCGF may determine BC-Addr-Scheme and BC-Onboarding-lnstructions for each device in Onboarding-Target-Dev-ID. The BCGF may also determine a list of identifiers of other onboarding target devices, which BC-Onboarding-lnstructions may be applied to.

[0247] At 1532, the BCGF may send a wireless blockchain onboarding response to the BCCF. This response may contain Native-BC-ID, BC-Addr-Scheme, and BC-Onboarding-lnstructions as determined at 1530. This response may also contain Onboarding-Target-Dev-ID, which may include Dev-B-ID and the identifiers of other onboarding target devices as determined at 1530.

[0248] At 1534, the BCCF may receive the response from the BCGF. The BCCF may process the response (e g., add its identifier to BC-Onboarding-lnstructions, adjust some parameters as contained in BC-Onboarding- lnstructions, buffer the response for a time period, etc.).

[0249] At 1536, the BCCF may send a wireless blockchain initiation response to Device-A. This response may contain Native-BC-ID, BC-Addr-Scheme, Onboarding-Target-Dev-ID, and BC-Onboarding-lnstructions as received at 1532 and / or adjusted at 1534.

[0250] At 1538, Device-A may send a wireless blockchain onboarding notification to each devices in Onboarding-Target-Dev-ID (e g., Device-B). This notification may contain the same set of parameters as contained in the response at 1536. After receiving the notification, Device-B may extract Native-BC-ID, BC- Addr-Scheme and BC-Onboarding-lnstructions from the notification; then, Device-B may generate a blockchain address according to BC-Addr-Scheme; next, Device-B may contact the BCCF or the BCGF according to BC- Onboarding-lnstructions. If Onboarding-Target-Dev-ID from the response at 1536 contains multiple devices, Device-A may prepare and send a similar but separate wireless blockchain initiation notification for each of those devices; Device-A may prepare and broadcast a similar wireless blockchain initiation notification for multiple devices in its proximity.

[0251] After receiving the notification at 1538, Device-B may send a confirmation to the Device-A indicating the successful receipt.

[0252] FIG. 16 illustrates embodiments for a procedure for Device-B 1610 as a discoveree to initiate wireless blockchain onboarding for Device-A 1612 as a discoverer. In this case, Device-B may be discovered by Device-A. During the discovery process, Device-A may inform Device-B of its need for onboarding to the native wireless blockchain. Then, Device-B may contact a BCCF 1614 to request BC-Onboarding-lnstructions for a target native wireless blockchain for Device-A. After receiving BC-Onboarding-lnstructions from the BCCF, Device-B may forward BC-Onboarding-lnstructions to Device-A. On FIG. 16, a BCCCF within Device-B may perform all required operations on behalf of Device-B.

[0253] Embodiments described below with respect to FIG. 16 may be summarized as follows: Receive by a WTRU (Device-B) a discovery solicitation request, which may indicate the WTRUs with a second node's onboarding requirement to the native wireless blockchain (BC-Onboarding-lndicator); Send a discovery response to the second node, which may indicate the WTRU's capability in onboarding other nodes to the native wireless blockchain; Send a wireless blockchain onboarding initiation request to the third node (e.g., a BCCF), which may indicate the second node as the target node to be onboarded to the native wireless blockchain; Receive a wireless blockchain onboarding initiation response from the third node, which may indicate blockchain onboarding instructions for the second node; and Forward the wireless blockchain onboarding initiation response to the second node

[0254] At 1620, Device-A 1612 may broadcast a discovery solicitation request to its neighboring devices. This request may contain the following parameters: Native-BC-ID: The identifier or the name of the target native wireless blockchain that Device-A may want to request BC-Onboarding-lnstructions for. This parameter is optional. Dev-A-ID: The identifier (e.g., 5G-GUTI, SUCI) of Device-A. BC-Onboarding-lndicator: This parameter-M -may be a binary flag. If this parameter is “TRUE”, it indicates that Device-A needs to request BC-Onboarding- Instructions for the target native wireless blockchain.

[0255] At 1622, Device-B 1610 may receive the request from step 1. It may accept the discovery solicitation and agree to be discovered by Device-A. Device-B may also decide to request BC-Onboarding-lnstructions for Device-A. Device-B may send a discovery response to Device-A. This response may contain the following parameters: Dev-B-ID: The identifier (e.g., 5G-GUTI, SUCI) of Device-B; Native-BC-ID: The name of the target native wireless blockchain, from which Device-B may be able to request BC-Onboarding-lnstructions for Device-A. BC-Onboarding-Capability: This parameter may be a binary flag If this parameter is “TRUE”, it may indicate that Device-B is able to contact a BCCF of the target native wireless blockchain as denoted by BC- Name for requesting BC-Onboarding-lnstructions for Device-A.

[0256] If Device-B has maintained some BC-Onboarding-lnstructions that may be applicable to Device-A for the target native wireless blockchain, procedure 1624, 1626, 1628, 1630, 1632 and 1634 as described below may be skipped; instead, Device-B may just pick some maintained BC-Onboarding-lnstructions for Device-A and send them to Device-A at 1636.

[0257] At 1624, Device-B may determine to request BC-Onboarding-lnstructions for Device-A based on local policies. An example local policy could contain a list of device identifiers, which Device-B can request BC- Onboarding-lnstructions for. Then, Device-B may send a wireless blockchain onboarding initiation request to a BCCF assuming Device-B has obtained a BCCF (e.g., Device-B has already been onboarded to the target native wireless blockchain and knows the BCCF). This request may contain the following parameters: Dev-B- ID: The identifier (e.g., 5G-GUTI, SUCI) of Device-B. Onboarding-Target-Dev-ID: The identifier (e.g., 5G-GUTI, SUCI) of the device, which BC-Onboarding-lnstructions will be requested for. In this case, Onboarding-Target- Dev-ID may be set to the identifier of Device-A (i e., Dev-A-ID) and the identifier of other devices that Device- B may have already being discovered by and / or may have already discovered; Native-BC-ID: The identifier or the name of the native wireless blockchain that Device-B may receive from Device-A or determine for Device- A.

[0258] At 1626, the BCCF 1614 may receive the request from Device-B. The BCCF 1614 may forward the request to a BCGF 1616 assuming the BCCF has obtained or known the address or the identifier of the BCGF. This request may contain the following parameters: Dev-B-ID: Same as in 1624. Onboarding-Target-Dev-ID: Same as in 1624.

[0259] Native-BC-ID: Same as in a624 orthe BCCF may (re)determine the target native wireless blockchain for devices in Onboarding-Target-Dev-ID. BCCF-ID: The identifier of the BCCF.

[0260] At 1628, the BCGF may receive the request from step 5. The BCGF may (re)determine the target native wireless blockchain for devices in Onboarding-Target-Dev-ID It may authorize: 1) if Device-B is allowed to request BC-Onboarding-lnstructions for devices in Onboarding-Target-Dev-ID; 2) if devices in Onboarding- Target-Dev-ID are allowed to receive BC-Onboarding-lnstructions; and 3) if devices in Onboarding-Target-Dev-ID are allowed to access or interact with the target native wireless blockchain as denoted by Native-BC-ID. Then, the BCGF may determine BC-Addr-Scheme and BC-Onboarding-lnstructions for devices in Onboarding- Target-Dev-ID. The BCGF may also determine a list of identifiers of other onboarding target devices, which BC-Onboarding-lnstructions may be applied to.

[0261] At 1630, the BCGF may send a wireless blockchain onboarding response to the BCCF. This response may contain Native-BC-ID, BC-Addr-Scheme and BC-Onboarding-lnstructions as determined at 1628. This response may also contain Onboarding-Target-Dev-ID, which may include Dev-A-ID and the identifiers of other onboarding target devices as determined at 1628.

[0262] At 1632, the BCCF may receive the response from the BCGF. The BCCF may process the response (e g., add its identifier to BC-Onboarding-lnstructions, adjust some parameters as contained in BC-Onboarding- lnstructions, buffer the response for a time period, etc.).

[0263] At 1634, the BCCF may send a wireless blockchain initiation response to Device-B. This response may contain Native-BC-ID, BC-Addr-Scheme, Onboarding-Target-Dev-ID, and BC-Onboarding-lnstructions as received from step 6 and / or adjusted at 1632.

[0264] At 1636 Device-B may send a wireless blockchain onboarding notification to Device-A. This notification may contain the same set of parameters as contained in the response sent at 1634. After receiving the notification, Device-A may extract Native-BC-ID, BC-Addr-Scheme, and BC-Onboarding-lnstructions from the notification; then, Device-A may generate a blockchain address according to BC-Addr-Scheme; next, Device-A may contact the BCCF or the BCGF according to BC-Onboarding-lnstructions. If Onboarding-Target- Dev-ID from the response at 1634 contains multiple devices, Device-B may prepare and send a similar but separate wireless blockchain initiation notification to each of those devices; Device-A may prepare and broadcast a similar wireless blockchain initiation notification for multiple devices in its proximity.

[0265] After receiving the notification at 1636, Device-A may send a confirmation (not shown) to the Device- B indicating the successful receipt of the notification.

[0266] FIG. 17 illustrates an example procedure for Device-A to initiate wireless blockchain onboarding assisted by Device-B. In this case, Device-A could be a discoverer or discoveree. Device-A receives the address or the identifier of a BCCF from another Device-B. Then, Device-A may request BC-Onboarding- lnstructions for itself. On FIG. 17, a BCCCF within Device-A may perform all required operations on behalf of Device-A.

[0267] In embodiments Device-A 1712 may use option 1 (1720, 1722), option 2 (1724), or option 3 (1726, 1728) to get the address or the identifier of a BCCF 1714 from another Device-B 1710

[0268] At 1720, Device-A may broadcast a discovery solicitation request to its neighboring devices. This request may contain the following parameters: Dev-A-ID: The identifier (e.g., 5G-GUTI, SUCI) of Device-A. Native-BC-ID: The identifier or the name of the target native wireless blockchain that Device-A likes to request BC-Onboarding-lnstructions for itself BC-Onboarding-lndicator: This parameter may be a binary flag. If thisparameter is “TRUE”, it may indicate that Device-A needs a BCCF of the native wireless blockchain as denoted by BC-Name to request BC-Onboarding-lnstructions from it.

[0269] At 1722, Device-B may receive the request made at 1720. Device-B may accept the discovery solicitation and agree to be discovered by Device-A. Device-B may send a discovery response to Device-A. This response may contain the following parameters: Dev-B-ID: The identifier (e.g., 5G-GUTI, SUCI) of Device- B. Native-BC-ID: The identifier or the name of target native wireless blockchain that the BCCF as denoted by BCCF-ID controls. BCCF-ID: The identifier of the BCCF belonging to and / or controlling the target native wireless blockchain as denoted by Native-BC-ID. This parameter may not be contained if Device-B does not have information about the BCCF.

[0270] In Option 2 (an alternative approach to 1720, 1722), at 1724, Device-B may broadcast a discovery announcement to its neighboring devices, so that it can be discovered by other devices such as Device-A. This discovery announcement may contain the following parameters: Dev-B-ID: Same as 1722 Native-BC-ID: Same as 1722. BCCF-ID: Same as 1722.

[0271] In Option 3 (a further alternative approach to 1720, 1722) at 1726, Device-B may send a discovery solicitation to Device-A This discovery solicitation may contain the following parameters: Dev-B-ID: Same as 1722. Native-BC-ID: Same as 1722. BCCF-ID: Same as 1722. At 1728, Device-A may send a discovery response to Device-B.

[0272] At 1732, Device-A may determine to request BC-Onboarding-lnstructions for itself. Then, Device-A may send a wireless blockchain onboarding initiation request to the BCCF 1714. This request may contain the following parameters: Dev-A-ID: The identifier (e.g., 5G-GUTI, SUCI) of Device-A. Native-BC-ID: The identifier or the name of the native wireless blockchain that Device-A likes to request BC-Onboarding-lnstructions for itself. Onboarding-Target-Dev-ID: The identifier (e.g., 5G-GUTI, SUCI) of the device, which BC-Onboarding- lnstructions will be requested for. In this case, Onboarding-Target-Dev-ID may be set to the identifier of Device- A (i.e., Dev-A-ID).

[0273] At 1732: The BCCF may receive the request from Device-A. The BCCF may forward the request to a BCGF 1716 assuming the BCCF has obtained or known the address or the identifier of the BCGF. This request may contain the following parameters: Dev-A-ID: Same as 1730. Native-BC-ID: Same as 1730 or the BCCF may (re)determine the target native wireless blockchain for each device in Onboarding-Target-Dev-ID. Onboarding-Target-Dev-ID: Same as 1730. BCCF-ID: The identifier of the BCCF.

[0274] At 1734, the BCGF may receive the request from the BCCF. The BCGF may authorize whether Device-A is allowed to request and receive BC-Onboarding-lnstructions for the target native wireless blockchain. Then, the BCGF may determine BC-Addr-Scheme and BC-Onboarding-lnstructions for Device-A. The BCGF may (re)determine the target native wireless blockchain for each device in Onboarding-T arget-Dev- ID. The BCGF may also determine a list of identifiers of other onboarding target devices, which BC-Onboarding- lnstructions may be applied to

[0275] At 1736, the BCGF may send a wireless blockchain onboarding initiation response to the BCCF. This response may contain Native-BC-ID, BC-Addr-Scheme and BC-Onboarding-lnstructions as determined in step 8. This response may also contain Onboarding-Target-Dev-ID, which may include Dev-A-IDs

[0276] At 1738: The BCCF may receive the response made at 1736. The BCCF may process the response (e g., add its identifier to BC-Onboarding-lnstructions, adjust some parameters as contained in BC-Onboarding- lnstructions, buffer the response for a time period, etc.).

[0277] At 1740: the BCCF may send a wireless blockchain initiation response to Device-A. This response may contain Native-BC-ID, BC-Addr-Scheme, Onboarding-Target-Dev-ID, and BC-Onboarding-lnstructions as received from the BCGF at 1773 and / or adjusted at 1738. After receiving this response, Device-A may extract Native-BC-ID, BC-Addr-Scheme and BC-Onboarding-lnstructions from the notification; then, Device-A may generate a blockchain address according to BC-Addr-Scheme; next, Device-A may contact the BCCF or the BCGF according to BC-Onboarding-lnstructions to access the target native wireless blockchain as denoted by Native-BC-ID.

[0278] The above-discussed embodiments may be implemented in 3GPP system architecture (e.g., 5GS) in following ways as illustrated in embodiments describe with respect to FIG. 18. Device / BCCCF 1810 may be implemented as a part of 3GPP WTRU. RAN 1812 is as shown. BCCF 1820 may be a new 3GPP network function or BCCF can be implemented as a part of AMF 1816. BCGF 1822 may be a new 3GPP network function or BCGF can be implemented as a part of AUSF 1816. BCAF 1818 may be implemented as 3GPP AF. Wireless blockchain onboarding can be initiated as a result of or as a part of 3GPP procedures and / or events (e.g., 3GPP WTRU registration, new analytics results about WTRU such as uplink traffic statistics, etc.).

[0279] Embodiments for Wireless Blockchain Onboarding Initiation via 3GPP Registration are discussed herein. FIG 19 illustrates an example process for leveraging a 3GPP Registration Accept message to initiate wireless blockchain onboarding for a WTRU. In embodiments, WTRU registration and wireless blockchain onboarding initiation are jointed performed. AMF in this procedure may perform some functionalities of BCGF (e g., determine BC-Onboarding-lnstructions) and also may perform some functionalities of BCCF (e.g., send BC-Onboarding-lnstructions to WTRU). FIG. 19 may be summarized as follows: Prepare by a WTRU a first information element that indicates the WTRU’s availability to be a blockchain node (BC-lndicator); Send a first request (e.g., a registration request) to a first network function (e.g., AMF); The first request may contain a first WTRU identifier and the first information element. Receive the first response (e.g , a registration accept) from the first network function; and the first response may contain the identifier of a second network function (e.g., a blockchain control function - BCCF), the blockchain address generation scheme, and blockchain onboarding instructions; Store the information contained in the first response.

[0280] With reference to FIG. 19, at 1920, the WTRU 1910 may send a Registration Request (or a Registration Update) message to its serving AMF 1912. This message may additionally contain BC-lndicator, which may indicate: 1) the WTRU wants to be a BCN; or 2) the WTRU wants to be a BSN. If the WTRU wasonboarded to a native wireless blockchain previously, BC-lndicator may also indicate its previous blockchain address as a result of previous onboarding (i.e., WTRU-BC-Addr) and the name or the identifier of the native wireless blockchain previously onboarded to (i.e., Previous-Native-BC-ID). The identifier of WTRU (i.e., WTRU- ID) contained in the registration request (1920) may be its SUCI or 5G-GUTI.

[0281] The WTRU may decide or be triggered to include a BC-lndicator based on one or multiple of the following conditions: A local application on the WTRU triggers the WTRU to do a Registration Update and contain a BC-lndicator in the Registration Update message This may occur when the device enters certain area (e.g., a new service area, a new registration area); when the device receives new Steering of Roaming (SoR) information from UDM; or when the device receives a new UPU container from UDM. When the trust index of the device received from network is below a threshold.

[0282] At 1920, if the WTRU knows the target native wireless blockchain, the WTRU may contain its identifier (i.e., Native-BC-ID). At 1920, the WTRU may instead perform existing 3GPP Registration Request or Registration Update, and may not indicate any blockchain-related information. The AMF may receive Registration Request (or Registration Update) message from 1920 and may perform regular WTRU registration including primary authentication If the primary authentication failed, the procedure described below (1922, 1924, 1926, 1928, 1930) will not be needed; otherwise, the AMF 1920 may continue 1922.

[0283] At 1922, there may be two cases as follows: In a first case, if the primary authentication passes and BC-lndicator was included in Registration Request (or Registration Update) message, the AMF may contact a UDM 1914 (or a PCF) to check if the WTRU is allowed to join and use the target native wireless blockchain and in which role (e.g., BCN or BSN), for example, according to its subscription data. In this case, the AMF may send WTRU-ID, Native-BC-ID, and BC-lndicator to the UDM (or the PCF). In a second case, if the primary authentication passes and BC-lndicator was not included in at 1920 , the AMF may still contact the UDM (or the PCF) to check if it is needed to initiate the WTRU to onboard to a target native wireless blockchain In this case, the AMF may prepare a BC-lndicator and send it as well as WTRU-ID to the UDM (or the PCF).

[0284] At 1924, the UDM (or the PCF) may check the WTRU’s subscription data to determine: 1) If the WTRU is allowed to use / participate the target native wireless blockchain as a BCN or a BSN (for the first case, above); or 2) if there is a target native wireless blockchain (its identifier is Native-BC-ID) that the WTRU can use / participate as a BCN or a BSN (for the second case, above). Then, the UDM (or the PCF) may send a response to the AMF indicating whether the WTRU is allowed to use / participate native wireless blockchain and in which role (e.g., BCN o BSN). For both cases with respect to 1922, the UDM (or the PCF) may (re)determine the target native wireless blockchain (Native-BC-ID) for the WTRU. When the WTRU is allowed to use the target native wireless blockchain (indicated by the WTRU at 1920 or determined by the UDM (or the PCF) at 1924), it means the WTRU will be a BCN. When the WTRU is allowed to participate in the target native wireless blockchain, the WTRU will be a BSN If the WTRU is not allowed to use / participate the target native wireless blockchain either as a BCN or a BSN, the UDM will indicate it at 1924 and procedures described at '926, 1928 and 19306 will not be needed.

[0285] In embodiments, interactions between the AMF and the UDM at 1922 and 1924 may be replaced with interaction between the AMF and a PCF (i.e., replace the UDM at 1922 and 1924 with the PCF). In other words, the AMF may check if there is any blockchain related policies for the WTRU from the PCF and may use those polices to determine if the WTRU is allowed to use / participate the target native wireless blockchain as a BCN or a BSN.

[0286] In step 4, if the WTRU is allowed to use / participate native wireless blockchain, the AMF may select a BCCF for the WTRU. The AMF may search the BCCF from an NRF. Alternatively, the BCCF may have been included as a part of the WTRU’s subscription data; in this case, the identifier of the BCCF will be sent from the UDM (or the PCF) to the AMF in step 3 and thus step 4 may be skipped. BCCF selection criteria as discussed in step 2 of FIG. 12 may be used here by the AMF.

[0287] If there was no BCCF being indicated in step 3 or selected in step 4, steps 5 and 6 may be skipped.

[0288] In step 5, the AMF may determine Native-BC-ID, BC-Addr-Scheme, and BC-Onboarding- Instructions for WTRU, especially if the AMF has been configured with them. If the AMF cannot determine those parameters, it may contact the selected BCCF, which may determine Native-BC-ID, BC-Addr-Scheme, and BC-Onboarding-Scheme and send them to the AMF. Alternatively, if the AMF cannot determine those parameters, it may contact an AUSF (or a PCF), which may implement BCGF functionalities and may determine them and send them to the AMF. Native-BC-ID, BC-Addr-Scheme, and BC-Onboarding-lnstructions may have been stored in the UDM as a part of the WTRU’s subscription data; in this case, those parameters may be sent from the UDM to the AMF in step 3 and thus step 5 may be skipped. If step 3 is from a PCF to the AMF, the PCF may send Native-BC-ID, BC-Addr-Scheme, and BC-Onboarding-lnstructions to the AMF; thus, step 5 may be skipped.

[0289] As a part of step 5, the AMF may generate an authorized blockchain address for the WTRU (Authorized-WTRU-BC-Addr); the AMF may also determine “WTRU-BC-lnit-Config” for the WTRU; “WTRU- BC-I nit-Config” is described herein below. The AMF may get both parameters from the AUSF that successfully authorized the WTRU’s Registration Request (or Registration Update).

[0290] In step 6, if the AMF selected the BCCF in step 4, it may send the selected BCCF (BCCF-ID) to the UDM, which will store BCCF-ID as a part of the WTRU’s subscription data for future use. Otherwise, if step 4 was not executed or no BCCF was selected in step 4, this step will be skipped. If Native-BC-ID, BC-Addr- Scheme, and BC-Onboarding-lnstructions was determined by the AMF (or received by the AMF from a PCF), the AMF may send them to the UDM (or a PCF) in step 5. If the AMF determined WTRU-BC-lnit-Config and Authorized-WTRU-BC-Addr in step 5, both parameters may be contained in step 6.

[0291] In step 7, the AMF may send a Registration Accept message to the WTRU. In addition to containing existing registration-accept-related parameters, the Registration Accept message may contain a few new parameters such as BCCF-ID, Native-BC-ID, BC-Addr-Scheme, WTRU-BC-lnit-Config, and BC-Onboarding- lnstructions. If step 5 was skipped, BC-Onboarding-lnstructions and BC-Addr-Scheme may not be included inRegistration Accept message, which instead may indicate an error “No BCCF available". If the AMF determined WTRU-BC-lnit-Config and Authorized- WTRU-BC-Addr in step 5, both parameters may be contained in step 7.

[0292] After step 7, the WTRU may store BC-Onboarding-lnstructions and other parameters as contained in the message received from step 7; then, the WTRU may generate its blockchain address according to BC- Addr-Scheme designated by step 7; after that, the WTRU may contact the BCCF as denoted by BC- Onboarding-Addr as a part of blockchain onboarding instructions to start wireless blockchain onboarding process, for example, by sending a wireless blockchain onboarding request to the BCCF, as described herein, below regarding Wireless Blockchain Onboarding. The information that is received by the WTRU’s modem in step 7 may be sent to a device application that is hosted on the WTRU; the information may be sent by invoking an API or AT Command; the information by then may be used by the device application to initiate contacting the BCCF for wireless blockchain onboarding If step 7 contains WTRU-BC-Final-Config (or WTRU-BC-lnit- Config) and Authorized-WTRU-BC-Addr, WTRU may start to interact with the target native wireless blockchain using Authorized-WTRU-BC-Addr, according to what WTRU-BC-Final-Config (or WTRU-BC-lnit-Config) describes.

[0293] FIG. 20 illustrates another procedure for leveraging 3GPP Registration procedure to additionally notify a registered WTRU of the identifier or the address of a selected BCCF (BCCF-ID). Then, the WTRU may contact the selected BCCF for retrieving Native-BC-ID, BC-Addr-Scheme and BC-Onboarding-lnstructions.

[0294] FIG. 20 may be summarized as follows: Prepare by a WTRU a first information element on indicating the WTRU’s availability to be a blockchain node (BC-lndicator); Send a first request (e.g., a registration request) to a first network function (e.g., AMF); The first request may contain a first WTRU identifier and the first information element; Receive the first response (e.g., a registration accept) from the first network function; The first response may contain the identifier of a second network function (e.g., a blockchain control function - BCCF); Send a second request to the second network function; the second request may be relayed from the first network function to the second network function; The second request may contain the first WTRU identifier and an indication for requesting a blockchain address generation scheme and blockchain onboarding instructions; Receive a second response from the second network function; The second response may contain the identifier of the second network function, the blockchain address generation scheme, and blockchain onboarding instructions; The second response may be relayed from the first network function to WTRU; and Store the information contained in the second response.

[0295] Details of embodiments illustrated by FIG. 20 are described below.

[0296] The registration at 2020 is similar to that described at 1920 of FIG. 19. The checking with the UDM 2014 at 2022 is similar to that described at 1922 of FIG. 19 The response at 2024 similar to that at 1924 of FIG. 19. The choosing at 2026 is similar that described at 1926 of FIG. 19.

[0297] At 2028 the AMF 2012 may send a Registration Accept message to the WTRU 2010. This message may contain the identifier of selected BCCF 2016 (i.e., BCCF-ID) as a hint to the WTRU to be ready for receivinga new message from at 2038 or the WTRU may actively retrieve “Wireless Blockchain Onboarding Initiation Request” from the BCCF via step 8. In other words, after receiving BCCF-ID, the WTRU may know that the BCCF may directly send a wireless blockchain onboarding initiation request (i.e., the request at 2038) to itself any time after 2028. While waiting for the request at 2038, the WTRU may actively or additionally send a request at 2034 to the BCCF to retrieve Native-BC-ID, BC-Addr-Scheme, and BC-Onboarding-lnstructions; then, the BCCF will send a response at 2036 to the WTRU.

[0298] If the primary authentication failed, the procedures described with respect to 2030, 20322034, 2036, 2038 are not needed.

[0299] At 2030, the AMF may send a blockchain indication including WTRU-ID and BC-lndicator to the selected BCCF. BC-lndicator may indicate if the WTRU wants to be a BCN or a BSN.

[0300] At 2032, the BCCF may determine, Native-BC-ID, BC-Addr-Scheme and BC-Onboarding- lnstructions for the WTRU. Alternatively, the procedure at 2032 may take place right after 2034. Alternatively, the BCCF may ask an AUSF (or a PCF) implementing BCGF functionalities to determine Native-BC-ID, BC- Addr-Scheme and BC-Onboarding-lnstructions for the WTRU; then the AUSF (or the PCF) may send the determined Native-BC-ID, BC-Addr-Scheme, and BC-Onboarding-lnstructions to the BCCF.

[0301] At 2032, the BCCF may also generate an authorized blockchain address for the WTRU (Authorized- WTRU-BC-Addr); the BCCF may also determine “WTRU-BC-Final-Config" for the WTRU; “WTRU-BC-Final- Config” is described herein, below. The BCCF may get both parameters from the AUSF that successfully authorized the WTRU’s Registration Request (or Registration Update).

[0302] At 2034, the WTRU may send a request to the BCCF to retrieve Native-BC-ID, BC-Addr-Scheme and BC-Onboarding-lnstructions This request may be sent as an NAS message and to be relayed by the AMF to the BCCF.

[0303] At 2036, the BCCF may send a response containing Native-BC-ID, BC-Addr-Scheme, and BC- Onboarding-lnstructions to the WTRU. This response may be sent as an NAS message and to be related by the AMF to the WTRU. This response may contain WTRU-BC-Final-Config and Authorized-WTRU-BC-Addr if both parameters were determined at 2032.

[0304] If the procedures of 2034 and 2036 took place, 2038 may be skipped. Alternatively, even if these two procedures have been executed, the BCCF still can send a request at 2038 to the WTRU, especially when there are new BC-Onboarding-lnstructions being determined by the BCCF for the WTRU.

[0305] At 2038, the BCCF may directly send Native-BC-ID, BC-Addr-Scheme and BC-Onboarding- lnstructions to WTRU. Process 2028 may occur right before 2034; in this case, 2034 and 2036 are not needed. The request at 2038 also can be used by the BCCF to send new BC-Onboarding-lnstructions to the WTRU, even if steps 2034 and 2038 were executed by the WTRU that has not been onboarded yet. This request at 2038 may be sent as an NAS message and to be relayed by the AMF to the WTRU. The request at 2038 may contain WTRU-BC-Final-Config and Authorized-WTRU-BC-Addr if both parameters were determined at 2032.

[0306] After the request at 2038, the WTRU may send a confirmation to the BCCF indicating the successful receipt of the request.

[0307] After 2036 (or 2038, the WTRU may store BC-Onboarding-lnstructions and other parameters as contained in the message received at 2036 (or 2038); then, the WTRU may generate its blockchain address according to BC-Addr-Scheme designated at 2036 (or 2038); after that, the WTRU may contact the BCCF as denoted by BC-Onboarding-Addr as a part of blockchain onboarding instructions to start wireless blockchain onboarding process, for example, by sending a wireless blockchain onboarding request to the BCCF, as described herein, below regarding Wireless Blockchain Onboarding. The information that is received by the WTRU’s modem in at 2036 (or 2038) may be sent to a device application that is hosted on the WTRU; the information may be sent by invoking an API or AT Command; the information by then may be used by the device application to initiate contacting the BCCF for wireless blockchain onboarding. If the response at 2036 (or the request at 2038 ) contains WTRU-BC-Final-Config (or WTRU-BC-lnit-Config) and Authorized- WTRU- BC-Addr, WTRU may start to interact with the target native wireless blockchain using Authorized-WTRU-BC- Addr, according to what WTRU-BC-Final-Config (or WTRU-BC-lnit-Config) describes.

[0308] FIG. 21 illustrates another example procedure for leveraging 3GPP Registration procedure where an AMF first performs 3GPP primary authentication for a WTRU. If the primary authentication is successful, the AMF may notify the registered WTRU of a BCCF which the registered WTRU can contact for wireless blockchain onboarding.

[0309] Request 2120 is similar to 2020 of FIG. 20. The choosing at 2122 is similar to 2026 of FIG. 20 If primary authentication failed, 2122 may not be needed. The accept at 2124 is similar to that at 2028 of FIG. 20.

[0310] If primary authentication failed, the processes described with respect to 2126, 2128, 2130, 2132, 2134 and 2136 may not be needed.

[0311] The sending at 2126 is similar to that at 2030 of FIG 20. At 2128, the BCCF may contact a UDM to check if the WTRU is allowed to use / participate a target native wireless blockchain as a BCN or as a BSN, for example, according to the WTRU’s subscription data. The BCCF may send WTRU-ID and BC-lndicator to the UDM. Then, the UDM checks the WTRU’s subscription data and sends a response to the BCCF indicating whether the WTRU is allowed to use / participate the target native wireless blockchain and in which role (BCN o BSN). The checking at 2128 is similar to 2022, 2024 of FIG. 20.

[0312] The processed for 2130 ,2132, 2134, 2136 are similar to those described at 2032, 2034, 2036 and 2038 of FIG. 20.

[0313] After the request at 2136, the WTRU may send a confirmation to the BCCF indicating the successful receipt of the request.

[0314] After the response at 2134 (or the request 12136), the WTRU may store BC-Onboarding-lnstructions and other parameters as contained in the message received from 2134 (or 2136); then, the WTRU maygenerate its blockchain address according to BC-Addr-Scheme designated by 2134 (or 2136); after that, the WTRU may contact the BCCF as denoted by BC-Onboarding-Addr as a part of blockchain onboarding instructions to start wireless blockchain onboarding process, for example, by sending a wireless blockchain onboarding request to the BCCF, as described herein, below regarding Wireless Blockchain Onboarding. The information that is received by the WTRU’s modem at 2134 (or 2136) may be sent to a device application that is hosted on the WTRU; the information may be sent by invoking an API or AT Command; the information by then may be used by the device application to initiate contacting the BCCF for wireless blockchain onboarding. If the response at 2134 (or the request at 2136) contains WTRU-BC-Final-Config (or WTRU-BC-lnit-Config) and Authorized- WTRU-BC-Addr, WTRU may start to interact with the target native wireless blockchain using Authorized- WTRU-BC-Addr, according to what WTRU-BC-Final-Config (or WTRU-BC-lnit-Config) describes.

[0315] Wireless Blockchain Onboarding Initiation via 3GPP NWDAF is described herein.

[0316] FIG. 22 illustrates an example procedure for leveraging a NWDAF to initiate wireless blockchain onboarding for a WTRU. For example, if the WTRU starts exhibiting abnormal behavior from its data traffic analytics, the network may need to onboard the WTRU to a target native wireless blockchain to accountably monitor and record the WTRU’s data traffic behavior. Other 3GPP network functions could use the same procedure (especially steps 2-6) to initiate wireless blockchain onboarding for the WTRU.

[0317] At 2220, a BCCF 2212 may send a request to the NWDAF 2214 for subscribing to some analytics results or subscribed events (as denoted by Analytics-ID) about the WTRU, based on which the BCCF may determine to send wireless blockchain onboarding initiation to the WTRU 2210. As an example, Analytics-ID may be about uplink traffic statistics about the WTRU. The BCCF may use such analytics results to determine any potential risks from the WTRU and thus can actively request the WTRU to be onboarded to a target native wireless blockchain to log its context and usage data. This request may contain the identifier of WTRU (i.e., WTRU-ID), the identifier of the BCCF (BCCF-ID), and Analytics-ID The BCCF may have found the NWDAF from an NRF.

[0318] At 2222, when the subscribed event occurs, the NWDAF may send a notification to the BCCF containing the analytics results corresponding to Analytics-ID.

[0319] At 2224, the BCCF may receive the notification, based on which it may determine whether the WTRU needs to start wireless blockchain onboarding. For example, if the WTRU uplink traffic statistics shows some abnormal behavior, the BCCF may decide to initiate to onboard the WTRU to a target native wireless blockchain (Native-BC-ID) that may be determined by the BCCF, so that the WTRU will log its uplink behavior to the target native wireless blockchain to enable accountable monitoring of the WTRU’s uplink behavior. If the BCCF decides there is no need to for the WTRU to start wireless blockchain onboarding, the following procedures 2226, 2228 and 2230 may be skipped.

[0320] The checking with the UDM at 2226 is similar to 2128 of FIG. 21.

[0321] The determining at 2228 is similar to that at 2130 of FIG. 21 As a part of this process, the BCCF may generate an authorized blockchain address for the WTRU (Authorized-WTRU-BC-Addr); the BCCF may also determine “WTRU-BC-Final-Config” for the WTRU; “WTRU-BC-Final-Config” is described herein, below. The BCCF may get both parameters from the AUSF that performed a successful primary authentication for the WTRU

[0322] The request at 2230 is similar to that at 2136 of FIG. 21. The request may contain WTRU-BC-Final- Config and Authorized-WTRU-BC-Addr if both parameters were determined at 2228.

[0323] After the request at 2230, the WTRU may send a confirmation to the BCCF indicating the successful receipt of the request.

[0324] After the request at 2230, the WTRU may store BC-Onboarding-lnstructions and other parameters as contained in the message received at 2230; then, the WTRU may generate its blockchain address according to BC-Addr-Scheme designated by the request at 2230; after that, the WTRU may contact the BCCF as denoted by BC-Onboarding-Addr as a part of blockchain onboarding instructions to start wireless blockchain onboarding process, for example, by sending a wireless blockchain onboarding request to the BCCF, as described herein, below regarding Wireless Blockchain Onboarding. The information that is received by the WTRU’s modem at 2230 may be sent to a device application that is hosted on the WTRU; the information may be sent by invoking an API or AT Command; the information by then may be used by the device application to initiate contacting the BCCF for wireless blockchain onboarding. If the request at 2230 contains WTRU-BC- Final-Config (or WTRU-BC-lnit-Config) and Authorized-WTRU-BC-Addr, WTRU may start to interact with the target native wireless blockchain using Authorized-WTRU-BC-Addr, according to what WTRU-BC-Final-Config (or WTRU-BC-lnit-Config) describes.

[0325] Embodiments for Wireless Blockchain Onboarding Initiation via 3GPP AF is described herein.

[0326] FIG. 23 illustrates an example procedure for an AF 2314 to initiate wireless blockchain onboarding for a WTRU 2310.

[0327] At 2320, a BCCF 2312 may register itself to an NRF. The selection at 2322 is similar to that at 1320 of FIG. 13. The AF with an identifier AF-ID may select one or multiple WTRUs (WTRU-ID) for them to start wireless blockchain onboarding.

[0328] The discovery at 2324 is similar to that at 1322 of FIG 13. The AF may select a BCCF from an NRF or via other approaches. The AF may interact with the NRF to find the BCCF, via an NEF especially when the AF is not in the same trust domain of 3GPP core network. If a UDM maintains the contact information of the BCCF, the AF may find the BCCF from the UDM via an NEF. If the BCCF is implemented as a part of an AMF, the AF may get the contact information of the BCCF from the AMF, via an NEF.

[0329] The request t 2326 is similar to that at 1324 of FIG. 13. The AF may send a wireless blockchain onboarding initiation request to the BCCF; this request may be relayed by an NEF, especially if the BCCF is co-located with an AMF and / or the AF is outside of the trust domain of 3GPP core network. This request maycontain the identifier of a target native wireless blockchain (Native-BC-ID) for the WTRU, WTRU-ID, and ARID.

[0330] The checking at 2328 is similar to that at 2226 of FIG. 22. The determining at 2330 is similar to that at 2228 of FIG. 22 The request at 2332 is similar to that at 2228 of FIG. 22. The message at 2332 may also contain the identifier of the AF (i.e. , AF-ID). The message at 2232 may be transmitted via an NAS message and be relayed by the WTRUs serving AMF.

[0331] After the request at 2332, the WTRU may send a confirmation to the BCCF indicating the successful receipt of the request.

[0332] The response at 2334 is similar to that at 1336 of FIG 13. The BCCF may send a response to the AF. If the BCCF determined the target native wireless blockchain (Native-BC-ID) for the WTRU in at 2330, this response may contain Native-BC-ID. This response may contain WTRU-ID and other parameters as sent at 2332 from the BCCF to the WTRU.

[0333] After the request at 2332, the WTRU may store BC-Onboarding-lnstructions and other parameters as contained in the message received from 2332; then, the WTRU may generate its blockchain address according to BC-Addr-Scheme designated by the request at 2332; after that, the WTRU may contact the BCCF as denoted by BC-Onboarding-Addr as a part of blockchain onboarding instructions to start wireless blockchain onboarding process, for example, by sending a wireless blockchain onboarding request to the BCCF, as described herein below regarding Wireless Blockchain Onboarding. The information that is received by the WTRU’s modem a t2332 may be sent to a device application that is hosted on the WTRU; the information may be sent by invoking an API or AT Command; the information by then may be used by the device application to initiate contacting the BCCF for wireless blockchain onboarding. If the request at 2332 contains WTRU-BC- Final-Config (or WTRU-BC-lnit-Config) and Authorized- WTRU-BC-Addr, WTRU may start to interact with the target native wireless blockchain using Authorized- WTRU-BC-Addr, according to what WTRU-BC-Final-Config (or WTRU-BC-lnit-Config) described.

[0334] Embodiments for Wireless Blockchain Onboarding Procedures are discussed herein. Design principles of the embodiments described herein include: 1) only authorized or permissioned blockchain clients or devices can have blockchain address(es); 2) device blockchain address needs to be authenticated and governed by native wireless blockchain and / or the wireless system that integrates native wireless blockchain; and 3) devices need to be provisioned with blockchain system configuration information as a part of wireless blockchain onboarding. Benefits of the embodiments described herein include: 1) able to detect transactions from unauthorized blockchain clients and prevent them from being propagated in a native wireless blockchain, which reduces propagation overhead and leads to improved system performance of native wireless blockchain e.g., ability to support more BCNs and process more blockchain transactions); and 2) avoid unauthorized blockchain clients and potential attacks from them, which leads to improved system security of native wireless blockchain.

[0335] The logical entities discussed include LAF, BCRF, and BCEF. The logical entities introduced herein include Device, BCCF, BCGF, and BCAF. BCCF may be implemented as LAF. BCGF may be implemented as BCRF. Alternatively, BCGF can be defined as a new network function. Device may be implemented as BCEF within WTRU. BCAF may be implemented as a new entity Blockchain Application Function (BCAF).

[0336] Alternatively, BCCF may be implemented as distributed LAF. BCGF may be implemented as centralized LAF. Alternatively, BCGF may be defined as a new network function. Device may be implemented as BCEF within WTRU. BCAF may be implemented as a new entity BCAF.

[0337] Wireless Blockchain Onboarding with BCGF for Device Blockchain Address Authentication is described herein.

[0338] Since native wireless blockchain is a permissioned blockchain system, both BCNs and BSNs of native wireless blockchain need to be managed and governed. It is proposed in this disclosure that blockchain addresses of either BCNs or BSNs need to be authenticated as a part of wireless blockchain onboarding. For example, when a device decides to have itself to be onboarded to a native wireless blockchain, the device needs to present its blockchain address to a BCCF. The BCCF will request a BCGF to authenticate the device blockchain address. After the device blockchain address is authenticated, the BCGF and / or the BCCF may generate a blockchain address signature and may determine blockchain configuration information for the device. Only after its blockchain address is authenticated, the device can start to use and interact with the native wireless blockchain according to what blockchain configuration information specifies

[0339] FIG. 24 illustrates an example procedure for wireless blockchain onboarding with a BCGF for authenticating device blockchain address. In this procedure, there are four logical entities: Device, which may be a WTRU, (with a BCCCF) that will present its blockchain address (Dev-BC-Addr) to BCCF / BCGF in a target native wireless blockchain for authentication. A BCGF that is responsible for authenticating Device’s blockchain address. A BCCF that may perform: 1) to receive Dev-BC-Addr from the Device and pass it to the BCGF; 2) to generate a blockchain onboarding record; and 3) to determine and send blockchain configuration information to the Device. A BCSF (or multiple BCSFs) through which the BCCF may: 1) send the list of authenticated device blockchain addresses to a BCSF so that the BCSF can perform access control in the user plane of the target native wireless blockchain (e.g., approve transactions from an authorized blockchain address, reject transactions from unauthorized blockchain address); and 2) send the blockchain onboarding record to a BCSF so that the BCSF can store it to the target native wireless blockchain (or to a different native wireless blockchain)

[0340] In this procedure, it is assumed that the BCCF knows the BCGF; for example, the BCCF may have been configured with the BCGF; in another example, the BCCF may have discovered the BCGF from a repository (e.g., an NRF in the core network). It is also assumed that the Device has obtained or has been provided with the BCCF.

[0341] At 2420, the Device 2410 may generate its blockchain address (Dev-BC-Addr), which may be generated according to a blockchain address generation function Faddr: Dev-BC-Addr = Faddr (KBCGF), where KBCGF is the blockchain security key that the Device has derived locally; alternatively, Dev-BC-Addr may be calculated as Dev-BC-Addr = Fad* (KBCCF). The Device may have actively retrieved the function Faddrfrom the core network before 2420 or passively received the function Faddr from the core network before 2420; Faddr may correspond to a blockchain address scheme (BC-Addr-Scheme). As an example, KBCGF or KBCCF may be used first to generate a blockchain private key, which will be used to derive a blockchain public key; then, Dev- BC-Addr is generated from the blockchain public key. Faddr may be one or multiple hashing functions, which may have been standardized, specified as a part of device subscription data stored in wireless systems such as in a UDM, and / or dynamically configured to the Device by core network.

[0342] The generation at 2420 may be triggered by different events or scenarios including wherein the Device itself determines to log its data to a native wireless blockchain to be shared with other devices or applications. Thus, the Device first needs to generate a blockchain address and then onboard to the native wireless blockchain. In embodiments, the native wireless blockchain has sent a request to the Device to instruct the Device to generate its blockchain address and onboard to the native wireless blockchain, for instance, using the procedures described herein above.

[0343] As a part of 3GPP WTRU Registration, the Serving AMF may request the registered Device / WTRU to generate a blockchain address and onboard to the native wireless blockchain.

[0344] At 2422, the Device may send a wireless blockchain onboarding request to the BCCF 2412 assuming the Device has obtained or been configured with the address / identifier of the BCCF (BCCF-ID). This request may be sent to BCCF via 3GPP control plane (e.g., using an NAS message) or user plane (e.g., over a PDU session). This request may contain: The identifier of the Device (i.e., Dev-ID). Dev-ID may be a subscription concealed identifier (SUCI) or a 5G globally unique temporary identifier (5G-GUTI) The Device’s blockchain address (i.e , Dev-BC-Addr). The blockchain node type of the Device (i.e., Dev-BC-Type). Dev-BC- Type may indicate if Device is a BCN or a BSN. A public key of the Device (Dev-Public-Key). The identifier of the target native wireless blockchain (Native-BC-ID) that the Device will be onboarded to. BC-Addr-Scheme or Faddr: Indicate how Dev-BC-Addr was generated at 2420 without disclosing any private security keys (e.g., KBCGF, KBCGF).

[0345] At 2424, the BCCF may receive the wireless blockchain onboarding request from the Device It may need to authenticate it especially when the onboarding request was fully initiated by the Device; for this purpose, the BCCF may send Dev-ID to the core network (e.g., UDM, PCF. AUSF), which will check and decide if the Device is allowed to be onboarded to the target native wireless blockchain (e.g., based on the Device’s subscription data and / or any policies related to native wireless blockchains); then the core network may send a response to the BCCF indicating if this request was approved or not. Alternatively, the BCCF itself may be able to decide if this onboarding request can be approved: 1) for example, if the target native wireless blockchain can accommodate more BCNs or BSNs, this request can be approved; 2) in another example, theBCCF may have retrieved and buffered the Device’s subscription data and / or relevant policies locally from the core network (e.g., UDM, PDF, AUSF), based on which the BCCF may decide if this onboarding request can be approved. Dev-BC-Type may be utilized in authenticating the wireless blockchain onboarding request; for example, the BCCF may approve onboarding requests from BCNs while limiting or declining requests from BSNs; in another example, the BCCF may approve an onboarding request for becoming a BSN but the Device will only act as a BCN (not the requested BSN) for instance, if the Device is found to be resource-constrained.

[0346] At 2426, this is an alternative 2424. The BCCF may simply forward the wireless blockchain onboarding request to the BCGF assuming the BCCF has discovered the BCGF 2414. The BCGF may perform similar operations as the BCCF did in step3a to decide if this request can be approved or not; then, the BCGF may send a response to the BCCF indicating if this request was approved or not.

[0347] If the result from 2424 or 2426 is that the wireless blockchain onboarding request was not approved, the procedures described with respect to FIG. 24, 2428 to 2442 may be skipped and the BCCF may simply send a response at 2444 to the Device indicating that the wireless blockchain onboarding request was not approved and the procedures at 2446 ad 2448 may be skipped.

[0348] At 2428, the BCCF may send a device blockchain address authentication request to the BCGF assuming BCCF has obtained the identifier or the address of the BCGF. This request may contain Native-BC- ID, BC-Addr-Scheme, Dev-ID and Dev-BC-Addr as received at 2422.

[0349] The procedures at 2426 and 2428 may be combined as one step; thus, the BCCF may only send one request to the BCGF; this single request serves the purpose of both steps.

[0350] At 2430, the BCGF may receive the device blockchain address authentication request. It may start to authenticate Dev-BC-Addr using the following steps as an example: 1) the BCGF may use Dev-ID to find KBCGF (or KBCCF) for the Device locally or request KBCGF (or KBCCF; for the Device from the core network (e.g., AUSF or SEAF); 2) the BCGF may generate a temporary blockchain address (Temp-BC-Addr) using the same blockchain address generation functionin step 1 : Temp-BC-Addr =(KBCGF) (or Temp-BC-Addr =(KBCCF)); 3) the BCGF may compare Temp-BC-Addr and Dev-BC-Addr; if both are equal, Dev-BC-Addr is authorized; if both are different, Dev-BC-Addr is rejected. If Dev-BC-Addr is authorized, the BCGF may generate a blockchain address signature (BC-Addr-Sign) using its private key (e.g., PHKBCGF) according to address signature function FSIGN: BC-Addr-Sign = FSIGN (PHKBCGF, Dev-BC-Addr). BC-Addr-Sign can be validated by any other party knowing Dev-BC-Addr and PubKBcGF. PubKBcGF is the BCGF’s public key corresponding to PHKBCGF. The BCGF may append BC-Addr-Sign to Dev-BC-Addr to generate an authorized device blockchain address for the Device, Authorized-Dev-BC-Addr = Dev-BC-Addr + BC-Addr-Sign or Authorized-Dev-BC-Addr = Dev-BC-Addr || BC-Addr-Sign.

[0351] If Dev-BC-Addr is not authorized, the BCGF may generate a new Dev-BC-Addr and assign it to the Device. Then, the BCGF may still generate an Authorized-Dev-BC-Addr, but according to the new Dev-BC- Addr; in other words, the new Dev-BC-Add will be contained in Authorized-Dev-BC-Addr

[0352] At 2432, the BCGF may send a response to the BCCF indicating if Dev-BC-Addr was authorized or rejected. This response may contain PULIKBCGF, FSIGN, and Authorized-Dev-BC-Addr as generated in step 5. If Authorized-Dev-BC-Addr was based on a new Dev-BC-Addr, this response may contain a “New BC Address” indicator.

[0353] At 2434, optionally, the BCCF may send a request indicating the authorized Dev-BC-Addr to the BCGF for retrieving initial blockchain configuration for the Device; the BCGF may receive this request and determine some blockchain initial configurations (i.e., Dev-BC-lnit-Config) for the Device, for example, based on some preconfigured policies at the BCGF and / or any blockchain related policies in the core network (e.g., PCF) which the BCGF can retrieve; then, the BCGF may send Dev-BC-lnit-Config to BCCF. Dev-BC-lnit-Config may contain the following parameters: BCCF-ID: The identifier of the BCCF. BCGF-ID: The identifier of the BCGF. PubKBcGF: The public key of the BCGF. FSIGN: The function the BCGF used at 2430 to generate the blockchain address signature. Dev-BC-Role: Indicate if the Device will be or has been assigned as a BCN or a BSN. Native-BC-ID: The identifier of the target native wireless blockchain that the BCGF may determine for the Device. Authorized-Dev-BC-Addr: A blockchain address generated and assigned to the Device especially if the Device did not indicate a blockchain address at 2422 or if Dev-BC-Addr at 2422 is an invalid one. Peer-BC- Addr-List: The authorized blockchain addresses of other devices or nodes acting as BCNs, which the Device can exchange transactions with. Authorized-BC-Addr-List: The list of authorized blockchain addresses that the Device (acting as a BSN) can only serve. In other words, if the Device as a BSN receives a transaction directly from a BCN which is not on this list (Authorized-BC-Addr-List), the Device may reject the transaction without propagating it to other BSNs. This parameter Authorized-BC-Addr-List may only be needed if the Device is approved to be a BSN. BC-NF-ID: The identifier or address of other blockchain related functions that the Device may need to access (e g., BCEF, LAF and BCRF). Para-for-Accessing-3GPP-NF: A list of parameters for the Device (a BCN or a BSN) to access 3GPP network functions Those parameters may be: NF-ID: The identifier of a NF (e.g., a UDM, a UDR, a PCF, an NRF, an NEF, an NWDAF, an LMF, an AMF) in 3GPP network. This parameter NF-ID may contain multiple identifiers - each for a 3GPP NF. NF-Protocol: The protocol (e.g., TLS, NAS) for interacting with the NF as identified by NF-ID. Para-for-BC-User-Plane: Indicates necessary parameters to enable the Device to interact with user plane of the target native wireless blockchain as denoted by Native-BC-ID, such as: BCSF-ID: The identifiers of selected BCSFs that the Device may interface with for accessing the target native wireless blockchain user plane (e.g., the Device as a BCN will send transactions to the target native wireless blockchain via the selected BCSFs, the Device as a BSN may only interact with those BCSFs acting as a BSN) CP-or-UP: Indicate if the Device should contact BCSFs using 3GPP control plane (CP) or 3GPP user plane (UP). DNN-for-BC: The name of data network(s) that host the designated BCSFs. The Device may include DNN-for-BC when it requests to establish a PDU session in order to interact with a designated BCSF. The network may assign different DNN-for-BC for different native wireless blockchains. This parameter may be skipped if CP-or-UP = “CP” WTRU-BC-URSP-ID: The identifier of the UE Route Selection Policy (URSP) that applies to the PDU session that the Device may use to contact the designated BCSFs. Thisparameter may contain / indicate new URSP to be applied for blockchain user plane for the Device. This parameter may be skipped if CP-or-UP = “CP”. On-Chain-Tran-Template: The list of parameters to be mandatorily and / or optionally contained in an on-chain transaction that the Device will generate and send to a selected BCSF. The template On-Chain-Tran-Template may also describe how off-chain transactions can be contained in an on-chain transaction (e.g., generate one on-chain transaction for every N(>1) off-chain transactions, generate one on-chain transaction containing any off-chain transaction which age exceeds a threshold). On-Chain-Tran-Constraints: One or multiple constraints on how the Device may or may not send on-chain transactions to the BCSFs as denoted by BCSF-ID. For example, one constraint may be to limit the maximum transactions in a configured time period or window being sent to each BCSF. Off-Chain-Tran- Template: The list of parameters to be mandatorily and / or optionally contained in an off-chain or micro transaction which the Device will generate and send to a BCN as denoted by Peer-BC-Addr or other BCNs the Device knows. Different templates Off-Chai n-T ran-T emplate may be applied to different BCNs. Off-Chain-T ran- Constraints: One or multiple constraints on how the Device may or may not send off-chain transactions to BCNs as denoted by Peer-BC-Addr or other BCNs the Device knows. For example, one constraint may be to limit the maximum off-chain transactions in a configured time period or window being sent to each potential BCN. Monitoring-Instructions: One or multiple monitoring instructions indicating: A list of blockchain-related parameters (e.g., number of on-chain transactions being sent to a BCSF during a time internal) the Device needs to collect and report to the BCCF and / or the BCGF.

[0354] Monitoring-Instructions may also indicate the conditions on when these parameters should be reported to the BCCF and / or the BCGF, which could be event-based (e.g., when a BCSF becomes unreachable), threshold-based (e.g., send a report each time when the number of sent on-chain transactions exceeds a threshold), and / or time-based (e.g., send periodical reports every T seconds).

[0355] The BCGF may determine Dev-BC-lnit-Config as a part of the authorization at 2430 and may contain it in the response at 2432; for this case, the request 12434 may be skipped.

[0356] At 2436, the BCCF may select one or multiple BCSFs (BCSF-ID) for the authorized Device, especially when Dev-BC-lnit-Config received from 2434 (or 2432) did not contain any BCSF-ID. BCSFs may be selected based on different criteria, but not limited to: If the Device is a BCN, the BCCF may select a BCSF closest to the Device (e.g., a BCSF in the edge network as an edge application server) to reduce the latency for the Device to send transactions to BCSFs. If the Device is a BSN, the BCCF may select BCSFs to have all BCSFs / BSNs better connected (e.g., each BCSF / BSN has the similar number of neighboring BCSFs / BSNs).

[0357] At 2438, the BCCF may generate blockchain final configurations for the Device (i.e., Dev-BC-Final- Config), for example, by adding some extra parameters to Dev-BC-lnit-Config received from the BCGF. Some parameters as described in 2434 for Dev-BC-lnit-Config may not actually have been included in Dev-BC-lnit- Config; as such, the BCCF may decide those parameters and add them to Dev-BC-Final-Config. In addition, the BCCF may add its identifier (i.e., BCCF-ID) and the identifier of BCSFs selected at 2436 to Dev-BC-Final- Config.

[0358] At 2440, the BCCF may maintain a blockchain onboarding repository which contains a list of onboarded devices (e.g., devices with authorized blockchain addresses). The BCCF may update the blockchain onboarding repository by adding the authorized Device (e.g., Dev-ID, Authorized-Dev-BC-Addr) to the list.

[0359] At 2442, the BCCF may send a blockchain onboarding record to all BCSFs included in Dev-BC- Final-Config. This record may contain a list of parameters such as BCCF-ID, Native-BC-ID, Dev-ID, and Dev- BC-Fi nal-Confi g This record may also indicate if Dev-BC-Addr was rejected or approved; if it was approved or a new Authorized-Dev-BC-Addr was generated by the BCGF, this record may include Authorized-Dev-BC- Addr. Therefore, those BCSFs know the authentication status of Dev-BC-Addr (i.e., approved / authorized or rejected). Then, the BCSFs can reject any future transactions with a rejected blockchain address as a sender and / or a recipient, which will improve the performance and security of the target native wireless blockchain. The BCSFs may store the received blockchain onboarding record to native wireless blockchain. The BCCF also may send the blockchain onboarding record to the BCGF.

[0360] The BCGF may create the similar blockchain onboarding record at 2430 and send the record to the BCCF in step 6; then, the BCCF may send the record to the BCSF to store it to the target native wireless blockchain or to a different native wireless blockchain

[0361] At 2444, the BCCF may send a wireless blockchain onboarding response to the Device. This response may indicate if the Device has been authorized or rejected or if a new address as generated. If the Device was authorized or a new address was generated, this response may contain Authorized-Dev-BC-Addr and Dev-BC-Final-Config This response may include the BCGF’s public key (PubKacGr) and FSIGN.

[0362] At 2446 the Device may receive the response from 2444. It may store Authorized-Dev-BC-Addr and Dev-BC-Final-Config locally. Then, the Device may start to interact with native wireless blockchain using instructions contained in Dev-BC-Final-Config.

[0363] At 2448 the Device may start to interact with the target native wireless blockchain using its Authorized-Dev-BC-Addr. The Device as a BCN may start to interact with the designed BCSFs according to what Dev-BC-Final-Config specifies; for example, the Device may create a transaction and send it to a designated BCSF via a 3GPP PDU session or via 3GPP control plane. After 2446, the Device as a BSN may also start to interact with the designed BCSFs according to what Dev-BC-Final-Config specifies; for example, the Device may download the latest blockchain ledger from the designated BCSFs to make itself synchronized with the designated BCSFs. The Device may also use Para-for-Accessing-3GPP-NF to access designed 3GPP network functions as needed (e.g., to discover other functions from a 3GPP NRF). The Device may also use BC-NF-ID to access other blockchain functions (e.g., BCRF)

[0364] Embodiments for Wireless Blockchain Onboarding with Blockchain Address being Generated by Network are described herein.

[0365] As a part of wireless blockchain onboarding, blockchain address of a device for a native wireless blockchain may be generated by the BCGF (or the BCCF) and be assigned to the device. FIG. 25 illustrates an example procedure for this scenario.

[0366] The request at 2520 is similar to that at 2422 of FIG. 24. But this step may not include Dev-BC-Addr. The authorization request at 2522 is similar to that at 2424 of FIG 24. The authorization request at 2524 is similar to that at 2424 of FIG 24. If the authorization at 2522 or 2524 failed, the procedures described for 2526 to 2540 and 2544 to 2548 may be skipped; then, the BCCF may send a rejection to the Device 2510 at 2542.

[0367] At 2536, the BCCF 2512 may send a blockchain address generation request to the BCGF 2514. This request may contain Dev-ID and Native-BC-ID.

[0368] At 2528, the BCGF may receive the request from 2526. The BCGF may use following steps as an example to generate a blockchain address for the Device according to a blockchain address scheme (BC-Addr- Scheme) or a blockchain address generation function (Faddr):The BCGF may determine the target native wireless blockchain (Native-BC-ID) for the Device. The BCGF may get Native-BC-ID from the core network (e g., UDM, PCF, orAUSF). The BCGF may use Dev-ID and / or Native-BC-ID to find / derive KBCGF (or KBCCF) for the Device locally or request KBCGF (or KBCCF) for the Device from the core network (e.g., AUSF or SEAF). The BCGF may determine BC-Addr-Scheme or Fad* applicable to the Device for the target native wireless blockchain. The BCGF may get both parameters from the core network (e.g., UDM, PCF, orAUSF). The BCGF may generate a device blockchain address (Dev-BC-Addr) using BC-Addr-Scheme or Faddr: Dev-BC-Addr = Faddr (KBCGF) (or Dev-BC-Addr = Faddr (KBCCF)). The BCGF may generate a blockchain address signature (BC- Addr-Sign) using its private key (e.g., PHKBCGF) according to address signature function FSIGN: BC-Addr-Sign = FSIGN (PHKBCGF, Dev-BC-Addr). BC-Addr-Sign can be validated by any other party knowing Dev-BC-Addr and PubKBCGF. PubKBcGF is the BCGF’s public key corresponding to PHKBCGF.

[0369] The BCGF may append BC-Addr-Sign to Dev-BC-Addr to generate an authorized device blockchain address for the Device, Authorized-Dev-BC-Addr = Dev-BC-Addr + BC-Addr-Sign or Authorized-Dev-BC-Addr = Dev-BC-Addr || BC-Addr-Sign

[0370] At 2530, the BCGF may send a blockchain address generation response to the BCCF. This response may contain Native-BC-ID, PubKscGF, BC-Addr-Scheme (or Fad*), and Authorized-Dev-BC-Addr as generated in step 4. Both the BCGF and the BCCF may mark Authorized-Dev-BC-Addr as an authorized blockchain address for the Device.

[0371] Procedures 2532, 2534, 2536, 2538 and 2540 are similar to 2436, 2438, 2440, 2442 and 2444 of FIG. 24.

[0372] The creation of an onboarding record at 2540 is similar to that at 2442 of FIG. 24. The response at 2542 may contain Authorized-Dev-BC-Addr, BC-Addr-Scheme (or Faddr), PubKscGF, and Native-BC-ID.

[0373] At 2544, the Device may validate Authorized-Dev-BC-Addr to verify if BC-Addr-Sign contained in Authorized-Dev-BC-Addr was generated by the BCGF, by using BC-Addr-Scheme (or Faddr) and PubKBCGF.If Authorized-Dev-BC-Addr is valid (e.g., generated by the BCGF), the Device may continue to execute the procedures at 2546 and 2548; otherwise, they may be skipped. The Device may have been pre-configured with BC-Addr-Scheme (or Faddr) and PubKscGF, have retrieved / received both parameters from the core network (e.g., UDM, BCGF, AUSF, PCF), or have received both parameters at 2542.

[0374] The storing at 2546 is similar to that at 2446 FIG. 24.

[0375] At 2548, the Device may start to interact with the native wireless blockchain according to the received Dev-BC-Final-Config The Device as a BCN may start to interact with the designed BCSFs using the received Authorized-Dev-BC-Addr and according to what Dev-BC-Final-Config specifies; for example, the Device may create a transaction and send it to a designated BCSF via a 3GPP PDU session or via 3GPP control plane. The Device as a BSN may also start to interact with the designed BCSFs according to what Dev- BC-Final-Config specifies; for example, the Device may download the latest blockchain ledger from the designated BCSFs to make itself synchronized with the designated BCSFs. The Device may also use Para- for-Accessing-3GPP-NF to access designed 3GPP network functions as needed (e.g., to discover other functions from a 3GPP NRF). The Device may also use BC-NF-ID to access other blockchain functions (e.g., BCRF).

[0376] Embodiments for Wireless Blockchain Onboarding with Random Device Blockchain Address is described herein.

[0377] A Device may generate its blockchain address at its will without following any blockchain address scheme. For example, the Device may generate a random blockchain address from a pair of its private key and public key. The Device’s private key may never be shared or disclosure to any party; as a result, other parties cannot authorize or validate this random blockchain address since the Device’s private key is unknown to other parties. It is proposed that the Device may present a Verifiable Credential (VC) to other parties, which may verify the VC. If the VC is verified, the Device’s blockchain address becomes authenticated. FIG. 26 shows an example procedure for this scenario.

[0378] The generation at 2620 similar to that at 2420 of FIG 24. The Device 2610 may generate its blockchain address (Dev-BC-Addr) using its private / public key pair. The Device may sign Dev-BC-Addr using its public key (Dev-Public-Key); thus, Dev-BC-Addr may contain a blockchain address signature. The Device may prepare a Verifiable Credential (Dev-VC) which may be received from another party (e.g., VC-lssuer). Dev-BC-Addr may be included as a part of Dev-VC

[0379] The request at 2622 is similar to that at 2422 of FIG. 24 This step may contain Dev-VC and Dev- Public-Key.

[0380] The requests at 2624 and 2626 are similar to 2424 and 2426 of FIG. 24.

[0381] The request at 2628 is similar to that at 2428 of FIG. 24 This request may contain Dev-VC and Dev-Public-Key.

[0382] The authorization at 2630 is similar to that 12430 of FIG. 24. The BCGF may perform the following operations: Validate the blockchain address signature contained in Dev-BC-Addr using the Device’s public key (Dev-Public-Key). If Dev-BC-Addr is valid, the BCGF may verify Dev-VC using VC-lssuer’s public key, which the BCGF may have known or may retrieve it from the target native wireless blockchain (or another native wireless blockchain). If Dev-VC is valid, the BCGF may generate a blockchain address signature (BC-Addr- Sign) using its private key (e g., PriKscGF) according to address signature function FSIGN: BC-Addr-Sign = FSIGN (POKBCGF, Dev-BC-Addr). BC-Addr-Sign can be validated by any other party knowing Dev-BC-Addr and PubKscGF. PubKBCGF is the BCGF’s public key corresponding to PriKecGF. The BCGF may append BC-Addr- Sign to Dev-BC-Addr to generate an authorized device blockchain address for the Device, Authorized-Dev-BC- Addr = Dev-BC-Addr + BC-Addr-Sign or Authorized-Dev-BC-Addr = Dev-BC-Addr || BC-Addr-Sign.

[0383] In step 5, if Dev-BC-Addr is not authorized, the BCGF may generate a new Dev-BC-Addr and assign it to the Device. Then, the BCGF may still generate an Authorized-Dev-BC-Addr, but according to the new Dev- BC-Addr; in other words, the new Dev-BC-Add will be contained in Authorized-Dev-BC-Addr.

[0384] The processes described at 2632, 2634, 2636, 2638 and 2640 are similar to those describe at 2432, 2434, 2436, 2438 and 2440 of FIG. 24.

[0385] The creation of a record at 2642 is similar to that at 2442 of FIG. 24 The onboarding record generated in this step may contain the identifier of VC-lssuer (VC-lssuer-ID) which has generated Dev-VC for the Device.

[0386] The response at 2644 similar to that at 2444 of FIG. 24

[0387] The storing at 2646 is similar to that at 2446 of FIG. 24

[0388] The interaction at 2648 is similar to that at 2448 of FIG. 24. The Device may also use Para-for-Accessing-3GPP-NF to access designed 3GPP network functions as needed (e.g , to discover other functions from a 3GPP NRF). The Device may also use BC-NF-ID to access other blockchain functions (e.g., BCRF)

[0389] Embodiments for Wireless Blockchain Onboarding for WTRU with Assisted by AUSF and AMF are described herein.

[0390] A first 3GPP embodiment for Wireless Blockchain Onboarding for WTRU with Assisted by AUSF and AMF is illustrated in FIG. 27

[0391] A Device may be implemented as a part of 3GPP WTRU. BCCF may be implemented as a new 3GPP network function. Alternatively, BCCF may be implemented as a part of AMF. BCGF may be implemented as a part of AUSF. BCSF1 may be implemented as a new 3GPP network function. Alternatively, BCSF may be implemented as a part of UDR or UDSR. BCSF also could be a part of an Edge Application Server (EAS) or an AF.

[0392] FIG. 27 may be summarized as follows: Generate by a WTRU 2710 a first blockchain address of the WTRU (WTRU-BC-Addr); Prepare a first request for requesting wireless blockchain onboarding; the first request may contain a WTRU identifier, a blockchain flag, the first blockchain address, and the type of blockchain node that WTRU requests to be (WTRU-BC-Type such as a BCN or a BSN); Send the firstrequest to a first network function (e.g., AMF 2712); The first request may be forwarded from the first network function to a second network function (e.g., BCCF 2714) according to the blockchain flag; Receive a first response from the first network function; The first response may have been generated by the second network function; The first response may indicate if the first blockchain address is authorized; The first response may indicate if the type of blockchain node the WTRU requested is authorized; The first response may contain a first information element on blockchain configuration information for the WTRU (WTRU-BC-Final-Config), which was decided by the second network function. The first information element may contain the identifier of the second network function; The first information element may contain monitoring instructions that the WTRU needs to follow in order to report its blockchain statistics to the second network function. Store the first information element; and Interact with the native wireless blockchain using the authorized first blockchain address according to the first information element.

[0393] The embodiments illustrated by FIG. 27 may include the following steps:

[0394] The generation at 2730 is similar to 2420 of FIG. 24 The WTRU 2710 may generate its blockchain address (WTRU-BC-Addr, the same as Dev-BC-Addr in FIG. 24), for example, according to KBCGF (or KBCCF) and BC-Addr-Scheme. The WTRU may have received BC-Addr-Scheme from the AMF 2712 as a result of 3GPP procedures such as Registration, Registration Update, etc. The WTRU may have received FBCGF (or FBCCF) from the AMF as a result of 3GPP procedures (e.g., Registration, Registration Update, WTRU Parameter Update, etc.) and may have derived KBCGF (or KBCCF) according to FBCGF (or FBCCF)

[0395] At 2730, the WTRU may generate its random blockchain address using its public key (WTRU-Public- Key) without relying on other derived blockchain security keys.

[0396] The request at 2732 is similar to that at 2422 of FIG 24. WTRU-ID may be SUCI or 5G-GUTI of the WTRU, which is equivalent to Dev-ID in FIG 24. WTRU-BC-Type is equivalent to Dev-BC-Type in FIG. 24.

[0397] This request at 2732 may contain BCCF-ID, Native-BC-ID, and / or BC-Addr-Scheme. The request at 2732 may contain another parameter BC-Flag. If BC-Flag = TRUE, the AMF will regard this request as a blockchain-related request and will forward it to a BCCF This request at 2732 may be contained as a part of a 3GPP NAS message (e.g., Registration Request, Registration Update).

[0398] If the WTRU generated its random blockchain address at 2730, this step may contain BC-Addr- Scheme and WTRU-Public-Key. The contained BC-Addr-Scheme may be set to “Random Blockchain Address”

[0399] If the request at 2732 is a Registration Request (or a Registration Update), the AMF may perform regular primary authentication. If the primary authentication is successful and the registration will be accepted, the AMF may continue to execute the following steps; otherwise, the following steps may be skipped and the AMF may just indicate “Blockchain Onboarding Rejection” in Registration Accept to be sent to the WTRU.

[0400] At 2734, the AMF may receive the request from 2732. If BC-Flag = TRUE, the AMF may select a BCCF (e g., discover one or multiple BCCFs from an NRF) serving the target native wireless blockchain asdenoted by Native-BC-ID; if the AMF already has a BCCF or if BCCF-ID is contained at 2732, it may or may not choose a different one. The identifier of the selected BCCF is BCCF-ID. For example, the AMF may select a least loaded BCCF (e.g., the BCCF with the least number of onboarded WTRUs). In another example, the AMF may just select the same BCCF which may have previously sent BC-Onboarding-lnstructions to the WTRU

[0401] At 2736 the AMF may forward the received request from 2732 to the BCCF 2714. The AMF may also inform the BCCF of a PCF and / or an AUSF 2716 that the BCCF may need to contact, respectively, at 2738 and 2742.

[0402] At 2738, the BCCF may retrieve blockchain onboarding policies for the WTRU from a PCF 2718. For this purpose, the BCCF may first send a request indicating WTRU-ID and show this blockchain onboarding purpose to the PCF; then, the PCF may find blockchain onboarding policies applicable to WTRU-ID; the PCF may return found blockchain onboarding policies to the BCCF. The retrieved policies may contain Native-BC- ID applicable to the WTRU; alternatively, the BCCF may determine Native-BC-ID first and send both Native - BC-ID and WTRU-ID to the PCF for retrieving relevant blockchain onboarding policies.

[0403] At 2740, the BCCF may authorize the request made at 2736 according to blockchain onboarding policies received from 2738.

[0404] At 2742, the BCCF may forward the blockchain onboarding request from 2736 to the AUSF. If the BCCF does not know the AUSF, it may discover the AUSF from an NRF or the AMF.

[0405] At 2744 The AUSF may authorize WTRU-BC-Addr using similar approach of 2430 of FIG. 24. Note that the AUSF itself can derive KBCGr (or KBCCF) from KAUSF (or KSEAF) for the WTRU. The AUSF may generate WTRU-BC-lnit-Config (equivalent to Dev-BC-lnit-Config in FIG. 24) for the WTRU. The AUSF may generate Authorized- WTRU-BC-Addr (equivalent to Authorized- WTRU-BC-Addr in FIG. 24). The AUSF may (re)determine the target native wireless blockchain (Native-BC-ID) for the WTRU.

[0406] If the request of 2732 contains BC-Addr-Scheme = “Random Blockchain Address", the AUSF may simply regard this WTRU-BC-Addr as an authorized one once primary authentication for the WTRU is successful. Then, the AUSF may sign WTRU-BC-Addr and generate Authorized-WTRU-BC-Addr The AUSF may store WTRU-Public-Key as received from 2742.

[0407] At 2744 if WTRU-BC-Addr is not authorized, the AUSF may generate a new WTRU-BC-Addr and assign it to the WTRU. Then, the AUSF may still generate an Authorized-WTRU-BC-Addr, but according to the new WTRU-BC-Addr; in other words, the new WTRU-BC-Add will be contained in Authorized-WTRU-BC-Addr.

[0408] The response at 2746 is similar to that at 2432 of FIG. 24 This response may contain Native-BC-ID, WTRU-BC-lnit-Config, and Authorized-WTRU-BC-Addr.

[0409] The selection at 2748 is similar to 2436 of FIG. 24.

[0410] The generation at 2750 is similar to 2438 of FIG. 24. In this step, the BCCF generates WTRU-BC-Final-Config, which is equivalent to Dev-BC-Final-Config in FIG. 24.

[0411] The updating at 2752 is similar to 2440 of FIG. 24.

[0412] The storing at 2754 is similar to 2442 of FIG. 24. In addition, the BCCF may store the blockchain onboarding record to the BCSF / UDR.

[0413] At 2756, the BCCF may send a wireless blockchain onboarding response containing Native-BC-ID, WT RU-BC-I nit-Config, and Authorized-WTRU-BC-Addr to the WTRU via the AMF.

[0414] The storing at 2758 is similar to 2446 of FIG. 24. The WTRU may receive the response from step 14. It may store Native-BC-ID, WTRU-BC-lnit-Config, and Authorized-WTRU-BC-Addr locally

[0415] The interaction at 2760 is similar to 2448 of FIG. 24. The WTRU may start to interact with the target native wireless blockchain via the BCCF and the selected BCSF using Authorized-WTRU-BC-Addr, according to what was described in WTRU-BC-Final-Config. The WTRU may also use Para-for-Accessing-3GPP-NF to access designed 3GPP network functions as needed (e.g., to discover other functions from a 3GPP NRF). The WTRU may also use BC-NF-ID to access other blockchain functions (e.g., BCRF)

[0416] Embodiments for Wireless Blockchain Onboarding for WTRU with Assisted by SEAF and AMF are described herein.

[0417] A 3GPP embodiment for Wireless Blockchain Onboarding for WTRU with Assisted by AUSF and AMF is illustrated in FIG. 28:

[0418] A Device may be implemented as a part of 3GPP WTRU 2810. BCCF and BCGF will be combined together and implemented as a new 3GPP network function, referred to as Blockchain Control and Governance Function (BCCGF).

[0419] BCSF may be implemented as a new 3GPP network function. Alternatively, BCSF may be implemented as a part of UDR or UDSR.

[0420] The example procedure in FIG. 28 consists of the following operations:

[0421] The generating 2830 and the request 2832 are similar to 2730 and 2730 of FIG. 27.

[0422] The selection at 2834 is similar to 2834 of FIG. 27. But the AMF 2812 in this step may select a BCCGF 2814. For example, the AMF may select a least loaded BCCGF (e.g., the BCCGF 2814 with the least number of onboarded devices). In another example, the AMF may just select the same BCCGF as the BCCGF which may have previously sent BC-Onboarding-lnstructions to the WTRU. The identifier of the BCCGF (BCCGF-ID) may have been included in step 2 and the AMF may just use it.

[0423] The request at 2836 is similar to that at 2736 of FIG. 27. The AMF may forward the request from 2832 to the selected BCCGF.

[0424] The retrieving at 2838 is similar to that at 2738 of FIG. 27.

[0425] The authorization at 2840 is similar to that 12740 of FIG 27.

[0426] At 2842, the BCCGF may send WTRU-ID and Native-BC-ID to an SEAF 2816 (or an AUSF); the SEAF (or the AUSF) may derive KBcor for the WTRU; the SEAF (or the AUSF) may send KBCGF to the BCCGF.

[0427] The verification at 2844 is similar to that at 2744 of FIG 27. The BCCGF may use the same way that the AUSF verified / authorized WTRU-BC-Addr at 2844 of FIG. 27 to verify WTRU-BC-Addr.

[0428] At 2844, if WTRU-BC-Addr is not authorized, the BCCGF may generate a new WTRU-BC-Addr and assign it to the WTRU. Then, the BCCGF may still generate an Authorized-WTRU-BC-Addr, but according to the new WTRU-BC-Addr; in other words, the new WTRU-BC-Add will be contained in Authorized- WTRU-BC- Addr.

[0429] The procedures at 2846, 2848, 2850, 2852, 2854, 2856 and 2858 are similar to those at 2748, 2750, 2752, 27542756, 2758 and 2760 of FIG. 27

[0430] Wireless Blockchain Onboarding with WTRU Blockchain Address being Generated by AUSF is described herein and is illustrated in FIG. 29.

[0431] A Device may be implemented as a part of 3GPP WTRU 2910 BCCF 2914 may be implemented as a new 3GPP network function Alternatively, BCCF may be implemented as a part of AMF 2912. BCGF may be implemented as a part of AUSF2916 or a part of SEAF or a new 3GPP NF. BCSF may be implemented as a new 3GPP network function. Alternatively, BCSF 2920 may be implemented as a part of UDR or UDSR. BCSF also could be a part of an Edge Application Server (EAS) or an AF.

[0432] FIG. 29 may be summarized as follows: Prepare by a WTRU a first request for requesting wireless blockchain onboarding; The first request may contain a WTRU identifier, a blockchain flag, and the type of blockchain node that WTRU requests to be (WTRU-BC-Type such as a BCN or a BSN); Send the first request to a first network function (e.g , AMF); The first request may be forwarded from the first network function to a second network function (e.g., BCCF) according to the blockchain flag; Receive a first response from the first network function; The first response may have been generated by the second network function; The first response may indicate a first blockchain address (Authorized-WTRU-BC-Addr) being generated and authorized by the second network function or a third network function (e.g., AUSF); The first response may indicate if the type of blockchain node WTRU requested is authorized; The first response may contain a first information element on blockchain configuration information for WTRU (WTRU-BC-Final-Config), which was decided by the second network function or the third network function. The first information element may contain the identifier of the second network function. The first information element may contain monitoring instructions that WTRU needs to follow in order to report its blockchain statistics to the second network function. Store the first information element; and Interact with the native wireless blockchain using the first blockchain address according to the first information element.

[0433] Embodiments illustrated by FIG. 29 may include the following steps:

[0434] The request at 2930 is similar to that at 2732 of FIG. 27, but the request may not contain WTRU- BC-Addr.

[0435] This request at 2930 may be contained as a part of a 3GPP NAS message (e.g , Registration Request, Registration Update). This request 12930 may also contain Native-BC-ID and WTRU-BC-Type.

[0436] This request at 2930 may contain an “BC-Addr-lndicator” which indicates to the network that the WTRU requests to get a blockchain address from the network.

[0437] If 2930 is a Registration Request (or a Registration Update), the AMF may perform regular primary authentication. If the primary authentication is successful and the registration will be accepted, the AMF may continue to execute the following steps; otherwise, the following steps may be skipped and the AMF may just indicate “Blockchain Onboarding Rejection” in Registration Accept to be sent to the WTRU.

[0438] The selection at 2932 is similar to that at 2734 of FIG. 27. When the AMF sees “BC-Addr-lndicator”, it may use an existing BCCF (as indicated in step 1 or locally maintained) or select a new BCCF.

[0439] The request at 2934 is similar to that at 2736 of FIG 27. This request may contain BC-Addr- lndicator.

[0440] The retrieving at 2936 is similar to that at 2738 of FIG. 27.

[0441] The authorization at 2938 is similar to that at 2740 of FIG. 27.

[0442] At 2940, the BCCF may send a wireless blockchain address request to the AUSF. This request may contain BC-Addr-lndicator, WTRU-ID, and Native-BC-ID. Alternatively, the BCCF may send this request to an SEAF.

[0443] 2942, the AUSF may receive the request from 2940. In embodiments, the AUSF may use following steps as an example to generate a blockchain address for the WTRU: The AUSF may determine the target native wireless blockchain (Native-BC-ID) for the WTRU. The AUSF may get Native-BC-ID from the core network (e.g., UDM, PCF). The AUSF may use WTRU-ID and / or Native-BC-ID to find / derive the WTRU’s root key and derive KBCGF (or K=) for the WTRU from KAUSF or KSEAF The AUSF may generate a WTRU blockchain address (WTRU-BC-Addr) using a blockchain address generation functionapplicable to the WTRU: WTRU-BC-Addr =(K=) (or WTRU-BC-Addr =(KBCCF)). The AUSF may generate a blockchain address signature (BC-Addr-Sign) using its private key (e.g., PriK=) according to address signature function FSIGN: BC-Addr-Sign = F=(PriKAusF, WTRU-BC-Addr). BC-Addr-Sign can be validated by any other party knowing WTRU-BC-Addr and PubK=. PubK= is the AUSF’s public key corresponding to PriK=. The AUSF may append BC-Addr-Sign to WTRU-BC-Addr to generate an authorized WTRU blockchain address for the WTRU, Authorized-WTRU-BC-Addr = WTRU-BC-Addr + BC-Addr-Sign or Authorized- WTRU-BC-Addr = WTRU-BC- Addr || BC-Addr-Sign.

[0444] Alternatively, the process at 2942 may be performed by the SEAF, which may perform: The SEAF may determine the target native wireless blockchain (Native-BC-ID) for the WTRU. The SEAF may get Native- BC-ID from the core network (e.g., UDM, PCF). The SEAT may derive KBCGF (or KBCCF) for the WTRU from KSEAF; 2)The SEAF generates a WTRU blockchain address (WTRU-BC-Addr) using a blockchain address generation functionapplicable to the WTRU: WTRU-BC-Addr =(KBCCF))-

[0445] The SEAF may generate a blockchain address signature (BC-Addr-Sign) using its private key (e.g., PriKSEAF) according to address signature function FSIGN: BC-Addr-Sign = FSIGN (PriK=, WTRU-BC-Addr). BC- Addr-Sign can be validated by any other party knowing WTRU-BC-Addr and PubKsEAF. PubKsEAF is the SEAF’s public key corresponding to PriKsEAF.

[0446] The SEAF may append BC-Addr-Sign to WTRU-BC-Addr to generate an authorized WTRU blockchain address for the WTRU, Authorized-WTRU-BC-Addr = WTRU-BC-Addr + BC-Addr-Sign or Authorized-WTRU-BC-Addr = WTRU-BC-Addr || BC-Addr-Sign

[0447] At 2944, the AUSF may send a wireless blockchain address response to the BCCF. This response may contain Authorized-WTRU-BC-Addr, BC-Addr-Scheme, Native-BC-ID, and PubKAusF as generated / determined at 2942. Alternatively, the SEAF may send the response containing those parameters to the BCCF.

[0448] The procedures at 2946, 2948, 2950 and 2952 are similar to those at 2748, 2750, 2752 and 2754 of FIG. 27.

[0449] The storing at 2752 is similar to 2754 of FIG. 27. The response at 2954 may also contain those parameters as contained at 2944. This response may also contain BCCF-ID.

[0450] At 2956, the WTRU may validate the received Authorized-WTRU-BC-Addr to verify if BC-Addr-Sign contained in Authorized-WTRU-BC-Addr was generated by the AUSF (or the SEAF), by using BC-Addr- Scheme (or Faddr) and PubKAusF. If Authorized-Dev-BC-Addr is valid (e.g., generated by the AUSF), the WTRU may continue to execute 2758 and 2760; otherwise, 2758 and 2760 may be skipped The WTRU may have been pre-configured with BC-Addr-Scheme (or Faddr) and PubKAusF, have retrieved / received both parameters from the core network (e.g., UDM, PCF), or have received both parameters from 2754

[0451] The storing at 2958 is similar to that at 2758 of FIG. 27.

[0452] The interaction at 2960 is similar to 2760 of FIG. 27.

[0453] In a further embodiment the logical entities introduced include LAF, BCRF, and BCEF. In embodiments the logical entities include Device / BCCCF, BCCF, BCGF, and BCSF BCCF may be implemented as LAF. BCGF may be implemented as BCRF Alternatively, BCGF can be defined as a new network function. A Device may be implemented as BCEF within WTRU. BCSF may be implemented as BCEF with a full blockchain node.

[0454] Alternatively, BCCF may be implemented as distributed LAF. BCGF may be implemented as centralized LAF. Alternatively, BCGF can be defined as a new network function. Device may be implemented as BCEF within WTRU. BCSF 1 can be implemented as BCEF with a full blockchain node.

[0455] Procedures for Provisioning Blockchain Access Information to a BCEF are discussed herein.

[0456] FIG. 30 illustrates an example of provisioning a BCEF with necessary information for it to access a designated native wireless blockchain and 3GPP core network functions.

[0457] In embodiments, the procedure in FIG. 30 may consist of the following steps. With this procedure, a LAF 3010 may send some blockchain configuration information to a BCEF 3040 so that the BCEF is able to: 1) access a designated native wireless blockchain system (Native-BC-ID); 2) interact with other blockchain- related functions using the designated approaches; and 3) interact with 3GPP NFs (e.g., discover other NFs from an assigned NRF). The LAF and / or a BCGF may determine the blockchain configuration information for the BCEF.

[0458] In this figure, the LAF may have all functions of a BCCF as proposed in this disclosure and the BCEF may have all functionalities of a BCSF and / or a BCCCF as proposed in this disclosure. The BCGF 3012 may be a BCRF. The BCGF may also be implemented as a part of the LAF (i.e., functionalities of BCGF on this figure are merged to the LAF).

[0459] At 3020, the LAF may select one or multiple BCEFs for sending blockchain configuration information to. The LAF may discover those BCEFs from a BCRF, a BCGF, and / or other LAF

[0460] At 3022, the LAF may send a request to the BCGF to request blockchain configuration information for the BCEF. This request may contain the identifier or the address of the BCEF (BCEF-ID).

[0461] At 3024, the BCGF may receive the request from 3022 and may determine some blockchain initial confirmation information for the BCEF (BC-lnit-Config). BC-lnit-Config is equivalent to Dev-BC-lnit-Config or WTRU-BC-lnit-Config as defined in this disclosure. BC-lnit-Config may contain the following information: Native-BC-ID: The identifier of the designated native wireless blockchain that the BCEF in FIG. 30 is assigned to be part of it. LAF-ID: The identifier of the LAF and / or other LAFs that BCEF may need to contact. BCEF-ID: The identifier of other BCEFs (e.g , a BCEF on a WTRU may send transactions to this BCEF in FIG. 30, a BCEF on a full blockchain node that will be the neighboring node of this BCEF in FIG. 30). BCRF-ID: The identifier or the address of a BCRF that the BCEF may contact in the future. BCGF-ID: The identifier or the address of a BCGF that the BCEF may contact in the future. Para-for-Accessing-3GPP-NF: A list of parameters for the BCEF to access 3GPP network functions (e.g., to discover another network function (NF), to subscribe / retrieve context information about WTRU). Those parameters may be: NF-ID: The identifier of a NF (e g., a UDM, an NRF, an NEF, an NWDAF, an LMF, an AMF) in 3GPP network This parameter NF-ID may contain multiple identifiers - each for a 3GPP NF. NF-Protocol: The protocol (e.g., TLS, NAS) for interacting with the NF as denoted by NF-ID Authorized-BC-Addr: An authorized blockchain address assigned to the BCEF. The BCGF may send a response to the LAF containing the determined BC-lnit-Config for each BCEF as indicated in step 2.

[0462] The following 3026 and 3028 (i.e., Case B) may be an alternative to 3020, 3022 and 3024 (i.e., Case A).

[0463] At 3026, the BCGF may select one or multiple BCEFs. The BCGF may determine BC-lnit-Config for each selected BCEF.

[0464] At 3028 the BCGF may send a response to the LAF. This response may contain the determined BC-lnit-Config for each BCEF as selected at 3026.

[0465] The following procedures 3030, 3032, 3034, 3036, 3038 and 3040 may be repeated for each BCEF as selected at 3020 or 3026.

[0466] At 3030, the LAF may determine the final blockchain configuration information for each selected BCEF (BC-Final-Config). BC-Final-Config is equivalent to Dev-BC-Final-Config or WTRU-BC-Final-Config as defined in this disclosure. BC-Final-Config may be the same as BC-lnit-Config. The LAF may change the value of some parameters contained in BC-lnit-Config and generate BC-Final-Config.

[0467] At 3032, the LAF may send a notification to the BCEF. The notification may contain BC-Final-Config as determined at 3030.

[0468] At 3034, the BCEF may receive the notification from 3032. The BCEF may store BC-Final-Config as received from the notification.

[0469] At 3036, the BCEF may send a confirmation to the LAF indicating that BC-Final-Config has been received.

[0470] At 3038, the BCEF may use the information contained in BC-Final-Config to access the designated native wireless blockchain and 3GPP NFs.

[0471] At 3040, the LAF may send a notification (for Case A) or a confirmation (for Case B) to the BCGF, indicating that the BCEF has been configured with BC-Final-Config.

[0472] Although the features and elements of the present invention are described in the preferred embodiments in particular combinations, each feature or element can be used alone without the other features and elements of the preferred embodiments or in various combinations with or without other features and elements of the present invention.

Claims

CLAIMSWhat is Claimed:

1. A method implemented in a WTRU comprising: receiving blockchain onboarding information from a first network function; generating a first blockchain address of the WTRU based on the onboarding information; preparing a first request for wireless blockchain onboarding; transmitting the first request to a first network function; receiving from the first network function a first response comprising a first information element; storing the first information element; and interacting with a native wireless blockchain based on the first information element.

2. The method of claim 1 , wherein the blockchain onboarding information includes a function for generating the first blockchain address of the WTRU.

3. The method of claim 1 or 2, wherein the first blockchain address is based on a security key derived by the WTRU.

4. The method of any of claims 1-3, wherein the WTRU determines to log data to the native wireless blockchain5. The method of any of claims 1-4, wherein the WTRU receives an instruction to log data to the native wireless blockchain.

6. The method of any of claims 1-5, wherein the first request for wireless blockchain onboarding is transmitted via a control plane.

7. The method of any of claims 1-5, wherein the first request for wireless blockchain onboarding is transmitted via a user plane.

8. The method of any of claims 1-7, wherein the first request for wireless blockchain onboarding includes a blockchain node type of the WTRU.

9. The method of any of claims 1-8, wherein the first request for wireless blockchain onboarding includes a public key of the WTRU.

10. The method of any of claims 1-9, wherein the first request for wireless blockchain onboarding includes an indication of how the first blockchain address was generated.

11. A WTRU comprising: a processor and a transceiver, wherein the processor is configured to: cause the transceiver to receive blockchain onboarding information from a first network function; generate a first blockchain address of the WTRU based on the onboarding information; prepare a first request for wireless blockchain onboarding; cause the transceiver to transmit the first request to a first network function;cause the transceiver to receive from the first network function a first response comprising a first information element; store the first information element; and interact with a native wireless blockchain based on the first information element.

12. The WTRU of claim 11, wherein the blockchain onboarding information includes a function for generating the first blockchain address of the WTRU.

13. The WTRU of claim 11 or 12, wherein the first blockchain address is based on a security key derived by the WTRU.

14. The WTRU of any of claims 11-13, wherein the processor determines to log data to the native wireless blockchain15. The WTRU of any of claims 11-14, wherein the processor is further configured to cause the transceiver to receive an instruction to log data to the native wireless blockchain.

16. The WTRU of any of claims 11-15, wherein the processor is further configured to cause the transceiver to transmit the first request for wireless blockchain via a control plane.

17. The WTRU of any of claims 11-15, wherein the processor is further configured to cause the transceiver to transmit the first request for wireless blockchain via a user plane.

18. The WTRU of any of claims 11-17, wherein the first request for wireless blockchain onboarding includes a blockchain node type of the WTRU.

19. The WTRU of any of claims 11-18, wherein the first request for wireless blockchain onboarding includes a public key of the WTRU.

20. The WTRU of any of claims 11-19, wherein the first request for wireless blockchain onboarding includes an indication of how the first blockchain address was generated.

Images