Methods for provisioning blockchain redaction capability in a wireless blockchain system

Abstract

Blockchain Redaction Capability provisioning may be requested by a wireless transmit / receive unit (WTRU). The WTRU may prepare a first information element on requested blockchain redaction capability (BC-RD-Cap-Req). The WTRU may send a first request to a first network function. The first request may include a first blockchain flag, a first blockchain address of the WTRU, and / or the first information element. The first request may be forwarded from the first network function to a second network function according to the blockchain flag. The WTRU may receive a first response from the first network function. The first response may include a blockchain redaction key generation scheme (BC-RD-Key-Scheme) and / or a granted blockchain redaction capability (BC-RD-Cap-Granted). The WTRU may derive a blockchain redaction key according to the blockchain redaction key generation scheme. The WTRU may store the blockchain redaction key. The WTRU may store the granted blockchain redaction capability.

Description

METHODS FOR PROVISIONING BLOCKCHAIN REDACTION CAPABILITY IN A WIRELESS BLOCKCHAIN SYSTEMCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional App. No. 63 / 583,405 filed on September 18, 2023, the entirety of which is incorporated herein by reference.BACKGROUND

[0002] A 5G (5thGeneration) system architecture includes Wireless Transmit / Receive Units (WTRUs), a Radio Access Network (RAN), and a Core Network. One of the design principles for the 5G System (5GS) is service-centric or service-based. 5G Core Network (5GC) includes a variety of network functions, which work together to fulfill and provide needed services to the RAN, WTRUs, and Application Servers / Service Providers. A network function can access other network functions in request / response mode or subscription / notification mode. Before two network functions interact with each other, they first need to register with a Network Repository Function (NRF) so that they can discover each other via the NRF. Among these network functions, Access and Mobility Management Function (AMF) is dedicated to managing WTRU’s access to 5GS and its mobility, Session Management Function (SMF) is responsible for establishing sessions between a WTRU and 5GC, and Authentication Server Function (AUSF) takes charge of WTRU authentication. In addition, Policy Control Function (PCF) provides policy rules for other control plane network functions and WTRUs; PCF assigns an identifier for each created policy rule, which other control plane network functions and WTRUs use to refer to the corresponding policy rule. User Plane Function (UPF) is the only core network function in the data plane that facilitates monitoring, managing, controlling, and redirecting user plane traffic flows such as between a WTRU and an Application Function (AF). Network Exposure Function (NEF) enables access to 5G control plane functions to entities such as network applications and AFs which are outside of 5GS and not in the same trusted domain. 5GC also provides data storage and analytics services through functions like Unified Data Management (UDM), Unified Data Repository (UDR), Unstructured Data Storage Function (UDSF) and Network Data Analytics Function (NWDAF). Another critical feature of 5GS is network slicing, which is facilitated by Network Slice Selection Function (NSSF). Although these network functions are defined as separate logical entities, a particular service scenario may require multiple network functions; for instance, WTRU mobility will need not only AMF, but also AUSF and SMF. For a type of network function, multiple instances could be instantiated and NRF will maintain the information of each instantiated network function instance. With theemergence of edge computing, some network functions in 5GC such as UPF and NEF could be deployed and resided in an edge network that is much nearer to and potentially co-located with the RAN. 5GS introduces a few network functions such as Location Management Function (LMF) to support location services. LMF is responsible for calculating, determining, or verifying a final location and any velocity estimation and may estimate the achieved accuracy, based on location information from the target WTRU and / or a RAN node. After LMF calculates the location of a target WTRU, other entities can access or query its location from LMF but need to go through a serving AMF.SUMMARY

[0003] Authentication and / or provisioning blockchain redaction capability may be provided. Blockchain redaction capability provisioning may be initiated by a device and / or an application function. For example, a wireless transmit / receive unit (WTRU) and / or an application function may request provisioning of a blockchain redaction capability. Blockchain redaction capability may be provisioned to a network function.

[0004] Blockchain Redaction Capability provisioning may be requested by a WTRU. The WTRU may prepare a first information element on requested blockchain redaction capability (BC-RD-Cap-Req). The WTRU may send a first request to a first network function (e.g., an Access and Mobility Management Function (AMF)). The first request may include a first blockchain flag, a first blockchain address of the WTRU, and / or the first information element. The first request may be forwarded from the first network function to a second network function (e.g., a blockchain control function (BCCF)), for example, according to the blockchain flag. 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 blockchain redaction key generation scheme (BC-RD-Key-Scheme) and / or a granted blockchain redaction capability (BC-RD-Cap-Granted). The WTRU may derive a blockchain redaction key according to the blockchain redaction key generation scheme. The WTRU may store the blockchain redaction key. The WTRU may store the granted blockchain redaction capability.

[0005] Blockchain Redaction Capability Provisioning may be requested by an AF. A WTRU may receive a first response from a first network function (e.g., an AMF). The first response may have been generated by a second network function (e.g., a BCCF). The first response may include a blockchain redaction key generation scheme (BC-RD-Key-Scheme), a granted blockchain redaction capability (BC-RD-Cap-Granted), and / or an identifier of a first application function (AF-ID) that initiated the second network function to generate the BC-RD-Cap-Granted for the first node WTRU. The WTRU may determine to accept granted blockchain redaction capability (BC-RD-Cap-Granted). The WTRU may derive a blockchain redaction key according to the blockchain redaction key generation scheme. The WTRU may store the blockchain redaction key. The WTRU may store the granted blockchain redaction capability. The WTRU may send a first confirmation message to the second network function via the first network function. The first confirmation message may include the identifier of the first node and / or the blockchain address of the first node.

[0006] Blockchain Redaction Capability may be provisioned to a 3GPP NF. A WTRU may prepare a first information element on requested blockchain redaction capability (e.g., BC- RD-Cap-Req) indicating the redaction capability on the first node will be delegated to the first network function (e.g., blockchain redaction function (BCRDF)). The WTRU may send a first request to a second network function (e.g., AMF). The first request may include a first identifier of the WTRU, a first blockchain address of the WTRU, the first information element, and / or an identifier of the third network function. The first request may be forwarded from the second network function to the third network function (e.g., BCCF), which will process and forward the first request to the first network function. The WTRU may receive a first response from the second network function. The first response may have been generated by the third network function. The first response may include an identifier of the first network function, a granted blockchain redaction capability (BC-RD-Cap-Granted) to the first network function, and / or a blockchain redaction key generation scheme (BC-RD-Key-Scheme). The WTRU may store the granted blockchain redaction capability.BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

[0011] FIG. 2 is a system diagram illustrating native wireless blockchain system functions.

[0012] FIGS. 3A-3B is a system diagram illustrating an example procedure to authenticate and provision blockchain redaction capability requested by a device.

[0013] FIGS. 4A-4B is a system diagram illustrating an example procedure to authenticate and provision blockchain redaction capability requested by a WTRU.

[0014] FIG. 5A-5B is a system diagram illustrating an example procedure authenticate and provision blockchain redaction capability initiated by a Blockchain Application Function (BCAF).

[0015] FIG. 6A-6B is a system diagram illustrating an example procedure authenticate and provision blockchain redaction capability requested by an application function (AF).

[0016] FIG. 7A-7B is a system diagram illustrating an example procedure provisioning blockchain redaction capability to a network function assisted by a Blockchain Governance Function (BCGF).

[0017] FIG. 8A-8B is a system diagram illustrating an example procedure provisioning blockchain redaction capability to a network function controlled by the BCGF.

[0018] FIG. 9A-9B is a system diagram illustrating an example procedure provisioning blockchain redaction capability to a network function.

[0019] FIG. 10 is a system diagram illustrating an example procedure for provisioning blockchain redaction capability.DETAILED DESCRIPTION

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

[0021] As shown in FIG. 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104 / 113, a CN 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and 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 (UE), 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.

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

[0023] The base station 114a may be part of the RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a wireless service to a specific geographical areathat 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.

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

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

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

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

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

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

[0030] The base station 114b in FIG. 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 cellularbased RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106 / 115.

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

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

[0033] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in FIG. 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0048] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may provide 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.

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

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

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

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

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

[0054] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an AccessPoint (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.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an “ad-hoc” mode of communication.

[0055] 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 in 802.11 systems. For CSMA / CA, the STAs (e.g., every STA), including the AP,may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

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

[0057] Very High Throughput (VHT) STAs may support 20MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. The 40 MHz, and / or 80 MHz, channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+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).

[0058] Sub 1 GHz modes of operation are supported by 802.11 af and 802.11 ah. The channel operating bandwidths, and carriers, are reduced in 802.11af and 802.11ah relative to those used in 802.11 n, and 802.11ac. 802.11af 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.11ah may support Meter Type Control / Machine-Type Communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and / or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0059] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11 n, 802.11ac, 802.11af, and 802.11 ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., onlysupport) 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 (e.g., only) a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.

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

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

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

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

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

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

[0066] The CN 115 shown in FIG. 1 D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the 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.

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

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

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

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

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

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

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

[0074] A blockchain system may include of two general types of blockchain nodes: full blockchain nodes and light blockchain nodes. A full blockchain node has all blockchain functions (e.g., host and maintain ledgers, participate in consensus protocols to generate new blocks, and validate received blocks). A light blockchain node acts as a blockchain client node such as digital wallets that sends transactions to the blockchain system via one or multiple full blockchain nodes.

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

[0076] Although a blockchain ledger is usually append-only and immutable due to the use of hash-based chain structure to link blocks together, there are some techniques to enable mutable or redactable blockchain, where a committed block could be modified or even removed without breaking the hash-based chain structure. Most of those techniques rely on one or multiple security keys, referred to as blockchain redaction keys, to enable hash collisions so that any party with the access to blockchain redaction keys can redact or modify existing blocks while maintaining the hash-based ledger structure due to the leveraging of hash collisions. Blockchain redaction keys could be generated or provisioned when the blockchain system is initiated. Full blockchain node may be referred to herein as Blockchain Service Node (BSN), while a light blockchain node is referred to as Blockchain Client Node (BCN). A device or a WTRU could be a BCN (if it only uses blockchain ledgers as a client) or a BSN (if it maintains blockchain ledgers and supports full blockchain functions). Since BCN and BSN are logical entities, a physical device or WTRU could host one or multiple instances of BCN and / or BSN if the physical device has sufficient resources to support.

[0077] A blockchain system could be: 1) a permissionless blockchain system (e.g., Bitcoin, Ethereum) where any party or user can use and participate in the blockchain system without pre-granted permissions; or 2) a permissioned blockchain system where access to the blockchain system needs to be permissioned, controlled and / or governed. Permissioned Distributed Ledgers (PDL) is an example of permissioned blockchain systems. PDL reference architectures, use cases, specific PDL functionalities, and vertical domains may be implemented. Various use cases and some techniques enable redactable distributed ledgers. There are also use cases where PDL can be leveraged and integrated with wireless communication systems (e.g., 3GPP system, 5GS). There may also be standards for provisioning PDL services (e.g., within 3GPP system). Example functions include Ledger Anchor Function (LAF), Blockchain Repository Function (BCRF), and Blockchain Enabler Function (BCEF). LAF and BCRF may be implemented as control plane functions (e.g., for the 3GPP system), while BCEF may be a data plane function.

[0078] Cellular wireless systems (e.g., 5GS) may provide various security functions, such as primary authentication during registration, secondary authentication during Protocol Data Unit (PDU) session establishment, network slicing-specific authentication and authorization, network slicing admission control, data plane encryption and integrity protection, etc. Cellular wireless systems, such as 6G Systems (6GS), may feature a broad range of heterogeneous devices and networks with an expected expansion of the supported verticals (e.g., mission critical) and thus need to be more trustworthy than 5G Systems. For example, devices and their interactions with wireless systems may be trustable by core network functions, application functions (in the cloud or at the edge), and other devices, referred to as trusted devices or trusted WTRUs. Security functions may lack the support for assessing or enforcing the trustworthiness of a given WTRU. For instance, whether a device is trustable could be dynamic and time-changing, while primary authentication or secondary authentication may not consider nor support such dynamic device trust.

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

[0080] To leverage blockchain technologies for enabling trustworthy systems, the wireless communication system may integrate blockchain capabilities (e.g., as network functions) with the wireless communication system as integral functions, which may be referred to as native wireless blockchain. Native wireless blockchain may be a permissioned blockchain system. For a device to efficiently interact with such a native wireless blockchain, the device first may be properly onboarded to the native blockchain and be provisioned with configuration information for interacting with it, which may be referred to as device onboarding to native wireless blockchain or wireless blockchain onboarding for simplicity.

