Method for chaining device to wireless blockchain system

Abstract

A method for configuring a block chain key derivation function on a wireless transmit receive unit (WTRU) side is described. A method for WTRU-side configuration device selection is also described. Methods for WTRU-side wireless blockchain uplink configuration notification and for wireless blockchain uplink are also described. A WTRU for performing the method described herein is also described.

Description

Cross-reference to related applications

[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 incorporated herein by reference. Background Technology

[0002] Existing cellular radio systems (e.g., 5GS) offer a variety of security features, such as primary authentication during registration, secondary authentication during Protocol Data Unit (PDU) session establishment, network slice-specific authentication and authorization, network slice admission control, data plane encryption, and integrity protection. Future cellular radio systems, such as 6G (6GS), will have a wide range of heterogeneous devices and networks, and the vertical industries they support (e.g., mission-critical) are expected to expand, thus requiring greater trustworthiness than 5G systems. For example, devices and their interactions with the radio system should be trusted by core network functions, application functions (in the cloud or at the edge), and other devices—a concept known as a trusted device or trusted WTRU—which is not supported in 5G. Existing security features provided in 5G lack the support to assess or impose trustworthiness on a given WTRU. For example, device trustworthiness may be dynamic and change over time, and existing 5G primary or secondary authentication does not consider or support this dynamic device trustworthiness.

[0003] Blockchain and distributed ledger technologies are considered promising enabling technologies for making future 6G devices and systems trustworthy. For example, devices and / or authorized parties can record device behavior and any necessary data on a distributed ledger, which is transparent and accountable to other devices and network nodes, thus achieving decentralized trust. To this end, devices need to be able to access the distributed ledger via 6GS to read data from and / or write data to it. Furthermore, if data stored in the distributed ledger is found to be outdated, contains errors, or affects user privacy, it may need to be modified or deleted, which can be achieved using a redactable distributed ledger.

[0004] To leverage blockchain technology to realize future trusted systems, 6GS needs to integrate blockchain capabilities (e.g., as network functions) into its overall functionality, known as a native wireless blockchain. The native wireless blockchain is expected to be a permissioned blockchain system, such as the ETSI PDL. For devices to effectively interact with such a native wireless blockchain, they first need to be properly on-chained to the native blockchain and configured with the necessary configuration information for interaction; this is called device-to-native-wireless-blockchain onboarding, or simply wireless blockchain onboarding. Summary of the Invention

[0005] In an embodiment, a method implemented in a WTRU may include: receiving blockchain on-chain information from a first network function; generating a first blockchain address for the WTRU based on the on-chain information; preparing a first request for wireless blockchain on-chaining; sending the first request to the first network function; receiving a first response including a first information element from the first network function; storing the first information element; and interacting with the native wireless blockchain based on the first information element. Additionally / alternatively, the blockchain on-chain information may include a function for generating the first blockchain address for the WTRU. Additionally / alternatively, the first blockchain address may be based on a security key derived by the WTRU. Additionally / alternatively, the WTRU may determine to record data to the native wireless blockchain. Additionally / alternatively, the WTRU may receive an instruction to record data to the native wireless blockchain. Additionally / alternatively, the first request for wireless blockchain on-chaining may be sent via the control plane. Additionally / alternatively, the first request for wireless blockchain on-chaining may be sent via the user plane. Additionally / alternatively, the first request for wireless blockchain on-chaining may include the blockchain node type of the WTRU. Additionally / alternatively, the first request for onboarding the wireless blockchain may include the public key of the WTRU. Additionally / alternatively, the first request for onboarding the wireless blockchain may include an indication of how the first blockchain address was generated.

[0006] In a further embodiment, a WTRU may include: a processor and a transceiver, wherein the processor is configured to: receive blockchain on-chain information from a first network function; generate a first blockchain address for the WTRU based on the on-chain information; prepare a first request for wireless blockchain on-chaining; send the first request to the first network function; receive a first response from the first network function including a first information element; store the first information element; and interact with the native wireless blockchain based on the first information element. Additionally / alternatively, the blockchain on-chain 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 from the WTRU. Additionally / alternatively, the processor determines to record data to the native wireless blockchain. Additionally / alternatively, the processor may be further configured to cause the transceiver to receive an instruction to record data to the native wireless blockchain. Additionally / alternatively, the processor may be further configured to cause the transceiver to send the first request for wireless blockchain via a control plane. Additionally / alternatively, the processor may be further configured to cause the transceiver to send the first request for wireless blockchain via the user plane. Additionally / alternatively, the first request for wireless blockchain onboarding may include the blockchain node type of the WTRU. Additionally / alternatively, the first request for wireless blockchain onboarding may include the 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. Attached Figure Description

[0007] A more detailed understanding can be obtained from the following description, given by way of example in conjunction with the accompanying drawings, wherein the same reference numerals denote the same elements, and wherein: Figure 1A This is a system diagram illustrating an exemplary communication system that can implement one or more of the disclosed embodiments; Figure 1B This illustrates that, according to an embodiment, it is possible to Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) used in the communication system shown; Figure 1C This illustrates that, according to an embodiment, it is possible to Figure 1A System diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) used in the communication system shown; Figure 1D This illustrates that, according to an embodiment, it is possible to Figure 1A A system diagram of another exemplary RAN and another exemplary CN used in the communication system shown; Figure 2This is an example diagram illustrating the functionality of a native wireless blockchain system; Figure 3 This is an example diagram of generating blockchain key materials at a core network with BCGF; Figure 4 This is an example diagram illustrating the generation of blockchain key material at the WTRU in the presence of BCGF at the core network. Figure 5 This is an example diagram of generating blockchain key material in a core network without BCGF; Figure 6 This is an example diagram of generating blockchain key material at WTRU without BCGF; Figure 7 This is an exemplary flowchart of BCGF requesting a blockchain key derive function from the core network; Figure 8 This is an exemplary flowchart for configuring the blockchain key export function to BCGF; Figure 9 This is an exemplary flowchart of the function for exchanging blockchain keys between the WTRU and the core network via the AMF; Figure 10 This is an exemplary flowchart of the function for exchanging blockchain keys between the WTRU and the core network during PDU session establishment; Figure 11 This is an exemplary flowchart of UDM pushing specific blockchain parameters to WTRU; Figure 12 This is an exemplary flowchart of the wireless blockchain onboarding process initiated by BCGF; Figure 13 This is an exemplary flowchart of device selection and notification for wireless blockchain on-chaining, conducted by BCAF and through BCCF. Figure 14 This is an exemplary flowchart of device selection and notification for wireless blockchain on-chaining, conducted by BCAF and through BCGF. Figure 15 This is an exemplary flowchart of device A, the discoverer, initiating a wireless blockchain on-chain process for device B, the discoverer. Figure 16 This is an exemplary flowchart of device B, the discoverer, initiating a wireless blockchain on-chain process for device A, the discoverer. Figure 17 This is an exemplary flowchart of device A initiating wireless blockchain on-chain with the assistance of device B; Figure 18 This is an example block diagram for implementing device selection and notification for wireless blockchain on-chain in 3GPP; Figure 19This is an exemplary flowchart of the wireless blockchain on-chain initiation process embedded in the 3GPP registration; Figure 20 This is an exemplary flowchart of using 3GPP registration to accept notifications to WTRU via BCCF to initiate wireless blockchain on-chaining; Figure 21 This is an exemplary flowchart of a wireless blockchain being initiated by the AMF after registration with 3GPP. Figure 22 This is an exemplary flowchart of the wireless blockchain onboarding process initiated by 3GPP NWDAF; Figure 23 This is an exemplary flowchart of a wireless blockchain onboarding process initiated by 3GPP AF. Figure 24 This is an exemplary flowchart of wireless blockchain on-chain authentication using BCGF for device blockchain address verification; Figure 25 This is an exemplary flowchart of wireless blockchain on-chaining where blockchain addresses are generated by the network; Figure 26 This is an exemplary flowchart of wireless blockchain onboarding using random device blockchain addresses; Figure 27 This is an exemplary flowchart of wireless blockchain on-chaining for WTRU assisted by AUSF and AMF; Figure 28 This is an exemplary flowchart of wireless blockchain on-chaining for WTRU assisted by SEAF and AMF; Figure 29 This is an exemplary flowchart of wireless blockchain onboarding using AUSF-generated WTRU blockchain addresses; and Figure 30 This is an exemplary flowchart for configuring BCEF. Detailed Implementation

[0008] Figure 1AThis diagram illustrates an exemplary communication system 100 that can implement one or more of the disclosed embodiments. The communication system 100 may be a multiple access system that provides content (e.g., voice, data, video, messaging, broadcasting, etc.) to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing system resources (including wireless bandwidth). For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word Discrete Fourier Transform Extended OFDM (ZT-UW-DFT-S-OFDM), Unique Word OFDM (UW-OFDM), Resource Block-Based Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

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

[0010] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks (e.g., CN 106, Internet 110, and / or other networks 112). For example, base stations 114a and 114b may be base transceiver stations (BTS), NodeBs, eNodeBs (eNBs), home NodeBs, home eNodeBs, next-generation NodeBs (e.g., gNodeBs (gNBs)), new radio (NR) NodeBs, site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are depicted as single elements, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

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

[0012] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116. Air interface 116 can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Air interface 116 can be established using any suitable radio access technology (RAT).

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

[0014] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can use Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro) to establish air interface 116.

[0015] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use NR to establish air interface 116.

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

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

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

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

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

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

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

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

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

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

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

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

[0028] The processor 118 can receive power from the power supply 134 and can be configured to distribute power to and / or control power to other components in the WTRU 102. The power supply 134 can be any suitable device for powering the WTRU 102. For example, the power supply 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

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

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

[0031] WTRU 102 may include a full-duplex radio for which the transmission and reception of some or all signals (e.g., associated with a specific subframe used for both 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 that reduces or substantially eliminates self-interference via hardware (e.g., a choke) or via signal processing by a processor (e.g., a separate processor (not shown) or via processor 118). In embodiments, WTRU 102 may include a half-duplex radio for which the transmission and reception of some or all signals (e.g., associated with a specific subframe used for either UL (e.g., for transmission) or DL ​​(e.g., for reception) may be concurrent and / or simultaneous.

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

[0033] RAN 104 may include eNodeBs 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of eNodeBs while remaining consistent with the embodiments. Each of eNodeBs 160a, 160b, and 160c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, eNodeBs 160a, 160b, and 160c may implement MIMO technology. Therefore, for example, eNodeB 160a may use multiple antennas to transmit and / or receive radio signals from WTRU 102a.

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

[0035] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. Although the foregoing elements are depicted as part of CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

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

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

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

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

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

[0042] In Infrastructure Basic Services Set (BSS) mode, a WLAN 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 into and / or out of the BSS. Traffic originating outside the BSS and destined for a STA can be delivered to the STA via the AP. Traffic originating from a STA destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be transmitted via the AP; for example, a source STA can send a traffic flow to the AP, and the AP can deliver the traffic flow to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be sent between the source and destination STAs (e.g., directly) via Direct Link Establishment (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). WLANs using the Standalone BSS (IBSS) mode can function without access points (APs), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as the "ad-hoc" communication mode in this document.

[0043] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel (e.g., the primary channel). The primary channel can have a fixed width (e.g., a 20 MHz bandwidth) or a dynamically configured width. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, such as in an 802.11 system, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) can be implemented. For CSMA / CA, each STA (including the AP) can listen on the primary channel. If the primary channel is listened to / detected and / or determined to be busy by a particular STA, that particular STA can back off. In a given BSS, at any given time, there can be only one STA (e.g., only one station) transmitting.

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

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

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

[0047] WLAN systems such as 802.11n, 802.11ac, 802.11af, and 802.11ah, which support multiple channels and channel bandwidths, include channels that can be designated as the primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STAs operating in the BSS that support the minimum bandwidth operating mode from among all STAs. In the 802.11ah example, for STAs supporting (e.g., only supporting) the 1MHz mode (e.g., MTC type devices), the primary channel can be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Assignment Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, because STAs supporting only the 1MHz operating mode are transmitting to the AP, all available bands can be considered busy, even if most available bands remain idle.

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

[0049] Figure 1D This is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 104 can also communicate with CN 106.

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

[0051] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable parameter sets. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary depending on different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing a varying number of OFDM symbols and / or varying absolute time lengths).

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

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

[0054] Figure 1DThe CN 106 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. Although the foregoing elements are depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

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

[0057] UPF 184a and 184b can be connected to one or more gNBs 180a, 180b, and 180c in RAN 104 via the N3 interface. They can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (e.g., Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, and providing mobility anchoring.

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

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

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

[0061] One or more emulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, emulation devices can be used in test scenarios in a test laboratory and / or in non-deployed (e.g., testing) wired and / or wireless communication networks to enable testing of one or more components. One or more emulation devices can be test devices. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) can be used by the emulation devices to transmit and / or receive data.

[0062] The following acronyms may be used in this article: 3GPP Third Generation Partnership Project 5G (Fifth Generation) 5GC 5G Core Network 5GS 5G system 5G-GUTI - The World's Only Temporary Identifier for 5G 6G sixth generation 6GC 6G Core Network 6GS 6G system Address AF Application Functions AMF Access and Mobility Management Functions ARPF Authentication Repository and Processing Functions AUSF Authentication Server Functionality BC Blockchain BCAF Blockchain Application Functions BCCCF Blockchain Client and Consumer Functions BCCF Blockchain Control Function BCCGF Blockchain Control and Governance Functions BCEF Blockchain Enablement Functions BCGF Blockchain Governance Function BCN Blockchain Client Node BCRF Blockchain Repository Functionality BCSF Blockchain Service Functions BSN Blockchain Service Node DN Data Network EAS Edge Application Server ETSI (European Telecommunications Standards Institute) GR Group Report GS Group Specifications ID identifier ISG Industry Standards Group LAF Ledger Anchor Function LMF location management function NAS Non-Access Layer NEF Network Open Functions NF Network Functions NRF Network Repository Functionality NWDAF Network Data Analysis Function PCF policy control function PDL (Permissioned Distributed Ledger) PDU Protocol Data Unit PLMN Public Land Mobile Network SA Service Architecture SEAF Security Anchor Function SIDF subscription identifier de-hiding function SIM subscriber identity module SUCI subscription hidden identifier SUPI subscription permanent identifier TLS Transport Layer Security UDM Unified Data Management UDR Unified Data Repository UDSF Unstructured Data Storage Function WTRU Wireless Transmit / Receive Unit UICC General Integrated Circuit Card URSP WTRU routing policy The 5G system architecture consists of a Transmit / Receive Unit (WTRU), a Radio Access Network (RAN), and a core network. One of the design principles of the 5G system (5GS) is that it is service-centric or service-based. The 5G core network (5GC) contains various network functions that work together to meet and provide the services required by the RAN, WTRU, and application servers / service providers. Network functions can access other network functions in a request / response mode or a subscription / notification mode. Before two network functions can interact with each other, they must first register with the Network Repository Function (NRF) so that they can discover each other via the NRF. Among these network functions, the Access and Mobility Management Function (AMF) is dedicated to managing the WTRU's access to the 5GS and its mobility, the Session Management Function (SMF) is responsible for establishing sessions between the WTRU and the 5GC, and the Authentication Server Function (AUSF) is responsible for WTRU authentication. In addition, the Policy Control Function (PCF) provides policy rules for other control plane network functions and WTRUs; the PCF assigns an identifier to each policy rule it creates, which other control plane network functions and WTRUs use to reference the corresponding policy rule. User Plane Functions (UPF) are the only core network functions in the data plane, facilitating the monitoring, management, control, and redirection of user plane traffic flows (e.g., between WTRUs and Application Functions (AFs)). Network Open Functions (NEF) enable 5G control plane functions to be accessed by entities such as network applications and AFs that are outside the 5GS and not in the same trust domain. 5GC also provides data storage and analysis services through functions such as Unified Data Management (UDM), Unified Data Repository (UDR), Unstructured Data Storage Function (UDSF), and Network Data Analysis Function (NWDAF). Another key feature of 5GS is network slicing, facilitated by the Network Slice Selection Function (NSSF). Although these network functions are defined as separate logical entities, specific service scenarios may require multiple network functions; for example, WTRU mobility will require not only the AMF but also the AUSF and SMF. For a given type of network function, multiple instances can be instantiated, and the NRF will maintain information for each instantiated network function instance. With the advent of edge computing, some network functions in 5GC (such as UPF and NEF) can be deployed and reside in edge networks, which are closer to the RAN and may co-located with it. 5GS introduces network functions such as Location Management Function (LMF) to support location services. The LMF is responsible for calculating, determining, or validating the final location and any velocity estimates, and can estimate the accuracy achieved based on location information from the target WTRU and / or RAN nodes.After the LMF calculates the location of the target WTRU, other entities can access or query its location in the LMF, but they need to go through the service AMF.

[0063] This article describes a blockchain system. A blockchain system consists of two general types of blockchain nodes: full blockchain nodes – full blockchain nodes have all blockchain functions (e.g., hosting and maintaining the ledger, participating in the consensus protocol to generate new blocks, and verifying received blocks); and light blockchain nodes – light blockchain nodes act as blockchain client nodes, such as digital wallets, which send transactions to the blockchain system via one or more full blockchain nodes.

[0064] Full blockchain nodes are interconnected via a peer-to-peer network; any new transaction or block propagates within the peer-to-peer network according to some routing protocol (e.g., rumor-based routing), ensuring that each full blockchain node has an identical copy of all unprocessed or uncommitted transactions (e.g., unspent transactions) and all blocks containing committed transactions (e.g., spent transactions). Blockchain client nodes have a unique blockchain address as their identifier, which is typically generated by the blockchain client node itself, for example, based on cryptographic and hashing techniques. For instance, a blockchain client node might have a pair of private and public keys; the public key is used to generate its blockchain address, while the private key is used to sign any transaction the blockchain client node will send to the blockchain system.

[0065] While blockchain ledgers are generally append-only and immutable due to their hash-based chain structure, several techniques exist that enable mutable or editable blockchains, where committed blocks can be modified or even removed without breaking the hash-based chain structure. Most of these techniques rely on one or more secure keys (called blockchain edit keys) to generate hash collisions, allowing any party with access to the blockchain edit key to edit or modify existing blocks while maintaining the hash-based ledger structure through these collisions. Blockchain edit keys can be generated or configured when the blockchain system is launched.

[0066] Full blockchain nodes are referred to herein as Blockchain Service Nodes (BSNs), while light blockchain nodes are referred to as Blockchain Client Nodes (BCNs). In embodiments, a device or WTRU can be a BCN (if it uses the blockchain ledger solely as a client) or a BSN (if it maintains the blockchain ledger and supports full blockchain functionality). Since BCNs and BSNs are logical entities, a physical device or WTRU can host one or more instances of a BCN and / or BSN if it has sufficient resources to support them.

[0067] In the embodiments, the blockchain system can be: 1) a permissionless blockchain system (e.g., Bitcoin, Ethereum), in which any party or user can use and participate in the blockchain system without prior authorization; or 2) a permissioned blockchain system, in which permissioned, controlled, and / or governed access to the blockchain system is required. The PDL defined by the ETSI Industry Specification Group (ISG) on Permissioned Distributed Ledgers (PDLs) is an example of a permissioned blockchain system.

[0068] This article discusses the generation of blockchain key material for native wireless blockchains. To interact with a native wireless blockchain, a device needs to be properly authorized to access the blockchain (e.g., a permissioned blockchain system) and support appropriate cryptography (e.g., generating blockchain addresses, signing transactions, etc.), which relies on security keys. Since native wireless blockchains are native (i.e., fully integrated into wireless systems such as 5GS, 6GS, etc.), existing key material in 5GS (e.g., K...) can be considered and utilized. AUSF K SEAF This document describes how to generate these blockchain security keys using 5G key materials. The terms "blockchain security key" and "blockchain key" are used interchangeably in this disclosure. The question is how to utilize 5G key materials to generate the blockchain security keys required for a local wireless blockchain. The process of generating blockchain security keys using 5G key materials can, for example, utilize security keys or credentials already configured in the WTRU (e.g., in the subscriber identity module (SIM card)), thereby avoiding the need to configure new key materials or credentials to support blockchain access.

[0069] This article discusses device selection and notification for wireless blockchain onboarding. To connect devices to a native wireless blockchain, device selection and notification are necessary, although in some cases the device itself can proactively initiate wireless blockchain onboarding. The challenge lies in selecting which devices to connect to the wireless blockchain and how to effectively notify the selected devices. 5GC lacks native wireless blockchain capabilities, and existing network functionalities within 5GC do not include a method for initiating wireless blockchain onboarding. An onboarding process is needed to send information to devices about the network's blockchain capabilities and how the device can contact the blockchain system. Without such a process, devices will be unable to establish a connection with the blockchain system or service without pre-configured information. In some scenarios, pre-configuring data is impossible because the necessary data is unknown when pre-configuration is possible.

[0070] This article discusses on-chaining wireless blockchains. To connect a device to a native wireless blockchain, the device's blockchain address needs to be authenticated, and some blockchain configuration information needs to be configured for the device (e.g., the address of the blockchain service node to which the device can send transactions, and constraints on generating on-chain transactions (e.g., transaction templates, maximum number of transactions allowed within a time period)). Devices require one or more blockchain addresses to interact with one or more native wireless blockchains. Since native wireless blockchains are likely to be permissioned blockchain systems, such as ETSI PDL, device blockchain addresses need to be authenticated, authorized, and managed. Device blockchain address authentication presents at least two challenges: 1) efficiently generating and authenticating device blockchain addresses within the context of a native wireless blockchain; and 2) determining blockchain configuration information for devices with authenticated blockchain addresses. Existing primary and secondary authentication methods in 5GS do not support blockchain address authentication.

[0071] The following terms may be used in this article.

[0072] Equipment: WTRU. Unless otherwise expressly stated, WTRU and WTRU are used interchangeably in this disclosure.

[0073] Network functions: Processing functions in a network (e.g., 5GC).

[0074] Trusted device: refers to a device or WTRU that can be trusted by future cellular wireless systems (such as 6GS). Unless otherwise explicitly stated, trusted device and trusted WTRU are used interchangeably in this disclosure.

[0075] Blockchain Client Node (BCN): This is a lightweight blockchain node that interacts only with blockchain service nodes to send transactions to or retrieve transactions / blocks from them. An example of a blockchain client node is a digital wallet. Blockchain application functionality within the network is another example of a BCN. Unless explicitly stated otherwise, blockchain client nodes and blockchain clients are used interchangeably in this disclosure. A BCN may have a BCAF, such as a BCCCF. A BCN may have multiple BCAFs or BCCCFs.

[0076] Blockchain Service Node (BSN): This is a full blockchain node that implements all the functions of blockchain technology (e.g., maintaining the blockchain ledger, participating in the consensus protocol). A BSN can have a BCSF. A BSN can have multiple BSNs.

