Publishing device public information in a wireless blockchain system

Abstract

Systems, methods, and instrumentalities for publishing in a wireless blockchain system. An example network function (NF) may receive, from a device, a decentralized identifier document (DID) document publishing request that indicates a DID associated with the device. The NF may verify that the device is authorized to publish the DID document. The NF may generate an initial DID document, associated with the DID, that comprises a first signature associated with the network function. The NF may send, to the device, a first response that includes the initial DID document. The NF may receive, from the device, a second response that indicates a second signature associated with the device. The NF may verify the second signature based on a public key associated with the device. The NF may generate a final DID document based on the initial DID document and the second signature. The NF may publish the final DID document.

Description

PUBLISHING DEVICE PUBLIC INFORMATION IN A WIRELESS BLOCKCHAIN SYSTEMCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 540,172, filed September 25, 2023, and U.S. Provisional Application No. 63 / 543,967, filed October 13, 2023, the contents of which are incorporated by reference herein.BACKGROUND

[0002] Mobile communications using wireless communications continue to evolve. A fifth generation of mobile communication radio access technology (RAT) may be referred to as 5G new radio (NR). A previous (legacy) generation of mobile communication RAT may be, for example, fourth generation (4G) long term evolution (LTE).SUMMARY

[0003] Systems, methods, and instrumentalities are disclosed herein for publishing device public information in a wireless blockchain system. An example device may include a processor configured to perform one or more actions.

[0004] In an example, a device may comprise and / or provide a network function. The network function may receive a decentralized identifier document (DID) document publishing request from a device. The DID document publishing request may indicate a DID associated with the device. The network function may verify that the device is authorized to publish the DID document. The network function may generate an initial DID document associated with the DID. The initial DID document may include a first signature associated with the network function. The network function may send a first response to the device. The first response may include the initial DID document. The network function may receive a second response from the device. The second response may indicate a second signature associated with the device. The network function may verify the second signature based on a public key associated with the device. The network function may generate a final DID document based on the initial DID document and the second signature. The network function may publish the final DID document.

[0005] The network function may send a third response to the device. The third response may indicate an address associated with the published final DID document.

[0006] The network function may be a first network function. The network function may verify that the device is authorized to publish the DID document by sending the DID document publishing request to a second network function and receiving, from the second network function, an indication that the DID document publishing request is approved and an indication of the public key associated with the device.

[0007] The initial DID document may include a value of a parameter. The second response may include an updated initial DID document that indicates an updated value of the parameter. The network function may generate the first signature based on a private key associated with the network function and a signature authentication scheme.

[0008] The network function may receive a second DID document publishing request from the device. The network function may determine that the device is not authorized to publish the second DID document. The network function may send a third response to the device. The third response may include an indication of a failure cause.

[0009] The DID document publication request may indicate a permissioned distributed ledgers (PDL) network. The final DID document may be published to the PDL network. The network function may include a ledger registration management service (L-RMS) and a DID document registration service. The device may be a wireless transmit / receive unit (WTRU).

[0010] In an example, a wireless transmit / receive unit (WTRU) or a method performed by the WTRU may be provided. A public document publishing request may be sent to a first network function (NF). The public document publishing request may indicate a first blockchain flag, a first blockchain address of the WTRU, and a first information element. The first information element may indicate a public document publishing requirement. A first response may be received from the first NF. The first response may be generated by a second NF and may indicate a first WTRU public document. The first WTRU public document may indicate a signature associated with the second NF. The signature associated with the second NF may be verified. A signature associated with the first WTRU public document may be generated based on a private key of the WTRU. A second response may be sent (e.g., from the WTRU to the first NF) that indicates a second blockchain flag and the signature associated with the first WTRU public document. A third response may be received from the first NF. The third response may be generated by the second NF and may indicate an address of a second WTRU public document to be published to a blockchain by the second NF. The address of the second WTRU public document may be stored.

[0011] In an example, a wireless transmit / receive unit (WTRU) or a method performed by the WTRU may be provided. An information element may be determined that indicates public document publishing requirements and a request for a public document template. A first request may be sent to a network function (NF). The first request may indicate the information element. A first response may be received from the NF. The first response may comprise a WTRU public document template and a first networkaddress. A WTRU public document may be generated based on the WTRU public document template. A second request may be sent to the first network address. The second request may comprise the WTRU public document. A second response may be received from the NF. The second response may indicate a second network address where the WTRU public document is published.

[0012] In an example, a wireless transmit / receive unit (WTRU) or a method performed by the WTRU may be provided. A public document notification may be received from a first network function (NF). The public document notification may comprise a WTRU public document, an identifier of the WTRU, and an identifier of the NF. A signature may be generated using a blockchain private key of the WTRU. The WTRU public document may be signed with the signature. A confirmation message may be generated that comprises the signature and the identifier of WTRU. The confirmation message may be sent to the NF.BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

[0017] FIG. 2 illustrates example wireless blockchain system functions.

[0018] FIG. 3 is a call flow diagram illustrating signaling for publishing a device public document via network functions.

[0019] FIG. 4 is a call flow diagram illustrating signaling for publishing a WTRU public document via a blockchain control function (BCCF).

[0020] FIG. 5 is a call flow diagram illustrating signaling for publishing a device public document using a template.

[0021] FIG. 6 is a call flow diagram illustrating signaling for publishing a WTRU public document using a template.

[0022] FIG. 7 is a call flow diagram illustrating signaling for publishing a device group public document.

[0023] FIG. 8 is a call flow diagram illustrating signaling for publishing a WTRU group public document.

[0024] FIG. 9 is a call flow diagram illustrating the creation and publication of a decentralized identifier document.DETAILED DESCRIPTION

[0025] FIG. 1 A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

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

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

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

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

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

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

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

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

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

[0035] The base station 114b in FIG. 1 A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106 / 115.

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

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

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

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

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

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

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

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

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

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

[0046] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable locationdetermination method while remaining consistent with an embodiment.

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

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

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

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

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

[0052] The CN 106 shown in FIG. 1 C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

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

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

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

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

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

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

[0060] When using the 802.11 ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example in 802.11 systems. For CSMA / CA, the STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0079] Reference to a timer herein may refer to a time, a time period, a tracking of time, a tracking of a period of time, a combination thereof, and / or the like. Reference to a timer expiration herein may refer to determining that the time has occurred or that the period of time has expired.

[0080] The following acronyms are used herein:

[0081] Example 5G system architectures are provided herein. 5G system architecture may include a wireless transmit / receive unit (WTRU) (e.g., a user equipment (UE)), a Radio Access Network (RAN), and a Core Network. The 5G System (5GS) may be service-centric or service-based. The 5G Core Network (5GC) may include one or more network functions. The network functions may work together to fulfill / provide services to the RAN, WTRUs, and / or application servers (ASs)Zservice providers. A network function may access other network functions in request / response mode or subscription / notification mode. Network functions may (e.g., before they interact with each other) register with a Network Repository Function (NRF) so that the network functions can discover each other via the NRF. Example network functions include: Access and Mobility Management Function (AMF) (e.g., which is dedicated to managing WTRU’s access to 5GS and its mobility), Session Management Function (SMF) (e.g., which is responsible for establishing sessions between a WTRU and 5GC), and Authentication Server Function (AUSF) (e.g., which takes charge of WTRU authentication), Policy Control Function (PCF) (e.g., which provides policy rules for other control plane network functions and WTRUs and / or assigns an identifier for each created policy rule, which other control plane network functions and WTRUs use to refer to the corresponding policy rule), User Plane Function (UPF) (e.g., which is a network function in the data plane that facilitates monitoring, managing, controlling, and redirecting user plane traffic flows such as between a WTRU and an Application Function (AF)), Network Exposure Function (NEF) (e.g., which enables access to 5G controlplane functions to entities such as network applications and AFs which are outside of 5GS and not in the same trusted domain), and / or the like.

[0082] A core network, such as 5GC, may provide data storage and analytics services through functions like Unified Data Management (UDM), Unified Data Repository (UDR), Unstructured Data Storage Function (UDSF), and / or Network Data Analytics Function (NWDAF). Network slicing may be facilitated by a Network Slice Selection Function (NSSF). Although these network functions are defined as separate logical entities, a particular service scenario may use (e.g., require) multiple network functions. For example, WTRU mobility may involve the AMF, AUSF, and SMF.

[0083] For a type of network function, multiple instances may be instantiated. The NRF may maintain the information of each instantiated network function instance. With the emergence of edge computing, some network functions in 5GC (e.g., UPF and / or NEF) may be deployed in (e.g., and reside in) an edge network (e.g., that is nearer to, and potentially co-located with the RAN). One or more network functions (e.g., a Location Management Function (LMF)) may be used to support location services. The LMF may be responsible for calculating, determining, or verifying a final location and / or a velocity estimation. The LMF may estimate the achieved accuracy (e.g., based on location information from the target WTRU and / or a RAN node). Another entity may access or query its location from the LMF (e.g., after the LMF calculates the location of a target WTRU). The other entity may go through (e.g., need to go through) a serving AMF.

[0084] An example blockchain system is provided herein. A blockchain system may include one or more (e.g., two) types of blockchain nodes. For example, a blockchain node may be a full blockchain node. A full blockchain node may have one or more blockchain functions (e.g., host and maintain ledgers, participate in consensus protocols to generate new blocks, and validate received blocks). A light blockchain node may act as a blockchain client node (e.g., such as a digital wallet that sends transactions to the blockchain system via one or multiple full blockchain nodes).

[0085] Full blockchain nodes may connect to each other via a peer-to-peer network. A (e.g., new) transaction or block may be propagated within the peer-to-peer network (e.g., according to certain routing protocols for example, gossip-based routing). The transaction or block may be propagated within the network so that a full blockchain node (e.g., each full blockchain node) may have the same copy of unprocessed or uncommitted transactions (e.g., unspent transactions) and blocks that include committed transactions (e.g., spent transactions).

[0086] A blockchain client node may have a unique blockchain address as its identifier. The blockchain address may be generated by the blockchain client node itself (e.g., based on cryptography and / or hashing techniques). For example, a blockchain client node may have a pair of a private key and a public key. The public key may be used to generate the blockchain address. The private key may be used to sign transaction(s) that the blockchain client node will send to the blockchain system.

[0087] A blockchain ledger may be append-only and immutable (e.g., due to the use of a hash-based chain structure to link blocks together). Some techniques may enable mutable or redactable blockchains (e.g., where a committed block could be modified or even removed without breaking the hash-based chain structure). These techniques may rely on one or more security keys (e.g., sometimes referred to as blockchain redaction keys). The security keys may enable hash collisions so that a party with access to the blockchain redaction keys can redact or modify existing blocks (e.g., while maintaining the hash-based ledger structure due to the leveraging of hash collisions). Blockchain redaction keys may be generated or provisioned (e.g., when the blockchain system is initiated).

[0088] As used herein, a full blockchain node may be referred to as a Blockchain Service Node (BSN), and a light blockchain node may be referred to as a Blockchain Client Node (BCN). A device or a WTRU may be a BCN (e.g., if it only uses blockchain ledgers as a client) or a BSN (e.g., if it maintains blockchain ledgers and supports full blockchain functions). A physical device or WTRU may host one or multiple instances of BCN and / or BSN (e.g., because the BCN and BSN are logical entities). For example, the physical device or WTRU may host one or multiple instances of BCN and / or BSN if the physical device or WTRU has sufficient resources to support the BCN and / or BSN.

[0089] A blockchain system may be a permissionless blockchain system (e.g., Bitcoin, Ethereum). In a permissionless blockchain system, a party or user may use and participate in the blockchain system without pre-granted permissions. A blockchain system may be a permissioned blockchain system (e.g., where access to the blockchain system needs to be permissioned, controlled and / or governed). Permissioned Distributed Ledgers (PDL) are an example of permissioned blockchain systems.

[0090] Standards may publish Group Reports (GR) and / or Group Specifications (GS) on various topics (e.g., PDL reference architecture, use cases, specific PDL functionalities, and / or vertical domains). For example, standards may describe use cases and / or techniques to enable redactable distributed ledgers. Standards may describe use cases where PDL may be leveraged and integrated with a 3GPP system, such as 5GS.