[0081] Blockchain redaction capability may be implemented for permissioned blockchain systems. A device may have been granted with capability to redact a blockchain ledger (e.g., modify or remove a committed block), for instance, to remove some on-chain data that becomes privacy-threating or outdated. The capability to redact a blockchain ledger may be controlled bysecurity keys (e.g., blockchain redaction keys). The issue is how to authenticate and assign blockchain redaction capability to a device during wireless blockchain onboarding (e.g., how to generate appropriate blockchain redaction keys and assign them to authorized entities). A device may be a WTRU (e.g., a User Equipment (UE)). Network Function may refer to a processing function in a network (e.g., 5GC). Trusted Device may refer to a device or WTRU which can be trusted by a cellular wireless system, such as 6GS. Blockchain Client Node (BCN) may refer to a light blockchain node which may interact (e.g., only interacts) with blockchain service nodes to send transactions. An example of blockchain client node may include a digital wallet. A blockchain application function within network is another example of BCN. Blockchain client node and blockchain client may be interchangeable. A BCN may have a BCAF such as a BCCCF. Blockchain Service Node (BSN) may refer to a full blockchain node which implements each function of blockchain technology (e.g., maintain a blockchain ledger, participate in consensus protocols). A BSN may have a BCSF. Blockchain Control Function (BCCF) may refer to a logical entity or a network function acting as the entry point for devices or applications to interaction with native wireless blockchain for control plane purposes such as managing BCNs and BSNs. Blockchain Service Function (BCSF) may refer to a logical entity or a network function acting as the entry point for devices or applications to interaction with native wireless blockchain for data plane purposes such as creating / sending new transactions. BCSF may be a part of a BSN. Blockchain Governance Function (BCGF) may refer to a logical entity or a network function acting for coordinating, governing, and / or managing the whole native wireless blockchain. BCGF may interact with BCCF, BCSF, and optionally other application functions or network functions (e.g., a system management application). Blockchain Application Function (BCAF) may refer to a logical entity or an application function which can act as a BCN to interact with BSNs (e.g., BCSFs) for generating and retrieving transactions. A BCAF may also interact (e.g., only interact) with other blockchain functions (BCCF, BCGF and BCSF) for controlling and managing the native wireless blockchain, but not necessarily generate any transaction to a blockchain ledger. A BCAF may have a blockchain address. Blockchain Client and Consumer Function (BCCCF) may refer to a BCAF on a BCN node. A BCCCF may reside in the network or a part of a BSN; when a BSN has a BCCCF, this BCCCF may be used by the BSN to perform transactions-based management purposes (e.g., the BSN may need to record its behaviors to blockchain ledgers); in this case, the BCCCF on the BSN can generate new transactions and send them to another BSN / BCSF. A BCCCF may have a blockchain address, which may be assigned or authorized by BCCF / BCGF; after that, a BCCCF may use its authorized blockchain address to consumer the services provided by a BCSN. Identifier may refer to thename / identifier / address of an entity (e.g., a device / WFRU, a network function such as 3GPP NFs and BCCCF, BCCF, BCSF, BCGF, BCRDF, etc.). An identifier may be a 3GPP identifier, an IP address, a URL (Uniform Resource Locator), a FQDN (Fully Qualified Domain Name), a blockchain address, etc. The identifier of an entity may enable or give access details based on which other entities can access and interact with this entity. Blockchain Address may refer to the address or identifier that uniquely identifies a blockchain entity (BCN, BSN, BCAF, BCSF, BCCCF, or other blockchain function) within a blockchain system. A blockchain address could be a sender or a recipient of a blockchain transaction. A blockchain service node could have a blockchain address which can be used for sending special transactions (e.g., transactions for managing the corresponding blockchain system). A blockchain application function may have a blockchain address. If a BCCF (or a BCGF) wants to send a transaction to blockchain ledger (e.g., for a management purpose, to record its behavior data to blockchain ledger), the BCCF (or the BCGF) can have a blockchain address or have an embedded BCN / BCCCF or BCAF. Blockchain Address Signature refers to the scenario where a blockchain address in a permissioned blockchain system may be authenticated and authorized. Before a blockchain address is authorized, it may include a raw blockchain address, which usually is generated based on a public key. After a raw blockchain address is authorized by an authorizing party (e.g., by a BCGF, a BCCF, and / or an AUSF), it may become an authorized blockchain address, which may include the raw blockchain address and / or a blockchain address signature. The blockchain address signature may be generated by the authorizing party using a private key. Any party (e.g., devices, BCSFs, BCCF) knowing the corresponding public key (associate with the private key for generating the blockchain address signature) can validate the blockchain address signature. Device Blockchain Address may refer to the blockchain address for a device in a blockchain system. Blockchain Ledger may refer to a ledger storing transactions and blocks and related system status in a hash-connected chained structure. Each full blockchain node may maintain a blockchain ledger. Blockchain ledger, distributed ledger, and ledger may be interchangeably used. Blockchain Technology may refer to a set of technologies used in a blockchain system such as consensus protocols, transaction generation and validation, block generation and validation, blockchain ledgers, etc. Blockchain technology and distributed ledger technology may be interchangeably used. Blockchain System refers to a system implementing or using blockchain technology. In this disclosure, blockchain system is equivalent to distributed ledger. A blockchain system may include many light blockchain nodes and / or a group of full blockchain nodes. Native Wireless Blockchain may refer to a blockchain system integrated with and implemented as a part of a cellular wireless system, such as 6G System (6GS). Nativewireless blockchain may include a set of blockchain-related functions such as, but not limited to, BCCCF, BCCF, BCGF, BCSF, and BCAF; those blockchain- related functions can be deployed in core network, edge networks, and even co-located with some powerful devices. Transaction may refer to a message that is usually sent from a sender (e.g., BCN-A, a BSN-A) and a recipient (e.g., BCN-B, a BSN-B). The message may include some information (e.g., digital currency, data, token) exchanged from the sender to the recipient. Block may refer to a data structure that may include a block header and a block body. The block body may include a set of transactions. A block may be generated by a BSN as a result of executing a blockchain consensus protocol. 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). Permissioned Blockchain System may refer to a blockchain system where the access to blockchain ledger (e.g., write data to blockchain ledger, read data from blockchain ledger, update / remove data in blockchain ledger) is available to permissioned or authorized parties, which usually are governed by a BCGF.

[0082] Blockchain redaction capability may be provisioned. Blockchain redaction capability provisioning may be initiated by different parties such as devices, network functions, and / or application functions. Blockchain redaction capability may be delegated (e.g., from a device to a network function). Blockchain redaction keys may be managed (e g., by a blockchain governance function). A blockchain redaction capability assigned to a device may be securely controlled and / or governed by a native wireless blockchain. Overhead for blockchain redaction at a device may be offloaded and / or reduced.

[0083] FIG. 2 is a system diagram 200 illustrating native wireless blockchain system functions in the context of an example 3GPP system.

[0084] A WTRU may be a light blockchain node 202 (e.g., WTRU-1) hosting a BCCCF 204 or a full blockchain node 206 (e.g., WTRU-2) hosting a BCSF 208. In a blockchain control plane, one or more blockchain-related functions (e.g., BCCCF, BCCF, BCGF, BCSF, and / or BCAF) may interact to perform one or more tasks related to but not limited to provisioning and / or managing the native wireless blockchain system. For example, a BCGF may coordinate blockchain security key derivation and / or distribute the derived blockchain security keys to the BCCF and / or the BCSF. The BCGF may interact with AUSF or be implemented as a part of AUSF to derive a blockchain security key based on one or more existing 3GPP key materials. In examples, the BCGF and the BCCF may determine and / or select WTRUs which may be onboarded to the native wireless blockchain system. The BCAF 212 may trigger the BCGF toselect one or more WTRUs for wireless blockchain onboarding. In examples, when a WTRU starts to onboard to the native wireless blockchain system, the WTRU may interact (e.g., only interact) with the BCCF, which is the entry point for the WTRU. The BCCF may be implemented as a part of an AMF or a standalone NF in 3GPP core network. During the wireless onboarding process, the BCCF may check with BCGF to determine if the WTRU is authorized to be onboarded. For this purpose, the BCGF may interact with 3GPP NFs (e.g., UDM) to retrieve the WTRU’s subscription data. In examples, the BCGF and the BCCF may determine to provision blockchain redaction capabilities to a WTRU when or after the WTRU is onboarded to the native wireless blockchain system.

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

[0086] A 3GPP Network (e.g., a Public Land Mobile Network (PLMN), a Non-Public Network (NPN)) as identified by 3GPP-NWK-ID may deploy and / or operate multiple native wireless blockchains. 3GPP-NWK-ID may be a PLMN-ID. The same set of physical blockchain nodes and physical network nodes / links may be leveraged by the 3GPP network to create multiple virtual native wireless blockchains. Each native wireless blockchain may be deployed in different locations, may be used to support different WTRUs and / or applications, and / or may provide different services. A native wireless blockchain may be identified and / or assigned by the 3GPP network with an identifier or a name (e.g., such as Native-BC-ID), which may be unique within the 3GPP Network or globally unique. Native-BC-ID may comprise information related to a 3GPP-NWK-ID, a context-1 D, a consensus-protocol-type, and / or a unique-BC-Seq. The 3GPP-NWK-ID may be the identifier of the 3GPP Network, which may be a PLMN-ID. The Context-1 D may be the hashed value of the context information of the native wireless blockchain (e.g., the location where the native wireless blockchain is deployed). The Consensus-Protocol- Type may be the type of consensus protocol used in the native wireless blockchain. The Unique-BC-Seq may be a sequence number or a name that identifies the native wireless blockchain uniquely within the 3GPP Network.

[0087] One or more functions in FIG. 2 may map to one or more other entities or functions. For example, BCCF may map to LAF. The BCCF in core network may map to a centralized LAF. The BCCF in RAN / Edge may map to a distributed LAF. The BCGF 210 maymap to a BCRF. Additionally or alternatively, the BCGF 210 may be implemented as another network function. The BCCCF may map to BCEF within WTRU. The BCSF may map to a BCEF with a full blockchain node.

[0088] Additionally or alternatively, FIG. 2 may map to one or more entities or functions. The BCCF may map to distributed LAF. The BCGF 210 may map to centralized LAF. Additionally or alternatively, the BCGF 210 may be implemented as another network function. The BCCCF may map to BCEF within WTRU. The BCSF may map to BCEF with a full blockchain node.

[0089] Redactable Blockchain may refer to a blockchain system where blockchain ledgers can be modified while maintaining their hash-connected structure. Redactable blockchain and redactable ledger may be used interchangeably herein unless there is an explicit clarification. A BSN may provide a redactable blockchain ledger. A Committed Block may refer to a block that has been validated and agreed by one or more (e.g., all) BSNs to be appended to a current blockchain ledger. A Committed Transaction may refer to one or more transactions in a committed block. A Blockchain Redaction may refer to a process to modify or redact a blockchain ledger, which may be enabled or controlled by a blockchain redaction key. Blockchain Redaction Operations may refer to actions that are needed or involved in the process of blockchain redaction. For example, a blockchain redaction operation may modify a committed block. In another example, a blockchain redaction operation may remove a committed block. Blockchain Redaction Capability may refer to the capability for a device or other entities to perform blockchain redaction operations. Blockchain Redaction Keys may refer to security keys that enable or control only the owner of blockchain redaction keys can perform blockchain redaction operations.

[0090] A device may initiate a request for blockchain redaction capability for a native wireless blockchain (e.g., from a BCCF). As a result, the device may be able to modify blockchain ledgers (e.g., to modify committed transactions with the device as the sender or the recipient).

[0091] Blockchain Redaction Capability provisioning may be requested by a WTRU. The WTRU may prepare a first information element on requested blockchain redaction capability (BC-RD-Cap-Req). The WTRU 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 WTRU, 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), for example, according to the blockchain flag. The WTRU may receive a first response from the first network function. Thefirst response may have been generated by the second network function. The first response may include a blockchain redaction key generation scheme (BC-RD-Key-Scheme) and / or a granted blockchain redaction capability (BC-RD-Cap-Granted). The WTRU may derive a blockchain redaction key according to the blockchain redaction key generation scheme. The WTRU may store the blockchain redaction key. The WTRU may store the granted blockchain redaction capability.

[0092] FIGS. 3A-3B is a system diagram illustrating an example procedure 300 for authenticating and provision blockchain redaction capability requested by a Device 301. FIGS. 3A-3B illustrates that a Device 301 (e.g., a BCN or a BSN) may request blockchain redaction capability for redacting blockchain ledgers. The Device 301 may have been onboarded to the native wireless blockchain (e.g., its blockchain address has been authorized, it has been provisioned with blockchain system configuration information). The Device 301 may send a request to a BCCF 303 indicating its requirements on blockchain redaction capability. The BCCF 303 may then authorize the request with help from the BCGF 305 and grant blockchain redaction capability for the Device 301 , which may be the same or different than what the Device 301 requested. The BCCF 303 may then send the granted blockchain redaction capability to the Device 301. The BCCF 303 may also send the granted blockchain redaction capability for the Device 301 to a BCSF 307 which serves the Device 301 in the blockchain user plane, so that the BCSF 307 can authenticate and authorize any redaction operations that the Device 301 may send to the BCSF 307 in the future. The BCCF 303 also may generate a blockchain redaction capability provisioning record and store the record to blockchain ledgers. As a result, the Device 301 may be able to modify blockchain ledgers.

[0093] The authentication and provisioning of blockchain redaction capability procedure in FIGS. 3A-3B may include one or more of the following operations. The blockchain address of the Device 301 may be assumed to be authorized by the network or the Device 301 may have received an authorized blockchain address from the network. The Device 301 may have received the address or the identifier of the BCCF 303 from network (BCCF-ID) and preconfigured with BCCF-ID. In this procedure, the Device 301 may be a BCSF 307 that may have created and stored blocks to blockchain ledgers in the native wireless blockchain as denoted by Native-BC-ID; then the BCSF 307 in FIG. 3A may be the neighboring BCSF 307 of the Device 301 , which means the Device 301 can send any blocks created by the Device 301 the BCSF 307. In FIGS. 3A-3B, the Device 301 may be a BCN / BCCCF; then, BCSF 307 in FIGS. 3A-3B may be the BCSN which are assigned to serve the Device 301 ; in other words, the Device 301 accesses native wireless blockchain via the BCSF 307.

[0094] In the example illustrated by FIGS. 3A-3B, the Device 301 may have an identifier (e.g., Dev-ID) and may have been onboarded to the target native wireless blockchain (Native- BC-ID) with an authorized blockchain address (e.g., Authorized-Dev-BC-Addr). At 302, the Device 301 may send a blockchain redaction capability request to the BCCF 303. The purpose of this request may be for the Device 301 to request blockchain redaction capability (e.g., the capability of modifying committed transactions with the Device 301 as a sender). This request may include Dev-ID, Authorized-Dev-BC-Addr, Native-BC-ID, BCCF-ID, and / or requested blockchain redaction capability (e.g., BC-RD-Cap-Req). BC-RD-Cap-Req may comprise one or more of the following parameters: Native-BC-ID-by-RD, BC-RD-lssuer, BC-RD-Mode, BC-RD- Scope, and / or Native-BC-ID-for-RD.

