Methods, architectures, apparatuses, and systems for an enabler of a blockchain-enabled wireless system

Abstract

Processes, methods, architectures, apparatuses, systems, devices, etc. are provided for enablers of blockchain-enabled wireless systems. A first of these apparatuses can be configured to receive a registration request from a network application, the registration request including information indicative of a plurality of application-level requirements of a distributed ledger service, including one or more performance requirements and one or more actions; determine a node of a distributed ledger system to associate to the network application based at least in part on the performance requirements; provide executable code for performing one or more of the one or more actions to each of one or more computing resources; and send a registration confirmation to the network application.

Description

[0001] Cross-references to related applications

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 045,857, filed June 30, 2020, which is incorporated herein by reference. Background Technology

[0003] This application relates to wired and / or wireless communications, including processes, for example, those relating to enablers for blockchain-enabled wireless systems. Attached Figure Description

[0004] A more detailed understanding can be obtained from the following detailed description, which is given by way of example in conjunction with its accompanying drawings. As with the detailed description, the figures in such drawings are illustrative. Therefore, the drawings and specific embodiments should not be considered limiting, and other equally effective examples are possible and contemplated. Additionally, similar reference numerals (“ref.”) in the drawings indicate similar elements, and wherein:

[0005] Figure 1A This is a system diagram illustrating an exemplary communication system;

[0006] Figure 1B It shows that it can be used Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) used within the communication system shown;

[0007] Figure 1C It shows that it can be used Figure 1A A system diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) used within the communication system shown;

[0008] Figure 1D It shows that it can be used Figure 1A The system diagram shown illustrates another exemplary RAN and another exemplary CN used within the communication system.

[0009] Figure 2 An exemplary workflow for a blockchain system is shown;

[0010] Figure 3 An exemplary timeline is shown at a blockchain node related to processing a new transaction;

[0011] Figure 4 This is a block diagram showing a communication system configured as a 5G system (5GS);

[0012] Figure 5 The various processes in 5GS are shown;

[0013] Figure 6An exemplary policy control reference architecture for non-session management related policy control is shown;

[0014] Figure 7 An exemplary policy control reference architecture for session management-related policy control is shown;

[0015] Figure 8 An exemplary use case for connected vehicles is shown;

[0016] Figure 9 This demonstrates use cases for smart manufacturing and logistics;

[0017] Figure 10 This is a block diagram illustrating an exemplary functional architecture of Blockchain Enabled Wireless Applications (BEWA);

[0018] Figure 11 An exemplary operation of a blockchain-enabled wireless application is shown;

[0019] Figure 12 An exemplary BCN registration process is shown;

[0020] Figure 13 An exemplary BCN registration process is shown;

[0021] Figure 14 An exemplary BCN registration process is shown;

[0022] Figure 15 The push-based BCN management process is illustrated.

[0023] Figure 16 The pull-based BCN management process is illustrated.

[0024] Figure 17 An exemplary procedure for BCN management triggered by BNA / BCA is shown;

[0025] Figure 18 An exemplary BNA registration process is shown;

[0026] Figure 19 An exemplary BNA registration process is shown;

[0027] Figure 20 An exemplary process for attributing BCF findings is shown;

[0028] Figure 21 An exemplary process for attributing BCF findings is shown;

[0029] Figure 22 An exemplary process for identifying BCFs in interviewees is shown;

[0030] Figure 23 An exemplary process for identifying BCFs in interviewees is shown;

[0031] Figure 24 An exemplary process for BCF discovery is shown;

[0032] Figure 25 An exemplary process for BCF discovery is shown;

[0033] Figure 26 An exemplary BCC registration process is shown;

[0034] Figure 27 An exemplary process for registering a BCA to its home BCF is shown;

[0035] Figure 28 An exemplary process for BCA to register with its visited BCF is shown;

[0036] Figure 29 An exemplary process for registering a BCA with a BCF is shown;

[0037] Figure 30 An exemplary process for BCF registration is shown;

[0038] Figure 31 An exemplary process for registering a BCC with a BCF is shown;

[0039] Figure 32 An exemplary process for registering a BCA with a BCC is shown;

[0040] Figure 33 An exemplary process for communication between BCFs is shown;

[0041] Figure 34 An exemplary process for communication between BCNs via BCF is shown;

[0042] Figure 35 An exemplary process for policy deployment is shown;

[0043] Figure 36 An exemplary process for policy execution is shown;

[0044] Figure 37 An exemplary 5G system architecture extension with blockchain application enablement is shown;

[0045] Figure 38 An exemplary blockchain-enabled wireless application deployment scenario is shown in 5GS;

[0046] Figure 39 An exemplary BCF / BCC / BNA implementation using existing entities in 5GS is shown.

[0047] Figure 40An example of managing blockchain policy rules for BCA and BCC in 5GS is shown;

[0048] Figure 41 This demonstrates an exemplary management of BNA's blockchain policy rules in 5GS.

[0049] Figure 42 This illustrates an example BNA-triggered blockchain policy update in 5GS;

[0050] Figure 43 An example of integrating existing vertical application enablement with blockchain application enablement is shown;

[0051] Figure 44 An example of integrating existing vertical application enablement with blockchain application enablement is shown;

[0052] Figure 45 An example of integrating existing vertical application enablement with blockchain application enablement is shown. Detailed Implementation

[0053] In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it should be understood that such embodiments and examples may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the following description. Furthermore, embodiments and examples not specifically described herein may be practiced in place of, or in combination with, the embodiments and other examples expressly, implicitly, and / or inherently described, disclosed, or otherwise provided herein (collectively, the “Provided”). Although various embodiments are described and / or claimed herein, in which apparatuses, systems, devices, etc., and / or any elements thereof perform operations, processes, algorithms, functions, etc., and / or any part thereof, it should be understood that any embodiment described herein and / or protected by the claims presupposes that any apparatus, system, device, etc., and / or any element thereof is configured to perform any operation, process, algorithm, function, etc., and / or any part thereof.

[0054] Exemplary communication system

[0055] The methods, apparatus, and systems provided herein are well-suited for communications involving both wired and wireless networks. Wired networks are well-known. Compared to... Figures 1A to 1D An overview of various types of wireless devices and infrastructures is provided, wherein various elements of the network may utilize, perform, be arranged according to, and / or be adapted to and / or configured with respect to the methods, apparatuses and systems provided herein.

[0056] Figure 1A This is a diagram of an exemplary communication system 100 that can be implemented in one or more of the disclosed embodiments. The exemplary communication system 100 is provided for illustrative purposes only and is not intended to limit the disclosed embodiments. The communication system 100 can be a multiple access system providing content such as voice, data, video, messaging, and broadcasting to multiple wireless users. The communication system 100 enables multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail (ZT) Unique Word (UW) Discrete Fourier Transform (DFT) Extended OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

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

[0058] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to, for example, facilitate access to one or more communication networks, such as CN 106 / 115, Internet 110, and / or Network 112. As an example, base stations 114a and 114b may be any of a base transceiver station (BTS), a node B (NB), an evolved node B (eNB), a home node B (HNB), a home evolved node B (HeNB), a g node B (gNB), an NR node B (NR NB), a site controller, an access point (AP), a wireless router, etc. Although base stations 114a and 114b are each depicted as a single element, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

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

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

[0061] More specifically, as noted above, the communication 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, etc. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 / 113 may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish air interfaces 115 / 116 / 117. WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink Packet Access (HSDPA) and / or High-Speed ​​Uplink Packet Access (HSUPA).

[0062] In the implementation scheme, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as evolved UMTS terrestrial radio access (E-UTRA), which can use Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro) to establish air interface 116.

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

[0064] In the implementation scheme, base station 114a and WTRUs 102a, 102b, 102c enable radio technology such as NR radio access, which can use New Radio (NR) to establish air interface 116.

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

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

[0067] Figure 1A Base station 114b can be, for example, a wireless router, a home node B, a home evolution node B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for use by drones), roads, etc. In implementations, base station 114b and WTRUs 102c and 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In implementations, base station 114b and WTRUs 102c and 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In implementations, base station 114b and WTRUs 102c and 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish any of the following: microcell, picocell, or femtocell. Figure 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106 / 115.

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

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

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

[0071] Figure 1B This is a system diagram of an exemplary WTRU 102. The exemplary WTRU 102 is provided for illustrative purposes only and is not intended to limit the disclosed embodiments. Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripheral devices 138, etc. It should be understood that, while remaining consistent with the implementation, WTRU 102 may include any sub-combination of the foregoing elements.

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

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

[0074] Additionally, although the transmitting / receiving element 122 is in Figure 1B While depicted as a single element, WTRU 102 may include any number of transmitting / receiving elements 122. For example, WTRU 102 may employ MIMO technology. Therefore, in one embodiment, WTRU 102 may include two or more transmitting / receiving elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interface 116.

[0075] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As noted above, WTRU 102 may have multi-mode capability. For example, transceiver 120 may therefore include multiple transceivers to enable WTRU 102 to communicate via various RATs such as NR and IEEE 802.11.

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

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

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

[0079] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software modules / units and / or hardware modules / units providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral device 138 may include an accelerometer, electronic compass, satellite transceiver, digital camera (e.g., for photos or video), Universal Serial Bus (USB) port, vibration device, television transceiver, hands-free headset, Bluetooth. ® Modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

[0080] WTRU 102 may include a full-duplex radio for which the transmission and reception of some or all signals (e.g., associated with specific subframes for 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 for reducing and / or substantially eliminating self-interference through signal processing via hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, WTRU 102 may include a half-duplex radio for which the transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

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

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

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

[0084] Figure 1C The core network 106 shown may include a mobility management gateway (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway 166. Although each of the foregoing elements is depicted as part of CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

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

[0086] The SGW 164 can connect to each of the evolved Nodes B 160a, 160b, and 160c in RAN104 via the S1 interface. The SGW 164 typically routes and forwards user data packets to and from WTRUs 102a, 102b, and 102c. The SGW 164 can also perform other functions, such as anchoring the user plane during handover between evolved Nodes B, triggering paging and / or mobility termination when DL data is available for WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0087] SGW 164 can also be connected to PDN gateway 166, which provides WTRU 102a, 102b and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

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

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

[0090] In a representative implementation, the other network 112 may be a WLAN.

[0091] A WLAN in Infrastructure Basic Services Set (BSS) mode may have an access point (AP) for the BSS and one or more sites (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or carries traffic out of the BSS. Traffic originating outside the BSS and destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA and destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as point-to-point traffic. Point-to-point traffic can be sent between source and destination STAs (e.g., directly between them) using Direct Link Establishment (DLS). In some representative implementations, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). WLANs using Standalone BSS (IBSS) mode may not have access points (APs), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. IBSS communication mode may sometimes be referred to as "ad-hoc" communication mode in this document.

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

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

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

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

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

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

[0098] Figure 1D This is a system diagram illustrating RAN 113 and CN 115 according to one implementation scheme. As noted above, RAN 113 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 113 can also communicate with CN 115.

[0099] RAN 113 may include gNBs 180a, 180b, and 180c; however, it should be understood that RAN 113 may include any number of gNBs while remaining consistent with the implementation scheme. Each of gNBs 180a, 180b, and 180c may include one or more transceivers for communication with WTRUs 102a, 102b, and 102c via air interface 116. In the implementation scheme, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, gNB 180a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In the implementation scheme, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers to 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 implementations, gNBs 180a, 180b, and 180c may implement Cooperative Multipoint (CoMP) technology. For example, WTRU 102a may receive cooperative transmissions from gNBs 180a and 180b (and / or gNB 180c).

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

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

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

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

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

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

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

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

[0108] Given Figures 1A to 1D as well as Figures 1A to 1D The functions described herein, including one or more of the functions described with reference to any of the following, may be performed by one or more emulation components / devices (not shown): WTRU102a-102d, base station 114a-114b, evolved Node B 160a-160c, MME 162, SGW 164, PGW166, gNB 180a-180c, AMF 182a-182b, UPF 184a-184b, SMF 183a-183b, DN 185a-185b, and / or any other components / devices described herein. An emulation device may be one or more devices configured to mimic one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0109] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, the one or more simulation devices may perform 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 to test other devices within the communication network. The one or more simulation devices may perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices may be directly coupled to another device for testing purposes and / or may use over-the-air wireless communication to perform tests.

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

[0111] introduction

[0112] Blockchain technology

[0113] Blockchain technology uses and builds upon a variety of existing technologies, such as cryptography, hashing, Merkle trees, distributed ledgers, peer-to-peer (P2P) networking, and consensus protocols. Blockchain innovatively combines these existing technologies to enable the system to provide advanced features such as decentralization, immutability, transparency, and security.

[0114] A blockchain system is a system that uses blockchain technology. Applications supported by a blockchain system are called blockchain applications. A blockchain system is supported by one or more underlying blockchain networks. Each blockchain network may include multiple (e.g., many) participating blockchain nodes (BCNs). Each BCN can host one or more distributed blockchains (a form of distributed ledger), broadcast blocks using a peer-to-peer network, and execute consensus protocols with other BCNs in the blockchain network to achieve distributed trust and data consistency without relying on a centralized party.

[0115] A blockchain transaction can be any of the following: a digital representation of a real-world transaction, a digital record of a physical asset, a digital record of a physical event, a digital record of any action in an information system, a digital payment, or a digital smart contract. A block combines multiple blockchain transactions. A blockchain is a data structure that links together a growing number of blocks.

[0116] For the sake of simplicity, the term "blockchain technology" is used in this document. It should be understood that these terms also refer to the broader concept of distributed ledger technology. Therefore, various implementation schemes are applicable to any specific blockchain technology and / or distributed ledger technology.

[0117] Figure 2 An exemplary workflow for a blockchain system is shown. The workflow may include initiating a transaction (1), broadcasting and verifying the transaction (2), building a new block (3), verifying the new block based on a consensus protocol (4), and updating the blockchain (5).

[0118] ● Initiating a Transaction: Each participating user can independently generate new transactions. Each user can have a user identifier and / or an account identifier. The user identifier and / or account identifier can be a hash of the user's public key ("User's Public Key"). Each new transaction is signed using the user's private key. After generating a new transaction, the user can send it to the blockchain network.

[0119] ● Broadcasting and Verifying Transactions: Some BCNs can receive new transactions. Transactions may include a user's public key. The BCN can use the user's public key to verify its integrity. After verification and if the new transaction is valid, it can be relayed and / or broadcast within the blockchain network. Ultimately, all blockchain nodes receive and possess a copy of any newly generated valid transactions.

[0120] ● Building a New Block: Some BCNs (called mining nodes) begin combining many newly generated pending transactions to generate a new block. A new block may include a block header and a block body. The block header may include the hash of the current block, the hash of previously confirmed blocks, and the hashes of all included transactions (e.g., a Merkle tree). Depending on the consensus protocol used, the block header may include other and / or additional information. The block body may include the content of all included transactions. Each mining node can independently attempt to create a new block.

[0121] ● Verifying new blocks based on a consensus protocol. Under the task of building a new block, mining nodes can independently attempt to create a new block. Mining nodes can run the same consensus protocol and can reach an agreement on who (i.e., the winner) is allowed to insert the block into the existing blockchain. The winner of the consensus protocol can send its newly generated block to the blockchain network. This new block may be broadcast; thus allowing all mining nodes to receive and / or verify it.

[0122] ● Update the blockchain. After the newly generated block is verified, it can be successfully appended to the existing blockchain because it includes the hash of the previous blockchain.

[0123] Figure 3An exemplary timeline at the BCN related to processing a new transaction is shown. The timeline illustrates the transaction and block states during the periods between the various stages of processing a new transaction. These periods may include transaction creation time, transaction waiting time, and transaction confirmation time (or blockchain confirmation time).

[0124] The transaction creation time can refer to the period between the time the request to create a new transaction is received and the time the transaction is created. During the transaction creation time, the transaction status can be "not created".

[0125] Transaction wait time refers to the period between the creation of a new transaction and its inclusion in a new block. The duration of the transaction wait time can depend on the underlying P2P network and consensus mechanism. During the transaction wait time, both the transaction and block states can be "pending".

[0126] Transaction confirmation time (or blockchain confirmation time) represents the period between when a new transaction is included in a new block and when the new block is confirmed. The duration of transaction confirmation time (or blockchain confirmation time) can depend on the underlying P2P network and consensus mechanism. During transaction confirmation time (or blockchain confirmation time), the transaction status can be "included," and the block status can be "pending." After the block is confirmed, its status can be "confirmed."

[0127] The speed of a transaction can be estimated as the sum of the transaction waiting time and the transaction confirmation time.

[0128] Figure 4 This is a block diagram illustrating a communication system 100 (Figure 1) configured as (e.g., as defined by 3GPP) a 5G system (5GS). The communication system 100 may include RAN 113 and CN 115. One of the design principles of the 5GS architecture is service-centric or service-based.

[0129] CN 115 may include various network functions. These network functions may work together to provide and / or offer services to RAN113, WTRU 102, and / or application servers / service providers. Network functions may include Network Repository Function (NRF), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Policy Control Function (PCF), User Plane Function (UPF), Network Exposure Function (NEF), Unified Data Management (UDM), Unified Data Repository (UDR), Unstructured Data Storage Function (UDSF), Network Data Analysis Function (NWDAF), and Network Slice Selection Function (NSSF).

[0130] Network functions can access other network functions. Network functions can access and / or interact with each other using either request / response or subscription / notification patterns. Network functions can register with the NRF. Registering with the NRF allows network functions to be discovered by other network functions.

[0131] The Access Management Function (AMF) manages access and mobility to WTRU 102 in communication system 100. The Support Management Function (SMF) is responsible for establishing sessions between WTRU 102 and CN 115. The Access US Function (AUSF) is responsible for authenticating users (e.g., WTRUs). The Control Plane Function (PCF) can create and / or provide one or more policy rules for other control plane network functions and WTRU 102. The PCF can assign identifiers to the created policy rules, and other control plane network functions and WTRU 102 can use the identifiers to reference (e.g., look up or otherwise obtain) the corresponding policy rules.

[0132] UPF can be a user plane function. UPF can monitor, manage, control, and redirect user plane traffic flows, such as between WTRU and application servers. NEF can expose control plane functionality to entities outside of 5GS and / or not in the same trust domain (e.g., network applications).

[0133] The CN can provide data storage and analysis services through any of the functions such as UDM, UDR, UDSF, and NWDAF. The communication system can support network fragmentation. NSSF can facilitate network fragmentation.

[0134] Although network functions can be defined as separate logical entities, some or all network functions can be combined. One or more network functions can be invoked and / or used in conjunction with specific processes or operations. For example, AMF, AUSF, and SMF can relate to WTRU mobility. One or more instances of a network function can be instantiated. The NRF can maintain information for each network function instance. Although shown in a single cloud, one or more network functions can be deployed in edge networks, such as edge networks supporting edge computing and / or closely proximate and / or co-located with RAN 113. Deploying UPF and / or NEF in edge networks supporting edge computing can be advantageous, as it can save on certain communication costs because policy control can be applied directly at the edge (i.e., where data / events are generated).

[0135] Figure 5 The various processes in 5GS are illustrated. For convenience, refer to... Figure 4 The communication system 100 describes various processes. Other architectures can also be used to execute various processes. For convenience and simplicity, the illustrations in the accompanying disclosure 5 are prefixed with "5:".

[0136] As shown in (5:1), the WTRU can discover and / or select networks (e.g., PLMN, RAN, cell, etc.) based on received System Information Blocks (SIBs) broadcast by one or more RAN nodes. As shown in (5:2), the WTRU can establish a Radio Resource Control (RRC) connection with the selected RAN (e.g., RAN1). The WTRU can communicate with the 5GS CN via the selected RAN. As shown in (5:3), the WTRU can initiate registration with the AMF. The selected RAN can determine / select the serving AMF for the WTRU from one or more AMFs. As shown in (5:3), the serving AMF can use the AFS to check for primary access authentication and authorization, request data subscriptions from the UDM, use the PCF to check for access and mobility policies, and / or contact the SMF to activate any existing PDU sessions (e.g., if instructed by the WTRU).

[0137] Registration Areas (RAs) can be defined within a 5GS. An RA can consist of one or more Tracking Areas (TAs); each Tracking Area can cover one or more cells. The advantage of an RA is that it reduces signaling overhead by eliminating the need for registration updates to the serving AMF within the RA, unless a periodic registration timer expires. If a WTRU moves from one RA (e.g., RA1) to another RA (e.g., RA2), the WTRU can perform a new registration, for example, using a registration type set to mobility registration update (as described herein and shown in (5:7)). Larger RAs can reduce registration overhead, but they can increase paging signaling overhead because the serving AMF must page the WTRU in a larger number of TAs (or cells).

[0138] After successful registration, the WTRU can enter the RM registration state and / or access and / or interact with other control planes (NFs) via the serving AMF. In various implementations, the serving AMF may be the sole entry point for the WTRU to access and interact with the CN control plane. For example, the processes represented in (5:3), (5:5), and (5:7) may be related to connection management.

[0139] As shown in (5:4), the WTRU can establish a PDU session for the DN with the SMF. The serving AMF can determine / select the serving SMF for the PDU session. As shown in (5:4), the SMF can use the PCF to check for the existence of a PDU session policy and / or select the UPF as the anchor point for the PDU session (“PDU session anchor”). The WTRU can access the DN and / or exchange packets with the DN via the PDU session anchor (PSA). The PCF can retrieve the WTRU’s subscription data from the UDR in conjunction with the SMF’s PCF check of the session policy and can provide it to the SMF. The SMF can use the WTRU’s subscription data retrieved from the UDM to perform primary session authentication and can perform secondary authentication between the WTRU and the DN-AAA server, for example, using Extensible Authentication Protocols (EAP) as defined in RFC3748 and RFC5247. The procedures shown in (5:4) and (5:5) can be performed together.

[0140] As shown in (5:5), the WTRU can be in a CM idle state (e.g., after releasing the connection with the serving AMF) and can initiate a service request procedure to re-establish the connection with the serving AMF and enter the CM connected state. When the WTRU initiates the service request procedure to re-establish the connection with the serving AMF, the WTRU can be in Mobile-Initiated Connection (MICO) mode. If the WTRU is not in MICO mode, the serving AMF can page and / or trigger the WTRU to initiate a service request procedure, for example, to receive any downlink packets. A non-access stratum (NAS) connection can be established between the WTRU and the serving AMF in conjunction with the service request.

[0141] This service can be performed in conjunction with WTRU registration, in which case the WTRU can enter the CM connection state. While in the CM connection state, the WTRU can move within the RA without notifying the service AMF. If the WTRU remains within the RA but moves out of the RAN notification area (RNA), the WTRU can perform a RAN update to trigger a RAN update of the WTRU context and the corresponding RRC connection maintained by the RAN. The RNA can be smaller than the RA. For example, the RNA may include a subset of the TAs that form the RA (e.g., TA1, TA2, and TA3 as shown).

[0142] As shown in (5:6), the WTRU can transmit data with the DN via RAN 113 and the UPF as a PSA (data plane). The DN can have a data network name (DNN). Although not shown, the 5GS can include more than one DN and / or be communicatively connected to it, and the DN can have a corresponding DNN.

[0143] As shown in (5:7), the WTRU can detect when it moves from RA1 to RA2. For example, the WTRU can detect such events by checking the TA list of each RA configured by the serving AMF. As shown in (5:7), the WTRU can utilize the new serving AMF to perform a mobility registration update. As shown in (5:7), a RAN handover (e.g., Xn-based or N2-based) can be performed from the current RAN to a new RAN with a changed serving AMF. The new serving AMF can contact the old serving AMF to transmit the WTRU's context information. As shown in (5:7), the SMF can contact the PCF and / or UPF to update the existing PDU session with the WTRU.

[0144] like Figure 5 As shown, multiple TAs can be combined together as a Local Area Data Network (LADN) service area to support LADN services. For example, TA4, TA5, and TA6 can form an LADN service area. WTRU access to LADN1 is permitted if (for example, if and only if) it remains within TA4, TA5, or TA6.

[0145] A group of TAs can be grouped into service areas. The 5GS can specify and / or enforce service area restrictions for WTRUs. For example, the 5GS can configure WTRUs to use service area restrictions for a service area formed by TA7, TA8, and TA9, where the WTRU is allowed to access the 5GS if (for example, if and only if) the WTRU remains within TA7, TA8, or TA9.

[0146] The information disclosed in this article and Figure 5 The various processes shown do not need to be executed in the order shown or described, and it is not necessary to execute all the processes. For example, the process represented by (5:7) can be executed before the process represented by (5:6), without the process represented by (5:5) needing to be executed.

[0147] Representative Policy Control Function (PCF)

[0148] Policy control in 5GS can include non-session management related policy control and session management related policy control. Figure 6 An exemplary policy control reference architecture for non-session management related policy control is shown. Figure 7 An exemplary policy control reference architecture for controlling policies related to session management is shown. Figure 7 The billing function (CHF) was introduced in China.

[0149] Examples of non-session management related policy controls include access and mobility related policy controls, WTRU access selection and PDU session selection related policy (WTRU policy) controls, Packet Flow Description (PFD) management, and network state analysis information requirements. Examples of session management related policy controls include QoS control for PDU sessions and service data flows (SDF), charging control for PDU sessions and SDF, reporting PDU session events to the AF, usage monitoring controls, application detection policy controls, service capability exposure policy controls, and traffic steering policy controls.

[0150] The PCF can provide various functions for both non-session management related policy control and session management policy control. The PCF can provide different policies to control plane functions (e.g., AMF, SMF, NEF), WTRU, and AF, where the provided policies can be executed. The PCF can retrieve subscription data from the UDR to create new policies. Operators can configure policies at the PCF. Policies can be stored at the UDR. Policies can be configured dynamically, semi-statically, and / or statically at various entities, devices, etc., such as any of the AMF, SMF, and WTRU.