[0091] Standards may provision PDL services within a system, such as a 3GPP system. For example, the PDL services may include a Ledger Anchor Function (LAF), Blockchain Repository Function (BCRF), and / or Blockchain Enabler Function (BCEF). LAF and BCRF may be control plane functions (e.g., for the 3GPP system). BCEF may be a data plane function.

[0092] Cellular wireless systems (e.g., 5GS) may provide various security functions (e.g., primary authentication during registration, secondary authentication during Protocol Data Unit (PDU) session establishment, network slicing-specific authentication and authorization, network slicing admission control, data plane encryption, and integrity protection, etc.).

[0093] Some (e.g., future) cellular wireless systems (e.g., 6G Systems (6GS)) may feature a broad range of heterogeneous devices and / or networks with an expected expansion of supported verticals (e.g., mission critical). These cellular wireless systems may be (e.g., may need to be) more trustworthy than other systems, such as 5G Systems. For example, devices and their interactions with wireless systems may be trustable by core network functions, application functions (e.g., in the cloud or at the edge), and other devices (e.g., sometimes referred to as trusted devices or trusted WTRUs). A trusted device may not be supported in a system, such as 5G. Some (e.g., existing) security functions (e.g., in 5G) may lack the support for assessing or enforcing the trustworthiness of a given WTRU. For example, whether a device may be trustable may be dynamic (e.g., time-changing). In an example, primary authentication and / or secondary authentication (e.g., 5G primary authentication and / or secondary authentication) may not consider nor support such dynamic device trust.

[0094] Blockchain and distributed ledger technologies may make cellular systems more trustworthy. For example, a device and / or an authorized party may record the device behaviors and / or data to distributed ledgers. The information in the distributed ledgers may be transparent to (and held accountable by) other devices and network nodes (e.g., network functions, as described herein). This may enable decentralized trust. Devices may be (e.g., may need to be) able to access distributed ledgers via the network (e.g., 6GS) to read data from and / or write data to the distributed ledgers. Data stored in distributed ledgers may be (e.g., may need to be) modified or removed if it turns out to be outdated, misinformation, and / or impacting user privacy (e.g., which is possible using redactable distributed ledgers).

[0095] To use blockchain technologies to enable a trustworthy system, the network (e.g., 6GS) may (e.g., may need to) integrate blockchain capabilities (e.g., as network functions) with the network as integral functions. This integration may be referred to as native wireless blockchain. Native wireless blockchain may be a permissioned blockchain system (e.g., PDL). For a device to efficiently interact with a native wireless blockchain, the device may be (e.g., may need to be) onboarded to the native blockchain and / or be provisioned with configuration information (e.g., necessary configuration information) for interacting with the native blockchain. This onboarding may be referred to as device onboarding to native wireless blockchain or wireless blockchain onboarding.

[0096] One or more technical issues may exist with respect to wireless blockchain onboarding. For example, issue(s) associated with publishing device public information to the native wireless blockchain may arise.

[0097] The blockchain address of a device may be regarded as a decentralized identifier of the device. As such, the device may be the holder of its blockchain address. The device may provide blockchain functions (e.g., as a full blockchain node) associated with this blockchain address. The device may have public information (e.g., public keys, authentication schemes for using public keys to authenticate device’ssignatures, etc.). The public information associated with the device may be referred to as device public information. The public information may be (e.g., may need to be) published to the blockchain system so that other parties (e.g., other devices or network functions) can retrieve the device public information. The other parties / devices may leverage the device public information for one or more purposes. For example, the parties / devices may leverage the device public information to verify a signature generated by the device without contacting the device, to obtain a list of properties associated with the device or services provided by the device in an authorizable way, and / or the like.

[0098] Protected / confidential information about devices and / or network may be encrypted (e.g., first).The protected / confidential information may be written into the native wireless blockchain (e.g., which is only readable or accessible to authorized parties). The capability to publish device public information may be a part of wireless blockchain onboarding. The publishing of device public information may be (e.g., may need to be) appropriately managed (e.g., especially if the devices are part of a permissioned blockchain system).

[0099] Feature(s) associated with securely and efficiently publishing / reading device public information to a native wireless blockchain (e.g., by a device, network, or application function) are provided herein. Feature(s) described herein may alleviate communication overhead associated with publishing device public information and retrieving the published device public information.

[0100] As used herein, the term “device” may refer to a WTRU. Device and WTRU may be used interchangeably herein, unless explicitly stated otherwise.

[0101] As used herein, the term “network function” may refer to a processing function in a network (e.g., 5GC).

[0102] As used herein, the term “trusted device” may refer to a device / WTRU that may be trusted by a cellular wireless system (e.g., 6GS). The terms trusted device and trusted WTRU may be used interchangeably herein, unless explicitly stated otherwise.

[0103] As used herein, the term “blockchain client node” (BCN) may refer to a light blockchain node that interacts (e.g., only interacts) with blockchain service nodes to send or retrieve transactions. An example of a blockchain client node is a digital wallet. A blockchain application function within a network is another example of BCN. Blockchain client node and blockchain client may be used interchangeably herein, unless explicitly stated otherwise. A BCN may have a BCAF, such as a BCCCF.

[0104] As used herein, the term “blockchain service node” (BSN) may refer to a full blockchain node that implements functions (e.g., all functions) of blockchain technology (e.g., maintaining a blockchain ledger, participating in consensus protocols, etc.). A BSN may have a BCSF.

[0105] As used herein, the term “blockchain control function” (BCCF) may refer to a logical entity or a network function that acts as the entry point for devices or applications to interact with the native wireless blockchain for control plane purposes (e.g., managing BCNs and BSNs).

[0106] As used herein, the term “blockchain service function” (BCSF) may refer to a logical entity or a network function that acts as the entry point for devices or applications to interact with the native wireless blockchain for data plane purposes (e.g., creating / sending new transactions, etc.). BCSF may be a part of a BSN.

[0107] As used herein, the term “blockchain governance function” (BCGF) may refer to a logical entity or a network function that coordinates, governs, and manages the native wireless blockchain. BCGF may interact with BCCF, BCSF, and / or other application functions or network functions (e.g., a system management application).

[0108] As used herein, the term “blockchain application function” (BCAF) may refer to a logical entity or an application function that may act as a BCN to interact with BSNs (e.g., BCSFs) to generate and retrieve transactions. A BCAF may interact with (e.g., only interact with) other blockchain functions (BCCF, BCGF and BCSF) to control and manage the native wireless blockchain. The BCAF may not generate a transaction to a blockchain ledger. A BCAF may have a blockchain address.

[0109] As used herein, the term “blockchain client and consumer function” (BCCCF) may refer to a BCAF on a BCN node. A BCCCF may reside in the network or as part of a BSN. If a BSN has a BCCCF, this BCCCF may be used (e.g., may only be used) by the BSN to perform transactions-based management purposes (e.g., to record the BSN’s behaviors to blockchain ledgers). In this case, the BCCCF on the BSN may generate new transactions. The BCCCF on the BSN may send the transactions to another BSN. A BCCCF may have a blockchain address. The blockchain address may be assigned or authorized by a BCCF / BCGF. The authorized blockchain address may enable the BCCCF to use the services provided by a BSN.

[0110] As used herein, the term “identifier” may refer to the name / identifier / address of an entity (e.g., a device / WTRU, a network function such as 3GPP NFs and BCCCF, BCCF, BCSF, BCGF, etc.). An identifier may be a 3GPP identifier, an IP address, a Uniform Resource Locator (URL), a Fully Qualified Domain Name (FQDN), a blockchain address, etc. The identifier of an entity may give the entity access to, or access details about, the blockchain (e.g., based on which other entities can access and interact with this entity).

[0111] As used herein, the term “blockchain address” may refer to the address or identifier that uniquely identifies a blockchain entity (BCN, BSN, BCAF, BCSF, BCCF, BCCCF, BCGF, or other blockchain functions) within a blockchain system. A blockchain address may be a sender or a recipient of a blockchain transaction. A blockchain service node may have a blockchain address that can be used for sending sometransactions (e.g., transactions for managing the corresponding blockchain system). A blockchain application function may have a blockchain address. If a BCCF (or a BCGF) plans to send a transaction to blockchain ledger (e.g., for a management purpose, to record its behavior data to blockchain ledger, etc.), the BCCF (or the BCGF) may have a blockchain address or have an embedded BCN or BCAF.

[0112] As used herein, the term “blockchain address signature” may refer to information used to authenticate and / or authorize a blockchain address in a permissioned blockchain system. Before a blockchain address is authorized, the blockchain address may include (e.g., only include) a raw blockchain address (e.g., which may be generated based on a public key). After a blockchain address is authorized by an authorizing party (e.g., by a BCGF, a BCCF, and / or an AUSF), the blockchain address may be referred to as an authorized blockchain address. The authorized blockchain address may include one or more (e.g., two) parts. For example, the authorized blockchain address may include the raw blockchain address and a blockchain address signature. The blockchain address signature may be generated by the authorizing party (e.g., using a private key). A party (e.g., devices, BCSFs, BCCF) that knows the corresponding public key (e.g., the public key associated with the private key for generating the blockchain address signature) may validate the blockchain address signature.

[0113] As used herein, the term “device blockchain address” may refer to a blockchain address for a device in a blockchain system.

[0114] As used herein, the term “blockchain ledger” may refer to a ledger that stores transactions, blocks, and related system status information in a hash-connected chained structure. A (e.g., each) full blockchain node may maintain a blockchain ledger. The terms blockchain ledger, distributed ledger, and ledger may be used interchangeably herein, unless explicitly stated otherwise.

[0115] As used herein, the term “blockchain technology” may refer to a set of technologies used in a blockchain system (e.g., consensus protocols, transaction generation and validation, block generation and validation, blockchain ledgers, etc.). The terms blockchain technology and distributed ledger technology may be used interchangeably herein, unless explicitly stated otherwise.

[0116] As used herein, the term “blockchain system” may refer to the system implementing or using blockchain technology. The terms blockchain system and distributed ledger system may be used interchangeably herein, unless explicitly stated otherwise. A blockchain system may include a plurality of light blockchain nodes and a group of full blockchain nodes.

[0117] As used herein, the term “native wireless blockchain” may refer to a blockchain system integrated with and / or implemented as a part (e.g., an integral part) of a cellular wireless system (e.g., 6GS). A native wireless blockchain may have a set of blockchain-related functions (e.g., BCCCF, BCCF, BCGF, BCSF, BCAF, and / or the like). The blockchain-related functions may be deployed in core network, edge networks, and / or co-located with some powerful devices.

[0118] As used herein, the term “transaction” may refer to a message that is sent from a sender (e.g., BCN-A, a BSN) to a recipient (e.g., BCN-B, a BSN). The message may include information (e.g., digital currency, data, tokens, etc.) exchanged from the sender to the recipient.

[0119] As used herein, the term “block” may refer to a data structure that includes a block header and a block body. The block body may include a set of transactions. A block may be generated by a BSN (e.g., as a result of executing a blockchain consensus protocol).

[0120] As used herein, the term “wireless blockchain onboarding” may refer to a process to onboard devices to a native wireless blockchain (e.g., generate blockchain security keys for devices, initiate wireless blockchain onboarding, authenticate device blockchain address, provision devices with blockchain redaction capability, publish device public information to native wireless blockchain, and / or the like).

[0121] As used herein, the term “permissioned blockchain system” may refer to a blockchain system in which the access to blockchain ledger (e.g., write data to blockchain ledger, read data from blockchain ledger, update / remove data in blockchain ledger) is available (e.g., only available) to permissioned or authorized parties (e.g., which may be governed by a BCGF).

[0122] Feature(s) described herein may improve (e.g., guarantee) the security and integrity of device public information. Feature(s) described herein may improve (e.g., minimize the steps involved in) the process of publishing device public information (e.g., from the device side).