[0077] Blockchain Control Function (BCCF): A logical entity or network function that acts as an entry point for devices or applications to interact with the native wireless blockchain for control purposes, such as managing the BCN and BSN.

[0078] Blockchain Service Function (BCSF): A logical entity or network function that acts as an entry point for devices or applications to interact with the native wireless blockchain for data-face purposes such as creating / sending new transactions. BCSF can be part of BSN.

[0079] Blockchain Governance Function (BCGF): A logical entity or network function used to coordinate, govern, and manage the entire native wireless blockchain. BCGF can interact with BCCF, BCSF, and optional other application or network functions (e.g., system management applications).

[0080] Blockchain Application Function (BCAF): A logical entity or application function that can act as a BCN to interact with a BSN (e.g., BCSF) to generate and retrieve transactions. A BCAF may also interact only with other blockchain functions (BCCF, BCGF, and BCSF) to control and manage the native wireless blockchain, but does not necessarily generate any transactions to the blockchain ledger. A BCAF may need to have a blockchain address.

[0081] Blockchain Client and Consumer Function (BCCCF): A BCCCF resides on a BCN node. A BCCCF can also reside within the network or be part of a BSN; when a BSN has a BCCCF, this BCCCF may only be used by the BSN for transaction-based administrative purposes (e.g., the BSN may need to record its actions on the blockchain ledger); in this case, the BCCCF on the BSN can generate new transactions and send them to another BSN. The BCCCF may need to have a blockchain address, which can be assigned or authorized by the BCCF / BCGF; subsequently, the BCCCF can use its authorized blockchain address to consume services provided by the BCSN.

[0082] Identifier: The name / identifier / address of an entity (e.g., a device / WTRU, network function such as 3GPP NF and BCCCF, BCCF, BCSF, BCGF, BCCGF, etc.). Identifiers can be 3GPP identifiers, IP addresses, URLs (Uniform Resource Locators), FQDNs (Fully Qualified Domain Names), blockchain addresses, etc. The entity's identifier implements or provides access details, which other entities can use to access and interact with this entity.

[0083] A blockchain address is an address or identifier that uniquely identifies a blockchain entity (BCN, BSN, BCAF, BCSF, or other blockchain functionality) within a blockchain system. A blockchain address can be the sender or receiver of a blockchain transaction. Blockchain service nodes can also have blockchain addresses, which can be used to send specific transactions (e.g., transactions used to manage the corresponding blockchain system). Blockchain application functionalities can have blockchain addresses. If a BCCF (or BCGF) needs to send transactions to the blockchain ledger (e.g., for administrative purposes, to record its behavioral data into the blockchain ledger), then the BCCF (or BCGF) can have a blockchain address or an embedded BCN or BCAF.

[0084] Blockchain Address Signature: In a permissioned blockchain system, blockchain addresses may require authentication and authorization. Before authorization, a blockchain address may only contain the original blockchain address, typically generated based on a public key. After authorization by an authorizing party (e.g., by BCGF, BCCF, and / or AUSF), it becomes an authorized blockchain address, which can consist of two parts: the original blockchain address and a blockchain address signature; the blockchain address signature can be generated by the authorizing party using a private key. Any party that knows the corresponding public key (associated with the private key used to generate the blockchain address signature) (e.g., a device, BCSF, BCCF) can verify the blockchain address signature.

[0085] Device blockchain address: The blockchain address used for devices in a blockchain system.

[0086] Blockchain ledger: A ledger that stores transactions, blocks, and related system states in a chain-like structure linked by hashes. Each full blockchain node needs to maintain the blockchain ledger. Unless otherwise explicitly stated, blockchain ledger, distributed ledger, and ledger are used interchangeably in this publication.

[0087] Blockchain technology: The set of technologies used in a blockchain system, such as consensus protocols, transaction generation and verification, block generation and verification, and the blockchain ledger. Unless otherwise expressly stated, blockchain technology and distributed ledger technology are used interchangeably in this disclosure.

[0088] Blockchain system: A system that implements or uses blockchain technology. Unless otherwise specified, in this disclosure, a blockchain system is equivalent to a distributed ledger system. A blockchain system typically consists of many light blockchain nodes and a set of full blockchain nodes.

[0089] Native wireless blockchain: A blockchain system that is integrated with and implemented as a component of future cellular wireless systems (such as 6GS). Native wireless blockchain has a set of blockchain-related functionalities, such as, but not limited to, BCCCF, BCCF, BCGF, BCSF, and BCAF; these blockchain-related functionalities can be deployed in the core network, edge network, or even co-located with some powerful devices.

[0090] A transaction is typically a message sent from a sender (e.g., BCN-A, BSN) to a receiver (e.g., BCN-B, BSN). The message may contain information exchanged between the sender and the receiver (e.g., digital currency, data, tokens).

[0091] A block is a data structure that can contain a block header and a block body. The block body can contain a set of transactions. Blocks are typically generated by the BSN as a result of executing the blockchain consensus protocol.

[0092] Wireless blockchain on-chaining: The process of connecting a device to the native wireless blockchain (e.g., generating a blockchain security key for the device, initiating wireless blockchain on-chaining, authenticating the device's blockchain address, configuring the device's blockchain editing capabilities, and publishing the device's public information to the native wireless blockchain).

[0093] Permissioned blockchain systems: Blockchain systems where access to the blockchain ledger (e.g., writing data to the blockchain ledger, reading data from the blockchain ledger, updating / removing data from the blockchain ledger) is only available to a permitted or authorized party (typically governed by BCGF).

[0094] The functionality of the native wireless blockchain system is described in this article. Figure 2 An exemplary native wireless blockchain system and its functionality within a 3GPP system context are illustrated. The blockchain ledgers are shown as 250, 252, and 254. The WTRU can be a light blockchain node hosting the BCAF (shown as, for example, WTRU-1 220) or a full blockchain node hosting the BCSN (shown as, for example, WTRU-2222). In the blockchain control plane, these blockchain-related functions (i.e., BCCCF 220, BCCF 224, BCGF 232, BCSF 222, 226, 236, 240, and BCAF 242) can interact to perform tasks related to configuring and managing the native wireless blockchain system, but not limited to these. For example, BCGF 232 can coordinate the export of blockchain security keys and distribute the exported blockchain security keys to BCCF 230 and BCSF 240. In embodiments, BCGF 232 may need to interact with or be implemented as part of AUSF to export blockchain security keys based on existing 3GPP key materials. 3GPP network functions 228 and 234 are shown in this example.

[0095] exist Figure 2 In the exemplary system, the first WTRU, namely WTRU-1 220, can be a BCCCF. The second WTRU, namely WTRU-2 222, can be a BCSF. BCCF 224 can be mapped to a LAF in a 5G system. For example, BCCF 230 in the core network can be mapped to a centralized LAF; BCCF 230 in the RAN / edge can be mapped to a distributed LAF. BCGF 232 can be mapped to a BCRF. Alternatively, BCGF can be implemented as a new network function. BCCCF can be mapped to BCEF within the WTRU. BCSF 226 can be mapped to a BCEF with full blockchain nodes. In a further embodiment, BCCF 224 can be mapped to a distributed LAF. In an embodiment, BCGF 232 can be mapped to a centralized LAF. Alternatively, BCGF 232 can be implemented as a new network function. BCCCF 220 can be mapped to a BCEF within the WTRU. BCSF (226, 236, 240) can be mapped to a BCEF with full blockchain nodes.

[0096] BCGF and BCCF can identify and select WTRUs that need to be added to the native wireless blockchain system. BCAF can also trigger BCGF to select WTRUs for wireless blockchain onboarding, as further described below.

[0097] In this embodiment, when the WTRU begins its on-chain process to the native wireless blockchain system, it can interact solely with the BCCF, which serves as the entry point for the WTRU. The BCCF can be implemented as part of the AMF or as a standalone NF within the 3GPP core network. During the on-chain process, the BCCF will confirm with the BCGF to determine if the WTRU is authorized to go on-chain. For this purpose, the BCGF may need to interact with a 3GPP NF (e.g., a UDM) to retrieve the WTRU's subscription data, as further described below.

[0098] On the blockchain user side, BCCCF, BCAF, and / or 3GPP NFs can send transactions to or retrieve transactions from the blockchain ledger via BCSF. Transactions and blocks will be propagated and exchanged between BCSFs, for example, via an underlying peer-to-peer network connecting all BCSFs. Each BCSF can directly interface with the blockchain ledger. The blockchain ledger can be deployed at a robust WTRU, in a data network (DN) at the edge, and / or in a DN in the cloud.

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

[0100] Native-BC-ID may include information related to the following: 3GPP-NWK-ID: an identifier for the 3GPP network, which may be a PLMN-ID; Context-ID: a hash 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 name that uniquely identifies the native wireless blockchain within the 3GPP network.

[0101] This article discusses the generation of blockchain key material for native wireless blockchains.

[0102] The following examples of blockchain security keys or blockchain key materials are described, which can be generated independently at both the WTRU and the core network without needing to be exchanged between the WTRU and the core network: K BCGF This is the master security key used for native wireless blockchains. All other blockchain security keys can be based on K. BCGF Export. K BCGF It can be obtained from existing 5G key materials (e.g., K) SEAF K AUSF or K AMF Export. In the core network, K BCGF Maintained and used by the Blockchain Governance Function (BCGF), which governs the entire native wireless blockchain, including authenticating blockchain client nodes and blockchain service nodes. The BCGF is responsible for managing the K... BCGF Export other blockchain security keys; K BCGF It can be used as a blockchain anchor key, from which all other blockchain security keys can be derived; if the native wireless blockchain does not have BCGF, then K is not required. BCGF Furthermore, other blockchain security keys can be obtained directly from existing 5G key materials (e.g., K...). SEAF KAUSF or K AMF Export.

[0103] K BCCF Maintained and used by WTRU and the Blockchain Control Function (BCCF). The BCCF is the entry point for control plane functions of the native wireless blockchain (e.g., connecting devices to the native wireless blockchain). In this embodiment, K BCCF From K BCGF Or existing 5G key materials (e.g., K SEAF K AUSF or K AMF Export. K BCCF It can be used to provide security for the control plane functionality of native wireless blockchains; for example, it can be used from K BCCF Derive one symmetric key for encryption and / or another symmetric key for integrity protection. In other words, K BCCF This is the master key between WTRU and BCCF, and multiple other keys can be derived from it for interaction between WTRU and BCCF. For example, WTRU and BCCF can retrieve the master key from K whenever interaction is needed. BCCF Export the one-time password book (e.g., the one-time password book is K). BCCF And functions that include additional information (such as the time of interaction between the two parties or random numbers known to both parties). In another example, WTRU and BCCF can simply use K. BCCF Used as an encryption / decryption key to securely exchange other security keys or information.

[0104] K BCSF Maintained by WTRU and Blockchain Service Function (BCSF). BCSF is the logical entity used for the data plane functions of the native wireless blockchain (e.g., sending transactions to the native wireless blockchain). K BCSF From K BCGF Or existing 5G key materials (e.g., K SEAF K AUSF or K AMF Export. Note that terms with subscripts [e.g., K] SEAF The symbol ] can appear without a subscript [e.g., KSEAF] and is interchangeable throughout the document. BCSF It can be used to provide security for the data plane functionality of native wireless blockchains; for example, it can be used from K BCSF Derive one symmetric key for encryption and / or another symmetric key for integrity protection. K BCSFThis is the master key between WTRU and BCSF, based on which multiple other keys can be derived and used for interactions between WTRU and BCSF. For example, WTRU and BCSF can derive a one-time keybook from KBCSF each time interaction is needed (e.g., the one-time keybook is K). BCSF And functions that include additional information (such as the time of interaction between the two parties or random numbers known to both parties). In another example, WTRU and BCSF can simply use K BCSF Used as an encryption / decryption key to securely exchange other security keys or information.

[0105] K BCRD Maintained by WTRU and Blockchain Control Function (BCCF). K BCRD It will be used for blockchain editing (BCRD). KBCRD can be obtained from K BCGF Or existing 5G key materials (e.g., K SEAF K AUSF or K AMF Export. Or, K BCRD It can also be maintained by BCGF, BCSF, and other NFs that coordinate blockchain editing.

[0106] In a further embodiment, a flatter blockchain security key hierarchy can be used, as described below.

[0107] BC-Key-Export #1: Can be derived from existing 5G key materials (e.g., K SEAF K AUSF or K AMF ) Export the blockchain anchor key (K) for WTRUs authorized to use the native wireless blockchain. BCA ); KBCA can be with K BCGF Same, and stored at BCGF and WTRU. K BCA Can be with K SEAF or K AUSF same.

[0108] BC-Key-Export #2: One or more additional blockchain security keys can be exported from KBCA for WTRUs authorized to use the native wireless blockchain to protect the integrity and confidentiality of blockchain user plane operations (e.g., reading / writing data to / from the blockchain ledger).

[0109] Secure interactions on the blockchain control plane (including interactions with 3GPP NFs) can reuse existing 3GPP security mechanisms (e.g., network access security via Non-Access Stratum (NAS) signaling, Transport Layer Security (TLS), etc.). The derived blockchain security keys (including KBCAs) can be performed for each native wireless blockchain system. For example, different native wireless blockchain systems can be used for different services, such as NPN and PLMN. The necessary export operations (i.e., BC-key-export #1 and BC-key-export #2) can be performed on the WTRU side and its home PLMN (HPLMN) side. As a result, the two sets of exported blockchain security keys can be stored at the WTRU and BCGF (or AUSF / SEAF), respectively. A third party (e.g., an AF) can provide a blockchain key export service to export blockchain security keys (e.g., BC-key-export #2) and securely share the exported blockchain security keys with the visited PLMN (VPLMN), making it not necessarily necessary to involve the VPLMN in the blockchain security key export.

[0110] This article describes the generation of blockchain key material using BCGF. When a native wireless blockchain and / or 3GPP system has BCGF, BCGF can be responsible for generating blockchain key material within the core network using some blockchain key derivation functions, leveraging existing 5G key material (see [link to documentation]). Figure 3 Independently, WTRU can use the same blockchain key export function to export blockchain key material (see [link]). Figure 4 This ensures 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 process is achieved by the fact that the WTRU has a key configured in the SIM card, and the core network also has the same key configured.

[0111] This article describes the generation of blockchain key material at a core network with BCGF. For example... Figure 3 As shown, the generation of blockchain key materials at the core network is primarily handled by BCGF. First, at 310, network functions such as the Secure Anchor Function (SEAF) receive K... SEAF And use function F in 312 BCGF Export K BCGF And in 314 it is shared with BCGF; then in 321, 323 and 325, BCGF is based on K BCGF Export other blockchain security keys; then at 322, 324, and 326, BCGF shares the exported blockchain security keys with other blockchain-related network functions (such as BCCF and BCSF), which are shown receiving security keys at 340 and 342 respectively. Besides K SEAF In addition, F BCGFThe input can include Native-BC-ID, which is the identifier of the target native wireless blockchain that WTRU will interact with.

[0112] Figure 4 An exemplary process for generating blockchain key material at the WTRU is illustrated, assuming the core network has BCGF. The WTRU can perform operations such as when the WTRU completes master authentication and registers with the core network, or when the WTRU receives a wireless on-chain instruction for network functions (e.g., BCCF, AMF). At 410, the WTRU obtains key material from K... AUSF Export K SEAF If the blockchain key derivation function is not yet standardized, the WTRU can send a request to the core network (e.g., BCGF, BCCF, and / or AMF) to retrieve the same blockchain key derivation function (i.e., F) in 412. BCGF F BCCF F BCRD and F BCSF Alternatively, the core network (e.g., BCGF, BCCF, and / or AMF) may configure or install the same blockchain key export function to the WTRU during or after the WTRU registers with the core network; in 414, the WTRU exports the blockchain key export function F. BCGF From K SEAF Export K BCGF K BCGF = F BCGF (K) SEAF In addition to KSEAF, FBCGF inputs can include Native-BC-ID, which is the identifier of the target native wireless blockchain that the WTRU will interact with. Alternatively, the WTRU can directly obtain it from KSEAF. AUSF K AMF Or other 5G key materials to export K BCGF In step 420, WTRU derives the blockchain key from function F. BCCF From K BCGF Export K BCCF K BCCF = F BCCF (K) BCGF In 422, WTRU derives the blockchain key from function F. BCRD From K BCGF Export K BCRD K BCRD = F BCRD (K) BCGF In 424, WTRU derives the blockchain key from function F. BCSF From K BCGF Export K BCSF K BCSF = F BCSF(K) BCGF ).

[0113] In an exemplary embodiment, WTRU can use K BCCF (or K) BCGF The WTRU then derives its blockchain private key (WTRU-BC-private key); subsequently, the WTRU can derive or determine its blockchain public key (WTRU-BC-Public-Key) from the WTRU-BC-private key; finally, the WTRU can generate its original blockchain address based on the WTRU-BC-Public-Key according to the blockchain address generation function defined by the blockchain address scheme (BC-Addr-Scheme). The WTRU can retrieve this scheme from the core network or the core network can assign it to the WTRU. If the WTRU needs to generate multiple blockchain addresses (WTRU-BC-Addr), the WTRU can do so from K... BCCF (or K) BCGF Exporting multiple WTRU-BC private keys will result in multiple WTRU-BC-Public-Keys (i.e., one WTRU-BC private key corresponds to one WTRU-BC-Public-Key) and multiple blockchain addresses (e.g., one WTRU-BC-Public-Key corresponds to one WTRU-BC-Addr). If K at the core network... BCGF Based on another 5G security key Kx (e.g., K AUSF K AMF (or other 5G key materials) rather than based on K SEAF The K at WTRU is derived from this. BCGF Will use Figure 3 The method is exported from [the source], but the same Kx must be used.

[0114] This article describes the generation of blockchain key material without using BCGF. When the native wireless blockchain does not have BCGF, existing 5G network functions (e.g., SEAF, AUSF, or AMF) can be responsible for generating blockchain key material by utilizing existing 5G system key material using some blockchain key derivation functions (see [link to documentation]). Figure 5 Independently, WTRU can use the same blockchain key export function to export blockchain key material (see [link]). Figure 6 This ensures that the blockchain key material generated by the WTRU will be equal to the blockchain key material generated by the 5G network function. This process is achieved by the fact that the WTRU has a key configured in the SIM card, and the core network also has the same key configured.

[0115] This article describes how to generate blockchain key material in a core network without BCGF. For example... Figure 5As shown, the generation of blockchain key materials at the core network is mainly handled by SEAF. First, SEAF is based on K... SEAF Export K BCCF K BCSF and K BCRD Then it can share K with BCCF. BCCF and K BCRD It can also share K with BCSF. BCSF and K BCRD Alternatively, BCCF can share K with BCSF. BCRD .

[0116] Figure 5 The exemplary process for generating blockchain key material in a core network without BCGF, as shown, includes the following operations at SEAF, BCCF, and BCSF, respectively. In an embodiment, SEAF may perform the following operation to derive K from BCCF. BCCF At 510, SEAF receives K from AUSF. SEAF In 511, SEAF derives the blockchain key from function F. BCCF Export KBCCF from KSEAF, K BCCF = F BCCF (K) SEAF ). Except for K SEAF In addition, F BCCF The input can include Native-BC-ID, which is the identifier of the target native wireless blockchain that the WTRU will interact with. Function F BCCF This could be a normalized function (e.g., a hash function). Or, F BCCF It can be configured differently for different WTRUs or different WTRU groups as part of the WTRU subscription data; in this case, SEAF can retrieve F from the WTRU subscription data stored at UDM. BCCF So that according to K BCCF = F BCCF (K) SEAF Export K BCCF At 512, SEAF sends K to BCCF. BCCF Alternatively, BCCF can request K from SEAF. BCCF Upon receiving a request from BCCF, SEAF exports K. BCCF And send it back to BCCF. At 520, BCCF receives K. BCCF .

[0117] In an embodiment, SEAF may perform the following operations: BCCF and optionally derive K for BCSF. BCRD In 513, SEAF derives the blockchain key from function F. BCRDFrom K SEAF Export K BCRD K BCRD = F BCRD (K) SEAF ). Except for K SEAF In addition, F BCRD The input can include Native-BC-ID, which is the identifier of the target native wireless blockchain that the WTRU will interact with. Function F BCRD This could be a normalized function (e.g., a hash function). Or, F BCRD It can be configured differently for different WTRUs or different WTRU groups as part of the WTRU subscription data; in this case, SEAF can retrieve F from the WTRU subscription data stored at UDM. BCRD So that according to K BCRD = F BCRD (K) SEAF ) Export K=; at 514, SEAF sends K to BCCF BCRD Alternatively, BCCF can request K from SEAF. BCRD Upon receiving a request from BCCF, SEAF exports K. BCRD And send it back to BCCF; and optionally send K in 514. BCRD Send to BCSF, BCSF receives K at 522 BCRD Alternatively, BCSF can request K from SEAF. BCRD Upon receiving a request from BCSF, SEAF exports K. BCRD And send it back to BCSF.

[0118] In this embodiment, SEAF can perform the following operation to derive K from BCSF. BCSF In 515, SEAF derived the blockchain key from the function F. BCSF From K SEAF Export K BCSF K BCSF = F BCSF (K) SEAF ). Except for K SEAF In addition, F BCSF The input can include Native-BC-ID, which is the identifier of the target native wireless blockchain that the WTRU will interact with. Function F BCSF This could be a normalized function (e.g., a hash function). Or, F BCSF It can be configured differently for different WTRUs or different WTRU groups as part of the WTRU subscription data; in this case, SEAF can retrieve F from the WTRU subscription data stored at UDM. BCSF So that according to KBCSF = F=(K SEAF Export K BCSF In 516, SEAF can send K to BCSF. BCSF BCSF receives K in 522 BCSF Alternatively, BCSF can request K from SEAF. BCSF Upon receiving a request from BCSF, SEAF can derive K. BCSF And send it back to BCSF.

[0119] In this embodiment, BCCF can perform the same as... Figure 3 The operation performed by BCGF shown is similar to the operation shown, except that BCCF can directly receive K= and K from SEAF. BCRD In this embodiment, BCSF can perform the same actions as... Figure 3 The operation performed by BCGF shown is similar to the operation shown, except that BCSF can directly receive K from SEAF. BCSF and K BCRD .

[0120] In a further embodiment, as Figure 5 The alternative shown has key K. x Another network function N Fx (For example, AUSF, AMF) can replace SEAF, but perform the same operations as SEAF, directly from K. x Export K BCCF K BCRD and K BCSF .

[0121] This article references Figure 6 An embodiment for generating blockchain key material at the WTRU in the absence of BCGF at the core network is described. In 610, the WTRU can obtain it from K. AUSF Export K SEAF In the absence of standardized blockchain key derivation functions, WTRU can send a request to the core network (e.g., BCCF, AMF) to retrieve the same blockchain key derivation function (i.e., F). BCCF F BCRD and F BCSF Alternatively, the core network (e.g., BCCF, AMF) can configure or install the same blockchain key export function on the WTRU during or after the WTRU registers with the core network; in 612, the WTRU can receive the blockchain key export function from the core network (e.g., BCCF, AMF, or SEAF). Then, using these blockchain key export functions, in 620, 622, and 624, as described below, the WTRU can, based on existing 5G key materials (e.g., K...SEAF Exporting blockchain security keys (e.g., K) BCCF K BCSF and K BCRD The WTRU will not exchange any blockchain security keys with the core network. In this embodiment, the generation of such blockchain key material can be completed by the BCCCF at the WTRU.

[0122] In 620, WTRU can derive function F based on the blockchain key. BCCF From K SEAF Export K BCCF K BCCF = F BCCF (K) SEAF ). Except for K SEAF In addition, F BCCF The input can include Native-BC-ID, which is the identifier of the target native wireless blockchain that the WTRU will interact with. In 622, the WTRU can derive the function F based on the blockchain key. BCRD From K SEAF Export K BCRD K BCRD = F BCRD (K) SEAF ). Except for K SEAF In addition, the input to FBCRD can include Native-BC-ID, which is the identifier of the target native wireless blockchain that the WTRU will interact with. In 624, the WTRU can derive the function F based on the blockchain key. BCSF From K SEAF Export K BCSF K BCSF = F BCSF (K) SEAF ). Except for K SEAF In addition, F BCSF The input can include a Native-BC-ID, which is the identifier of the target native wireless blockchain that the WTRU will interact with. If the K at the core network... BCCF K BCRD and K BCSF From another security key K x (For example, K) AUSF K AMF (or other 5G key materials) instead of from K SEAF The exported blockchain security keys at WTRU (e.g., KBCCF, KBCRD, and KBCSF) can be used. Figure 6 The method is exported from [the source], but the same Kx must be used.