[0151] For example, access and mobility-related policy control can provide any of the following: service area restriction management, RAT / Frequency Selection Priority (RFSP) function management, and SMF selection management. The serving AMF and PCF can perform "AM policy association establishment" for the WTRU (e.g., when the WTRU performs initial registration and selects (e.g., selects only the serving AMF). The serving AMF and PCF can exchange access and mobility-related policies, for example, after the AM policy association establishment.

[0152] Based on operator-defined policies, the PCF can modify the service area restrictions of the WTRU as part of its subscription data. The operator-defined policies in the PCF may depend on input data such as the WTRU's location, time, and information provided by other NFs. When the WTRU registers with the serving AMF, the serving AMF can retrieve its service area restrictions from the UDM as part of its subscription data. The serving AMF can report the service area restrictions to the PCF. The PCF can modify the service area restrictions and / or can send the modified service area restrictions to the serving AMF. The AMF can store the modified service area restrictions and / or can execute the modified service area restrictions to determine the WTRU's mobility restrictions.

[0153] The RFSP index can be used by the Serving AMF to manage the radio resources of the WTRU. The PCF can modify the RFSP index, for example, based on operator-defined policies. For instance, operator-defined policies in the PCF may depend on input data such as cumulative usage, load level information for each network slice instance, etc. When the WTRU registers with the Serving AMF, the Serving AMF can retrieve the RFSP index from the UDM, for example, as part of the subscription data. The Serving AMF can report the RFSP index to the PCF. The PCF can modify the RFSP index and / or can send it to the Serving AMF. The AMF can send the modified RFSP index to the (R)AN node. The RAN node can execute the modification of the RFSP index.

[0154] The PCF can configure the WTRU with various policies via the Serving AMF. These policies may include Access Network Discovery and Selection Policy (ANDSP) for non-3GPP access and WTRU Routing Policy (URSP) related to applications and PDU sessions. The WTRU can use URSP rules to determine whether to use an already established PDU session and / or trigger the establishment of a new PDU session for an application, for example, based on a traffic descriptor specified in a matching criterion included in (e.g., each) URSP rule. If the WTRU is in a CM idle state, the Serving AMF may send a paging message to the WTRU to trigger the WTRU to execute a WTRU-initiated service request procedure, thereby allowing the Serving AMF to pass the ANDSP and URSP (received from the PCF) to the WTRU.

[0155] Application detection, as a type of policy control related to session management, can be provided through interaction between the PCF, SMF, and UPF. The PCF can install (or activate) one or more Policy and Charging Control (PCC) rules, including enforcement actions, into the SMF. The SMF can instruct the UPF to detect events in specific application traffic. The UPF can apply configured enforcement actions to specific application traffic, such as gating (e.g., blocking application traffic), QoS control (e.g., bandwidth limiting), and traffic redirection.

[0156] UPF can detect events and report detected events to PCF via SMF. PCF can modify PCC rules and / or install the modified PCC rules into SMF based on one or more reported events.

[0157] In various implementations, enablers for wireless systems enabling distributed ledgers (e.g., blockchain) and / or methods used in conjunction with such enablers can be implemented in a WTRU. A first method can be implemented in a device including a circuit system comprising a transmitter, a receiver, and a processor, and the method may include (e.g., any of the following): receiving a registration request from a network application, the registration request including information indicating multiple application-level requirements of a distributed ledger service, including one or more performance requirements and one or more actions; determining nodes of the distributed ledger system, at least in part, based on the performance requirements, to associate with the network application; providing each of one or more computing resources with executable code for performing one or more of the one or more actions; and sending a registration confirmation to the network application.

[0158] The second method of these methods can be implemented in a device including a circuit system comprising a transmitter, a receiver, and a processor, and the method may include (for example, any of the following): receiving a registration request from a network application, the registration request including information indicating multiple application-level requirements of a distributed ledger service, including one or more distributed ledger system features, one or more performance requirements, and one or more actions; determining nodes of a distributed ledger system, at least in part, based on the performance requirements and the one or more distributed ledger system features, to associate with the network application; providing each of a plurality of computing resources with executable code for performing one or more of the one or more actions; and sending a registration confirmation to the network application.

[0159] The method further includes: generating one or more distributed ledger-related configurations for one or more actions, wherein providing executable code for performing one or more of the one or more actions includes providing executable code and distributed ledger-related configurations.

[0160] In various implementations, these multiple application-level requirements may include information indicating one or more distributed ledger-related policies.

[0161] In various embodiments, at least one of these methods may include providing distributed ledger-related policies to the policy functions of the communication network. In various embodiments, at least one of these methods may include deploying distributed ledger-related policies at the device.

[0162] The first type of these devices can be configured to receive a registration request from a network application, the registration request including information indicating multiple application-level requirements of the distributed ledger service, including one or more performance requirements and one or more actions; determine nodes of the distributed ledger system, at least in part, based on the performance requirements, to be associated with the network application; provide each of one or more computing resources with executable code for performing one or more of the one or more actions; and send a registration confirmation to the network application.

[0163] The second type of device can be configured to receive a registration request from a network application, the registration request including information indicating multiple application-level requirements of the distributed ledger service, including one or more distributed ledger system features, one or more performance requirements, and one or more actions; determine nodes of the distributed ledger system, at least in part, based on the performance requirements and the one or more distributed ledger system features, to associate with the network application; provide each of a plurality of computing resources with executable code for performing one or more of the one or more actions; and send a registration confirmation to the network application.

[0164] In various implementations, the circuit system can be configured to generate one or more distributed ledger-related configurations for the one or more actions; and to provide each of one or more computing resources with executable code for performing the one or more actions and one or more of the one or more distributed ledger-related configurations.

[0165] In various implementations, these multiple application-level requirements may include information indicating one or more distributed ledger-related policies.

[0166] In various implementations, the circuitry can be configured to provide distributed ledger-related policies to the policy functions of the communication network. In various implementations, the circuitry can be configured to deploy distributed ledger-related policies at the device.

[0167] In various implementations, the distributed ledger-related configuration may include either the transaction format of the distributed ledger system or any of the identified nodes.

[0168] In various implementations, this policy function can be a policy control function of the communication network.

[0169] In various implementations, the multiple application-level requirements may include any of the following: the identifier of the distributed ledger system; the type of the distributed ledger system; the consensus mechanism / protocol; the application programming interface (API) specification of the distributed ledger system; the number of peer nodes of the distributed ledger system; the current size of the ledger of the distributed ledger system; the geographical distribution of the peer nodes of the distributed ledger system; the ability of the distributed ledger to support new ledgers; one or more performance metrics supported by the distributed ledger system; the access details of the node of the distributed ledger system; the node type of the node of the distributed ledger system; the mobility type of the node of the distributed ledger system; and the organization associated with the node of the distributed ledger system.

[0170] In various implementations, the device and / or may be at least one service-based function, and the at least one service-based function may at least perform the task of identifying nodes in the distributed ledger.

[0171] In various implementations, a registration confirmation can be sent to the web application via an air interface. In various implementations, the registration request can be received via an air interface.

[0172] In various embodiments, the device and / or circuitry is configured as and / or configured with elements of a wireless transmit / receive unit (WTRU). In various embodiments, the device and / or circuitry is configured, or configured as and / or configured with elements of a sidelink relay or a base station.

[0173] The third of these methods can be implemented in a Blockchain Function (BCF) and may include any of the following: registering a Blockchain Node (BCN) for the blockchain capabilities of the BCN; monitoring and managing the blockchain capabilities of the BCN; and using the BCN to provide blockchain as a service to vertical applications.

[0174] In various implementations, another BCN can register its blockchain capabilities with the BCF, and the blockchain capabilities of the other BCN can be different from those of the first BCN.

[0175] In various implementations, the method may include determining the use of a BCN based on the vertical application and the blockchain capabilities of the BCN.

[0176] In various implementations, the method may include determining which BCN to use based on the vertical application, the blockchain capabilities of the BCN, and the blockchain capabilities of the other BCN.

[0177] In various implementations, the method may include configuring the blockchain as a service based on the blockchain capabilities of the BCN.

[0178] In various implementations, providing the blockchain as a service may include encapsulating the blockchain capabilities of the BCN. In various implementations, the method may include registering the vertical application.

[0179] In various implementations, the method may include registering the vertical application, which may include registering either a Blockchain Client Application (BCA) or a Blockchain Network Application (BNA).

[0180] In various implementations, registering a BCN may include any of the following: receiving a registration request from the BCN, wherein the registration request indicates the blockchain capabilities of the BCN; generating a BCN registration record for the BCN; adding the BCN registration record to a (e.g., local) repository; and sending a response to the BCN indicating the registration status.

[0181] In various implementations, the registration request may be a discovery message. In various implementations, the response may be a discovery message.

[0182] In various implementations, the method may include inspecting information sent from the BCN. In various implementations, the method may include verifying the BCN as a valid BCN for further operation. In various implementations, the method may include determining how to manage the BCN by: 1) subscribing to the first BCN regarding metrics and / or status that should be reported, or 2) periodically querying the real-time performance status of the first BCN.

[0183] In various implementations, the BCN can be a node in a blockchain system.

[0184] In various implementations, the registration request may indicate and / or include the blockchain capabilities of the BCN.

[0185] In various implementations, the registration request indicates and / or includes any of the following: (i) blockchain system identifier / identity; blockchain system type; consensus mechanism / protocol; application programming interface (API) specification of the blockchain system; number of peer nodes of the blockchain system; current size of the ledger of the blockchain system; geographical distribution of peer nodes of the blockchain system; the ability of the blockchain system to support new chains; one or more performance metrics supported by the blockchain system; access details of the BCN; node type of the BCN; mobility type of the BCN; and the organization associated with the BCN.

[0186] In various implementations, the method may include combining determination of using the BCN with referencing the BCN registration record.

[0187] In various implementations, the vertical application lacks the ability to interact directly with the BCN.

[0188] In various implementations, the method may include receiving a request to use a blockchain service from the vertical application.

[0189] In various implementations, providing blockchain as a service may include sending a response to the request to the vertical application.

[0190] In various implementations, the BCF can be deployed in any of the following: radio access network (RAN) nodes, core network (CN) nodes, servers, local gateways, and WTRUs.

[0191] The fourth method of these methods can be implemented in a first Blockchain Function (BCF) and may include any of the following: receiving a first request from a vertical application to discover a BCF capable of providing blockchain services; having the first BCF examine the information received from the vertical application; having the first BCF verify that the vertical application is permitted to use blockchain-related operations; having the first BCF determine a first Blockchain Node (BCN) assigned to the vertical application for providing the blockchain service; sending a second request to a second BCF capable of providing the blockchain service to provide the blockchain service; and receiving a response from the second BCF indicating that the second BCF agrees to provide the blockchain service to the first vertical application.

[0192] The fifth of these methods can be implemented in a first Blockchain Function (BCF) and may include any of the following: receiving a first request from a vertical application to use the blockchain service; determining that a BCF other than the first BCF is capable of providing the blockchain service; sending a second request to a second BCF to provide the blockchain service to the vertical application; receiving a response from an alternative BCF indicating that the second BCF agrees to provide the blockchain service to the vertical application; and sending a notification to the vertical application indicating that the second BCF is a substitute for the first BCF used to provide the blockchain service.

[0193] In various implementations, the method may include examining information received from the vertical application. In various implementations, the method may include verifying whether the vertical application has permission to request the blockchain service. In various implementations, the first request may be a discovery message.

[0194] In various implementations, the first request may indicate and / or include any one of the following: the identifier / identity of the vertical application, the identifier / identity of the vertical application client, the identifier / identity of the vertical application server, blockchain-related operations {to be performed}, and the current location of the device hosting the vertical application.

[0195] In various implementation schemes, the first BCN can be deployed in the core network.

[0196] In various implementations, the second BCF may reside at the edge of the network and / or at a location closer (e.g., physically closer) to the device hosting the vertical application.

[0197] In various implementations, the method may include identifying and / or selecting the second BCF based on its ability to provide the blockchain service.

[0198] In various implementations, the method may include sending a response to the first request to the vertical application.

[0199] In various implementations, the response to the first request indicates either that the second BCF will provide the blockchain service, or that the blockchain service will be provided by the second BCN. In various implementations, the vertical application may include a vertical application client.

[0200] The sixth of these methods may include any of the following: receiving a first request from a vertical application at a first blockchain function (BCF) to discover a BCF capable of providing blockchain services; having the first BCF examine the information received from the vertical application; having the first BCF verify that the vertical application is permitted to use blockchain-related operations; having the first BCF determine a first blockchain node (BCN) assigned to the vertical application for providing the blockchain service; sending a second request from the first BCF to a second BCF capable of providing the blockchain service; and receiving from the second BCF at the first BCF a response indicating that the second BCF agrees to provide the blockchain service to the first vertical application client.

[0201] In various implementations, the first request may be a discovery message.

[0202] In various implementations, the first request may indicate and / or include any one of the following: the identifier / identity of the vertical application, the identifier / identity of the vertical application client, the blockchain-related operation to be performed, and the current location of the device hosting the vertical application.

[0203] In various implementation schemes, the first BCN can be deployed in the core network.

[0204] In various implementations, the second BCF may reside at the edge of the network and / or at a location closer (e.g., physically closer) to the device hosting the vertical application.

[0205] In various implementations, the method may include identifying and / or selecting the second BCF based on its ability to provide the blockchain service.

[0206] In various implementations, the method may include sending a response to the first request to the vertical application.

[0207] In various implementations, the method may include a response to the first request, which may include any of the following: the second BCF will provide the blockchain service; and the blockchain service will be provided by the second BCN.

[0208] In various implementations, the method may include the second BCF determining whether to provide the blockchain service to the first vertical application.

[0209] In various implementations, the method may include determining the second BCN from one or more BCNs managed by the second BCF.

[0210] In various implementations, the first BCN and the second BCN are of the same type.

[0211] In various implementation schemes, the first BCN and the second BCN can have the same blockchain capabilities.

[0212] In various implementations, the BCF can be deployed in any of the following: radio access network (RAN) nodes, core network (CN) nodes, servers, local gateways, and WTRUs.

[0213] One of these devices may include any one of a receiver, a transmitter, a processor, and a memory, configured to perform at least one of the methods described above.

[0214] Representative Use Case 1 - Internet of Vehicles

[0215] Figure 8 An exemplary use case for vehicle-to-everything (V2X) connectivity is illustrated. Each vehicle may have a connection to the Internet via at least a wireless connection (e.g., 5G) with a roadside unit (RSU) (or base station). The RSU may include or access a local edge network with computing and storage resources.

[0216] A vehicle can move from one RSU to another. A vehicle can communicate with another vehicle, RSU, edge network, core network, and / or network applications. For example, vehicle 1 can discover vehicle 2 and may discover that both are under the same RSU 1. Vehicle 1 and vehicle 2 can communicate directly (e.g., vehicle-to-vehicle). After direct communication, one or both of vehicle 1 and / or vehicle 2 can send their communication records to the network to maintain history. Vehicle 2 may move out of the coverage area of ​​RSU 1 and / or may be associated with a new RSU, RSU 2. Vehicle 2 can communicate with any of the CN and network applications via RSU 2.

[0217] In this use case, there may be various scenarios where blockchain transactions can be created and stored on the target blockchain. Examples of these scenarios may include any of the following.

[0218] ● Events where Vehicle 1 and Vehicle 2 meet under the same RSU1 can be recorded in a blockchain transaction. This blockchain transaction may include, for example, the location information of the two vehicles.

[0219] ● Direct communication between vehicle 1 and vehicle 2 can be coordinated and enabled in a decentralized manner through a blockchain system.

[0220] ● Communication records between vehicle 1 and vehicle 2 can be recorded in a blockchain transaction. This blockchain transaction may include, for example, the duration of the communication and the total amount of data.

[0221] ● When vehicle 2 moves from RSU1 to RSU2, the new location of vehicle 2 can be recorded in the blockchain system.

[0222] ● RSU1 can store the context information of vehicle 2 in the blockchain system. Therefore, when vehicle 2 moves from RSU1 to RSU2, RSU2 can directly access the context information of vehicle 2 from the blockchain system without contacting RSU1.

[0223] ● After vehicle 2 moves to RSU2, it can directly send application messages to the network application via the blockchain network.

[0224] ● This blockchain transaction can record platooning events involving multiple vehicles. Example of a platooning scenario with three vehicles: Figure 8 Vehicles 3, 4, and 5 are shown in the image.

[0225] Representative Use Case 2 - Smart Manufacturing and Logistics

[0226] Figure 9 The accompanying illustrations illustrate smart manufacturing and logistics use cases. For convenience and simplicity, the reference numerals in the accompanying disclosures are prefixed with "9:". Smart manufacturing and logistics use cases may involve four stakeholders: customers, e-commerce companies, manufacturers, and logistics companies. These four stakeholders can utilize Internet of Things (IoT) and / or 5G technologies to implement smart manufacturing and logistics processes. Smart manufacturing and logistics processes may include any of the following:

[0227] ● Step or Operation 1: Each party can register as an application to 5GS (or cloud system) (9:1).

[0228] ● Step or Operation 2: Customers can submit a purchase request to the e-commerce platform (the application of the e-commerce company) (9:2). For simplicity, the purchase request can be for a single product item.

[0229] ● Step or Operation 3: The manufacturer application can receive a list of product items that may be ordered by customers from e-commerce platforms (9:3).

[0230] ● Step or Operation 4: The manufacturer application can send the list to the factory, where the ordered product items are manufactured and ready to be shipped to the customer (9:4).

[0231] ● Step or operation 5: The logistics company may receive notification that it has picked up the manufactured goods from the factory and is sending them to the customer (9:5).

[0232] ● Step or operation 6: The shipped items arrive at a warehouse that can be owned or rented by the logistics company (9:6).

[0233] ● Step or operation 7: The item can be delivered along the route to the customer (9:7).

[0234] ● Step or operation 8: The item may arrive and be received by the customer (9:8).

[0235] ● Step or operation 9: The e-commerce platform can receive notifications (9:9).

[0236] In this context, each step or operation can trigger one or more actions by the corresponding party, and any (e.g., each) such event can be created as a blockchain transaction and stored on the target blockchain. However, the WTRU attached to each package may be severely limited by resources due to cost reduction (e.g., WTRU reduction). Reduced WTRU may not have the ability to create transactions and / or participate in the blockchain system (e.g., store on the blockchain, execute consensus mechanisms, etc.). As used herein, the term "step" should be understood to encompass "one or more operations," and therefore, for convenience and simplicity, the terms "step" and "operation" are used interchangeably herein.

[0237] Each implementation addresses the following key issues described with reference to the use cases disclosed herein.

[0238] Key Issue #1: Blockchain as a Service (BAS) refers to providing users with an easy access interface so that they can leverage blockchain in their applications without having to deal with all the internal operational complexities of the blockchain system. However, most BAS solutions are proprietary and do not offer sufficient flexibility. For example, upper-layer application developers must understand the full API specification of the BAS provided by a specific company. When application developers intend to use a different BAS platform (provided by a different company) at a later time (e.g., due to new / emerging requirements / needs in their application or business logic), this results in significant maintenance and upgrade costs because application developers must relearn the new API specification of the second BAS platform. Proprietary BAS solutions may only offer a limited selection of underlying blockchain systems, which may not meet the diverse needs of application developers from different applications. In reality, it is foreseeable that many different types of blockchain systems exist, and it would be desirable if blockchain systems could participate in providing blockchain services. Therefore, public or standards-based Blockchain Functions (BCFs) may be needed as middleware to not only effectively manage different types of underlying blockchain systems but also provide easy and efficient blockchain services to upper-layer application developers. Unlike existing proprietary Blockchain-as-a-Service solutions where the entire blockchain infrastructure is proprietary, the public and standards-based Blockchain Functional Framework (BCF) allows multiple parties (e.g., multiple blockchain system providers) to freely participate in providing blockchain services. For example, using this BCF, different blockchain systems can proactively register with and be managed by it. In this way, the BCF can meet all kinds of needs from applications because it can manage a large number of different types of blockchain systems. In various implementations, the BCF can and / or can provide application developers with standard or unified interfaces, allowing application developers to understand only the common API specifications provided by the BCF. However, currently, this kind of public standards-based BCF is still lacking in all previous research and solutions.

[0239] Key Issue #2: Existing proprietary Blockchain-as-a-Service (BAS) solutions fail to provide effective edge-side support for applications. For example, most existing BAS solutions are cloud-based, and applications are often unaware of the geographical distribution of the underlying blockchain system's nodes. However, applications are typically deployed at the edge (e.g., on WTRUs), and they don't need to request certain blockchain services from a central cloud if certain desired blockchain nodes are directly available at or closer to the WTRU. To do this, a public BAS is expected to not only provide blockchain management capabilities but also help application developers identify available blockchain services at the edge. However, this feature is missing in all existing BAS solutions.

[0240] Key Issue #3: In more advanced scenarios, the system can have multiple BCFs, each managing a list of underlying blockchain nodes. Specifically, BCFs can periodically exchange information via an overlay network built between them, distinct from the P2P network of the underlying blockchain nodes. For two (or more) BCFs, each manages specific blockchain nodes, and the two nodes can originate from the same underlying blockchain system. Currently, there is no research on how the overlay network between BCFs can facilitate communication between blockchain nodes. In other words, all communication / interaction between two blockchain nodes does not necessarily rely on the P2P network of the underlying blockchain system. Instead, they can rely on BCFs to exchange information via an overlay network between them, which may not use the same communication medium used in the underlying blockchain network / system. Specifically, there is currently no research on how BCFs can facilitate messaging between underlying blockchain nodes, while also considering their own need for information exchange between BCFs.

[0241] Representative functional architecture of blockchain-enabled wireless applications

[0242] Figure 10 This is a block diagram illustrating an exemplary functional architecture of a Blockchain Enabled Wireless Application (BEWA) 1000. The functional architecture 1000 may include various entities, such as a Blockchain Client Application (BCA), a Blockchain Client (BCC), a Blockchain Network Application (BNA), a Blockchain Function (BCF), and a Blockchain Node (BCN). For ease of explanation and simplicity, reference is made to a communication system 100 (Figure 1 and...). Figure 5 Architecture 1000 is described. Functional Architecture 1000 can also be deployed in different architectures.

[0243] Some entities can be deployed on the WTRU / device side, while others can be deployed on the communication infrastructure side. For example, the WTRU / device can be configured with BCA and BCC. The infrastructure can be configured with BCF and BNA. In some implementations, the BCF can be deployed on any of the WTRU (e.g., a robust WTRU), home computer, edge host, etc.

[0244] The functional architecture 1100 can define a set of layers, such as an upper layer (e.g., top layer), a middle layer, and a lower layer (e.g., bottom layer). The upper, middle, and lower layers can respectively comprise a vertical application layer, a blockchain application enabling layer, and a blockchain infrastructure layer. Various entities can belong to different layers. For example, BCA and / or BNA can reside in the vertical application layer. BCC and / or BCF can reside in the blockchain application enabling layer. Although not shown, in some implementations, BCA can belong to the blockchain application enabling layer. BCN can belong to the blockchain infrastructure layer.

[0245] Vertical applications can be implemented by a BNA (e.g., for server-side functions) and one or more BCAs (e.g., for client-side functions). The BCA and BNA can, for example, perform client-side and server-side application logic processing for one or more (e.g., specific) vertical wireless applications, respectively.

[0246] A blockchain application enabling layer can provide and / or expose one or more (e.g., public) functionalities to vertical application layers. Using such functionalities, vertical application layers can access (e.g., more easily and / or efficiently) the blockchain infrastructure layer through the enabling layer. For example, BCC and BCF can provide various value-added blockchain services to BCA and BNA, respectively. BCC and BCF can interact with and / or manage the underlying BCN to use and / or combine its blockchain-related resources.

[0247] A BEWA can be a vertical wireless application. A BEWA can be implemented by a BNA (e.g., for server-side functionality) and one or more BCAs (e.g., for client-side functionality). The BCAs and BNAs can respectively handle client-side and server-side application logic for (e.g., specific) vertical wireless applications.

[0248] BCA can be a client entity, for example, used to support (e.g., specific) vertical wireless applications. For instance, in a smart manufacturing and logistics use case, a WTRU can be attached (e.g., linked) to a package, and a smart manufacturing and logistics BCA can be mounted on the WTRU. During transport, a package may fall off the rack of the delivery truck due to a sharp turn. Sensors on the WTRU can detect such events and / or can report such events to the BCA on that WTRU. The BCA can determine whether the fall is sufficient (e.g., serious enough) to require further action, such as whether to (i) log the event in the transport log (i.e., store the event record in a blockchain) and / or (ii) report the event record (or report the event record to the server-side smart factory and logistics BNA).

[0249] BCC can be, for example, a client entity that provides functionality related to blockchain services. BCA can be responsible for client application logic on WTRU and can interact with BCC to obtain blockchain services. In various implementations, BCC may not handle business logic for a specific vertical application; instead, it can act as a service interface of BCA to interact with the blockchain service (exposed by BCF).

[0250] A BNA can be a server-side entity used to support vertical applications. For example, in smart manufacturing and logistics use cases, a smart manufacturing and logistics management platform can be a BNA on the server side. A BNA can monitor all packages during transit. A BNA can be viewed as a manager / server / controller for wireless vertical applications, and it can provide and / or define application-specific processing logic, a list of associated BCAs, and relevant policies.

[0251] A BCN can be, for example, an entity that provides blockchain capabilities and functionalities. A BCN can be one of multiple BCNs that form the underlying blockchain infrastructure. A BCA and / or BNA can be consumers of the blockchain capabilities provided by a BCN.

[0252] The communication infrastructure can be a communication system 100 that supports communication between and / or among BCA, BCC, BNA and BCF.

[0253] BCF can be, for example, an entity used to support blockchain-enabled wireless applications. BCF functionality may include any of the following:

[0254] BCF can provide blockchain as a service. Different types of blockchain systems may exist with various performance specifications. The design principles or operations of the BCNs within these blockchain systems may differ significantly. BCA and / or BNA can provide business logic processing and may not possess the general capabilities / knowledge to interact with various BCNs from different blockchain systems. BCA / BNA may have difficulty effectively using BCNs or interacting with them directly. BCF can act as an intermediary and can provide blockchain capabilities as a service to BCA / BNA. For example, BCF can encapsulate the capabilities of the underlying BCN (e.g., regardless of the type of blockchain system to which the BCN belongs).