[0123] Feature(s) described herein may reduce overhead at the device side. Feature(s) described herein may reduce communication overhead from the device to / from a native wireless blockchain.Feature(s) described herein may reduce overhead for retrieving device public documents if public keys of multiple devices are used (e.g., if needed).

[0124] Example native wireless blockchain system functions are provided herein. FIG. 2 illustrates an example native wireless blockchain system and its functions.

[0125] A WTRU may be a light blockchain node (e.g., WTRU-1) hosting a BCAF / BCCCF or a full blockchain node (e.g., WTRU-2) hosting a BCSF.

[0126] In the blockchain control plane, the blockchain-related functions (e.g., BCCCF, BCCF, BCGF, BCSF, BCAF, etc.) may interact to perform tasks (e.g., related to provisioning and managing the native wireless blockchain system). For example, the BCGF may coordinate blockchain security key derivation. The BCGF may distribute the derived blockchain security keys (e.g., to the BCCF and BCSF). The BCGF may interact with the AUSF (or be implemented as a part of AUSF) to derive the blockchain security key.

[0127] The BCGF and BCCF may determine and / or select WTRUs to be onboarded to the native wireless blockchain system. The BCAF may trigger the BCGF to select WTRUs for wireless blockchain onboarding.

[0128] If a WTRU starts to onboard to the native wireless blockchain system, the WTRU may (e.g., may only) interact with the BCCF (e.g., which is the entry point for the WTRU). The BCCF may be implemented as a part of an AMF or as a standalone NF in the core network. During the wireless onboarding process, the BCCF may check with the BCGF to determine if the WTRU is authorized to be onboarded. For this purpose, the BCGF may interact with other NFs (e.g., the UDM) to retrieve the WTRU’s subscription data.

[0129] An onboarding or an onboarded WTRU may publish its public information (e.g., its public key, service information, verifiable credentials, etc., which may be encrypted) to the native wireless blockchain system. This task may be coordinated and facilitated by the BCCF and BCSF.

[0130] In the blockchain user plane, the BCCCF, BCAF, and / or other NFs may send transactions to blockchain ledgers or retrieve transactions from blockchain ledgers (e.g., via a BCSF). Transactions and / or blocks may be propagated and exchanged among BCSFs. For example, transactions and / or blocks may be propagated and exchanged via an underlying peer-to-peer network (e.g., which connects all BCSFs). A BCSF (e.g., each BCSF) may interface with a blockchain ledger (e.g., directly). Blockchain ledgers may be deployed at a WTRU (e.g., a powerful WTRU), in a data network (DN) at the edge, and / or in a DN in the cloud.

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

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

[0133] Functions in FIG. 2 may map to the functions defined in standards. For example, BCCF may map to a LAF (e.g., BCCF in a core network may map to a centralized LAF and BCCF, and / or a distributed LAF); BCGF may map to a BCRF, or BCGF may be implemented as a new network function; BCCCF maymap to BCEF or a Blockchain Enabler within a WTRU; and / or BCSF may map to BCEF or a Blockchain Enabler with a full blockchain node.

[0134] As another example, BCCF may map to a distributed LAF, BCGF may map to a centralized LAF, or BCGF may be implemented as a network. BCCCF may map to BCEF or a Blockchain Enabler within a WTRU, and / or BCSF may map to BCEF or a Blockchain Enabler with a full blockchain node.

[0135] Example terms related to device public document publishing are provided herein.

[0136] As used herein, the term “device public document” may refer to a file or a description, including a set of public information about a device that may be (or needs to be) published / exposed to a blockchain system. An example device public information is the public key of a device acting as a BCN (or a BSN). Other nodes in the blockchain system may leverage the public information of a device to verify and / or authenticate a signature generated by the device (e.g., based on the published device public document, without contacting the device). A device public document may be leveraged for service provisioning (e.g., to describe services provided by a device via a device public document and publish it to a blockchain ledger). A device public document may publish encrypted or protected verifiable credentials (VC) of a device to a permissioned blockchain system. A device may publish one or multiple device public documents. A device public document may include public information about one or multiple devices.

[0137] As used herein, the term “device group public document” may refer to a special device public document that includes public information for a group of devices.

[0138] As used herein, the term “signature authentication scheme” may refer to an authentication scheme that indicates how a device’s signature may be authenticated (e.g., using the device’s blockchain public key based on certain cryptographic algorithms). The signature authentication scheme may be public information. The signature authentication scheme may be contained in a device’s device public document.

[0139] As used herein, the term “device public document publishing” may refer to a process of publishing device public documents to a blockchain system and / or distributed storage system.

[0140] As used herein, the term “device public document subject” may refer to the devices or entities that have been described by a device public document. The device public document subject may be referred to as the subject of a device public document.

[0141] As used herein, the term “device public document publisher” may refer to the entity that publishes a device public document to a blockchain system. The device public document publisher may be referred to as the publisher of a device public document. A device public document may be published by its subject or other entities (e.g., a BCCF).

[0142] Feature(s) described herein may relate to the following examples.

[0143] In a first example, a device public document for a device may be (e.g., may need to be) controlled and / or managed by a native wireless blockchain. For example, a device public document (e.g., each device public document) may be (e.g., may need to be) signed by a BCCF (e.g., which may be important for the native wireless blockchain as a permissioned blockchain system).

[0144] In a second example, device public documents may be (e.g., may need to be) generated according to templates (e.g., as required by a native wireless blockchain). Generating the device public documents according to templates may help avoid including unnecessary information in a device public document.

[0145] In a third example, a signature may be generated based on one or multiple private keys (e.g., referred to as multi-key signature if multiple keys are used). Multiple public keys of a group of devices (e.g., each from a different device) may be used to verify a multi-key signature. Multiple signatures may be (e.g., may need to be) verified together. In this case, multiple public keys may be used. A common device public document may be generated to contain public information of the devices in the group (e.g., instead of multiple separate device public documents). A ring signature is an example of multi-key signature. For example, a ring signature may be generated by one of a group of devices. It may be almost impossible to determine which device signed the ring signature. To verify a ring signature, public keys of the devices may be used (e.g., may be needed).

[0146] Feature(s) associated with publishing a device public document via a BCCF are provided herein.

[0147] FIG. 3 is a call flow illustrating an example of generating and publishing a device public document for a device to a native wireless blockchain (e.g., Native-BC-ID). As shown in FIG. 3, the device may, at 1, send a request for publishing a device public document to a BCCF. The BCCF may prepare a device public document for the device. The device public document may be signed by the BCCF and the device. The BCCF may generate the final device public document (e.g., including two signatures - one from the device and one from the BCCF). The BCCF may publish and / or store the device public document to blockchain ledger(s) of the native wireless blockchain (e.g., via a BCSF). A BCGF may be used to authorize the public document publishing request from the device.

[0148] The device may have its blockchain address authorized by a native wireless blockchain (e.g., Native-BC-ID). The device may have received an authorized blockchain address from a native wireless blockchain. The device may have received the address or the identifier of the BCCF from network (e.g., BCCF-ID) or may be pre-configured with the identifier of the BCCF.

[0149] The device may know it will sign one or more messages (e.g., verifiable credentials). The device may know one or more other parties may have the device’s public information (e.g., public key to verify the device’s signatures). The device may know it will offer services to one or more other parties. The device may know that public information about those services will be published to the native wireless blockchain.The device may send a device public document publishing request to the BCCF (e.g., at 1 in FIG. 3). The device may send the device public document publishing request after the device has obtained the i dentifier / ad dress of the BCCF.

[0150] Sending the device public document publishing request may involve one or more of the following parameters: the identifier of the device (e.g., Dev-ID); the blockchain address of the device (e.g., Authorized-Dev-BC-Addr); the identifier of the native wireless blockchain where the device public document will be published and / or where the device has been onboarding or onboarded (e.g., Native-BC-ID); the identifier of the BCCF (e.g., BCCF-ID); and / or an indication for the device to publish its public document (e.g., Dev-Public-Doc-I ndicator). This may allow other entities or nodes to leverage the public document to authenticate a signature generated by the device (e.g., without contacting the device), to more easily access services provided by the device. If there are several types of device public documents, the indication may indicate the type of device public document preferred by the device (e.g., Dev-Public-Doc- Type-Preferred). A type (e.g., each type) may correspond to a different device public document template.

[0151] At 2, the BCCF may receive the request from the device. The BCCF may check if the blockchain address of the device (e.g., Authorized-Dev-BC-Addr) is an authorized address (e.g., by searching a local database maintaining all authorized blockchain addresses). The BCCF may (re)determine Native-BC-ID (e.g., even if Native-BC-ID was included in the message at 1). At 3, if the BCCF does not have a local database or cannot find the blockchain address of the device in the local database, the BCCF may send the blockchain address of the device, Native-BC-ID, and / or the device identifier (e.g., Dev-ID) to the BCGF. At 4, the BCGF may check the blockchain address of the device. At 5, the BCGF may send a response to the BCCF indicating if the blockchain address of the device is authorized or rejected.

[0152] If the blockchain address of the device is not an authorized address, the operations at 3-6 and 8- 12 may not be performed. In this case, the BCCF may, at 7, send a rejection (or “Unauthorized Blockchain Address”) to the device.

[0153] If the BCCF is able to authenticate the blockchain address of the device, the BCCF may forward the device public document publishing request to the BCGF at 3.

[0154] The BCGF may receive the request. At 4, the BCGF may check its local policies (or the device’s subscription data and / or policies from the core network, such as a PCF) to determine if the requested device document publishing as indicated by Dev-Public-Doc-I ndicator is allowed. If the request is approved, the BCGF may determine a signature authentication scheme for the device (e.g., Dev-Sign-Auth-Scheme). The signature authentication scheme may be included in the device’s public document. The BCGF may redetermine the native wireless blockchain identifier (e.g., Native-BC-ID).

[0155] At 5, the BCGF may send a response to the BCCF indicating whether the request has been approved or rejected. The response may include a signature authorization scheme and / or nativeblockchain identifier (e.g., Dev-Sign-Auth-Scheme and / or Native-BC-ID) if re-determined at 4. The response may include the device’s blockchain public key (e.g., Dev-BC-Public-Key).

[0156] If the response at 5 indicates a rejection, the operations described at 6 and 8-12 may not be performed. In this case, the BCCF may send a rejection to the device at 7.

[0157] At 6, the BCCF may generate an initial device public document for the device (e.g., Dev-lnit- Public-Doc). The list of parameters included in the initial device public document may be dependent on the device’s preferred public document type (e.g., Dev-Public-Doc-Type-Preferred). The list of parameters may be determined by the BCGF at 4 and / or sent to the BCCF at 5.

[0158] For example, the signature authorization schemes (e.g., Dev-Sign-Auth-Scheme) and the device public key (e.g., Dev-BC-Public-Key) may be included in the initial device public document. If the signature authorization schemes and the device public key are not included in the response (e.g., at 5), the BCCF may determine the signature authorization schemes and the device public key.

[0159] The initial device public document may include the device blockchain address (e.g., Dev-BC- Addr) and / or the identifier or blockchain address of the BCCF (e.g., BCCF-ID).

[0160] The BCCF may sign the initial device public document (e.g., Dev-I nit-Public-Doc) using its private key (e.g., BCCF-Private-Key) according to the BCCF’s signature authentication scheme (e.g., BCCF-Sign- Auth-Scheme). The initial device public document may include the BCCF public key (e.g., BCCF-Public- Key), the identifier of native wireless blockchain that the device has been onboarding or onboarded to (Native-BC-ID), the identifier or the address of the BCCF’s public document being published, the BCCF’s signature authentication scheme (e.g., BCCF-Sign-Auth-Scheme) and / or the BCCF’s signature (e.g., BCCF-Public-Doc-Sign).

[0161] At 7, the BCCF may send a public document publishing response to the device. The response may include the initial device public document (e.g., Dev-lnit-Public-Doc).