[0123] This document describes an embodiment for configuring blockchain key export functions. The 6GS can configure or specify different blockchain key export functions for different native wireless blockchains (e.g., F...). BCGF F BCCF F BCSF F BCRD Different WTRUs within the 6GS and / or the native wireless blockchain can be configured or specified with different blockchain key export functions (e.g., F). BCGF F BCCF F BCSF F BCRD The same set of blockchain key export functions can be applied to a set of WTRUs. These blockchain key export functions can be stored at UDM / ARPF (Authentication Repository and Processing Function) as part of the WTRU subscription data. These functions can be exchanged between two network functions (e.g., between BCGF and UDM / ARPF); they can also be exchanged between WTRUs and network functions. Each blockchain key export function can describe or specify its input parameters, which may include Native-BC-ID.

[0124] This article describes an example of network-side configuration for blockchain key export functions. Figure 7 An exemplary procedure is shown in which the BCGF (or other network functions, such as the BCCF and AMF) can request one or more blockchain key derivation functions from the UDM / ARPF. At 720, the BCGF 710 can send a request to the UDM / ARPF 714 to obtain a blockchain key derivation function for a target native wireless blockchain that can be applied to one or more WTRUs. In an embodiment, this request may include the following parameters: Native-BC-ID: Identifier of the target native wireless blockchain. If this parameter is not included, the UDM / ARPF may indicate the identifier of the target native wireless blockchain to the BCGF. WTRU-ID: Identifier of the WTRU (e.g., SUCI, 5G-GUTI, SUPI). This parameter is optional if the blockchain key derivation function applies to all WTRUs in the same way or if the BCGF does not have a WTRU-ID. The WTRU-ID may also indicate the blockchain address of the WTRU if the corresponding WTRU currently has a blockchain address and the BCGF knows it. BCGF-ID: Identifier of the BCGF. BC-Key-Derv-Func-Names: Indicates the name of the requested blockchain key derivation function. It can be F BCGF F BCCF F BCSF and / or F BCRD This parameter can also indicate other key-derived functions that can be used to extract keys from K. BCGF KBCCF K BCSF and / or K BCRD Export other blockchain keys. This parameter can indicate "ALL" and / or "ANY", which means request all and / or any available blockchain key export functions.

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

[0126] The request at 720 can first be sent to AUSF 712, and then AUSF 712 can retrieve the blockchain key export function from the UDM / ARPF used for BCGF. The UDM / ARPF 714 used for BCGF can be a UDM / ARPF deployed by the same network (i.e., PLMN) that deploys BCGF.

[0127] The request in 720 can first be sent to the NRF, and then the NRF can determine the blockchain key derivation function based on the information received by the NRF from the PCF (or UDM) serving the WTRU.

[0128] At 722, UDM / ARPF 714 can receive and process the request. If the request contains a WTRU-ID and it is a SUCI, UDM / ARPF can first use the Subscription Identifier De-Hidden Function (SIDF) to convert the SUCI into its corresponding Subscription Persistent Identifier (SUPI). Then, UDM / ARPF uses the SUPI to find and determine the appropriate blockchain key derivation function for the WTRU indicated by the WTRU-ID, assuming these functions are already stored in the WTRU's subscription data. UDM / ARPF can also use the SUPI with other formats of WTRU-IF (e.g., SUCI) to find and determine the appropriate blockchain key derivation function for the WTRU. The determined blockchain key derivation function may only be applicable to one or more target native wireless blockchain networks, which can be determined by UDM / ARPF, especially if the request sent at 720 does not contain a Native-BC-ID.

[0129] At 724, UDM / ARPF 714 can prepare a response containing the blockchain key derivation function determined at 722. UDM / ARPF can send this response to BCGF. This response can first be sent to AUSF, which will forward it to BCGF. If the request sent at 720 was sent to AUSF, the response sent at 724 can be sent by AUSF to BCGF. If the request sent at 720 was sent to NRF, the response sent at 724 can be sent by NRF to BCGF. This response can contain the Native-BC-ID, which is the target native wireless blockchain determined by UDM / ARPF at 722.

[0130] Figure 8 An exemplary procedure is shown for an AMF 812 or AUSF to request configuration of a blockchain key export function to the BCGF 810. At 820, the AMF or AUSF may send a request to the UDM / ARPF 814 to configure / provide the blockchain key export function to the BCGF 810. This request may include the following parameters: Native-BC-ID: Identifier of the target native wireless blockchain. If this parameter is not included, the UDM / ARPF may indicate the identifier of the target native wireless blockchain to the BCGF at 824. AMF-ID (or AUSF-ID): Identifier of the AMF (or AUSF). WTRU-ID: Identifier of the WTRU (e.g., SUCI, 5G-GUTI, SUPI). If the corresponding WTRU currently has a blockchain address and the AMF / AUSF knows it, the WTRU-ID may also indicate the blockchain address of the WTRU. BCGF-ID: Identifier of the BCGF receiving the response at 824. BC-Key-Derv-Func-Names: Equivalent to... Figure 6 BC-Key-Derv-Func-Names as described in section 610.

[0131] In 822, UDM / ARPF can use SUPI (which can be equal to or derived from WTRU-ID) or other formats of WTRU-ID to find and determine the appropriate blockchain key export function for the WTRU indicated by the WTRU-ID, assuming that these functions are stored in the WTRU subscription data.

[0132] The response at 824 may include an AMF (or AUSF) identifier to indicate the entity that sent the request at 820. Alternatively, this response may first be sent to the AMF / AUSF, which will then forward the response to the BCGF or forward the information from the response to the BCGF. This response may include the blockchain key derivation function determined at 822. This response may also include a Native-BC-ID, which is the target native wireless blockchain determined by the UDM / ARPF at 822.

[0133] This article describes an example of WTRU-side configuration for blockchain key export functions. Figure 9 An exemplary process is shown for exchanging blockchain key export functions between the WTRU (e.g., the BCCCF within the WTRU) and the core network via the AMF. Figure 9 In summary: the WTRU sends a first request to a first network function (e.g., AMF / SEAF) to retrieve a blockchain key export function; receives a first response from the first network function (e.g., AMF / SEAF), which may contain one or more blockchain key export functions; stores the blockchain key export functions; uses the first blockchain export function to export a first blockchain key based on a first 3GPP key material (e.g., KSEAF); stores the first blockchain key; uses a second blockchain export function to export a second blockchain key based on the first blockchain key; stores the second blockchain key; uses a third blockchain export function to export a third blockchain key based on the first blockchain key; and stores the third blockchain key.

[0134] Figure 9 Details of the embodiment illustrated in the figure are as follows. At 920, WTRU 910 can send a request to its serving AMF 912. In this embodiment, this request may include the following parameters: Native-BC-ID: 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), UDM / ARPF can indicate the identifier of the target native wireless blockchain to the WTRU at 927, 928, 929. WTRU-ID: Identifier of the WTRU (e.g., SUCI, 5G-GUTI). If the WTRU currently has a blockchain address, the WTRU-ID can also indicate the WTRU's blockchain address. BCGF-ID: Identifier of the BCGF, if the WTRU has already obtained this identifier. BC-Key-Derv-Func-Names: Indicates the name of the requested blockchain key derivation function. It can be F BCGF F BCCF F BCSF and / or F BCRDThis parameter can also indicate other key-derived functions that can be used to extract keys from K. BCGF K BCCF K BCSF and / or K BCRD Export other blockchain keys. This parameter can indicate "ALL" and / or "ANY", which means request all and / or any available blockchain key export functions.

[0135] The information in the request at 920 can be embedded in other Non-Access Stratum (NAS) signaling messages to be exchanged between the WTRU and AMF (e.g., registration requests, registration updates, PDU session establishment requests). The AMF can receive the request at 920 and can select a BCGF for the WTRU based on the WTRU-ID (if the BCGF-ID is not included in the request at 920). At 922, the AMF can request the blockchain key derivation function from BCGF 914.

[0136] In section 924, requests from BCGF 914 to UDM / ARPF 918 can additionally include the AMF identifier (AMF-ID). This is possible if BCGF already includes or has configured a blockchain key derivation function suitable for WTRU (e.g., using...). Figure 7 If the process is not as described in the previous section, this step can be skipped; instead, BCGF can determine the appropriate blockchain key derivation function for WTRU from those locally configured and stored functions and include it in the response to be sent on 928; this response can contain Native-BC-ID, which is the target native wireless blockchain determined by BCGF for WTRU.

[0137] At 926, UDM / ARPF 918 can use SUPI (which can be equal to or derived from WTRU-ID) or other formats of WTRU-ID to look up and determine the appropriate blockchain key export function for the WTRU to interact with the target native wireless blockchain, assuming these functions are stored in the WTRU subscription data. If the request sent at 920 does not contain the Native-BC-ID, or if the Native-BC-ID contained in the request sent at 920 is incorrect, UDM / ARPF can also determine the target native wireless blockchain for the WTRU, for example, based on the WTRU subscription data.

[0138] The response sent from UDM / ARPF to BCGF at 927 may include a Native-BC-ID, which is the target native wireless blockchain identified by UDM / ARPF at 926. Interactions between BCGF and UDM / ARPF are shown at 924, 926, and 927. In an alternative embodiment, the interaction may occur between BCGF and PCF. PCF can use the WTRU-ID to determine the target native wireless blockchain and blockchain key derivation function for the WTRU; PCF can then send the determined target native wireless blockchain and corresponding blockchain key derivation function to BCGF.

[0139] At 928, the BCGF can send a response to the AMF. This response can be the one received at 927 or a response generated by the BCGF. At 929, the AMF can receive the response from the BCGF and forward it to the WTRU. At 930, the WTRU can receive the response sent by the AMF at 929 and can begin deriving its blockchain key using the determined blockchain key derivation function. The WTRU can then use the derived security key to generate its blockchain address. The WTRU can then use its blockchain address to interact with the specified target native wireless blockchain indicated by the Native-BC-ID.

[0140] WTRU can use reference Figure 9 The process described in (920-929) is to retrieve the first blockchain key derivation function (e.g., F). BCGF ), and use the first blockchain key export function to export the first blockchain key (e.g., K). BCGF Then, WTRU can be repeated. Figure 9 Steps 920 to 929, as described above, are used to retrieve the second blockchain key derivation function (e.g., F). BCCF And, using the first blockchain key and second blockchain key export function, derive the second blockchain key (e.g., KBCCF). WTRU can continue. Figure 9 Steps 920 to 929 retrieve other blockchain key export functions and export other blockchain keys. Alternatively, WTRU can use steps 920-928 to retrieve all blockchain key export functions at once, and export all blockchain keys at once in step 930.

[0141] Figure 10 An exemplary procedure is illustrated for exchanging blockchain key derivation functions between the WTRU and the core network during the PDU session establishment process. When the WTRU needs to establish a PDU session for the blockchain user plane (e.g., sending transactions to the blockchain ledger) but needs to derive a blockchain security key to protect the transmission of transactions, in this embodiment, the WTRU can use the following reference... Figure 10An exemplary process is described.

[0142] At 1020, WTRU 1010 can send a PDU session establishment request to its serving AMF 1012. In an embodiment, this request may include the following parameters: Native-BC-ID: 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), UDM / ARPF can indicate the identifier of the target native wireless blockchain to the WTRU at 1030, 1032, and 1034. WTRU-ID: Identifier of the WTRU (e.g., SUCI, 5G-GUTI). If the corresponding WTRU currently has a blockchain address, the WTRU-ID can also indicate the blockchain address of the WTRU. BC-Key-Derv-Func-Names: Indicates the name of the requested blockchain key derivation function, which can be F BCGF F BCCF F BCSF and / or F BCRD This parameter can also indicate other key-derived functions that can be used to extract keys from K. BCGF K BCCF K= and / or K BCRD Export other blockchain keys. This parameter can indicate "ALL" and / or "ANY", which means request all and / or any available blockchain key export functions.

[0143] At 1022, the AMF can receive the request from 1020. Since this request is for PDU session establishment, the AMF can select an SMF. Because the request at 1020 contains "BC-Key-Derv-Func-Names", the AMF can select an SMF capable of retrieving the blockchain key derivation function from the UDM / ARPF. At 1024, the AMF can send an Nsmf_PDUSesson_CreateSMContext request to the selected SMF 1014. In addition to including parameters as defined in existing 3GPP specifications for PDU session establishment, this request can also include the BC-Key-Derv-Func-Names received from the request at 1020. Furthermore, the Data Network Name (DNN) in this request can be set to "NATIVE WIRELESS BLOCKCHAIN" or BC-Name, representing the name of the native wireless blockchain. At 1026, the SMF requests the blockchain key derivation function from the UDM / ARPF 1016. This request can include BC-Key-Derv-Func-Names.

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

[0145] The interaction between the SMF and UDM / ARPF is shown in 1026, 1028, and 1030. Alternatively, the interaction can occur between the SMF and PCF when the SMF establishes a policy association with the PCF for a PDU session. The PCF can use the DNN of the PDU session (which can be set to "NATIVE WIRELESS BLOCKCHAIN" or BC-Name) and S-NSSAI to determine the target native wireless blockchain and the blockchain key derivation function.

[0146] At 1024, the SMF (Short-Terminal Frame) can send an Nsmf_PDUSesson_CreateSMContext response to the AMF (Answer Key Function). This response can include the determined blockchain key derivation function and the Native-BC-ID. At 1034, the AMF can receive the response from the SMF and forward it to the WTRU (WT Root Wire Unit). At 1036, the WTRU can receive the response sent at 1034 and can begin deriving its blockchain key using the determined blockchain key derivation function. The WTRU can then use the derived blockchain key to generate its blockchain address. The WTRU can then use its blockchain address to interact with the specified target native wireless blockchain indicated by the Native-BC-ID.

[0147] WTRU can use reference Figure 10 The process described in (1020-1034) is to retrieve the first blockchain key derivation function (e.g., F). BCGF ), and use the first function to derive the first blockchain key (e.g., K). BCGF Then, WTRU can be referenced repeatedly. Figure 10 The process described in (1020-1036) is to retrieve the second blockchain key derived function (e.g., F). BCCF), and use the first blockchain key and the second function to derive the second blockchain key (e.g., K). BCCF WTRU can continue to be referenced. Figure 10 The process described in (1020-1036) is to retrieve other blockchain key export functions and export other blockchain keys. Alternatively, WTRU can use the reference once. Figure 10 The process described in (1020-1034) retrieves all blockchain key export functions, and as referenced... Figure 10 1036 describes the one-time export of all blockchain keys.

[0148] This document describes an embodiment for UDM to push blockchain-specific parameters to WTRU. As... Figure 11 As an alternative approach, UDM / ARPF can use 3GPP WTRU parameter updates via the UDM control plane process to push blockchain-specific parameters (e.g., BC address, BC access credentials, BC key derivation function (BC-Key-Derv-Func)) to the WTRU. These blockchain-specific parameters can be included in the Blockchain Information Element (BC-IE).

[0149] In one embodiment, at 1120, UDM 1114 may determine that WTRU 1110 is performing a WTRU parameter update (e.g., updating Roaming Guided Routing (SoR) information stored at the WTRU). In another embodiment, this determination may be triggered by the PCF based on certain policies; for example, the policy may describe that when the WTRU's trust index is below a threshold, the WTRU needs to join the native wireless blockchain, thus requiring the WTRU to first be configured with blockchain export functions. In another embodiment, this determination may also be triggered when a new native wireless blockchain is established and the WTRU needs to join this new or different native wireless blockchain. In yet another embodiment, this determination may also be triggered by the Mobile Network Operator (MNO) after a subscription data update for the WTRU (e.g., the blockchain enabling operation is authorized). In yet another embodiment, this determination may also be triggered by the AF after a blockchain configuration update (e.g., blockchain address information update). At 1122, UDM notifies AMF 1112 of the new blockchain-specific parameters by invoking the Nudm_SDM_Notification service operation. This notification message transmitted via the Nudm_SDM_Notification service 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: Parameters related to generating and managing blockchain security-related information (e.g., the blockchain security key at the WTRU, the WTRU's blockchain address, etc.). For example, BC-Security-Para may include: BC-Key-Derv-Func: The blockchain key derivation function determined for the WTRU and applicable to the target native wireless blockchain indicated by Native-BC-ID. This parameter BC-Key-Derv-Func may also contain other necessary input parameters required to run the corresponding blockchain key derivation function. WTRU-BC-Addr-Scheme: The blockchain address scheme that the WTRU may follow to generate its blockchain address. For example, WTRU-BC-Addr-Scheme can be set to "generate a blockchain address using a security key derived from BC-Key-Derv-Func"; in this case, WTRU can first derive a blockchain security key (e.g., a pair of private and public keys of WTRU) from BC-Key-Derv-Func, and then use the derived blockchain security key (e.g., WTRU's public key) to generate its blockchain address.In another example, WTRU-BC-Addr-Scheme can be set to "Generate blockchain address using random security key"; in this case, WTRU can generate its blockchain address using its own private / public key pair without deriving any blockchain security key. In yet another example, WTRU-BC-Addr-Scheme can be set to "Blockchain address assigned by the network," meaning WTRU's blockchain address can be assigned by an NF (e.g., by a BCGF); in this case, the NF's identifier can be additionally included in WTRU-BC-Addr-Scheme. WTRU-BC-Addr: A blockchain address that the network may have generated and is currently assigning to WTRU. If this parameter is included, WTRU-BC-Addr-Scheme may not be necessary.

[0150] Para-for-BC-Control-Plane: Indicates the necessary parameters that enable the WTRU to interact with the control plane of the native wireless blockchain indicated by Native-BC-ID. For example: BCCF-ID: Identifier or address of the specified BCCF that the WTRU can contact. BC-Addr-Registration-Mode: Indicates how the WTRU should register its blockchain address and have it authorized by the network (e.g., BCGF). This parameter can indicate one of the following modes: The WTRU can include its blockchain address in the first WTRU registration request to be sent to its service AMF. The WTRU can include its blockchain address in a WTRU registration update request to be sent to its service AMF. The WTRU can send its blockchain address to its service AMF in a separate NAS message after successful WTRU registration or successful master authentication. Para-for-BC-User-Plane: Indicates the necessary parameters that enable the WTRU to interact with the user plane of the target native wireless blockchain indicated by Native-BC-ID. For example: BCSF-ID: Identifier or address of one or more specified BCSFs that the WTRU can contact to write or retrieve transactions from the target native wireless blockchain. CP-or-UP: Indicates whether the WTRU should use the 3GPP Control Plane (CP) or the 3GPP User Plane (UP) to contact the BCSF. DNN-for-BC: The name of the data network hosting the specified BCSF. The WTRU may include a DNN-for-BC when it requests to establish a PDU session to interact with the specified BCSF. The network can assign different DNN-for-BCs for different native radio blockchains. This parameter can be skipped if CP-or-UP = "CP". WTRU-BC-URSP-ID: An identifier for the UE Routing Policy (URSP) that the WTRU can use to contact the specified BCSF for a PDU session. The UDM can also use this parameter to update the WTRU with a new URSP to be applied to the blockchain's user plane. This parameter, WTRU-BC-URSP-ID, can be skipped if CP-or-UP = "CP". Each BC-IE can correspond to a native radio blockchain. The UPU container can contain one or more BC-IEs as described above.

[0151] At 1124, AMF 1112 can send a DL NAS TRANSPORT message to WTRU 1110. This message may contain a UPU container, which may include the BC-IE received at 1122. At 1126, WTRU can store the UPU container. In an embodiment, WTRU can extract any BC-IE from the UPU container. In an embodiment, WTRU can store the extracted BC-IE. At 1128, WTRU can perform local blockchain-related operations based on the BC-IE. For example, WTRU can create a local BC-IE to store each received BC-IE for a target native wireless blockchain indicated by Native-BC-ID. WTRU can derive the blockchain security key based on BC-Key-Derv-Func. WTRU can record whether each blockchain key function can be successfully executed. If the BC-IE contains WTRU-BC-Addr, WTRU can store it; otherwise, WTRU can generate a blockchain address based on WTRU-BC-Addr-Scheme. WTRU can use WTRU-BC-URSP-ID to locate the URSP stored locally at WTRU. In 1128, in an embodiment, the WTRU can also establish a PDU session with a specified BCSF, for example, based on the WTRU-BC-URSP-ID.

[0152] At 1130, the WTRU can send a UL NAS TRANSPORT message to the AMF. This message may contain a UPU ACK, which can indicate the result (e.g., success or failure) of the local blockchain-related operation performed by the WTRU at 1128 (WTRU-BC-OP-Results), for example, to indicate whether each blockchain key export function was successfully executed at 1128. At 1132, the AMF1112 can use Nudm_SDM_Info to send the UPU ACK received at 1130 to the UDM1114. The UPU ACK may contain WTRU-BC-OP-Results. The UDM can perform additional actions that depend on the WTRU-BC-OP-Results. For example: if the received WTRU-BC-OP-Results indicate that some blockchain key export function failed to execute successfully, the UDM can, as follows: Figure 11As shown in 1122, a new blockchain key derivation function is sent to the WTRU. If the received WTRU-BC-OP-Results indicates that the WTRU cannot find the corresponding URSP indicated by WTRU-BC-URSP-ID, the UDM can trigger the sending of a new URSP for the blockchain user plane to the WTRU. At 1134, the WTRU can contact the designated BCCF and / or the designated BCSF based on the content specified in the received BC-IE and the results of the local blockchain-related operation at 1128. For example, the WTRU can contact the designated BCCF based on BC-Addr-Registration-Mode to register its blockchain address and have it authenticated by the target native wireless blockchain system. The WTRU can contact the designated BCSF using the PDU session established at 1128 based on the designated URSP indicated by WTRU-BC-URSP-ID.

[0153] This article discusses embodiments for device selection and notification for wireless blockchain on-chain.

[0154] The design principles of the embodiments described herein include: 1) considering various needs for initiating wireless blockchain on-chaining; and 2) only allowing authorized parties to select and notify devices used for wireless blockchain on-chaining. The advantages of the embodiments described herein include: 1) applicability to different scenarios; 2) avoiding unnecessary duplication of device selection and notification for wireless blockchain on-chaining; and 3) device selection and notification for wireless blockchain on-chaining is more secure compared to scenarios where any party can perform device selection and notification.