[0255] BCF can expose (e.g., a unified) interface and / or service description to the upper-layer BCA and BNA for accessing and / or utilizing the underlying blockchain capabilities provided by BCN. Various operational requests can be sent from BCA or BNA to BCN via BCF (e.g., to store transactions on the blockchain). BCF can translate requests into specific commands / calls for a particular blockchain system. It can be seen that, due to the existence of BCF, the system can become highly flexible in the sense that BCA and BNA can use the (e.g., a unified) blockchain service interface provided by BCF to obtain blockchain services from BCNs with different blockchain capabilities. BCF can perform effective BCN management (e.g., to use different BCNs provided by different types of blockchain systems) without notifying or influencing the upper-layer BCA and BNA. Unlike existing proprietary Blockchain-as-a-Service solutions where the entire blockchain infrastructure is proprietary, BCF allows multiple parties (e.g., multiple blockchain system providers) to freely participate in providing blockchain services (e.g., through BCN registration and management disclosed herein). For example, different blockchain systems can (e.g., proactively) register with and / or be managed by BCF, and BCF can provide blockchain-as-a-service in multi-party or multi-stakeholder environments.

[0256] A BCF can act as a principal of a BNA. As mentioned above, a BNA can be a server-side entity used to support (e.g., a specific) vertical application. For example, in smart manufacturing and logistics use cases, a management platform (as a BNA) can monitor all packages in transit. For distributed applications, processing data close to its origin may be preferred. For example, sending some or all of the real-time events from WTRUs (e.g., a large number of WTRUs) attached to a logistics mail package to a central management platform for processing may be inefficient and / or resource-intensive. A large amount of data is currently being generated at the edge, and the system closest to the edge can be a communications infrastructure (such as an access network). A significant portion of this large amount of data currently relies on the communications network to be sent to the vertical application server, and this data can be propagated from or through the access network and through the core network before reaching its vertical application server. A BCF can be deployed in either the access network or the core network. For example, multiple BCFs can be deployed in a communications system, where, for example, one BCF can be deployed on the access network while another BCF can be deployed in the core network. A BCF deployed in the core network can handle complex processing (such BCF deployments can facilitate / optimize data transmission from the edge to the server), while a BCF deployed in the access network can handle less complex processing. A BCF can provide blockchain management capabilities and help application developers identify available blockchain services at the edge. The communication network can provide various functions beyond supporting data communication. For example, in smart manufacturing and logistics use cases, the real-time location of the WTRU attached to the package can be obtained from the communication network (e.g., from its base station). Real-time location information may be necessary for processing business logic and for inclusion in blockchain transactions. A BCF can include and / or execute at least some business logic processing and / or business logic strategies (e.g., replacing and / or supplementing all business logic processing deployed on backend servers (e.g., on a BNA)); particularly if some processing is blockchain-related, such as retrieving blockchain transactions.

[0257] The BCF can act as an interface for interaction between the communication infrastructure / system and the BCC and / or BNA. As mentioned above, the communication infrastructure can provide functions beyond just transmitting data. When vertical applications are integrated with 3GPP networks, the BCA / BNA can effectively interact with 3GPP systems. For example, to establish an application-specific policy in the communication system, the BNA can transmit and deploy the policy to the PCF for future use. The BNA can communicate with the communication system to collect various information, including the current location of a specific WTRU, the current state of the WTRU (e.g., connected or offline), etc. For example, the BNA may need to obtain location information about a specific user or WTRU, and the BNA may not have the ability to interact directly with the communication system. The BCF can assist the BCA / BNA in interacting with the communication system, for example, for BCA / BNAs that may not have the ability to interact directly with the communication system.

[0258] Representative operations of blockchain-enabled wireless applications

[0259] BCF can perform operations related to system settings and configurations used to enable blockchain-based wireless applications. Figure 11 An exemplary operation 1100 of a blockchain-enabled wireless application is illustrated. For ease of explanation and simplicity, reference is made to the BEWA architecture 1000 ( Figure 10 ) and communication system 100 (Figure 1 and Figure 5 Operation 1100 is described using the symbol 11:. Different architectures can also be used to perform operation 1100. For convenience and simplicity, the illustrations in the accompanying disclosures are prefixed with "11:".

[0260] These operations may include BCF provisioning (11:0); BCN registration (11:1); BCN management (11:2); BNA registration (11:3); BCF discovery and selection (11:4); BCC / BCA registration (11:5); BCF-to-BCF interaction (11:6); and policy management (11:7).

[0261] BCF provides this functionality. BCF provisioning operations may include certain configuration settings, such as access details and instructions regarding how to interact with the communication infrastructure. This BCF provisioning operation can be performed using existing solutions.

[0262] BCN registration. The BCN registration process involves how a BCN registers with the blockchain application enabling layer. As mentioned above, different types of BCNs can be integrated into systems that support blockchain-enabled wireless applications, and the BCF can facilitate interaction between the underlying BCN and the upper-layer BNA / BCA. A BCN can register with the BCF. After a BCN is successfully registered with the BCF, the BCF can manage the BCN. The BCF can be called the managing BCF of that BCN, and the BCN can be called the managed BCN.

[0263] BCN Management. After a BCN is registered with BCF, BCF can provide various services to consumers, such as BNA and BCA. For example, BCF can offer blockchain as a service to consumers and can hide the underlying details of the BCN. BCF can perform certain management activities for the BCN. For example, BCF can monitor the real-time performance of the BCN (or the global performance of the entire blockchain system). If the BCN consistently performs well in supporting BNA or other consumers, BCF can use different types of BCNs to provide services for specific BNA / BCA.

[0264] BNA Registration. Blockchain-enabled systems can support various vertical applications. BCF can provide blockchain as a service to vertical applications. When a new vertical application is deployed, the corresponding BNA can register with BCF to leverage the blockchain service. During registration, the BNA can specify its application-level requirements for the blockchain service, and BCF can arrange and select the correct type of expectation (e.g., appropriate) BCN (which can come from different types of blockchain systems) to serve the BNA. The BNA can specify one or more application-specific policies and / or one or more blockchain-related policies. Application-specific and / or blockchain-related policies can be executed by BCF and / or directly deployed to the communication infrastructure for execution (e.g., deployed to the PCF in the communication network).

[0265] BCF Discovery and Selection. This BCF discovery and selection operation involves the WTRU / device side. Since WTRUs can be mobile, if they want to use blockchain services, the BCA / BCC on the WTRU can discover available BCFs that are close to or within a metric (e.g., close to) its current location (e.g., if the BNA is relatively static, the BNA can be directly connected to the BCF through pre-configuration). The disclosed BCF discovery solution can also be used by the BNA. For example, the WTRU may need to frequently interact with blockchain networks that may be deployed at the edge, for example, from an access network such as gNodeB. In this case, the WTRU may want to discover BCFs that are directly deployed in the WTRU's current access network and are close to or within a metric (e.g., close to) the WTRU's current location. In this way, the BCF can easily and / or quickly obtain information from the WTRU for interacting with the blockchain system.

[0266] BCC / BCA Registration. A BCC is a client-side middleware entity used to provide functionality related to blockchain services. A BCA can be a client-side entity used to support specific vertical wireless applications. To utilize the blockchain services provided by BCF, a BCA on a WTRU can interact with BCF via a BCC hosted on the same WTRU. The BCC / BCA registration process primarily involves how a BCC or BCA registers with BCF (discovered during the BCF discovery process) to use the blockchain services.

[0267] Interaction between BCFs and BCFs. Multiple BCFs can exist in the system, and each of them can manage a list of BCNs. Interaction between BCFs and BCFs can involve how different BCFs can exchange useful information to facilitate other operations. For example, two BCNs from the same underlying blockchain system can be managed by two different BCFs. These two BCFs can communicate with each other by relying on their managing BCFs for message passing (e.g., through an overlay network between BCFs in the blockchain application enabling layer) (e.g., not through the classic method, i.e., using a P2P network in the underlying blockchain system).

[0268] Policy management. Policy management operations can involve how to manage blockchain-related and / or application-specific policies. Policies can be created by different entities, deployed to different entities, and executed by different entities. For example, policies can be executed by a BCF (Blockchain-related Policy Provider) and / or by a PCF (Public Communication Provider) in a communication network (e.g., if policy execution collects data from the communication system).

[0269] Representative BCN registration

[0270] A typical basic case of BCN registration (one BCN registered to one BCF)

[0271] A BCN can be registered with a BCF. For example, a BCN and a BCF can perform a process to register the BCN with the BCF (“BCN Registration Process”). Once registered, the BCN can be managed by the BCF. A BCN can define capabilities, characteristics, basic information, etc. Since many different types of blockchain systems can be used, one or more of the capabilities, characteristics, basic information, etc., of a BCN can be defined according to one or more blockchain systems. The BCF can be notified of the capabilities, characteristics, basic information, etc., of the BCN in relation to registration with the BCF, for example, during the BCN registration process.

[0272] Figure 12 An exemplary BCN registration process 1200 is shown. For ease of explanation and simplicity, refer to the BEWA architecture 1000 ( Figure 10 ) and communication system 100 (Figure 1 and Figure 5 The process 1200 is described using the following: (e.g., BCN-1) . Different architectures can also be used to execute the process 1200. The BCN registration process 1200 can be executed by the BCN (e.g., BCN-1) and the BCF for supporting blockchain-based wireless applications. For convenience and simplicity, the accompanying illustrations in the public disclosures are prefixed with "12:".

[0273] BCN-1 can register itself with BCF. BCN-1 can be a node in a specific type of blockchain system, and it may have discovered BCF by providing operations through BCF (e.g., using an existing solution) (12:0). The blockchain system can be, for example, a private / consortium blockchain system. BCN-1 can know information about the entire blockchain system, including, for example, other BCNs within the blockchain system (e.g., as functions of P2P peers inherent in the blockchain system). BCN-1 can be a manager node, a controller node, or other types of nodes, etc.

[0274] BCN-1 may send a registration request (“Registration Request”) (12:1) to BCF. The Registration Request may indicate and / or include various information, such as capabilities, specifications, characteristics, basic information, parameters, etc. The Registration Request may include one or more (e.g., many) information elements. For example, BCN-1 may separately transmit information about (i) the blockchain system (e.g., as a whole) and (ii) BCN-1. BCN-1 may use one or more (e.g., different) IEs of the request to transmit information about the blockchain system (“BCS Information”) and information about BCN-1 (“BCN-Specific Information”).

[0275] BCS information may include any of the following: Affiliate Blockchain System (ABS) Identifier / Identity (ID) (ABS-ID), ABS Type (ABS-TYPE), Consensus Mechanism / Protocol Information Element (IE), Application Programming Interface (API) Specification IE, Number of peer nodes of the ABS IE, Current size of the ABS IE ledger, Geographical distribution of ABS IE peer nodes, Ability to support new chains of ABS, One or more performance metrics supported by ABS.

[0276] An ABS-ID can identify (e.g., uniquely identify) a blockchain system. An ABS-ID can be any ID, such as a name, number, alphanumeric value, etc., and can be locally and / or globally unique.

[0277] ABS-TYPE can indicate the type of blockchain system used in a blockchain system (“Blockchain System Type”). The Blockchain System Type can be any of, for example, a public blockchain, a private blockchain, and a consortium blockchain.

[0278] The consensus mechanism / protocol IE can indicate the type of consensus mechanism and / or protocol used in a blockchain system.

[0279] Many blockchain systems provide user-friendly APIs to facilitate user interaction with such systems (e.g., for retrieving transactions within the blockchain). The API specification (IE) can indicate the details and / or instructions for API access used to interact with the blockchain system via BCN-1 (e.g., available from BCF).

[0280] The number of peer nodes (IE) indicates how many peer nodes are in the blockchain system. This information allows BCF to understand the scale of the underlying blockchain system to which BCN-1 belongs. Specifically, when BCN-1 is the manager or controller node of a private / consortium blockchain system, it can provide this parameter to BCF.

[0281] Current Ledger Size (IE) indicates the current size of the ledger in a blockchain system.

[0282] Peer-to-peer (IE) data indicates where peer nodes in a blockchain system are located. For example, BCN-1 might be located in one geographic region, while another BCN in the blockchain system might be located in the same or one or more other geographic regions. This information is useful for BCFs to locate available BCNs in a specific region.

[0283] The New Chain Support IE indicates whether a blockchain system supports the creation of a new chain. For a given blockchain system, multiple chains can be created and maintained. Where data related to BNA-1 cannot be stored together with data related to BNA-2, all transactions related to BNA-1 and all transactions related to BNA can be stored in the corresponding chain hosted / run by the same set of blockchain nodes. The New Chain Support IE can also indicate whether BCN-1 can and / or work with multiple chains, including creating new chains or storing transactions in a specific chain.

[0284] Supported performance metrics (IEs) can indicate the performance metrics that the system can provide. Examples of performance metrics may include any number of blocks per hour (an indicator of the rate at which blocks are added to the blockchain); transactions per hour (an indicator of the number of transactions confirmed per hour); transaction wait time (an indicator of the time between when a transaction is created and when it is confirmed in the blockchain system), etc.

[0285] BCN-specific information may include any access details used for the BCN, the BCN's node type ("BCN Node Type"), the BCN's mobility type ("BCN Mobility Type"), and one or more IEs from any of the organizations associated with the BCN.

[0286] BCN access details can indicate the access details of BCN-1 (e.g., access address). BCN access details can also indicate how to interact with BCN-1 (e.g., to retrieve the current state of BCN-1).

[0287] The BCN node type can indicate the node type of BCN-1. The BCN node type can indicate one of several node types for BCN-1. The BCN node type can indicate that BCN-1 can be a partial node. As a partial node, BCN does not hold the entire ledger; instead, it can hold a portion of the ledger (e.g., related to a specific vertical application). The BCN node type can indicate that BCN-1 can be a basic full node. As a basic full node, BCN-1 can hold the entire ledger / blockchain. The BCN node type can indicate that BCN-1 can be a basic full node with additional mining capabilities. As a basic full node with additional mining capabilities, BCN-1 can hold the entire ledger / blockchain and can have mining capabilities within the blockchain system to which BCN-1 belongs. The BCN node type can indicate that BCN-1 can provide mining capabilities and can hold a portion of the ledger / blockchain.

[0288] The Local Performance Metric (IE) can indicate the performance metrics of BCN-1. Local performance metrics can include any of the following: confirmed on-chain blocks, local computing resources, neighboring node list, BCN mobility, communication capabilities, BCN host capabilities, and any of the BCN affiliate organizations.

[0289] The number of confirmed on-chain blocks indicates the number of blocks that BCN-1 has submitted and that have been successfully confirmed by the blockchain system to which it belongs.

[0290] Local computing resources can indicate the available memory and CPU resources of BCN-1.

[0291] The neighboring node list can indicate the number of other BCNs and their information (such as their addresses), which are the next-hop neighbors of that BCN in the underlying P2P network as part of the blockchain system designated by ABS-ID.

[0292] BCN mobility can indicate whether the physical node hosting BCN-1 possesses a certain level of mobility. For example, BCN-1 could be hosted on a mobile node such as a mobile vehicle with computing resources. It is anticipated that BCN-1 can travel across different geographical regions. This type of information can be useful for BCF in deciding whether to use BCN-1 as an interface node to interact with the underlying blockchain system.

[0293] Communication capabilities indicate what types of communication capabilities / media the BCN can use, such as Wi-Fi, cellular, LAN, etc.

[0294] BCN host capabilities can indicate: 1) if BCN-1 is hosted by a terminal device such as a mobile vehicle (e.g., the computing and storage resources that the device has); 2) if BCN-2 is a virtual software instance residing in some physical server, it indicates the software instance capabilities such as the allocated computing and storage resources.

[0295] BCN affiliates may refer to the affiliates of BCN-1 (e.g., the party or organization to which BCN-1 belongs).

[0296] BCF can inspect information sent from BCN-1 and / or can verify BCN-1 as a valid blockchain node for further operations. BCF can host a local BCN repository. BCF can create records for BCN-1 and add relevant information (e.g., as shown in (12:1) and in conjunction with it as shown above) for future use (12:2). BCF can assign a BCNID to BCN-1 (12:2). The BCN ID can be an external ID and can be used in intermediate layers (e.g., BCF) and upper layers (including BNA / BCA). The BCN ID can be different from the ID of BCN-1, which is a participating node in the underlying blockchain system.

[0297] BCF can send a response to BCN-1 to confirm its registration (12:3). This response may include and / or indicate the assigned BCN-ID.

[0298] BCF may be interested in other peer nodes of BCN-1 (e.g., in certain geographical areas) and may request BCN-1 to trigger the registration operation of such peer nodes when a peer node (e.g., a neighbor of BCF-1 in the underlying P2P network as part of the blockchain system) is identified by BCN-1. BCN-1 may monitor the availability of peer nodes during broadcast communications within the underlying blockchain system. After identifying other BCNs, BCN-1 may send triggers and / or requests to them to register BCNs with BCF via the underlying blockchain system or off-chain communications. The response may include any of the following parameters: (i) one or more types of BCNs of interest, (ii) the number of BCNs of interest, (iii) one or more performance requirements of the BCNs of interest, (iv) one or more desired regions of the BCNs of interest, (v) one or more other types of characteristics of the BCNs of interest, and (vii) one or more desired reporting instructions. The type of BCN of interest may indicate one or more types of BCNs of interest to BCF, such as partial nodes, full nodes, nodes with mining capabilities only, or full nodes with mining capabilities. The number of BCNs of interest can indicate the number of BCNs of interest to be identified by BCN-1. Performance requirements for the BCNs of interest may include the corresponding memory and CPU resources of the BCN. The desired region of the BCNs of interest can indicate one or more desired geographical regions where the BCN should be located. Note that this is just an example, and other types of desired characteristics can also be included as requirements. Access details for the BCF may be instructions to the BCNs, specifying where they should be registered. Expected reporting instructions may include detailed instructions that tell BCN-1 how to report its real-time status and performance metrics to the BCF in a defined manner. For example, to support BCN management operations, the BCF may require BCN-1 to periodically report its real-time performance metrics.

[0299] Figure 12 Process 1200 can be adapted for a BCN to register with a BCF. As mentioned above, a blockchain system may include multiple (e.g., many) peer nodes distributed in different locations, and each peer node may have similar or equivalent capabilities. For example, all full nodes in the blockchain system can host a copy of the ledger and / or all full nodes with mining capabilities can participate in the mining process. Other processes for BCN registration are disclosed below.

[0300] Procedure 1200 can be adapted to update the registration record of a BCN that has already registered with the BCF, except that BCN-1 can send a BCN registration update request to the BCF instead of sending a registration request to the BCF as shown in (12:1). The registration update request may include the BCNID.

[0301] Representative extension 1: BCN can register a set of BCNs to BCF.

[0302] Figure 13 An exemplary BCN registration process 1300 is shown. For ease of explanation and simplicity, refer to the BEWA architecture 1000 ( Figure 10 ) and communication system 100 (Figure 1 and Figure 5 The BCN registration process 1300 is described using the following syntax: ) . Different architectures can also be used to execute process 1300. The BCN registration process 1300 is suitable for scenarios where a BCN can register a set of BCNs with a BCF.

[0303] A BCN (e.g., BCN-1) can be a node in a specific type of blockchain system and can have discovered a BCF through a BCF offering operation, as shown in (13:0). BCN-1 can gather information from its peers in the blockchain system (e.g., based on information exchanged via broadcast), which can indicate other peer nodes present in the blockchain system (e.g., BCN-2, BCN-3, BCN-4, etc.) and / or can register with a BCF to support blockchain-based wireless applications (e.g., any other peer node that has not performed a BCF offering operation and wishes to rely on BCN-1 for registration). BCN-1 can know information about the entire blockchain system, including, for example, other BCNs in the blockchain system (e.g., as a function of the inherent P2P peers in the blockchain system). BCN-1 can be a manager node, a controller node, or other types of nodes, etc.

[0304] As shown in (13:0), BCN-1 can send a registration request to BCF. The registration request can be used to register one or more BCNs. The registration request can indicate and / or include various information for each BCN to be registered, such as capabilities, specifications, characteristics, basic information, parameters, etc. The registration request can include either the BCS information disclosed above or BCN-specific information for each BCN to be registered.

[0305] In various implementations, the group of BCNs may not have any collaboration when interacting with the BCF. The BCF can decide which BCN in the group to interact with.

[0306] In various implementations, the group of BCNs may support certain collaborations to guarantee the system performance of the underlying blockchain system to which they belong. In such implementations, the request may include any of the following:

[0307] BCN Priority—This indicates the priority of all BCNs to be registered. If this IE exists, it likely means that the BCF can interact with the underlying blockchain system via the BCN with the highest priority. If the BCN with the highest priority is unavailable, the BCF can check another BCN with the second highest priority, and so on. For example, BCN-1 could have the highest priority among the other three BCNs, namely BCN-2, BCN-3, and BCN-4, and for any interaction with the underlying blockchain system (e.g., retrieving the current state of the blockchain system), the BCF could attempt to perform certain operations using BCN-1. If BCN-1 is unavailable (e.g., leaving the system), the BCF can attempt to use BCN-2, as it has the second highest priority.

[0308] The operation of process 1300, represented by (13:2), is similar to that of process 1200, represented by (12:3). Figure 12 The operation involves assigning a BCN ID to each registered BCN. A BCF can assign a group ID to a group of BCNs (or multiple group IDs, each with a different BCN). The group ID can be used by other entities to search for member BCNs included in the group identified by the group ID.

[0309] The operation of process 1300, represented by (13:3), is similar to that of process 1200, represented by (12:3). Figure 12 The operation may include, except that the response may include and / or indicate either the group ID or the assigned BCN-ID.

[0310] As shown in (13:4), BCN-1 can notify other BCNs (via the underlying blockchain system) of the success and / or failure of their registration with BCF. For example, BCN-1 can notify each BCN of any of the following parameters: 1) the address and / or access details of the BCF; 2) the group ID of the group to which each BCN belongs; and 3) the priority of each BCN.

[0311] Representative extension 2: A group of BCNs can be registered to multiple BCFs.