[0162] At 8, the device may receive the response. The device may use BCCF’s signature authentication scheme, BCCF’s public key, and BCCF’s signature in the initial device public document to verify the initial device public document (e.g., to verify BCCF-Public-Doc-Sign is a valid signature of the BCCF for Dev-lnit- Public-Doc). The device may verify the initial device public document using an inverse (e.g., opposite) operation than that used to generate the signature (e.g., use BCCF-Public-Key to decrypt BCCF-Public- Doc-Sign and compare the decrypted value with the original value, such as the hash value of Dev-lnit- Public-Doc).

[0163] If the signature verification failed, the operations at 10-12 may be skipped. In this case, the device may send a “BCCF Signature Invalid” indication to the BCCF at 9.

[0164] If the signature verification passed, the device may use its blockchain private key (e.g., Dev-BC- Private-Key) to generate its signature for the initial device public document (e.g., Dev-lnit-Public-Doc-Sign). The Device may update one or more parameters (e.g., introduce new parameters, update the value of existing parameters, etc.) that were in the initial device public document. The device’s signature (e.g., Dev- lnit-Public-Doc-Sign) may be determined (e.g., calculated) based on the new values of the updated parameters.

[0165] At 9, the device may send its signature (e.g., Dev-I nit-Public-Doc-Sign) to the BCCF. If the device updated any parameters at 8, the device may send the new values of the updated parameters to the BCCF at 9.

[0166] At 10, the BCCF may receive the device’s signature (e.g., Dev-lnit-Public-Doc-Sign). If any changed parameters were indicated, the BCCF may regenerate the initial device public document (e.g., Dev-I nti-Public-Doc) to incorporate the changed parameters. The BCCF may verify the changes and regenerate the BCCF’s signature (e.g., BCCF-Public-Doc-Sign). The BCCF may use the changed parameters and regenerated BCCF signature to update the initial device public document. The BCCF may verify the device’s signature using the device’s blockchain public key (e.g., Dev-BC-Public-Key). If the verification of the device’s signature passes, the BCCF may insert the device’s signature in the initial device public document to generate a final device public document (e.g., Dev-Final-Public-Doc).

[0167] The final device public document may be generated using one or more of the following embedded signatures and may include one or more of the following: the initial device public document (e.g., Dev-lnit-Public-Doc), as generated by the BCCF or regenerated at 10; the device’s signature (e.g., Dev-lnit-Public-Doc-Sign), as received at 9 and verified by the BCCF; and the BCCF’s signature (e.g., BCCF-Public-Doc-Sign), recalculated by the BCCF based on the combination of the initial device public document and the device’s signature.

[0168] At 11 , the BCCF may publish the final device public document (e.g., Dev-Final-Public-Doc) to the native wireless blockchain (e.g., denoted by Native-BC-ID via the BCSF). The BCCF may receive (e.g., from the BCSF) an address or URL for accessing the published final device public document (e.g., Dev- Final-Public-Doc-URL).

[0169] At 12, the BCCF may send a response to the device. The response may indicate the address or URL for accessing the published final device public document (e.g., Dev-Final-Public-Doc-URL). The device may store the address or URL for accessing the published final device public document (e.g., locally).

[0170] A WTRU public document may be published using the BCCF, as illustrated in FIG. 3.

[0171] The device may prepare a first information element. The first information element may indicate public document publishing requirements (e.g., WTRU-Public-Doc-lndicator).

[0172] The device may send a first request to a first network function (e.g., AMF). The first request may include a first blockchain flag, a first blockchain address of the device, and / or the first information element. The first request may be forwarded from the first network function to a second network function (e.g., BCCF) according to the blockchain flag.

[0173] The device may receive a first response from the first network function. The first response may be generated by the second network function (e.g., and forwarded to the device by the first network function). The first response may include an initial WTRU public document. The initial WTRU public document may include the first blockchain address, the device’s public key, the identifier of the second network function, the public key of the second network function, and / or the first signature of the second network function.

[0174] The device may verify the first signature of the second network function that was in the initial WTRU public document. The device may generate a second signature for the initial WTRU public document (e.g., using the device’s private key). The device may prepare a second response. The second response may include a second blockchain flag and the second signature. The device may send the second response to the second network function. The second response may be received by the first network function. The second response may be forwarded from the first network function to the second network function.

[0175] The device may receive the third response from the first network function. The third response may have been generated by the second network. The third response may include an address / URL of the final WTRU public document (e.g., that was published by the second network function to blockchain). The device may store the address / URL of the final WTRU public document.

[0176] The device described with respect to FIG. 3 may be implemented as a part of a WTRU (e.g., 3GPP UE).

[0177] The BCCF described with respect to FIG. 3 may be implemented as a network function (e.g., a new 3GPP network function). The BCCF described with respect to FIG. 3 may be implemented as a part of an AMF (e.g., 3GPP AMF).

[0178] The BCGF described with respect to FIG. 3 may be implemented as a part of an AUSF or other network function (e.g., 3GPP AUSF or a new 3GPP network function). One or more BCGF functions described with respect to FIG. 3 may be incorporated into a BCCF.

[0179] The BCSF described with respect to FIG. 3 may be implemented as a network function (e.g., a new 3GPP network function or a 3GPP AF).

[0180] FIG. 4 is a call flow illustrating an example of publishing a WTRU public document via a BCCF.

[0181] The device (e.g., WTRU) may have its blockchain address authorized by a native wireless blockchain (e.g., Native-BC-ID). The device may have received an authorized blockchain address (e.g., from a native wireless blockchain). The device may have received the address or the identifier of the BCCF (e.g., BCCF-ID) from the network. The device may be (pre)configured with the BCCF-ID.

[0182] At 1 in FIG. 4, the WTRU may obtain an authorized blockchain address (e.g., Authorized-WTRU- BC-Addr). The authorized blockchain address may be similar or equivalent to the Authorized-Dev-BC-Addr described with respect to FIG. 3. WTRU-ID may be a SUCI or 5G-GUTI of the WTRU. The WTRU-ID may be similar or equivalent to Dev-ID described with respect to FIG. 3. The request at 1 may include an indication of the WTRU public document (e.g., WTRU-Public-Doc-lndicator). This indication may be similar or equivalent to the Dev-Public-Doc-I ndicator described with respect to FIG. 3. The request may include the identifier of the native wireless blockchain (e.g., Native-BC-ID). The native wireless blockchain may be where the WTRU / device public document will be published and / or where the WTRU / device has been onboarding or onboarded to. The request may include the identifier of the BCCF (e.g., BCCF-ID).

[0183] At 2, the AMF may receive the request. The AMF may select a BCCF (e.g., discover one or multiple BCCFs from an NRF). If the AMF has a BCCF or if the request includes a BCCF-ID, the AMF may not choose a different one. The identifier of the selected BCCF may be used as the BCCF-ID.

[0184] At 3, the AMF may forward the received request to the BCCF. The AMF may inform the BCCF of an AUSF and / or a PCF for the BCCF to contact (e.g., at 5).

[0185] At 4, the BCCF may authorize the WTRU’s blockchain address. The authorized WTRU blockchain address (e.g., Authorized-WTRU-BC-Addr) may be similar or equivalent to Authorized-Dev-BC- Addr described with respect to FIG. 3. The BCCF may (re)determine Native-BC-ID.

[0186] At 5, the BCCF may forward the public document publishing request (and Native-BC-ID if it was (re)determined at 4) to the AUSF. If the native blockchain identifier (e.g., Native-BC-ID) was not included in the request at 1 , the BCCF may determine the native blockchain identifier for the WTRU (e.g., and include it in the public document publishing request at 5).

[0187] At 6, the AUSF may use the WTRU’s subscription data and / or relevant policies to determine if the requested WTRU document publishing (e.g., as indicated by WTRU-Public-Doc-lndicator) is allowed. If the request is approved, the AUSF may determine the WTRU’s signature authentication scheme for the WTRU (WTRU-Sign-Auth-Scheme, which may be similar or equivalent to Dev-Sign-Auth-Scheme described with respect to FIG. 3). The WTRU signature authentication scheme may be included in the WTRU’s public document. The AUSF may re-determine the native blockchain identifier (e.g., Native-BC-ID).

[0188] At 7, the response from the AUSF to the BCCF may include the WTRU’s signature authentication scheme (e.g., WTRU-Sign-Auth-Scheme), the WTRU’s blockchain public key (e.g., WTRU-BC-Public-Key, which may be similar or equivalent to Dev-BC-Public-Key described with respect to FIG. 3), and / or the native wireless blockchain identifier.

[0189] At 5-7, the BCCF may retrieve one or more policies related to WTRU public document publication from a PCF. The BCCF may use the policies to authorize the public document publishing request received from the WTRU. The BCCF may request (e.g., from the PCF) a WTRU public document publishing policy associated with the WTRU and the target native wireless blockchain (e.g., without interacting with BCGF / AUSF). For example, the policy may control the time and / or location when / where the WTRU can make transactions in the target native wireless blockchain. The policy may control the number or the rate of transactions the WTRU can make in the target native wireless blockchain. The BCCF may verify the related device public document publishing policy information (e.g., received from the PCF). The BCCF may grant or deny the WTRU’s request with authorization for publishing its public document into the target native wireless blockchain (e.g., Native-BC-ID) based on the device public document publishing policy information.

[0190] At 8, the BCCF may generate an initial WTRU public document. The initial WTRU public document (e.g., WTRU-lnit-Public-Doc) may be similar or equivalent to Dev-lnit-Public-Doc described with respect to FIG. 3.

[0191] At 9, the BCCF may send a public document publishing response to the WTRU via the AMF. The response may include the native blockchain identifier (e.g., Native-BC-ID), the WTRU identifier (e.g., WTRU-ID), and / or the initial WTRU public document (e.g., WTRU-lnit-Public-Doc).

[0192] At 10, the WTRU may verify the initial WTRU public document (e.g., as described herein with respect to FIG. 3).

[0193] At 11 , the WTRU may send its signature in a message to the BCCF via the AMF. This message may include the BCCF identifier (e.g., BCCF-ID) and / or the WTRU’s signature (e.g., WTRU-I nit-Public-Doc- Sign, which may be similar or equivalent to Dev-lnit-Public-Doc-Sign, as described with respect to FIG. 3).

[0194] At 12, the final WTRU public document (e.g., WTRU-Final-Public-Doc) may be generated. The final WTRU public document may be similar or equivalent to Dev-Fi nal-P ublic-Doc as described with respect to FIG. 3.

[0195] At 13, the BCCF may send the final WTRU public document to the BCSF for publication to the blockchain (e.g., as described herein with respect to FIG. 3).

[0196] At 14, the BCCF may send the final WTRU public document (e.g., WTRU-Final-Public-Doc-URL, which may be similar or equivalent to Dev-Final-Public-Doc-URL as described herein with respect to FIG.3) to the WTRU.

[0197] Logical entities introduced in standards may include LAF, BCRF, and / or BCEF. The logical entities described with respect to FIG. 4 may include a device (e.g., WTRU), BCCF, BCGF, and / or BCSF.

[0198] The device (e.g., WTRU) described with respect to FIG. 4 may be implemented as a BCEF or a Blockchain Enabler (e.g., within a WTRU).

[0199] The BCCF described with respect to FIG. 4 may be implemented as an LAF. The BCCF described with respect to FIG. 4 may be implemented as a distributed LAF (e.g., a distributed LAF).

[0200] The BCGF described with respect to FIG. 4 may be implemented as a BCRF. The BCGF may be implemented as a network function (e.g., as a new network function). BCGF described with respect to FIG.4 may be implemented as a centralized LAF.

[0201] The BCSF described with respect to FIG. 4 may be implemented as a BCEF or a Blockchain Enabler (e.g., a BCEF with a full blockchain node).

[0202] A device public document may be published using a template.

[0203] FIG. 5 is a call flow diagram that illustrates an example technique for generating and publishing a device public document for a device using a template (e.g., a template provided by a native wireless blockchain). The device may request a device public document template from a BCCF. The device may generate its device public document according to the template. The device may send the generated device public document to the BCCF. The BCCF may request that a BCGF verify the device public document. The BCCF and the BCGF may update the device public document. The BCCF may publish the device public document to the native wireless blockchain (e.g., via a BCSF).