[0155] To connect a device to the native wireless blockchain, the device can initiate the on-chain process itself. However, the device may first need to obtain some initial information (e.g., the address or identifier of the BCCF or BCGF) before starting the on-chain process. Logical entities such as BCGF and BCAF can initiate the wireless blockchain on-chain process and send such initial information (e.g., in the form of a wireless blockchain on-chain instruction) to the device; in the context of 3GPP, UDM can leverage the existing 3GPP "WTRU parameter update via UDM control plane procedure" to push such initial information to the device / WTRU by including the initial information in a UPU container, which is sent from UDM to AMF and forwarded from AMF to the device / WTRU.

[0156] This article discusses several implementation methods for initiating wireless blockchain on-chaining. In the first method, such as Figure 12As shown and described below, the BCGF can first select and determine the devices to be added to the native wireless blockchain. Then, the BCGF can prepare the on-chain instructions for the selected devices. Finally, the BCGF (and / or BCCF) can send the on-chain instructions to the selected devices to initiate the wireless blockchain on-chain process.

[0157] Figure 13 A second method is illustrated below, in which the BCAF (e.g., a management or administrative application) can request to be on-chain from one or more devices. The BCAF can first prepare on-chain instructions; then, the BCAF can send them to the BCCF. The BCCF can request the BCGF to authorize the request from the BCAF. After authorization, the BCCF can send the on-chain instructions to the device to initiate the wireless blockchain on-chain process. Alternatively, another device / WTRU can perform the same operation as the BCAF.

[0158] like Figure 14 The third method, shown and described below, is similar to the second method. The difference is that BCAF will send the on-chain instruction to BCGF (instead of BCCF in the second method).

[0159] A device can also trigger a wireless blockchain onboarding process for another device. Several processes are described.

[0160] Devices can proactively and independently initiate / determine to put themselves on the native wireless blockchain. In this case, no initiation process between the device and the network is required; instead, the device can use the process discussed below to perform the wireless blockchain on-chaining.

[0161] This article discusses an embodiment of device selection and notification for wireless blockchain on-chaining by BCGF.

[0162] Figure 12 An exemplary process for wireless blockchain onboarding initiated by BCGF is illustrated. This process involves three logical entities: 1) BCGF 1214 with the identifier or address BCGF-ID; 2) BCCF 1212 with the identifier or address BCCF-ID; and 3) device 1210 with the identifier or address Dev-ID. Although Figure 12 Only one device, 1210, is shown, but the same process can be applied to initiate wireless blockchain on-chaining for multiple devices. (See reference...) Figure 12 In the described process embodiment, the BCCCF within the device can perform all necessary operations on behalf of the device.

[0163] In step 1221, BCGF 1214 can select one or more devices to be added to the target native wireless blockchain indicated by Native-BC-ID. This device selection can have several scenarios: Location-based: BCGF can decide which devices are located around a specific physical location to add to the blockchain. In an embodiment, BCGF can obtain these devices 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), and can use this information to decide whether to use the target native wireless blockchain for some WTRUs to enable or improve their trustworthiness. The core network (e.g., AMF, SMF) can send a list of these WTRUs to BCGF; BCGF can then select WTRUs / devices from this list to initiate the wireless blockchain addition. Service-based: BCGF can decide to add new BSNs to the target native wireless blockchain to provide closer blockchain functionality to existing BSNs and / or replace some existing BSNs for better performance. To host new BSNs, devices (or AF / NF / edge application servers) need to be selected and added to the target native wireless blockchain. Address-based: Some existing BCNs may need to be re-listened to obtain new or additional blockchain addresses. BCGF can determine which devices hosting BCNs need to be re-listened.

[0164] Also at 1221, the BCGF can determine the list of devices to be (re)on-chain. For each selected device, the BCGF can obtain its identifier in the radio system (e.g., 5GS) from the core network (e.g., Subscription Hidden Identifier (SUCI), Subscription Permanent Identifier (SUPI), 5G Globally Unique Temporary Identifier (5G-GUTI)). Also at 1220, if the selected device is already a BCN or BSN, the BCGF can know the device's blockchain address.

[0165] In an embodiment, the selection at 1221 can be triggered by a request from the AF. The request from the AF can request the triggering of the on-chain process, and the request can include one or more device identifiers and / or identifiers of device groups to which the request applies. In an embodiment, the selection at 1221 can be triggered by a 3GPP NF (e.g., AMF, AUSF, UDM) during or after the device successfully registers with the 3GPP network through primary authentication. Step 1 may be triggered by a 3GPP NF (e.g., AMF, SMF) during or after device 1210 establishes a PDU session through successful secondary authentication.

[0166] In step 1222, for each selected device, BCGF 1214 can select BCCF 1212 as the entry point for that device to the target native wireless blockchain. In an embodiment, the selected BCCF can serve multiple devices. The target native wireless blockchain can have multiple BCCFs, which may be registered to a repository (e.g., NRF in 5GC); the BCGF can then discover BCCFs from the repository. For example, the discovery operation can be performed via NRF. Alternatively, the BCCF may already be registered to the BCGF; the BCGF can maintain a list of registered BCCFs and can directly select a BCCF from this list. Each BCCF can be assigned to serve devices from different locations; the BCGF can then assign a BCCF to a device based on its location. In another example, the BCGF can monitor the load of each BCCF (e.g., the number of devices on the chain via each BCCF) and select the BCCF with the lowest load. In yet another example, the BCGF can select a BCCF that is closer to the selected device and / or has a better communication channel (e.g., higher capacity) for the AMF serving the selected device. The BCGF can reuse the previously selected BCCF for new devices; therefore, the selection at 1222 is optional.

[0167] In 1222, BCGF can generate an authorized blockchain address (Authorized-Dev-BC-Addr) for each selected device; BCGF can also determine a "Dev-BC-Init-Config" for each selected device; "Dev-BC-Init-Config" is described in this document.

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

[0169] BC-Onboarding-Instructions: Contains instructions on when / how the device should begin wireless blockchain onboarding. BC-Onboarding-Instructions may include the following parameters: BC-Onboarding-Addr: Indicates the address or identifier of the BCCF that the device should later contact for wireless blockchain onboarding. BC-Onboarding-Role: Indicates whether the device should onboard as a BCN or BSN. BC-Onboarding-Path: Indicates whether the device should contact the BCCF indicated by BC-Onboarding-Addr using the control plane (e.g., Non-Access Stratum (NAS) signaling) or the user plane (e.g., via PDU session). BC-Onboarding-Policies: Indicates when and / or under what conditions the device can begin onboarding. Policies can be based on one, more, and / or a combination of the following conditions / parameters: 1) BC-Onboarding-Delay: Indicates whether the device should immediately perform wireless blockchain onboarding upon receiving BC-Onboarding-Instructions (e.g., BC-Onboarding-Delay=0) or wait for a fixed or random time interval; 2) When the device successfully generates its blockchain address; 3) When the device enters an area (e.g., a new service area, a new registration area); 4) When the device receives new roaming guidance (SoR) information from the UDM; 5) When the device trust index received from the network is below a threshold; 6) When the device receives a local request from a device user or a local application on the device.

[0170] If BCGF determines Authorized-Dev-BC-Addr and Dev-BC-Init-Config at 1222, both parameters can be included in the request at 1224.

[0171] In step 1226, BCCF 1212 can process wireless blockchain on-chain initiation requests. BCCF can buffer these requests for a period of time, as instructed by BCGF or determined by BCCF. By buffering such initiation requests, BCCF can (re)group devices and use a single request (in step 5) to instruct multiple devices to begin wireless blockchain on-chaining. In step 1226, BCCF can also update Dev-BC-Init-Config to generate a Dev-BC-Final-Config for each device, according to the details described below.

[0172] At 1228, BCCF 1212 can send a wireless blockchain onboarding initiation request to device 1210. This request can include parameters from the request at 1224, such as Native-BC-ID, Dev-ID, BC-Addr-Scheme, BCGF-ID, and BC-Onboarding-Instructions. This request can also include the BCCF-ID. BCCF can send this request to the device via its serving AMF in a 3GPPN1 (NAS) message; BCCF can use the Dev-ID to locate the serving AMF. Alternatively, it can trigger the device to establish a PDU session; for this purpose, the core network may need to send a downlink trigger message to the device; this message can then include blockchain onboarding initiation information as received at 1224. This request can be broadcast to multiple devices; for example, it can be broadcast using the 5G messaging service. After receiving this request, the device can send a response to BCCF indicating successful receipt of the request. The request at 1228 can include Authorized-Dev-BC-Addr and Dev-BC-Final-Config. Immediately following the request at 1228, device 1210 can send an acknowledgment (not shown) to the BCCF, indicating that the request was successfully received.

[0173] At 1230, the BCCF can send a wireless blockchain on-chain initiation response to the BCGF. This response may contain a list of devices that have successfully notified the on-chain initiation at 1228. The BCCF and / or BCGF may maintain the list of devices that have successfully notified the on-chain initiation. In an embodiment, the response made at 1230 may contain Dev-BC-Final-Config.

[0174] In 1232, as an alternative method (marked as Option 2), BCGF can directly send the same wireless blockchain on-chain initiation request to the device as in 1224. After receiving this request from BCGF, the device can send a response to BCGF to indicate that the request was successfully received.

[0175] Immediately following the request at 1232, the device can send an acknowledgment (not shown) to the BCCF indicating that the request at 1232 was successfully received.

[0176] Following the request at 1228 (Option 1) or 1232 (Option 2), the device can store BC-Onboarding-Instructions and other parameters contained in the request received at 1228 (Option 1) or 1232 (Option 2); the device can then generate its blockchain address based on the BC-Addr-Scheme specified in the request received at 1228 (Option 1) or 1232 (Option 2); subsequently, the device can contact the BCCF indicated by the BC-Onboarding-Addr as part of the blockchain onboarding instructions to initiate the wireless blockchain onboarding process, for example, by sending a wireless blockchain onboarding request to the BCCF, as described herein regarding wireless blockchain onboarding. Information received by the device modem in the request at 1228 (Option 1) or 1232 (Option 2) can be sent to a device application hosted on the device; this information can be sent by invoking an API or AT command; this information can then be used by the device application to initiate contact with the BCCF. If the request at 1228 contains Dev-BC-Final-Config, the device can begin interacting with the target native wireless blockchain according to the description of Dev-BC-Final-Config; if the request at 1232 contains Dev-BC-Init-Config, the device can begin interacting with the target native wireless blockchain according to the description of Dev-BC-Init-Config.

[0177] This article describes the device selection and notification process for wireless blockchain on-chaining, conducted by BCAF and through BCCF.

[0178] Figure 13 An embodiment is illustrated whereby a BCAF 1316 (e.g., a management application or a 3GPP NF (e.g., AMF, AUSF, UDM, SMF) or another device B) can initiate a wireless blockchain on-chain process via BCCF 1312. In this embodiment, the BCCF may require BCGF 1314 to authorize the on-chain initiation request received from the BCAF. In this approach, it is assumed that the BCCF has obtained the BCGF's contact information from a repository (e.g., an NRF) or has the BCGF's contact information configured. In this embodiment, the BCCCF within device A can perform all necessary operations on behalf of device A.

[0179] In 1320 (similar to) Figure 12 Device A (1220), BCAF 1316 (or even another device B) can select one or more devices (e.g., device A 1310) to be added to the target native wireless blockchain. BCAF can be used with reference to Figure 12 The same method is described for selecting devices.

[0180] At 1322, the BCAF can obtain contact information for BCCF 1312. In one example, BCAF 1316 may be provided with or configured with BCCF 1312. In another example, the BCAF can discover the BCCF from a repository (e.g., the NRF in the 5GC); when the BCAF discovers the BCCF from the repository (or another network function in the core network), it may need to indicate to the repository the identifier of the selected device at 1320 and / or the identifier of the target native wireless blockchain (if the BCAF knows this); the repository can then find the appropriate BCCF capable of handling those selected devices, assuming each BCCF is registered with the repository.

[0181] In 1324 (similar to) Figure 12 (1224) The BCAF can send a wireless blockchain on-chain initiation request to the BCCF. This request may include the BCAF's identifier (BCAF-ID), but may not include the BC-Addr-Scheme, as the BCAF may not know it or be unable to determine it. This request may include the identifier of the target native wireless blockchain (if the BCAF knows it); the target native wireless blockchain for the selected device (e.g., device A) may be re-determined by the BCGF (1328) or by the BCCF (1332). This request may include the Dev-ID, which is related to... Figure 12 The Dev-ID contained in 1224 is the same. This request may not contain BC-Onboarding-Instructions. If this request contains BC-Onboarding-Instructions, it may indicate a subset of the parameters of BC-Onboarding-Instructions (e.g., BC-Onboarding-Delay).

[0182] In step 1326, the BCCF can receive a wireless blockchain on-chain request from the BCAF and forward it to the BCGF for authorization. In this embodiment, the request may also include the BCCF's identifier (BCCF-ID).

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

[0184] In 1328, BCGF can also generate an authorized blockchain address (Authorized-Dev-BC-Addr) for device A; BCGF can also determine "Dev-BC-Init-Config" for device A; "Dev-BC-Init-Config" is described in this document as follows.

[0185] At 1330: The BCGF can send a response to the BCCF. This response may include: the identifier of the target native wireless blockchain (Native-BC-ID) as determined in 1328; the list of approved devices (Approved-Dev) in 1328; the list of rejected devices (Rejected-Dev) in step 5; the list of partially approved devices (Partially-Approved-Dev) in 1328; the BC-Addr-Scheme as determined in 1328 for each approved device; the BC-Onboarding-Instructions as determined in 1328 for each approved device; and a New-BCCF, indicating another new BCCF (New-BCCF-ID) that can process the partially approved device list.

[0186] If BCGF determines Authorized-Dev-BC-Addr and Dev-BC-Init-Config in 1328, then both parameters can be included in the response made in 1330.

[0187] At 1332, the BCCF can prepare a new wireless blockchain onboarding request based on the original request received at 1334 and the response received at 1330. The BCCF can (re)determine the target native wireless blockchain for the approved device. This new request may only contain the necessary information about and for the device approved at 1328, such as Native-BC-ID, Dev-ID, BC-Addr-Scheme, BC-Onboarding-Instructions, BCCF-ID, and BCAF-ID. The BCCF may need to (re)determine the BC-Addr-Scheme and BC-Onboarding-Instructions for each approved device, especially if the response sent at 1330 did not include the BC-Addr-Scheme and BC-Onboarding-Instructions.

[0188] In 1332 7, BCCF can also update Dev-BC-Init-Config to generate Dev-BC-Final-Config for device A, based on the details described below.

[0189] At 1334, BCCF can send a new wireless blockchain on-chain initiation request to each approved device (e.g., device A); each approved device can send a response back to BCCF indicating successful receipt of this on-chain initiation request. Optionally, BCCF can also send a notification to each partially approved device to inform them of their New-BCCF-ID and BCAF-ID; then each partially approved device can proactively contact its New-BCCF-ID or BCAF to initiate wireless blockchain on-chain. The request at 1334 can include Authorized-Dev-BC-Addr and Dev-BC-Final-Config.

[0190] Following the request at 1334, the device can send an acknowledgment to the BCCF indicating that the request was successfully received.

[0191] At 1336, the BCCF can send a response to the BCAF. This response can indicate the (re)determined Native-BC-ID, Approved-Dev, Partially-Approved-Dev, Rejected-Dev, and New-BCCF-ID. After receiving this response, the BCAF can then contact the new BCCF indicated by the New-BCCF-ID to initiate wireless blockchain on-chaining for the partially approved devices included in the Partially-Approved-Dev.

[0192] Following the request at 1334, Device A can store BC-Onboarding-Instructions and other parameters included in the request; then, Device A can generate its blockchain address according to the BC-Addr-Scheme specified in the request at 1334; subsequently, Device A can contact the BCCF indicated by the BC-Onboarding-Addr as part of the blockchain onboarding instructions to begin the wireless blockchain onboarding process, for example, by sending a wireless blockchain onboarding request to the BCCF, as described below regarding wireless blockchain onboarding. The information received by Device A's modem at 1334 can be sent to the device application hosted on Device A; this information can be sent by calling an API or AT command; this information can then be used by the device application to initiate contact with the BCCF. If the request at 1334 contains Dev-BC-Final-Config (or Dev-BC-Init-Config), Device A can begin interacting with the target native wireless blockchain according to the description of Dev-BC-Final-Config (or Dev-BC-Init-Config).

[0193] This document describes an embodiment for device selection and notification on a wireless blockchain initiated by BCAF 1416 and via BCGF 1414. Figure 14 Another exemplary process is illustrated, in which a BCAF or a 3GPP NF (e.g., AMF, AUSF, UDM, SMF) or another device B can initiate a wireless blockchain on-chain process via the BCGF. The BCGF can authorize the request from the BCAF and can determine the on-chain instructions for the device to be on-chain. The BCGF can then send the on-chain instructions to the device via BCCF 1412. (See reference...) Figure 14 In the described embodiment, the BCCCF within device A 1410 can perform all necessary operations on behalf of device A.

[0194] The device selection at 1420 is similar. Figure 13Device selection at 1320. At 1422, the BCAF can obtain the contact information of the BCGF. In one example, the BCAF may already have the BCGF's contact information configured. In another example, the BCAF can 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 industry, etc. When the BCAF discovers the BCGF from the repository (e.g., NRF or another core network function), it may need to indicate to the repository the identifier of the selected device at 1420 and / or the identifier of the target native wireless blockchain (if the BCAF knows this). The repository can then find the appropriate BCGF capable of handling those selected devices, assuming each BCGF is registered to the repository. The repository can use certain criteria (e.g., for BCGFs of different BCAF-types) to determine the appropriate BCGF for the BCAF.

[0195] The request at 1424 is similar to Figure 13 The request at position 1324. In this embodiment, BCAF can send a wireless blockchain on-chain initiation request to BCGF.

[0196] The authorization at 1426 is similar to Figure 13 The authorization is at point 1328. In an embodiment, the BCGF can authorize the wireless blockchain onboarding initiation request received at point 1424. In one example, some devices may not be allowed to initiate the request by this BCGF. In another example, if the target native wireless blockchain currently has too many onboarded devices, the BCGF can refuse to initiate the request for some or all of the devices included in the request. For each device that the BCGF approves for wireless blockchain onboarding initiation, the BCGF can determine the target native wireless blockchain (Native-BC-ID), BC-Addr-Scheme, and BC-Onboarding-Instructions.

[0197] The BCCF choice at 1428 is similar to Figure 12 The BCCF selection at position 1222. The BCGF can select the BCCF. As part of this step, the BCGF can generate an authorized blockchain address (Authorized-Dev-BC-Addr) for device A; the BCGF can also determine the "Dev-BC-Init-Config" for device A; "Dev-BC-Init-Config" is described below.

[0198] At 1430, the BCGF can send a response to the BCAF. This response may include: the (re)determined identifier of the target native wireless blockchain (Native-BC-ID); the list of devices approved in 1426 (Approved-Dev); the list of any devices rejected in 1426 (Rejected-Dev); the list of devices partially approved in 1426 (Partially-Approved-Dev); and a new-BCGF-ID (determined in 1426 or 1428), indicating another BCGF that can process the partially approved device list.

[0199] If BCGF determines Authorized-Dev-BC-Addr and Dev-BC-Init-Config at 1428, then both parameters can be included in the response at 1430. The request at 1432 is similar to... Figure 13 The request at position 1332. The request at position 1434 is similar. Figure 12 The request at position 1224. The processing at position 1436 is similar. Figure 12 The processing at position 1226. The request at position 1438 is similar. Figure 11 The request at 1128. After receiving this request at 1438, device A can send a response to BCCF to indicate that the request was successfully received; BCCF can forward this response to BCGF; BCGF can forward this response to BCAF.

[0200] Upon receiving the request at 1438, the device can send an acknowledgment to the BCCF indicating that the request was successfully received.

[0201] Upon receiving the request at 1438, Device A can store BC-Onboarding-Instructions and other parameters contained in the received request. Device A can then generate its blockchain address based on the BC-Addr-Scheme specified in the request at 1438. Afterward, Device A can contact the BCCF, as indicated by the BC-Onboarding-Addr (which is part of the blockchain onboarding instructions), to begin the wireless blockchain onboarding process, for example, by sending a wireless blockchain onboarding request to the BCCF, as described below regarding wireless blockchain onboarding. The information received by Device A's modem at 1438 can be sent to the device application hosted on Device A; this information can be sent by calling an API or AT command; the device application can then use this information to initiate contact with the BCCF. If the request at 1438 contains Dev-BC-Final-Config, Device A can use Authorized-Dev-BC-Addr to begin interacting with the target native wireless blockchain according to the description in Dev-BC-Final-Config.

[0202] This document describes an embodiment for device selection and notification for wireless blockchain on-chaining initiated by other devices.

[0203] Figure 15 This illustrates an embodiment of a process where device A 1512, acting as the discoverer, initiates a wireless blockchain onboarding for device B 1510, also acting as the discoverer. Device B can be discovered by device A. During the discovery process, device B can notify device A that it needs to be onboarded to the target native wireless blockchain. Device A can then contact BCCF 1514 to request BC-Onboarding-Instructions for device B. After receiving the BC-Onboarding-Instructions from BCCF, device A can forward the BC-Onboarding-Instructions to device B. Figure 15 In this context, the BCCCF within device A can perform all necessary operations on behalf of device A. Figure 15 In the described embodiment, the BCCCF within device B can perform all necessary operations on behalf of device B.