[0312] Figure 14 An exemplary BCN registration process 1400 is shown. For ease of explanation and simplicity, refer to the BEWA architecture 1000 ( Figure 10 ) and communication system 100 (Figure 1 and Figure 5 The BCN registration process 1300 is described using the following approach. Different architectures can also be used to execute process 1400. The BCN registration process 1400 is suitable for scenarios where a group of BCNs can register with a group of BCFs.

[0313] A BCN (e.g., BCN-1) can be a node in a specific type of blockchain system and can have discovered a BCF by providing operations through it. BCN-1 can gather information from its peers in the blockchain system (e.g., based on information exchanged via broadcast) that indicates the existence of other peer nodes (e.g., BCN-2, BCN-3, and BCN-4, etc.) that can register with the BCF to support blockchain-based wireless applications (14:0). One or more groups of BCNs may want to register with different BCFs. BCN-1 can know information about the entire blockchain system, including, for example, other BCNs in the blockchain system (e.g., as a function of the inherent P2P peers in the blockchain system). BCN-1 can be a manager node, a controller node, or other types of nodes, etc.

[0314] As shown in (14:1), BCN-1 can collect registration requests from multiple BCNs (e.g., BCN-2, BCN-3, and BCN-4) within the blockchain system and can send a single registration request to BCF-1. This registration request can be used to register several BCNs, with at least two BCNs registering with their respective BCFs. The registration request can indicate and / or include various information for each BCN to be registered, such as capabilities, specifications, characteristics, basic information, parameters, etc. The registration request can include either the BCS information disclosed above or BCN-specific information for each BCN to be registered. Alternatively and / or additionally, the request can indicate and / or include the following parameters for each BCN to be registered: the desired BCF, which can indicate the specific BCF that the particular BCN wishes to register with.

[0315] As shown in (14:2), BCF-1 can receive this registration request. BCF-1 can, for example, use process 1200 (… Figure 12 The operation represented by (12:2) is used to register the BCN to be registered with BCF-1.

[0316] As shown in (14:3), BCF-1 can send registration requests to other BCFs to make any other registrations at other BCFs (e.g., based on the expected BCF parameters of each BCN).

[0317] As shown in (14:4), one or more other BCFs can handle the corresponding registration request (e.g., using process 1200). Figure 12 (12:2) shows the operation.

[0318] As shown in (14:5), the registration response can be sent from other BCFs to BCF-1 and can be received by BCF-1.

[0319] As shown in (14:6), BCF-1 can be, for example, based on processes 1200, 1300 ( Figure 12 and Figure 13 The operation (12:3, 13:3) represents the operation to send a response, except that the response may include and / or an aggregate response indicating all registered responses received from the BCF, and may include a list of BCN IDs. Each BCN ID may be assigned by BCF-1 and / or other BCFs.

[0320] As shown in (14:7), BCN-1 can, for example, be based on Figure 13 The process represented by (13:4) notifies other BCNs (via the underlying blockchain system) of the success and / or failure of their registration with their respective / desired BCFs.

[0321] Representative extension 3: BCN can be registered with multiple BCFs.

[0322] Refer again Figure 14 An exemplary BCN registration process 1450 is also illustrated. The BCN registration process 1450 can be adapted to register a BCN to a set of BCFs. In addition to those disclosed herein, by Figure 14 The diagram illustrates and relates to the BCN registration process 1450, which is similar to that described by... Figure 14 This diagram illustrates and incorporates the publicly disclosed BCN registration process 1400. When the BCN is hosted on a mobile node such as a smartphone WTRU or a mobile vehicle, it is... Figure 14 It may be useful to represent and combine the BCN registration process disclosed in the figure 1450.

[0323] BCN-1 can register with multiple BCFs (e.g., BCF-1, BCF-2, BCF-3, and BCF-4) because BCN-1 is hosted on a mobile host. Based on BCN-1's planned trajectory, BCN-1 can be scheduled to register with multiple BCFs during different time periods. For example, BCN-1 can be scheduled to register with BCF-1 during the period from 10:00 AM to 11:00 AM on a day when BCN-1 is traveling in geographic region A, and then it can be scheduled to register with BCF-2 during the period from 11:00 AM to 2:00 PM on a day when BCN-1 is traveling in a different geographic region B.

[0324] The operation of process 1450, represented by (14:1), is similar to the operation of process 1400, represented by (14:1). For example, BCN-1 can instruct BCF-1 how it wants to register with multiple BCFs (e.g., by including a schedule).

[0325] The operations of process 1400, represented by (14:2) to (14:6), are similar to those of BCN registration process 1450, except that such processes are performed for each BCF to be registered. BCN registration process 1450 does not require the operations of process 1400, represented by (14:7).

[0326] Representative BCN Management

[0327] BCN management operations can address how the BCF can manage BCNs registered with it. The BCF can monitor the real-time performance of a specific BCN and its corresponding blockchain system. The purpose of BCN management can be to ensure that the hosted BCN meets the needs of upper-layer users such as BNA and BCA. In cases where the performance of the hosted BCN (and its blockchain system) is not as expected, the BCF can perform certain management tasks (e.g., finding a replacement BCN or a replacement blockchain system) to meet (e.g., best meet) the needs of BNA and BCA.

[0328] Examples of BCN management operations can include push-based and pull-based processes. Under a push-based process, one or more BCNs within a BCN can proactively report real-time performance metrics to their managing BCN. Under a pull-based process, the managing BCN can send queries to its hosting BCNs to collect certain information.

[0329] Representative push-based BCN management methods

[0330] Figure 15 The push-based BCN management process 1500 is illustrated. For ease of explanation and simplicity, refer to the BEWA architecture 1000 ( Figure 10 ) and communication system 100 (Figure 1 and Figure 5 The BCN management process 1500 is described using the following: ) . Different architectures can also be used to execute process 1500.

[0331] Prior to the operation indicated by (15:1), BCN (e.g., BCN-1) may have already registered with BCF, for example, as disclosed herein. In the response message of BCN registration, BCF may instruct BCN-1 how BCN-1 should report real-time performance metrics to BCF (e.g., using desired reporting instruction parameters). For example, BCF may make one or more subscriptions to BCN-1 for performance reporting.

[0332] As shown in (15:1), BCN-1 can send a performance report request to BCF (e.g., due to a subscription to BCN-1). This request may include the following parameters:

[0333] ● BCN ID — This can indicate the BCN ID of BCN-1. The BCN ID may have been assigned to BCN-1 by BCF during BCN registration.

[0334] BCN-1 may report various performance metrics to BCF. For example, BCN-1 may transmit performance metrics about (i) the blockchain system (e.g., as a whole) and (ii) BCN-1 separately. BCN-1 may use one or more (e.g., different) reports to report performance metrics about the blockchain system (“BCS performance metrics”) and performance metrics about BCN-1 (“BCN-specific performance metrics”).

[0335] BCS performance metrics may include one or more of the following:

[0336] ● Subsidiary Blockchain System ID (ABS-ID): ABS-ID indicates the ID of the blockchain system to which BCN-1 belongs.

[0337] ● The latest number of peer nodes. The latest number of peer nodes indicates how many peer nodes are in the blockchain system.

[0338] ● Latest Ledger Size: The latest ledger size indicates the latest size of the ledger in the blockchain system.

[0339] ● Latest peer node geographic distribution. The latest peer node geographic distribution indicates the current geographic distribution of peer nodes in the blockchain system.

[0340] ● Latest Performance Metrics: Latest performance metrics indicate the system's most recent performance. Examples of latest performance metrics could include any blocks per hour; transactions per hour; transaction latency, etc.

[0341] BCN-specific performance metrics may include any of the following:

[0342] ● Latest Local Performance Metric: The latest local performance metric can refer to the most recent performance metric of BCN-1 itself. Examples of the latest local performance metric may include any of the following:

[0343] ○ Latest number of on-chain segments confirmed daily (or hourly): The latest number of on-chain blocks confirmed daily (or hourly) indicates the number of blocks submitted by BCN-1 and successfully confirmed by the blockchain system on the last day (or hourly).

[0344] ○ The latest available computing resources, such as available BCN-1 memory and CPU resources.

[0345] ● Latest Geographic Location: The latest geographic location can indicate the latest geographic location of BCN-1 (e.g., if BCN-1 is a mobile node).

[0346] ● Latest communication capabilities and performance: Latest communication capabilities and performance can indicate BCN’s latest communication capabilities (e.g., Wi-Fi, LAN or cellular) and / or current communication bandwidth / specifications.

[0347] As shown in (15:1), the BCF can receive performance metrics sent from BCN-1 and, if applicable, can perform appropriate actions (15:2). For example, the BCF can analyze the performance metrics and / or determine what actions need to be performed. For example, actions may include any of the following:

[0348] ● Assuming that the current BNA-1 and its corresponding BCA can utilize the underlying blockchain services provided by BCN-1 via BCF (e.g., according to the BNA registration disclosed herein), BCF can evaluate (e.g., compare) the performance metrics received from BCN-1 and the expected performance requirements of BNA-1 (which can be indicated to BCF by BNA-1 during the BNA registration operation). Based on the evaluation, BCF can decide:

[0349] ○ 1) Whether any adjustments need to be made to the underlying blockchain system that can serve BNA-1. For example, BCF can make one or more of the following decisions:

[0350] ■ BCF can determine that the local performance metric of BCN-1 does not meet the performance requirements specified by BNA-1, and can determine whether another BCN (e.g., BCN-2) can be found to serve BNA-1.

[0351] ■ The BCF can determine that the global performance metrics of the entire blockchain system to which BCN-1 belongs (e.g., with ABS-ID-1) do not meet the performance requirements specified by BNA-1. The BCF can determine whether to find another BCN (e.g., BCN-3) for serving BNA-1 from a different blockchain system (e.g., with a different ABS-ID-2). BCN-2 can be selected from different blockchain systems.

[0352] ○ 2) Whether to send any notifications to the upper-level BNA or BCA to learn about them.

[0353] As shown in (15:3), BCF can send confirmation of the performance metrics reported by BCN-1.

[0354] As shown in (15:4), if the BCF decides to make certain adjustments, such as selecting a different BCN for service BNA-1, the BCF can interact with BCN-1 and / or with other BCNs.

[0355] As shown in (15:5), the BCF can interact with BNA-1 and / or its corresponding BCA. For example, the BCF can send one or more notification messages to inform BNA-1 if needed. For example, the BCF can notify BNA-1 whether the newly assigned BCN of BNA-1 is capable of and / or can meet its needs. The BCF can hide the detailed characteristics of the newly assigned BCN from BNA-1 (e.g., in process 1200 represented by (12:1)). Figure 12 (Parameters disclosed in the operation). BNA-1 and / or the corresponding BCA can be adjusted based on application logic, for example, to use the blockchain service in different timelines.

[0356] Figure 15 Process 1500 can be adapted to update the registration records of BCNs that have already registered with BCF, except that BCN-1 can send a BCN registration update request to BCF instead of sending a registration request to BCF as shown in (12:1). The registration update request may include the BCN ID and / or updated information about the BCN.

[0357] Representative pull-based BCN management methods

[0358] Figure 16 The pull-based BCN management process 1600 is illustrated. For ease of explanation and simplicity, refer to the BEWA architecture 1000 ( Figure 10 ) and communication system 100 (Figure 1 and Figure 5 The BCN management process 1600 is described using the following: ) . Different architectures can also be used to execute process 1600.

[0359] Prior to the operation represented by (16:1), BCN (e.g., BCN-1) may have been registered with BCF.

[0360] As shown in (16:1), BCF can send a performance query request to BCN-1. This request may include the following parameters:

[0361] ● BCN ID: The BCN ID can indicate the BCN ID of BCN-1. The BCN ID may have been assigned to BCN-1 by BCF during BCN registration.

[0362] BCF can query various performance metrics. These metrics may include, for example, BCS performance metrics and / or BCN-specific performance metrics, as disclosed above.

[0363] As shown in (16:2), BCN-1 can report one or more performance metrics to BCF. The operation of process 1600, represented by (16:3) to (16:5), is similar to that of process 1500, represented by (15:2) to (15:5). Figure 15 ) operation

[0364] Representative BNA / BCA triggered BCN management

[0365] BCN management can be triggered by the BCN, for example, when the BCN's performance cannot meet the needs or requirements of upper-layer clients (i.e., BNA and its corresponding BCA). BCN management can also be triggered by the BNA and / or BCA in response to receiving and / or determining an update request / need to use the blockchain services provided by the BCN. Previously allocated BCNs (which are assigned for vertical applications during the BNA registration process, and the allocated BCNs will serve BNA and its corresponding BCA services, see below) may not meet updated / new requirements. Therefore, certain BCN management actions or adjustments can be performed by the BCF.

[0366] Figure 17 An exemplary process for BCN management 1700 triggered by BNA / BCA is shown. For ease of explanation and simplicity, refer to BEWA Architecture 1000 ( Figure 10 ) and communication system 100 (Figure 1 and Figure 5 The management process 1700 is described using the following methods. Different architectures may also be used to perform process 1700. The term "step" as set forth in the accompanying drawings is understood to include "one or more operations," and the terms "step" and "operation" are used interchangeably herein. The reference numerals for operations set forth in the accompanying drawings may include a prefix consisting of a figure number and a colon.

[0367] Prerequisites: A BCN (e.g., BCN-1) can be registered with a BCF and can currently serve BNA-1 and one or more corresponding BCAs. BNA-1 can be registered with a BCF.

[0368] Step 1: BNA-1 obtains and / or determines the expected performance of the service BCN update. BNA-1 may send an update request / need (17:1) to BCF.

[0369] Step 2: BCF can analyze the updated requirements / needs and determine one or more actions to be performed to meet the new requirements of BNA-1 and the corresponding BCA (17:2). Process 1500, represented by (17:2), can be executed. Figure 15 Similar to the operation of ).

[0370] Step 3: If the BCF decides to make certain adjustments, such as selecting a new BCN to serve BNA-1 and its corresponding BCA, the BCF may interact with BCN-1 and / or with other BCNs (17:3).

[0371] Step 4: The BCF can confirm whether the updated expected performance requirements (17:4) are met. The BCF can hide or not hide the detailed characteristics of the newly assigned BCN from BNA-1 (e.g., in conjunction with process 1200 shown in (12:1)). Figure 12 (The parameters of the operation are publicly disclosed). BNA-1 and / or the corresponding BCA can be adjusted based on application logic (e.g., for using blockchain services in different timelines), which can be specific to the implementation.

[0372] Representative BNA Registration

[0373] Blockchain-enabled systems can and / or support a variety of vertical wireless applications, and the enabling layer, including BCF, is a general-purpose middleware used to provide blockchain as a service to these vertical applications. Therefore, when a new vertical application is deployed, its corresponding Blockchain Application Name (BNA) can be registered with BCF, enabling it to utilize blockchain services. Generally, a BNA can be viewed as a manager for the vertical wireless application, providing application processing logic, a list of associated BCAs, and relevant policies. Both the BNA and its associated BCAs can be clients of one or more underlying blockchain systems managed by BCF.

[0374] Representatives register BNA with BCF for complete setup.

[0375] When a BNA is registered with a BCF, the BNA can rely on the BCF for complete deployment, including:

[0376] 1) During the registration process with a BNA, the BNA can specify its application-level requirements for the desired blockchain service. Therefore, a BCF can select a BCN of the desired type to serve that vertical application.

[0377] 2) BCF is responsible for deploying application logic processing modules, such as executable code for deployment actions (which will be executed by some participants).

[0378] 3) If the BNA needs to interact with communication infrastructure (such as 3GPP systems), for example, to deploy policies into the communication infrastructure, the BCF can interact with the communication infrastructure on behalf of the BNA.

[0379] After BNA is registered with BCF, BCF becomes the BNA's parent BCF.

[0380] Figure 18An exemplary BNA registration process 1800 is shown. For ease of explanation and simplicity, refer to the BEWA architecture 1000 ( Figure 10 ) and communication system 100 (Figure 1 and Figure 5 The process 1800 is described using the following method. Different architectures can also be used to execute process 1800. Process 1800 is suitable for scenarios where the BNA can be registered to a BCF with a complete BCF layout.

[0381] Prerequisites: A BNA (e.g., BNA-1) is a server / manager that has discovered a vertical wireless application of BCF. BNA-1 can register itself with BCF to utilize blockchain services. Each vertical application is implemented as a task list. Each task is implemented as a workflow of an action list. Each action is performed by a participant. Participants can be BNAs, BCAs, BCFs, or other network function entities in the communication system.

[0382] Step 1: BNA-1 can send a registration request and information about vertical wireless applications (such as smart manufacturing and logistics) to BCF. For example, the registration request may include the following parameters: a first set of information, a second set of information, and a third set of information.

[0383] The first set of information may include information that indicates, relates to, is associated with, and / or corresponds to a BNA, a corresponding vertical application, and / or a potential BCA, such as:

[0384] ● Application Name: The Application Name parameter indicates the name of the vertical application.

[0385] ● Registration Certificate: Registration certificate parameters may include information required for BCF verification and registration of BNA-1 (e.g., basic information).

[0386] ● Related BCA: The related BCA parameter can indicate BCAs belonging to the same vertical application (e.g., BCAs that can interact with BCF and BNA-1 for various processes related to this vertical application). The related BCA parameter can be a list of identifiers for related BCAs (e.g., a specific BCA-ID list or a WTRU-ID list, since BCAs can reside on WTRUs, or a list of manufacturing serial numbers). An example is in a permissioned or private blockchain system where only authorized users can access the blockchain serving a specific vertical application. Alternatively, the related BCA parameter can include one or more filtering criteria regarding which BCAs are capable of and / or can interact with BCF or BNA-1. In various implementations, the related BCA parameter can include a list of identifiers for related BCAs obtained from the vertical application's management server.

[0387] The second set of information may include indications, references, associations with, and / or correspondences to the expected interoperability, requirements, needs, and / or performance (e.g., expected performance) of the BCN that can be used in a vertical application (e.g., BNA-1), such as:

[0388] ● Desired Blockchain System Type: The desired blockchain system parameter can indicate the desired type of blockchain system for BNA-1, such as a public chain, a private chain, or a consortium chain.

[0389] ● Expected consensus mechanism: The expected consensus mechanism parameter can indicate the expected type of consensus mechanism for BNA-1.

[0390] ● Need for a New Chain: The "Need for a New Chain" parameter indicates whether all transactions related to BNA-1 should be stored on a new chain. For a given blockchain system, multiple chains can be created and maintained. For example, data related to BNA-1 cannot be stored together with data related to BNA-2. In this case, it might be desirable that all transactions related to BNA-1 can be stored on chain A, while all transactions related to BNA-1 can be stored on another chain B, and both chains can be hosted / run by the same group of blockchain nodes. In one implementation, if the value of this parameter is true, it may mean that BNA-1 needs a new chain to store its related data. Otherwise, it means that BNA-1 does not need a new chain.

[0391] ● Expected performance requirements: Expected performance requirements parameters can indicate the expected performance requirements of the blockchain system that BNA-1 wants to use, such as (i) the expected number of blocks confirmed per hour, (ii) the expected number of transactions per hour, (iii) the expected transaction latency, (iv) and so on.

[0392] ● Number of Allowed BCAs: The Number of Allowed BCAs parameter indicates the number of BCAs associated with BNA-1 and permitted to use the blockchain system.

[0393] The third set of information may include information that indicates, relates to, is associated with, and / or corresponds to application logic processing, such as:

[0394] ● Application Task List: The application task list parameter can indicate a list of one or more tasks related to a vertical application. The tasks listed on the task list can form the application logic processing of the vertical application. In the implementation scheme, for each task, the application task list parameter may include the following information:

[0395] ○ Task ID: The Task ID parameter indicates the specific task ID for this vertical application.

[0396] ○ Task Workflow and Participants: The task workflow and participant parameters can indicate the entire workflow of a task, such as the first participant that takes the first action (i.e., to trigger task execution), and the subsequent actions to be completed.

[0397] For each action, the application task list parameter may include the following information (e.g., actions typically correspond to processes performed by participants, implemented by executable code):

[0398] ■ Participants: The participant parameter indicates who is a participant in an action. This information defines the participants involved for a given task. For example, a participant can be any of the following: BNA, BCA, BCF, network functions in the communication infrastructure, etc. For example, action 1 in task flow A of BCF could be processing a request and sending a response back to BCA-1. The subsequent action after action 1 in task flow A could be action 2, which would be performed by BCA-1 (as a participant in action 2). Action 2 includes receiving a response from BCF and performing some further processing (by BCA-1).

[0399] ■ Executable Code: Each action (which may have an action ID) can be implemented as executable software code. The executable software code can be deployed to the corresponding participants, as defined in the workflow. Executable code parameters may include the executable code itself and / or a URL indicating where the stored executable code is located and / or where BCF can download or retrieve the code.

[0400] ■ Transaction Format: When an action requires the creation of a blockchain transaction, the transaction format information indicates the type of blockchain transaction to be created for that specific action, if necessary; and the format of the transaction associated with that action (e.g., the exact format). For example, the transaction format parameter may include the following information:

[0401] ■ Vertical Application Name or BNA ID: The Vertical Application Name or BNA ID parameter can indicate the name of a specific vertical application, the identifier of the vertical application, a pre-provided BNA-ID, or a BNA-ID assigned by BCF.

[0402] ■ Task ID: The Task ID parameter can indicate the identifier of a task. Alternatively, the Task ID parameter can be a specific task name. In short, the information in this parameter will show (and may indicate) which specific process the transaction to be created is associated with.

[0403] ■ Action ID: The Action ID parameter can indicate the identifier of the action of the task. Alternatively, the Action ID parameter can be a specific action name. In short, the information in this parameter will show (possibly indicate) which specific action / operation the transaction to be created is associated with.

[0404] ■ Participant ID: Generally, the participant ID parameter indicates the participant's identifier. It can be a participant ID, a participant's specific name, a participant's unique serial number, a participant's MAC address, a manufacturing serial number, etc. A participant can typically be, for example, a BCF (Blockchain Function), assuming that the BCF can interact with the underlying BCN to insert new transactions into the blockchain.

[0405] ■ Transaction creation time: The transaction creation time parameter indicates when a blockchain transaction is created.

[0406] ■ Other application-specific data (if applicable)

[0407] ■ Configuration Data: For a given action to be taken, it is possible to refer to configuration data during the processing of that action. An example of configuration data could be a policy, and an action could refer to executing that policy. For each specific information element of the configuration data, configuration data parameters may include any of the following information:

[0408] ■ Data name: For example, a strategy name.

[0409] ■ Data Content: Actual data content. For example, it could be a detailed strategy.

[0410] ■ Data Deployment Location: For example, blockchain-related policies can be stored in the BCF (i.e., the policy can be executed by the BCF), or the policy can be stored directly in the communication infrastructure, such as in the PCF of a 3GPP network. For example, suppose a transaction describes the state of a BCA, and a policy (e.g., policy X) is that a transaction should not be created if the BCA (hosted by the WTRU) is located in a specific area (due to privacy concerns). In this case, it would be desirable if policy X could be deployed directly into the 3GPP network (e.g., into the PCF), allowing other 3GPP network functions to easily retrieve policy X and automatically execute it when the WTRU moves to the specific area described in policy X.

[0411] Step 2: BCF can inspect the information sent from BNA-1 and can verify BNA-1 as a valid BNA representing a vertical application based on the registration credential parameters. BCF can host a local BNA repository and can create new BNA records for BNA-1, as well as add the relevant information specified in Step 1 for future use (18:2). BCF can assign a BNAID to BNA-1 (18:2).

[0412] Step 3: The BCF can analyze the expected performance requirements sent from BNA-1, check its BCN repository, and select an appropriate BCN to meet BNA-1's needs (18:3). For example, BCN-1 can be selected as the appropriate BCN to serve all blockchain-related processing of BNA-1. In advanced scenarios, the BCF can and / or can select an appropriate BCN for specific tasks of a vertical application or for specific actions of a task (e.g., a more granular approach using blockchain services). In another advanced scenario, if the BCF cannot find the expected BCN for serving BNA-1 in its own BCN repository, it can request other BCFs to help determine if another BCF manages a particular BCN that can and / or can serve BNA-1 (as a result, BNA-1 can then choose to register with a later BCF).

[0413] Step 4: For each piece of configuration data, the BCF performs various deployments (18:4). For example, a specific information element of the configuration data may be a policy, and this policy needs to be directly deployed into the 3GPP network for execution. The BCF can perform this task on behalf of BNA-1 to interact with the 3GPP network and deploy such policies to the PCF of the 3GPP network, or to store them in the UDM of the 3GPP network. Alternatively, the BCF can install such policies locally or to the BCC and / or another BCF. The BCF can generate new policy rules based on the configuration data and install these new policy rules to the BCN, BCC, another BCF, and / or PCF in the 3GPP network.

[0414] Step 5: For each task specified in the request message in Step 1, BCF can perform some deployment (18:5). For example, each task involves a workflow of actions, and these actions are performed by different participants. Therefore, BCF can deploy the executable code for each action to the corresponding participant. If some configuration data is available during the action, BCF also needs to configure the participants so that they know where to obtain the required configuration data deployed in Step 4.

[0415] Step 6: BCF can send an acknowledgment to BNA-1 to confirm its registration (18:6). BCF becomes the home BCF of BNA-1, thus belonging to the same vertical application.

[0416] As can be seen, in the above process, the BCF plays multiple roles, such as: 1) managing and interacting with the BCN to serve the BNA and the corresponding BCA; 2) interacting with the communication infrastructure (e.g., deploying strategies to the 3GPP network on behalf of the BNA / BCA); 3) deploying executable code for each action to the corresponding participant; and 4) performing actions (e.g., executing application logic code, collecting certain data from the 3GPP network, or storing blockchain transactions in the BCN on behalf of the BNA). Alternatively, after registering with the BCF, the BNA-1 can send a third set of information (corresponding to application logic processing) to the BCF using a separate step. After receiving the application logic processing information via this separate step, the BCF can perform steps 4 and 5 as described above.

[0417] Representatives registered BNAs with BCF for partial deployment.

[0418] In this section, when a BNA registers with a BCF, it relies on the BCF for partial deployment. For example, during BNA registration, it can (e.g., only) specify its application-level requirements for the desired blockchain service. Therefore, the BCF can select a BCN of the desired type to serve that vertical application. All other matters can be handled by the BNA itself; for example, the BNA is responsible for deploying application logic processing modules, such as executable code for deployment actions (which will be executed by some participants). If the BNA needs to interact with communication infrastructure (e.g., 3GPP systems), for example, to deploy policies within the communication infrastructure, the BNA can interact directly with the communication infrastructure.