[0204] The device may have its blockchain address authorized by a native wireless blockchain (e.g., with the native blockchain identifier Native-BC-ID). The device may have received an authorized blockchain address from a native wireless blockchain. The device may have received the address or the identifier of the BCCF (e.g., BCCF-ID) from the network. The device may have been (pre-)configured with the identifier of the BCCF.

[0205] The device may know it will sign one or more messages (e.g., to verifiable credentials). The device may know one or more other parties may have (e.g., need to have) the device’s public information (e.g., public key) to verify the device’s signatures. The Device may know it will offer services to one or more other parties. Public information about the services may be (e.g., may need to be) published to the native wireless blockchain. The device may not know how to generate its device public document and / or may not have a template. At 1 in FIG. 5, the device may send a public document template request to the BCCF(e.g., if the device has obtained or has been configured with the BCCF identifier). The public document template request may include one or more of the following parameters: the identifier of the device (e.g., Dev-ID); the blockchain address of the device (e.g., Authorized-Dev-BC-Addr); the identifier of the native wireless blockchain where the device public document will be published and / or where the device has been onboarding or onboarded (e.g., Native-BC-ID:); the identifier of the BCCF (e.g., BCCF-ID:); and / or an indication (e.g., Dev-Public-Doc-lndicator) that the device is requesting to (e.g., needs to) publish its public document and a request to get a public document template from the BCCF.

[0206] At 2, the BCCF may receive the public document template request. The BCCF may check if the blockchain address of the device (e.g., Authorized-Dev-BC-Addr) included in the request is an authorized blockchain address. If the blockchain address of the device is not an authorized blockchain address, the operations at 3-5 and 7-14 may be skipped. In this case, at 6, the BCCF may send a “Blockchain Address Unauthorized” message to the device. The BCCF may (re)determine the native blockchain identifier (e.g., Native-BC-ID) for the device.

[0207] At 3, the BCCF may send a request to the BCGF to retrieve one or more parameters (e.g., to include in the device public document template). The request may include the authorized blockchain address of the device (e.g., Authorized-Dev-BC-Addr) and / or the native blockchain identifier (e.g., Native- BC-ID). The request may include a list of the requested parameters. For example, the requested parameters may include the authentication scheme for authenticating a device public document (e.g., Dev- Public-Doc-Auth-Scheme).

[0208] At 4, the BCGF may receive the request from the BCCF. The BCGF may determine the values of the requested parameters for the device. The BCGF may (re)determine the native blockchain identifier (e.g., Native-BC-ID) for the device. The BCGF may send a response to the BCCF. The response may include the determined values of the requested parameters (e.g., Dev-Public-Doc-Auth-Scheme). The response may include the redetermined native blockchain identifier.

[0209] At 5, based on the response from the BCGF and one or more local policies applicable to the device, the BCCF may generate a device public document template (e.g., Dev-Public-Doc-Temp) for the device. The template may include one or more of the following parameters: the unique identifier of this template (e.g., Dev-Public-Doc-Temp-ID); the identifier or the address of the BCCF’s public document being published; the version of the device public document template (Dev-Public-Doc-Temp-Version); the expiration time of the device public document template (e.g., Dev-Public-Doc-Temp-Lifetime); the identifier of the entity that issued the device public document template (Dev-Public-Doc-Temp-lssuer, which may be BCCF-ID); and / or a list of devices that can use this template (e.g., Dev-Public-Doc-Temp-Scope, which may include the device identifier, Dev-ID, and / or the authorized device blockchain address, Authorized- Dev-BC-Addr, received from the device at 1); a list of parameters (e.g., mandatory parameters) that adevice public document to be generated according to this template may include (e.g., Dev-Public-Doc- Mandatory-Parameters, which may include the device public document identifier, Dev-Public-Doc-ID, the authentication scheme for authenticating device public document, Dev-Public-Doc-Auth-Scheme, as determined by the BCGF); a list of optional parameters that a device public document to be generated according to this template may include (e.g., Dev-Public-Doc-Optional-Parameters, which may include the template identifier (e.g., Dev-Public-Doc-Temp-ID); and / or the signature of the template (e.g., Dev-Public- Doc-Temp-Sign).

[0210] The BCCF may have determined the values for one or more of the mandatory parameters and / or optional parameters and included the values in the template. The BCCF may sign the template using its blockchain private key (e.g., BCCF-BC-Private-Key).

[0211] At 6, the BCCF may send a public document template response to the device. The public document template response may include one or more of the following parameters: the device public document template (e.g., Dev-Public-Doc-Temp, as determined at 5); the address or URL to which the device may contact for publishing its public document (e.g., Dev-Public-Doc-Publishing-Addr, which may be BCCF-ID or a BCSF-ID); and / or the identifier of the native wireless blockchain where the device public document will be published (e.g., Native-BC-ID).

[0212] At 7, the device may create its public document (e.g., Dev-Public-Doc) according to the received device public document template.

[0213] At 8, the device may send a request to the publishing address / URL (e.g., Dev-Public-Doc- Publishing-Addr, which may be BCCF-ID) to publish the device public document. The publishing request may include the native blockchain identifier where the device public document will be published and / or where the device has been onboarding or onboarded (e.g., Native-BC-ID), the device identifier (e.g., Dev- ID), the authorized device blockchain address (e.g., Authorized-Dev-BC-Addr), and / or the device public document (e.g., Dev-Public-Doc). This request may include the identifier of the template (e.g., Dev-Public- Doc-Temp-ID) that the device used to generate the device public document (e.g., Dev-Public-Doc). The publishing request may be sent (e.g., directly) to the BCSF (e.g., if the publishing address URL is BCSF- ID).

[0214] At 9, the BCCF may send a request to the BCGF to authenticate the received device public document. The authentication request may include the device public document (e.g., Dev-Public-Doc).

[0215] At 10, the BCGF may verify the device public document (e.g., Dev-Public-Doc). For example, the BCGF may verify the device public document using the scheme (e.g., Dev-Public-Doc-Auth-Scheme) to check if the device’s signature in the device public document is valid. The BCGF may check if the device public document matches the corresponding template (e.g., Dev-Public-Doc-Temp). The operationsdescribed at 10 may be performed by the BCCF. The operations described at 10 may be performed by the BCCF.

[0216] At 11 , the BCGF may update the device public document (e.g., Dev-Public-Doc). For example, the BCGF may remove one or more parameters, add new parameters, change the value of one or more parameters, etc.). The BCGF may use the device’s blockchain private key (e.g., if the BCGF knows or can derive the device’s blockchain private key) to generate a new signature for device public document (e.g., Dev-Public-Doc). If the BCGF does not know the device’s blockchain private key, the BCGF may not generate a new signature for device public document. The operations described at 11 may be performed by the BCCF (e.g., if the BCCF knows or can derive the device’s blockchain private key).

[0217] At 12, the BCGF may send a response to the BCCF. The response may indicate the verification result determined at 10 (e.g., “Valid Device Public Document,” “Invalid Device Public Document,” and / or the like). “Invalid Device Public Document” may mean that mandatory parameters are missing, that the device public document includes unknown parameters, and / or the device public document includes an invalid device signature. If the BCGF updated the device public document (e.g., at 11), the response may include the updated device public document. If the BCCF performed the operations at 10 and 11 , the BCCF may use the operations at 12 to generate a similar response.

[0218] At 13, if the response at 12 includes an updated device public document, or indicates “Valid Device Public Document,” the BCCF may publish the latest (e.g., original or updated) device public document to the native wireless blockchain (e.g., denoted by Native-BC-ID) by sending the device public document to the BCSF. As a result of publishing, the BCCF may receive an address / URL (e.g., Dev-Pu blic- Doc-URL) from the BCSF. The address / URL may be used to retrieve the published device public document.

[0219] At 14, the BCCF may send a response to the device. The response may include the native blockchain identifier where Dev-Public-Doc was published to at 13 (e.g., Native-BC-ID), the BCSF identifier (e.g., BCSF-ID), and / or the published device public document URL (e.g., Dev-Public-Doc-URL). The response may include the updated device public document, if the BCGF updated the device public document at 11.

[0220] Feature(s) associated with publishing a WTRU public document using a template are provided herein.

[0221] An example WTRU may prepare a first information element. The first information element may indicate public document publishing specifications / requirements (e.g., WTRU-Public-Doc-I ndicator), for example, a request for a public document template.

[0222] The WTRU may send a first request to a first network function (e.g., AMF). The first request may include a first blockchain address of the WTRU, the native wireless blockchain identifier, an identifier of a second network function (e.g., BCCF), and / or the first information element. The first request may be forwarded from the first network function (e.g., AMF) to the second network function (e.g., BCCF) according to a blockchain flag.

[0223] The WTRU may receive a first response from the first network function. The first response may have been generated by the second network function. The first response may include a first WTRU public document template and / or a first network address through which WTRU can publish its public document (e.g., WTRU-Public-Doc-Publishing-Addr).

[0224] The WTRU may create a first WTRU public document (e.g., according to the first WTRU public document template). The WTRU may send a second request (e.g., including the first WTRU public document) to the first network address. The WTRU may receive a second response from the first network address. The second response may include the second network address where the first WTRU public document has been published.

[0225] FIG. 6 is a call flow diagram illustrating an example technique for publishing a WTRU public document using a template.

[0226] A device, as described with respect to FIG. 6, may be implemented as a part of a WTRU (e.g., a 3GPP UE).

[0227] A BCCF as described with respect to FIG. 6 may be implemented as a network function (e.g., a new 3GPP network function, such as a BCCF as in FIG. 6). The BCCF as described with respect to FIG. 6 may be implemented as a part of an AMF (e.g., a 3GPP AMF).

[0228] A BCGF, as described with respect to FIG. 6, may be implemented as a part of an AUSF (e.g., a 3GPP AUSF) or a network function (e.g., a new 3GPP network function). One or more BCGF functions, described with respect to FIG. 6, may be incorporated into a BCCF.

[0229] A BCSF, as described with respect to FIG. 6, may be implemented as a network function (e.g., a new 3GPP network function, such as a BCSF as in FIG. 6) or an application function (e.g., a new application function).

[0230] The WTRU may have its blockchain address authorized by a native wireless blockchain (e.g., Native-BC-ID). The WTRU may have received an authorized blockchain address from the native wireless blockchain. The WTRU may have received the address or the identifier of the BCCF (e.g., BCCF-ID) from the network. The WTRU may have been (pre-)configured with the BCCF-ID.

[0231] At 1 in FIG. 6, the WTRU may have obtained an authorized blockchain address (e.g., Authorized- WTRU-BC-Addr, which may be similar or equivalent to Dev-BC-Addr in FIG. 5). The WTRU-ID may be aSUCI or 5G-GUTI of the WTRU (e.g., which may be similar or equivalent to Dev-ID in FIG. 5). The request may include an indication of the WTRU public document (e.g., WTRU-Public-Doc-lndicator, which may be similar or equivalent to Dev-Public-Doc-lndicator in FIG. 5). The request may include the native blockchain identifier (e.g., Native-BC-ID) and / or the identifier of the BCCF (e.g., BCCF-ID), similar to Native-BC-ID and BCCF-ID in FIG. 5.

[0232] At 2, the AMF may receive the request from the WTRU. The AMF may select a BCCF (e.g., discover one or more BCCFs from an NRF). If the AMF has selected a BCCF or the request from the WTRU includes a BCCF-ID, the AMF may not choose a different BCCF. The identifier of the selected BCCF may be BCCF-ID.

[0233] At 3, the AMF may forward the received request from the WTRU to the BCCF. The AMF may inform the BCCF of an AUSF and / or a PCF for BCCF to contact (e.g., at 5 in FIG. 6).

[0234] At 4, the BCCF may authorize the WTRU blockchain address, as described herein. The authorized WTRU blockchain address (e.g., Authorized-WTRU-BC-Addr) may be similar or equivalent to the Authorized-Dev-BC-Addr described with respect to FIG. 5. The BCCF may (re)determine the native blockchain identifier (e.g., Native-BC-ID) where the WTRU public document will be published to and / or where the WTRU has been onboarding or has been onboarded.