[0204] The following is for reference. Figure 15The described embodiment can be summarized as follows: a WTRU broadcasts a discovery request, which may instruct a first node to enable other nodes to be on-chain to the native wireless blockchain; a discovery response is received from a second node, which may instruct the second node to request on-chaining to the native wireless blockchain (BC-Onboarding-Indicator); a wireless blockchain onboarding initiation request is sent to a third node (e.g., BCCF), which may indicate the second node as a target node to be on-chained to the native wireless blockchain; a wireless blockchain onboarding initiation response is received from the third node, which may instruct the second node to perform blockchain onboarding; and the wireless blockchain onboarding initiation response is forwarded to the second node.

[0205] At 1520, device A 1512 can broadcast a discovery request to its neighboring devices. This request can include the following parameters: Dev-A-ID: The identifier of device A (e.g., 5G-GUTI, SUCI). Native-BC-ID: The identifier or name of the native wireless blockchain for which device A can request BC-Onboarding-Instructions for other devices. BC-Onboarding-Capability: This parameter can be a binary flag. If this parameter is "TRUE", it indicates that device A can contact the BCCF of the native wireless blockchain indicated by Native-BC-ID to request BC-Onboarding-Instructions for other devices.

[0206] At 1522, Device B 1510 can receive a request from Device A. Device B can accept the discovery request and agree to be discovered by Device A. Device B can also decide to invite Device A to request BC-Onboarding-Instructions. Device B can send a discovery response to Device A. This response can contain the following parameters: BC-Onboarding-Indicator: This parameter can be a binary flag. If this parameter is "true", it indicates that Device B agrees to invite Device A to request BC-Onboarding-Instructions. Dev-B-ID: The identifier of Device B (e.g., 5G-GUTI, SUCI). Native-BC-ID: The identifier or name of the native wireless blockchain that Device B needs to request BC-Onboarding-Instructions from.

[0207] In alternative embodiments 1522 and 1524, as described above (Option 1), device B can broadcast a discovery announcement to its neighboring devices in 1524 (Option 2) so that it can be discovered by other devices (e.g., device A). This discovery announcement may include the following parameters: BC-Onboarding-Indicator: This parameter can be a binary flag. If this parameter is "true", it indicates that device B agrees to invite device A to request BC-Onboarding-Instructions. Dev-B-ID: The identifier of device A (e.g., 5G-GUTI, SUCI). If device A has maintained some BC-Onboarding-Instructions that may be applicable to device B, the processes described below in 1526, 1528, 1530, 1532, 1534, and 1536 can be skipped; instead, device A can select some BC-Onboarding-Instructions maintained for device B and send them to device B in 1538.

[0208] In section 1526, device A can receive a discovery response (1522) or a discovery announcement (1524) from device B. Device A can determine to request BC-Onboarding-Instructions for device B based on certain local policies. An exemplary local policy may contain a list of device identifiers for which device A can request BC-Onboarding-Instructions. Device A can then send a wireless blockchain onboarding initiation request to the BCCF, assuming that device A has obtained the BCCF's contact information (e.g., device A has already onboarded to the native wireless blockchain and therefore knows about the BCCF). This request may include the following parameters: Dev-A-ID: The identifier of device A (e.g., 5G-GUTI, SUCI). Onboarding-Target-Dev-ID: The identifier of the device for which BC-Onboarding-Instructions will be requested (e.g., 5G-GUTI, SUCI). In this case, Onboarding-Target-Dev-ID may be set to the identifier of device B (i.e., Dev-B-ID) and the identifiers of other devices that device A may have discovered and / or may have discovered. Native-BC-ID: An identifier or name of the native wireless blockchain that device A can receive from or that is determined for device B.

[0209] In step 1526, the BCCF can receive a request from device A. In step 1528, the BCCF can forward this request to the BCGF, assuming the BCCF has obtained or knows the BCGF's address or identifier. This request can include the following parameters: Dev-A-ID: Same as in step 1526. Onboarding-Target-Dev-ID: Same as in step 1526. Native-BC-ID: Same as in step 1526, or the BCCF can (re)determine the target native wireless blockchain for the device in the Onboarding-Target-Dev-ID. BCCF-ID: The identifier of the BCCF.

[0210] At 1530, BCGF can receive requests from BCCF. BCGF can (re)determine the target native wireless blockchain for devices in the Onboarding-Target-Dev-ID. BCGF can authorize: 1) whether device A is allowed to request BC-Onboarding-Instructions for the target native wireless blockchain for devices in the Onboarding-Target-Dev-ID; 2) whether devices in the Onboarding-Target-Dev-ID are allowed to receive BC-Onboarding-Instructions; and 3) whether devices in the Onboarding-Target-Dev-ID are allowed to access or interact with the target native wireless blockchain indicated by Native-BC-ID. BCGF can then determine the BC-Addr-Scheme and BC-Onboarding-Instructions for each device in the Onboarding-Target-Dev-ID. BCGF can also determine a list of identifiers for other on-chain target devices to which BC-Onboarding-Instructions can be applied.

[0211] In 1532, BCGF can send a wireless blockchain on-chain response to BCCF. This response may include Native-BC-ID, BC-Addr-Scheme, and BC-Onboarding-Instructions as defined in 1530. This response may also include Onboarding-Target-Dev-ID, which may include Dev-B-ID and identifiers of other on-chain target devices as defined in 1530.

[0212] In 1534, the BCCF can receive a response from the BCGF. The BCCF can process this response (e.g., add its identifier to BC-Onboarding-Instructions, adjust some parameters contained in BC-Onboarding-Instructions, buffer the response for a period of time, etc.).

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

[0214] In 1538, Device A can send a wireless blockchain onboarding notification to each device in the Onboarding-Target-Dev-ID list (e.g., Device B). This notification can contain the same set of parameters as in the response of 1536. Upon receiving this notification, Device B can extract the Native-BC-ID, BC-Addr-Scheme, and BC-Onboarding-Instructions from the notification; then, Device B can generate a blockchain address based on the BC-Addr-Scheme; next, Device B can contact the BCCF or BCGF based on the BC-Onboarding-Instructions. If the Onboarding-Target-Dev-ID in the response from 1536 includes multiple devices, Device A can prepare and send a similar but independent wireless blockchain initiation notification for each of these devices; Device A can also prepare and broadcast similar wireless blockchain initiation notifications to multiple devices in its vicinity.

[0215] After receiving notification 1538, device B can send an acknowledgment to device A, indicating successful reception.

[0216] Figure 16This illustration shows an embodiment of a process where device B 1610, acting as the discoverer, initiates a wireless blockchain onboarding for device A 1612, also acting as the discoverer. In this scenario, device B can be discovered by device A. During the discovery process, device A can notify device B that it needs to onboard to the native wireless blockchain. Device B can then contact BCCF 1614 to request BC-Onboarding-Instructions for the target native wireless blockchain on behalf of device A. After receiving the BC-Onboarding-Instructions from BCCF, device B can forward the BC-Onboarding-Instructions to device A. Figure 16 In this context, the BCCCF within device B can perform all necessary operations on behalf of device B.

[0217] The following is for reference. Figure 16 The described embodiment can be summarized as follows: A WTRU (device B) receives a discovery request, which may indicate the WTRU having a second node's onboarding requirement (BC-Onboarding-Indicator) for the native wireless blockchain; sends a discovery response to the second node, which may indicate the WTRU's ability to onboard other nodes to the native wireless blockchain; sends a wireless blockchain onboarding initiation request to a third node (e.g., BCCF), which may indicate the second node as the target node to be onboarded to the native wireless blockchain; receives a wireless blockchain onboarding initiation response from the third node, which may indicate the blockchain onboarding instructions for the second node; and forwards the wireless blockchain onboarding initiation response to the second node.

[0218] At 1620, device A 1612 can broadcast a discovery request to its neighboring devices. This request may include the following parameters: Native-BC-ID: The identifier or name of the target native wireless blockchain that device A may want to request BC-Onboarding-Instructions for. This parameter is optional. Dev-A-ID: The identifier of device A (e.g., 5G-GUTI, SUCI). BC-Onboarding-Indicator: This parameter can 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.

[0219] At step 1622, device B 1610 can receive a request from step 1. It can accept the discovery request and agree to be discovered by device A. Device B can also decide to request BC-Onboarding-Instructions for device A. Device B can send a discovery response to device A. This response can include the following parameters: Dev-B-ID: The identifier of device B (e.g., 5G-GUTI, SUCI); Native-BC-ID: The name of the target native wireless blockchain for which device B can request BC-Onboarding-Instructions for device A; BC-Onboarding-Capability: This parameter can be a binary flag. If this parameter is "true", it indicates that device B can contact the BCCF of the target native wireless blockchain indicated by BC-Name to request BC-Onboarding-Instructions for device A.

[0220] If device B has maintained some BC-Onboarding-Instructions for the target native wireless blockchain that may be applicable to device A, then processes 1624, 1626, 1628, 1630, 1632, and 1634 described below can be skipped; instead, device B can directly select some maintained BC-Onboarding-Instructions for device A and send them to device A in 1636.

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

[0222] In 1626, BCCF 1614 can receive a request from device B. BCCF 1614 can forward this request to BCGF1616, assuming BCCF has obtained or knows the address or identifier of BCGF. This request can include the following parameters: Dev-B-ID: Same as 1624. Onboarding-Target-Dev-ID: Same as 1624. Native-BC-ID: Same as a624, or BCCF can (re)determine the target native wireless blockchain for the device in Onboarding-Target-Dev-ID. BCCF-ID: The identifier of BCCF.

[0223] At step 1628, the BCGF can receive a request from step 5. The BCGF can (re)determine the target native wireless blockchain for the device in the Onboarding-Target-Dev-ID. It can authorize: 1) whether device B is allowed to request BC-Onboarding-Instructions for the device in the Onboarding-Target-Dev-ID; 2) whether the device in the Onboarding-Target-Dev-ID is allowed to receive BC-Onboarding-Instructions; and 3) whether the device in the Onboarding-Target-Dev-ID is allowed to access or interact with the target native wireless blockchain indicated by the Native-BC-ID. The BCGF can then determine the BC-Addr-Scheme and BC-Onboarding-Instructions for the device in the Onboarding-Target-Dev-ID. The BCGF can also determine a list of identifiers for other on-chain target devices to which the BC-Onboarding-Instructions can be applied.

[0224] At 1630, BCGF can send a wireless blockchain on-chain response to BCCF. This response may include Native-BC-ID, BC-Addr-Scheme, and BC-Onboarding-Instructions as determined in 1628. This response may also include Onboarding-Target-Dev-ID, which may include Dev-A-ID and identifiers of other on-chain target devices as determined in 1628.

[0225] In 1632, the BCCF can receive a response from the BCGF. The BCCF can process this response (e.g., add its identifier to BC-Onboarding-Instructions, adjust some parameters contained in BC-Onboarding-Instructions, buffer the response for a period of time, etc.).

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

[0227] In step 1636, device B can send a wireless blockchain onboarding notification to device A. This notification can contain the same set of parameters as the response sent in step 1634. Upon receiving this notification, device A can extract the Native-BC-ID, BC-Addr-Scheme, and BC-Onboarding-Instructions from the notification; then, device A can generate a blockchain address based on the BC-Addr-Scheme; next, device A can contact the BCCF or BCGF based on the BC-Onboarding-Instructions. If the Onboarding-Target-Dev-ID in the response from step 1634 includes multiple devices, device B can prepare and send a similar but independent wireless blockchain initiation notification for each of these devices; device A can prepare and broadcast a similar wireless blockchain initiation notification for multiple devices in its vicinity.

[0228] Upon receiving notification 1636, device A can send an acknowledgment (not shown) to device B, indicating that the notification was successfully received.

[0229] Figure 17 This illustrates an exemplary process by which device A initiates a wireless blockchain onboarding process with the assistance of device B. In this scenario, device A can be the discoverer or the discoverer of information. Device A receives the address or identifier of the BCCF from another device, B. Device A can then request BC-Onboarding-Instructions for itself. Figure 17 In this context, the BCCCF within device A 1712 can perform all necessary operations on behalf of device A.

[0230] In an embodiment, device A 1712 may use option 1 (1720, 1722), option 2 (1724), or option 3 (1726, 1728) to obtain the address or identifier of BCCF 1714 from another device B 1710.

[0231] At 1720, device A can broadcast a discovery request to its neighboring devices. This request can include the following parameters: Dev-A-ID: The identifier of device A (e.g., 5G-GUTI, SUCI). Native-BC-ID: The identifier or name of the target native wireless blockchain for which device A wishes to request BC-Onboarding-Instructions. BC-Onboarding-Indicator: This parameter can be a binary flag. If this parameter is "true", it indicates that device A needs the BCCF of the native wireless blockchain indicated by BC-Name to request BC-Onboarding-Instructions from it.

[0232] At 1722, Device B can receive the request at 1720. Device B can accept the discovery request and agree to be discovered by Device A. Device B can send a discovery response to Device A. This response can include the following parameters: Dev-B-ID: Identifier of Device B (e.g., 5G-GUTI, SUCI). Native-BC-ID: Identifier or name of the target native wireless blockchain to which the BCCF belongs and / or controls, indicated by the BCCF-ID. BCCF-ID: Identifier of the BCCF of the target native wireless blockchain, indicated by the Native-BC-ID. If Device B has no information about the BCCF, this parameter can be omitted.

[0233] In option 2 (an alternative to 1720 and 1722), in 1724, device B can broadcast a discovery announcement to its neighboring devices so that it can be discovered by other devices (such as device A). This discovery announcement can include the following parameters: Dev-B-ID: same as 1722. Native-BC-ID: same as 1722. BCCF-ID: same as 1722.

[0234] In option 3 (another alternative to 1720 and 1722), at 1726, device B can send a discovery request to device A. This discovery request can include the following parameters: Dev-B-ID: same as 1722. Native-BC-ID: same as 1722. BCCF-ID: same as 1722. At 1728, device A can send a discovery response to device B.

[0235] In 1732, Device A can determine that it is requesting BC-Onboarding-Instructions for itself. Device A can then send a wireless blockchain onboarding initiation request to BCCF 1714. This request can include the following parameters: Dev-A-ID: The identifier of Device A (e.g., 5G-GUTI, SUCI). Native-BC-ID: The identifier or name of the native wireless blockchain for which Device A wishes to request BC-Onboarding-Instructions. Onboarding-Target-Dev-ID: The identifier of the device that will request BC-Onboarding-Instructions (e.g., 5G-GUTI, SUCI). In this case, Onboarding-Target-Dev-ID can be set to the identifier of Device A (i.e., Dev-A-ID).

[0236] In 1732: BCCF can receive a request from device A. BCCF can forward this request to BCGF 1716, assuming BCCF has obtained or knows BCGF's address or identifier. This request can include the following parameters: Dev-A-ID: Same as 1730. Native-BC-ID: Same as 1730, or BCCF can (re)determine the target native wireless blockchain for each device in Onboarding-Target-Dev-ID. Onboarding-Target-Dev-ID: Same as 1730. BCCF-ID: BCCF's identifier.

[0237] At 1734, the BCGF can receive requests from the BCCF. The BCGF can authorize whether device A is allowed to request and receive BC-Onboarding-Instructions for the target native wireless blockchain. The BCGF can then determine the BC-Addr-Scheme and BC-Onboarding-Instructions for device A. The BCGF can (re)determine the target native wireless blockchain for each device in the Onboarding-Target-Dev-ID. The BCGF can also determine a list of identifiers for other on-chain target devices to which BC-Onboarding-Instructions can be applied.

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

[0239] At 1738: BCCF can receive the response at 1736. BCCF can process the response (e.g., add its identifier to BC-Onboarding-Instructions, adjust some parameters contained in BC-Onboarding-Instructions, buffer the response for a period of time, etc.).

[0240] At 1740: The BCCF can send a wireless blockchain initiation response to Device A. This response may include Native-BC-ID, BC-Addr-Scheme, Onboarding-Target-Dev-ID, and BC-Onboarding-Instructions, as received from the BCGF at 1773 and / or adjusted at 1738. Upon receiving this response, Device A can extract the Native-BC-ID, BC-Addr-Scheme, and BC-Onboarding-Instructions from the notification; then, Device A can generate a blockchain address based on the BC-Addr-Scheme; next, Device A can contact the BCCF or BCGF based on the BC-Onboarding-Instructions to access the target native wireless blockchain indicated by the Native-BC-ID.

[0241] The embodiments discussed above can be implemented in a 3GPP system architecture (e.g., 5GS) as follows, as per [reference to...]. Figure 18 As described in the embodiments. Device / BCCCF 1810 can be implemented as part of a 3GPP WTRU. RAN 1812 is shown in the figure. BCCF 1820 can be a new 3GPP network function, or BCCF can be implemented as part of AMF 1816. BCGF 1822 can be a new 3GPP network function, or BCGF can be implemented as part of AUSF 1816. BCAF 1818 can be implemented as a 3GPP AF. Wireless blockchain on-chaining can be initiated as a result or part of a 3GPP process and / or event (e.g., 3GPP WTRU registration, new analysis results about the WTRU, such as uplink traffic flow statistics, etc.).

[0242] This article discusses an implementation example for on-chain initiation of wireless blockchains registered via 3GPP. Figure 19 An exemplary process for initiating wireless blockchain onboarding for a WTRU using 3GPP registration and acceptance messages is illustrated. In this process, WTRU registration and wireless blockchain onboarding initiation are performed jointly. The AMF in this process can perform some functions of the BCGF (e.g., determining BC-Onboarding-Instructions) and also some functions of the BCCF (e.g., sending BC-Onboarding-Instructions to the WTRU). Figure 19 In summary: The WTRU prepares a first information element (BC-Indicator) to indicate that the WTRU can be used as a blockchain node; sends a first request (e.g., registration request) to a first network function (e.g., AMF); the first request may contain a first WTRU identifier and the first information element. A first response (e.g., registration acceptance) is received from the first network function; and the first response may contain the identifier of a second network function (e.g., Blockchain Control Function - BCCF), a blockchain address generation scheme, and blockchain on-chain instructions; the information contained in the first response is stored.

[0243] refer to Figure 19 In 1920, WTRU 1910 can send a registration request (or registration update) message to its service AMF 1912. This message may additionally include a BC-Indicator, which can indicate: 1) WTRU wants to become a BCN; or 2) WTRU wants to become a BSN. If WTRU has previously been on-chain to a native wireless blockchain, the BC-Indicator can also indicate its previous blockchain address (i.e., WTRU-BC-Addr) and the name or identifier of the native wireless blockchain to which it was previously on-chain (i.e., Previous-Native-BC-ID). The WTRU identifier (i.e., WTRU-ID) included in the registration request (1920) can be its SUCI or 5G-GUTI.

[0244] A WTRU may decide or be triggered to include a BC-Indicator based on one or more of the following conditions: A local application on the WTRU triggers a registration update and includes the BC-Indicator in the registration update message. This may occur when a device enters a region (e.g., a new service region, a new registration region); when a device receives new Roaming Bootstrapping (SoR) information from a UDM; or when a device receives a new UPU container from a UDM. It may also occur when the trust index of a device received from the network is below a threshold.

[0245] In step 1920, if the WTRU knows the target native wireless blockchain, it can include its identifier (i.e., Native-BC-ID). In step 1920, the WTRU can instead execute existing 3GPP registration requests or registration updates without indicating any blockchain-related information. The AMF can receive registration request (or registration update) messages from step 1920 and can perform regular WTRU registration, including master authentication. If master authentication fails, the procedures described below (steps 1922, 1924, 1926, 1928, 1930) are not required; otherwise, AMF step 1920 can continue with step 1922.

[0246] In case 1922, there are two possible scenarios: First, if master authentication passes and the registration request (or registration update) message includes the BC-Indicator, the AMF can contact the UDM (or PCF) in case 1914 to check if the WTRU is allowed to join and use the target native wireless blockchain and in what role (e.g., BCN or BSN), for example, based on its subscription data. In this case, the AMF can send the WTRU-ID, Native-BC-ID, and BC-Indicator to the UDM (or PCF). Second, if master authentication passes and 1920 does not include the BC-Indicator, the AMF can still contact the UDM (or PCF) to check if it is necessary to initiate the WTRU on-chaining to the target native wireless blockchain. In this case, the AMF can prepare the BC-Indicator and send it along with the WTRU-ID to the UDM (or PCF).

[0247] In 1924, the UDM (or PCF) could examine the WTRU's subscription data to determine: 1) whether the WTRU was permitted to use / participate in the target native wireless blockchain as a BCN or BSN (for the first case above); or 2) whether there existed a target native wireless blockchain (identified as Native-BC-ID) that the WTRU could use / participate in as a BCN or BSN (for the second case above). The UDM (or PCF) could then send a response to the AMF indicating whether the WTRU was permitted to use / participate in the native wireless blockchain and in what role (e.g., BCN or BSN). For both cases related to 1922, the UDM (or PCF) could (re)determine the WTRU's target native wireless blockchain (Native-BC-ID). When the WTRU was permitted to use the target native wireless blockchain (indicated by the WTRU in 1920 or determined by the UDM (or PCF) in 1924), this meant the WTRU would become a BCN. When the WTRU was permitted to participate in the target native wireless blockchain, the WTRU would become a BSN. If WTRU is not permitted to use / participate in the target native wireless blockchain as a BCN or BSN, UDM will instruct it in 1924, and the procedures described in 1926, 1928, and 1930 will not be required.

[0248] In this embodiment, the interaction between the AMF and UDM at locations 1922 and 1924 can be replaced by the interaction between the AMF and PCF (i.e., replacing the UDM at locations 1922 and 1924 with the PCF). In other words, the AMF can check whether the PCF has any blockchain-related policies for the WTRU and can use these policies to determine whether the WTRU is allowed to use / participate in the target native wireless blockchain as a BCN or BSN.

[0249] In step 4, if the WTRU is allowed to use / participate in the native wireless blockchain, the AMF can select the BCCF for the WTRU. The AMF can search for the BCCF from the NRF. Alternatively, the BCCF may already be included as part of the WTRU subscription data; in this case, the BCCF identifier will be sent from the UDM (or PCF) to the AMF in step 3, so step 4 can be skipped. The AMF can then use... Figure 12 The BCCF selection criteria discussed in step 2.

[0250] If BCCF is not indicated in step 3 or not selected in step 4, steps 5 and 6 can be skipped.