[0095] Native-BC-ID-by-RD may refer to the identifier of the native wireless blockchain where redaction operations will be sent to or which blockchain ledgers will be redacted. Native- BC-ID-by-RD may be equal to Native-BC-ID. BC-RD-lssuer may indicate the identifier of the blockchain redaction issuer that can issue blockchain redaction operations. For the case in FIGS. 3A-3B, BC-RD-lssuer may be set to Dev-ID or Authorized-Dev-BC-Addr. BC-RD-Mode may indicate the blockchain redaction mode. The blockchain redaction mode may be Direct Redaction or Indirect Redaction. For Direct Redaction, the blockchain redaction issuer can perform redaction operations directly through a BCSF 307. In this case, BC-RD-Mode may also indicate the identifier of the BCSF 307 (BCSF-ID). For Indirect Redaction, each blockchain redaction operation from the blockchain redaction issuer may be authorized first by the BCCF 303. The BCCF 303 may send the authorized blockchain redaction operation to the target native wireless blockchain on behalf of the blockchain redaction issuer. BC-RD-Scope may indicate the scope of blockchain redaction. The scope of the blockchain redaction may include transactions issued from one or more than one blockchain addresses. The scope of the blockchain redaction may include transactions with one or more than one blockchain addresses as recipients. The scope of the blockchain redaction may include transactions with a pair of blockchain addresses as the sender and the recipient; Committed blocks being created by a specific BCSF 307 (e.g., BC-RD-lssuer). The scope of the blockchain redaction may include committed blocks including transactions from a set of specific blockchain addresses. For example, if BC-RD-Scope = “Dev-ID as the Sender”, it may indicate that the Device 301 requests blockchain redaction capability for committed transactions with itself as the sender or committed blocks with itself as the creator. Native-BC-ID-for-RD refers to the identifier of a native wireless blockchain which may be used to store the history of blockchain redaction operations. Native-BC-ID-for-RD may be equal to Native-BC-ID. This parameter may beoptional during the process described above, but may be determined by the BCGF 305 when the BCGF 305 receives a redaction capability request from the BCCF 303, described below. The request described above may be signed by the Device 301 using its blockchain private key (Dev-BC-Private-Key). As such, the request may include the Device’s signature (Dev-BC-Sign).

[0096] The BCCF 303 may receive the request described above. If the request includes Dev-BC-Sign, the BCCF 303 may verify the integrity of the request using the Device’s blockchain public key (Dev-BC-Public-Key). At 304, BCCF 303 may check if Authorized- Dev- BC-Addr is an authorized address by looking up its local database maintaining one or more (e.g., all) authorized blockchain addresses. If the BCCF 303 does not have such local database or it cannot find Authorized-Dev-BC-Addr from its local database, it may send Authorized- Dev- BC-Addr and Dev-ID to the BCGF 305; the BCGF 305 can verify Authorized-Dev-BC-Addr and send a response to the BCCF 303 indicating if Authorized-Dev-BC-Addr is authorized or rejected. If Authorized-Dev-BC-Addr is not an authorized address, some processes described below may not be needed; instead, the BCCF 303 may send “Blockchain Redaction Capability Rejection” as a blockchain redaction capability response to the Device 301.

[0097] At 306, the BCCF 303 may forward the blockchain redaction capability request, described above, to the BCGF 305. The BCCF 303 may also indicate that it has checked Authorized-Dev-BC-Addr and it is valid. At 308, the BCGF 305 may receive the request described above. In this example, the BCGF 305 may authorize the request in two subprocesses. The BCGF 305 may first use Dev-ID and / or Authorized-Dev-BC-Addr to check its local policies (or the Device’s subscription data and / or policies from core network) to determine if the Device 301 is allowed to request blockchain redaction capability. If the Device 301 is allowed to request blockchain redaction capability, the BCGF 305 may check BC-RD-Cap-Req against its local policies to grant blockchain redaction capability to the Device 301 (e.g., BC-RD- Cap-Granted). BC-RD-Cap-Granted may include the same set of parameters as BC-RD-Cap- Req includes, but the value of each parameter may not be equal to BC-RD-Cap-Req. For example, BC-RD-Mode in BC-RD-Cap-Req may be “Direct Redaction”, but the granted “BC-RD- Mode” in BC-RD-Cap-Granted may be changed to “Indirect Redaction” to make blockchain redaction more controlled by the BCCF 303. In another example, the BCGF 305 may (re)determine Native-BC-ID-for-RD and include it in BC-RD-Cap-Granted. In another example, the BCGF 305 may (re)determine Native-BC-ID-by-RD and include it in BC-RD-Cap-Granted.

[0098] BC-RD-Cap-Granted may include the following parameters described herein. For example, BC-RD-Cap-Granted may include Para-for-BC-RD-Enabler, which may indicate parameters to enable blockchain redaction operations. Para-for-BC-RD-Enabler, andparameters to enable blockchain redaction operations, may include Tran-Format-with-BC-RD- Support, Block-Format-with-BC-RD-Support, and Special-Tran-Format-for-BC-RD-OP. Tran- Format-with-BC-RD-Support refers to the transaction format or template for the BC-RD-lssuer to generate a regular transaction (e.g., send a data in the transaction to the native wireless blockchain). In order to support blockchain redaction on transactions, a regular transaction may include some new fields, dependent on the specific blockchain redaction scheme (e.g., Chameleon Hash (CH)). If using CH-based blockchain redaction scheme, the parameters (a, b) in CH may be such fields to be included in a transaction header. Block-Format-with-BC-RD- Support refers to the block format or template for the BC-RD-lssuer to generate a regular block. In order to support blockchain redaction on blocks, a block may include some fields, dependent on the specific blockchain redaction scheme (e.g., Chameleon Hash (CH)). If using CH-based blockchain redaction schemes, the parameters (a, b) in CH may be such fields to be included in a block header. If the BC-RD-lssuer is a BCN or a BCCCF, this parameter may not be implemented since a BCN or a BCCCF may not create any block. Special-Tran-Format-for-BC- RD-OP refers to the transaction format or template for including a blockchain redaction operation. In other words, this format defines the transaction used to issue or include a blockchain redaction operation.

[0099] At 310, the BCGF 305 may derive a blockchain redaction key (KBCRD) for the Device 301 for the target native wireless blockchain, using a key generation scheme BC-RD- Key-Scheme and some input parameters such as Native-BC-ID and / or Native- BC- 1 D-by-RD, and a private security key which may only be known to the Device 301 and the network (e.g., the BCGF 305). The BCGF 305 may also derive a public key corresponding to KBCRD (KBCRD-PUB). Any entity or node with the access to KBCRD will be able to issue blockchain redaction operations as specified by BC-RD-Cap-Granted. Therefore, KBCRD must be kept privately and the BCGF 305 may share it with the BCCF 303 (especially when BC-RD-Mode included in BC-RD-Cap- Granted is “Indirect Redaction”). The BCGF 305 may also generate a blockchain redaction proof (BC-RD-Proof), which may be generated using the BCGF’s public key and / or the Device’s private key; thus, BC-RD-Proof may be verified by the BCGF’s private key and / or the Device’s public key. BC-RD-Proof may be generated based on KBCRD. The BCGF 305 may specify a blockchain redaction proof scheme (BC-RD-Proof-Scheme), which may be notified to the Device 301. The Device 301 may use BC-RD-Proof-Scheme to generate BC-RD-Proof when it needs to perform a blockchain redaction operation; then the Device 301 may send / present the generated BC-RD-Proof to BCSF 307 / BCCF 303 for verification. In this case, the BCGF 305 may not generate / send a BC-RD-Proof to the Device 301.

[0100] At 312, the BCGF 305 may send a blockchain redaction capability response to the BCCF 303. This response may include Authorized-Dev-BC-Addr, Native-BC-ID, BC-RD- Cap-Granted, BC-RD-Proof, BC-RD-Proof-Scheme, BC-RD-Key-Scheme, and / or KBCRD. BC- RD-Proof-Scheme and BC-RD-Key-Scheme may be included in BC-RD-Cap-Granted. At 314, the BCCF 303 may store BC-RD-Proof, BC-RD-Proof-Scheme, BC-RD-Key-Scheme, KBCRD locally and privately. At 316, the BCCF 303 may generate a blockchain redaction capability provisioning record (BC-RD-Cap-Granted-Record), which may include Authorized-Dev-BC- Addr, Native-BC-ID, BC-RD-Proof-Scheme, BC-RD-Key-Scheme, BC-RD-Cap-Granted, and / or KBCRD-PUB- The BCCF 303 may store this record locally and / or store it to the native wireless blockchain. At 318, the BCCF 303 may send the generated blockchain redaction capability provisioning record to a BCSF 307, through which the Device 301 may issue blockchain redaction operations (especially when BC-RD-Mode included in BC-RD-Cap-Granted is “Direct Redaction”), for example, when a device sends a blockchain redaction request to the BCSF 307, described below. The BCSF 307 may create a transaction including the received blockchain redaction capability provisioning record and send this transaction to the native wireless blockchain so that one or more (e.g., all) other BCSFs may receive this blockchain redaction capability provisioning record and can use it to authorize and approve future blockchain redaction operations from other parties. At 320, the BCCF 303 may send a blockchain redaction capability response to the Device. This response may include BC-RD- Proof, BC-RD-Proof-Scheme, BC-RD-Key-Scheme and BC-RD-Cap-Granted; alternatively, this response may include a URL of the stored BC-RD-Cap-Granted (BC-RD-Cap-Granted-URL), which the Device 301 can use to retrieve BC-RD-Cap-Granted.

[0101] At 322, the Device 301 may receive the redaction capability response described above. It may derive KBCRD according to BC-RD-Key-Scheme, which may be equal to KBCRD derived by the BCGF 305 in operation 310. The Device 301 may store KBCRD locally and privately. The Device 301 may also generate a BC-RD-Proof according to BC-RD-Proof- Scheme and store it locally and privately. At 324, the Device 301 may store BC-RD-Cap- Granted locally If the response from operation 320 includes BC-RD-Cap-Granted-URL, the Device 301 can retrieve BC-RD-Cap-Granted from this URL. When BC-RD-Mode included in BC-RD-Cap-Granted is “Direct Redaction”, processes described below may be performed.

[0102] The Device 301 may decide to modify an existing block Old-Block (or a transaction) stored in the native wireless blockchain ledgers, for example, when the data included in the existing block becomes inaccurate or causes privacy concerns. For this purpose, at 326, the Device 301 may generate a blockchain redaction transaction, which may include theNative-BC-ID (or Native-BC-ID-by-RD), Old-Block-ID, New-Block-Content, BC-RD-Proof, and / or Parameters-for-Hash-Collision. Native-BC-ID refers to the identifier of the native wireless blockchain where old blocks (or old transactions) have been maintained. Old-Block-ID may refer to the identifier of Old-Block, based on which the BCSF 307 may be able to find or locate Old- Block from blockchain ledgers. New-Block-Content refers to the content of the new block (New- Block) to replace Old-Block. BC-RD-Proof may be the encrypted version of BC-RD-Cap- Granted using KBCRD or the encrypted version of hashed BC-RD-Cap-Granted using KBCRD. Alternatively, BC-RD-Proof may be a random number based on input parameters such as Authorized-Dev-BC-Addr, Native-BC-ID, and KBCRD; since KBCRD is known to the Device 301 and the BCCF 303, the BCCF 303 will be able to verify BC-RD-Proof if it is presented to the BCCF 303. BC-RD-Proof may be received from the BCCF’s blockchain redaction capability response, or BC-RD-Proof may be generated after the response is received, when KBCRD is derived. Parameters-for-Hash-Collision refers to parameters used to generate hash collision so that the replacement of Old-Block with New-Block will not break the hash-based chain structure of blockchain ledgers in the target native wireless blockchain as denoted by Native-BC-ID. Those parameters may be different, for different blockchain redaction schemes being used. For example, for blockchain redaction schemes based on Chameleon Hash (CH), KBCRD can be used as the trapdoor key in CH; then, two parameters (a’, b’) will be generated using Old-Block, New-Block, KBCRD, and Old-Block-Hash= CH. Hash (a, b, Old-Block, KBCRD-PUB), so that eventually New-Block-Hash=CH.Hash (a’, b’, New-Block, KBCRD) is equal to Old-Block- Hash=CH.Hash (a, b, Old-Block, KBCRD-PUB). Here, (a, b) are two random numbers selected when generating Old-Hash assuming Old-Block has never been modified before.

[0103] At 328, the Device 301 may send a blockchain redaction request to the BCSF 307 which was previously determined by the BCGF 305 to serve the Device 301. This request may include the blockchain redaction transaction generated in the process described above. The BCSF 307 may receive the blockchain redaction request. At 330, the BCSF 307 may verify and authorize this request using the following process. The BCSF 307 may check BC-RD-Cap- Granted for the Device 301 , which was received from the BCCF 303 from operation 318. For example, the BCSF 307 may check if BC-RD-Mode and BC-RD-Scope included in BC-RD-Cap- Granted allows the Device 301 to send this redaction request. If not allowed, the BCSF 307 may reject this redaction request. The BCSF 307 may send BC-RD-Proof to the BCCF 303. The BCCF 303 may decrypt BC-RD-Proof using KBCRD. The BCCF 303 may check if the decrypted BC-RD-Cap-Granted is equal to the BC-RD-Cap-Granted stored locally. If they are not equal, the BCCF 303 may send a rejection to the BCSF 307 and the BCSF 307 may rejectthis redaction request. If BC-RD-Proof is a random number based on input parameters such as Authorized-Dev-BC-Addr, Native-BC-ID, and KBCRD. Those input parameters were known to the BCCF 303. The BCCF 303 may generate a temporary proof (Temp-Proof) using those input parameters. If Temp-Proof is equal to BC-RD-Proof, BC-RD-Proof is valid. Otherwise, the BCCF 303 may send a rejection to the BCSF 307 and the BCSF 307 may reject this redaction request. The BCSF 307 may send Parameters-for-Hash-Collision, New-Block-Content, and Old- Block-Content (which the BCSF 307 can retrieve from the native wireless blockchain ledgers) to the BCCF 303. The BCCF 303 may verify if a hash collision will be caused between New-Block and Old- Block. If there is no hash collision, the BCCF 303 may send a rejection to the BCSF 307 and the BCSF 307 may reject this redaction request. If the BCCF 303 shares KBCRD with the BCSF 307, this process may be done by the BCSF 307 locally without contacting the BCCF 303.

[0104] If the BCSF 307 rejects the redaction request described above, the BCSF 307 may skip execution of the blockchain redaction request and the BCSF 307 may send a “Blockchain Redaction Rejection” to the Device 301 in a Blockchain Redaction Response. Alternatively, at 332, the BCSF 307 may execute the blockchain redaction request. To execute the blockchain redaction request, the BCSF 307 may replace Old-Block with New-Block and may replace Old-Block-Hash with New-Block-Hash in blockchain ledgers. New-Block may include (a’, b’), which is a replacement of (a, b) in Old-Block. Further, the BCSF 307 may generate a blockchain redaction history transaction, which may include the same parameters as in the blockchain redaction request. The BCSF 307 may send this history transaction to the native wireless blockchain as denoted by Native-BC-ID-for-RD. Further, the BCSF 307 may forward this redaction request to other BCSFs, which may perform the same process described above. At 334, the BCSF 307 may send a response to the Device 301 indicating if the request has been rejected or successfully executed.