[0235] At 5, the BCCF may send a request to the AUSF to retrieve one or more parameters (e.g., to be included in the public document template). The template request may include the native blockchain identifier where WTRU public document will be published to and / or where the WTRU has been onboarding or has been onboarded (e.g., Native-BC-ID) and / or the authorized WTRU blockchain address (e.g., Authorized-WTRU-BC-Addr). The template request may include a list of requested parameters. The parameters may include the authentication scheme for authenticating WTRU public document (e.g., WTRU-Public-Doc-Auth-Scheme, which may be similar or equivalent to Dev-Public-Doc-Auth-Scheme described with respect to FIG. 5).

[0236] At 6, the AUSF may use the WTRU’s subscription data and / or one or more policies to determine the values of the requested parameters (e.g., for the WTRU to include in its public document). The AUSF may (re)determine the native blockchain identifier (e.g., Native-BC-ID). The AUSF may send a response to the BCCF. The response may include the determined values of the requested parameters (e.g., WTRU- Public-Doc-Auth-Scheme) and / or the native blockchain identifier (e.g., Native-BC-ID), similar to what has been described in FIG. 5.

[0237] At 5 and 6, the BCCF may retrieve the requested parameters from a PCF (e.g., if the parameter is stored at a PCF as a part of WTRU public document publishing related policies). The BCCF may request (e.g., from the PCF) a WTRU public document publishing policy associated with the WTRU and / or the target native wireless blockchain (e.g., without interacting with BCGF / AUSF). For example, the policy maycontrol the time and / or location when / where the WTRU can make transactions in the target native wireless blockchain. The policy may control the number or the rate of transactions the WTRU can make in the target native wireless blockchain. The BCCF may verify the related device public document publishing policy information received from the PCF. The BCCF may grant or deny the WTRU’s request with authorization for publishing its public document into the target native wireless blockchain (e.g., Native-BC-ID) based on the policy information.

[0238] At 7, the BCCF may generate a WTRU public document template (e.g., WTRU-Public-Doc-Temp, which may be similar or equivalent to Dev-Public-Doc-Temp described with respect to FIG. 5).

[0239] At 8, the BCCF may send a response to the WTRU (e.g., via the AMF). The response may include the native blockchain identifier where WTRU public document will be published and / or where the WTRU has been onboarding or has been onboarded (e.g., Native-BC-ID), the WTRU identifier (e.g., WTRU-ID), the public document template (e.g., WTRU-Public-Doc-Temp), and / or the public document publishing address / URL (e.g., WTRU-Public-Doc-Publishing-Addr, which may be similar or equivalent to Dev-Public-Doc-Publishing-Addr described with respect to FIG. 5 and may be BCCF-ID in the example in FIG. 6).

[0240] At 9, the WTRU may create its public document (e.g., WTRU-Public-Doc) according to the received template (e.g., WTRU-Public-Doc-Temp).

[0241] At 10, the WTRU may send a request to the BCCF via the AMF to publish its public document to the native wireless blockchain (e.g., Native-BC-ID received at 8). The request may include the native blockchain identifier where WTRU public document will be published to and / or where the WTRU has been onboarding or has been onboarded (e.g., Native-BC-ID), the WTRU identifier (e.g., WTRU-ID), the blockchain flag (e.g., BC-Flag), the authorized WTRU blockchain address / URL (e.g., Authorized-WTRU- BC-Addr), and / or the WTRU public document (e.g., WTRU-Public-Doc).

[0242] At 11 , the BCCF may verify the WTRU public document (e.g., as described herein at 10 in FIG. 5). At 12, the BCCF may update the WTRU public document (e.g., as described herein at 11 in FIG. 5). At 13, the BCCF may send the WTRU public document to a BCSF or BCSF. The BCCF may (e.g., after sending WTRU-Public-Doc to the BCSF) receive the address / URL for the location in which the public document was published (e.g., WTRU-Public-Doc-URL) from the BCSF. The publication address / URL (e.g., WTRU-Public-Doc-URL) may be similar or equivalent to Dev-Public-Doc-URL as described with respect to FIG. 5.

[0243] At 14, the BCCF may send a response to the WTRU (e.g., via the AMF). The response may include the native blockchain identifier (e.g., Native-BC-ID), the BCSF identifier (e.g., BCSF-ID), and / or the publication address / URL (e.g., WTRU-Public-Doc-URL). The response may include the updated public document (e.g., WTRU-Public-Doc) if the BCCF updated the WTRU public document at 12.

[0244] The logical entities described in standards may include LAF, BCRF, and BCEF or Blockchain Enabler. The logical entities described with respect to FIG. 6 may include a device (e.g., WTRU), BCCF, BCGF, and BCSF.

[0245] The device, as described with respect to FIG. 5, may be implemented as a BCEF or a Blockchain Enabler (e.g., within a WTRU).

[0246] The BCCF, as described with respect to FIG. 5, may be implemented as an LAF. The BCCF, as described with respect to FIG. 5, may be implemented as a distributed LAF.

[0247] The BCGF, as described with respect to FIG. 5, may be implemented as a BCRF. The BCGF may be implemented as a network function (e.g., a new network function). The BCGF, as described with respect to FIG. 5, may be implemented as a centralized LAF.

[0248] The BCSF, as described with respect to FIG. 5, may be implemented as a BCEF or a Blockchain Enabler (e.g., a BCEF with a full blockchain node).

[0249] A device public document for multiple devices may be published.

[0250] FIG. 7 is a call flow diagram illustrating example signaling for generating and publishing a device public document for a group of devices (e.g., Device-A and Device-B). A BCAF may send a device public document publishing request for the group of devices to a BCCF. The BCCF may generate a (e.g., separate) device public document for the devices (e.g., a device public document for each device or a (single) common device public document for all devices of the group). The BCCF may send the generated device public document(s) (e.g., separated, or common) to the devices (e.g., each device) to obtain their signature. The BCCF may generate the device group public document. The BCCF may publish the device group public document to a native wireless blockchain (e.g., via a BCSF). The BCCF may use (e.g., may need) a BCGF to authorize the publishing request from the BCAF, or the BCCF may authorize the publishing request.

[0251] The BCAF may have received the address or the identifier of the BCCF (e.g., BCCF-ID) from the network or may have been (pre-)configured with the BCCF-ID.

[0252] In FIG. 7, at 1 , the BCAF may send a public document publishing request to the BCCF (e.g., if the BCAF has obtained or has been configured with the BCCF). The public document publishing request may be used to publish public document(s) for a group of devices. The public document publishing request may include one or more of the following parameters: the identifier of the BCAF (e.g., BCAF-ID), which may be a blockchain address if the BCAF has obtained an authorized blockchain address; the identifier of the native wireless blockchain where the device public document will be published and / or where devices have been onboarding or have been onboarded (e.g., Native-BC-ID); an indication (e.g., Dev-Group) of a list of devices (e.g., Device-A and Device-B), which may indicate a list of device identifiers (e.g., Dev-ID) and / or alist of devices blockchain addresses (e.g., Dev-BC-Addr), or (e.g., if the BCCF has maintained groups of devices) the identifier of the group (e.g., Dev-Group-ID) which the BCCF may use to find corresponding devices (e.g., corresponding Dev-ID and / or Dev-BC-Addr) for its local onboarding repository or from a BCGF; and / or an indication of a request to publish public document(s) for a group of devices (e.g., Dev- Public-Doc-I ndicator), so that other entities or nodes may leverage the published public document to authenticate any signature generated by one of the devices (e.g., without contacting the devices). If there are several types of device public documents, the Dev-Public-Doc-I ndicator parameter may indicate the type of device public document the BCAF prefers (e.g., Dev-Public-Doc-Type-Preferred). For example, Dev-Public-Doc-Type-Preferred may be set to “One Public Document for Multiple Devices.”

[0253] The public document publishing request may be sent from another device (e.g., Device-C) to the BCCF (e.g., instead of from the BCAF). Device-C may be a device indicated in the device group (e.g., Dev- Group). The BCCF may generate a device public document for Device-C (e.g., at 6 in FIG. 7). The operations at 7 and 8 may be repeated for Device-C (e.g., in addition to Device-A and Device-B). The operations at 9 and 10 may involve a Device-C signature (e.g., DevC-Sign).

[0254] At 2, the BCCF may receive the public document publishing request. The BCCF may identify blockchain addresses of the devices in the Dev-Group (e.g., DevA-BC-Addr for Device-A, DevB-BC-Addr for Device-B, etc.). For a blockchain address (e.g., each blockchain address), the BCCF may check if the blockchain address is an authorized address (e.g., by looking in a local database that maintains all authorized blockchain addresses). If the BCCF does not have a local database or cannot find a particular blockchain address from the local database, the BCCF may send the blockchain address and the native blockchain identifier (e.g., Native-BC-ID) to the BCGF (e.g., at 3). The BCGF may check if the blockchain address is authorized. The BCGF may send a response to the BCCF indicating if the blockchain address is authorized or rejected. If Dev-Group may not be a group identifier, the BCCF may create a group (e.g., a new group) including the devices from Dev-Group. The BCCF may maintain the created group (e.g., locally). The BCCF may assign a group identifier (Dev-Group-ID) to the created group. The BCGF may (re)determine the native blockchain identifier Native-BC-ID and send it to the BCGF at 3.

[0255] At 3, the BCCF may send a device public document publishing authorization request to the BCGF. The device public document publishing authorization request may include the device blockchain addresses that were in (or referenced by) Dev-Group and were authorized (e.g., at 2). The Native-BC-ID and Dev-Public-Doc-I ndicator may be included in the device public document publishing authorization request.

[0256] At 4, the BCGF may receive the device public document publishing authorization request. The BCGF may check its local policies (or those devices’ subscription data and / or policies received from the core network) to determine if the requested device document publishing to Native-BC-ID (e.g., as indicatedby Dev-Public-Doc-I ndicator) is allowed. If the device public document publishing authorization request is approved, the BCGF may determine a device public documentation authentication scheme for the devices (e.g., each device). The BCGF may determine the same signature authentication scheme (e.g., Dev- Group-Sign-Auth-Scheme) for a device (e.g., each device) in the group of devices. The BCGF may (re)determine the native blockchain identifier Native-BC-ID and send it to the BCCF at 5.

[0257] At 5, the BCGF may send a response to the BCCF indicating whether the request has been approved or rejected (e.g., at 4). The response may include the native blockchain identifier (e.g., Native- BC-ID), the device group signature authorization scheme (e.g., Dev-Group-Sign-Auth-Scheme), and / or a device’s (e.g., each device’s) blockchain public key (e.g., DevA-BC-Public-Key for Device-A, DevB-BC- Public-Key for Device-B, DevC-BC-Public-Key for Device-C, etc.).

[0258] At 6 (e.g., based on the response from the BCGF and / or one or more local policies), the BCCF may determine the appropriate device public document template for each device. The BCCF may determine the same template for one or more devices (e.g., all devices and / or Dev-Group-Public- Document-Temp). The BCGF may have determined those templates as a part of the operations at 4. The BCGF may have sent the templates to the BCCF at 5. The BCCF may use the determined template(s) to create a device public document for a device (e.g., each device, DevA-Public-Doc for Device-A, DevB- Public-Doc for Device-B, etc.). A device public document (e.g., each device public document) may include the device group identifier (e.g., Dev-Group-ID) and / or the device group signature authorization scheme (e.g., Dev-Group-Sign-Auth-Scheme). The BCCF may generate a common device public document (e.g., Dev-Common-Public-Doc) for the devices. The common device public document may include the device group ID (e.g., Dev-Group-ID) and / or the device group signature authorization scheme (e.g., Dev-Group- Sign-Auth-Scheme). In an example, the DevA-Public-Doc and DevB-Public-Doc may be similar or equivalent to Dev-Common-Public-Doc.

[0259] At 7, the BCCF may send a notification (e.g., including the corresponding device public document and corresponding device identifier) to a device (e.g., the BCCF may send DevA-Public-Doc to Device-A at 7a, send DevB-Public-Doc to Device-B at 7b, etc.). The notifications may include the identifier of the BCAF (e.g., BCAF-ID), the identifier of the device group (and / or the identifier of all devices in the group), and / or the native blockchain identifier (e.g., Native-BC-ID).