[0251] In step 5, the AMF can determine the Native-BC-ID, BC-Addr-Scheme, and BC-Onboarding-Instructions for the WTRU, especially if the AMF has configured them. If the AMF cannot determine these parameters, it can contact the selected BCCF, which can determine the Native-BC-ID, BC-Addr-Scheme, and BC-Onboarding-Instructions and send them to the AMF. Alternatively, if the AMF cannot determine these parameters, it can contact the AUSF (or PCF) that implements the BCGF functionality, which can determine them and send them to the AMF. The Native-BC-ID, BC-Addr-Scheme, and BC-Onboarding-Instructions may already be stored in the UDM as part of the WTRU subscription data; in this case, these parameters can be sent from the UDM to the AMF in step 3, so step 5 can be skipped. If step 3 is from the PCF to the AMF, the PCF can send the Native-BC-ID, BC-Addr-Scheme, and BC-Onboarding-Instructions to the AMF; therefore, step 5 can be skipped.

[0252] As part of step 5, the AMF can generate an authorized blockchain address (Authorized-WTRU-BC-Addr) for the WTRU; the AMF can also determine the "WTRU-BC-Init-Config" for the WTRU; the "WTRU-BC-Init-Config" is described below. The AMF can obtain these two parameters from the AMF upon successfully authorizing the WTRU's registration request (or registration update).

[0253] In step 6, if the AMF selected a BCCF in step 4, it can send the selected BCCF (BCCF-ID) to the UDM, which will store the BCCF-ID as part of the WTRU subscription data for future use. Otherwise, if step 4 is not performed or a BCCF is not selected in step 4, this step is skipped. If the Native-BC-ID, BC-Addr-Scheme, and BC-Onboarding-Instructions are determined by the AMF (or received by the AMF from the PCF), the AMF can send them to the UDM (or PCF) in step 5. If the AMF determines WTRU-BC-Init-Config and Authorized-WTRU-BC-Addr in step 5, these two parameters can be included in step 6.

[0254] In step 7, the AMF can send a registration acceptance message to the WTRU. In addition to the existing registration acceptance parameters, the registration acceptance message may also include new parameters such as BCCF-ID, Native-BC-ID, BC-Addr-Scheme, WTRU-BC-Init-Config, and BC-Onboarding-Instructions. If step 5 is skipped, the registration acceptance message may omit BC-Onboarding-Instructions and BC-Addr-Scheme, and may instead indicate the error "No BCCF available." If the AMF has determined WTRU-BC-Init-Config and Authorized-WTRU-BC-Addr in step 5, these two parameters can be included in step 7.

[0255] After step 7, the WTRU can store BC-Onboarding-Instructions and other parameters contained in the message received from step 7; then, the WTRU can generate its blockchain address according to the BC-Addr-Scheme specified in step 7; subsequently, the WTRU can contact the BCCF indicated by the BC-Onboarding-Addr as part of the blockchain onboarding instructions to begin the wireless blockchain onboarding process, for example, by sending a wireless blockchain onboarding request to the BCCF, as described below regarding wireless blockchain onboarding. The information received by the WTRU's modem in step 7 can be sent to the device application hosted on the WTRU; this information can be sent by calling an API or AT command; then, this information can be used by the device application to initiate contact with the BCCF for wireless blockchain onboarding. If step 7 includes WTRU-BC-Final-Config (or WTRU-BC-Init-Config) and Authorized-WTRU-BC-Addr, the WTRU can use the Authorized-WTRU-BC-Addr to begin interacting with the target native wireless blockchain according to the description in the WTRU-BC-Final-Config (or WTRU-BC-Init-Config).

[0256] Figure 20 Another procedure is shown for using the 3GPP registration process to additionally notify the registered WTRU of the identifier or address (BCCF-ID) of a selected BCCF. The WTRU can then contact the selected BCCF to retrieve the Native-BC-ID, BC-Addr-Scheme, and BC-Onboarding-Instructions.

[0257] Figure 20 This can be summarized as follows: The WTRU prepares a first information element (BC-Indicator) to indicate that the WTRU can be used as a blockchain node; sends a first request (e.g., a registration request) to a first network function (e.g., AMF); the first request may include a first WTRU identifier and the first information element; receives a first response (e.g., registration acceptance) from the first network function; the first response may include an identifier of a second network function (e.g., Blockchain Control Function - BCCF); sends 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 include the first WTRU identifier and an indication for requesting a blockchain address generation scheme and blockchain on-chain instructions; receives a second response from the second network function; the second response may include the identifier of the second network function, the blockchain address generation scheme, and the blockchain on-chain instructions; the second response may be relayed from the first network function to the WTRU; and stores the information contained in the second response.

[0258] Figure 20 The detailed description of the illustrated embodiment is as follows.

[0259] Registration in 2020 was similar to Figure 19 The registration described at 1920. The 2022 check is similar to that of UDM 2014. Figure 19 The check described at point 1922. The response in 2024 is similar. Figure 19 The response at 1924. The choice in 2026 is similar. Figure 19 The choice described at point 1926.

[0260] In 2028, AMF 2012 can send a registration acceptance message to WTRU 2010. This message can include the identifier of the selected BCCF 2016 (i.e., BCCF-ID) as a hint to WTRU to prepare to receive new messages in 2038, or WTRU can proactively retrieve the "Wireless Blockchain Onboarding Initiation Request" from BCCF via step 8. In other words, upon receiving the BCCF-ID, WTRU knows that BCCF can send a Wireless Blockchain Onboarding Initiation Request directly to itself at any time after 2028 (i.e., the request at 2038). While waiting for the request at 2038, WTRU can proactively or additionally send a request to BCCF in 2034 to retrieve the Native-BC-ID, BC-Addr-Scheme, and BC-Onboarding-Instructions; then, BCCF will send a response to WTRU in 2036.

[0261] If primary authentication fails, the procedures described in 2030, 2032, 2034, 2036, and 2038 are not required.

[0262] By 2030, the AMF can send blockchain instructions, including the WTRU-ID and BC-Indicator, to selected BCCFs. The BC-Indicator can indicate whether the WTRU wants to become a BCN or a BSN.

[0263] In 2032, the BCCF can determine the Native-BC-ID, BC-Addr-Scheme, and BC-Onboarding-Instructions for the WTRU. Alternatively, the process at 2032 can be performed immediately after 2034. Alternatively, the BCCF can invite the AUSF (or PCF) implementing the BCGF functionality to determine the Native-BC-ID, BC-Addr-Scheme, and BC-Onboarding-Instructions for the WTRU; the AUSF (or PCF) can then send the determined Native-BC-ID, BC-Addr-Scheme, and BC-Onboarding-Instructions to the BCCF.

[0264] In 2032, BCCF can also generate an authorized blockchain address (Authorized-WTRU-BC-Addr) for WTRU; BCCF can also determine the "WTRU-BC-Final-Config" for WTRU; "WTRU-BC-Final-Config" is described below. BCCF can obtain these two parameters from the AUSF of a successfully authorized WTRU registration request (or registration update).

[0265] In 2034, WTRU can send a request to BCCF to retrieve Native-BC-ID, BC-Addr-Scheme, and BC-Onboarding-Instructions. This request can be sent as a NAS message and relayed to BCCF by AMF.

[0266] In 2036, the BCCF can send a response to the WTRU containing Native-BC-ID, BC-Addr-Scheme, and BC-Onboarding-Instructions. This response can be sent as a NAS message and relayed to the WTRU by the AMF. If these two parameters are determined at 2032, this response can contain WTRU-BC-Final-Config and Authorized-WTRU-BC-Addr.

[0267] If procedures 2034 and 2036 have been executed, procedure 2038 can be skipped. Alternatively, even if these two procedures have been executed, the BCCF can still send a request to the WTRU in 2038, especially if the BCCF has determined new BC-Onboarding-Instructions for the WTRU.

[0268] At 2038, the BCCF can directly send Native-BC-ID, BC-Addr-Scheme, and BC-Onboarding-Instructions to the WTRU. Procedure 2028 can occur immediately before 2034; in this case, 2034 and 2036 are unnecessary. The request at 2038 can also be used by the BCCF to send new BC-Onboarding-Instructions to the WTRU, even if steps 2034 and 2038 are performed by a WTRU that has not yet been put on-chain. This request at 2038 can be sent as a NAS message and relayed to the WTRU by the AMF. If these two parameters are determined at 2032, the request at 2038 can contain WTRU-BC-Final-Config and Authorized-WTRU-BC-Addr.

[0269] Following the request at 2038, WTRU can send an acknowledgment to BCCF indicating that the request was successfully received.

[0270] After 2036 (or 2038), the WTRU can store BC-Onboarding-Instructions and other parameters contained in the message received in 2036 (or 2038); then, the WTRU can generate its blockchain address according to the BC-Addr-Scheme specified at 2036 (or 2038); subsequently, the WTRU can contact the BCCF, as instructed by the BC-Onboarding-Addr as part of the blockchain onboarding instructions, to initiate the wireless blockchain onboarding process, for example, by sending a wireless blockchain onboarding request to the BCCF, as described below regarding wireless blockchain onboarding. Information received by the WTRU's modem in 2036 (or 2038) can be sent to a device application hosted on the WTRU; this information can be sent by calling an API or AT command; then, this information can be used by the device application to initiate contact with the BCCF for wireless blockchain onboarding. If the response at 2036 (or the request at 2038) contains WTRU-BC-Final-Config (or WTRU-BC-Init-Config) and Authorized-WTRU-BC-Addr, then WTRU can use Authorized-WTRU-BC-Addr to begin interacting with the target native wireless blockchain according to the description of WTRU-BC-Final-Config (or WTRU-BC-Init-Config).

[0271] Figure 21 Another exemplary process for utilizing the 3GPP registration process is shown, in which the AMF first performs 3GPP master authentication for the WTRU. If the master authentication is successful, the AMF can notify the registered WTRU that the registered WTRU can contact the BCCF for wireless blockchain onboarding.

[0272] Request 2120 is similar to Figure 20 The choice at 2122 in 2020 is similar to... Figure 20 2026. If primary authentication fails, 2122 may not be necessary. The acceptance at 2124 is similar to... Figure 20 2028.

[0273] If primary authentication fails, the procedures described in 2126, 2128, 2130, 2132, 2134, and 2136 may not be necessary.

[0274] The sending at 2126 is similar to Figure 20The transmission at 2030. At 2128, the BCCF can contact the UDM to check whether the WTRU is permitted to use / participate in the target native wireless blockchain as a BCN or as a BSN, for example, based on the WTRU's subscription data. The BCCF can send the WTRU-ID and BC-Indicator to the UDM. The UDM then checks the WTRU's subscription data and sends a response to the BCCF indicating whether the WTRU is permitted to use / participate in the target native wireless blockchain and in what role (BCN or BSN). The check at 2128 is similar to... Figure 20 2022 and 2024.

[0275] The process of 2130, 2132, 2134, and 2136 is similar to Figure 20 The processes described at 2032, 2034, 2036 and 2038.

[0276] Following the request in 2136, WTRU can send an acknowledgment to BCCF indicating that the request was successfully received.

[0277] Following the response at 2134 (or the request at 2136), the WTRU can store the BC-Onboarding-Instructions and other parameters contained in the message received from 2134 (or 2136); the WTRU can then generate its blockchain address based on the BC-Addr-Scheme specified at 2134 (or 2136); subsequently, the WTRU can contact the BCCF, as indicated by the BC-Onboarding-Addr as part of the blockchain onboarding instructions, to initiate the wireless blockchain onboarding process, for example, by sending a wireless blockchain onboarding request to the BCCF, as described below regarding wireless blockchain onboarding. The information received by the WTRU's modem at 2134 (or 2136) can be sent to a device application hosted on the WTRU; this information can be sent by invoking an API or AT command; the device application can then use this information to initiate contact with the BCCF for wireless blockchain onboarding. If the response at 2134 (or the request at 2136) contains WTRU-BC-Final-Config (or WTRU-BC-Init-Config) and Authorized-WTRU-BC-Addr, then WTRU can use Authorized-WTRU-BC-Addr to begin interacting with the target native wireless blockchain according to the description of WTRU-BC-Final-Config (or WTRU-BC-Init-Config).

[0278] This article describes the on-chain initiation of a wireless blockchain via 3GPP NWDAF.

[0279] Figure 22 An exemplary process for initiating wireless blockchain onboarding for a WTRU using NWDAF is illustrated. For example, if the WTRU begins to exhibit anomalous behavior from data traffic flow analysis, the network may need to onboard the WTRU to a target native wireless blockchain to monitor and log the WTRU's data traffic behavior accountably. Other 3GPP network functions can use the same process (especially steps 2-6) to initiate wireless blockchain onboarding for WTRUs.

[0280] At 2220, BCCF 2212 can send a request to NWDAF 2214 to subscribe to some analytics results or subscription events (indicated by the Analytics-ID) regarding the WTRU. Based on this, BCCF can determine to initiate a wireless blockchain on-chain request to WTRU 2210. For example, the Analytics-ID could be uplink traffic flow statistics related to the WTRU. BCCF can use such analytics results to identify any potential risks from the WTRU and therefore can proactively request the WTRU to be on-chained to the target native wireless blockchain to record its context and usage data. This request can include the WTRU's identifier (i.e., WTRU-ID), BCCF's identifier (BCCF-ID), and Analytics-ID. BCCF may have already located NWDAF from NRF.

[0281] In 2222, when a subscription event occurs, NWDAF can send a notification to BCCF containing the analysis results corresponding to the Analytics-ID.

[0282] At 2224, the BCCF can receive this notification, based on which it can determine whether the WTRU needs to begin onboarding to the wireless blockchain. For example, if the WTRU's uplink traffic statistics show some abnormal behavior, the BCCF can decide to initiate onboarding of the WTRU to the target native wireless blockchain (Native-BC-ID) (which can be determined by the BCCF), so that the WTRU records its uplink behavior to the target native wireless blockchain, thereby enabling accountable monitoring of the WTRU's uplink behavior. If the BCCF decides that the WTRU does not need to begin onboarding to the wireless blockchain, it can skip the following processes 2226, 2228, and 2230.

[0283] The check at point 2226 is similar to that of UDM. Figure 21 2128.

[0284] The determination at point 2228 is similar to Figure 212130. As part of this process, the BCCF can generate an authorized blockchain address (Authorized-WTRU-BC-Addr) for the WTRU; the BCCF can also determine the "WTRU-BC-Final-Config" for the WTRU; the "WTRU-BC-Final-Config" is described below. The BCCF can obtain these two parameters from the AUSF, which has performed successful master authentication for the WTRU.

[0285] The request at 2230 is similar to Figure 21 The request is at position 2136. If these two parameters are determined at position 2228, the request may include WTRU-BC-Final-Config and Authorized-WTRU-BC-Addr.

[0286] Following the request in 2230, WTRU can send an acknowledgment to BCCF indicating that the request was successfully received.

[0287] Following the request at 2230, the WTRU can store BC-Onboarding-Instructions and other parameters contained in the message received at 2230. The WTRU can then generate its blockchain address based on the BC-Addr-Scheme specified in the request at 2230. Afterward, the WTRU can contact the BCCF, as instructed by the BC-Onboarding-Addr (which is part of the blockchain onboarding instructions), to initiate the wireless blockchain onboarding process, for example, by sending a wireless blockchain onboarding request to the BCCF, as described below regarding wireless blockchain onboarding. Information received by the WTRU's modem at 2230 can be sent to a device application hosted on the WTRU; this information can be sent via API or AT commands; the device application can then use this information to initiate contact with the BCCF for wireless blockchain onboarding. If the request at 2230 contains WTRU-BC-Final-Config (or WTRU-BC-Init-Config) and Authorized-WTRU-BC-Addr, then WTRU can use Authorized-WTRU-BC-Addr to begin interacting with the target native wireless blockchain according to the description of WTRU-BC-Final-Config (or WTRU-BC-Init-Config).

[0288] This document describes an embodiment for on-chain initiation of wireless blockchain via 3GPP AF.

[0289] Figure 23 An exemplary process for initiating wireless blockchain on-chaining for WTRU 2310 using AF 2314 is shown.

[0290] At 2320, BCCF 2312 can register itself with the NRF. The choice at 2322 is similar. Figure 13 The choice at 1320. An AF with the identifier AF-ID can choose one or more WTRUs (WTRU-ID) to start its wireless blockchain on-chain.

[0291] The discovery at 2324 is similar to Figure 13 The discovery was made at point 1322. The AF can select the BCCF from the NRF or via other methods. The AF can interact with the NRF to find the BCCF, especially when the AF is not in the same trust domain as the 3GPP core network, it can interact via the NEF. If the UDM maintains the BCCF's contact information, the AF can find the BCCF from the UDM via the NEF. If the BCCF is implemented as part of the AMF, the AF can obtain the BCCF's contact information from the AMF via the NEF.

[0292] The request at 2326 is similar to Figure 13 The request at position 1324. The AF can send a wireless blockchain on-chain initiation request to the BCCF; this request can be relayed by the NEF, especially when the BCCF is co-located with the AMF and / or the AF is outside the trust domain of the 3GPP core network. This request can include the identifier of the target native wireless blockchain (Native-BC-ID), WTRU-ID, and AF-ID of the WTRU.

[0293] The check at 2328 is similar to Figure 22 The check at 2226. The determination at 2330 is similar. Figure 22 The determination at 2228. The request at 2332 is similar. Figure 22 The request is at position 2228. The message at position 2332 may also contain the AF identifier (i.e., AF-ID). The message at position 2232 may be sent via NAS messages and relayed by the WTRU's service AMF.

[0294] Following the request in 2332, WTRU can send an acknowledgment to BCCF indicating that the request was successfully received.

[0295] The response at 2334 is similar to Figure 13 The response at 1336. The BCCF can send a response to the AF. If the BCCF has identified the WTRU's target native wireless blockchain (Native-BC-ID) at 2330, this response may include the Native-BC-ID. This response may include the WTRU-ID and other parameters sent from the BCCF to the WTRU at 2332.

[0296] Following the request at 2332, the WTRU can store BC-Onboarding-Instructions and other parameters contained in the message received from 2332; then, the WTRU can generate its blockchain address according to the BC-Addr-Scheme specified in the request at 2332; subsequently, the WTRU can contact the BCCF indicated by the BC-Onboarding-Addr as part of the blockchain onboarding instructions to initiate the wireless blockchain onboarding process, for example, by sending a wireless blockchain onboarding request to the BCCF, as described below regarding wireless blockchain onboarding. Information received by the WTRU's modem at 2332 can be sent to a device application hosted on the WTRU; this information can be sent by calling an API or AT command; this information can then be used by the device application to initiate contact with the BCCF for wireless blockchain onboarding. If the request at 2332 contains WTRU-BC-Final-Config (or WTRU-BC-Init-Config) and Authorized-WTRU-BC-Addr, then WTRU can use Authorized-WTRU-BC-Addr to begin interacting with the target native wireless blockchain according to the description of WTRU-BC-Final-Config (or WTRU-BC-Init-Config).

[0297] This document discusses embodiments for the wireless blockchain on-chain process. The design principles of the embodiments described herein include: 1) only authorized or licensed blockchain clients or devices can possess blockchain addresses; 2) device blockchain addresses need to be authenticated and managed by the native wireless blockchain and / or a wireless system integrated with the native wireless blockchain; and 3) as part of the wireless blockchain on-chain process, blockchain system configuration information needs to be configured to the device. The advantages of the embodiments described herein include: 1) the ability to detect transactions from unauthorized blockchain clients and prevent their propagation within the native wireless blockchain, which reduces propagation overhead and improves the system performance of the native wireless blockchain (e.g., the ability to support more BCNs and process more blockchain transactions); and 2) the avoidance of unauthorized blockchain clients and their potential attacks, which improves the system security of the native wireless blockchain.

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

[0299] Alternatively, BCCF can be implemented as a distributed LAF. BCGF can be implemented as a centralized LAF. Alternatively, BCGF can be defined as a new network function. The device can be implemented as a BCEF within a WTRU. BCAF can be implemented as a new entity BCAF.

[0300] This article describes wireless blockchain on-chaining for device blockchain address authentication using BCGF.

[0301] Because the native wireless blockchain is a permissioned blockchain system, both the BCN and BSN of the native wireless blockchain need to be managed and governed. This disclosure proposes that, as part of the wireless blockchain onboarding process, the blockchain address of the BCN or BSN needs to be authenticated. For example, when a device decides to onboard itself to the native wireless blockchain, the device needs to present its blockchain address to the BCCF. The BCCF will request the BCGF to authenticate the device's blockchain address. After the device's blockchain address is authenticated, the BCGF and / or BCCF can generate a blockchain address signature and determine the blockchain configuration information for the device. Only after the blockchain address is authenticated can the device begin using the native wireless blockchain and interact with it according to the content specified in the blockchain configuration information.

[0302] Figure 24 An exemplary process for wireless blockchain on-chaining for device blockchain address authentication using BCGF is illustrated. In this process, there are four logical entities: a device, which may be a WTRU (with BCCCF), which presents its blockchain address (Dev-BC-Addr) to the BCCF / BCGF in the target native wireless blockchain for authentication; a BCGF, responsible for authenticating the device's blockchain address; a BCCF, which can perform the following actions: 1) receiving the Dev-BC-Addr from the device and passing it to the BCGF; 2) generating a blockchain on-chain record; and 3) determining and sending blockchain configuration information to the device; and a BCSF (or multiple BCSFs), through which the BCCF can: 1) send a list of authenticated device blockchain addresses to the BCSF so that the BCSF can perform on-chain control on the user plane of the target native wireless blockchain (e.g., approving transactions from authorized blockchain addresses and rejecting transactions from unauthorized blockchain addresses); and 2) send the blockchain on-chain record to the BCSF so that the BCSF can store it on the target native wireless blockchain (or on a different native wireless blockchain).

[0303] In this process, it is assumed that the BCCF is aware of the BCGF; for example, the BCCF may have already configured 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 been provided with the BCCF.

[0304] At 2420, device 2410 can generate its blockchain address (Dev-BC-Addr), which can be used to generate function F based on the blockchain address. addr Generate: Dev-BC-Addr = F addr (K BCGF ), where K BCGF It is the blockchain security key exported locally by the device; or, Dev-BC-Addr can be calculated as Dev-BC-Addr = F addr (KBCCF). The device could have proactively retrieved function F from the core network before 2420. addr Or, it passively received function F from the core network before 2420. addr ;F addr This can correspond to a blockchain address scheme (BC-Addr-Scheme). For example, KBCGF or KBCCF can first be used to generate a blockchain private key, which will then be used to derive the blockchain public key; then, Dev-BC-Addr can be generated from the blockchain public key. addr It can be one or more hash functions, which may have been standardized, specified as part of the device subscription data stored in the wireless system (e.g., in a UDM), and / or dynamically configured to the device by the core network.

[0305] The generation at address 2420 can be triggered by various events or scenarios, including situations where the device itself determines to record its data on the native wireless blockchain for sharing with other devices or applications. Therefore, the device first needs to generate a blockchain address and then upload it to the native wireless blockchain. In this embodiment, the native wireless blockchain has sent a request to the device instructing it to generate its blockchain address and upload it to the native wireless blockchain, for example, using the process described above.