[0105] The detailed operations of the processes described above may depend on actual blockchain redaction schemes being used to modify blockchain ledgers. The parameters included in the blockchain redaction transaction and the blockchain redaction request also may depend on actual blockchain redaction schemes.

[0106] The processes described above can be implemented in a wireless communication system architecture, such as a 3GPP system architecture (e.g., 5GS), in several ways. Another embodiment for FIGS. 3A-3B is illustrated in FIGS. 4A-4B. FIGS. 4A-4B is a system diagram illustrating an example procedure 400 to authenticate and provision blockchain redaction capability requested by a WTRU 401. A Device described by FIGS. 3A-3B may beimplemented as a part of 3GPP WTRU (e.g., a UE). BCCF 303 described by FIGS. 3A-3B may be implemented as a 3GPP network function. Alternatively, BCCF may be implemented as a part of an AMF (e.g., 3GPP AMF). BCGF 305 described by FIGS. 3A-3B may be implemented as a part of an AUSF (e.g., 3GPP AUSF). BCGF 305 in FIGS. 3A-3B may be implemented as a NF (e.g., 3GPP NF). But some BCGF 305 functions in FIGS. 3A-3B may be incorporated to BCCF in FIGS. 4A-4B. BCSF 307 described by FIGS. 3A-3B may be implemented as a 3GPP network function or a part of 3GPP UDR or UDSF.

[0107] The procedure 400 in FIGS. 4A-4B may comprise the operations described below. Similar to FIGS. 3A-3B, the WTRU 401 may obtain a blockchain address (Authorized- WTRU-BC-Addr), which is equivalent to Dev-BC-Addr in FIGS. 3A-3B. WTRU-ID may be SUCI or 5G-GUTI (5G Globally Unique Temporary Identity) of the WTRU 401 , which is equivalent to Dev-ID in FIGS. 3A-3B. The request in the process 400 described herein may include another parameter BC-Flag. If BC-Flag = TRUE, the AMF 403 will regard this request as a blockchain- related request and will forward it to the BCCF 405. This request may include Native-BC-ID, the identifier of the native wireless blockchain that the WTRU 401 has been onboarded to and that blockchain redaction operations as requested by this request will be applied to. The request in the process 400 described here may also include BC-RD-Cap-Req. The WTRU 401 may sign this request using its blockchain private key (WTRU-BC-Private-Key) and generate a signature (WTRU-BC-Sign) to be included in this request. WTRU-BC-Private-Key is equivalent to Dev- BC-Private-Key in FIGS. 3A-3B, while WTRU-BC-Sign is equivalent to Dev-BC-Sign in FIGS. 3A-3B. This request may also include the identifier of the BCCF 405.

[0108] At 402, the AMF 403 may receive the Blockchain Redaction Capability Request described above. At 404, if BC-Flag = TRUE, the AMF 403 may select a BCCF 405 (e.g., discover one or multiple BCCFs from an NRF). If the AMF 403 already has a BCCF (e.g., the BCCF that has handled wireless blockchain onboarding process for the WTRU 401) or the previous process included a BCCF-ID, it may not choose a different one. The identifier of the selected BCCF is BCCF-ID. At 406, the AMF 403 may forward the received Blockchain Redaction Capability Request described above to the BCCF 405. The AMF 403 may also inform the BCCF of a PCF 407 and an AUSF 409 that the BCCF 405 needs to contact, respectively, during the FIGS. 4A-4B processes of Retrieve Blockchain Redaction Policies for WTRU 401 , and Request Blockchain Redaction Key (KBCRD). Similar to the process 300 described in FIGS. 3A-3B, the BCCF 405 first may verify the integrity of the blockchain redaction capability request described above using the WTRU’s blockchain public key (WTRU-BC-Public-Key), which is equivalent to Dev-BC-Public-Key in FIGS. 3A-3B. At 408, the BCCF 405 may check ifAuthorized-WTRU-BC-Addr is an authorized address by looking up its local database maintaining one or more (e.g., all) authorized blockchain addresses. If the BCCF 405 does not have such local database or it cannot find Authorized-WTRU-BC-Addr from its local database, it may send Authorized-WTRU-BC-Addr and WTRU-ID to the AUSF 409. The AUSF 409 can authorize Authorized-WTRU-BC-Addr and send a response to the BCCF 405 indicating if Authorized-WTRU-BC-Addr is authorized or rejected. If Authorized-WTRU-BC-Addr is not an authorized address, processes 410-424 and processes 428-430 of FIGS. 4A-4B may not be implemented. In this case, the BCCF 405 may send a rejection as a Blockchain Redaction Capability Response to the WTRU 401 , described below.

[0109] At 410, the BCCF 405 may retrieve blockchain redaction capability policies for the WTRU 401 from a PCF 407. For this purpose, the BCCF 405 may send a request indicating WTRU-ID and / or Native-BC-ID to the PCF 407. Then, the PCF 407 may find blockchain redaction capability policies applicable to WTRU-ID and Native-BC-ID. The PCF 407 may return found blockchain redaction capability policies for the WTRU 401 to the BCCF 405. Similar to the Authorize Blockchain Redaction Capability Request process 308 of FIG. 3A, at 412, the BCCF 405 may authorize the request in two sub-steps. The BCCF 405 may first use WTRU-ID and / or Authorized-WTRU-BC-Addr to check its local policies and / or policies retrieved from the PCF 407 in the process described above (and / or the WTRU’s subscription data) to determine if the WTRU 401 is allowed to request blockchain redaction capability. If the WTRU 401 is allowed to request blockchain redaction capability, the BCCF 405 may check BC-RD- Cap-Req against its local policies and / or policies retrieved previously, described above, to grant blockchain redaction capability to the WTRU 401 (e.g., BC-RD-Cap-Granted). BC-RD-Cap- Granted may include the same set of parameters as BC-RD-Cap-Req, but the value of those parameters in BC-RD-Cap-Granted may not be equal to BC-RD-Cap-Req. For example, BC- RD-Mode in BC-RD-Cap-Req may be “Direct Redaction”, but the granted “BC-RD-Mode” in BC- RD-Cap-Granted may be changed to “Indirect Redaction”. In another example, the AUSF 409 may (re)determine Native-BC-ID-for-RD and include it in BC-RD-Cap-Granted. In another example, the AUSF 409 may (re)determine Native-BC-ID-by-RD and include it in BC-RD-Cap- Granted.

[0110] BC-RD-Cap-Granted may include the Para-for-BC-RD-Enabler, which may indicate parameters to enable blockchain redaction operations. In one example, parameters to enable blockchain redaction operations may include Tran-Format-with-BC-RD-Support, Block- Format-with-BC-RD-Support, and / or Special-Tran-Format-for-BC-RD-OP. Tran-Format-with-BC- RD-Support refers to the transaction format or template for the BC-RD-lssuer to generate aregular transaction (e.g., send a data in the transaction to the native wireless blockchain). In order to support blockchain redaction on transactions, a regular transaction may include additional fields, dependent on the specific blockchain redaction scheme (e.g., Chameleon Hash (CH)). If using CH-based blockchain redaction scheme, the parameters (a, b) in CH may be such additional fields to be included in a transaction header. Block-Format-with-BC-RD- Support refers to the block format or template for the BC-RD-lssuer to generate a regular block. In order to support blockchain redaction on blocks, a block may include additional fields, dependent on the specific blockchain redaction scheme (e.g., Chameleon Hash (CH)). If using CH-based blockchain redaction schemes, the parameters (a, b) in CH may be such additional fields to be included in a block header. If the BC-RD-lssuer is a BCN or a BCCCF, this parameter may not be needed since a BCN or a BCCCF will not create any block. Special-Tran- Format-for-BC-RD-OP refers to the transaction format or template for including a blockchain redaction operation. In other words, this format defines the transaction used to issue or include a blockchain redaction operation.

[0111] At 414, the BCCF 405 may send a request to the AUSF 409 to get blockchain redaction key KBCRD. If the BCCF 405 does not know the AUSF 409, it may discover an AUSF 409 from the AMF 403 or an NRF. Similar to the Derive Blockchain Redaction Key process 310 of FIG. 3A, at 416, the AUSF 409 may derive KBCRD according to a blockchain redaction key scheme BC-RD-Key-Scheme. The AUSF 409 may also determine BC-RD-Proof-Scheme and generate BC-RD-Proof according to BC-RD-Proof-Scheme. At 418, the AUSF 409 may send a response to the BCCF 405 including KBCRD, BC-RD-Key-Scheme, BC-RD-Proof-Scheme and / or BC-RD-Proof. Similar to the Store KBCRD Privately process 314 of FIG. 3A, at 420, the BCCF 405 may store BC-RD-Proof, BC-RD-Proof-Scheme, BC-RD-Key-Scheme, KBCRD locally and privately. Similar to the Generate a Redaction Capability Provisioning Record process 316 of FIG. 3A, at 422, the BCCF 405 may generate a blockchain redaction capability provisioning record (BC-RD-Cap-Granted-Record), which may include Authorized-Dev-BC-Addr, Native-BC- ID, BC-RD-Proof-Scheme, BC-RD-Key-Scheme, BC-RD-Cap-Granted, and / or KBCRD-PUB. The BCCF 405 may store this record locally and / or store it to the native wireless blockchain. The BCCF 405 may store the generated blockchain redaction capability provisioning record generated previously, at 424, to native wireless blockchain via the BCSF and / or to UDR. The BCCF 405 may also send this record to the BCSF 411, which the WTRU 401 will send blockchain redaction operations to. At 426, the BCCF 405 may send a blockchain redaction capability response to the WTRU 401 via the AMF 403. This response may include BC-RD- Proof-Scheme and BC-RD-Proof, BC-RD-Key-Scheme and BC-RD-Cap-Granted; alternatively,this response may include a URL of the stored BC-RD-Cap-Granted (BC-RD-Cap-Granted- URL).

[0112] The WTRU 401 may receive the response described above. At 428, the WTRU 401 may derive KBCRD according to BC-RD-Key-Scheme, which should be equal to KBCRD derived by the AUSF 409, described previously. The WTRU 401 may store KBCRD locally and privately. The WTRU 401 may derive BC-RD-Proof according to BC-RD-Proof-Scheme and store BC-RD-Proof locally and privately. At 430, the WTRU 401 may store BC-RD-Cap-Granted locally. If the blockchain redaction capability response described above includes BC-RD-Cap- Granted-URL, the WTRU 401 may retrieve BC-RD-Cap-Granted from this URL. After this process, the WTRU 401 and the BCSF 411 may continue to use similar processes as previously described and illustrated in FIGS. 3A-3B to issue and execute a blockchain redaction request. As an alternative, the BCCF 405 may be implemented as a part of the AMF 403; thus, one or more (e.g., all) operations in FIGS. 4A-4B done by the BCCF 405 may be performed by AMF 403. Also, the BCCF 405 may be implemented as a part of AUSF 409. Thus, one or more (e.g., all) operations in FIGS. 4A-4B done by the BCCF 405 may be performed by AUSF 409.

[0113] Logical entities may include the LAF, BCRF, and BCEF. The logical entities introduced and described above and present in FIGS. 3A-3B may include Device 301 , BCCF 303, BCGF 305, and BCSF 307. The embodiments described above and illustrated by FIGS. 3A-3B may be implemented differently, as described herein. For example, the BCCF of FIGS. 3A-3B may be implemented as an LAF. The BCGF 305 of FIGS. 3A-3B may be implemented as a BCRF. Alternatively, BCGF 305 may be implemented as another network function. The Device of FIGS. 3A-3B may be implemented as a BCEF within the WTRU 401. The BCSF of FIGS. 3A-3B may be implemented as BCEF with a full blockchain node.

[0114] Alternatively, the proposed embodiments described by FIGS. 3A-3B may be implemented in another manner, as described herein. For example, the BCCF of FIGS. 3A-3B may be implemented as distributed LAF. BCGF 305 of FIGS. 3A-3B may be implemented as a centralized LAF. Alternatively, the BCGF 305 may be defined as another network function. The Device of FIGS. 3A-3B may be implemented as a BCEF within the WTRU 401. BCSF of FIGS. 3A-3B may be implemented as a BCEF with a full blockchain node.

[0115] A BCAF (e.g., a management function) may request a native wireless blockchain to grant blockchain redaction capability to one or multiple devices. As a result, those devices may be able to modify blockchain ledgers (e.g., to modify committed transactions with them as the sender or the recipient).

[0116] FIGS. 5A-5B illustrates a procedure 500 for a BCAF 507 (e.g., a management function) to request blockchain redaction capability for one or multiple designated devices. First, the BCAF 507 may send a request to a BCCF 503 indicating a set of devices and the requirements for granting blockchain redaction capability for those devices. Then, the BCCF 503 may authorize the BCAF’s request with help from a BCGF 505 and grant blockchain redaction capability for those devices, which may be the same or different than what the BCAF 507 requested. Finally, the BCCF 503 may send the granted blockchain redaction capability to each designated device. The BCCF 503 also may generate a blockchain redaction capability provisioning record. As a result, those designated devices will be able to modify / remove committed blocks or transactions stored in blockchain ledgers.

[0117] The proposed procedure 500 in FIGS. 5A-5B may comprise the following operations. Assume the Device 501 has its blockchain address authorized by the network or the Device 501 has received an authorized blockchain address from the network. The Device 501 may have received the address or the identifier of the BCCF 503 from network (BCCF-ID) and pre-configured with BCCF-ID. In this procedure 500, the Device 501 may be a BCSF that may have created and stored blocks / transactions to blockchain ledgers in the native wireless blockchain as denoted by Native-BC-ID. Then the BCSF in FIGS. 5A-5B may be the neighboring BCSF of the Device 501, which means the Device 501 can send any blocks created by the Device 501 to the BCSF in FIG. 5.