[0260] At 8, the devices (e.g., each device) may receive their respective device public document from the BCCF. The devices may sign the document using their respective blockchain private key. The devices (e.g., each device) may send a confirmation (e.g., including the corresponding signature) to the BCCF. For example, Device-A may send its signature (e.g., DevA-Sign) and its identifier (e.g., DevA-ID) or its blockchain address to the BCCF at 8a. Similarly, Device-B may send its signature (e.g., DevB-Sign) and its identifier (e.g., DevB-ID) or its blockchain address to the BCCF at 8b.

[0261] At 9, the BCCF may verify the signature of the devices (e.g., from each device) using a device’s (e.g., each device’s) blockchain public key.

[0262] At 10, the BCCF may generate a device group public document (e.g., Dev-Group-Public-Doc) for the devices in (or referenced by) the device group (e.g., Dev-Group). Using Device-A and Device-B as an example, Dev-Group-Public-Doc may be a combination of DevA-Public-Doc, DevB-Public-Doc, DevA-Sign, and DevB-Sign (e.g., if DevA-Public-Doc and DevB-Public-Doc are different). In another example, Dev- Group-Public-Doc may be a combination of Dev-Common-Public-Doc, DevA-Sign, and DevB-Sign.

[0263] At 11 , the BCCF may publish Dev-Group-Public-Doc to the native wireless blockchain as denoted by Native-BC-ID (e.g., via a BCSF). The BCCF may receive a URL (e.g., Dev-Group-Public-Doc-URL) from the BCSF. The URL may indicate the location to which Dev-Group-Public-Doc was published (e.g., and from where Dev-Group-Public-Doc may be retrieved). The Dev-Group-Public-Doc may be retrieved through a native wireless blockchain (e.g., as denoted by Native-BC-ID).

[0264] At 12, the BCCF may send a response to the BCAF. The response may include the native blockchain identifier (e.g., Native-BC-ID), the BCSF identifier (e.g., BCSF-ID), the device group public document URL (e.g., Dev-Group-Public-Doc-URL), and / or a list of which devices’ blockchain addresses have been or have not been authorized (e.g., at 2). The response at 12 may be sent from the BCCF to all devices in the device group.

[0265] Feature(s) associated with publishing a WTRU group public document are provided herein.

[0266] An example WTRU may receive a first public document notification from the first network function (e.g., AMF). The first public document notification may include a first public document for WTRU, the identifier of WTRU, the identifier of the device group (and / or the identifier of all devices in the group), the identifier of a native wireless blockchain to which WTRU public document will be published, and / or the identifier of the first application function that has initiated to create the first public document.

[0267] The WTRU may generate a first signature (e.g., as part of signing the first public document). The WTRU may sign the first public document using a first blockchain private key of the WTRU.

[0268] The WTRU may prepare a first confirmation message. The first confirmation message may include the first signature and the identifier of WTRU. The WTRU may send the first confirmation message to the first network function. The WTRU may receive a first response message as a response to the first confirmation message. The first response message may include the identifier of the native wireless blockchain to which the WTRU group public document was published and / or the address / URL from which the published WTRU group public document may be retrieved.

[0269] The device described with respect to FIG. 7 may be implemented as a part of a WTRU (e.g., a 3GPP UE).

[0270] The BCCF described with respect to FIG. 7 may be implemented as a network function (e.g., a new 3GPP network function). The BCCF may be implemented as a part of an AMF (e.g., a 3GPP AMF).

[0271] The BCGF described with respect to FIG. 7 may be implemented as a part of an AUSF (e.g., a 3GPP AUSF). The BCGF may be implemented as a network function (e.g., a new 3GPP network function). One or more BCGF functions of the BCGF described with respect to FIG. 7 may be incorporated into a BCCF.

[0272] The BCAF described with respect to FIG. 7 may be implemented as a part of an AF (e.g., a 3GPP AF) or network function (e.g., a new 3GPP network function).

[0273] FIG. 8 is a call flow illustrating example signaling for publishing a WTRU group public document.

[0274] The AF may have received the address or the identifier of the BCCF from the network (e.g., BCCF-ID). The AF may have been (pre-)configured with the BCCF-ID.

[0275] At 1 in FIG. 8, the AF may send a public document publishing request to the BCCF. The public document publishing request may be relayed by an NEF to the BCCF. The public document publishing request may include one or more of the following parameters: an AF-ID (e.g., which may be similar or equivalent to BCAF-ID described with respect to FIG. 7); a Native-BC-ID (e.g., which may be similar to or the same as Native-BC-ID described with respect to FIG. 7); a WTRU group identifier (e.g., WTRU-Group, which may be similar or equivalent to Dev-Group described with respect to FIG. 7); and / or a WTRU public document indication (e.g., WTRU-Public-Doc-I ndicator, which may be similar or equivalent to Dev-Public- Doc-lndicator described with respect to FIG. 7).

[0276] At 2, the BCCF may create a WTRU group (e.g., a new WTRU group). The BCCF may assign a group identifier (e.g., WTRU-Group-ID) for the WTRUs in or referred to by WTRU-Group (e.g., received at 1). The WTRU group identifier (e.g., WTRU-Group-ID) may be similar or equivalent to the device group identifier (e.g., Dev-Group-ID) described with respect to FIG. 7. The BCCF may (re)determine the native blockchain identifier (e.g., to which the WTRU group public document will be published and / or where WTRUs have been onboarding or have been onboarded, for example, Native-BC-ID).

[0277] At 3, the BCCF may send a device public document publishing authorization request to the AUSF. The device public document publishing authorization request may include the Native-BC-ID, the WTRU group identifier, AF-ID, the WTRUs’ blockchain addresses (e.g., WTRU-BC-Addr) for the WTRUs that were in or referred to by WTRU-Group and were authorized at 2. The WTRU-Public-Doc-lndicator received at 1 may be included in the device public document publishing authorization request.

[0278] At 4, the AUSF may receive the device public document publishing authorization request. The AUSF may use WTRUs’ subscription data and / or relevant policies to determine if the requested WTRU document publishing to the Native-BC-ID (e.g., as indicated by WTRU-Public-Doc-lndicator) is allowed. Ifthe device public document publishing authorization request is approved, the AUSF may determine the WTRU authentication scheme (e.g., the same WTRU authentication scheme) for the WTRUs in the group. The WTRU authentication scheme (e.g., WTRU-Group-Sign-Auth-Scheme) may be similar or equivalent to Dev-Group-Sign-Auth-Scheme described with respect to FIG. 7. The AUSF may (re)determine the Native- BC-ID. The AUSF may (re)determine or change the devices in the device group.

[0279] At 5, the AUSF may send a response to the BCCF indicating if the device public document publishing authorization request was approved or rejected. The response may include the Native-BC-ID (e.g., if a new Native-BC-ID was redetermined at 4), WTRU-Group-Sign-Auth-Scheme, and a WTRU’s (e.g., each WTRU’s) blockchain public key (e.g., WTRU-A-BC-Public-Key for WTRU-A, WTRU-B-BC- Public-Key for WTRU-B, etc.).

[0280] At 3-5, the BCCF may retrieve one or more policies related to WTRU public document publication from a PCF. The BCCF may use the policies to authorize public document publishing requests received from the AF (e.g., without contacting the BCGF), for example, similar to the operations at 3-5 in FIG. 7.

[0281] At 6, according to the response received at 5 and the one or more local policies, the BCCF may determine the appropriate public document template for each WTRU. The BCCF may determine the same template(s) (e.g., WTRU-Group-Public-Document-Temp) for the WTRUs (e.g., all WTRUs) in the group. The BCCF may use the determined template(s) to create a WTRU public document for each WTRU (e.g., WTRU-A-Public-Doc for WTRU-A, WTRU-B-Public-Doc for WTRU-B, etc.). A WTRU public document (e.g., each WTRU public document) may include the WTRU-Group-ID and / or WTRU-Group-Sign-Auth-Scheme. The BCCF may generate a common WTRU public document (e.g., WTRU-Common-Public-Doc) for the WTRUs (e.g., all WTRUs) in the group. The common WTRU public document may include the WTRU- Group-ID and / or WTRU-Group-Sign-Auth-Scheme. In this case, WTRU-A-Public-Doc and WTRU-B-Public- Doc may be replaced by (or may be equivalent to) WTRU-Common-Public-Doc.

[0282] At 7, the BCCF may send a notification including the corresponding WTRU public document to the WTRUs in the group (e.g., send WTRU-A-Public-Doc to WTRU-A at 7a, and / or may send WTRU-B- Public-Doc to WTRU-B at 7b, etc.). The notification may be relayed by an AMF (e.g., the AMF serving the WTRUs) to the WTRUs in the group. The notification may include the native blockchain identifier (e.g., Native-BC-ID), the AF identifier (AF-ID), and / or the identifier of the AF (e.g., AF-ID).

[0283] At 8, the WTRUs (e.g., each WTRU) may sign the received public document using its respective blockchain private key. The WTRUs (e.g., each WTRU) may send a confirmation message to the BCCF. The confirmation message may include the respective signature of the WTRUs. For example, WTRU-A may send its signature (e.g., WTRU-A-Sign) to the BCCF at 8a, WTRU-B may send its signature (e.g., WTRU-B-Sign) to the BCCF at 8b, etc. The WTRU signatures (e.g., each WTRU signature) may be relayed (e.g., by WTRU’s serving AMF) to the BCCF.

[0284] At 9, the BCCF may verify the signature from the WTRUs (e.g., from each WTRU) using the WTRUs’ respective blockchain public key.

[0285] At 10, the BCCF may generate a WTRU group public document (e.g., WTRU-Group-Public-Doc) for the WTRUs. The WTRU-Group-Public-Doc may be a combination of WTRU-A-Public-Doc, WTRU-B- Public-Doc, WTRU-A-Sign, and WTRU-B-Sign (e.g., if WTRU-A-Public-Doc and WTRU-B-Public-Doc are different). If a common public document is used, the WTRU-Group-Public-Doc may be a combination of WTRU-Common-Public-Doc, WTRU-A-Sign, and WTRU-B-Sign.

[0286] At 11 , the BCCF may publish the WTRU-Group-Public-Doc to the native wireless blockchain (e.g., denoted by Native-BC-ID) via a BCSF. The BCCF may receive a URL (e.g., WTRU-Group-Public- Doc-URL) from the BCSF, through which the WTRU-Group-Public-Doc can be retrieved from the native wireless blockchain.

[0287] At 12, the BCCF may send a response to the AF. The response may include the native blockchain identifier (e.g., Native-BC-ID), the device group identifier, the BCSF identifier (e.g., BCSF-ID), the WTRU public document URL / address (e.g., WTRU-Group-Public-Doc-URL), and / or a list of WTRUs (e.g., including whether the WTRUs’ respective blockchain addresses have been authorized or not at 2). The response may be relayed by a NEF to the AF. The BCCF may forward the response to each device.

[0288] The logical entities introduced in standards may include LAF, BCRF, and / or BCEF. The logical entities introduced with respect to FIG. 7 include a device, BCCF, BCGF, BCSF, and BCAF.

[0289] The device, described with respect to FIG. 7, may be implemented as a BCEF or a Blockchain Enabler (e.g., within a WTRU).

[0290] The BCCF, described with respect to FIG. 7, may be implemented as an LAF. The BCCF, described with respect to FIG. 7, may be implemented as a distributed LAF.

[0291] The BCGF, described with respect to FIG. 7, may be implemented as a BCRF. The BCGF may be a network function (e.g., a new network function). BCGF, described with respect to FIG. 7, may be implemented as a centralized LAF.

[0292] The BCAF, described with respect to FIG. 7, may be implemented as an entity BCAF (e.g., a new entity BCAF).

[0293] The BCSF, described with respect to FIG. 7 (e.g., at 11), may be implemented as a BCEF or a Blockchain Enabler (e.g., a full blockchain node).