[0306] As part of the 3GPP WTRU registration, the service AMF can request registered devices / WTRUs to generate blockchain addresses and upload them to the native wireless blockchain.

[0307] At 2422, a device can send a wireless blockchain on-chain request to BCCF 2412, assuming the device has obtained or been configured with a BCCF address / identifier (BCCF-ID). This request can be sent to BCCF via the 3GPP control plane (e.g., using NAS messages) or the user plane (e.g., via a PDU session). This request may include: the device's identifier (i.e., Dev-ID). The Dev-ID can be a Subscription Hidden Identifier (SUCI) or a 5G Globally Unique Temporary Identifier (5G-GUTI). The device's blockchain address (i.e., Dev-BC-Addr). The device's blockchain node type (i.e., Dev-BC-Type). The Dev-BC-Type can indicate whether the device is a BCN or BSN. The device's public key (Dev-Public-Key). The identifier of the target native wireless blockchain to which the device will be on-chain (Native-BC-ID). BC-Addr-Scheme or F addr Indicates how Dev-BC-Addr was generated in 2420 without disclosing any private security keys (e.g., K). BCGF K BCGF ).

[0308] At 2424, the BCCF can receive wireless blockchain on-chain requests from devices. It may need to authenticate these requests, especially when the on-chain request is entirely initiated by the device. To do this, the BCCF can send a Dev-ID to the core network (e.g., UDM, PCF, AUSF), which will check and determine whether the device is allowed to on-chain to the target native wireless blockchain (e.g., based on the device's subscription data and / or any policies associated with the native wireless blockchain). The core network can then send a response to the BCCF indicating whether the request was approved. Alternatively, the BCCF itself can decide whether to approve the on-chain request: 1) For example, if the target native wireless blockchain can accommodate more BCNs or BSNs, the request can be approved; 2) In another example, the BCCF may have already retrieved and locally buffered the device's subscription data and / or related policies from the core network (e.g., UDM, PCF, AUSF), based on which the BCCF can decide whether to approve the on-chain request. Dev-BC-Type can be used to authenticate wireless blockchain on-chain requests; for example, BCCF can approve on-chain requests from BCN while restricting or rejecting requests from BSN; in another example, BCCF can approve on-chain requests that become BSN, but the device will only act as BCN (not the requested BSN), for example, if the device is found to have limited resources.

[0309] In 2426, this is an alternative to 2424. BCCF can simply forward the wireless blockchain on-chain request to BCGF, assuming BCCF has already discovered BCGF 2414. BCGF can perform a similar operation as BCCF did in step 3a to determine whether this request can be approved; then, BCGF can send a response to BCCF indicating whether the request has been approved.

[0310] If the result from 2424 or 2426 is that the wireless blockchain on-chain request was not approved, then you can skip the reference. Figure 24 The process described in 2428 to 2442 is that the BCCF can simply send a response to the device at 2444 indicating that the wireless blockchain on-chain request has not been approved, and can skip the processes in 2446 and 2448.

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

[0312] The processes 2426 and 2428 can be combined into one step; therefore, the BCCF can send only one request to the BCGF; this single request serves the purpose of both steps simultaneously.

[0313] At 2430, BCGF can receive device blockchain address authentication requests. It can begin authenticating Dev-BC-Addr using the following example steps: 1) BCGF can use the Dev-ID to locally look up the K for the device. BCGF (or KBCCF), or request K from the core network (e.g., AUSF or SEAF) for the device. BCGF (or K) BCCF ); 2) BCGF can use the same blockchain address generation function F from step 1. addr Generate a temporary blockchain address (Temp-BC-Addr): Temp-BC-Addr = F addr (K BCGF (or Temp-BC-Addr = F) addr (K BCCF 3) BCGF can compare Temp-BC-Addr and Dev-BC-Addr; if they are equal, Dev-BC-Addr is authorized; if they are different, Dev-BC-Addr is rejected. If Dev-BC-Addr is authorized, BCGF can use its private key (e.g., PriK). BCGFGenerate a blockchain address signature (BC-Addr-Sign) based on the address signature function FSIGN: BC-Addr-Sign = FSIGN (PriK BCGF (Dev-BC-Addr). Know Dev-BC-Addr and PubK. BCGF BC-Addr-Sign can be verified by any other party. PubK BCGF It is the BCGF that corresponds to PriK BCGF The public key. BCGF can append BC-Addr-Sign to Dev-BC-Addr to generate an authorized device blockchain address for the device, where Authorized-Dev-BC-Addr = Dev-BC-Addr + BC-Addr-Sign or Authorized-Dev-BC-Addr = Dev-BC-Addr || BC-Addr-Sign.

[0314] If the Dev-BC-Addr is not authorized, the BCGF can generate a new Dev-BC-Addr and assign it to the device. The BCGF can then still generate an Authorized-Dev-BC-Addr, but based on the new Dev-BC-Addr; in other words, the new Dev-BC-Addr will be included in the Authorized-Dev-BC-Addr.

[0315] At step 2432, the BCGF can send a response to the BCCF indicating whether Dev-BC-Addr is authorized or denied. This response may contain a PubK file generated in step 5. BCGF The response may include FSIGN and Authorized-Dev-BC-Addr. If Authorized-Dev-BC-Addr is based on the new Dev-BC-Addr, this response may include a "new BC address" indicator.

[0316] Optionally, at 2434, the BCCF may send a request to the BCGF instructing an authorized Dev-BC-Addr to retrieve an initial blockchain configuration for the device; the BCGF may receive this request and determine some initial blockchain configuration for the device (i.e., Dev-BC-Init-Config), for example, based on some pre-configured policies at the BCGF and / or any blockchain-related policies in the core network that the BCGF can retrieve (e.g., PCF); then, the BCGF may send the Dev-BC-Init-Config to the BCCF. Dev-BC-Init-Config may contain the following parameters: BCCF-ID: Identifier of the BCCF. BCGF-ID: Identifier of the BCGF. PubK BCGF : BCGF's public key. F SIGNBCGF uses the function at 2430 to generate blockchain address signatures. Dev-BC-Role: Indicates whether the device will or has been assigned as a BCN or BSN. Native-BC-ID: An identifier of the target native wireless blockchain that BCGF can 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 the Dev-BC-Addr at 2422 is invalid. Peer-BC-Addr-List: Authorized blockchain addresses of other devices or nodes acting as BCNs with which the device can exchange transactions. Authorized-BC-Addr-List: A list of authorized blockchain addresses that the device (acting as a BSN) can only serve. In other words, if a device acting as a BSN receives a transaction directly from a BCN not on this list (Authorized-BC-Addr-List), the device can reject the transaction without propagating it to other BSNs. This parameter, Authorized-BC-Addr-List, may only be needed when the device is approved as a BSN. BC-NF-ID: Identifiers or addresses of other blockchain-related functions (e.g., BCEF, LAF, and BCRF) that the device may need to access. Para-for-Accessing-3GPP-NF: A list of parameters for the device (BCN or BSN) to access 3GPP network functions. These parameters can be: NF-ID: Identifier of an NF (e.g., UDM, UDR, PCF, NRF, NEF, NWDAF, LMF, AMF) in the 3GPP network. This parameter NF-ID can contain multiple identifiers—each corresponding to a 3GPP NF. NF-Protocol: The protocol (e.g., TLS, NAS) used to interact with the NF identified by the NF-ID. Para-for-BC-User-Plane: Indicates the necessary parameters that enable the device to interact with the user plane of the target native wireless blockchain indicated by Native-BC-ID. For example: BCSF-ID: The identifier of the selected BCSF that the device can interface with to access the user plane of the target native wireless blockchain (e.g., the device, acting as a BCN, will send transactions to the target native wireless blockchain via the selected BCSF; the device, acting as a BSN, can only interact with those BCSFs acting as BSNs). CP-or-UP: Indicates whether the device should use the 3GPP control plane (CP) or the 3GPP user plane (UP) to contact the BCSF. DNN-for-BC: The name of the data network hosting the specified BCSF. The device can include DNN-for-BC when requesting to establish a PDU session to interact with the specified BCSF. Networks can assign different DNN-for-BCs for different native wireless blockchains.If CP-or-UP = “CP”, this parameter can be skipped. WTRU-BC-URSP-ID: An identifier for the UE routing policy (URSP) that the device can use to contact a PDU session with the specified BCSF. This parameter may include / indicate a new URSP to be applied to the device's blockchain user plane. If CP-or-UP = “CP”, this parameter can be skipped. On-Chain-Tran-Template: A list of parameters that the device must and / or may optionally include in the on-chain transactions that it will generate and send to the selected BCSF. The On-Chain-Tran-Template template may also describe how off-chain transactions are included in on-chain transactions (e.g., generating one on-chain transaction for every N (>1) off-chain transactions, generating one on-chain transaction that includes any off-chain transactions that exceed a threshold age). On-Chain-Tran-Constraints: One or more constraints regarding how the device may or may not send on-chain transactions to the BCSF indicated by BCSF-ID. For example, a constraint may be the maximum number of transactions sent to each BCSF within a configured time period or window. Off-Chain-Tran-Template: A list of parameters that the device will generate and send to the off-chain or microtransactions that must and / or can optionally include in the BCN indicated by the Peer-BC-Addr or other BCNs known to the device. Different Off-Chain-Tran-Templates can be applied to different BCNs. Off-Chain-Tran-Constraints: One or more constraints regarding how the device can or may not send off-chain transactions to the BCN indicated by the Peer-BC-Addr or other BCNs known to the device. For example, a constraint could be the maximum number of off-chain transactions sent to each potential BCN within a configured time period or window. Monitoring-Instructions: One or more monitoring instructions that indicate that the device needs to collect and report a list of blockchain-related parameters (e.g., the number of on-chain transactions sent to the BCSF within a time interval) to the BCCF and / or BCGF.

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

[0318] BCGF can determine Dev-BC-Init-Config in the authorization at 2430 and include it in the response at 2432; in this case, the request at 2434 can be skipped.

[0319] At 2436, the BCCF can select one or more BCSFs (BCSF-IDs) for authorized devices, especially when no BCSF-ID is included in the Dev-BC-Init-Config received from 2434 (or 2432). The selection of BCSFs can be based on different criteria, but is not limited to: If the device is a BCN, the BCCF can select the BCSF closest to the device (e.g., the BCSF in an edge network acting as an edge application server) to reduce latency in sending transactions from the device to the BCSF. If the device is a BSN, the BCCF can select a BCSF to improve connectivity among all BCSFs / BSNs (e.g., each BCSF / BSN has a similar number of neighboring BCSFs / BSNs).

[0320] In 2438, the BCCF can generate the final blockchain configuration (i.e., Dev-BC-Final-Config) for the device, for example, by adding some additional parameters to the Dev-BC-Init-Config received from the BCGF. Some parameters, as described for Dev-BC-Init-Config in 2434, may not actually be included in Dev-BC-Init-Config; therefore, the BCCF can determine these parameters and add them to Dev-BC-Final-Config. Furthermore, the BCCF can add its identifier (i.e., BCCF-ID) and the identifier of the BCSF selected in 2436 to Dev-BC-Final-Config.

[0321] At 2440, BCCF can maintain a blockchain on-chain repository, which contains a list of devices already on-chain (e.g., devices with authorized blockchain addresses). BCCF can update the blockchain on-chain repository by adding authorized devices (e.g., Dev-ID, Authorized-Dev-BC-Addr) to the list.

[0322] In step 2442, the BCCF can send a blockchain-on-chain record to all BCSFs included in the Dev-BC-Final-Config. This record can contain a list of parameters, such as BCCF-ID, Native-BC-ID, Dev-ID, and Dev-BC-Final-Config. This record can also indicate whether the Dev-BC-Addr has been rejected or approved; if approved, or if the BCGF generates a new Authorized-Dev-BC-Addr, this record can include the Authorized-Dev-BC-Addr. Therefore, these BCSFs know the authentication status of the Dev-BC-Addr (i.e., approved / authorized or rejected). The BCSFs can then reject any future transactions with the rejected blockchain address as the sender and / or receiver, which improves the performance and security of the target native wireless blockchain. The BCSFs can store the received blockchain-on-chain record on the native wireless blockchain. The BCCF can also send the blockchain-on-chain record to the BCGF.

[0323] BCGF can create a similar blockchain on-chain record at 2430 and send the record to BCCF in step 6; then BCCF can send the record to BCSF to store it on the target native wireless blockchain or a different native wireless blockchain.

[0324] At 2444, BCCF can send a wireless blockchain on-chain response to the device. This response can indicate whether the device has been authorized or denied, or whether a new address has been generated. If the device has been authorized or a new address has been generated, this response can include Authorized-Dev-BC-Addr and Dev-BC-Final-Config. This response can also include BCCF's public key (PubK). BCGF ) and F SIGN .

[0325] At 2446, the device can receive a response from 2444. It can locally store Authorized-Dev-BC-Addr and Dev-BC-Final-Config. The device can then begin interacting with the native wireless blockchain using the instructions contained in Dev-BC-Final-Config.

[0326] At 2448, the device can begin interacting with the target native wireless blockchain using its Authorized-Dev-BC-Addr. A device acting as a BCN can begin interacting with the designated BCSF according to the Dev-BC-Final-Config; for example, the device can create transactions and send them to the designated BCSF via a 3GPP PDU session or via the 3GPP control plane. After 2446, a device acting as a BSN can also begin interacting with the designated BCSF according to the Dev-BC-Final-Config; for example, the device can download the latest blockchain ledger from the designated BCSF to synchronize it with the designated BCSF. The device can also use Para-for-Accessing-3GPP-NF to access designated 3GPP network functions (e.g., discovering other functions from 3GPP NRFs) as needed. The device can also use BC-NF-ID to access other blockchain functions (e.g., BCRFs).

[0327] This article describes an embodiment for wireless blockchain on-chaining of blockchain addresses generated by the network.

[0328] As part of the wireless blockchain on-chain process, the device's blockchain address for the native wireless blockchain can be generated and assigned to the device by BCGF (or BCCF). Figure 25 An exemplary process for this scenario is shown.

[0329] The request at 2520 is similar to Figure 24 The request at 2422. However, this step may not include Dev-BC-Addr. The authorization request at 2522 is similar. Figure 24 The authorization request at position 2424. The authorization request at position 2524 is similar to... Figure 24 The authorization request at 2424. If authorization at 2522 or 2524 fails, the procedures described for 2526 to 2540 and 2544 to 2548 can be skipped; then, the BCCF can send a rejection to device 2510 at 2542.

[0330] At 2536, BCCF 2512 can send a blockchain address generation request to BCGF 2514. This request can include Dev-ID and Native-BC-ID.

[0331] At 2528, BCGF can receive requests from 2526. BCGF can use the following exemplary steps based on the blockchain address scheme (BC-Addr-Scheme) or the blockchain address generation function (F... addrGenerates a blockchain address for the device: The BCGF can determine the target native wireless blockchain (Native-BC-ID) for the device. The BCGF can obtain the Native-BC-ID from the core network (e.g., UDM, PCF, or AUSF). The BCGF can use the Dev-ID and / or Native-BC-ID to locally find / export the device's K. BCGF (or K) BCCF ), or request the device's K from the core network (e.g., AUSF or SEAF). BCGF (or K) BCCF BCGF can determine the BC-Addr-Scheme or F applicable to the target native wireless blockchain of the device. addr BCGF can obtain these two parameters from the core network (e.g., UDM, PCF, or AUSF). BCGF can use BC-Addr-Scheme or F... addr Generate device blockchain address (Dev-BC-Addr): Dev-BC-Addr = F addr (K BCGF (or Dev-BC-Addr = F) addr (K BCCF BCGF can use its private key (e.g., PriK). BCGF Generate a blockchain address signature (BC-Addr-Sign) based on the address signature function FSIGN: BC-Addr-Sign = FSIGN (PriK BCGF (Dev-BC-Addr). Any other party that knows Dev-BC-Addr and PubKBCGF can verify BC-Addr-Sign. PubK BCGF It is the BCGF that corresponds to PriK BCGF The public key.

[0332] BCGF can attach BC-Addr-Sign to Dev-BC-Addr to generate an authorized device blockchain address for the device, where Authorized-Dev-BC-Addr = Dev-BC-Addr + BC-Addr-Sign or Authorized-Dev-BC-Addr = Dev-BC-Addr || BC-Addr-Sign. At step 2530, BCGF can send a blockchain address to BCCF to generate a response. This response may include, for example, the Native-BC-ID and PubK generated in step 4. BCGF BC-Addr-Scheme (or F addrBoth BCGF and BCCF can mark Authorized-Dev-BC-Addr as the authorized blockchain address of a device.

[0333] Processes 2532, 2534, 2536, 2538, and 2540 are similar. Figure 24 2436, 2438, 2440, 2442 and 2444.

[0334] Creating an on-chain record at position 2540 is similar to... Figure 24 At position 2442. The response at position 2542 can contain Authorized-Dev-BC-Addr, BC-Addr-Scheme (or F... addr PubK BCGF And Native-BC-ID.

[0335] In 2544, the device can verify Authorized-Dev-BC-Addr to confirm whether the BC-Addr-Sign contained in Authorized-Dev-BC-Addr was created by BCGF using BC-Addr-Scheme (or F addr The device uses PubKBCGF to generate the BC-Addr. If Authorized-Dev-BC-Addr is valid (e.g., generated by BCGF), the device can proceed with the procedures at 2546 and 2548; otherwise, they can be skipped. The device may already have BC-Addr-Scheme (or F) pre-configured. addr ) and PubK BCGF These two parameters have been retrieved / received from the core network (e.g., UDM, BCGF, AUSF, PCF) or have been received at 2542.

[0336] The storage at 2546 is similar to Figure 24 Storage at location 2446.

[0337] In section 2548, a device can initiate interaction with the native wireless blockchain based on the received Dev-BC-Final-Config. A device acting as a BCN can use the received Authorized-Dev-BC-Addr to initiate interaction with the designated BCSF according to the Dev-BC-Final-Config; for example, the device can create transactions and send them to the designated BCSF via a 3GPP PDU session or via the 3GPP control plane. A device acting as a BSN can also initiate interaction with the designated BCSF according to the Dev-BC-Final-Config; for example, the device can download the latest blockchain ledger from the designated BCSF to synchronize it with the designated BCSF. The device can also use Para-for-Accessing-3GPP-NF as needed to access designated 3GPP network functions (e.g., discovering other functions from 3GPP NRFs). The device can also use BC-NF-ID to access other blockchain functions (e.g., BCRFs).

[0338] This article describes an embodiment for wireless blockchain on-chaining using random device blockchain addresses.

[0339] Devices can generate their blockchain addresses arbitrarily, without adhering to any blockchain addressing scheme. For example, a device can generate a random blockchain address from its pair of private and public keys. The device's private key may not be shared or disclosed to any party; as a result, other parties cannot authorize or verify this random blockchain address because the device's private key is unknown to them. This paper proposes that devices can present verifiable credentials (VCs) to other parties, who can then verify these VCs. If the VC is verified, the device's blockchain address is authenticated. Figure 26 An exemplary process for this scenario is shown.

[0340] The generation at 2620 is similar to Figure 24 The generation occurs at point 2420. Device 2610 can generate its blockchain address (Dev-BC-Addr) using its private / public key pair. The device can sign the Dev-BC-Addr using its public key (Dev-Public-Key); therefore, the Dev-BC-Addr can contain a blockchain address signature. The device can prepare verifiable credentials (Dev-VC), which may be received from another party (e.g., a VC-Issuer). The Dev-BC-Addr can be included as part of the Dev-VC.

[0341] The request at 2622 is similar to Figure 24 The request is at position 2422. This step may include Dev-VC and Dev-Public-Key.

[0342] The requests at 2624 and 2626 are similar to Figure 24 2424 and 2426.

[0343] The request at 2628 is similar to Figure 24 The request at position 2428. This request may contain Dev-VC and Dev-Public-Key.

[0344] The authorization at 2630 is similar to Figure 24 The authorization at 2430. BCGF can perform the following operations: Verify the blockchain address signature contained in Dev-BC-Addr using the device's public key (Dev-Public-Key). If Dev-BC-Addr is valid, BCGF can verify Dev-VC using the VC-Issuer's public key, which BCGF may already know or be able to retrieve from the target native wireless blockchain (or another native wireless blockchain). If Dev-VC is valid, BCGF can use its private key (e.g., PriK). BCGF According to the address signature function F SIGN Generate blockchain address signature (BC-Addr-Sign): BC-Addr-Sign = FSIGN (PriK BCGF (Dev-BC-Addr). Know Dev-BC-Addr and PubK. BCGF BC-Addr-Sign can be verified by any other party. PubK BCGF It corresponds to PriK BCGF The public key of BCGF. BCGF can append BC-Addr-Sign to Dev-BC-Addr to generate an authorized device blockchain address for the device, where Authorized-Dev-BC-Addr = Dev-BC-Addr + BC-Addr-Sign or Authorized-Dev-BC-Addr = Dev-BC-Addr || BC-Addr-Sign.

[0345] In step 5, if Dev-BC-Addr is not authorized, BCGF can generate a new Dev-BC-Addr and assign it to the device. Then, BCGF can still generate Authorized-Dev-BC-Addr, but based on the new Dev-BC-Addr; in other words, the new Dev-BC-Addr will be included in Authorized-Dev-BC-Addr.

[0346] The processes described in 2632, 2634, 2636, 2638, and 2640 are similar to those described in Figure 24The processes described in 2432, 2434, 2436, 2438 and 2440.

[0347] Creating a record at position 2642 is similar to... Figure 24 At position 2442. The on-chain record generated in this step may contain the identifier (VC-Issuer-ID) of the VC-Issuer that generates the Dev-VC for the device.

[0348] The response at 2644 is similar to Figure 24 The response at position 2444.

[0349] The storage at 2646 is similar to Figure 24 Storage at location 2446.

[0350] The interaction at point 2648 is similar to Figure 24 The interaction at point 2448. The device can also use Para-for-Accessing-3GPP-NF as needed to access specified 3GPP network functions (e.g., discovering other functions from 3GPP NRF). The device can also use BC-NF-ID to access other blockchain functions (e.g., BCRF).

[0351] This article describes an implementation of wireless blockchain on-chaining for WTRU assisted by AUSF and AMF.

[0352] The first 3GPP embodiment for wireless blockchain on-chaining for WTRU assisted by AUSF and AMF Figure 27 The diagram in the middle is shown.

[0353] The device can be implemented as part of a 3GPP WTRU. The BCCF can be implemented as a new 3GPP network function. Alternatively, the BCCF can be implemented as part of an AMF. The BCGF can be implemented as part of an AUSF. The BCSF1 can be implemented as a new 3GPP network function. Alternatively, the BCSF can be implemented as part of a UDR or UDSR. The BCSF can also be part of an Edge Application Server (EAS) or AF.

[0354] Figure 27The process can be summarized as follows: WTRU 2710 generates a first blockchain address for the WTRU (WTRU-BC-Addr); prepares a first request for requesting to join the wireless blockchain; the first request may include a WTRU identifier, a blockchain flag, the first blockchain address, and the blockchain node type the WTRU requests to become (WTRU-BC-Type, such as BCN or BSN); sends the first request 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) based on the blockchain flag; receives 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 whether the first blockchain address is authorized; the first response may indicate whether the blockchain node type requested by the WTRU is authorized; the first response may contain a first information element (WTRU-BC-Final-Config) regarding the WTRU's blockchain configuration information, which is determined by the second network function. The first information element may contain an identifier of the second network function; the first information element may contain monitoring instructions that the WTRU needs to follow to report its blockchain statistics to the second network function. Store the first information element; and use the authorized first blockchain address to interact with the native wireless blockchain based on the first information element.

[0355] Figure 27 The illustrated embodiment may include the following steps: The generation at 2730 is similar to Figure 24 WTRU 2710 can generate its blockchain address (WTRU-BC-Addr, and...). Figure 24 (The Dev-BC-Addr is the same in K), for example, according to K BCGF (or K) BCCF The WTRU may have already received the BC-Addr-Scheme from AMF 2712 as a result of 3GPP procedures (e.g., registration, registration update, WTRU parameter update, etc.). BCGF (or F) BCCF ), and may have been based on F BCGF (or F) BCCF K was exported BCGF (or K) BCCF ).

[0356] In 2730, WTRU can use its public key (WTRU-Public-Key) to generate its random blockchain address without relying on other derived blockchain security keys.

[0357] The request at position 2732 is similar to Figure 24 The request at position 2422. The WTRU-ID can be the WTRU's SUCI or 5G-GUTI, which is equivalent to... Figure 24 The Dev-ID in WTRU-BC-Type is equivalent to... Figure 24 Dev-BC-Type in the middle.

[0358] This request at position 2732 may include BCCF-ID, Native-BC-ID, and / or BC-Addr-Scheme. The request at position 2732 may also include another parameter, BC-Flag. If BC-Flag = TRUE, the AMF treats this request as a blockchain-related request and forwards it to the BCCF. This request at position 2732 may be included as part of a 3GPP NAS message (e.g., a registration request, registration update).

[0359] If WTRU generated its random blockchain address at 2730, this step can include BC-Addr-Scheme and WTRU-Public-Key. The included BC-Addr-Scheme can be set to "random blockchain address".

[0360] If the request at 2732 is a registration request (or registration update), the AMF can perform a regular master authentication. If the master authentication is successful and the registration will be accepted, the AMF can continue with the following steps; otherwise, the following steps can be skipped, and the AMF can simply indicate "blockchain on-chain rejection" in the registration acceptance to be sent to the WTRU.

[0361] At 2734, the AMF can receive requests from 2732. If BC-Flag = TRUE, the AMF can choose to serve the BCCF of the target native wireless blockchain indicated by the Native-BC-ID (e.g., discovering one or more BCCFs from the NRF); if the AMF already has a BCCF, or if BCCF-ID is contained in 2732, it can choose or not choose a different BCCF. The identifier of the selected BCCF is the BCCF-ID. For example, the AMF can choose the BCCF with the lowest load (e.g., the BCCF with the fewest on-chain WTRUs). In another example, the AMF can directly choose the same BCCF that may have previously sent BC-Onboarding-Instructions to WTRUs.

[0362] At 2736, the AMF can forward requests received from 2732 to BCCF 2714. The AMF can also notify BCCF that BCCF may need to contact PCF and / or AUSF 2716 at 2738 and 2742 respectively.

[0363] At 2738, the BCCF can retrieve blockchain on-chain policies for WTRUs from PCF 2718. To do this, the BCCF can first send a request to the PCF indicating the WTRU-ID and displaying the purpose of this blockchain on-chain activity; then, the PCF can find a blockchain on-chain policy suitable for the WTRU-ID; the PCF can then return the found blockchain on-chain policy to the BCCF. The retrieved policy can include a Native-BC-ID suitable for the WTRU; alternatively, the BCCF can first determine the Native-BC-ID and then send both the Native-BC-ID and the WTRU-ID to the PCF to retrieve the relevant blockchain on-chain policy.

[0364] At 2740, BCCF can authorize the request at 2736 based on the blockchain on-chain policy received from 2738.

[0365] At 2742, BCCF can forward blockchain on-chain requests from 2736 to AUSF. If BCCF is unaware of AUSF, it can discover AUSF from NRF or AMF.

[0366] In 2744, AUSF can use something similar to Figure 24 The 2430 method is authorized by WTRU-BC-Addr. Note that AUSF itself can be accessed from K... AUSF (or K) SEAF Export K for WTRU BCGF (or K) BCCF AUSF can generate WTRU-BC-Init-Config for WTRU (equivalent to...). Figure 24 In Dev-BC-Init-Config). AUSF can generate Authorized-WTRU-BC-Addr (equivalent to Dev-BC-Init-Config). Figure 24 The Authorized-WTRU-BC-Addr in the document. AUSF can (re)determine the target native wireless blockchain (Native-BC-ID) for WTRU.

[0367] If request 2732 contains BC-Addr-Scheme="random blockchain address", then once WTRU master authentication is successful, AUSF can simply treat this WTRU-BC-Addr as an authorized address. AUSF can then sign the WTRU-BC-Addr and generate an Authorized-WTRU-BC-Addr. AUSF can store the WTRU-Public-Key received from 2742.

[0368] In 2744, if WTRU-BC-Addr is not authorized, AUSF can generate a new WTRU-BC-Addr and assign it to the WTRU. Then, AUSF can still generate Authorized-WTRU-BC-Addr, but based on the new WTRU-BC-Addr; in other words, the new WTRU-BC-Addr will be included in Authorized-WTRU-BC-Addr.

[0369] The response at 2746 is similar to Figure 24 The response at position 2432. This response may contain Native-BC-ID, WTRU-BC-Init-Config, and Authorized-WTRU-BC-Addr.

[0370] The choice at 2748 is similar to Figure 24 2436.

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

[0372] The update at 2752 is similar to Figure 24 2440.

[0373] The storage at 2754 is similar to Figure 24 2442. Furthermore, BCCF can store blockchain-on-chain records to BCSF / UDR.

[0374] At 2756, BCCF can send a wireless blockchain on-chain response containing Native-BC-ID, WTRU-BC-Init-Config, and Authorized-WTRU-BC-Addr to WTRU via AMF.

[0375] The storage at 2758 is similar to Figure 242446. WTRU can receive a response from step 14. It can locally store Native-BC-ID, WTRU-BC-Init-Config, and Authorized-WTRU-BC-Addr.

[0376] The interaction at 2760 is similar to Figure 24 2448. WTRU can use Authorized-WTRU-BC-Addr, as described in WTRU-BC-Final-Config, to begin interacting with the target native wireless blockchain via BCCF and the selected BCSF. WTRU can also use Para-for-Accessing-3GPP-NF as needed to access specified 3GPP network functions (e.g., discovering other functions from 3GPP NRFs). WTRU can also use BC-NF-ID to access other blockchain functions (e.g., BCRFs).

[0377] This article describes an embodiment of wireless blockchain on-chaining for WTRU assisted by SEAF and AMF.

[0378] 3GPP implementation for wireless blockchain on-chaining for WTRU assisted by AUSF and AMF Figure 28 Chinese illustration: The device can be implemented as part of 3GPP WTRU 2810. BCCF and BCGF will be combined and implemented as a new 3GPP network function called Blockchain Control and Governance Function (BCCGF).

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

[0380] Figure 28 The exemplary process includes the following operations: The generation at 2830 and the request at 2832 are similar. Figure 27 2730 and 2730.

[0381] The choice at 2834 is similar to Figure 27 2834. However, AMF 2812 in this step can choose BCCGF2814. For example, AMF can choose the BCCGF with the lowest load (e.g., BCCGF2814 with the fewest on-chain devices). In another example, AMF can directly choose the same BCCGF as the one that may have previously sent BC-Onboarding-Instructions to the WTRU. The BCCGF's identifier (BCCGF-ID) may have already been included in step 2, which AMF can use directly.

[0382] The request at position 2836 is similar to Figure 27 The request at position 2736. AMF can forward the request from position 2832 to the selected BCCGF.

[0383] The search at 2838 is similar to Figure 27 The search result was found at position 2738.

[0384] The authorization at 2840 is similar to Figure 27 Authorization at address 2740.

[0385] At 2842, BCCGF can send WTRU-ID and Native-BC-ID to SEAF 2816 (or AUSF); SEAF (or AUSF) can derive K for WTRU. BCGF SEAF (or AUSF) can convert K BCGF Send to BCCGF.

[0386] The verification at 2844 is similar to Figure 27 Verification at 2744. BCCGF can use AUSF in Figure 27 Verify WTRU-BC-Addr in the same way as 2844 Validate / Authorize WTRU-BC-Addr.

[0387] In 2844, if WTRU-BC-Addr is not authorized, BCCGF can generate a new WTRU-BC-Addr and assign it to WTRU. Then, BCCGF can still generate Authorized-WTRU-BC-Addr, but based on the new WTRU-BC-Addr; in other words, the new WTRU-BC-Addr will be included in Authorized-WTRU-BC-Addr.

[0388] The processes in 2846, 2848, 2850, 2852, 2854, 2856, and 2858 are similar to Figure 27 2748, 2750, 2752, 2754, 2756, 2758 and 2760.

[0389] This article describes and Figure 27 The diagram shows the wireless blockchain on-chaining of a WTRU blockchain address generated by AUSF.

[0390] The device can be implemented as part of 3GPP WTRU 2910. BCCF 2914 can be implemented as a new 3GPP network function. Alternatively, BCCF can be implemented as part of AMF 2912. BCGF can be implemented as part of AUSF 2916, SEAF, or a new 3GPP NF. BCSF can be implemented as a new 3GPP network function. Alternatively, BCSF 2920 can be implemented as part of UDR or UDSR. BCSF can also be part of Edge Application Server (EAS) or AF.

[0391] Figure 29 The process can be summarized as follows: The WTRU prepares a first request to request blockchain onboarding; the first request may include a WTRU identifier, a blockchain flag, and the blockchain node type the WTRU requests to become (WTRU-BC-Type, e.g., BCN or BSN); the first request is sent 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) based on the blockchain flag; a first response is received 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) generated and authorized by the second or third network function (e.g., AUSF); the first response may indicate whether the blockchain node type requested by the WTRU has been authorized; the first response may contain a first information element (WTRU-BC-Final-Config) regarding the WTRU's blockchain configuration information, which is determined by the second or third network function. The first information element may contain an identifier of the second network function. The first information element may contain monitoring instructions that the WTRU needs to follow to report its blockchain statistics to the second network function. Storing the first information element; and using the first blockchain address to interact with the native wireless blockchain based on the first information element.

[0392] Figure 29 The illustrated embodiment may include the following steps: The request at 2930 is similar to Figure 27 The request is at position 2732, but the request may not contain WTRU-BC-Addr.

[0393] This request at 2930 can be included as part of a 3GPP NAS message (e.g., a registration request, registration update). This request at 2930 can also include Native-BC-ID and WTRU-BC-Type.

[0394] This request at 2930 may contain a “BC-Addr-Indicator”, which instructs the network that WTRU requests a blockchain address from the network.

[0395] If 2930 is a registration request (or registration update), the AMF can perform a regular master authentication. If the master authentication is successful and the registration will be accepted, the AMF can continue with the following steps; otherwise, the following steps can be skipped, and the AMF can simply indicate "blockchain on-chain rejection" in the registration acceptance to be sent to the WTRU.

[0396] The choice at 2932 is similar to Figure 27 The choice at position 2734. When the AMF sees “BC-Addr-Indicator”, it can use an existing BCCF (as indicated in step 1 or locally maintained) or select a new BCCF.

[0397] The request at position 2934 is similar to Figure 27 The request is at position 2736. This request may contain the BC-Addr-Indicator.

[0398] The search at 2936 is similar to Figure 27 The search result was found at position 2738.

[0399] The authorization at 2938 is similar to Figure 27 Authorization at address 2740.

[0400] At 2940, the BCCF can send a wireless blockchain address request to the AUSF. This request can include the BC-Addr-Indicator, WTRU-ID, and Native-BC-ID. Alternatively, the BCCF can send this request to the SEAF.

[0401] 2942, AUSF can receive a request from 2940. In an embodiment, AUSF can generate a blockchain address for the WTRU using the following exemplary steps: AUSF can determine the target native wireless blockchain (Native-BC-ID) for the WTRU. AUSF can obtain the Native-BC-ID from the core network (e.g., UDM, PCF). AUSF can use the WTRU-ID and / or Native-BC-ID to find / derive the WTRU's root key and from K AUSF or K SEAF Export K for WTRU BCGF (or K=). AUSF can use the blockchain address generation function F suitable for WTRU. addr To generate a WTRU blockchain address (WTRU-BC-Addr): WTRU-BC-Addr = F addr(K=) (or WTRU-BC-Addr = F) addr (K BCCF AUSF can use its private key (e.g., PriK=) to generate a blockchain address signature (BC-Addr-Sign) based on the address signature function FSIGN: BC-Addr-Sign = F=(PriK=FSIGN ... AUSF WTRU-BC-Addr. Any other party that knows WTRU-BC-Addr and PubK= can verify BC-Addr-Sign. PubK= is the AUSF public key corresponding to PubK=. AUSF can append BC-Addr-Sign to WTRU-BC-Addr to generate an authorized WTRU blockchain address for WTRU, where Authorized-WTRU-BC-Addr = WTRU-BC-Addr + BC-Addr-Sign or Authorized-WTRU-BC-Addr = WTRU-BC-Addr || BC-Addr-Sign.

[0402] Alternatively, the process at 2942 can be performed by the SEAF, which can: the SEAF can determine the target native wireless blockchain (Native-BC-ID) for the WTRU. The SEAF can obtain the Native-BC-ID from the core network (e.g., UDM, PCF). The SEAF can obtain it from K... SEAF Export K for WTRU BCGF (or K) BCCF ); 2) SEAF uses the blockchain address generation function F suitable for WTRU. addr Generate a WTRU blockchain address (WTRU-BC-Addr): WTRU-BC-Addr = F addr (K BCGF (or WTRU-BC-Addr = F) addr (K BCCF )).

[0403] SEAF can use its private key (e.g., PriK) SEAF According to the address signature function F SIGN Generate blockchain address signature (BC-Addr-Sign): BC-Addr-Sign = F SIGN (PriK=, WTRU-BC-Addr). Know WTRU-BC-Addr and PubK. SEAF BC-Addr-Sign can be verified by any other party. PubK SEAF It is SEAF corresponding to Pri K SEAF The public key.

[0404] SEAF can append BC-Addr-Sign to WTRU-BC-Addr to generate an authorized WTRU blockchain address for WTRU, where Authorized-WTRU-BC-Addr = WTRU-BC-Addr + BC-Addr-Sign or Authorized-WTRU-BC-Addr = WTRU-BC-Addr || BC-Addr-Sign.

[0405] At 2944, AUSF can send a wireless blockchain address response to BCCF. This response may include Authorized-WTRU-BC-Addr, BC-Addr-Scheme, Native-BC-ID, and PubK, as generated / determined at 2942. AUSF Alternatively, SEAF can send a response containing these parameters to BCCF.

[0406] The processes in 2946, 2948, 2950, ​​and 2952 are similar to Figure 27 2748, 2750, 2752 and 2754.

[0407] The storage at 2752 is similar to Figure 27 The response at positions 2754 and 2954 can also contain parameters like those at position 2944. This response can also contain the BCCF-ID.

[0408] In 2956, WTRU can verify the received Authorized-WTRU-BC-Addr to confirm whether the BC-Addr-Sign contained in the Authorized-WTRU-BC-Addr was obtained by AUSF (or SEAF) through the BC-Addr-Scheme (or F... addr ) and PubK AUSF To generate it. If Authorized-Dev-BC-Addr is valid (e.g., generated by AUSF), WTRU can proceed with steps 2758 and 2760; otherwise, steps 2758 and 2760 can be skipped. WTRU may have already pre-configured BC-Addr-Scheme (or F... addr ) and PubK AUSF These two parameters have been retrieved / received from the core network (e.g., UDM, PCF) or have been received from 2754.

[0409] The storage at 2958 is similar to Figure 27 Storage at location 2758.

[0410] The interaction at 2960 is similar to Figure 27 2760.

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

[0412] Alternatively, BCCF can be implemented as a distributed LAF. BCGF can be implemented as a centralized LAF. Alternatively, BCGF can be defined as a new network function. The device can be implemented as a BCEF within a WTRU. BCSF 1 can be implemented as a BCEF with full blockchain nodes.

[0413] This article discusses the process for configuring blockchain access information to BCEF.

[0414] Figure 30 An example is shown of configuring the necessary information to BCEF to enable it to access specified native wireless blockchain and 3GPP core network functions.

[0415] In an embodiment, Figure 30 The process may include the following steps. Through this process, the LAF 3010 can send some blockchain configuration information to the BCEF 3040, enabling the BCEF to: 1) access a designated native wireless blockchain system (Native-BC-ID); 2) interact with other blockchain-related functions using designated methods; and 3) interact with 3GPP NFs (e.g., discover other NFs from assigned NRFs). The LAF and / or BCGF can determine the blockchain configuration information for the BCEF.