[0419] Figure 19 An exemplary BNA registration process 1900 is shown. For ease of explanation and simplicity, refer to the BEWA architecture 1000 ( Figure 10 ) and communication system 100 (Figure 1 and Figure 5 The process 1900 is described using the following method. Different architectures can also be used to execute process 1900. Process 1900 is suitable for scenarios where a BNA can be registered to a BCF with a partial BCF arrangement.

[0420] Prerequisites: A BNA (e.g., BNA-1) is a server / manager that has discovered a specific vertical wireless application of BCF. BNA-1 intends to register itself with BCF to utilize blockchain services. Each vertical application is implemented as a task list. Each task is implemented as a workflow of an action list. Each action is performed by a participant. Participants can be BNA, BCA, BCF, or any other network functional entity in the communication system.

[0421] Step 1: BNA-1 can send a BNA registration request and information about vertical wireless applications (such as smart manufacturing and logistics) to BCF. For example, the registration request may include the following parameters:

[0422] The first set of information may include information indicating, relating to, associated with, and / or corresponding to a BNA, a corresponding vertical application (e.g., BNA-1), and / or a potential BCA, such as as described in step 1 of process 1800 ( Figure 18 ).

[0423] The second set of information may include indications, references, associations with, and / or correspondence to the expected interoperability, requirements, needs, and / or performance (e.g., expected performance) of the BCN that can be used in a vertical application (e.g., BNA-1), such as step 1 of process 1800. Figure 18 As stated in ( ).

[0424] The third set of information may include information that indicates, relates to, is associated with, and / or corresponds to application logic processing, such as: information related to... Figure 18 The third set of information described in step 1 (except for the "configuration data" section which is not required for BNA-1).

[0425] Step 2: with Figure 18 Step 2 is the same.

[0426] Step 3: with Figure 18 Step 3 is the same.

[0427] Step 4: BCF can send an acknowledgment to BNA-1 that potentially has a BNA ID assigned to BNA-1 in order to confirm its registration.

[0428] Step 5: To run vertical applications, some configuration data may be required. Therefore, for each piece of configuration data, BNA-1 can perform some deployment. For example, a piece of configuration data could be a policy, and such policies need to be deployed directly into the 3GPP network for execution. Therefore, BNA-1 can perform this task to interact with the 3GPP network and deploy such policies into the 3GPP network's PCF, or to store them in the 3GPP network's UDM.

[0429] Step 6: For each task, BNA-1 can perform certain deployments. For example, each task involves a workflow of actions, and these actions are performed by different participants. Therefore, BNA-1 can deploy the executable code for each action to the corresponding participant. In particular, if certain configuration data is available during the action, BNA-1 can configure the participants so that they know where to obtain the required configuration data.

[0430] Representative BCF discovery and selection

[0431] Different system settings and assumptions can be used for BCF discovery and selection. Therefore, this section proposes solutions for discovering BCF in three different scenarios, each with its own assumptions and settings.

[0432] Representative Scenario 1: When a BCA can be associated with multiple BCFs for different purposes

[0433] In this scenario, we consider the following system setup and assumptions:

[0434] ● A BCC-1 on WTRU can register with a BCF, which is the first contact BCF of the BCA served by the BCC-1 (to be defined below) (e.g., based on its current location).

[0435] ● Any BCA served by BCC-1 (e.g., BCA-1) may register with its home BCF (defined below), which is the BCF to which its corresponding BNA registers.

[0436] ● In addition, any BCA served by BCC-1 (e.g., BCA-1) can register with a visited BCF (defined below), which can be a BCF at the edge or in other locations closer to BCA-1, and can provide BCA-1 with blockchain services equivalent to those of its home BCF.

[0437] This operation primarily relates to the WTRU of the BCA. Typically, for a given BCA (e.g., BCA-1), it can have different types of findings for various purposes, as listed below:

[0438] ● Home BCF Discovery: In this type of discovery, if BCA-1 enters the system for the first time, BCA-1 will find a qualified BCF as its home BCF for BCA registration (this BCF is defined as BCA-1's home BCF).

[0439] ● BCF Receiver Discovery: In this type of discovery, BCA has already registered with its home BCF (which hosts the registration records of BCA-1), but now BCA intends to find another BCF (defined as its Receiver BCF) to utilize blockchain services. For example, the Receiver BCF could be a BCF deployed closer to the edge or closer to BCA's current location, and could provide blockchain services to BCA and assist BCA in blockchain-related operations (e.g., the Receiver BCF manages the underlying BCN, which is BCA's desired BCF).

[0440] Therefore, for a given BCA-1 at its current position, there can be three different types of BCF:

[0441] ● Home BCF: A home BCF (e.g., BCF-1) is a home BCF to which the corresponding BNA registers. Within this home BCF, the BNA registry repository and the BCA registry repository are hosted. The home BCF can interact with the underlying BCN that provides blockchain services to BCA-1 and its corresponding BNA.

[0442] ● Targeted BCF: Due to the movement of BCA-1, BCA-1 can be directly served by the targeted BCF. This is because, as mentioned earlier, the underlying blockchain system is a distributed system with many peer BCNs. For example, the home BCF (e.g., BCF-1) can interact with BCN-1 to serve BCA-1, and BCN-1 is a node from blockchain system 1 (i.e., with affiliated blockchain system ID ABS-ID-1). For a blockchain system with ABS-ID-1, it can have another peer node managed by another BCF-2, such as BCN-2. In particular, BCF-2 is deployed in a location closer to BCA-1's current location. Therefore, if BCA needs to perform any blockchain-related operation (e.g., retrieving transactions), it is expected that BCA-1 can attempt to discover BCF-2 (as its targeted BCF) and try to perform the blockchain-related operation using BCF-2. In this way, it can save significant communication costs associated with communicating with its remote home BCF.

[0443] ● First Contact BCF: The first contact BCF is the BCF that provides the first-hop connection to BCA-1 from its current location. A visited BCF may be located closer to BCA-1 than its home BCF, but not immediately adjacent to BCA-1. BCA-1 can rely on its first contact BCF deployed at its current location (or corresponding geographic area) to further discover its home BCF (for home BCA registration) or visited BCF (for blockchain-related operations). Alternatively, the role of the first contact BCF can be replaced by other entities, as long as it helps BCA-1 find its home BCF or visited BCF. Given BCA-1, its first contact BCF can be a BCF registered by its corresponding BCC. In other words, the BCC-1 hosting BCA-1 can register with nearby BCFs, and such BCFs can be considered BCA-1's first contact BCF. For example, BCC-1 can broadcast discovery messages to the network to discover available BCFs covering its current location (such as...). Figure 20 (as shown in step 0).

[0444] The home BCF, the visited BCF, and the first contact BCF are all logical roles and can be located in the same place or act as the same physical BCF instance. For example, for a given BCA, its first contact BCF may also be its visited BCF.

[0445] BCF attribution discovery for BCA registration / association purposes

[0446] Figure 20 An exemplary attribution BCF discovery process 2000 is illustrated. For ease of explanation and simplicity, refer to the BEWA architecture 1000 ( Figure 10 ) and communication system 100 (Figure 1 and Figure 5 Process 2000 can be described using [a specific architecture]. Different architectures can also be used to execute Process 2000. Process 2000 is suitable for [specific applications]. Figure 20 The scenario shown in Scenario 1 is the home BCF discovery process for BCA registration purposes.

[0447] Prerequisites: A BCC (e.g., BCC-1) has discovered a BCF and has registered with it (e.g., BCF-1) based on the current location of the WTRU hosting BCC-1 and BCA-1. BCF-1 may be the first contact BCF of BCA-1. Multiple BCFs exist in the system and are aware of each other due to, for example, periodic information exchange.

[0448] Step 1: BCA-1 can send a discovery request to BCC-1 on the same WTRU (in more general cases, BCC-1 may be hosted elsewhere), and the request may include the following parameters:

[0449] ● Purpose of Discovery: This will indicate the purpose of the discovery. In this case, the purpose is "BCA Registration". Therefore, BCF-1 knows that BCA-1 has just entered the system and intends to find its home BCF.

[0450] ● Identity Information: This parameter is used to display the identity of BCA-1, that is, to indicate who BCA-1 is. For example, if BCA-1 is provided with a pre-existing BCA_ID, it can indicate its BCA_ID in this parameter, so that this information can be used during discovery to identify the BCF to which BCA-1 belongs.

[0451] ● Registration Certificate: This parameter includes the basic information required for BCF to verify BCA-1 (such as the BCA-1 identifier).

[0452] ● Application Name: This indicates the name of the vertical application, such as smart manufacturing and logistics. BCA and its BNA share the same application name. This information can be used during discovery to identify the BCF to which BCA-1 belongs.

[0453] ● BNA ID: This indicates the identifier of the corresponding BNA for BCA-1. This information can be used during discovery to identify the BCF to which BCA-1 belongs.

[0454] Step 2: BCC-1 can send (forward) the request to BCF-1.

[0455] Step 3: BCF-1 may send a query request along with BCA-1's identification information to other BCFs. Typically, BCF-1 may request other peer BCFs to check their respective BNA registration repositories and identify whether BCA-1 is included in the "relevant BCA" of the vertical wireless application represented / registered by the BNA (e.g., BNA-1).

[0456] Step 4: BCF-2 can receive query requests from BCF-1 and can check its BNA registration store. Specifically, BCF-2 finds a match in the sense that BCA-1 is included in the “Relevant BCA” parameter representing a specific vertical wireless application. Alternatively, the identifier of BCA-1 meets the filtering criteria indicated in the “Relevant BCA” parameter, and the identifier of BCA-1 can refer to a BCA-ID (when the BCA can be provided in advance) or a manufacturing serial number (when the BCA has not yet been assigned a BCA-ID).

[0457] As a result, this means that BCA-1 is the client entity of this vertical application, while BCF-2 is the BCF to which BCA-1 belongs.

[0458] Step 5: BCF-2 can send its response back to BCF-1, indicating that BNA-1 has been identified in its BNA registry and that BCA-1 should register with BCF-2.

[0459] Step 6: BCF-1 can send a discovery response to BCC-1, indicating that BCF-2 has been identified and should be the home BCF of BCA-1. BCA-1 can then initiate the BCA registration process with BCF-2.

[0460] Step 7: BCC-1 can send (forward) a response to BCA-1.

[0461] The alternative process involves BCC-1 initiating a discovery request in step 1, and the detailed process is as follows: Figure 21 As shown. This applies when BCC-1 can serve multiple BCAs (such as BCA-1, BCA-2, BCA-3 on the same WTRU and served by the same BCC-1) and each of them intends to discover its respective home BCF. Therefore, BCC-1 can issue a single discovery request to BCF-1, which will identify multiple BCFs. In this case, Figure 20 Steps 3 to 5 shown can be performed multiple times (i.e., Figure 21 (Step 2 in the process), and each time a specific BCA is assigned a BCF.

[0462] Another way for a BCA to find its home BCF is by pre-providing the access address of its corresponding BNA to the BCA. The BCA can then contact its BNA to request a registration instruction from its home BCF. Therefore, the BNA can provide the BCA with the address of its home BCF. In this way, the BCA can locate its home BCF.

[0463] Representative BCF respondents found that the purpose of using blockchain services was to...

[0464] Figure 22 The BCF discovery process for the purpose of using blockchain services is shown.

[0465] Prerequisites: A BCC node (e.g., BCC-1) has discovered a BCF and has registered with it (e.g., BCF-1) based on the current location of the WTRU hosting BCC-1 and BCA-1. BCF-1 is the first contact BCF of BCA-1. BCA-1 may register with its home BCF (e.g., BCF-2).

[0466] Step 1: BCA-1 can send a discovery request to BCC-1, and the request may include the following parameters:

[0467] ● Purpose of Discovery: This will indicate the purpose of the discovery. In this case, the purpose is "utilization of blockchain services". Therefore, BCF-1 knows that BCA-1 can register with its parent BCF and now intends to use the blockchain service.

[0468] ● BCA ID: This parameter identifies the BCA. Generally, its parent BCF can assign a BCA ID during the BCA registration process.

[0469] ● Blockchain-related operation to be performed: This will indicate details about what type of blockchain operation will be performed.

[0470] ● Home BCF: This will indicate the home BCF of BCA-1 (e.g., BCF-2).

[0471] ● Current location: This indicates the current location of BCA-1.

[0472] Step 2: BCC-1 can send a request to BCF-1.

[0473] Step 3: BCF-1 can examine the request and may know that BCF-1 wants to use the blockchain service. BCF-1 can contact BCF-2 and let BCF-2 make a further decision. Optionally, BCF-1 may have some information about other BCFs in its vicinity, so BCF-1 can send information indicating one or more candidate BCFs for selection.

[0474] Step 4: BCF-1 can send a request to BCF-2, which carries information sent from BCA-1.

[0475] Step 5: BCF-2 can receive the request and perform the following processing:

[0476] ● Determine whether the operation requested by BCA-1 is allowed. This can be based on detailed information about the application logic processing obtained during BNA registration.

[0477] ● Identify which specific BCN managed by BCF-2 is responsible for providing blockchain operation services for BCA-1 (e.g., BCN-1). BCF-2 may identify the Affiliate Blockchain System ID (ABS-ID) of the blockchain system to which BCN-1 belongs.

[0478] ● Based on BCA-1's current location, it determines the appropriate BCF (e.g., based on its own information or some information sent from BCF-1, if BCF-1 has already sent a list of candidate BCFs in step 3), such as a potential BCF deployed near BCA-1 and possessing the necessary blockchain resources required by BCA-1 (e.g., hosting a BCN of the same type as BCN-1). BCF-2 can also determine that it is capable of and / or can serve BCA-1. In this case, it means that serving BCA-1 at this time does not require a visited BCF. If such a BCF-3 cannot be identified, BCF-2 can serve BCA-1 on its own.

[0479] Step 6: BCF-2 can send a service provision request to a potential BCF along with the following information:

[0480] ● BCA ID: This parameter indicates the identity of BCA-1.

[0481] ● Attached Blockchain System ID (ABS-ID): This indicates what type of blockchain system BCA-1 intends to use. For example, in the final step, it identifies the blockchain system that BCA should use with ABS-ID-1.

[0482] ● Blockchain operation to be performed: This will indicate details about what type of blockchain operation will be performed.

[0483] Step 7: BCF-3 can receive the request, check its BCN registry repository, and identify that one of the BCNs it manages (e.g., BCN-2) comes from the same blockchain system that BCA-1 intends to use. In other words, the affiliated blockchain system ID of BCN-2 is also ABS-ID-1. BCF-3 can then decide whether it can serve requests from BCA-1 to perform its blockchain-related operations.

[0484] Step 8: BCF-3 may confirm with BCF-2 that BCA-1 is able and / or may send its requests for blockchain-related operations to BCF-3 for processing.

[0485] Step 9: BCF-3 may confirm with BCF-1 that BCA-1 is able and / or may send its requests for blockchain operations to BCF-3 for processing.

[0486] Step 10: BCF-1 may confirm with BCC-1 that BCA-1 is able and / or may send its requests for blockchain operations to BCF-3 for processing.

[0487] Step 11: BCC-1 can confirm to BCA-1 that BCF-3 has been identified, and BCA-1 is able and / or may send its requests for blockchain operations to BCF-3 for processing.

[0488] In the above process, the assigned BCF finds the appropriate BCF (as shown in step 5). Alternatively, BCF-1 may retrieve basic information only from BCF-2 and enable BCF-1 to find the appropriate BCF for BCA-1. In this case, once BCF-1 identifies the appropriate BCF, step 6 can be performed by BCF-1.

[0489] Additionally, once the visited BCF (i.e., BCF-3) begins serving BCA-1, it can report service status / data / performance to BCA-1's home BCF and allow the home BCF to perform some administrative tasks, such as billing. The home BCF can collaborate with the visited BCF. For example, some access control processing may still have to be performed by the home BCF, while the visited BCF only performs blockchain-related processing. As another example, if the visited BCF is temporarily unable to provide certain blockchain operation services to BCA-1, such requests can still be sent to the home BCF for processing.

[0490] The alternative process involves BCC-1 initiating a discovery request in step 1, and the detailed process is as follows: Figure 23 As shown. This applies when BCC-1 can serve multiple BCAs (such as BCA-1, BCA-2, and BCA-3 on the same WTRU and served by the same BCC-1) and each of them intends to discover their respective visited BCFs. Therefore, BCC-1 can issue a single discovery request to BCF-1, which will identify multiple visited BCFs. In this case, Figure 22 Steps 3 through 9 shown can be performed multiple times (i.e., Figure 23 (Step 2 in the process), and find the desired BCF for each specific BCA.

[0491] Figure 23 An example of a BCF discovery (for the purpose of using blockchain services) (a discovery initiated by BCC) is shown.

[0492] Representative scenario 2: When BCA can only be associated with one BCF at a time

[0493] In this scenario, the following are examples of system settings and assumptions:

[0494] ● BCCs (e.g., BCC-1) on WTRU are not registered to BCF.

[0495] ● BCAs served by BCC-1 can register with BCF to use blockchain services.

[0496] ● A BCA can and / or may register with only one BCF or be associated with only one BCF at a time. Specifically, a BCA can or may always be associated with a BCF (e.g., BCF-1) to which its corresponding BNA has registered. If this is the case, it means that BCF-1 may always be the only BCF providing blockchain services for all BCAs and BNAs for specific vertical wireless applications. Alternatively, a decoupled approach can be adopted, where BCA-1 does not necessarily have to register with the same BCF registered by its corresponding BNA. Instead, BCA-1 can be associated with a different BCF (e.g., BCF-2), for example, BCF-2 may provide the same blockchain services as BCF-1 (e.g., the same type of BCN) and / or BCF-2 may be deployed closer to BCA-1.

[0497] ● BCC-1 only helps forward requests from the managed BCA to its target BCF.

[0498] In Scenario 2, BCF discovery is only used for BCA registration, meaning BCA-1 will find a qualified BCF for BCA registration. In other words, logical roles such as "first contact BCF," "home BCF," and "visited BCF" do not exist in Scenario 2.

[0499] Figure 24 The BCF discovery process for BCA registration purposes is shown in Scenario 2.

[0500] Step 1: BCA-1 can send a discovery request to BCC-1 on the same or different WTRUs, and the request can include the following parameters:

[0501] ● Identity Information: This parameter is used to display the identity of the BCA, that is, to indicate who BCA-1 is. For example, if BCA-1 is provided with a BCA ID in advance, it can indicate its BCA ID in this parameter so that this information can be used during discovery to identify the BCF to which BCA-1 can and / or can register itself.

[0502] If BCA-1 already knows the basic information of its corresponding vertical application (e.g., through prior provision or previous registration with another BCF), it can indicate the following information:

[0503] ● Application Name: This will indicate the name of the vertical application to which BCA-1 belongs.

[0504] ● Corresponding BNA ID: This will indicate who is the server BNA of BCA-1.

[0505] If BCA-1 already knows what type of blockchain service it needs (e.g., by pre-providing or by previously registering with another BCF), it can indicate the following information about the desired BCN it wants to use:

[0506] ● BCN Type: This will indicate the type of BCN selected to provide blockchain services to BCA-1 and its corresponding BNA (this is determined during the BNA registration process).

[0507] ● Registered BCF for the corresponding BNA: This will indicate the ID of the BCF that the corresponding BNA of BCA-1 has registered with (through the BNA registration process).

[0508] Step 2: BCC-1 can host a list of BCFs that stores available BCFs at the current location (such a list can be provided in advance or obtained through local BCF broadcasts received by BCC-1 at its current location).

[0509] Step 3: BCF-1 can send the query request along with the information indicated in Step 1 to other BCFs in the list (e.g., BCF-1).

[0510] Step 4: BCF-1 can receive the query request from BCC-1. Specifically, BCF-1 can manage BCNs of the same type used to serve BCA-1's corresponding BNA (as shown in the BCN type parameter in Step 1). Optionally, BCF-1 can first contact the registered BCF of BCA-1's corresponding BNA (as shown in the "Registered BCF of Corresponding BNA" parameter in Step 1) for more information. BCF-1 can decide that it wants to serve BCA-1 because it is able and / or can provide equivalent blockchain services to BCA-1.

[0511] Step 5: BCF-1 can send its response back to BCC-1 and indicate that it is willing to accept BCA-1's registration.

[0512] Step 6: BCF-1 can send a discovery response to BCC-1, indicating that BCF-1 has been identified.

[0513] Figure 25 An exemplary process for BCF discovery in Scenario 2 (for BCA registration / association purposes) is shown—initiated by BCC.

[0514] The alternative selection process involves BCC-1 initiating a discovery request, and the detailed process is as follows: Figure 25 As shown. This applies to situations where BCC-1 can serve multiple BCAs (e.g., BCA-1, BCA-2, and BCA-3 are served by the same BCC-1) and each of them wants to discover the desired BCF (remember, in scenario 2, each BCA can be associated with only one BCF at a time, but multiple BCAs can exist, and therefore each of them may need to identify the desired BCF). Therefore, BCC-1 can and / or can help find the desired BCF for each BCA. In this case, Figure 24 Steps 3 to 5 shown can be performed multiple times (i.e., Figure 25 Step 1 in the process, and each time find the desired BCF for a specific BCA. If there is a BCF that can and / or can serve all of these BCAs, then Figure 25 Step 1 in the process can be performed only once.

[0515] Scenario 3: When BCC can only be associated with one BCF at a time

[0516] In this scenario, we consider the following system setup and assumptions:

[0517] ● BCCs (e.g., BCC-1) can implement existing broadcast methods to discover available BCFs.

[0518] ● BCC-1 on WTRU can and / or may register to BCF only once (e.g., based on its current location).

[0519] ● BCC-1 may register with BCF at its own discretion (for example, BCC-1 may choose to register with BCF-1).

[0520] ● BCA does not need to register with BCF.

[0521] ● If BCF-1 manages the expected BCN of BCA-1, then any BCA served by BCC-1 (e.g., BCA-1) can use the blockchain services provided by BCF-1 (which is registered by BCC-1). Alternatively, if BCF-1 does not manage the expected BCN of BCA-1, then BCA-1 may request BCF-1 to communicate with the home BCF of its corresponding BNA, which hosts the expected BCN of BCA-1.

[0522] In scenario 3, BCC-1 can discover nearby available BCFs simply by broadcasting locally, and this process is not shown to save space.

[0523] BCC / BCA Registration

[0524] A BCA can register itself with a BCC and become a serving BCA of that BCC. Once a BCF is discovered, a BCC can register itself and / or the BCAs it serves with the BCF. Similarly, a BCA can register itself with a discovered BCF, which can be a regular BCF, a home BCF, or a visited BCF. Different system settings and assumptions can exist for BCC / BCA registration. Therefore, solutions for BCC / BCA registration are proposed in three scenarios, each with its own assumptions and settings.

[0525] Representative Scenario 1: When a BCA can be associated with multiple BCFs for different purposes

[0526] In Scenario 1, we consider the following system setup and assumptions:

[0527] ● A BCC-1 on WTRU can register with a BCF, which is the first contact BCF of the BCA served by the BCC-1 (e.g., based on its current location).

[0528] ● Any BCA served by BCC-1 (e.g., BCA-1) may register with its home BCF, which is the BCF to which its corresponding BNA registered.

[0529] ● In addition, any BCA served by BCC-1 (e.g., BCA-1) can register with a visited BCF, which can be a BCF at the edge or in other locations closer to BCA-1, and can provide BCA-1 with blockchain services equivalent to those of its home BCF.

[0530] This section discusses BCC registration and BCA registration:

[0531] ● BCC registration is registering a BCC with a BCF. Typically, the BCF is the first contact BCF of the BCA serving the BCC on the same WTRU (at its current location).

[0532] BCA registration has two types:

[0533] ● The first type of registration is BCA registering to its home BCF, which has already been identified in the home BCF discovery operation used for BCA registration purposes.

[0534] ● This second type of registration is used for BCA registration to the registered BCF for use of blockchain services, where the BCF has already been identified in the BCF discovery operation for the purpose of using blockchain services.

[0535] Representative BCC registration to first contact BCF

[0536] Figure 26 An exemplary BCC registration process is shown (e.g., in scenario 1).

[0537] Prerequisites: WTRU can host BCC-1, which can serve the upper-layer BCA. BCC-1 has identified a BCF (e.g., BCF-1) through pre-provisioning or local broadcasting and intends to register itself with that BCF. Note that for the upper-layer BCA, BCF-1 is their first contact BCF at their current location.

[0538] Step 1: BCC-1 can send a registration request to BCF-1, and the request may include the following parameters:

[0539] ● BCC ID: This is the identifier for the BCC ID. Generally, for a given BCC on the WTRU, it can have a globally unique BCC ID, or it can have a locally unique BCC ID used for the current first contact BCF. If BCC-1 already has a globally unique BCC ID (meaning it has been previously registered to another BCF or has a pre-provided BCC-ID), this parameter can indicate that BCC ID.

[0540] ○ Registration Certificate: This parameter includes the basic information required for BCF-1 verification and registration of BCC-1.

[0541] ○ Other basic information about BCC-1, such as:

[0542] ● Basic information about the managed WTRU, such as the WTRU's computing resources, communication capabilities, current location, mobility / route planning, and available batteries.

[0543] ● Communication capabilities: For example, how BCC-1 wants to communicate with BCF-1, such as via Wi-Fi, cellular, or local area network.

[0544] ● Information about the BCA it hosts: Optionally, the BCC-1 may carry certain information about the BCA it hosts. For example, it may carry the following information:

[0545] ○ A list of names or identifiers of BCAs hosted or serviced by BCC-1.

[0546] ○ If a BCA intends to register itself with its respective home / visited BCF, then a registration certificate will be issued for each BCA served by BCC-1.

[0547] ○ Each BCA has a corresponding BCF ID (which is identified during the BCF discovery phase).

[0548] ○ The corresponding BCF ID for each BCA (which was identified during the BCF discovery phase)

[0549] Note that if "information about the BCA being hosted" is included, this means that step 1 aims to initiate multiple types of registrations, namely:

[0550] ● Register BCC-1 itself with the first contact BCF, i.e., BCF-1

[0551] ● Register the BCA served by BCC-1 to its respective home BCF (Home BCF Registration) or its respective visited BCF (Visitor BCF Registration).

[0552] Step 2: BCF-1 can verify BCC-1 and create a registration record for BCC-1. If BCC-1 does not indicate its BCC ID, BCF-1 can assign a new BCC ID to BCC-1, which is either a global BCC ID or a locally unique ID.

[0553] Step 3. Optional Step. With the inclusion of "Information about the BCAs being hosted," BCC-1 may send separate registration requests to the home BCF and / or visited BCF for each BCA served by BCC-1, thereby registering the BCAs separately to their home / visited BCFs. This process can be combined with... Figure 27 or Figure 28 The process shown is the same.

[0554] Step 4: BCF-1 can send a response message to BCF-1 indicating successful registration of BCC-1, along with other useful information such as the assigned BCC ID. If the message includes "Information about the BCA being hosted," BCC-1 may also receive notification that the BCA has successfully registered with its corresponding home BCF or visited BCF and that an identifier has been assigned to each registered BCA.

[0555] The above process can and / or can be used to update the registration records of a BCC that has already registered with the first contact BCF. The difference is that step 1 can be a registration update request.

[0556] BCA registered to its parent BCF

[0557] BCA registration to the affiliated BCF can and / or can be done independently. Figure 27 An exemplary process for registering a BCA to its home BCF (e.g., in scenario 1) is shown.

[0558] Prerequisites: WTRU can host BCC-1, which can register with BCF-1. BCA-1 is hosted on top of BCC-1, and during the BCF discovery phase, BCA-1 can be identified as having BCF-2 as its home BCF. Note that for the upper-level BCA-1, BCF-1 is its first contact BCF at its current location.

[0559] Step 1: BCA-1 can send a registration request to BCC-1, and this request may include the following parameters:

[0560] ● BCA ID: If such an ID has been provided in advance, this is the identifier for BCA-1.

[0561] ● BCA Name: This will indicate the name of BCA-1.

[0562] ● Application Name: The name of the vertical application to which BCA-1 belongs.

[0563] ● Registration Certificate: This parameter includes the BCF attribution verification for BCA-1 and the basic information required for BCA-1 registration.

[0564] ● Name of the BCF: This will show the name of the BCF to which BCA-1 belongs.

[0565] ● BCF ID of the BCF to which BCF belongs: This will show the ID of the BCF to which BCA-1 belongs.

[0566] Step 2: BCC-1 can send the registration request to BCF-1.

[0567] Step 3: BCF-1 can analyze the request and can send the request to the BCF with the BCF ID indicated in the "BCF ID of the home BCF" parameter in step 1. In this case, the BCF-ID is, for example, BCF-2.

[0568] Step 4: BCF-2 can receive the request and verify the registration request sent from BCA-1. For example, BCF-2 can check its BNA registry repository and verify that BCA-1 is indeed a licensed BCA for a specific vertical application (corresponding to a BNA). BCF-2 can create a registration record for the successful registration of BCA-1 (i.e., BCF-2 can also host the BCA registry repository).

[0569] Step 5. BCF-2 can send a confirmation to BCF-1 that BCA-1 has successfully registered with its home BCF.

[0570] Step 6. BCF-1 can send this confirmation to BCC-1.

[0571] Step 7. BCC-1 can send this confirmation to BCA-1.

[0572] The above process can and / or can be used to update the registration records of a BCA that has already registered with its parent BCF. The difference is that step 1 can be a registration update request.

[0573] Representative BCA registered with surveyed BCF

[0574] If a BCA intends to use blockchain services provided by a surveyed BCF, the BCA may first register with the surveyed BCF. BCA registration with a surveyed BCF can be done independently, as discussed in this section. Figure 28 An exemplary process is shown for a BCA to register with its visited BCF (e.g., in scenario 1).

[0575] Prerequisites: WTRU can host BCC-1, which can register with BCF-1. BCA-1 is hosted on top of BCC-1 and can register with its home BCF (e.g., BCF-2). During the BCF discovery phase for using blockchain services in its current location, BCA-1 can be identified as BCF-3, which can be its visited BCF.

[0576] Step 1: BCA-1 can send a registration request to BCC-1 to register with BCF-3, and this request may include the following parameters:

[0577] ● BCA ID: This is the identifier for BCA-1.

[0578] ● BCA Name: This will indicate the name of BCA-1.

[0579] ● Registration Certificate: This parameter includes the BCF interviewee verification for BCA-1 and the basic information required for BCA-1 registration.

[0580] ● Name of the BCF to which BCA-1 belongs: This will show the name of the BCF to which BCA-1 belongs, for example, BCF-2.

[0581] ● BCF ID of the BCF to which BCF belongs: This will show the ID of the BCF to which BCA-1 belongs.

[0582] Step 2: BCC-1 can send the registration request to BCF-1.

[0583] Step 3: BCF-1 can analyze the request and send it to BCF-3.

[0584] Step 4: BCF-3 can receive the request and verify the registration request sent from BCA-1. For example, BCF-3 can contact BCF-2 (the BCF to which BCA-1 belongs) for more information about BCA-1. Alternatively, BCF-3 can also request BCC or BCA-1 to submit more information.

[0585] Step 5: BCF-3 intends to approve BCA-1's registration; therefore, it can send a request to contact BCF-2 for more information. When contacting BCF-2, BCF-3 can indicate its own capabilities, enabling BCF-2 to make a better decision regarding what actions should be taken with BCF-3.

[0586] Step 6: The attribution BCF (i.e., BCF-2) of BCA-1 can check the following information (assuming that the corresponding BNA of BCA-1 is BNA-1, and that detailed information about BNA-1 and its associated BCAs is stored in the BNA registration repository during the BNA registration process):

[0587] ● Check the application task list: This is a list of tasks related to the vertical application to which BCA belongs. In other words, these tasks constitute the application logic processing.

[0588] ● Specifically, each task has a corresponding workflow consisting of several actions. Each action is performed by one or more participants. For each action, BCF-2 can determine which actions BCF-3 should perform based on the following information stored in the BNA registry repository:

[0589] ○ Participant: This indicates who is the participant in the action. BCF-2 can reassess whether the participant is now the interviewee BCF-3, or whether the action can still be performed by BCF-2 itself.

[0590] ○ Executable Code: For each action, it can be implemented as a piece of executable software code, and as defined in the workflow, this code can be deployed to the corresponding participants. If the action will now be performed by the interviewee BCF, the corresponding code can also be deployed to the interviewee BCF.

[0591] ○ Transaction Format: In the case of an action that creates a blockchain transaction, this information will indicate what transaction needs to be created for that specific action, and the exact format of the transaction associated with that action. For example, the transaction format may include the following basic information:

[0592] ■ Vertical Application Name or BNA ID: This will indicate the name of a specific vertical application or the identifier of a specific vertical application or a pre-provided BNA-ID or a BNA-ID assigned by BCF.

[0593] ■ Task ID: This will indicate the identifier of the task. Alternatively, it can be (for example, also) a specific task name. In short, the information in this parameter will indicate which specific process the transaction to be created is associated with.

[0594] ■ Action ID: This will indicate the identifier of the action of the task. Alternatively, it can be (for example, also) a specific action name. In short, the information in this parameter will show which specific action / operation the transaction to be created is associated with.

[0595] ■ Participant ID: Generally, the participant ID represents the identifier of the participant. It can be the participant's ID, the participant's specific name, the participant's unique serial number, the participant's MAC address, manufacturing serial number, etc. In this case, the participant is usually a BCF (Blockchain Functional Provider), as it is primarily the BCF that can interact with the underlying BCN to insert new transactions into the blockchain.

[0596] ■ Transaction creation time

[0597] ■ Other application-specific data

[0598] ○ If a blockchain transaction is to be created at the interviewed BCF, the interviewed BCF may also need to know the transaction format.

[0599] ● Generally, BCF-2 can examine each action and decide whether it should still be performed by the underlying BCF (i.e., BCF-2 itself) or by BCF-3. On one hand, if the visited BCF (i.e., BCF-3) can perform a specific action, BCF-2 can inform BCF-3 of the details of that action. For example, BCF-2 can decide that instead of having BCF-2 assist BCA-1 in interacting with the blockchain system, BCA-1 can and / or can use BCF-3 (i.e., its visited BCF), because BCF-3 can also manage BCNs of the same type managed by BCF-2 and serving BCA-1. On the other hand, after assessing BCF-3's capabilities, BCF-2 can decide that BCF-3 may not provide the desired blockchain services to BCA-1 and therefore reject BCF-3's request to serve BCA-1.

[0600] Step 7: BCF-2 informs BCF-3 of detailed instructions on how to service BCA-1. For example, this may include the following information:

[0601] ● List of tasks involved in BCA-1.

[0602] ● Workflow for each task.

[0603] ● Actions required for BCF-3 (based on the reassessment in step 6).

[0604] ● Any executable code required to perform the action.

[0605] ●

[0606] Step 8: BCF-3 performs certain configurations and creates a registration record for BCA-1.

[0607] Step 9. BCF-3 may send a confirmation to BCF-1 of successful registration with BCA-1 (as its visited BCF).

[0608] Step 10. BCF-1 can send this confirmation to BCC-1.

[0609] Step 11. BCC-1 can send this confirmation to BCA-1.

[0610] The above process can and / or can be used to update the registration records of BCAs that have already registered with their visited BCFs. The difference is that step 1 can be a registration update request. If BCA-1 no longer wishes to use the blockchain services provided by the visited BCF, it can also send a registration revocation request to the visiting BCF.

[0611] Representative scenario 2: When BCA can only be associated with one BCF at a time

[0612] In this scenario, we consider the following system setup and assumptions:

[0613] ● BCCs (e.g., BCC-1) on WTRU are not registered to BCF.

[0614] ● BCAs served by BCC-1 can register with BCF to use blockchain services.

[0615] ● A BCA can only register with or be associated with one BCF at a time. Specifically, a BCA can always be associated with a BCF (e.g., BCF-1), to which its corresponding BNA is registered. If this is the case, it means that BCF-1 may always be the only BCF providing blockchain services for all BCAs and BNAs for specific vertical wireless applications. Alternatively, a decoupled approach can be adopted, where BCA-1 does not necessarily have to register with the same BCF registered by its corresponding BNA. Instead, BCA-1 can be associated with a different BCF (e.g., BCF-2), for example, BCF-2 providing the same blockchain services as BCF-1 (e.g., the same type of BCN) and / or BCF-2 being deployed closer to BCA-1.

[0616] ● BCC-1 only helps forward requests from the managed BCA to its target BCF.

[0617] In Scenario 2, BCF discovery is only used for BCA registration, meaning BCA-1 will find a qualified BCF for BCA registration. In other words, logical roles such as "first contact BCF," "home BCF," and "visited BCF" do not exist in Scenario 2.

[0618] Figure 29 An exemplary process for registering a BCA with a BCF is shown (in Scenario 2).

[0619] The process of BCA registering with its parent BCF is as follows: Figure 29 As shown.

[0620] Prerequisites: WTRU can host BCC-1. BCA-1 is hosted on top of BCC-1, and during the BCF discovery phase, BCA-1 can be identified as BCF-1 in its current location. The corresponding BNA for BCA-1 is BNA-1 registered with BCF-2.

[0621] Step 1: BCA-1 can send a registration request to BCC-1, and this request may include the following parameters:

[0622] ● BCA ID: If such an ID has been provided in advance, this is the identifier for BCA-1.

[0623] ● BCA Name: This will indicate the name of BCA-1.

[0624] ● BNA ID: This will show the ID of the corresponding BNA (e.g., BNA-1).

[0625] ● Registration Certificate: This parameter includes the BCF attribution verification for BCA-1 and the basic information required for BCA-1 registration.

[0626] ● The name of the BCF registered by its corresponding BNA: This will show the name of the BCF registered by BNA-1.

[0627] ● BCF ID of the BCF registered by its corresponding BNA: This will show the ID of the BCF registered by BNA-1 (e.g., BCF-2).

[0628] ● The name and / or BCF ID of the last registered BCF: This will show the last BCF registered by BCA-1 if BCA-1 has previously registered with another BCF.

[0629] Step 2: BCC-1 can send the registration request to BCF-1.

[0630] Step 3: BCF-1 can analyze the request and send a query request to BCF-2 for verification (based on the "BCF ID of the BCF registered by its corresponding BNA" parameter in Step 1). Alternatively, BCF-1 can also send the query request to the last BCF registered by BCA-1 (based on the "Name and / or BCF ID of the last registered BCF" parameter in Step 1).

[0631] Step 4: BCF-2 can receive the request and verify the registration request sent from BCA-1. For example, BCF-2 can check its BNA registration repository and verify that BCA-1 is indeed a licensed BCA for a specific vertical application (identified by BNA-1).

[0632] Step 5. BCF-2 may send BCF-1 confirmation that BCA-1 has been verified. If the last BCF registered by BCA-1 (e.g., BCF-3) has completed verification, BCF-3 may move information related to BCA-1 from BCF-3 to BCF-1 (if the information can be reused).

[0633] Step 6. BCF-1 can send this confirmation to BCC-1. BCF-1 can then create a registration record for BCA-1 and prepare to provide blockchain services to BCA-1.

[0634] Step 7. BCC-1 can send this confirmation to BCA-1.

[0635] Figure 30 An exemplary process for BCF registration in Scenario 2 is shown—initiated by BCC.

[0636] The alternative selection process involves BCC-1 initiating a discovery request, and the detailed process is as follows: Figure 30 As shown. This applies when BCC-1 can serve multiple BCAs (such as BCA-1, BCA-2, BCA-3) and each of them intends to register with a desired and potentially different BCF. Therefore, BCC-1 can and / or can help find the desired BCF for each BCA. In this case, Figure 29 Steps 2 through 6 shown can be performed multiple times (i.e., Figure 30 Step 1 in the process, and each time it involves registering a specific BCA to the desired BCF. If there is one BCF capable of serving all of these BCAs, then Figure 30 Step 1 in the process can be performed only once.

[0637] Scenario 3: When BCC can only be associated with one BCF at a time

[0638] In this scenario, we consider the following system setup and assumptions:

[0639] ● BCCs (e.g., BCC-1) can implement existing broadcast methods to discover available BCFs.

[0640] ● A BCC-1 on a WTRU can only be registered to a BCF at a time (e.g., based on its current location).

[0641] ● BCC-1 may register with BCF at its own discretion (for example, BCC-1 may choose to register with BCF-1).

[0642] ● BCA does not need to register with its corresponding BNA, which hosts the expected BCN of BCA-1.

[0643] ● If BCF-1 manages the expected BCN of BCA-1, then any BCA served by BCC-1 (e.g., BCA-1) can use the blockchain services provided by BCF-1 (which is registered by BCC-1). Alternatively, if BCF-1 does not manage the expected BCN of BCA-1, then BCA-1 may request BCF-1 to communicate with the home BCF of its corresponding BNA, which hosts the expected BCN of BCA-1.

[0644] Figure 31 An exemplary process for registering a BCC to a BCF is shown (in Scenario 3). The process for registering a BCC to a BCF is as follows: Figure 29 As shown.

[0645] Prerequisites: BCC-1 can serve multiple BCAs (e.g., BCA-1), and the corresponding BNA for BCA-1 is BNA-1 registered with BCF-2.

[0646] Step 1: BCC-1 can send a registration request to BCF-1, and the request may include the following parameters:

[0647] ● BCC ID: If such an ID has been provided in advance, this is the identifier for BCC-1.

[0648] ● BCC Name: This will indicate the name of BCC-1.

[0649] ● The name and / or BCF ID of the last registered BCF: This will show the last BCF registered by BCC-1 if BCC-1 has previously registered with another BCF.

[0650] ● List of BCAs Hosted: This will show a list of BCAs served by BCC-1.

[0651] ● For each BCA (e.g., BCA-1), include the following information:

[0652] ○ BNA ID: This will show the ID of the corresponding BNA (e.g., BNA-1).

[0653] ○ Name of the BCF registered by its corresponding BNA: This will display the name of the BCF registered by BNA-1.

[0654] ○ BCF ID of the BCF registered by its corresponding BNA: This will show the ID of the BCF registered by BNA-1.

[0655] Step 2: BCF-1 can verify BCC-1. If BCC-1 has previously registered with a previous BCF (e.g., BCF-2), BCF-1 can move BCC-1's relevant information from BCF-2 to BCF-1 (if the information can be reused).

[0656] Step 3: For each BCA (e.g., BCA-1), it does not need to register with the BCF. Instead, it can interact directly with the BCF registered by its corresponding BNA (e.g., BNA-1). For example, in this step, BCF-1 can send a notification to BCF-2, which is registered by BNA-1, and notify it that BCA-1 is now online.

[0657] Step 4: BCF-2 can receive the request and verify BCA-1. For example, BCF-2 can check its BNA registry repository and verify that BCA-1 is indeed a licensed BCA for a specific vertical application (corresponding to a BNA).

[0658] Step 5. BCF-2 may send BCF-1 confirmation that BCA-1 has been verified. BCF-2 may indicate to BCA-1 the desired type of BCN to be used (which is determined during the BNA registration process).

[0659] Step 6. BCF-1 can check the BCNs it manages to see if they have the desired type of BCN that will be used by BCA-1. If so, BCF-1 can directly provide blockchain services to BCA-1. Otherwise, for any blockchain-related service requests sent from BCA-1, BCF-1 can forward the request to BCF-2 for processing.

[0660] Note that steps 3 through 6 can be performed multiple times for each BCA served by BCC-1.

[0661] Step 7. BCF-1 can send this confirmation to BCC-1.

[0662] Representative BCA registered with BCC

[0663] In the preceding sections, the registration process primarily involved registering the BCA / BCC to the BCF. The BCA can register to the BCC in order to use the BCC to communicate with other BCFs via the BCC (especially when the BCA and BCC are not hosted on the same WTRU / device).

[0664] Figure 32 An exemplary process for registering a BCA with a BCC is shown.

[0665] Prerequisite: BCA-1 has discovered BCC-1 and intends to register with BCC-1.

[0666] Step 1: BCA-1 can send a registration request to BCC-1, and this request may include the following parameters:

[0667] ● BCA-ID: If such an ID is provided in advance, this is the identifier for BCA-1. If BCA-ID is unavailable, BCA-1 can provide its manufacturing serial number.

[0668] ● BCA Name: This will indicate the name of BCA-1.

[0669] ● Application Name: The name of the vertical application to which BCA-1 belongs.

[0670] ● Registration Certificate: This parameter includes the basic information required for BCC-1 verification and BCA-1 registration.

[0671] If BCA-1 wants to request BCC-1 to help it register with BCA-1's home BCF, it can include the following information:

[0672] ● Name of the BCF: This will show the name of the BCF to which BCA-1 belongs.

[0673] ● BCF ID of the BCF to which BCF belongs: This will show the ID of the BCF to which BCA-1 belongs.

[0674] ● Blockchain Application Requirements: This indicates some of the blockchain system requirements that BCA-1 may have. For example, BCA-1 may need to interact with private or public blockchains. Furthermore, this parameter can indicate BCA-1's performance requirements for the blockchain system, such as transaction creation speed.

[0675] ● BNA-ID: If BCC-1 already knows its BNA, it can indicate the identifier of that BNA to BCC-1.

[0676] Step 2: BCC-1 can receive the request and verify the registration request sent from BCA-1. If BCA-1 wants BCC-1 to help it register with BCA-1's home BCF, BCC-1 can decide whether to agree to do so. For example, if BCC-1 has not yet registered itself with any BCF, BCC-1 can choose to help BCA-1 register with BCA-1's home BCF during its own BCF registration period (see...). Figure 26 (Step 3 in the process). If the request from BCA-1 in Step 1 is verified and approved, BCC-1 may assign a BCA-ID to BCA-1. BCC-1 may maintain a BCA repository to record all successfully registered BCAs. The BCA repository may include a BCA record for each registered BCA. Each BCA record may describe the registered BCA and may include some of the parameters included in Step 1.

[0677] Step 3. BCC-1 can send a confirmation to BCA-1 of BCA-1's successful registration, and BCC-1 now acts as a client middleware entity providing blockchain-related functions to BCA-1. Optionally, if BNA-ID is included in step 1, BCC-1 can send a notification to the BNA represented by BNA-ID, informing it that BCA-1 has been registered with BCC-1.

[0678] Representative BCF interactions

[0679] Representative BCF-to-BCF communication

[0680] Some communication between BCFs is proposed. As mentioned earlier, there can be multiple BCFs in the system, and each BCF serves a specific geographic region. For a given BCF, it can manage a list of underlying BCNs, and each BCN comes from a specific blockchain system. When the system is running, the BCFs can periodically communicate with each other to exchange useful information such as BNA registry repositories, BCA registry repositories, and BCN registry repositories. Such information exchange can facilitate other operations, such as BNA registration, BCC registration, BCA registration, BCF discovery, etc.

[0681] Figure 33 An exemplary process for communication between BCFs is shown.

[0682] Prerequisites: The two BCFs are aware of each other (either through pre-configuration / pre-providement or discovery via public / shared repositories / directories). For example, in a 5GS context, a BCF can be implemented as a 5G control plane network function. Each BCF can register itself with the NRF. A first BCF can and / or can find a second BCF from the NRF. Afterward, the two BCFs can begin communicating with each other to discover more BCFs directly without entering the NRF.

[0683] Step 1: BCF-1 can send a request to BCF-2, and this request can take different forms, such as (a non-exhaustive list):

[0684] ● The request can be a BCF network topology discovery request. In this case, two BCFs can communicate with each other about their known peer BCFs (e.g., BCF-1 knows and connects to two other BCFs, namely BCF-5 and BCF-6. BCF-2 knows and connects to three other BCFs, namely BCF-9, BCF-10, and BCF-11). Through this periodic discovery, BCFs can gradually learn about all other peer BCFs in the system and the network topology between BCFs.

[0685] ● The request can be a BNA information exchange request. In this case, two BCFs can communicate with each other about information stored in their BNA registration repositories. For example, through this periodic information exchange, BCFs can quickly determine which BCF is the home BCF for a given / new BCA to be registered.

[0686] ● The request can be a BCA information exchange request. In this case, two BCFs can communicate with each other about information stored in their BCA registration repositories. For example, through this periodic information exchange, BCFs can quickly determine which BCF is the home BCF for a given BCA to be registered.

[0687] ● The request can be a BCN information exchange request. In this case, two BCFs can communicate with each other about information stored in their BCN registration repositories. For example, through this periodic information exchange, BCFs can quickly determine which BCFs are managing the BCNs of a particular blockchain system.

[0688] ● A request can be an action assignment request. In this case, a BCF can request another BCF to perform a specific action. For example, BCF-1 can request another BCF-2 to help store a transaction in a BCN managed by BCF-2.

[0689] ● The request can be a subscription request. In this case, BCF-1 may be interested in certain events or information that can be captured by another BCF-2. Therefore, BCF-1 can subscribe to BCF-2 and receive notifications.

[0690] ● The request can be a request for exchanging management-related information. For example, in a scenario where the BCA can and / or may have a home BCF and a visited BCF, once the visited BCF begins serving the BCA, the visited BCF can report service status / data / performance to the home BCF and enable the home BCF to perform some management tasks, such as billing.

[0691] Step 2: Depending on the different situations listed in Step 1, BCF-2 can perform certain processing.

[0692] Step 3: Based on the different scenarios listed in Step 1, BCF-2 can send back the corresponding response. For example (non-exhaustive list):

[0693] ● Response to a previous BCF network topology discovery request. In this case, the response may include a list of peer / neighboring BCFs.

[0694] ● Response to a previous BNA information exchange request. In this case, they may exchange any information, such as information stored in their BNA registry repository.

[0695] ● A response to a previous BCA information exchange request. In this case, the response may include information stored in their BCA registry repository.

[0696] ● A response to a previous BCN information exchange request. In this case, the response may include information stored in their BCN registration repository.

[0697] ● Response to a previous action assignment request. In this case, BCF can receive confirmation of whether the action was successfully assigned.

[0698] ● Response to a previous subscription request. In this case, BCF-1 can receive confirmation of whether the subscription was successful. Specifically, if successful, BCF-1 can receive subsequent notifications as a result of the subscription.

[0699] Representative BCN-to-BCN communication via BCF

[0700] BCFs can and / or manage a list of underlying BCNs. Specifically, for two (or more) different BCFs, each BCF can manage a specific BCN, and the two BCNs can originate from the same blockchain system. While two BCNs typically communicate with each other via a P2P network within the underlying blockchain system, this disclosure proposes a novel approach for two BCNs to communicate via an overlay network between BCFs. This is a new functionality or value-added service provided by the BCFs. In the proposed method, not all communication / interaction between two BCNs must rely on a P2P network within the underlying blockchain system. Instead, they can rely on BCFs to exchange information via a communication channel between BCFs, which may not use the same communication medium used in the underlying blockchain network.

[0701] Figure 34 An exemplary process for communication between BCNs via BCF is shown.

[0702] Prerequisites: BCF-1 can manage BCN-1 from the underlying blockchain system A, and BCF-2 can manage BCN-2, which also comes from the same underlying blockchain system A. BCF-1 and BCF-2 periodically exchange information with each other.

[0703] Step 1: BCN-1 intends to send a message to BCN-2, primarily for the underlying blockchain system A. Note that this type of message can be any message used within the underlying blockchain system and initially sent via the P2P network in underlying blockchain system A. However, BCN-1 now intends to send this message to BCN-2 via the communication channel between BCFs. This message can carry all possible parameters used in underlying blockchain system A. Therefore, the message can be encapsulated in the payload of a request sent from BCN-1 to BCF-1. BCN-1 may only need to indicate that the message is addressed to BCN-2, which is currently managed by BCF-2.

[0704] Step 2: BCF-1 can receive the request, and it can add some additional data to the request, which will then be sent to BCF-2 (in other words, the additional data is piggybacked). BCF-1 can send the request to BCF-2.

[0705] Step 3: BCF-2 can receive the request and then extract the data destined for it (sent from BCF-1). Afterward, BCF-2 can pass the request (containing only the data from BCN-1) to BCN-2.

[0706] Step 4: BCN-2 can receive the request and extract the original message from the request's payload. BCN-2 can perform certain processing defined by the underlying blockchain system A.

[0707] Step 5: BCN-2 can send a response to BCF-2 to convey the request. Similarly, the processing result of BCN-2 can be encapsulated in the payload of the response message.

[0708] Step 6: BCF-2 can send the response to BCF-1 to pass on the request. BCF-2 can also confirm to BCF-1 that the data sent from BCF-1 has also been passed on to BCF-2.

[0709] Step 7: BCF-1 can receive the response and know that its own data has been transmitted to BCF-2. BCF-1 can send the response to BCN-1, and BCN-1 can retrieve the processing result sent from BCN-2.

[0710] Although the above process uses the example of BCN-1 and BCN-2 being managed by two different BCFs (i.e., BCF-1 and BCF-2), the proposed process can be used when BCN-1 and BCN-2 are managed by the same BCF.

[0711] In summary, communication between BCFs can and / or supports the following scenarios:

[0712] ● When BCN-1 (managed by BCF-1) wants to send a message to BCN-2 (managed by BCF-2), BCN-1 can send the message to BCF-1, and the message can pass through BCF-2 before reaching BCN-2. Specifically, at BCF-1, it can add additional data to the original message request, and this data will be passed to BCF-2 or any other intermediate BCF on the way to BCF-2. In short, in this scenario, BCF-1 can piggyback some data from the original message sent from BCN-1, and this data has already been... Figure 34 This scene is shown in the image.

[0713] ● As BCF-1, if it wants to send certain messages to another BCF-2, BCF-1 can query the BCNs it manages to see if any BCNs want to send data to any BCN managed by BCF-2 (or any BCF en route to BCF-2). If so, BCF-1 can request the BCNs to submit their data to BCF-1. At BCF-1, it can integrate all data together in the message request, i.e., data from its managed BCNs (the destination of such data is the BCN) and data from itself (the destination of such data is the BCF, such as BCF-2). BCF-1 can issue this message, and as the message propagates from BCF-1 to BCF-2 within the BCF overlay network, the data can be delivered to both the destination BCF and the destination BCN.

[0714] ● When BCN-1 (managed by BCF-1) intends to send data to another BCN-2 (managed by BCF-2) relying on BCF-1, BCF-1 can examine the data and collect useful information when permitted. For example, by examining messages from the underlying blockchain system, BCF-1 can perform certain statistics or analyses, such as the average size of messages used in the underlying blockchain system, which BCNs have the most blocks created and confirmed, etc.

[0715] Representative strategy management

[0716] As described in the preceding sections, a policy can be viewed as a type of configuration data discussed in the BNA registry. Policy deployment and policy management can be considered as two policy-related actions, collectively referred to as policy management.

[0717] Representative strategy deployment

[0718] There are different types of policies. For example, some policies might involve how to utilize the BCN. In this case, deploying the policy to the BCF might make sense, as the BCF is the managing entity of the BCN. Another scenario is that some policies might involve the communications infrastructure, for example, how much bandwidth should be allocated to send blockchain transactions from the BCA (creating transactions) to the BCN (storing these transactions in the blockchain system) for a given application-specific action. In this example, it might be desirable for such policies to be stored within the communications infrastructure, making it possible and / or convenient for policy management, since it is the communications infrastructure (such as a 3GPP network) that ultimately allocates, monitors, and regulates the bandwidth between the BCA and the BCF / BNA. Another example is that, to enforce a policy, it might be necessary to collect certain data from or have certain data provided by the communications infrastructure. In this case, it would be desirable to deploy such policies directly within the communications infrastructure.

[0719] Figure 35 An exemplary process for policy deployment is shown.

[0720] Step 1: The policy creator (e.g., BNA-1) can send a request to the policy deployer to deploy the policy. For example, this step can be performed through the previous BNA registration process (i.e., Figure 18 Step 1) is implemented whereby BNA-1 can send a registration request to BCF. Specifically, in this registration request, BNA includes all necessary information about the business logic processing, such as a task list, the workflow for each task, each action in the workflow, and the corresponding participant. Here, actions can be related to policies.

[0721] Step 2: The policy deployer can analyze the request and determine who the policy enforcer is. Continuing with the previous example related to BNA registration, during BNA registration to the BCF, the BCF is the policy deployer, and the BCF can determine who will be the policy enforcer. For example, the BCF can decide whether a specific policy should be deployed in the 3GPP network, in the BCN, and / or simply on the BCF itself.

[0722] Step 3: The strategy deployer deploys the strategy to the strategy executor. The strategy executor is the person who will execute the strategy.

[0723] Step 4. The policy enforcer can receive the policy and agree to execute it when necessary.

[0724] Step 5. The policy enforcer can send a response to the policy deployer.

[0725] Step 6. The policy deployer can send a response to the policy creator.

[0726] Note that the entities mentioned above, such as policy creator, policy deployer, and policy enforcer, are logical roles and can be assumed by different real entities. For example, the policy creator can be BNA or BCF, the policy deployer can be BCF, and the policy enforcer can be BCN, BCF itself, and / or a 3GPP network function.

[0727] Another alternative process is that the policy creator can directly create policies and deploy them to the policy executor.

[0728] The above process can and / or can be used to update already deployed policies. The difference is that step 1 can be a policy update request that includes the updated policy content and the corresponding policy ID.

[0729] Representative strategy management

[0730] Policy management is the management of policies, such as the policy applied to a deployment. The following policy management process and the entities involved are discussed. These entities are logical entities, not physical entities; therefore, actual physical entity instances can and / or may act as multiple different logical entities.

[0731] 1. The strategy has been deployed to the strategy executor. For example, the strategy could be related to how to use the blockchain services provided by BCF. For instance, for a given BCA, it could require BCF to store a certain number of transactions in the desired BCN within a given time period, the maximum data size of each transaction, and so on.

[0732] 2. A strategy management initiator can send triggers to a strategy executor based on certain inputs to initiate strategy management. For example, BNA or BCA can be a strategy management initiator, and it can send triggers to BCF to initiate blockchain-related strategies. The strategy management initiator can also be a strategy executor.

[0733] a. For example, a policy management initiator can retrieve / collect some data and send that data (as a trigger) to a policy enforcer to initiate policy management. For example, a BNA can send its own data to a BCF, which acts as the policy enforcer. Alternatively, a BNA can request the BCF to collect certain relevant data from the communications infrastructure.

[0734] 3. Based on this data input, the policy executor begins executing the policy upon receiving a trigger. The result is that certain executable operational rules can be generated by applying this policy to the data input. For example, the BCF (as the policy executor) can execute the policy and create specific operational rules, such as blockchain transaction creation rules, blockchain transaction size control rules, BCN access control rules, etc.

[0735] 4. The policy executor can send the generated executable operation rules to one or more operation execution entities, which can be BCNs, other BCFs, or NFs in the 3GPP system. It is worth noting that for a given BCF, it can be not only a policy executor, but also an operation execution entity used to perform blockchain-related operations (because both policy executors and operation execution entities are logical roles).

[0736] 5. The operation execution entity receives these operation rules and applies them when executing their corresponding operations. For example, when an application (such as BCA or BNA) sends a request to BCF for a specific blockchain-related operation, BCF can use previously generated policy rules to decide whether to allow the operation or meet certain requirements.

[0737] Figure 36An exemplary process for policy execution is shown.

[0738] Step 1: The policy management initiator can send a data collection request to the data repository.

[0739] Step 2: The data repository returns the data to the policy management initiator.

[0740] Step 3: The policy initiator can send the policy trigger, the data collected in Step 2, and the ID of the policy to be executed to the policy executor. If data collection is not required, steps 1 to 3 can be skipped.

[0741] Alternatively, a policy enforcer can be triggered to apply a policy based on certain events monitored by the policy enforcer. Furthermore, the enforcer can collect certain data itself, which will be used when executing the policy.

[0742] Step 4: The policy enforcer can verify the request and decide whether to execute the policy as requested. If so, the policy enforcer begins to execute the policy, for example by applying the policy along with the required data input.

[0743] Step 5: As a result of executing this strategy, the strategy executor can formulate a set of operational rules. The strategy executor can determine who the operational execution entities are. The generated operational rules can be deployed to the operational execution entities.

[0744] Step 6: The policy enforcer can send the generated operation rules to one or more operation execution entities.

[0745] Step 7: The operation execution entity receives these operation rules and begins to execute these rules in the corresponding operation when needed.

[0746] Step 8: The operation execution entity sends an acknowledgment to the policy executor.

[0747] Step 9. The policy enforcer can send a response to the policy management initiator.

[0748] It is worth noting that the policy deployment and policy management processes can and / or may also be triggered by other types of requests. For example, a BNA registration request to BCF can also trigger... Figure 35 and Figure 36 The diagram illustrates the strategy deployment and management process. In this case, BNA acts as both the strategy creator and the strategy management initiator.

[0749] Representative Blockchain Application Enabler Architecture in 5G System Architecture

[0750] Figure 37This document illustrates an implementation scheme for blockchain-related logical entities within a 5G and above system architecture. The core network refers to the 5G core network or a future wireless core network.

[0751] ● The BCF can be implemented as a new Control Plane Network Function (NF) or Application Function (AF). The BCF can reside in the core network or the edge network. The BCF can interact with existing core network functions. For example, the BCF can register itself with the NRF, allowing it to discover other network functions or be discovered by other network functions. The BCF can use AUSF to authenticate any blockchain-related requests or messages received from the WTRU (i.e., from the BCA / BCC). The BCF can use the PCF to check for any blockchain-related policies (where the policy will be executed by the PCF). The BCF can use UDR or UDSF to store some blockchain-related policies. Driven by the NEF, the BCF may be accessible and accessible to third parties. The BCF can use NWDAF to analyze transactions and / or other characteristics of the blockchain.

[0752] ● BCF can also be implemented as part of existing network functions such as NEF or AUSF.

[0753] ● A BCN can be a new network function provided by a third party, either within or outside the core network. If the BCN is provided by a third party, the BCF can access the 3GPP core network via the NEF.

[0754] ● The BNA can be implemented as a server network function entity corresponding to a specific vertical wireless application. If the BNA is provided by a third party, it cannot interact directly with the BCF, but rather interacts with the BCF via the NEF (in the case where the BCF is deployed in the core network of a 3GPP network).

[0755] ● BCA and BCC can be implemented within the WTRU. Alternatively, a restricted WTRU (such as a narrowband IoT device) can host only the BCA, and the BCC can be hosted by other robust WTRUs such as vehicles, gateways, and edge servers.

[0756] Alternatively, in the context of 5G and above system architecture, there may be other possible implementation schemes for the proposed blockchain-related logical entities, as listed below:

[0757] ● The BCC can also be deployed at the AMF. In this way, one BCC can serve multiple BCAs hosted by the WTRU. A potential benefit is that it simplifies the implementation of the WTRU in the sense that the WTRU only needs to install specific vertical applications. Since the BCC can be deployed with the AMF, and the WTRU does not have to run tasks related to the blockchain-related operations to be performed by the BCC, it can also save some computing resources for the WTRU. In this case, most of the communication between the BCA and BCC can be achieved through the N1 reference point, and the parameters for BCA-BCC communication proposed in this disclosure can also be carried through messages on the N1 reference point.

[0758] ● Another possible implementation is that the proposed BCF can be implemented by the AMF. In other words, the proposed BCF is a new value-added service provided by an existing AMF. In this case, all the proposed processes and new parameters related to the BCF can be associated with the AMF in the 5G system.

[0759] ● Furthermore, any current network function (e.g., AMF) may need to interact directly with the BCF to utilize services provided by the BCF. Finally, the BNA function can be implemented within the network function; therefore, a network function with an embedded BNA can interact directly with the BCF. The interaction between the BNA and the BCF proposed in this disclosure can be implemented as a novel process between the current network function and the BCF.

[0760] Figure 39 Several scenarios / options for deploying the proposed blockchain-related entities in 5G and above system architectures are described. Similarly, the core network refers to the 5G core network or a future wireless core network.

[0761] ● In Figure 39 In (a), BCA and BCC are implemented within the WTRU. Therefore, the interface between BCA and BCC is compressed into the internal API. Both BCF and BCN are implemented as core network functions, while BNA is implemented as a network application that can be used within or outside the core network. This type of deployment can be viewed as a deployment implementation scheme for scenarios 2 and 3 discussed in BCF discovery and BCC / BCA registration.

[0762] ● In Figure 39In (b), there are edge networks, relay nodes, and / or microcell networks between the WTRU and the core network. The BCA is still implemented within the WTRU, but the edge network (or relay node / microcell) hosts the BCC. The core network still hosts the BNA, BCF, and BCN. The BCA on the WTRU uses the BCC to interact with the BNA, BCF, and BCN in the core network. This type of deployment can be viewed as a deployment implementation of scenarios 2 and 3 discussed in BCF discovery and BCC / BCA registration.

[0763] ● In Figure 39 In (c), an edge network, relay nodes, and / or microcell network exist between the WTRU and the core network. This type of deployment can be viewed as a deployment implementation of scenarios 1, 2, and 3 discussed in BCF discovery and BCC / BCA registration. In scenario 1, the BCA and BCC are still implemented within the WTRU. The core network hosts BNA, BCF1, and BCN1. Additionally, an edge network (or relay node / microcell) hosts another BCF2 and BCN2. A BCC on the WTRU can communicate directly with BCF1 (i.e., in scenario 2, BCF1 is the WTRU's home BCF) or indirectly with it via BCF2; a BCC can (e.g., can only) communicate with BCF2 (i.e., in scenario 1, BCF2 is the WTRU's first contact or visited BCF) because it is located closer to the WTRU. Communication between BCFs is also shown in this case. For scenarios 2 and 3, we can have the following deployment, for example: the BCC on the WTRU can communicate directly or indirectly with BCF1 via BCF2 (i.e., in scenario 2, BCF1 is the registered BCF of BCA-1, and BCF2 is the registered BCF of the corresponding BNA of BCA-1). The BCC can (e.g., can only) communicate with BCF2 (in scenario 3, BCF-2 is the registered BCF of the BCC) because it is located closer to the WTRU.

[0764] ● In Figure 39 In (d), WTRU hosts not only BCA / BCC but also BCF2. The edge network (or relay node / microcell) hosts only BCN2. The core network still hosts BNA, BCF1, and BCN1. To access the blockchain, WTRU can communicate directly with BCN2 using BCF2, or allow BCF2 to indirectly access BCN1 via BCF1 in the core network. Communication between BCFs is also shown in this case. Similar to case 3, this type of deployment can be considered a deployment implementation of scenarios 1-3 discussed in BCF discovery and BCC / BCA registration.

[0765] Figure 38An exemplary blockchain-enabled wireless application deployment scenario is shown in 5GS.

[0766] Figure 39 Several scenarios / options for implementing the proposed entities (such as BCF, BCC, and BNA) using existing functional entities in 5G systems such as AMF are described:

[0767] ● In Figure 39 In case 1 shown in (a), BCF is implemented as a new value-added service of AMF.

[0768] ● Therefore, BCA / BCC can communicate with AMF via the N1 interface, which can carry the new parameters proposed in this disclosure.

[0769] ● In Figure 39 In case 2 (b), the BCC is implemented by the AMF. In this case, communication between the BCA and the BCC can be achieved through the existing N1 interface between the WTRU and the AMF.

[0770] ● In Figure 39 In scenario 3 (c), the BNA is implemented by the AMF. Therefore, when BCA / BCC wants to communicate with BCF, BCA / BCC may first need to communicate through the AMF on the N1 interface, and then the AMF will assist BCA / BCC in interacting with BCF. In this implementation, if the AMF itself intends to use the blockchain service, it can also act as the BNA to interact directly with BCF using the process proposed in this invention.

[0771] Representative blockchain strategy management

[0772] Figure 40 The process for managing blockchain policy rules for BCA and / or BCC in 5GS is illustrated, which can be regarded as... Figure 36 The diagram illustrates a 3GPP implementation of the process. Although the diagram shows BCA residing in WTRU1 and BCC hosted by WTRU2, BCA and BCC can coexist in the same WTRU.

[0773] Prerequisites: BCC can discover BCF, and BCC is discovered by BCA. BCF can discover PCF, for example, via NRF. BCF is aware of one or more blockchain networks and their corresponding BCNs. WTRU, which hosts BCA and BCC, has established a connection with its service AMF. Comparison Figure 40 and Figure 36 Between the entities, we can see the following role assignments:

[0774] ● Figure 36 The initiator of strategy management in the process: Figure 40 BCC in

[0775] ● Figure 36 Strategy executor in: Figure 40 PCF in

[0776] ● Figure 36 Data storage in China: Figure 40 UDR in

[0777] ● Figure 36 Operation execution entity in: Figure 40 UPF, SMF, and BCC.

[0778] Step 1: The BCF can request some initial blockchain policy rules from the PCF. Alternatively, the BCF may already be subscribed to the PCF. As a result, the PCF can provide the BCF with some initial blockchain policy rules. For example, the initial blockchain policy rule could be: disallow WTRUs from accessing the list of blockchain networks in a specific service area to avoid generating additional blockchain traffic to those service areas. Another example could be: the BCF can (e.g., can only) be allowed to serve a list of specific BCA / UEs.

[0779] Step 2: The BCC (as the policy management initiator) can send a request to the BCF via the WTRU2 service AMF. This request can be a BCC registration request (during which the BCC can and / or assist the BCA in registering with the BCF if it knows certain information about the BCA) or a simple request to execute a policy to create / check new blockchain policy rules. The request can include the BCC's identifier (i.e., BCC-ID) and WTRU identifier (i.e., WTRU2-ID). If any blockchain policy rules have already been provided to the BCC, the BCC can also include a list of identifiers for existing blockchain policy rules in the request. This information allows the BCF to avoid configuring the same blockchain policy rules for the BCC again.

[0780] Step 3: BCF can process the request. BCF can directly reject the request based on any local blockchain policy rules (such as the initial rules received from PCF), especially when the request is a registration request to register BCC with BCF.

[0781] Step 4: If Step 2 is a BCC registration request, the BCF can select one or more BCNs for the BCA hosted by WTRU (during this time, if the BCC knows some information about the BCA, the BCC can also be and / or help the BCA register with the BCF). Alternatively, if the BCA has already been assigned a BCN due to previous registration, this step can select only the BCN previously assigned to the BCC / BCA.

[0782] Step 5: The BCF can send a request to the PCF to check for any new blockchain policy rules for the BCC. This request may include the BCF's identifier (i.e., BCF-ID), the BCN's identifier selected in Step 4 (i.e., BCN-ID), and / or WTRU2-ID, BCC-ID, and BCA-ID. The BCF can also notify the PCF whether it and / or the BCC / BCA can use the 5G control plane or data plane to store data (i.e., create blockchain transactions) to the target blockchain network represented by the BCN-ID. If the BCF or BCC can use the data plane, Step 9 may be required. If the BCF or BCC can use the control plane, Step 9 can be skipped.

[0783] Step 6: PCF can process the request from Step 5. PCF can retrieve WTRU2's subscription data from UDR using WTRU2-ID. WTRU2's subscription data may include some specifications and / or restrictions (service area restrictions), which can be used to generate new blockchain policy rules for WTRU2. If the target blockchain network is defined and supported as an LADN by 5GS, WTRU2's subscription data may include the LADN service area, meaning that WTRU2 can only access the target blockchain network while it remains within that LADN service area.

[0784] Step 7: Based on the response from UDR (i.e., subscription data), PCF can generate some new blockchain policy rules.

[0785] Step 8: PCF can send the new blockchain policy rules generated in step 7 to BCF.

[0786] Step 9: The PCF can configure some blockchain policy rules to the UPF via the SMF. Using the WTRU2-ID, the PCF can determine the SMF of WTRU2 from the UDM. The UPF can use the configured policy rules to regulate and manage data plane blockchain traffic between the BCC and the selected BCN. If the BCC does not use the data plane to communicate with the BCN, skip this step.

[0787] Step 10: BCF can send a response back to BCC via WTRU2's service AMF. This response may include the new blockchain policy rules and BCN-ID.

[0788] Note that steps 2 through 10 are used by the BCF to create new blockchain policy rules, and these rules (or some of them) can be configured into the BCC. The PCF can install the blockchain policy rules into the UPF that connects the BCC to the BCN. Furthermore, without any request from the BCC, the BCF can trigger the execution of steps 4 through 9 to obtain some new blockchain policy rules. Afterward, it is able to and / or can configure and install these rules into one or more BCCs.

[0789] Step 11: Instead of having the BCC initiate policy management, the BCA can initiate policy management to create policy rules. The BCA can send a request to the BCC by providing the WTRU1-ID and BCA-ID. This request can be a BCA registration request or a simple request to check new blockchain policy rules. WTRU1 can reach WTRU2 directly using device-to-device communication, or via relay from their serving AMF (the same AMF or a different AMF).

[0790] Step 12: When the request is a BCA registration request, BCC can process the request from BCA and generate a new BCA-ID.

[0791] Step 13: BCC can repeat steps 2 through 10 by registering itself and / or BCA to BCF or simply requesting new blockchain policy rules from BCF.

[0792] Step 14: If BCC generates BCA-ID in step 12, BCC can send a response to BCA, which may include the new blockchain policy rule and BCA-ID. WTRU2 can reach WTRU1 directly using device-to-device communication, or via relay from their serving AMF (the same AMF or a different AMF).

[0793] Figure 41 The process for managing the blockchain policy rules for BNA in 5GS is illustrated. This implementation corresponds to a scenario where BCF fully deploys BNA and BNA does not have the ability to interact directly with PCF, and all interactions are assisted by BCF.

[0794] Prerequisites: BNA can discover BCF. BCF can discover PCF, for example, via NRF. BCF knows one or more blockchain networks and their corresponding BCNs.

[0795] Step 1: BCF can request some initial blockchain policy rules from PCF. Alternatively, BCF may already be subscribed to PCF. As a result, PCF can provide BCF with some initial blockchain policy rules. For example, the initial blockchain policy rule could be: BCF is only allowed to serve lists of specific BNAs.

[0796] Step 2: The BNA can send a request to the BCF, which can be relayed by the NEF. This request can be a BNA registration request or a simple policy management request to check new blockchain policy rules. The request can include the BNA's identifier (i.e., BNA-ID). If any blockchain policy rules have already been provided to the BNA, the BNA can also include a list of identifiers for existing blockchain policy rules in the request. This information allows the BCF to avoid configuring the same blockchain policy rules to the BNA again.

[0797] Step 3: BCF can process the request. BCF can directly reject the request based on any local blockchain policy rules (such as the initial rules received from PCF), especially when the request is a registration request to register a BNA with BCF. When the request is a registration request, BCF can generate a new BNA identifier (i.e., BNA-ID).

[0798] Step 4: BCF can select one or more BCNs for BNA.

[0799] Step 5: The BCF can send a request to the PCF to check for any new blockchain policy rules for the BCC. This request may include the BCF's identifier (i.e., BCF-ID), the BCN's identifier (i.e., BCN-ID) selected in Step 4, and / or the BNA-ID. The BCF can inform the PCF whether it and / or the BNA can use the 5G control plane or data plane to store data (i.e., create blockchain transactions) to the target blockchain network represented by the BCN-ID. If the BCF or BNA can use the data plane, steps 6 and 9 may be required. If the BCF or BNA can use the control plane, steps 6 and 9 can be skipped.

[0800] Step 6: The PCF can process the request from Step 5 and can determine the SMF and UPF for the data path between the BNA (or BCF) and BCN.

[0801] Step 7: PCF can generate some new blockchain policy rules.

[0802] Step 8: PCF can send the new blockchain policy rules generated in step 7 to BCF.

[0803] Step 9: The PCF can configure some blockchain policy rules to the UPF via the SMF. The UPF can use the configured policy rules to regulate and manage data plane blockchain traffic between the BNA and the selected BCN (or BCF). If the BNA (or BCF) does not use the data plane to communicate with the BCN, skip this step.

[0804] Step 10: If BCF generates a BCA-ID in step 3, BCF can send a response back to BNA, which may include the new blockchain policy rules and the BNA-ID. This response can be relayed by NEF.

[0805] Figure 42 This document illustrates a process for configuring blockchain policy rules for data plane traffic originating from / to one or more blockchain networks. This implementation corresponds to a scenario where the BCF only partially deploys the BNA and the BNA has the ability to interact directly with the PCF.

[0806] Prerequisites: BNA can discover BCF. BNA can also discover PCF, for example, via NEF / NRF. BCF knows one or more blockchain networks and their corresponding BCNs.

[0807] Step 1: BCF can request some initial blockchain policy rules from PCF. Alternatively, BCF may already be subscribed to PCF. As a result, PCF can provide BCF with some initial blockchain policy rules. For example, the initial blockchain policy rule could be: BCF is only allowed to serve lists of specific BNAs.

[0808] Step 2: BNA can register itself with BCF. As a result, BNA can know the list of blockchain networks (i.e., one or more BCNs).

[0809] Step 3: The BNA can send a request to the PCF, requesting the PCF to configure certain blockchain policy rules to one or more BCNs. This request may include the BNA's identifier (i.e., BNA-ID), the BCN's identifier (i.e., BCF-ID), and / or the identifier of each BCN (i.e., BCN-ID). This request can be relayed by the NEF.

[0810] Step 4: PCF can contact BCF to verify BNA and authorize BNA to configure blockchain policy rules to BCN.

[0811] Step 5: PCF can determine the SMF and UPF of the data path from / or BCN based on BCN-ID and BNA-ID.

[0812] Step 6: PCF can generate some new blockchain policy rules.

[0813] Step 7: PCF can configure some blockchain policy rules to UPF via SMF. UPF can use the configured policy rules to regulate and manage data plane blockchain traffic to / from BCN.

[0814] Step 8: PCF can send the new blockchain policy rules generated in step 6 to BCF.

[0815] Step 9: The PCF can send a response back to the BNA, which may include a list of identifiers for the new blockchain policy rules configured to the UPF in step 7. This response may be relayed by the NEF.

[0816] Representative implementation plans for BCF discovery and BCC / BCA registration

[0817] Novel solutions were previously proposed for three different scenarios of BCF discovery and BCC / BCA registration. Specifically, each scenario has its own system setup and assumptions. 3GPP implementations for BCF discovery and BCC / BCA registration are given. Note that these implementations are applicable to the solutions proposed in all three scenarios.

[0818] Figure 4 This diagram illustrates some general processes in a 5G system architecture, which are sequentially and jointly executed by the WTRU, RAN, and 5GC to enable the WTRU to perform the following functions. As a result, several levels of connections / sessions (i.e., RRC connections, AMF connections, and PDU sessions) are established between the WTRU and other 5GS entities. This allows the WTRU to send / receive control plane traffic to / from the core network and data plane traffic to / from the data network via the UPF.

[0819] ● Step 1: WTRU can discover and select networks (i.e., PLMN, RAN, cell) based on the received System Information Block (SIB). The RAN broadcasts the System Information Block to all WTRUs.

[0820] ● Step 2: The WTRU can establish a Radio Resource Control (RRC) connection with the selected RAN (e.g., RAN1), enabling the WTRU to communicate with the core network via the selected RAN.

[0821] ● Step 3: The WTRU can initiate registration with the serving AMF, as determined by the selected RAN. This step can be a first implementation of BCF discovery. In this case, one or more parameters included in the BCF discovery request can be included in the 3GPP registration request. Alternatively, if the WTRU already knows which BCF to register with, this step can also be and / or can be a first implementation of BCC / BCA registration. In this case, one or more parameters included in the BCC / BCA registration request can be included in the 3GPP registration request.

[0822] ● Step 4: The WTRU can establish a PDU session with the SMF for the specified DN, as determined by the serving AMF. This step can be a second implementation of BCF discovery. In this case, all parameters included in the BCF discovery request can be included in the 3GPP PDU session establishment request from the WTRU. Alternatively, if the WTRU already knows which BCF to register with, this step can also be a second implementation of BCC / BCA registration. In this case, all parameters included in the BCC / BCA registration request can be included in the 3GPP request.

[0823] ● Step 5: When the WTRU enters the CM idle state (e.g., after the connection between the WTRU and the serving AMF is released), the WTRU (e.g., in Mobile-Initiated Connection (MICO) mode) can proactively initiate a service request procedure to re-establish the connection with the serving AMF and enter the CM connected state. If the WTRU is not in MICO mode, the serving AMF can page and trigger the WTRU to initiate a service request procedure, for example, to receive any downlink packets. This step can be a third implementation of BCF discovery. In this case, one or more parameters included in the BCF discovery request can be included in the 3GPP service request. Alternatively, if the WTRU already knows which BCF to register with, this step can also be a third implementation of BCC / BCA registration. In this case, one or more parameters included in the BCC / BCA registration request can be included in the 3GPP service request.

[0824] ● Step 6: The WTRU now begins data plane data transmission with the designated DN via the RAN and the UPF as the PSA. Note that each DN has a Data Network Name (DNN).

[0825] ● Step 7: When the WTRU moves from Registration Area (RA) 1 to RA2, it can detect this event by checking the TA list of each RA configured by the serving AMF. The WTRU can perform a mobile registration update for the new serving AMF. During this step, an inter-RAN handover based on Xn or N2 can be performed between the new and old RANs. The new serving AMF contacts the old serving AMF to transmit the WTRU's context information. In this step, the SMF can contact the PCF and UPF to update the existing PDU session with the WTRU. This step can be a fourth implementation of BCF discovery. In this case, one or more parameters included in the BCF discovery request can be included in the 3GPP mobile registration update request. Alternatively, if the WTRU already knows which BCF to register with, this step can also be a fourth implementation of BCC / BCA registration. In this case, one or more parameters included in the BCC / BCA registration request can be included in the 3GPP mobile registration update request.

[0826] In another approach, a BCF can be implemented as a 5G network function. Therefore, the BCF can first register itself with the NRF. Application functions, other network functions (e.g., the Serving AMF for its WTRU), and / or other BCFs can then discover any registered BCFs from the NRF. Specifically, the BCF can first send a BCF registration request to the NRF, which may include BCF information and information from other repositories maintained by the BCF, such as the BNA repository, BCA repository, and BCN repository. The NRF can receive the BCF registration request, process it, and create a new BCF record as part of the network function repository maintained by the NRF. The NRF can send a response to the BCF indicating whether the BCF registration was successful or failed. Another entity X (e.g., another BCF, another network function, another application function) can send a BCF discovery request to the NRF. The NRF can process this BCF discovery request, look up its maintained BCF records, and determine a list of registered BCFs that match the discovery criteria included in the BCF discovery request. The NRF can then send the list of discovered BCFs to entity X.

[0827] Representative 3GPP implementation scheme for interaction between BCF and BCF

[0828] The 5G data storage architecture comprises three data-related entities: Unified Data Management (UDM), Unified Data Repository (UDR), and Unstructured Data Storage Function (UDSF). When multiple BCFs exist in the system, two new methods emerge for enabling interaction between BCFs. For example, two BCFs can exchange information directly as described above, or indirectly via these data-related 3GPP entities. Specifically, for different BCFs to exchange information, the BCFs can store the following information in the UDR.

[0829] For example, a UDR can store the following types of information:

[0830] ● BCF network topology information. In this scenario, BCFs can communicate with each other via a UDR about their known peer BCFs (e.g., BCF-1 knows and is connected to two other BCFs, BCF-5 and BCF-6. BCF-2 knows and is connected to three other BCFs, BCF-9, BCF-10, and BCF-11). Through this UDR, the BCFs can gradually learn about all other peer BCFs in the system and the network topology between them.

[0831] ● BNA Information. In this case, BCFs can communicate with each other about the information stored in their BNA registry stores.

[0832] ● BCA Information Exchange Request. In this case, BCFs can communicate with each other about information stored in their BCA registry repositories.

[0833] ● BCN Information Exchange Request. In this case, BCFs can communicate with each other about information stored in their BCN registration repository.

[0834] ● BCF Subscription Information. In this case, BCF-1 may be interested in certain events or information that can be captured by another BCF-2. Therefore, BCF-1 can subscribe to BCF-2 and receive notifications.

[0835] ● When BCF is an NF in a 5G network, UDR can be used to implement BCF's BNA registration repository, BCA registration repository and BCN registration repository (that is, for BCF, all registration information of BCA, BNA and BCN that it hosts can be stored in UDR).

[0836] Alternatively, multiple BCFs can register themselves with the Network Repository Function (NRF) so that they can be discovered by each other.

[0837] In addition, BCC / BCA can also be used and / or the above methods can be used to find BCF.

[0838] Another possible implementation is that the proposed BCF can be implemented by existing functions in 5GS, such as AMF or SMF. In other words, the proposed BCF is a new value-added service provided by existing functional entities. For example, the following could be two implementations for communication between BCFs:

[0839] ● In 5G systems, AMF and SMF each implement BCF functions. In this case, communication between BCFs is specifically manifested as communication from AMF to SMF.

[0840] ● In a 5G system, two network slices are created, and each network slice includes an AMF instance, with each AMF instance implementing the BCF function. In this case, communication between BCFs is specifically manifested as communication between AMFs in two different network slices.

[0841] Representative implementation plans for BCN registration and BCN management

[0842] The BCN functionality, including blockchain / ledger maintenance, can be implemented as a UDSF. Therefore, a BCN acting as a UDSF (referred to as BCN-UDSF) can register itself (including its capabilities and information about the affiliated blockchain system) with the NRF. In other words, a BCN-UDSF can send a registration request to the NRF. This registration request can include, for example... Figure 12 The steps in step 1 include one or more parameters for basic BCN registration. The NRF can process this registration request and can create a new BCN-UDSF record (similar to the BCN registration repository maintained by the BCF). The NRF can send a registration response to the BCN-UDSF, similar to... Figure 12 Step 3. BCF can search for BCN capabilities and corresponding blockchain system information from the NRF by sending a BCN discovery request to the NRF. The NRF can process the BCN discovery request, search its maintained BCN-UDSF records to find any matching records, and return the matching records to BCF. Alternatively, BCF can send a subscription request to the NRF to subscribe to any new BCN-UDSF registration. When a new BCN-UDSF is registered with the NRF, the NRF can send BCF a notification including all subscription information about the BCN-UDSF and its associated blockchain systems.

[0843] Similarly, BCN-UDSF can send a report request to the NRF to report the current state of its own and / or affiliated blockchain systems. This report request may include, for example... Figure 15The NRF can process the report request and update the corresponding BCN-UDSF record. The BCF can proactively send a request to the NRF to retrieve the latest BCN-UDSF record, and automatically receive notifications of new BCN-UDSF records from the NRF using a subscription mechanism whenever the BCN-UDSF attempts to update its state stored in the NRF.

[0844] Representative blockchain applications enable integration with other vertical applications.

[0845] 3GPP SA6 has introduced several vertical applications for mission-critical scenarios, including edge applications, V2X applications, Factory of the Future (FF) applications, 5G Messaging Service (5GMSGS) applications, and Unmanned Aerial System (UAS) applications. For each of these vertical applications, 3GPP SA6 defines an application enablement layer. Generally, the application enablement layer consists of entities such as: Vertical Application Client (VAC), Vertical Enabled Client (VEC), Vertical Enabled Server (VES), and Vertical Application Server (VAS). VAC and VEC can coexist within the WTRU. Table 1 shows how VAC, VEC, VES, and VAS map to the entities defined in each vertical application layer enablement.

[0846] Table 1. Entities Enabled in the SA6 Vertical Application Layer

[0847]

[0848] These vertical applications can use blockchain application enablers, for example, to store their communication records on a target blockchain and / or transmit unicast or multicast messages through the target blockchain network. Therefore, these vertical applications can benefit from blockchain characteristics such as decentralization, immutability, transparency, and security. To enable vertical applications to interact with blockchain application enablers, in Figure 43 , Figure 44 and Figure 45 Three integration architectures were proposed in the paper.

[0849] In ensemble model 1, such as Figure 43 As shown, there are two methods for communication between vertical applications and blockchain application enablers.

[0850] ● Method 1: VES can discover and register with BCF. VES can behave like BCC or BNA. After registration, VES can interact with BCF on behalf of any VAC, any VEC, and any VAS via the Vertical Application to Blockchain (VTB1) interface. In this method, VAC / VEC / VAS cannot communicate directly with BCF, but rather indirectly through VES. Through VES and BCF, VEC (or VAS) can access any target blockchain network that BCF interfaces with. VEC represents VAC as needed. After establishment (e.g., after VEC / VAC / VES / VAS / BCF are connected and operational), VEC can be treated as BCC, VES as BCC, and VAS as BNA.

[0851] ● Method 2: VES can help VEC or VAS discover BCF via the VTB1 interface. VES does not need to register with BCF. VEC or VAS can register with BCF discovered via the VTB1 interface. After registration, VEC or VAS can communicate directly with BCF via the VTB2 and VTB3 interfaces respectively. Through BCF, VAC / VEC and VAS can access any target blockchain network that BCF interfaces with. VEC stands for VAC as needed. After establishment, VEC can be considered as BCC, VES can be considered as BCC, and VAS can be considered as BNA.

[0852] In such Figure 44 In the integrated model 2 shown, there are also three methods for vertical applications and blockchain application enablers to communicate.

[0853] ● Method 1: VES can discover BCC. VES can discover BCC from BCF. VES can register with BCC. Afterward, VES can interact with BCC on behalf of any VAC, any VEC, and any VAS. In this method, VAC / VEC / VAS cannot communicate directly with BCC, but rather indirectly with BCF via VES. Through VES, BCC, and BCF, VEC (or VAS) can access any target blockchain network that BCF interfaces with. VEC represents VAC as needed. After establishment, VEC / VAS / VES can be considered clients of BCC.

[0854] ● Method 2: VES helps VEC (or VAS) discover BCC. VES can discover BCC from BCF. Afterwards, VEC (or VAS) can register with BCC. Following registration, VEC (or VAS) can interact directly with BCC, and BCC can communicate with BCF on behalf of VEC (or VAS). Through BCC and BCF, VEC (or VAS) can access any target blockchain network that BCF interfaces with. VEC represents VAC as needed. Once established, VEC / VAS / VES can be considered clients of BCC.

[0855] ● Method 3: VEC (or VAS) can discover and register with BCC. Afterward, VEC (or VAS) can interact directly with BCC, and BCC can communicate with BCF on behalf of VEC (or VAS). Through BCC and BCF, VEC (or VAS) can access any target blockchain network that BCF interfaces with. VEC represents VAC as needed. Once established, VEC / VAS / VES can be considered a client of BCC.

[0856] ● Method 4: A VEC (or VAS) can discover and register with a BCC. A VEC (or VAS) can discover a BCF via a BCC. Afterward, a VEC (or VAS) can communicate directly with a BCF. Through a BCF, a VEC (or VAS) can access any target blockchain network that a BCF interfaces with. A VEC can stand for VAC as needed. After setup, a VEC can be considered a BCC, a VES can be considered a BCC, and a VAS can be considered a BNA.

[0857] Figure 45 This example illustrates the integration of existing vertical application enablement with blockchain application enablement (e.g., SA6) – Model 3.

[0858] In integrated model 3, such as Figure 45 As shown, blockchain enabling can be implemented directly or within existing entities in various vertical application entities. For example, VAC can implement all the functions of BCA, VEC can implement all the functions of BCC, VES can implement all the functions of BCF, and VAS can implement all the functions of BNA. As a result, all communication between BCC / BCF / BNA proposed in this disclosure can use the existing interfaces defined in SA6 for vertical application enabling. In other words, all existing interfaces can be enhanced to support blockchain-related interactions between BCC / BCF / BNA as defined in this disclosure, for example, to carry all the new parameters proposed in this disclosure.

[0859] ""in conclusion

[0860] Although features and elements have been provided above in specific combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with other features and elements. This disclosure is not limited to the specific embodiments described in this patent application, which are intended as examples of various aspects. Many modifications and variations are possible without departing from the spirit and scope of the invention, as will be apparent to those skilled in the art. Unless expressly stated otherwise, no element, action, or description used in this specification should be construed as essential or necessary to the invention. Based on the foregoing description, functionally equivalent methods and apparatus within the scope of this disclosure, other than those listed herein, will be apparent to those skilled in the art. Such modifications and variations are intended to fall within the scope of the appended claims. This disclosure is limited only to the terms of the appended claims and the full scope of equivalents of such claimed claims. It should be understood that this disclosure is not limited to any particular method or system.

[0861] For simplicity, the aforementioned embodiments have been discussed regarding the terminology and structure of infrared-capable devices (i.e., infrared transmitters and receivers). However, the embodiments discussed are not limited to these systems, but can be applied to other systems that use other forms of electromagnetic waves or non-electromagnetic waves (such as sound waves).

[0862] It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the term “video” or the term “image” may mean any of a snapshot, a single image, and / or multiple images displayed on a time basis. As another example, when referred to herein, the term “user equipment” and its abbreviation “UE,” the term “remote” and / or the term “head-mounted display” or its abbreviation “HMD” may mean or include (i) a wireless transmitting and / or receiving unit (WTRU); (ii) any of several embodiments of a WTRU; (iii) a device with wireless and / or wired (e.g., tetherable) capabilities configured with some or all of the structure and functions of a WTRU; (iii) a device with fewer than all the structure and functions of a WTRU; or (iv) the like. Figures 1A to 1D Details of exemplary WTRUs that may represent any WTRU described herein are provided. As another example, the various disclosed embodiments herein are described above and below as utilizing head-mounted displays. Those skilled in the art will recognize that devices other than head-mounted displays may be utilized, and some or all of this disclosure and the various disclosed embodiments may be modified accordingly without excessive experimentation. Examples of such other devices may include drones or other devices configured to stream information to provide an adapted realistic experience.

[0863] Furthermore, the methods described herein can be implemented in computer programs, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile optical discs (DVDs)). The processor associated with the software can be used to implement a radio frequency transceiver for a WTRU, terminal, base station, RNC, or any host computer.

[0864] Variations of the methods, apparatus, and systems provided above are possible without departing from the scope of the invention. Given the various applicable embodiments, it should be understood that the illustrated embodiments are merely examples and should not be construed as limiting the scope of the following claims. For example, embodiments provided herein include handheld devices that may include or be used with any suitable voltage source (such as a battery) that provides any suitable voltage.

[0865] Furthermore, the embodiments provided above specify processing platforms, computing systems, controllers, and other devices including processors. These devices may include at least one central processing unit (“CPU”) and memory. According to the practice of those skilled in the art of computer programming, references to symbolic representations of actions and operations or instructions can be executed by various CPUs and memories. Such actions and operations or instructions may be considered as being “executed,” “computer-executed,” or “CPU-executed.”

[0866] Those skilled in the art will recognize that the actions and symbols representing operations or instructions include the CPU's manipulation of electrical signals. The electrical system represents data bits, which can lead to the final transformation or reduction of electrical signals and the retention of data bits at memory locations in the memory system, thereby reconfiguring or otherwise altering the CPU's operation and performing other signal processing. The memory location holding the data bits is a physical location having specific electrical, magnetic, optical, or organic properties corresponding to or representing the data bits. It should be understood that the implementation is not limited to the platform or CPU described above, and other platforms and CPUs may also support the provided methods.

[0867] Data bits may also be stored on a computer-readable medium, including disks, optical disks, and any other CPU-readable volatile (e.g., random access memory (“RAM”) or non-volatile (e.g., read-only memory (“ROM”) mass storage system. The computer-readable medium may include cooperative or interconnected computer-readable media that are uniquely present on the processing system or distributed across multiple interconnected processing systems, which may be local or remote relative to the processing system. It should be understood that the implementation is not limited to the aforementioned memory, and other platforms and memories may also support the provided methods.

[0868] In exemplary embodiments, any of the operations, processes, etc., described herein may be implemented as computer-readable instructions stored on a computer-readable medium. These computer-readable instructions may be executed by a processor of a mobile unit, network element, and / or any other computing device.

[0869] There is little difference between the hardware and software implementations of various aspects of the system. The use of hardware or software typically (but not always, as the choice between hardware and software can become important in certain contexts) represents a design choice that weighs cost against efficiency. Various media (e.g., hardware, software, and / or firmware) may exist to implement the processes and / or systems and / or other technologies described herein, and the preferred media may vary depending on the context of the deployment of the processes and / or systems and / or other technologies. For example, if the implementer determines that speed and accuracy are most important, the implementer may choose a media that is primarily hardware and / or firmware. If flexibility is most important, the implementer may choose a primarily software implementation. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0870] The above detailed description has illustrated various embodiments of the apparatus and / or processes using block diagrams, flowcharts, and / or examples. Where such block diagrams, flowcharts, and / or examples contain one or more functions and / or operations, those skilled in the art will understand that each function and / or operation within such block diagrams, flowcharts, or examples can be implemented individually and / or collectively by a wide range of hardware, software, firmware, or virtually any combination thereof. In embodiments, certain portions of the subject matter described herein can be implemented via application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integration formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein can be equivalently implemented in an integrated circuit, either wholly or partially, as one or more computer programs (e.g., one or more programs running on one or more computer systems), one or more programs running on one or more processors (e.g., one or more programs running on one or more microprocessors), firmware, or virtually any combination thereof, and that designing circuits and / or writing code for software and / or firmware according to this disclosure will be entirely within the skill of those skilled in the art. Furthermore, those skilled in the art will recognize that the mechanisms of the subject matter described herein can be distributed as program products in various forms, and the exemplary embodiments of the subject matter described herein apply regardless of the specific type of signal-bearing medium used to actually implement the distribution. Examples of signal-bearing media include, but are not limited to, the following: recordable media (such as floppy disks, hard disk drives, CDs, DVDs, digital magnetic tapes, computer memory, etc.); and transmission media (such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.)).

[0871] Those skilled in the art will recognize that it is common practice in the art to describe devices and / or processes in the manner set forth herein, and subsequently to use engineering practice to integrate such described devices and / or processes into data processing systems. That is, at least a portion of the devices and / or processes described herein can be integrated into a data processing system through a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system generally includes one or more of the following: a system unit enclosure; a video display device; memory, such as volatile and non-volatile memory; a processor, such as a microprocessor and a digital signal processor; computing entities, such as an operating system, drivers, a graphical user interface, and applications; one or more interactive devices, such as a touchpad or screen; and / or a control system, including feedback loops and control motors (e.g., feedback for sensing position and / or speed, control motors for moving and / or adjusting components and / or quantities). Typical data processing systems can be implemented using any suitable commercially available components, such as those commonly found in data computing / communication and / or network computing / communication systems.

[0872] The topics described herein sometimes illustrate different components contained within or connected to different other components. It should be understood that such depicted architectures are merely examples, and many other architectures can in fact achieve the same functionality. Conceptually, any arrangement of components achieving the same function is effectively “associated” to enable the desired functionality. Therefore, any two components combined herein to achieve a particular function can be considered “associated” with each other to enable the desired function, regardless of the architecture or intermediate components. Similarly, any two such associated components can also be considered “operably connected” or “operably coupled” to each other to achieve the desired function, and any two components that can be suchly associated can also be considered “operably coupled” to each other to achieve the desired function. Specific examples of operably coupled components include, but are not limited to, components that can physically cooperate and / or physically interact and / or components that can wirelessly interact and / or logically interact and / or logically interact.

[0873] Regarding virtually any plural and / or singular terms used herein, those skilled in the art can appropriately convert them from plural to singular and / or from singular to plural depending on the context and / or application. For clarity, various singular / plural permutations may be explicitly listed herein.

[0874] Those skilled in the art will understand that, in general, the terminology used herein, particularly in the appended claims (e.g., the body of the appended claims), is typically intended as “open-ended” terms (e.g., the term “comprising” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “including” should be interpreted as “including but not limited to,” etc.). Those skilled in the art will also understand that if it is intended to specify a particular number of introduced claim objects, such intention will be explicitly stated in the claims, and if no such claim objects are present, such intention will not exist. For example, the term “single” or similar language may be used where only one item is anticipated. To aid understanding, the appended claims and / or the description herein may contain the use of the introductory phrases “at least one” and “one or more” to introduce claim objects. However, the use of such phrases should not be construed as implying that any particular claim containing such introduced claim objects is limited to an embodiment containing only one such claim object by using the indefinite articles “a” or “an.” Even when the same claim includes the introductory phrase "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"), this is also true. The same applies to the use of definite articles used to introduce the subject matter of a claim. Furthermore, even when a specific number of the introduced subject matter of a claim is explicitly stated, those skilled in the art will recognize that such a statement should be interpreted as meaning at least the stated number (e.g., a bare statement of "two subject matters" without other modifiers means at least two subject matters, or two or more subject matters). Additionally, in instances where conventions such as "at least one of A, B, and C" are used, generally speaking, such constructions mean that those skilled in the art will understand that convention (e.g., "a system having at least one of A, B, and C" will include, but is not limited to, systems having A alone, having B alone, having C alone, having both A and B, having both A and C, having both B and C, and / or having both A, B, and C, etc.). In instances where conventions such as "at least one of A, B, or C" are used, generally speaking, such a construction implies that a person skilled in the art will understand that the convention (e.g., "a system having at least one of A, B, or C" includes, but is not limited to, systems having A alone, having B alone, having C alone, having both A and B, having both A and C, having both B and C, and / or having both A, B, and C, etc.). A person skilled in the art should also understand that, in fact, any separate words and / or phrases presenting two or more alternative terms, whether in the specification, claims, or drawings, should be understood to contemplate the possibility of including one term, any one of the terms, or both terms.For example, the phrase “A or B” will be understood to include the possibility of “A” or “B” or “A and B”. Additionally, as used herein, the term “any one of…” followed by a list of multiple items and / or multiple item categories is intended to include items alone or in combination with other items and / or other item categories, “any one of,” “any combination,” “any multiple,” and / or “any combination of multiples of.” Furthermore, as used herein, the term “group” is intended to include any number of items, including zero. Additionally, as used herein, the term “quantity” is intended to include any quantity, including zero.

[0875] Furthermore, where features or aspects of this disclosure are described in accordance with the Markush Group, those skilled in the art will recognize that this disclosure is also described in accordance with any individual member of the Markush Group or a subgroup of its members.

[0876] As those skilled in the art will understand, for any and all purposes (such as for providing a written description), all scopes disclosed herein also encompass any and all possible subscopes and combinations thereof. Any listed scope can be readily identified as sufficiently descriptive and such that the same scope can be divided into at least two equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each scope discussed herein can be readily divided into a lower third, a middle third, and an upper third, etc. As those skilled in the art will also understand, all language such as “at most,” “at least,” “greater than,” “less than,” etc., includes the referenced number and refers to a scope that can subsequently be divided into subscopes as described above. Finally, as those skilled in the art will understand, a scope includes each individual number. Thus, for example, a group having 1 to 3 units means a group having 1, 2, or 3 units. Similarly, a group having 1 to 5 units means a group having 1, 2, 3, 4, or 5 units, etc.

Claims

1. A method implemented in a device including a circuit system, the device comprising a transmitter, a receiver, a processor, and a memory, the method comprising: A registration request is received from a web application via either wireless or wired communication, the registration request including first information indicating multiple application-level requirements of the distributed ledger service; Based on (i) one or more of the plurality of application-level requirements and (ii) second information indicating one or more characteristics of each of the plurality of distributed ledger systems, a first distributed ledger system is determined from the plurality of distributed ledger systems communicatively coupled to the device to serve the network application; as well as A third message is sent to the network application via either wireless or wired communication, wherein the third message indicates (i) registration confirmation and (ii) a unique identifier assigned to the network application.

2. The method according to claim 1, comprising: Maintain a distributed ledger store containing at least some of the first information and the second information.

3. The method according to claim 2, comprising: Receive at least some of the information from the distributed ledger store, which is the second information.

4. The method according to claim 2, comprising: Receive another registration request from each of the network nodes in the plurality of distributed ledger systems via either wireless or wired communication; Information identifying each of the plurality of distributed ledger systems is added to the distributed ledger repository; as well as Registration confirmation is sent to the network node of each of the plurality of distributed ledger systems via either wireless or wired communication.

5. The method of claim 1, comprising at least two of the following: Maintain a distributed ledger store that includes at least some of the information from the first information and the second information; Receive at least some of the information from the second information from the distributed ledger store; Another registration request is received from each of the network nodes in the plurality of distributed ledger systems via either wireless or wired communication; Information identifying each of the plurality of distributed ledger systems is added to the distributed ledger repository; as well as Registration confirmation is sent to the network node of each of the plurality of distributed ledger systems via either wireless or wired communication.

6. The method according to any one of claims 1 to 5, wherein the plurality of application-level requirements include one or more features of each of the plurality of distributed ledger systems.

7. The method according to at least one of claims 1 to 5, wherein the plurality of application-level requirements includes any of the following: The identifier of the distributed ledger system; The type of distributed ledger system; Consensus mechanism / protocol; The application programming interface (API) specification for the distributed ledger system; The number of peer nodes in the distributed ledger system; The current size of the ledger in the distributed ledger system; The geographical distribution of the peer nodes in the distributed ledger system; The distributed ledger supports the ability to create new ledgers; One or more performance metrics supported by the distributed ledger system; The access details of the nodes in the distributed ledger system; The node type of the node in the distributed ledger system; The mobility type of the node in the distributed ledger system; as well as The organization associated with the node of the distributed ledger system.

8. The method according to any one of claims 1-5, wherein, Each of the multiple distributed ledger systems is registered to the device.

9. The method according to any one of claims 1-5, wherein, The multiple distributed ledger systems are managed by the device.

10. The method according to any one of claims 1-5, wherein, The one or more features of each of the plurality of distributed ledger systems include any of the capabilities, specifications, types, characteristics, basic information, and parameters of the corresponding distributed ledger system.

11. An apparatus including a circuit system, the apparatus comprising a transmitter, a receiver, a processor, and a memory, the apparatus being configured to: A registration request is received from a web application via either wireless or wired communication, the registration request including first information indicating multiple application-level requirements of the distributed ledger service; Based on (i) one or more of the plurality of application-level requirements and (ii) second information indicating one or more characteristics of each of the plurality of distributed ledger systems, a first distributed ledger system is determined from the plurality of distributed ledger systems communicatively coupled to the device to serve the network application; as well as A third message is sent to the network application via either wireless or wired communication, wherein the third message indicates (i) registration confirmation and (ii) a unique identifier assigned to the network application.

12. The apparatus of claim 11, wherein the circuitry is configured to maintain a distributed ledger store containing at least some of the first information and the second information.

13. The device of claim 12, wherein the circuitry is configured to receive at least some of the information of the second information from the distributed ledger store.

14. The device of claim 12, wherein the circuit system is configured to: Receive another registration request from each of the network nodes in the plurality of distributed ledger systems via either wireless or wired communication; Add information identifying each of the plurality of distributed ledger systems to the distributed ledger store; and Registration confirmation is sent to the network node of each of the plurality of distributed ledger systems via either wireless or wired communication.

15. The device of claim 11, wherein the circuitry is configured for at least two of the following: Maintain a distributed ledger store that includes at least some of the information from the first information and the second information; Receive at least some of the information from the second information from the distributed ledger store; Another registration request is received from each of the network nodes in the plurality of distributed ledger systems via either wireless or wired communication; Information identifying each of the plurality of distributed ledger systems is added to the distributed ledger repository; as well as Registration confirmation is sent to the network node of each of the plurality of distributed ledger systems via either wireless or wired communication.

16. The device according to any one of claims 11 to 15, wherein the plurality of application-level requirements include one or more features of each of the plurality of distributed ledger systems.

17. The device according to any one of claims 11 to 15, wherein the plurality of application-level requirements include any one of the following: The identifier of the distributed ledger system; The type of distributed ledger system; Consensus mechanism / protocol; The application programming interface (API) specification for the distributed ledger system; The number of peer nodes in the distributed ledger system; The current size of the ledger in the distributed ledger system; The geographical distribution of the peer nodes in the distributed ledger system; The distributed ledger supports the ability to create new ledgers; One or more performance metrics supported by the distributed ledger system; The access details of the nodes in the distributed ledger system; The node type of the node in the distributed ledger system; The mobility type of the node in the distributed ledger system; as well as The organization associated with the node of the distributed ledger system.

18. The device according to any one of claims 11-15, wherein, Each of the multiple distributed ledger systems is registered to the device.

19. The device according to any one of claims 11-15, wherein, The multiple distributed ledger systems are managed by the device.

20. The device according to any one of claims 11-15, wherein, The one or more features of each of the plurality of distributed ledger systems include any of the capabilities, specifications, types, characteristics, basic information, and parameters of the corresponding distributed ledger system.

Images