[0294] FIG. 9 illustrates an example of creating a decentralized identifier (DID) document for a device. The DID document (e.g., DID-Doc) may be published to a PDL network. The DID may be a blockchain address. The DID-Doc may be a type of device public document. In FIG. 9, the DID holder may refer to the entity to which the DID belongs. The DID-Doc may describe the DID holder entity. A device may be a DIDholder. For example, the DID may be the device’s blockchain address. The DID document may be the device’s public document. A ledger registration management service (L-RMS) may have functionalities of the BCCF and / or BCGF. As used in FIG. 9, a DID document registration service or governance service may be similar or equal to BCGF and / or may have some functionalities of BCCF. A PDL node may have some functionalities of BCSF.

[0295] In FIG. 9, at 1 , the DID holder (e.g., a device, for example, a WTRU) may send a DID document publishing request to a network function (e.g., the L-RMS). The DID document publishing request may be similar to the public document publishing request discussed herein. The DID document publishing request may be referred to as a DID document storage request. The DID document publishing request may include the DID of the DID holder; the blockchain address of the DID holder (e.g., BC-Addr); the identifier of PDL network to which the DID document will be published (e.g., PDL-NWK-ID, which may be similar to Native- BC-ID); and / or a DID-Doc-indicator. The DID-Doc-indicator may indicate that the DID holder wishes to create and publish its public document to a PDL network via a PDL node.

[0296] The network function may be the L-RMS. At 2, the network function may send the DID document publishing request to a second network function (e.g., the L-RMS may forward the DID document publishing request to the DID document registration service or governance service). The network function may include the L-RMS and DID document registration service (e.g., a DID document registration service or governance service).

[0297] At 3, the DID document registration service or governance service may receive the request from the L-RMS. The DID document registration service or governance service may check its local policies to verify that the device is authorized to publish the DID document (e.g., determine if the requested DID document publishing is allowed). If the request is not approved (e.g., the device is not authorized to be published), the network function may send a response to the device that indicates a failure cause. If the request is approved, the DID document registration service or governance service may determine a signature authentication scheme for the DID holder (e.g., DID-Holder-Sign-Auth-Scheme). The authentication scheme may be included in the DID document. The DID document registration service or governance service may re-determine the identifier of the PDL network (e.g., PDL-NWK-ID).

[0298] At 4, the DID document registration service or governance service may send a response to the L- RMS. The network function (e.g., the L-RMS) may receive the response. The response may indicate if the request has been approved or rejected. The response may include an indication of the public key associated with the device. The response may include an indication of the signature authentication scheme (e.g., DID-Holder-Sign-Auth-Scheme), the PDL network identifier (e.g., PDL-NWK-ID, for example, if it was re-determined by the DID document registration service or governance service), and / or the DID holder’s public key (e.g., DID-Holder-Public-Key, which may be similar to Dev-BC-Public-Key).

[0299] At 5, the L-RMS may generate an initial DID document (e.g., I nit-DI D-Doc) for the DID holder. Init-DID-Doc may be similar to Dev-lnit-Public-Doc, described herein. The list of parameters in Init-DID-Doc may include DID, DID-Holder-Sign-Auth-Scheme, DI D-Holder-Public-Key, the identifier of L-RMS (e.g., L- RMS-ID), etc. The initial DID document may include the signature associated with the network function (e.g., the L-RMS may sign Init-DID-Doc), for example, using its private key (e.g., L-RMS-Private-Key) according to L-RMS’s signature authentication scheme (e.g., L-RMS-Sign-Auth-Scheme). The Init-DID-Doc also may include L-RMS-Public-Key, L-RMS-Sign-Auth-Scheme, and / or the L-RMS’s signature (e.g., L- RMS-DID-Doc-Sign). The actions described at 5 may be performed by the DID document registration service or governance service (e.g., which then will send Init-DID-Doc to the L-RMS and / or the DID holder).

[0300] At 6, the L-RMS may send a DID document publishing response to the DID holder including Init- DID-Doc. The DID Document registration service or governance service may send the response including Init-DID-Doc to the DID holder (e.g., directly to the DID holder).

[0301] At 7, the DID holder may receive the DID document publishing response. The DID holder may use the L-RMS-Sign-Auth-Scheme, L-RMS-Public-Key, and L-RMS-DID-Doc-Sign in Init-DID-Doc to verify Init-DID-Doc (e.g., to verify L-RMS-DID-Doc-Sign is a valid signature of L-RMS for Init-DID-Doc). For example, the DID holder may verify Init-DID-Doc using an opposite operation of generating the signature (e.g., use L-RMS-Public-Key to decrypt L-RMS-DID-Doc-Sign and compare the decrypted value with the original value such as the hash value of Init-DID-Doc).

[0302] If the signature verification at 7 passed, the DID holder may use its private key (e.g., DID-Holder- Private-Key) to generate its signature for Init-DID-Doc (e.g., DID-Holder-I nit-DI D-Doc-Sign). The DID holder may update one or more parameters (e.g., introduce new parameters, update the value of existing parameters) in Init-DID-Doc. The DI D-Holder-I nit-DI D-Doc-Sign may be calculated considering the values of the updated parameters.

[0303] At 8, the DID holder may send its signature (e.g., DID-Holder-I nit-DI D-Doc-Sign) and / or its public key (e.g., DID-Holder-Public-Key, which can be used by the L-RMS to verify DID-Holder-lnit-DID-Doc-Sign) to the L-RMS. If the DID holder updated any parameters at 7, the DID holder may send the values of the updated parameters to the L-RMS at 8.

[0304] At 9, the network function may receive from the DID holder, a response that indicates the signature associated with the DID holder (e.g., the L-RMS may receive DI D-Holder-I nit-DI D-Doc-Sign). The response may include an updated initial DID document that indicates an updated value of one or more parameters. If any parameters change, L-RMS may regenerate Init-DID-Doc to incorporate the changed parameters. The L-RMS may verify the changes and regenerate the L-RMS-DID-Doc-Sign. The L-RMS may use the changed parameters and regenerated L-RMS-DID-Doc-Sign to update Init-DID-Doc. The network function may verify the second signature based on a public key associated with the device (e.g.,the L-RMS may verify DI D-Holder-I nit-DI D-Doc-Sign using the DID holder’s public key, for example, DID- Holder-Public-Key). If the verification of DID-Holder-lnit-DID-Doc-Sign passes, generate a final DID document based on the initial DID document and the signature associated with the DID holder. For example, the L-RMS may include DI D-Holder-I nit-DI D-Doc-Sign in I nit-DI D-Doc to generate the final DID Document (e.g., Final-DID-Doc, which may be similar to Dev-Final-Public-Doc, described herein). The Final-DID-Doc may include the values of the updated parameters (e.g., as received at 8). The actions described at 9 may be performed by the DID document registration service or governance service. In this case, the DID document registration service or governance service may send Final-DID-Doc to the PDL node.

[0305] At 10, the L-RMS may publish the final DID document (e.g., Final-DID-Doc) to the PDL network as denoted by PDL-NWK-ID via the PDL node. For example, the L-RMS may send a transaction, including the Final-DID-Doc, to the PDL node. The PDL node may verify the transaction and propagate it to other PDL nodes. The Final-DID-Doc may be added to the ledger at each PDL node. The L-RMS may receive an address or URL for accessing the published Final-DID-Doc (e.g., Final-DI D-Doc-URL) from the PDL node.

[0306] At 11 , the network function may send a response that indicates an address associated with the published final DID document. For example, the L-RMS may send a response to the DID holder indicating Final-DI D-Doc-URL. The DID holder may store Final-DI D-Doc-URL (e.g., locally).

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

[0308] Although the implementations described herein may consider 3GPP specific protocols, it is understood that the implementations described herein are not restricted to this scenario and may be applicable to other wireless systems. For example, although the solutions described herein consider LTE, LTE-A, New Radio (NR) or 5G specific protocols, it is understood that the solutions described herein are not restricted to this scenario and are applicable to other wireless systems as well.

[0309] The processes described above may be implemented in a computer program, software, and / or firmware incorporated in a computer-readable medium for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted over wired and / or wireless connections) and / or computer-readable storage media. Examples of computer- readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as, but not limited to, internal hard disks and removable disks, magneto-optical media, and / or optical media such as compact disc (CD)-ROM disks, and / or digital versatile disks (DVDs). A processor in association withsoftware may be used to implement a radio frequency transceiver for use in a WTRU, terminal, base station, RNC, and / or any host computer.

Claims

CLAIMSWhat is Claimed:1 . A network function comprising: a processor, wherein the processor is configured to: receive a decentralized identifier document (DID) document publishing request from a device, wherein the DID document publishing request indicates a DID associated with the device; verify that the device is authorized to publish the DID document; generate an initial DID document that comprises a first signature associated with the network function, wherein the initial DID document is associated with the DID; send a first response to the device, wherein the first response comprises the initial DID document; receive a second response from the device, wherein the second response indicates a second signature associated with the device; verify the second signature based on a public key associated with the device; generate a final DID document based on the initial DID document and the second signature; and publish the final DID document.

2. The network function of claim 1 , wherein the processor is further configured to send a third response to the device, wherein the third response indicates an address associated with the published final DID document.

3. The network function of claim 1 , wherein the network function is a first network function, and the processor being configured to verify that the device is authorized to publish the DID document comprises the processor being configured to: send the DID document publishing request to a second network function; receive, from the second network function, an indication that the DID document publishing request is approved and an indication of the public key associated with the device.

4. The network function of claim 1 , wherein the initial DID document comprises a value of a parameter, and the second response further comprises an updated initial DID document, wherein the updated initial DID document indicates an updated value of the parameter.

5. The network function of claim 1 , wherein the processor is further configured to generate the first signature based on a private key associated with the network function and a signature authentication scheme.

6. The network function of claim 1 , wherein the processor is further configured to: receive a second DID document publishing request from the device; determine that the device is not authorized to publish the second DID document; and send a third response to the device, wherein the third response comprises an indication of a failure cause.

7. The network function of claim 1 , wherein the DID document publication request further indicates a permissioned distributed ledgers (PDL) network, and the final DID document is published to the PDL network.

8. The network function of claim 1 , wherein the network function comprises a ledger registration management service (L-RMS) and a DID document registration service.

9. The network function of claim 1 , wherein the device is a wireless transmit / receive unit (WTRU).

10. A method performed by a network function, the method comprising: receiving a decentralized identifier document (DID) document publishing request from a device, wherein the DID document publishing request indicates a DID associated with the device; verifying that the device is authorized to publish the DID document; generating an initial DID document that comprises a first signature associated with the network function, wherein the initial DID document is associated with the DID; sending a first response to the device, wherein the first response comprises the initial DID document; receiving a second response from the device, wherein the second response indicates a second signature associated with the device; verifying the second signature based on a public key associated with the device; generating a final DID document based on the initial DID document and the second signature; and publishing the final DID document.11 . The method of claim 10, wherein the method further comprises sending a third response to the device, wherein the third response indicates an address associated with the published final DID document.

12. The method of claim 10, wherein the network function is a first network function, and verifying that the device is authorized to publish the DID document comprises: sending the DID document publishing request to a second network function; receiving, from the second network function, an indication that the DID document publishing request is approved and an indication of the public key associated with the device.

13. The method of claim 10, wherein the initial DID document comprises a value of a parameter, and the second response further comprises an updated initial DID document, wherein the updated initial DID document indicates an updated value of the parameter.

14. The method of claim 10, wherein the method further comprises generating the first signature based on a private key associated with the network function and a signature authentication scheme.

15. The method of claim 10, wherein the method further comprises: receiving a second DID document publishing request from the device; determining that the device is not authorized to publish the second DID document; and sending a third response to the device, wherein the third response comprises an indication of a failure cause.

16. The method of claim 10, wherein the DID document publication request further indicates a permissioned distributed ledgers (PDL) network, and the final DID document is published to the PDL network.

17. The method of claim 10, wherein the network function comprises a ledger registration management service (L-RMS) and a DID document registration service.

18. The method of claim 10, wherein the device is a wireless transmit / receive unit (WTRU).

Images