[0416] In this diagram, the LAF can have all the functions of the BCCF as proposed in this disclosure, and the BCEF can have all the functions of the BCSF and / or BCCCF as proposed in this disclosure. BCGF 3012 can be BCRF. The BCGF can also be implemented as part of the LAF (i.e., the functions of the BCGF in this diagram are incorporated into the LAF).

[0417] In 3020, the LAF can select one or more BCEFs to send blockchain configuration information to. The LAF can discover these BCEFs from the BCRF, BCGF, and / or other LAFs.

[0418] In step 3022, LAF can send a request to BCGF to request blockchain configuration information for BCEF. This request can include the identifier or address of BCEF (BCEF-ID).

[0419] At 3024, BCGF can receive requests from 3022 and can determine some initial blockchain confirmation information (BC-Init-Config) for BCEF. BC-Init-Config is equivalent to Dev-BC-Init-Config or WTRU-BC-Init-Config as defined in this disclosure. BC-Init-Config may contain the following information: Native-BC-ID: Figure 30 The BCEF in the blockchain is designated as an identifier of the native wireless blockchain that is part of it. LAF-ID: Identifier of the LAF and / or other LAFs that the BCEF may need to contact. BCEF-ID: Identifier of other BCEFs (e.g., the BCEF on WTRU can contact...). Figure 30 This BCEF sending transaction will become Figure 30 (BCEF on the full blockchain nodes of the neighboring nodes of this BCEF). BCRF-ID: Identifier or address of the BCRF that the BCEF may contact in the future. BCGF-ID: Identifier or address of the 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 to / retrieve context information about WTRU). These parameters can be: NF-ID: Identifier of an NF in the 3GPP network (e.g., UDM, NRF, NEF, NWDAF, LMF, AMF). This parameter NF-ID can contain multiple identifiers—each corresponding to a 3GPP NF. NF-Protocol: Protocol (e.g., TLS, NAS) used to interact with the NF indicated by NF-ID. Authorized-BC-Addr: Authorized blockchain address assigned to the BCEF. The BCGF can send a response to the LAF, which contains the BC-Init-Config determined for each BCEF as indicated in step 2.

[0420] The following 3026 and 3028 (i.e., case B) can be alternatives to 3020, 3022 and 3024 (i.e. case A).

[0421] In 3026, BCGF can select one or more BCEFs. BCGF can determine BC-Init-Config for each selected BCEF.

[0422] At 3028, the BCGF can send a response to the LAF. This response can contain the BC-Init-Config determined for each BCEF selected as shown at 3026.

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

[0424] In 3030, LAF can determine the final blockchain configuration information (BC-Final-Config) for each selected BCEF. BC-Final-Config is equivalent to Dev-BC-Final-Config or WTRU-BC-Final-Config as defined in this disclosure. BC-Final-Config can be the same as BC-Init-Config. LAF can change the values ​​of some parameters contained in BC-Init-Config and generate BC-Final-Config.

[0425] In 3032, LAF can send a notification to BCEF. This notification can contain BC-Final-Config as defined in 3030.

[0426] At 3034, BCEF can receive notifications from 3032. BCEF can store BC-Final-Config, such as that received from the notifications.

[0427] At 3036, BCEF can send an acknowledgment to LAF, indicating that BC-Final-Config has been received.

[0428] In 3038, BCEF can use the information contained in BC-Final-Config to access the specified native wireless blockchain and 3GPP NF.

[0429] In 3040, LAF can send a notification (for case A) or an acknowledgment (for case B) to BCGF, indicating that BCEF has BC-Final-Config configured.

[0430] Although the features and elements of the invention are described in a particular combination in the preferred embodiment, each feature or element may be used alone without the other features and elements of the preferred embodiment, or in a variety of combinations with or without the other features and elements of the invention.

Claims

1. A method implemented in a WTRU, comprising: Receive blockchain on-chain information from the first network function; The first blockchain address of the WTRU is generated based on the on-chain information. Preparing the first request for wireless blockchain on-chain; Send the first request to the first network function; Receive a first response including a first information element from the first network function; Store the first information element; as well as Interact with the native wireless blockchain based on the first information element.

2. The method of claim 1, wherein the blockchain on-chain 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 one of claims 1-3, wherein the WTRU determines to record data to the native wireless blockchain.

5. The method of any one of claims 1-4, wherein the WTRU receives an instruction to record data to the native wireless blockchain.

6. The method of any one of claims 1-5, wherein the first request for wireless blockchain on-chain is sent via the control plane.

7. The method of any one of claims 1-5, wherein the first request for wireless blockchain on-chain is sent via the user plane.

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

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

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

11. A WTRU, comprising: processor; and Transceiver, wherein the processor is configured to: This enables the transceiver to receive blockchain on-chain information from the first network function; The first blockchain address of the WTRU is generated based on the on-chain information. Preparing the first request for wireless blockchain on-chain; This causes the transceiver to send the first request to the first network function; This enables the transceiver to receive a first response, including a first information element, from the first network function; Store the first information element; as well as Interact with the native wireless blockchain based on the first information element.

12. The WTRU of claim 11, wherein the blockchain on-chain 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 from the WTRU.

14. The WTRU of any one of claims 11-13, wherein the processor determines to record data to the native wireless blockchain.

15. The WTRU of any one of claims 11-14, wherein the processor is further configured to cause the transceiver to receive an instruction to record data to the native wireless blockchain.

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

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

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

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

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

Images