[0118] Similar to the initial operation 302 described in FIG. 3A, assume the BCAF 507 has obtained the contact information of a BCCF. At 502, BCAF 507 may send a blockchain redaction capability provisioning request to the BCCF 503, which may include the BCAF-ID, BCAF-Credential, Native-BC-ID, Dev-ID, Dev-BC-Addr, and / or BC-RD-Cap-Req. BCAF-ID may refer to the identifier of the BCAF 507. If the BCAF 507 has an authorized blockchain address, BCAF-ID may include this authorized blockchain address. BCAF-Credential may refer to the credential of the BCAF 507, which may be utilized by the BCGF 505 to authorize if the BCAF 507 is allowed to request blockchain redaction capability for the Device 501 as denoted by Dev- ID and / or Dev-BC-Addr. Native-BC-ID may refer to the identifier of the target native wireless blockchain which blockchain ledgers could be redacted and which devices as denoted by Dev- ID have been onboarded to. Dev-ID may refer to the identifier of the Device 501 that may be provisioned with blockchain redaction capability. Dev-BC-Addr may refer to the blockchain address of the Device 501 that may be provisioned with blockchain redaction capability. Dev- BC-Addr may be an authorized blockchain address. BC-RD-Cap-Req is similar to that describedabove and in FIGS. 3A-3B. In this case, BC-RD-lssuer in BC-RD-Cap-Req may be equal to Dev-ID or Dev-BC-Addr.

[0119] Similar to the operation 302 described previously, and illustrated in FIG. 3A, the BCCF 503 of FIGS. 5A-5B may receive the request described above. If the request includes a BCAF’s signature, the BCCF 503 may verify the integrity of the request using the BCAF’s blockchain public key. At 504, the BCCF 503 may check if Authorized-Dev-BC-Addr is an authorized address by looking up its local database maintaining one or more (e.g., all) authorized blockchain addresses. Optionally, if the BCCF 503 does not have such local database or it cannot find Authorized-Dev-BC-Addr from its local database, it may send Authorized-Dev-BC-Addr and Dev-ID to the BCGF 505; the BCGF 505 can verify Authorized- Dev-BC-Addr and send a response to the BCCF 503 indicating if Authorized-Dev-BC-Addr is authorized or rejected.

[0120] Similar to the operation 306 described previously, and illustrated by FIG. 3A, at 506, the blockchain redaction capability provisioning request may be sent from the BCCF 503 to the BCGF 505, which may include Native-BC-ID (or Native-BC-ID-by-RD), Native-BC-ID-for-RD, BCAF-ID, and BCAF-Credential. This request also may include Dev-ID and / or Dev-BC-Addr. Optionally, this request may include BC-RD-Cap-Req.

[0121] At 508, BCGF 505 may authorize whether the BCAF 507 is allowed to request blockchain redaction capability for the Device 501 . For example, the BCGF 505 may first check if BCAF-ID is a valid BCAF based on BCAF-Credential. Then, the BCGF 505 may check BCAF- ID and / or BCAF-Credential against some preconfigured blockchain redaction policies or other policies that the BCGF 505 may retrieve from a PCF to determine if the BCAF 507 as denoted by BCAF-ID is allowed to request blockchain redaction capability for the Device 501 as denoted by Dev-ID and / or Dev-BC-Addr and / or if the Device 501 as denoted by Dev-ID and / or Dev-BC- Addr can be assigned with blockchain redaction capability as denoted by BC-RD-Cap-Req. If either condition fails or is false, the request received from operation 506 may be rejected. If both conditions pass or are true, the request described previously may be approved or authorized. If the request is approved, the BCGF 505 may continue to check BC-RD-Cap-Req against its local policies to grant blockchain redaction capability to the Device 501 (e.g., BC-RD-Cap-Granted). BC-RD-Cap-Granted may include the same set of parameters as BC-RD-Cap-Req, but their values in BC-RD-Cap-Granted may not be equal to BC-RD-Cap-Req. For example, BC-RD- Mode in BC-RD-Cap-Req may be “Direct Redaction”, but the granted “BC-RD-Mode” in BC-RD- Cap-Granted may be “Indirect Redaction”. In another example, the BCGF 505 may(re)determine Native-BC-ID-for-RD and include it in BC-RD-Cap-Granted. In another example, the BCGF 505 may (re)determine Native-BC-ID-by-RD and include it in BC-RD-Cap-Granted.

[0122] BC-RD-Cap-Granted may also include Para-for-BC-RD-Enabler, which may indicate parameters to enable blockchain redaction operations. Parameters to enable blockchain redaction operations may include Tran-Format-with-BC-RD-Support, Block-Format- with-BC-RD-Support, and / or Special-Tran-Format-for-BC-RD-OP. Tran-Format-with-BC-RD- Support may refer to the transaction format or template for the BC-RD-lssuer to generate a regular transaction (e.g., send a data in the transaction to the native wireless blockchain). In order to support blockchain redaction on transactions, a regular transaction may include other fields, dependent on the specific blockchain redaction scheme (e.g., Chameleon Hash (CH)). If using CH-based blockchain redaction scheme, the parameters (a, b) in CH may be such fields to be included in a transaction header. Block-Format-with-BC-RD-Support refers to the block format or template for the BC-RD-lssuer to generate a regular block. In order to support blockchain redaction on blocks, a block may include other fields, dependent on the specific blockchain redaction scheme (e.g., Chameleon Hash (CH)). If using CH-based blockchain redaction schemes, the parameters (a, b) in CH may be such fields to be included in a block header. If the BC-RD-lssuer is a BCN or a BCCCF, this parameter may not be implemented since a BCN or a BCCCF will not create any block. Special-Tran-Format-for-BC-RD-OP may refer to the transaction format or template for including a blockchain redaction operation. In other word, this format defines the transaction used to issue or include a blockchain redaction operation.

[0123] The Derive Blockchain Redaction Key (KBCRD) operation 510 is similar to the previously described and illustrated Derive Blockchain Redaction Key (KBCRD) operation 310 of FIG. 3A. The Blockchain Redaction Capability Response 512 operation is similar to the previously described and illustrated Blockchain Redaction Capability Response operation 312 of FIG. 3A. After the Blockchain Redaction Capability Response operation 512, the BCCF 503 may send BC-RD-Cap-Granted to the BCAF 507. The BCAF 507 may approve or reject BC- RD-Cap-Granted. For example, the BCAF 507 may reject BC-RD-Cap-Granted if it is different than what was requested previously. Then, the BCAF 507 may send a response indicating acceptance or rejection of BC-RD-Cap-Granted to the BCCF 503. If the response from the BCAF 507 is rejection, the operations described below may be skipped.

[0124] The Store KBCRD Privately operation 514 is similar to the previously described and illustrated Store KBCRD Privately operation 314 of FIG. 3A. At 516, the BCCF 503 may send a blockchain redaction capability notification to the Device 501. This notification may includeBCAF-ID (from operation 502 of FIG. 5A), Dev-ID and / or Dev-BC-Addr (from operation 502), BC-RD-Key-Scheme (from operation 512 of FIG. 5A), BC-RD-Cap-Granted (from operation 512), BC-RD-Proof-Scheme (from operation 512), and / or BC-RD-Proof (from operation 512).

[0125] At 518, Device 501 may decide whether it accepts the granted blockchain redaction capability as denoted by BC-RD-Cap-Granted. For example, if BCAF-ID is an unknow BCAF 507, the Device 501 may reject BC-RD-Cap-Granted. As such, operations 520-522 may be skipped. If BCAF-ID is a known BCAF (e.g., a BCAF being configured at the Device 501), the Device 501 may accept BC-RD-Cap-Granted. The Derive KBCRD and Store BC-RD-Cap- Granted operations 520 and 522 are similar to the previously described Derive KBCRD and Store BC-RD-Cap-Granted operations 322 and 324 of FIG. 3B. At 524, the Device 501 may send a confirmation to the BCCF 503 indicating if the Device 501 accepts or rejects BC-RD- Cap-Granted as decided in operation 518. The confirmation may also include Dev-ID (or Dev- BC-Addr) and / or BCAF-ID.

[0126] The BCCF 503 may receive the confirmation described above. At 526, if the Device 501 has accepted the granted blockchain redaction capability, the BCCF 503 may generate a blockchain redaction capability provisioning record, which may include BCAF-ID, Native-BC-ID, Native-BC-ID-for-RD, Dev-BC-Addr, BC-RD-Key-Scheme, BC-RD-Proof- Scheme, and / or BC-RD-Cap-Granted. The BCCF 503 may store this record locally and / or store it to native wireless blockchain. The BCCF 503 may send this record to the BCSF, which the Device 501 will issue blockchain redaction operations to. Then the BCSF may create an additional transaction including the received blockchain redaction capability provisioning record and send this additional transaction to the native wireless blockchain, so that one or more (e.g., all) other BCSFs will receive this blockchain redaction capability provisioning record and can use it to authorize and approve future blockchain redaction operations from other parties.

[0127] At 528, the BCCF 503 may send a response to the BCAF. This response may include the blockchain redaction capability provisioning record generated in the operation described above. If the Device 501 has rejected the granted blockchain redaction capability in operation 518, this response may indicate “Rejection from Dev-ID / Dev-BC-Addr”. If the BCGF 505 has rejected the blockchain redaction capability request in operation 508, this response may indicate “BCAF is not authorized” and / or “BC-RD-Cap-Req is not approved”.

[0128] Using the procedure 500 in FIGS. 5A-5B, the BCAF can request the BCCF 503 to provision blockchain redaction capability to multiple devices. In this case, the request in operation 502 will include multiple Dev-ID and / or multiple Dev-BC-Addr. For each device, this operation 502 may include a different BC-RD-Cap-Req; the BCAF can also use the same BC-RD-Cap-Req for multiple devices. Then, operation 504 may be repeated for each device. Operations 506, 508 and 512 could be executed once for one or more (e.g., all) devices but the BCGF 505 may repeat operation 510 multiple times - one time for each device. Also, operations 514-524 of FIGS. 5A-5B may be executed for each device.

[0129] Blockchain Redaction Capability Provisioning may be requested by an AF. A WTRU may receive a first response from a first network function (e.g., AMF). The first response may have been generated by a second network function (e.g., BCCF). The first response may include a blockchain redaction key generation scheme (BC-RD-Key-Scheme), a granted blockchain redaction capability (BC-RD-Cap-Granted), and / or an identifier of a first application function (AF-ID) that initiated the second network function to generate the BC-RD-Cap-Granted for the first node WTRU. The WTRU may determine to accept granted blockchain redaction capability (BC-RD-Cap-Granted). The WTRU may derive a blockchain redaction key according to the blockchain redaction key generation scheme. The WTRU may store the blockchain redaction key. The WTRU may store the granted blockchain redaction capability. The WTRU may send a first confirmation message to the second network function via the first network function. The first confirmation message may include the identifier of the first node and / or the blockchain address of the first node.

[0130] An embodiment of the process 500 described above and illustrated by FIGS. 5A- 5B is illustrated in FIGS. 6A-6B. In such a (e.g., 3GPP) embodiment, Device 501 of FIGS. 5A- 5B may be implemented as a part of (e.g., 3GPP) WTRU, BCAF of FIGS. 5A-5B may be implemented as 3GPP AF, and BCCF 503 of FIGS. 5A-5B may be implemented as a network function (e.g., 3GPP network function). Alternatively, BCCF may be implemented as a part of AMF (e.g., 3GPP AMF). BCGF 505 of FIGS. 5A-5B may be implemented as a part of AUSF (e.g., 3GPP AUSF) or an NF (e.g., 3GPP NF). But some BCGF 505 functions of FIGS. 5A-5B may be incorporated to BCCF 605 in the embodiment illustrated by FIGS. 6A-6B. The procedure 600 in FIGS. 6A-6B may comprise the following operations, where the AF 613 could be replaced with a NF.

[0131] Similar to operation 502 of FIG. 5A, at 602, the AF 613 may send a blockchain redaction capability provisioning request to the BCCF 605. The AF 613 may have obtained the BCCF 605 from an NRF. If the AF 613 is not a 3GPP-domain entity, this request may first be sent to an NEF, which will forward the request to the BCCF 605. This request may include an AF-ID, AF-Credential, Native-BC-ID, WTRU-ID, WTRU-BC-Addr, and / or BC-RD-Cap-Req. AF- ID may refer to the identifier of the AF 613. It may be equivalent to BCAF-ID in operation 502 of FIG. 5A. AF-Credential refers to the credential of the AF 613, which may be utilized by theNEF / AUSF to authorize if the AF 613 is allowed to request blockchain redaction capability for the WTRU 601 as denoted by WTRU-ID and / or WTRU-BC-Addr. Native-BC-ID may refer to the identifier of the target native wireless blockchain which blockchain ledgers could be redacted and which the WTRU 601 as denoted by Dev-ID have been onboarded to. WTRU-ID may refer to the identifier of WTRU 601. It is similar to Dev-ID in operation 502 of FIG. 5A. WTRU-ID may be Generic Public Subscription Identifier (GPSI). WTRU-BC-Addr may refer to the blockchain address of the WTRU 601 . WTRU-BC-Addr may be similar to Dev-BC-Addr in operation 502 of FIG. 5A. WTRU-BC-Addr may be an authorized blockchain address. BC-RD-Cap-Req may refer to the same as BC-RD-Cap-Req in operation 502 of FIG. 5A.

[0132] Similar to the previously described operation 504 of FIG. 5A, at 604, the BCCF 605 may check if WTRU-BC-Addr is an authorized address by looking up its local database maintaining one or more (e.g., all) authorized blockchain addresses. Optionally, if the BCCF 605 does not have such local database or it cannot find WTRU-BC-Addr from its local database, it may send Native-BC-ID, WTRU-BC-Addr and WTRU-ID to the AUSF 609; the AUSF 609 can authorize WTRU-BC-Addr and may send a response to the BCCF 605 indicating if WTRU-BC- Addr is authorized or rejected.

[0133] If WTRU-BC-Addr is not an authorized address, some of the operations and processes described below may not be needed; instead, the BCCF 605 may send a rejection in the operation 632 to the AF 613 indicating “Unauthorized WTRU Blockchain Address”.

[0134] At 606, the BCCF 605 may retrieve blockchain redaction capability policies for the WTRU 601 and the AF 613 from a PCF 607. For this purpose, the BCCF 605 may first send a request indicating Native-BC-ID, WTRU-ID and / or AF-ID to the PCF 607. The PCF 607 may find blockchain redaction capability policies applicable to WTRU-ID and / or AF-ID. The PCF 607 may return found blockchain redaction capability policies to the BCCF 605.

[0135] Operation 608 is similar to operation 508 of FIG. 5A. The BCCF 605 may authorize the request in one or more sub-steps. The BCCF 605 first may use AF-ID to check its local policies and / or policies retrieved from the PCF 607 in operation 606 to determine if the AF 613 is allowed to request blockchain redaction capability for the WTRU 601. Then, the BCCF 605 may use WTRU-ID and / or WTRU-BC-Addr to check its local policies and / or policies retrieved from the PCF 607 in operation 606 (or the WTRU’s subscription data) to determine if the WTRU 601 is allowed to be granted with blockchain redaction capability for the native wireless blockchain as denoted by Native-BC-ID. If both of the above processes pass, the BCCF 605 may check BC-RD-Cap-Req against its local policies and / or policies retrieved from the PCF 607 in operation 606 to grant blockchain redaction capability to the WTRU 601 (e.g.,BC-RD-Cap-Granted). BC-RD-Cap-Granted may include the same set of parameters as BC- RD-Cap-Req does, but their values in BC-RD-Cap-Granted may not be equal to BC-RD-Cap- Req. For example, BC-RD-Mode in BC-RD-Cap-Req may be “Direct Redaction”, but the granted “BC-RD-Mode” in BC-RD-Cap-Granted may be changed to “Indirect Redaction”. In another example, the BCCF 605 may (re)determine Native-BC-ID-for-RD and include it in BC-RD-Cap- Granted. In another example, the BCCF 605 may (re)determine Native-BC-ID-by-RD and include it in BC-RD-Cap-Granted.

[0136] BC-RD-Cap-Granted may also include the parameters Para-for-BC-RD-Enabler. Para-for-BC-RD-Enabler may indicate necessary parameters to enable blockchain redaction operations such as Tran-Format-with-BC-RD-Support, Block-Format-with-BC-RD-Support and / or Special-Tran-Format-for-BC-RD-OP. Tran-Format-with-BC-RD-Support may refer to the transaction format or template for the BC-RD-lssuer to generate a regular transaction (e.g., send a data in the transaction to the native wireless blockchain). In order to support blockchain redaction on transactions, a regular transaction may include some other fields, dependent on the specific blockchain redaction scheme (e.g., Chameleon Hash (CH)). If using CH-based blockchain redaction scheme, the parameters (a, b) in CH may be such other fields to be included in a transaction header. Block-Format-with-BC-RD-Support refers to the block format or template for the BC-RD-lssuer to generate a regular block. In order to support blockchain redaction on blocks, a block may include some other fields, dependent on the specific blockchain redaction scheme (e.g., Chameleon Hash (CH)). If using CH-based blockchain redaction schemes, the parameters (a, b) in CH may be such other fields to be included in a block header. If the BC-RD-lssuer is a BCN or a BCCCF, this parameter may not be needed since a BCN or a BCCCF will not create any block. Special-Tran-Format-for-BC-RD-OP refers to the transaction format or template for including a blockchain redaction operation. In other word, this format may define the transaction used to issue or include a blockchain redaction operation.

[0137] At 610, the BCCF 605 may send a request to the AUSF to get blockchain redaction key KBCRD- If the BCCF 605 does not know the AUSF, it may discover an AUSF from the AMF 603 or an NRF given WTRU-ID or a transformed WTRU-ID (e.g., transformed from GPSI to SUPI if WTRU-ID in operation 602 is a GPSI). Operation 612 is similar to operation 510 of FIG. 5A. The AUSF may derive KBCRD according to a blockchain redaction key scheme BC- RD-Key-Scheme. The AUSF may also determine BC-RD-Proof-Scheme and generate BC-RD- Proof according to BC-RD-Proof-Scheme.

[0138] At 614, the AUSF may send a response to the BCCF 605 including KBCRD, BC- RD-Key-Scheme, BC-RD-Proof-Scheme, and / or BC-RD-Proof. Operation 616 is similar to operation 514 of FIG. 5A. Operation 618 is similar to operation 516 of FIG. 5A. The BCCF 605 may send a blockchain redaction capability notification to the WTRU 601 via the AMF 603. This notification may include AF-ID, Native-BC-ID, WTRU-ID or WTRU-BC-Addr, BC-RD-Key- Scheme, BC-RD-Proof-Scheme and / or BC-RD-Proof, and BC-RD-Cap-Granted.

[0139] Operation 620 is similar to operation 518 of FIG. 5B. Operation 622 is similar to operation 520 of FIG. 5B. Operation 624 is similar to operation 522 of FIG. 5B. Operation 626 is similar to operation 524 of FIG. 5B. The confirmation may be sent from the WTRU 601 to the BCCF 605 via the AMF 603, which may include WTRU-ID (or WTRU-BC-Addr), Native-BC-ID, and / or AF-ID. Operation 628 is similar to operation 526 of FIG. 5B. The BCCF 605 may receive the confirmation from operation 626. If the WTRU 601 has accepted the granted blockchain redaction capability in operation 620, the BCCF 605 may generate a blockchain redaction capability provisioning record, which may include AF-ID, Native-BC-ID, WTRU-ID, WTRU-BC- Addr, BC-RD-Key-Scheme, BC-RD-Proof-Scheme, and / or BC-RD-Cap-Granted. The BCCF 605 may store this record locally.

[0140] At 630, the BCCF 605 may send the generated blockchain redaction capability provisioning record to UDR or native wireless blockchain. The BCCF 605 may send this record to a BCSF 611 , which the WTRU 601 will issue blockchain redaction operations to. Operation 632 is similar to operation 528 of FIG. 5B. This response sent from the BCCF 605 to the AF 613 may include the blockchain redaction capability provisioning record generated in operation 628. This response may be relayed by an NEF when the AF 613 is a 3GPP-domain entity.

[0141] The logical entities described herein may include LAF, BCRF, and BCEF. The logical entities introduced above in describing FIGS. 5A-5B may include Device 501 , BCCF 503, BCGF 505, and BCAF 507. The proposed embodiments described above in describing FIGS. 5A-5B may be implemented as described herein. For example, the BCCF as described above and illustrated in FIGS. 5A-5B may be implemented as an LAF. BCAF as described above and illustrated in FIGS. 5A-5B may be implemented as another entity Blockchain Application Function (BCAF). BCGF as described above and illustrated in FIGS. 5A-5B may be implemented as a BCRF. Alternatively, BCGF may be defined as another network function. Device 501 as described above and illustrated in FIGS. 5A-5B may be implemented as BCEF within the WTRU 601 .

[0142] In an alternative example, the proposed embodiments described above and illustrated by FIGS. 5A-5B may be implemented as described herein. For example, BCCF in asdescribed above and illustrated in FIGS. 5A-5B may be implemented as distributed LAF. BCAF in as described above and illustrated in FIGS. 5A-5B may be implemented as another entity Blockchain Application Function (BCAF). BCGF in as described above and illustrated in FIGS. 5A-5B may be implemented as centralized LAF. Alternatively, BCGF may be defined as a another network function. Device 501 in as described above and illustrated in FIGS. 5A-5B may be implemented as BCEF within WTRU 601.

[0143] A device may initiate to request a native wireless blockchain (e.g., a BCCF) to grant blockchain redaction capability to a network function, so that the network function may be able to modify blockchain ledgers (e.g., to modify any committed transactions with the device as the sender or the recipient). A device may send a request for provisioning blockchain redaction capability to a Blockchain Redaction Function (BCRDF) or multiple instances of BCRDF, which could be implemented as a part of a 3GPP NF (or a part of a BCSF). First, the Device may send a request to a BCCF indicating its requirements on blockchain redaction capability. Then, the BCCF may authorize the request with help from a BCGF and grant blockchain redaction capability, which may be the same or different than what the Device requested. The BCCF may send the granted blockchain redaction capability to the BCRDF. The BCCF also may generate a blockchain redaction capability provisioning record. As a result, the BCRDF may be able to perform blockchain redaction operations on behalf of the Device.

[0144] FIGS. 7A-7B illustrates Provisioning Blockchain Redaction Capability to a Network Function Assisted by BCGF 705. The procedure 700 described in FIGS. 7A-7B may include the operations described below. The embodiments described with reference to procedure 700 may assume the Device 701 has its blockchain address authorized by the network and / or the Device 701 has received an authorized blockchain address from the network. The Device 701 may have received the address or the identifier of the BCCF 703 from network (BCCF-ID) and pre-configured with BCCF-ID.

[0145] The Device 701 may have an identifier (e.g., Dev-ID) and / or an authorized blockchain address (e.g., Authorized-Dev-BC-Addr). At 702, the Device 701 may send a blockchain redaction capability provisioning request to the BCCF 703 assuming the Device 701 has obtained or has been configured with the BCCF 703. The purpose of this request may be for the Device 701 to request blockchain redaction capability (e.g., the capability of modifying committed transactions with the Device 701 as the sender) to be provisioned to the BCRDF 707. This request may include Native-BC-ID (or Native-BC-ID-by-RD). This request may include Dev-ID, Authorized-Dev-BC-Addr, and requested blockchain redaction capability (e.g., BC-RD- Cap-Req). BC-RD-Cap-Req may include the following parameters: BC-RD-Delegator, BC-RD-Issuer, BC-RD-Mode, BC-RD-Scope, and / or Native-BC-ID-for-RD. BC-RD-Delegator may indicate the identifier of the party that issues the request in operation 702. For this case, BC- RD-Delegator is equal to Dev-ID and / or Authorized-Dev-BC-Addr. BC-RD-lssuer may indicate the identifier of the blockchain redaction issuer that can issue blockchain redaction operations. For the case in FIGS. 7A-7B, BC-RD-lssuer is the identifier of the BCRDF 707 (e.g., BCRDF- ID), which could indicate multiple BCRDFs. If BC-RD-lssuer is none or empty, the BCCF 703 or the BCGF 705 may select one BCRDF 707 or multiple BCRDFs for the Device 701. BC-RD- Mode may indicate the blockchain redaction mode, which may be a direct redaction or an indirect redaction. For a direct redaction, the blockchain redaction issuer can perform blockchain redaction operation directly through a BCSF. for an indirect redaction, each blockchain redaction operation from the blockchain redaction issuer needs to be authorized first by the BCCF 703. Then, the BCCF 703 may send authorized blockchain redaction operations to native wireless blockchain on behalf of the blockchain redaction issuer. BC-RD-Scope may indicate the scope of blockchain redaction, which may be transactions issued from one or more than one blockchain addresses; transactions with one or more than one blockchain addresses as recipients; transactions with a pair of blockchain addresses as the sender and the recipient; committed blocks; and / or committed blocks including transactions from a set of specific blockchain addresses. For example, if BC-RD-Scope = “Dev-ID as the Sender”, it indicates that the Device 701 requests blockchain redaction capability for committed transactions with itself as the sender. Native-BC-ID-for-RD refers to the identifier of a native wireless blockchain which may be used to store the history of blockchain redaction operations. Native-BC-ID-for-RD may be equal to Native-BC-ID. This parameter may be optional in operation 702 but may be determined by the BCGF 705 in operation 708.

[0146] The BCCF 703 may receive the request from operation 702. At 704, the BCCF 703 may check if Authorized-Dev-BC-Addr is an authorized address by looking up its local database maintaining one or more (e.g., all) authorized blockchain addresses. Optionally, if the BCCF 703 does not have such local database or it cannot find Authorized-Dev-BC-Addr from its local database, it may send Authorized-Dev-BC-Addr and / or Dev-ID to the BCGF 705. The BCGF 705 may authorize Authorized-Dev-BC-Addr and send a response to the BCCF 703 indicating if Authorized-Dev-BC-Addr is authorized or rejected. If Authorized-Dev-BC-Addr is not an authorized address, some of the operations described below (e.g. operations 706-726) may not be implemented. Instead, the BCCF 703 may send a rejection in operation 728 to the Device 701.

[0147] At 706, the BCCF 703 may forward the blockchain redaction capability request received from operation 702 to the BCGF 705. The BCGF 705 may receive the request from operation 706. At 708, the BCGF 705 may authorize the request in sub-steps. For example, the BCGF 705 may use Dev-ID and / or Authorized-Dev-BC-Addr to check its local policies (or the Device’s subscription data and / or policies from core network) to determine if the Device 701 is allowed to request and delegate blockchain redaction capability to the BCRDF 707. If the request includes BCRDF-ID (e.g., in BC-RD-lsser), the BCGF 705 may check BCRDF-ID against its local policies to determine if the BCRDF 707 is allowed to perform blockchain redaction operations on behalf of the Device 701. If the BCRDF 707 is not allowed or if the BCRDF 707 was not included in the request, the BCGF 705 may select a BCRDF 707 for the Device 701. If both of the above processes pass, the BCGF 705 may check BC-RD-Cap-Req against its local policies to grant blockchain redaction capability (e.g., BC-RD-Cap-Granted) to be provisioned to the BCRDF 707. BC-RD-Cap-Granted may include the same set of parameters as BC-RD-Cap-Req does, but their values in BC-RD-Cap-Granted may not be equal to BC-RD-Cap-Req. For example, BC-RD-Mode in BC-RD-Cap-Req may be “Direct Redaction”, but the granted “BC-RD-Mode” in BC-RD-Cap-Granted may be changed to “Indirect Redaction”. In another example, the BCGF 705 may (re)determine Native-BC-ID-for-RD and include it in BC-RD-Cap-Granted. In another example, the BCGF 705 may (re)determine Native-BC-ID-by- RD and include it in BC-RD-Cap-Granted. BC-RD-Cap-Granted may also include Para-for-BC- RD-Enabler, which may indicate parameters to enable blockchain redaction operations. Parameters to enable blockchain redaction operations may include Tran-Format-with-BC-RD- Support, and / or Block-Format-with-BC-RD-Support. Tran-Format-with-BC-RD-Support refers to the transaction format or template for the BC-RD-lssuer to generate a regular transaction (e.g., send a data in the transaction to the native wireless blockchain). In order to support blockchain redaction on transactions, a regular transaction may include some other fields, dependent on the specific blockchain redaction scheme (e.g., Chameleon Hash (CH)). If using CH-based blockchain redaction scheme, the parameters (a, b) in CH may be such other fields to be included in a transaction header. Block-Format-with-BC-RD-Support refers to the block format or template for the BC-RD-lssuer to generate a regular block. In order to support blockchain redaction on blocks, a block may include some other fields, dependent on the specific blockchain redaction scheme (e.g., Chameleon Hash (CH)). If using CH-based blockchain redaction schemes, the parameters (a, b) in CH may be such other fields to be included in a block header. If the BC-RD-lssuer is a BCN or a BCCCF, this parameter may not be needed since a BCN or a BCCCF will not create any block. Special-Tran-Format-for-BC-RD-OP refersto the transaction format or template for including a blockchain redaction operation. In other word, this format defines the transaction used to issue or include a blockchain redaction operation.

[0148] At 710, the BCGF 705 may derive a blockchain redaction key (KBCRD) using a blockchain redaction key generation scheme BC-RD-Key-Scheme. The BCGF 705 may derive a blockchain redaction proof (BC-RD-Proof) using a blockchain redaction proof generation scheme BC-RD-Proof-Scheme. Any logical entity or node with access to KBCRD may be able to issue blockchain redaction operations as specified by BC-RD-Cap-Granted, similar to operations 326-334 of FIG. 3B. Therefore, KBCRD may be kept privately and the BCGF 705 may only share it with the BCCF 703 and / or the BCRDF 707.

[0149] At 712, the BCGF 705 may send a blockchain redaction capability provisioning response to the BCCF 703. This response may include Authorized-Dev-BC-Addr, Native-BC-ID, BCRDF-ID (the identifier of the selected BCRDF 707 in operation 708 if any), BC-RD-Cap- Granted, BC-RD-Proof, BC-RD-Proof-Scheme, BC-RD-Key-Scheme, and KBCRD.

[0150] At 714, the BCCF 703 may store BC-RD-Key-Scheme and KBCRD privately. The BCCF 703 may store BC-RD-Proof and BC-RD-Proof-Scheme locally. If there are multiple BCRDFs (e.g., indicated in operation 702 or selected by the BCCF 703 or selected by the BCGF 705), operations 716-724 may be repeated for each BCRDF.

[0151] At 716, the BCCF 703 may send a blockchain redaction capability provisioning notification to the BCRDF 707 This notification may include Authorized-Dev-BC-Addr, Dev-ID, BCCF-ID, Native-BC-ID, BC-RD-Cap-Granted, BC-RD-Key-Scheme, and BC-RD-Proof-Scheme and / or BC-RD-Proof. Alternatively, this notification may include Authorized-Dev-BC-Addr, Dev- ID, BCCF-ID, Native-BC-ID, BC-RD-Cap-Granted, KBCRD, and BC-RD-Proof-Scheme and / or BC-RD-Proof.

[0152] The BCRDF 707 may receive the notification described above, from operation 716. At 718, the BCRDF 707 may authorize this notification. For example, the BCRDF 707 may use Authorized-Dev-BC-Addr to check its local policies (or other policies that the BCRDF 707 may retrieve from network functions such as a PCF) and determine if it is willing to perform blockchain redaction operations as specified in BC-RD-Cap-Granted for the Device 701. If the BCRDF 707 determines not to accept the blockchain redaction provisioning or delegation from the Device 701 , operations 720-722 may be skipped; instead, the BCRDF 707 may simply send “Redaction Notification Rejection” in operation 724.

[0153] At 720, if KBCRD was not included in the notification from operation 716, the BCRDF 707 may use BC-RD-Key-Scheme to derive KBCRD, which should be the same as that the BCGF 705 derived in operation 710. The BCRDF 707 may store KBCRD privately.

[0154] At 722, the BCRDF 707 may store BC-RD-Cap-Granted. At 724, the BCRDF 707 may send a confirmation to the BCCF 703 indicating if it accepted or rejected the notification from operation 716. At 726, the BCCF 703 may generate a blockchain redaction capability provisioning record, which may include Authorized-Dev-BC-Addr, Dev-ID, Native-BC-ID, BC- RD-Key-Scheme, BC-RD-Proof-Scheme, BCRDF-ID of each BCRDF, and / or BC-RD-Cap- Granted for each BCRDF. The BCCF 703 may store this record locally. In another example, the BCCF 703 may store this record to the native wireless blockchain; for this purpose, the BCCF 703 may send this record to a BCSF. Then, the BCSF may create a transaction including this record and send this transaction to the native wireless blockchain so that other BCSFs will receive this record and can use it to authorize and approve future blockchain redaction operations from other parties. The BCCF 703 may send this record to the BCSF that the BCRDF 707 will send blockchain redaction operations to. At 728, the BCCF 703 may send a response to the Device 701. This response may indicate “Rejection”. Otherwise, this response may include BCRDF-ID and / or other parameters included in the generated blockchain redaction capability provisioning record.

[0155] FIGS. 8A-8B illustrates another procedure 800 for provisioning blockchain redaction capability to a BCRDF 807 initiated by a Device 801, but controlled by a BCCF and a BCGF 805. After this procedure 800, the BCRDF 807 may be able to modify / remove committed transactions with the Device 801 as the sender and / or the recipient, on behalf of the Device 801. FIGS. 8A-8B illustrates a process 800 of Provisioning Blockchain Redaction Capability to a Network Function Controlled by BCGF 805. The procedure 800 illustrated in FIGS. 8A-8B may comprise the following operations described herein.

[0156] Operation 802 may be similar to operation 702 of FIG. 7A. Operation 804 may be similar to operation 704 of FIG. 7A. Operation 806 may be similar to operation 706 of FIG. 7A. Operation 808 may be similar to operation 708 of FIG. 7A. Operation 810 may be similar to operation 710 of FIG. 7A.

[0157] At 812, the BCGF 805 may send a blockchain redaction capability provisioning notification to the BCRDF 807 This notification may include Authorized-Dev-BC-Addr, Native- BC-ID (or Native-BC-ID-by-RD), BCCF-ID, BC-RD-Cap-Granted, BC-RD-Proof, BC-RD-Proof- Scheme, and / or BC-RD-Key-Scheme. Alternatively, this notification may include Authorized- Dev-BC-Addr, Native-BC-ID (or Native-BC-ID-by-RD), BCCF-ID, BC-RD-Cap-Granted, BC-RD-Proof, and / or KBCRD. Operation 814 may be similar to operation 718 of FIG. 7B. Operation 816 may be similar to operation 720 of FIG. 7B. Operation 818 may be similar to operation 722 of FIG. 7B. At 820, the BCRDF 807 may send a confirmation to the BCGF 805 indicating if it accepted or rejected the notification received from operation 812.

[0158] At 822, the BCGF 805 may send a response to the BCCF 803 This response may indicate BCRDF-ID, Native-BC-ID (or Native-BC-ID-by-RD), BC-RD-Cap-Granted, BC-RD- Proof, BC-RD-Proof-Scheme, BC-RD-Key-Scheme, and / or KBCRD. Operation 824 may be similar to operation 714 of FIG. 7A. Operation 826 may be similar to operation 726 of FIG. 7B. Operation 828 may be similar to operation 728 of FIG. 7B.

[0159] A 3GPP embodiment for the process 700 described by FIGS. 7A-7B is illustrated in FIGS. 9A-9B and described below. Device 701 as described above and illustrated by FIGS. 7A-7B may be implemented as a part of WTRU (e.g., 3GPP WTRU). BCCF 703 as described above and illustrated by FIGS. 7A-7B may be implemented as a 3GPP network function. Alternatively, BCCF 703 may be implemented as a part of AMF (e.g., 3GPP AMF). BCGF as described above and illustrated by FIGS. 7A-7B may be implemented as a part of AUSF (e.g., 3GPP AUSF) or a network function (e.g., 3GPP network function). But some BCGF functions described above and illustrated by FIGS. 7A-7B may be incorporated to BCCF in FIGS. 9A-9B. BCRDF as described above and illustrated by FIGS. 7A-7B may be implemented as a network function (e.g., 3GPP network function). BCRDF could also be implemented as a AF (e.g., 3GPP AF).

[0160] Blockchain Redaction Capability may be provisioned to a network function (NF). A WTRU as a first node may prepare a first information element on requested blockchain redaction capability e.g., BC-RD-Cap-Req) indicating the blockchain redaction capability for the first node will be delegated to the first network function (e.g., BCRDF). The WTRU may send a first request to a second network function (e.g., AMF). The first request may include a first identifier of the WTRU, a first blockchain address of the WTRU, the first information element, and / or an identifier of the third network function. The first request may be forwarded from the second network function to the third network function (e.g., BCCF), which will process and forward the first request to a third network function. The WTRU may receive a first response from the second network function. The first response may have been generated by the third network function. The first response may include an identifier of the first network function, a granted blockchain redaction capability (BC-RD-Cap-Granted) to the first network function, and / or a blockchain redaction key generation scheme (BC-RD-Key-Scheme). The WTRU may store the granted blockchain redaction capability.

[0161] FIGS. 9A-9B is a system diagram illustrating Provisioning Blockchain Redaction Capability to a 3GPP Network Function. The procedure 900 in FIGS. 9A-9B may comprise one or more of the following operations and processes. Operation 902 may be similar to operation 702 of FIG. 7A. WTRU 901 has obtained an authorized blockchain address (Authorized-WTRU- BC-Addr), which is equivalent to Authorized-Dev-BC-Addr in FIG. 7A. WTRU-ID could be SUCI or 5G-GUTI of the WTRU 901 , which is equivalent to Dev-ID in FIG. 7A. The request in operation 902 may also include BC-RD-Cap-Req. This request may also include the identifier of the BCCF 905. The request may also include Native-BC-ID (or Native-BC-ID-by-RD). The AMF 903 may receive the request from operation 902. At 904, the AMF 903 may select a BCCF 905 (e.g., discover one or multiple BCCFs from an NRF); if the AMF 903 already has a BCCF (e.g., the same BCCF that has previously onboarded the WTRU 901) or operation 902 includes a BCCF, it may not choose a different one. The identifier of the selected BCCF is BCCF-ID. At 906, the AMF 903 may forward the received request from operation 902 to the BCCF 905. The AMF 903 may also inform the BCCF of a PCF 907 or an AUSF 909 that the BCCF 905 may contact, respectively, in operations 910 and 914.

[0162] Operation 908 may be similar to operation 704 of FIG. 7A. The BCCF 905 first may check if Authorized-WTRU-BC-Addr is an authorized address by looking up its local database maintaining one or more (e.g., all) authorized blockchain addresses. Optionally, if the BCCF 905 does not have such local database or it cannot find Authorized-WTRU-BC-Addr from its local database, it may send Authorized-WTRU-BC-Addr and / or WTRU-ID to the AUSF 909; the AUSF 909 may authorize Authorized-WTRU-BC-Addr and send a response to the BCCF 905 indicating if Authorized-WTRU-BC-Addr is authorized or rejected.

[0163] At 910, the BCCF 905 may retrieve one or more blockchain redaction capability policies for the WTRU 901 from a PCF 907. For this purpose, the BCCF 905 may first send a request indicating WTRU-ID and / or Native-BC-ID to the PCF 907. Then, the PCF 907 may find blockchain redaction capability policies applicable to WTRU-ID and Native-BC-ID; the PCF 907 may return found blockchain redaction capability policies to the BCCF 905.

[0164] Operation 912 may be similar to operation 708 of FIG. 7A. The BCCF 905 may authorize the request in one or more sub-processes. For example, the BCCF 905 may use WTRU-ID and / or WTRU-BC-Addr to check its local policies (or the WTRU’s subscription data and / or policies from core network) to determine if the WTRU 901 is allowed to request and delegate blockchain redaction capability in Native-BC-ID to a BCRDF 911. If the request includes BCRDF-ID, the BCCF 905 may check BCRDF-ID against its local policies to determine if the BCRDF 911 is allowed to perform blockchain redaction operations on behalf of the WTRU901. If the BCRDF 911 is not allowed or if the BCRDF 911 was not included in the request, the BCCF 905 may select a BCRDF 911 for the WTRU 901 . If both previous sub-processes pass, the BCCF 905 may check BC-RD-Cap-Req against its local policies to grant blockchain redaction capability (e.g., BC-RD-Cap-Granted) to be provisioned to the BCRDF 911. BC-RD- Cap-Granted may include the same set of parameters as BC-RD-Cap-Req does, but it may not be equal to BC-RD-Cap-Req. For example, BC-RD-Mode in BC-RD-Cap-Req may be “Direct Redaction”, but the granted “BC-RD-Mode” in BC-RD-Cap-Granted may be “Indirect Redaction”. In another example, the BCCF 905 may (re)determine Native-BC-ID-for-RD and include it in BC-RD-Cap-Granted. In another example, the BCCF 905 may (re)determine Native-BC-ID-by- RD and include it in BC-RD-Cap-Granted.

[0165] BC-RD-Cap-Granted may also include Para-for-BC-RD-Enabler which may indicate necessary parameters to enable blockchain redaction operations. Necessary parameters to enable blockchain redaction operations may include Tran-Format-with-BC-RD- Support, Block-Format-with-BC-RD-Support, and / or Special-Tran-Format-for-BC-RD-OP. Tran- Format-with-BC-RD-Support may refer to the transaction format or template for the BC-RD- Issuer to generate a regular transaction (e.g., send a data in the transaction to the native wireless blockchain). In order to support blockchain redaction on transactions, a regular transaction may include some other fields, dependent on the specific blockchain redaction scheme (e.g., Chameleon Hash (CH)). If using CH-based blockchain redaction scheme, the parameters (a, b) in CH may be such other fields to be included in a transaction header. Block- Format-with-BC-RD-Support refers to the block format or template for the BC-RD-lssuer to generate a regular block. In order to support blockchain redaction on blocks, a block may include some other fields, dependent on the specific blockchain redaction scheme (e.g., Chameleon Hash (CH)). If using CH-based blockchain redaction schemes, the parameters (a, b) in CH may be such other fields to be included in a block header. If the BC-RD-lssuer is a BCN or a BCCCF, this parameter may not be needed since a BCN or a BCCCF will not create any block. Special-Tran-Format-for-BC-RD-OP refers to the transaction format or template for including a blockchain redaction operation. In other word, this format defines the transaction used to issue or include a blockchain redaction operation. At 914, the BCCF 905 may send a request to the AUSF 909 to get blockchain redaction key KBCRD. If the BCCF 905 does not know the AUSF 909, it may discover an AUSF 909 from the AMF 903 or an NRF, given WTRU- ID and / or Native-BC-ID.

[0166] Operation 916 may be similar to operation 710 of FIG. 7A. The AUSF 909 may derive KBCRD according to a blockchain redaction key scheme BC-RD-Key-Scheme. TheAUSF 909 may receive BC-RD-Proof-Scheme from the BCCF 905 or the AUSF 909 determines it for the WTRU 901 by itself; then, the AUSF 909 may derive BC-RD-Proof according to BC- RD-Proof-Scheme. At 918, the AUSF 909 may send a response to the BCCF 905 including KBCRD, BC-RD-Key-Scheme, BC-RD-Proof-Scheme, and / or BC-RD-Scheme. The BCCF 905 may receive the response from operation 918. At 920, the BCCF 905 may store KBCRD, BC- RD-Key-Scheme, BC-RD-Proof, and / or BC-RD-Proof-Scheme privately. Operation 922 may be similar to operation 716 of FIG. 7A. Authorized-WTRU-BC-Address in this process is equivalent to Authorized-Dev-BC-Addr in operation 718 of FIG. 7B. Operation 924 may be similar to operation 718 of FIG. 7B. Operation 926 may be similar to operation 720 of FIG. 7B. Operation 928 may be similar to operation 722 of FIG. 7B. Operation 930 may be similar to operation 724 of FIG. 7B. Operation 932 may be similar to operation 726 of FIG. 7B. Operation 934 may be similar to operation 728 of FIG. 7B. The BCCF 905 may send a response to the WTRU 901 via the AMF 903. This response may indicate “Rejection”. Otherwise, this response may include BCRDF-ID and / or other parameters included in the blockchain redaction capability provisioning record generated in operation 932.

[0167] The logical entities described herein may include LAF, BCRF, and BCEF. The logical entities introduced above and described by FIGS. 7A-7B and FIGS. 8A-8B include Device, BCCF, BCGF, BCSF, and BCRDF. In one example, the proposed embodiments described above and illustrated by FIGS. 7A-7B and FIGS. 8A-8B may be implemented. BCCF as described above and illustrated by FIGS. 7A-7B and FIGS. 8A-8B may be implemented as LAF. BCRDF as described above and illustrated by FIGS. 7A-7B and FIGS. 8A-8B may be implemented as a function (e.g., BCRDF or BCEF) with a full blockchain node. BCGF as described above and illustrated by FIGS. 7A-7B and FIGS. 8A-8B may be implemented as BCRF. Alternatively, BCGF may be implemented as a network function. Device as described above and illustrated by FIGS. 7A-7B and FIGS. 8A-8B may be implemented as BCEF within WTRU 901. BCSF as described above and illustrated by FIGS. 7A-7B and FIGS. 8A-8B may be implemented as BCEF with a full blockchain node.

[0168] In another example, the proposed embodiments described above and illustrated by FIGS. 7A-7B and FIGS. 8A-8B may be implemented as described herein. For example, BCCF as described above and illustrated by FIGS. 7A-7B and FIGS. 8A-8B may be implemented as distributed LAF. BCRDF as described above and illustrated by FIGS. 7A-7B and FIGS. 8A-8B may be implemented as a function BCRDF or BCEF with a full blockchain node. BCGF as described above and illustrated by FIGS. 7A-7B and FIGS. 8A-8B may be implemented as centralized LAF. Alternatively, BCGF may be defined as a network function.The device described above and illustrated by FIGS. 7A-7B and FIGS. 8A-8B may be implemented as BCEF within WTRU. BCSF as described above and illustrated by FIGS. 7A-7B and FIGS. 8A-8B may be implemented as BCEF with a full blockchain node.

[0169] FIG. 10 illustrates an example of procedure 1000 for provisioning blockchain redaction capability to BCEF-A 1001. In other words, with this procedure, BCEF-A 1001 may be able to issue blockchain redaction operations to modify blockchain ledgers (e.g., blocks and / or transactions) of a target native wireless blockchain system, which identifier or name can be denoted as Native-BC-ID. In FIG. 10, a LAF 1003 may have one or more (e.g., all) functions of a BCCF as disclosed herein and each BCEF (e.g., BCEF-A 1001 and BCEF-B 1007) may have one or more (e.g., all) functionalities of a BCSF as disclosed herein. BCGF 1005 may be a BCRF in ETSI-024. BCGF 1005 may also be implemented as a part of the LAF 1003 (e.g., functionalities of BCGF 1005 on this figure are merged to the LAF 1003). The procedure 1000 illustrated in FIG. 10 may comprise the operations described below.

[0170] At 1002, the BCGF 1005 may select BCEF-A 1001 and determine that BCEF-A 1001 can issue blockchain redaction operations to the target native wireless blockchain system. For this purpose, the BCGF 1005 may retrieve necessary BCEF-A’s information from a BCRF (e.g., if the BCRF monitors and maintains the performance of BCEF-A 1001). As an alternative operation to operation 1002 in FIG. 10, BCEF-A 1001 may send a Blockchain Redaction Capability Request (similar to operation 302 in FIG. 3A) to the LAF 1003, which will forward the Blockchain Redaction Capability Request to the BCGF 1005. This request may include the requested blockchain redaction capability (e.g., BC-RD-Cap-Req as described previously and illustrated by FIGS. 3A-3B), the identifier and / or the blockchain address of BCEF-A 1001 , Native-BC-ID (or Native-BC-ID-by-RD) that is the identifier of the target native wireless blockchain which the requested redaction capabilities will be applied to, and / or other parameters as described previously for operation 302 in FIG. 3A and illustrated by FIGS. 3A-3B. According to BC-RD-Cap-Req, the BCGF 1005 may grant blockchain redaction capabilities to BCEF-A 1001 in the following operation 1004.

[0171] At 1004, the BCGF 1005 may grant some blockchain redaction capabilities (BC- RD-Cap-Granted) to BCEF-A 1001. BC-RD-Cap-Granted was described previously and illustrated by FIGS. 3A-3B. For Example, BC-RD-Cap-Granted may specify the BC-RD-lssuer, BC-RD-Mode, Native-BC-ID-by-RD, and / or Native-BC-ID-for-RD. BC-RD-lssuer may indicate the identifier of the blockchain redaction issuer. For this case, BC-RD-lssuer may be set to the identifier of BCEF-A 1001 (BCEF-A-ID). BC-RD-Mode may indicate the blockchain redaction mode. The blockchain redaction mode may be direct redaction or indirect redaction. Directredaction may refer to blockchain redaction issuer can perform or send redaction operations directly to the target native wireless blockchain system via itself or other BCEFs. Indirect redaction may refer to blockchain redaction operation from the blockchain redaction issuer first needs to be send to and be authorized by the LAF 1003. Then, the LAF 1003 may forward the authorized blockchain redaction operation to the target native wireless blockchain on behalf of the blockchain redaction issuer.

[0172] Native-BC-ID-by-RD may refer to the identifier of the target native wireless blockchain where redaction operations will be sent to or which blockchain ledgers will be redacted. Native-BC-ID-by-RD may be equal to Native-BC-ID. BC-RD-Scope may indicate the scope of blockchain redaction (e.g., only certain transactions can be modified, only certain blocks can be modified, etc.). Native-BC-ID-for-RD may refer to the identifier of a native wireless blockchain which may be used to store the history of blockchain redaction operations. Native- BC-ID-for-RD may be equal to Native-BC-ID.

[0173] At 1006, the BCGF 1005 may generate blockchain redaction key material (BC- RD-Key-Materials), for example, to derive a blockchain redaction key (KBCRD) according to a blockchain redaction key scheme (BC-RD-Key-Scheme). BC-RD-Key-Materials may include BC-RD-Key-Scheme, and KBCRD, and BCEF-A-ID. BC-RD-Cap-Granted may be added with a reference or a link to BC-RD-Key-Materials, especially if BC-RD-Key-Materials does not include BCEF-A-ID. BCEF-A 1001 may be able to use the same BC-RD-Key-Scheme to generate the same KBCRD. In this case, a BC-RD-Key-Scheme (e.g., only a BC-RD-Key-Scheme) may be transmitted to the BCEF-A 1001.

[0174] The BCGF 1005 may sign BC-RD-Cap-Granted using its private key. The BCGF 1005 may also sign BC-RD-Key-Materials using its private key. At 1008, the BCGF 1005 may send BC-RD-Cap-Granted and BC-RD-Key-Materials to the LAF 1003. The LAF 1003 may store BC-RD-Cap-Granted and BC-RD-Key-Materials locally. At 1010, the LAF 1003 may send BC- RD-Cap-Granted and BC-RD-Key-Materials to BCEF-A 1001. In this notification in operation 1010, the LAF 1003 may also tell BCEF-A 1001 to publish BC-RD-Cap-Granted to the target native wireless blockchain as denoted by Native-BC-ID-by-RD.

[0175] BCEF-A 1001 may receive the notification from operation 1010. BCEF-A 1001 may first verify the signature included in BC-RD-Cap-Granted and BC-RD-Key-Materials using the BCGF’s public key and store both locally after their signatures are verified. If the notification indicates that BCEF-A 1001 needs to publish BC-RD-Cap-Granted to the target native wireless blockchain as denoted by Native-BC-ID-by-RD. If BC-RD-Key-Materials does not include KBCRD, BCEF-A 1001 may use BC-RD-Key-Scheme included in BC-RD-Key-Materials to derive thesame KBCRD as the BCGF 1005 did in operation 1006. BCEF-A 1001 may create a transaction including BC-RD-Cap-Granted and send the transaction to the target native wireless blockchain. At 1012, BCEF-A 1001 may send a confirmation back to the LAF 1003. At 1014, the LAF 1003 may send BC-RD-Cap-Granted to BCEF-B 1007. BCEF-B 1007 may be a BCEF serving BCEF- A 1001 if BCEF-A 1001 is not a full blockchain node. If BCEF-A 1001 is a full blockchain node, BCEF-B 1007 may be neighboring BCEF of BCEF-A 1001.

[0176] BCEF-B 1007 may create a transaction including BC-RD-Cap-Granted. At 1016, the BCEF-B 1007 may send the transaction to the target native wireless blockchain as denoted by Native-BC-ID-by-RD.

[0177] At 1018, the BCEF-B 1007 may send a confirmation to the LAF 1003. The LAF 1003 may receive the confirmation from BCEF-B 1007. At 1020, the BCEF-B 1007 may send another confirmation to the BCGF 1005.

Claims

CLAIMS:

1. A method performed by a network entity, the method comprising: determining that a wireless transmit receive unit (WTRU) is capable of performing a blockchain redaction operation in a wireless blockchain network associated with a wireless blockchain network identifier; granting the WTRU a blockchain redaction capability for the wireless blockchain network; generating blockchain redaction key material; and transmitting a blockchain redaction capability notification, wherein the blockchain redaction capability notification includes a blockchain redaction capability element indicating that the WTRU is granted with the blockchain redaction capability for the wireless blockchain network, wherein the blockchain redaction capability notification includes an indication of the blockchain redaction key material.

2. The method of claim 1 , wherein the network entity is configured to implement a blockchain governance function (BCGF) associated with a private key.

3. The method of claim 2, further comprising: signing, using the private key of the BCGF, one or more transactions configured to indicate at least one of: (i) the granting of the blockchain redaction capability for the WTRU, or (ii) the blockchain redaction key material.

4. The method of claim 1 , further comprising: receiving an indication of a monitored performance of the WTRU; and selecting the WTRU for the granting of the blockchain redaction capability based on the monitored performance of the WTRU.

5. The method of claim 1 , further comprising: receiving a blockchain redaction capability request for the WTRU; and determining to grant the WTRU with the blockchain redaction capability in response to receiving the blockchain redaction capability request.

6. The method of claim 1 , wherein granting the blockchain redaction capability comprises:sending information indicating one or more of: a blockchain redaction issuer, a blockchain redaction mode, the wireless blockchain network identifier of the wireless blockchain network, or an identifier of another wireless blockchain network configured to store a history of blockchain redaction operations associated with the wireless blockchain network.

7. The method of claim 6, wherein the blockchain redaction mode includes a direct redaction mode configured to cause the blockchain redaction issuer to send redaction operations directly to the wireless blockchain network.

8. The method of claim 6, wherein the blockchain redaction mode includes an indirect redaction mode configured to cause the blockchain redaction issuer to send redaction operations, via another network entity, to the wireless blockchain network.

9. The method of claim 1 , wherein the blockchain redaction key material includes at least one of a blockchain redaction key or a blockchain redaction key scheme used to derive the blockchain redaction key.

10. The method of claim 1 , further comprising: in response to transmitting the blockchain redaction capability notification, receiving a confirmation message indicating acceptance or rejection of the granting of the blockchain redaction capability for the WTRU.

11. A network entity comprising: a processor configured to: determine that a wireless transmit receive unit (WTRU) is capable of performing a blockchain redaction operation in a wireless blockchain network associated with a wireless blockchain network identifier; grant the WTRU a blockchain redaction capability for the wireless blockchain network; generate blockchain redaction key material; and transmit a blockchain redaction capability notification, wherein the blockchain redaction capability notification includes a blockchain redaction capability element indicating that the WTRU is granted with the blockchain redaction capability for thewireless blockchain network, wherein the blockchain redaction capability notification includes an indication of the blockchain redaction key material.

12. The network entity of claim 11 , wherein the network entity is configured to implement a blockchain governance function (BCGF) associated with a private key.

13. The network entity of claim 12, wherein the processor is further configured to: sign, using the private key of the BCGF, one or more transactions configured to indicate at least one of: (i) the granting of the blockchain redaction capability for the WTRU, or (ii) the blockchain redaction key material.

14. The network entity of claim 11 , wherein the processor is further configured to: receive an indication of a monitored performance of the WTRU; and select the WTRU for the granting of the blockchain redaction capability based on the monitored performance of the WTRU.

15. The network entity of claim 11 , wherein the processor is further configured to: receive a blockchain redaction capability request for the WTRU; and determine to grant the WTRU with the blockchain redaction capability in response to receiving the blockchain redaction capability request.

16. The network entity of claim 11 , wherein the processor, to grant the blockchain redaction capability, is configured to: send information indicating one or more of: a blockchain redaction issuer, a blockchain redaction mode, the wireless blockchain network identifier, or an identifier of another wireless blockchain network configured to store a history of blockchain redaction operations associated with the wireless blockchain network.

17. The network entity of claim 16, wherein the blockchain redaction mode includes a direct redaction mode configured to cause the blockchain redaction issuer to send redaction operations directly to the wireless blockchain network.

18. The network entity of claim 16, wherein the blockchain redaction mode includes an indirect redaction mode configured to cause the blockchain redaction issuer to send redaction operations, via another network entity, to the wireless blockchain network.

19. The network entity of claim 11 , wherein the blockchain redaction key material includes at least one of a blockchain redaction key or a blockchain redaction key scheme used to derive the blockchain redaction key.

20. The network entity of claim 11 , wherein the processor is further configured to: receive a confirmation message indicating acceptance or rejection of the granting of the blockchain redaction capability for the WTRU.

Images