Method for managing offline operations on blockchain

Abstract

A method and apparatus for offline management of a blockchain node is disclosed. The method performed by a first blockchain node may include: sending a first message to at least a second blockchain node, the first message including information indicating a state of the first blockchain node and a value indicating a time when the first blockchain node will be offline, receiving a second message from the second blockchain node including information indicating a blockchain proxy node selected for the first blockchain node, and transitioning to an offline state at the time indicated by the value.

Description

[Background technology]

[0001] Blockchain technology is a technology that jointly leverages and builds on several existing techniques such as cryptography, hashing, Merkle trees, distributed ledgers, peer-to-peer (P2P) networking, and consensus protocols. However, blockchain technology innovatively integrates them to enable a system that can provide advanced features such as decentralization, immutability, transparency, and security. A blockchain system refers to a system that uses blockchain technology. An application that uses and / or is supported by a blockchain system is called a blockchain application. A blockchain system is supported by an underlying blockchain network that is composed of many participating blockchain nodes. Each blockchain node hosts one or more distributed blockchains (a form of distributed ledger) and participates in the blockchain system.

[0002] For example, blockchain nodes broadcast blockchain transactions and blocks to each other using peer-to-peer networking, and blockchain nodes implement consensus protocols with each other to reach distributed trust without relying on a centralized party. Blockchain transactions can be digital representations of real-world transactions, digital records of physical assets, digital records of physical events, digital records of any action in an information system, digital payments, and / or digital smart contracts, where a block groups multiple blockchain transactions together, and a blockchain is a data structure that allows an increasing number of blocks to be chained together. Summary of the Invention

[0003] A method and apparatus for offline management of a blockchain node is disclosed. The method implemented by a first blockchain node may include sending a first message to at least a second blockchain node, the first message including information indicating a value indicating a time when the first blockchain node changes state to offline, receiving a second message from a blockchain management function (BMF) including information indicating a blockchain proxy node selected for the first blockchain node, and transitioning to an offline state at a time indicated by the value. The first blockchain node may be a wireless transmit / receive unit (WTRU). The first message may indicate a preferred proxy node for the first blockchain node. The blockchain client may indicate a preferred proxy node for the first blockchain node. The BMF may select a proxy node based on the capabilities of each proxy node. The second message may indicate that the second blockchain node can be a proxy node for the first blockchain node. [Brief description of the drawings]

[0004] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which like reference numbers indicate similar elements and in which: [Figure 1A] FIG. 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1A is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A, according to one embodiment. [Figure 1C] FIG. 1B is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 1D] FIG. 1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Diagram 2] 1 illustrates an exemplary general workflow of a blockchain system. [Diagram 3] 1 illustrates an exemplary blockchain system architecture. [Figure 4] 1 illustrates an exemplary 5G system architecture. [Diagram 5] 1 illustrates an exemplary general procedure in a 5G system architecture. [Figure 6] An exemplary use case for the Internet of Vehicles (IoV) based on blockchain technology is presented. [Figure 7] 1 illustrates an exemplary system overview of off-chain blockchain offline operation management. [Figure 8] 1 illustrates an exemplary procedure for active off-chain blockchain offline operation management. [Figure 9] 1 illustrates an exemplary procedure for passive off-chain blockchain offline operations management. [Figure 10] 1 illustrates an exemplary system overview of on-chain blockchain offline operation management. [Figure 11] We present an example procedure for on-chain BOOM. [Figure 12] 13 shows another exemplary procedure for on-chain BOOM. [Figure 13] 1 illustrates an exemplary procedure for blockchain synchronization. [Figure 14] 1 illustrates an example procedure for determining a proxy node for an offline blockchain node. [Figure 15] Shows multiple oracles. [Figure 16] 1 illustrates an exemplary oracle proxy. [Figure 17]1 illustrates an exemplary blockchain offline operation management in a 5G / 6G cellular network. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0006] 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a station (STA), may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, mobile 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 wearables, 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 an industrial and / or automated processing chain context), consumer electronic devices, devices operating in commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0007] The communications system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communications networks, such as the CN 106, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode B (eNB), a Home Node B, a home eNode B, a next generation Node B such as a gNode B (gNB), a new radio (NR) Node B, a site controller, an access point (AP), a wireless router, etc. Although the base stations 114a, 114b are each shown as a single element, it will be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

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

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

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

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

[0012] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access, which may establish the air interface 116 using NR.

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

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

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

[0016] The RAN 104 may communicate with the CN 106, which may be any type of network configured to provide voice, data, application, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have various quality of service (QoS) requirements, such as, for example, different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although not shown in FIG. 1A, it will be understood that the RAN 104 and / or the CN 106 may communicate directly or indirectly with other RANs that use the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may utilize NR radio technology, the CN 106 may also communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA or WiFi radio technologies.

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

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

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

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

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

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

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

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

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

[0026] 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) regarding a current location of the WTRU 102. In addition to or in lieu of information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of signals being received from two or more nearby base stations. It will be understood that the WTRU 102 may obtain location information by way of any suitable location determination method while remaining consistent with an embodiment.

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

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

[0029] 1C is a system diagram illustrating the RAN 104 and the CN 106 according to one embodiment. As mentioned above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using E-UTRA radio technology. The RAN 104 may also communicate with the CN 106.

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

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

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

[0033] The MME 162 may be connected to each of the eNodeBs 162a, 162b, 162c in the RAN 104 via an S1 interface and may function as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, activating / deactivating bearers, selecting a particular serving gateway during initial attachment of the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

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

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

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

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

[0038] In an exemplary embodiment, the other network 112 may be a WLAN.

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

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

[0041] A High Throughput (HT) STA may use a 40 MHz wide channel for communication, which may be formed, for example, through a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels.

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

[0043] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support meter-type control / machine-type communications (MTC), such as MTC devices in macro coverage areas. MTC devices may have specific capabilities, including, for example, support for (e.g., support only for) specific and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0044] WLAN systems that may support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that may be designated as a primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be configured and / or limited by the STAs among all STAs operating in the BSS that support the smallest bandwidth operating mode. In an 802.11ah example, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only) the 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the state of the primary channel. For example, if the primary channel is busy, a STA (that only supports 1 MHz mode of operation) transmitting to the AP may cause all of the available frequency bands to be considered busy, even if most of the available frequency bands are idle.

[0045] In the United States, the available frequency bands that can be used by 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 bandwidth available for 802.11ah is 6MHz to 26MHz depending on the country code.

[0046] 1D is a system diagram illustrating the RAN 104 and the CN 106 according to one embodiment. As mentioned above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using NR radio technology. The RAN 104 may also communicate with the CN 106.

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

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

[0049] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without accessing another RAN (e.g., eNodeBs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate with and connect to a gNB 180a, 180b, 180c while also communicating with and connecting to another RAN, such as an eNodeB 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNodeBs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, while the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0050] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, support for network slicing, DC, interworking between NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a, 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D, the gNBs 180a, 180b, 180c may communicate with each other via an Xn interface.

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

[0052] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and may function as a control node. For example, the AMF 182a, 182b may be responsible for user authentication of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling different protocol data unit (PDU) sessions having different requirements), selection of the SMFs 183a, 183b for registration, management of registration areas, termination of non-access stratum (NAS) signaling, mobility management, etc. The network slicing may be used by the AMF 182a, 182b to customize the CN support of the WTRUs 102a, 102b, 102c based on the type of service utilizing the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, etc. The AMF 182a, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0053] The SMFs 183a, 183b may be connected to the AMFs 182a, 182b in the CN 106 via an N11 interface. The SMFs 183a, 183b may also be connected to the UPFs 184a, 184b in the CN 106 via an N4 interface. The SMFs 183a, 183b may select and control the UPFs 184a, 184b and configure the routing of traffic through the UPFs 184a, 184b. The SMFs 183a, 183b may perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0054] The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPFs 184, 184b may perform other functions, such as packet routing and forwarding, user plane policy enforcement, support for multi-homed PDU sessions, handling user plane QoS, DL packet buffering, mobility anchoring, etc.

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

[0056] 1A-1D and the corresponding description thereof, one or more or all of the functions described herein with respect to one or more of the WTRUs 102a-d, base stations 114a-b, eNodeBs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

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

[0058] The one or more emulation devices may perform one or more functions, inclusive, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in test scenarios in a test lab and / or in an undeployed (e.g., test) wired and / or wireless communication network to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, for example, one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0059] Figure 2 shows the general workflow of a blockchain system 200. At 202, each participating user independently creates a new transaction. Each user has a user or account identifier, which is typically a hash of the user's public key. Each new transaction may be signed using the user's private key. After a new transaction is created, the user submits it to the blockchain network.

[0060] At 204, the new transaction is initially received by some blockchain nodes, which may verify its integrity using the user's public key that may be included in the transaction. After verification, if the new transaction is valid, it may be relayed and broadcast within the blockchain network. Eventually, all blockchain nodes may receive and have a copy of any newly generated valid transaction.

[0061] At 206, some blockchain nodes (called "mining nodes" or "full nodes") start to group together many newly created pending transactions to generate a new block. A new block may consist of a block header and a block body. The block header typically contains a hash of the current block, a hash of the previously confirmed block, and a hash of all included transactions (e.g., a Merkle tree). Depending on the consensus protocol, the block header may contain additional information. The block body contains the contents of all included transactions. Each mining node attempts to create a new block independently.

[0062] At 208, mining nodes independently attempt to create a new block. These nodes run the same consensus protocol (e.g., proof of work in the Bitcoin system) and reach an agreement on who (i.e., the winner) will be allowed to insert a block into the existing blockchain. The winner of the consensus protocol may send the newly created block to the blockchain network. This new block may be broadcast, causing all mining nodes to receive it and validate it.

[0063] At 210, after the newly generated block is verified, it can be successfully added to the existing blockchain because it contains the hash of the previous block (i.e., the last block of the previous blockchain).

[0064] FIG. 3 shows a general blockchain system architecture, which may consist of several types of logical entities, including an administrative node, several blockchain nodes that host a blockchain or distributed ledger, and several blockchain clients 302a, 302b, and 302c, such as blockchain applications.

[0065] Blockchain Middleware (BCM) 304 bridges blockchain clients 302a, 302b, and 302c with blockchain nodes 306a, 306b, 306c, 306d, and 306e. BCM 304 interacts with blockchain nodes 306a, 306b, 306c, 306d, and 306e on behalf of blockchain clients 302a, 302b, and 302c, although blockchain clients may also interface directly with blockchain nodes in some cases. BCM 304 may also manage and coordinate all blockchain nodes 306a, 306b, 306c, 306d, and 306e. For example, the blockchain client 302a, 302b, or 302c simply sends a blockchain transaction to the BCM 304 without indicating any blockchain node 306a, 306b, 306c, 306d, or 306e as a destination node. The BCM 304 may then select a blockchain node 306a, 306b, 306c, 306d, or 306e and forward the blockchain transaction to the selected or appropriate blockchain node 306a, 306b, 306c, 306d, or 306e. The BCM 304 may be considered as a proxy for the blockchain client 302a, 302b, or 302c to interact with the blockchain node 306a, 306b, 306c, 306d, or 306e. The BCM 304 may optionally maintain the same blockchain / ledger as the blockchain node host. A public blockchain system may not have such a BCM 304, but a private or permissioned blockchain system will typically have a BCM 304 for blockchain governance, access control, and other administrative purposes.

[0066] A blockchain node (BCN) may participate in a blockchain workflow and may perform actions as shown in FIG. 2. The blockchain nodes may be connected via P2P links to form a mesh P2P network, in which transactions and blocks are broadcast among all blockchain nodes. A blockchain node may connect to multiple other blockchain nodes as its neighbors or adjacent blockchain nodes. For example, blockchain node A 306a has two neighbors (i.e., blockchain node B 306b and blockchain node C 306c). Because the blockchain nodes may form a mesh network, the loss of a blockchain node (e.g., going offline) typically does not affect the normal operation of the blockchain system. For example, if blockchain node A 306a goes offline, the other blockchain nodes 306b, 306c, 306d, or 306e may still be connected and function well. However, if the loss of a blockchain node disrupts the mesh network, such a blockchain node may be referred to as a critical blockchain node. For example, blockchain node C 306c may be a critical blockchain node. A properly designed P2P routing protocol may avoid the presence of any critical blockchain node. A blockchain node may serve multiple blockchain clients. When a blockchain node receives new transactions from its clients, it may broadcast them to the entire P2P network so that they can be received by all other blockchain nodes. Similarly, when a blockchain node wins the consensus protocol, the new blockchain blocks generated by it may also be broadcast to all other blockchain nodes.

[0067] Each blockchain node hosts one or more ongoing blockchains. How blockchain nodes are connected to each other depends on the P2P routing protocol (e.g., gossip-based routing) for the P2P network. A good P2P routing protocol may avoid the presence of any critical blockchain nodes. Blockchain nodes with P2P routing protocols may be managed and coordinated by a BCM. Standardization for blockchain operation in the presence of offline mode blockchain nodes has recently begun. There may be two types of blockchain nodes: (1) basic blockchain nodes that host the blockchain, including sending / receiving transactions and receiving new blocks, but do not participate in the consensus protocol, or (2) endorsers / verifiers / miners that not only host the blockchain, but also participate in the consensus protocol, including generating new blocks.

[0068] A Blockchain Client (BCC) may generate new transactions and send them directly to the corresponding blockchain node or send them to the BCM to be forwarded to the blockchain node. A BCC may interface with one blockchain node when interacting directly with the blockchain node, but this may change. Multiple blockchain clients may connect to the same blockchain node. A blockchain client may lose connection to a blockchain node or blockchain middleware, resulting in it going offline to the entire blockchain system. A blockchain client may be a blockchain application on a device (i.e., a local blockchain client) versus a blockchain application in the cloud (i.e., a remote blockchain client).

[0069] FIG. 4 illustrates an exemplary 5G system architecture. As shown in FIG. 4, the exemplary 5G system may consist of a radio transmit / receive unit (WTRU) 402, a radio access network (RAN) 404, and a core network 406. One of the design principles for the 5G system architecture is service-centric or service-based. As shown in FIG. 4, the 5G core network may include various network functions that cooperate to perform and provide the necessary services to the RAN 404, the WTRU 402, and the application server / service provider. A network function may access another network function in a request / response mode or a subscription / notification mode. Before two network functions can interact with each other, they must first register with a Network Repository Function (NRF) 414 so that they can discover each other from the NRF 414. Among these network functions, an Access and Mobility Management Function (AMF) 422 may be dedicated to managing the WTRU, its access to the 5G system, and its mobility. The Session Management Function (SMF) 426 may be responsible for establishing a session between the WTRU 402 and the 5G core network 406. The Authentication Server Function (AUSF) 424 is responsible for WTRU 402 authentication. In addition, the Policy Control Function (PCF) 416 provides policy rules for other control plane network functions and the WTRU 402. The PCF 416 assigns an identifier for each created policy rule that is used by other control plane network functions and the WTRU 402 to reference the corresponding policy rule. The User Plane Function (UPF) 434 may be the only function for the user plane. The UPF 434 facilitates monitoring, managing, controlling, and redirecting user plane traffic flows, such as between the WTRU 402 and application servers.

[0070] The Network Exposure Function (NEF) 412 allows control plane functions to be exposed to entities such as network applications that are external to the 5G system and not in the same trust domain. The 5G Core Network 406 also provides data storage and analysis services through functions such as Unified Data Management (UDM) 418, Unified Data Repository (UDR) 428, Unstructured Data Storage Function (UDSF) 430, and Network Data Analytics Function (NWDAF) 420. Another important feature in the 5G system is network slicing, which can be facilitated by the Network Slice Selection Function (NSSF) 410. Although these network functions are defined as separate logical entities, certain scenarios may require multiple network functions. For example, WTRU mobility requires not only the AMF 422, but also the AUSF 424 and SMF 426. For a certain type of network function, multiple instances may be instantiated, and the NRF may maintain information of each instantiated network function instance. With the advent of edge computing, some network functions in the 5G core network, such as the UPF 434 and NEF 412, may be deployed and reside in edge networks, potentially co-located much closer to the RAN 404.

[0071] FIG. 5 illustrates several general procedures in a 5G system architecture 500 that are jointly performed by the WTRU 502a, the RAN nodes 504a and / or 504b, and the 5G core network to enable the WTRU 502a to perform the functions described below.

[0072] At 550, the WTRU 502a may discover and select a network (ie, PLMN, RAN, cell) based on a received System Information Block (SIB) that the RAN nodes 504a and / or 504b broadcast to all WTRUs.

[0073] At 552, the WTRU 502a may establish a Radio Resource Control (RRC) connection with the selected RAN (e.g., RAN1 504a) such that the WTRU 502a may communicate with the core network 520 via the selected RAN 504a.

[0074] At 554, the WTRU 502a may initiate registration with the serving AMF 522a, which may be determined by the selected RAN 504a. Here, the serving AMF 522a may check with the AUSF 524 for primary access authentication and authorization, request the WTRU's subscription data from the UDM 526, check with the PCF 528 for access and mobility policies, and may optionally contact the SMF 530 to activate any existing PDU sessions if the WTRU 502a indicates. 5G introduces the concept of a Registration Area (RA), which consists of multiple Tracking Areas (TAs). When the WTRU 502a stays within a RA (e.g., RA1), it is usually not necessary to perform a registration update with the serving AMF 522a again to reduce signaling overhead unless a periodic registration timer expires. Each TA may cover multiple cells. When the WTRU 502a moves from one RA to another (e.g., RA2), the WTRU 502a needs to perform a new registration with the registration type set in the mobility registration update. A larger RA helps reduce registration overhead, but may increase the overhead of paging signaling that the serving AMF 522a uses to page the WTRU 502a.

[0075] The WTRU 502a may then enter an RM-REGISTERED state and start interacting with other control plane NFs via the serving AMF 522a. The serving AMF 522a may be the only entry point for the WTRU 502a to access and interact with the core network control plane. A service request may be made together with the WTRU 502a registration, which results in the WTRU entering CM-CONNECTED. When the WTRU 502a stays in the CM-CONNECTED state, the WTRU 502a may move within the RA without notifying the serving AMF 522a. However, if the WTRU moves out of the RAN Notification Area (RNA) and is still within the RA, the WTRU 502a may need to perform a RAN update to trigger the RAN to update the WTRU 502a context and the corresponding RRC connection maintained by the RAN. Note that the RNA may be a subset of the RA. For example, TA1, TA2, and TA3 form an RNA.

[0076] At 556, the WTRU 502a may establish a PDU session for the specified DN with the SMF 530, which may be determined by the serving AMF 522s. The SMF 530 may check with the PCF 528 for a PDU session policy and may select the UPF 532 as a PDU Session Anchor (PSA). The PSA may be an entry point for the WTRU 502a to access the data network (DN) 540 or to receive packets from the DN 540. When the SMF 530 checks with the PCF 528 for a session policy, the PCF 528 may retrieve subscription data of the WTRU 502a from the UDM. The SMF 530 may perform primary session authentication using the subscription data of the WTRU 502a retrieved from the UDM, and may optionally perform secondary authentication between the WTRU 502a and the DN-AAA server using the Extensible Authentication Protocol (EAP) defined in RFC3748 and RFC5247. This may be carried out in conjunction with the procedure described in 558.

[0077] When the WTRU 502a enters the CM-IDLE state (e.g., after the WTRU 502a's connection with the serving AMF is released), the WTRU 502a may actively initiate a service request procedure to re-establish a connection with the serving AMF 522a (e.g., in Mobile Initiated Connections Only (MICO) mode) and enters the CM-CONNECTED state. If the WTRU is not in MICO mode while in the CM-IDLE state, the serving AMF 522a may page and trigger the WTRU 502a to initiate a service request procedure, e.g., to receive any downlink packets. As a result of the service request, a Non-Access Stratum (NAS) connection may be established between the WTRU 502a and its serving AMF 522a.

[0078] When the WTRU starts data transmission in the data plane using a specified DN via the RAN 504a and the UPF 532 as a PSA. Each DN may have a Data Network Name (DNN).

[0079] When the WTRU 502a moves from RA1 to RA2, it may detect this event by checking the list of TAs for each RA configured by the serving AMF. The WTRU 502a then performs a mobile registration update with the new serving AMF. An Xn-based or N2-based inter-RAN handover may be performed between the new and old RAN. The new serving AMF contacts the old serving AMF to transfer the context information of the WTRU 502a. The SMF may contact the PCF and UPF to update the existing PDU session with the WTRU 502a.

[0080] As shown in FIG. 5, multiple TAs may be grouped together as a Local Area Data Network (LADN) service area to support LADN services. As an example, TA4, TA5, and TA6 form a LADN service area. Thus, a WTRU 502a may be allowed to access LADN1 if and only if it camps in TA4, TA5, or TA6. Similarly, a set of TAs may be grouped as a service area based on which the 5GS may specify and enforce service area restrictions for the WTRU 502a. For example, TA7, TA8, and TA9 form a service area, and the 5GS may configure the service area with the WTRU 502a for service area restrictions. Thus, a WTRU may be allowed to access the 5GS if and only if the WTRU 502a camps with TA7, TA8, or TA9.

[0081] An example is shown in Figure 5. The WTRU 502a may perform the procedures in a different order. The procedure described in 560 may occur in the data plane, and all other procedures may occur in the control plane.

[0082] FIG. 6 illustrates an example use case of Internet of Vehicles (IoV) based on blockchain technology. Each vehicle 602a, 602b, and / or 602c may have at least a wireless connection (e.g., 5G and / or 6G) that connects the vehicle to the Internet via Roadside Units (RSUs) 604a and / or 604b (or base stations). The RSUs 604a and 604b may have a local edge network with computing and storage resources. The vehicles 602a, 602b, and 602c may move from one RSU to another. The vehicles 602a, 602b, and 602c may communicate with each other or with other vehicles, RSUs, edge networks, core networks, and / or application servers. In this use case, blockchain nodes may be deployed in the 5G / 6G core network, edge network, radio access network (RAN), and even in the vehicle. For example, the vehicle 602c may host the blockchain. The blockchain nodes 620b, 620c, and 620d in the edge network may be co-located with the edge server, while the blockchain node 610e in the wireless access network may be co-located with the RSU.

[0083] In one exemplary use case, a blockchain node may lose connectivity completely and therefore cannot talk to other blockchain nodes. Thus, this blockchain node may be considered an offline blockchain node from the perspective of the blockchain system. For example, when a vehicle 602c moves from RAN1 610a to RAN2 610b, it may lose communication links to both RAN1 610a and RAN2 610b. As a result, the blockchain node 620f of the vehicle 602c cannot be reached by other blockchain nodes and becomes an offline blockchain node.

[0084] In this example use case, blockchain nodes may become congested and unreachable (i.e., offline). For example, blockchain node B 620b in edge network #1 640 may serve too many vehicles from RAN #1 610a and applications from the 5G / 6G core network or cloud. As a result, its computational power and storage space may be exhausted. To mitigate or solve this problem, blockchain node B 620b may implement an offline schedule (either one-time or periodic) and go offline periodically. Such an offline schedule may also help blockchain node B 620b conserve its energy efficiency.

[0085] A blockchain node may go offline due to loss of communication connectivity, or the blockchain node may take turns going offline for load balancing and / or other performance considerations. A blockchain node may wake up and come online after being offline for a period of time. In other words, a blockchain node has an offline schedule between online and offline states. The offline management of blockchain nodes refers to problems such as, but not limited to: (1) detecting offline blockchain nodes; (2) determining when and which blockchain nodes go offline; (3) determining how long selected blockchain nodes will stay online; (4) determining whether a blockchain node that goes offline needs a proxy node (e.g., another blockchain node); and (5) determining how a blockchain node can synchronize itself with the normal blockchain when it wakes up and comes back online. Two methods are proposed for Blockchain Offline Operation Management (BOOM). The terms BOOM, offline management, and offline operation management can be used interchangeably unless explicitly stated otherwise.

[0086] In off-chain BOOM, coordination and management of blockchain node offline operations can be implemented without using blockchain system mechanisms. The proposed blockchain management function (BMF) can be responsible for offline schedule management of blockchain nodes. BMF can be a centralized out-of-band approach. Also, each blockchain node may have BOOM as a logical function responsible for offline operation management, including offline schedule management on the blockchain node side. Coordination and management commands / messaging between blockchain nodes and BMF may be blockchain system agnostic in the sense that those commands / messaging are issued as general messages (not blockchain transactions) exchanged between blockchain nodes and BMF.

[0087] In on-chain BOOM, coordination and management of offline operations of blockchain nodes may be performed through normal blockchain operations (e.g., by creating a new blockchain that is different from the normal blockchain, or simply by leveraging the normal blockchain). Also, each blockchain node may have BOOM as a logical function. This may be a decentralized and in-band approach, since coordination and management commands / messaging may be issued as a type of blockchain transaction, broadcast, announced, verified, and agreed upon among all blockchain nodes (through normal blockchain operations).

[0088] As part of managing the offline operation of blockchain nodes, a method is proposed for blockchain synchronization and offline blockchain node detection, which can be used to refer to a blockchain node that is currently offline at the offline level.

[0089] An online blockchain node may be used to refer to a blockchain node that is currently online and performing regularly and normally to support all blockchain-related functions and / or operations.

[0090] An offline blockchain client may be used to refer to a blockchain client that is currently offline at an offline level.

[0091] An online blockchain client may be used to refer to a blockchain client that is currently online and operating regularly and normally to support all blockchain-related functions and / or operations.

[0092] Offline levels may be used to refer to various levels or options or possibilities or modes of the offline state of an offline blockchain node (or offline blockchain client), including, but not limited to, the following:

[0093] Offline Level 1 may be used to refer to an offline blockchain node that remains in Offline Level 1. The offline blockchain node may still be able to perform all functions that support and maintain the regular blockchain, but may only be able to reach a portion of the online blockchain nodes. This blockchain node and some other offline Level 1 and / or online blockchain nodes may communicate with each other and may form a separate or isolated P2P network to create a separate blockchain that is different from the original regular blockchain.

[0094] Offline level 2 may be used to refer to a blockchain node remaining in offline level 2. The blockchain node may still be able to perform all functions that support and maintain a normal blockchain, but it cannot reach any of the other online blockchain nodes. In other words, the blockchain node itself may still be reachable by the BMF and / or other network entities, but is completely isolated in the blockchain network.

[0095] Offline Level 3 may be used to refer to offline blockchain nodes that remain in Offline Level 3. An offline blockchain node cannot perform functions to support and maintain a normal blockchain, but may still have communication connectivity and thus may interact with or be reached by the BMF and / or other network entities for control and management purposes, such as offline schedule management.

[0096] Offline level 4 may be used to refer to an offline blockchain node remaining in offline level 4. The offline blockchain node cannot perform functions to support and maintain a normal blockchain. Also, the communication physical layer of the offline blockchain node enters a power saving mode (e.g., Discontinuous Reception (DRX) and Connected Mode DRX (cDRX) in 4G / 5G). In other words, an offline blockchain node in offline level 4 cannot be reached by the BMF, but can be woken up by some network entities (e.g., 4G / 5G base stations or Wi-Fi access points), which usually depend on the underlying communication infrastructure.

[0097] Offline Level 5 may be used to refer to an offline blockchain node remaining in offline Level 5. An offline blockchain node is completely offline (e.g., powered off), in other words, it cannot perform functions to support and maintain the normal blockchain, and is not reachable by any network entity. An offline blockchain node is reachable only the next time it wakes up.

[0098] The offline start time may be used to refer to the time when a blockchain node (or blockchain client) begins to go offline.

[0099] Offline duration may be used to refer to the period between when a blockchain node (or blockchain client) goes offline and the next time it wakes up.

[0100] Online duration may be used to refer to the period between when a blockchain node (or blockchain client) wakes up and the next time it goes offline again.

[0101] The offline iteration may indicate whether the blockchain node (or blockchain client) goes offline once or repeatedly. If the blockchain node needs to go offline repeatedly, the "offline duration" and "online duration" indicate how long the blockchain node goes offline and then stays online.

[0102] An offline schedule may be used to refer to a time schedule for a blockchain node (or a blockchain client) to alternately maintain offline and online, including offline level, offline start time, offline duration, online start time, online duration, offline repetition, etc. An offline schedule may be applied to a blockchain client as well. For example, an offline schedule may be as follows: (offline level="level 1", offline start time="t1", offline duration="600 seconds, offline repetition="1 time"), which indicates that a blockchain node (or a blockchain client) with this offline schedule needs to be offline at offline level 1, once at t1, for 600 seconds. In another example, the offline schedule may look like this: (offline level="level 4", offline start time="t2", offline duration=300 seconds, online duration=3600 seconds, offline recurrence="PERIORIDCAL"), which indicates that a blockchain node (or blockchain client) with this offline schedule will start going offline and waking up alternately at t2, with an offline duration of 300 seconds at offline level 2 and an online duration of 3600 seconds.

[0103] A blockchain node may be used to refer to a logical node that hosts a blockchain (or ledger). A blockchain node may also have the functionality to endorse / verify transactions / blocks. In this case, a blockchain node may also be a blockchain endorser and / or a blockchain verifier.

[0104] Conventional blockchain may be used to refer to the main / primary blockchain and / or corresponding sidechains on which all blockchain nodes are hosted and which support one or more blockchain applications.

[0105] Blockchain synchronization may be used to refer to the process whereby when a previously offline blockchain node wakes up or comes online, it needs to retrieve transactions / blocks that were missed during its offline duration in order to build an up-to-date regular blockchain.

[0106] Although a blockchain may be a type of distributed ledger, all proposed methods are not dependent or specific to any particular type of distributed ledger, and therefore, all proposed methods are applicable to blockchain systems and distributed ledger systems more generally.

[0107] In off-chain BOOM, as shown in FIG. 7, the BMF 702 may act as a centralized node, which hosts a repository for collecting and maintaining the state and blockchain capabilities of all blockchain nodes, called the blockchain node repository. The BMF 702 also hosts another repository for collecting and maintaining requirements and context information of blockchain clients, called the blockchain client repository. The BMF 702 may also have a BOOM 704 as a logical function for managing offline schedules and / or offline operations of blockchain nodes. Blockchain nodes (e.g., blockchain node A 706a and blockchain node D 706d as examples in FIG. 7) may actively and periodically report their state and blockchain capabilities to the BMF 702.

[0108] Alternatively, a blockchain node may report its state and blockchain capabilities only when requested by the BMF 702. A blockchain node may also report the state and blockchain capabilities of its neighboring blockchain nodes on the P2P network to the BMF 702. Here, blockchain capabilities may be a joint parameter based on multiple variables such as residual storage, available computing power, available communication capacity, reliability of communication connectivity, statistics of recently generated normal blocks, security threats, supported and / or used consensus protocols, support for blockchain interoperability, support for smart contracts, support for side chains, etc. The state of a blockchain node may be online and various offline levels (e.g., offline level 1, offline level 2, offline level 3, offline level 4, offline level 5). In addition, blockchain clients 708a and 708b (e.g., blockchain client #1 in FIG. 7) may monitor the performance of a blockchain node and report it to the BMF 702 / BOOM 704 when interacting directly with the blockchain node.

[0109] A blockchain client (e.g., blockchain client #1 708a as an example in FIG. 7) may actively and periodically report its requirements and context information to the BMF 702. Alternatively, blockchain clients 708a and / or 708b may report their requirements and context information only when requested by the BMF 702. Here, the requirements and context information of a blockchain client may be joint parameters based on multiple variables such as offline schedule, rate of issuing new transactions, rate of accessing the normal blockchain, latency requirements when accessing the normal blockchain, location, reliability of communication connectivity, etc.

[0110] For example, the blockchain client 708a and / or 708b may be a blockchain application on a constrained device with a specific offline schedule to save energy consumption and extend device life. As a result, the blockchain client may periodically generate messages to the blockchain node or the BMF 702 according to its offline schedule. The BMF 702 may align the offline schedules of the blockchain client and the corresponding blockchain node with each other, so that when the blockchain client is online, there is always an available online blockchain node. The requirements and context information of the blockchain client are stored in a blockchain client repository in the BMF 702.

[0111] Next, the BMF 702 may analyze the information stored in the blockchain client repository 712 and the blockchain node repository 710 to determine the next blockchain node to go offline. The BMF 702 may employ various strategies to select the blockchain node to go offline. For example, it may simply select each blockchain node in a round-robin manner. In a greedy approach, the BMF may always select the blockchain node with the least blockchain capacity to remain offline for a period of time. Since some blockchain clients may have their own offline schedule, the BMF may select corresponding blockchain nodes (serving these clients) that go offline with a similar offline schedule of these blockchain clients.

[0112] When a blockchain node is selected to go offline, the BMF702 may send any offline schedule and instructions to the blockchain node, which may include an assigned offline level, an assigned offline duration, an assigned proxy node for the blockchain node, and / or how to sync with the blockchain node hosting the latest regular blockchain when the blockchain node next comes online.

[0113] After remaining at the assigned offline level for the specified offline duration, the blockchain node wakes up as a working blockchain node. After the blockchain node wakes up, it may contact its proxy nodes and / or its previous neighboring blockchain nodes to download blocks and transactions that it missed when it was offline. The blockchain node may first contact multiple neighboring nodes to find out the longest branch of the latest regular blockchain and synchronize itself with the longest branch.

[0114] For example, blockchain node A 706a has two neighboring nodes (i.e., blockchain node B 706b and blockchain node C 706c), and either blockchain node B 706b or blockchain node C 706c may be selected by the BMF 702 as a proxy for the blockchain node. If the blockchain node remains offline, its clients may interact with its proxy or other blockchain nodes, which may be coordinated by the blockchain node and / or the BMF. For example, if blockchain node B 706b is selected as a proxy for blockchain node A 706a, blockchain client #1 708a may be informed of the address of blockchain node B 706b and may interact with blockchain node B 706b when blockchain node A 706a goes offline.

[0115] BMF / BOOM may be a logical functional entity that can perform the following functions: (1) connecting requirements and context information of blockchain clients and maintaining them in a blockchain client repository, (2) connecting blockchain capabilities and states of blockchain nodes and maintaining them in a blockchain node repository, such as their existing blockchain offline schedules, (3) analyzing the information stored in the blockchain node repository and generating instructions for blockchain offline operations or offline schedules of blockchain nodes, (4) sending the generated instructions for blockchain offline operations or offline schedules to the corresponding blockchain nodes, and (5) facilitating an offline blockchain node to synchronize itself with the normal blockchain when it wakes up.

[0116] Additionally, the BOOM in a blockchain node may be a logical functional entity that may perform the following functions: (1) reporting its blockchain capabilities and status to the BMF / BOOM, (2) detecting the blockchain capabilities and status of neighboring blockchain nodes and reporting them to the BMF / BOOM, (3) receiving blockchain offline operation or offline schedule instructions from the BMF / BOOM, (4) when an offline blockchain node comes online, its BOOM receives synchronization assistance from the BMF / BOOM, (5) acting as a proxy node for other offline blockchain nodes and providing services to their blockchain clients, and / or (6) when an offline blockchain node comes online, its BOOM downloads missing transactions / blocks from the BMF / BOOM and / or BOOMs of other blockchain nodes.

[0117] BOOM in BMF acts as a logical BOOM server role, while BOOM in blockchain nodes acts as a logical BOOM client. The terms BMF and BMF / BOOM are used interchangeably unless explicitly stated otherwise. Similarly, blockchain nodes have BOOM by default unless explicitly stated otherwise. The BOOM functionality proposed in this invention includes both BOOM in BMF and BOOM in blockchain nodes.

[0118] The above approach is called active off-chain BOOM because BMF / BOOM actively determines the offline schedule of blockchain nodes (or blockchain clients). In contrast, a passive off-chain BOOM approach is also proposed in which BMF / BOOM does not determine the offline schedule of blockchain nodes (or blockchain clients). Instead, blockchain nodes may have their own offline schedules and notify BMF / BOOM of their schedules, and may also send notifications to BMF / BOOM every time they go offline. BMF / BOOM may then select and assign proxies for offline nodes or wake up other offline nodes as a solution to maintain blockchain system performance.

[0119] As an extension, the proposed BMF / BOOM may be defined as a logical role / function (instead of acting as a centralized physical node), i.e., the BMF / BOOM may be operated by different physical nodes. For example, different blockchain nodes may be considered as physical nodes, and among those nodes, they may vote and select one node that is the node with BMF / BOOM and implement the proposed BMF / BOOM functions as described above. For example, the physical nodes may implement a specific voting or consensus protocol to determine which physical blockchain node will act as a BMF / BOOM node during a specific time interval.

[0120] After such nodes are determined, all blockchain nodes may be notified. Such a BMF node selection process may be periodically re-run or triggered. In addition, when the proposed BOOM makes any offline decisions for blockchain nodes (or blockchain clients), the decisions may be made in a system-wide manner. For example, instead of determining whether a particular blockchain node should go offline, BMF / BOOM may make a global decision for a list or group of blockchain nodes. Alternatively, when determining whether a particular blockchain node should go offline, BMF / BOOM may take into account previous decisions made for other blockchain nodes.

[0121] As an example, BMF may be implemented as part of the platform services layer of a Permissioned Distributed Ledger (PDL) reference architecture. BOOM in a blockchain node may be implemented as part of a PDL node in the PDL reference architecture. Alternatively, the proposed BMF / BOOM may also be considered as a new feature or a new value-added service of the blockchain middleware as described in FIG. 2.

[0122] FIG. 8 illustrates an active off-chain BOOM 802. In 820a, 820b, and 820c, the BMF 802 collects the blockchain capabilities and states of all blockchain nodes 804a, 804b, and 804c and maintains them in a blockchain node repository. Each blockchain node 804a, 804b, and 804c may be configured with the address of the BMF 802. If a blockchain node manages a sidechain system consisting of sidechain nodes, the blockchain node may report the capabilities and / or states of one or more sidechain nodes to the BMF. The blockchain nodes (i.e., 804a, 804b, and 804c) may report or indicate their preferred proxy nodes to the BMF 802. The blockchain nodes (i.e., 804a, 804b, and 804c) may report or indicate a list of blockchain nodes that can act as proxy nodes. One or more of the following methods may be used:

[0123] In one method, at 820a, 820b, and / or 820c, the BMF 802 may send a blockchain capabilities and state request request to the blockchain nodes 804a, 804b, and / or 804c. The blockchain nodes 804a, 804b, and / or 804c may then send a blockchain capabilities and state request response to the BMF 802. The request request may include the blockchain node's identifier / address, a flag indicating that the blockchain node should also report the state of neighboring nodes, one or more blockchain capabilities variables indicating that the blockchain node should only include values ​​for these variables, a response time indicating that the blockchain node should send back the request response before this time, etc. The request response may include the blockchain node's identifier / address, the value of the requested blockchain capability variable, an offline intention indicating whether the blockchain node is willing to go offline, an offline schedule previously assigned by the BMF 802 and currently operated by this node, the blockchain node's own offline schedule, a reasonable offline duration indicating how long the blockchain node can remain offline (e.g., a blockchain node that supports many active applications may not remain offline for an extended period of time), an offline start time indicating when blockchain nodes 804a, 804b, and / or 804c are willing to begin going offline, and the state and capabilities of neighboring blockchains, including identifiers / addresses of neighboring nodes.

[0124] In another method, the BMF 802 may first send a blockchain capability and state subscription request to the blockchain nodes 804a, 804b, and / or 804c. The blockchain nodes 804a, 804b, and / or 804c may first send a blockchain capability and state subscription response to the BMF 802. The blockchain nodes 804a, 804b, and / or 804c may then send blockchain capability and state notifications to the BMF 802 whenever there is a change in their blockchain capability and / or state that satisfies the notification criteria included in the blockchain capability and state subscription request. The blockchain capability and state notifications may include the same information as the blockchain capability and state request response in the first method.

[0125] In yet another method, the BMF 802 may first configure a blockchain capability and status reporting period for each blockchain node 804a, 804b, and / or 804c. The blockchain nodes 804a, 804b, and / or 804c may periodically send blockchain capability and status report messages to the BMF. The blockchain capability and status report messages may include the same information as the blockchain capability and status request responses in the first method.

[0126] In yet another method, the BMF 802 may receive a normal transaction creation request or blockchain transaction from the blockchain client 812. The BMF 802 then generates the transaction and / or simply forwards the transaction to the selected blockchain node. The BMF 802 receives transaction responses from the blockchain nodes accordingly. As a result, the BMF 802 can analyze received and / or missing transaction responses to estimate the performance of the blockchain nodes. This is a passive approach, although it can also detect if the blockchain nodes 804a, 804b, and / or 804c have gone offline.

[0127] If the blockchain client 812 directly interacts with the blockchain nodes 804a, 804b, and / or 804c, the blockchain client 812 may also monitor the performance of the blockchain node (e.g., blockchain node A), such as the average transaction response time as perceived by the blockchain client, the average number of transactions the blockchain client has recently sent to the blockchain nodes 804a, 804b, and / or 804c. If the blockchain client 812 only interfaces with the BCM / BMF, the blockchain client 812 may not be able to monitor the performance of the blockchain node, but the BMF may passively monitor the performance of the blockchain node. As a result, this may be skipped by the blockchain client. At 822, the blockchain client 812 may report the monitored performance of the blockchain node to the BMF 802.

[0128] At 824, the BMF 802 may collect requirements and context information of all blockchain clients 812. In one method, the BMF 802 may send a blockchain client requirements and context request request to the blockchain client 812. The blockchain client 812 then sends a blockchain client requirements and context request response to the BMF 802. The request request may include the identifier / address of the blockchain client 812, one or more blockchain client requirements and context variables indicating that the blockchain client 812 need only include values ​​for these variables, a response time indicating that the blockchain client 812 should return the request response before this response time, etc. The request response may include the identifier / address of the blockchain client 812, the values ​​of the blockchain client requirements and the requested context variables, an offline intent indicating whether the blockchain client is willing to go offline, a reasonable offline duration indicating how long the blockchain client can stay offline, an offline start time indicating when the blockchain client 812 is willing to start going offline, and an existing offline schedule for the blockchain client 812.

[0129] Alternatively, the BMF 802 may first send a blockchain client requirement and a context subscription request to the blockchain client 812. The blockchain client 812 may first send a blockchain client request and a context subscription response to the BMF. The blockchain client may then send a blockchain client request and a context notification to the BMF whenever there is a change in its blockchain client requirement and context that meets the notification criteria included in the blockchain client request and the context request. The blockchain client 812 requirement and context notification may include the same information as the blockchain client requirement and context request response described above.

[0130] In yet another method, the BMF 802 may first configure the blockchain client requirements and context reporting period for each blockchain client 812. The blockchain client 812 may periodically send a blockchain client requirements and context report message to the BMF 802. The blockchain client request and context report message may include the same information as the blockchain client request and context request response in the first method.

[0131] At 826, the BMF may monitor the performance of blockchain nodes as it generates or forwards transactions to blockchain nodes on behalf of blockchain clients. The BMF maintains a blockchain repository to record the blockchain capabilities and status of its blockchain nodes of interest based on information received from the blockchain nodes at 820c, 820b, and / or 820c, information received from the blockchain clients at 823, and / or information from passive performance monitoring of the blockchain nodes.

[0132] At 828, based on the information recorded in the blockchain node repository and the blockchain client repository, the BMF 802 determines the next blockchain node 804a, 804b, and / or 804c to go offline. For example, the BMF 802 may select a blockchain node with the least blockchain capacity to go offline. The BMF 802 may have its own policies and rules for selecting or rotating the blockchain node to go offline. Assuming that the blockchain node A 804a is selected to go offline, the BMF 802 may also select another blockchain node (e.g., blockchain node B 804b) as a proxy node for the blockchain node A 804a when the blockchain node A 804a goes offline. The BMF 802 also determines the offline schedule of the blockchain node A 804a (e.g., when the blockchain node A 804a needs to go offline at the assigned offline level and how long it needs to stay offline). The BMF 802 may determine the offline schedule of multiple blockchain nodes (e.g., blockchain node A 804a and blockchain node C 802c). The BMF802 may then send a separate notification to each blockchain node containing their offline schedule (e.g., offline level, offline start time, offline duration).

[0133] If blockchain node A802a is determined to be offline, the BMF802 may determine and assign one or more proxy nodes for blockchain node A802a based on some pre-configured rules or based on a smart contract.

[0134] The BMF 802 may select an online blockchain node close to the blockchain node A 804a as a proxy node for the blockchain node A 804a. In another example, during or after 828, the BMF 802 may send a proxy node solicitation request to one or more online blockchain nodes to ask if they are willing to become a proxy node for the blockchain node A 804a. The BMF 802 may then receive a proxy node solicitation response from the one or more online blockchain nodes. The BMF 802 may then select one or more received responses as corresponding online blockchain nodes as proxy nodes for the blockchain node A 804a. In another example, during or after 828, the BMF 802 and the online blockchain nodes may automatically select one or more proxy nodes for the blockchain node A 804a using a smart contract.

[0135] The BMF 802 may also determine an offline schedule (e.g., when to go offline, how long to stay offline, whether this offline schedule should be repeated, and how many times or how long to repeat) for one or more blockchain clients. For example, if a blockchain client 812 intends to stay offline for a while, the BMF 802 may instruct the blockchain client 812 to go offline if the associated blockchain node is also selected to be offline. In another case, to reduce traffic overhead in the blockchain network and thus improve transaction speed, the BMF 802 may select some blockchain clients to go offline based on their requirements and context information. In another example, if a blockchain client 812 is about to trigger an existing smart contract that relies on an external oracle, and the external oracle is offline or has an offline schedule, the BMF 802 may also instruct this blockchain client to go offline until the external oracle is online and available.

[0136] At 830, the BMF 802 may send a message to each of blockchain node A 804a's neighboring nodes or its proxy nodes (i.e., blockchain node B 804b). This message may include the identifier / address of blockchain node A 804a, the assigned offline schedule of blockchain node A 804a (e.g., an offline start time indicating when blockchain node A 804a may begin to go offline, an assigned offline level of blockchain node A 804a, an offline duration indicating how long blockchain node A 804a may remain offline), a list of blockchain clients 812 that may migrate from blockchain node A 804a to blockchain node A's neighboring nodes or its proxy nodes, etc.

[0137] In 832, if there are any blockchain clients 812, such as blockchain applications, that directly interact with and / or are associated with blockchain node A 804a (e.g., issue transactions to blockchain node A 804a, query transaction / block information from blockchain node A 804a), BMF 802 may also inform those clients 812 of blockchain node A 804a's offline schedule (e.g., offline level, offline duration, offline start time) and its proxy node (e.g., identifier / address of blockchain node B). BMF 802 instructs clients of blockchain node A 804a to interact with its proxy node when blockchain node A 804a is offline. Alternatively, BMF 802 may simply instruct clients of blockchain node A 804a to switch to using BMF 802 and blockchain middleware as proxies to indirectly interact with other blockchain nodes. Also, to improve reliability, the BMF 802 may request the blockchain client 812 to establish a connection with both the BMF and one or more proxy nodes of blockchain node A. If the BMF 802 selects some blockchain clients to go offline at 826, the BMF 802 may inform each of these selected blockchain clients of the determined offline schedule for them (e.g., when to go offline, how long to stay offline, whether and how many times the offline schedule may be repeated, etc.). The BMF 802 sends blockchain client instructions to the blockchain client 812 to instruct the blockchain client 812 with the following options: Alternatively, blockchain node A 804a may send these blockchain client instructions to the blockchain client 812.

[0138] In one example of the blockchain client instructions, the blockchain client 812 may stop generating any new blockchain transactions for a first specified period of time. In another example of the blockchain client instructions, the blockchain client should not generate new blockchain transactions that exceed a first specified rate. In another example of the blockchain client instructions, the blockchain client 812 may send new blockchain transactions to a new blockchain node. In one example of the blockchain client instructions, the blockchain client 812 may stop sending any new blockchain transactions for a second specified period of time. In another example of the blockchain client instructions, the blockchain client 812 may not send new blockchain transactions that exceed a second specified rate. In another example of the blockchain client instructions, the blockchain client 812 may send new blockchain transactions to the BMF 802. In another example of the blockchain client instructions, the blockchain client 812 may contact a third blockchain node as a proxy node for a fourth blockchain node. In another example of the blockchain client instructions, the blockchain client 812 may be notified that a fifth blockchain node is going offline and may be notified of the offline schedule of the fifth blockchain node.

[0139] The BMF 802 instructs the blockchain client 812 to access blockchain node B 804b, which may be selected as a proxy node for blockchain node A 804a.

[0140] The BMF 802 requests the blockchain client 812 to suspend interactions with blockchain nodes, including blockchain node A, until blockchain node A is online again after 842. To this end, the BMF 802 may communicate to the blockchain client 812 the length of time to be suspended, which should be equal to or greater than the offline duration of blockchain node A 804a. After 842, the blockchain client 812 may resume interactions with blockchain node A 804a.

[0141] If the blockchain client 812 was interfaced with the BMF 802, the BMF 802 may not notify the blockchain node A 804a of anything. Instead, the BMF 802 may allow the blockchain client 812 to continue sending any messages to the BMF 802. The BMF 802 may then simply buffer any received messages and send a quick acknowledgement to the blockchain client 812, telling it that the received messages may be fully processed later. When the blockchain node A 804a comes online, the BMF 802 may forward the buffered messages to the blockchain node A 804a, or may actively retrieve these buffered messages from the BMF 802 when the blockchain node A 804a comes online.

[0142] If the blockchain client 812 was not interfaced with the BMF 802, the BMF 802 may instruct it to use the BMF 802 as a proxy for blockchain node A 804a. The blockchain client 812 may then send any messages to the BMF 802, which may simply buffer any messages it receives and send a quick acknowledgement to the blockchain client, informing it that the received messages may be fully processed later, and when blockchain node A 804a comes online, the BMF 802 may forward the buffered messages to blockchain node A 804a, or may actively retrieve these buffered messages from the BMF 802 when blockchain node A 804a comes online.

[0143] At 834, the BMF 802 may send a message to blockchain node A 804a to instruct it to go offline. This message may include the identifier / address of the selected proxy for blockchain node A 804a (i.e., the identifier / address of blockchain node B 804b), the assigned offline schedule (e.g., the offline start time indicating when the blockchain node will start going offline, the assigned offline level, the offline duration indicating how long blockchain node A 804a may stay offline, if and how many times or for how long the offline schedule needs to be repeated, etc.). Note that if blockchain node A 804a is running an old offline schedule previously assigned by the BMF 802, the newly assigned offline schedule may replace the old schedule.

[0144] At 836, blockchain node A 804a may begin to go offline for the offline duration received at 834. When blockchain node A 804a remains offline, it may not receive or process normal blockchain transactions. Prior to going offline, blockchain node A 804a may alternatively send a blockchain client instruction to blockchain client 812 similar to the one sent by BMF 802 to blockchain client 812 at 832.

[0145] At 838, the blockchain client of blockchain node A 804a may send a hello or registration message to the proxy node of blockchain node A 804a.

[0146] At 838, the blockchain client 812 may continue to interact with other blockchain nodes 804b and / or 804c directly through the proxy node of blockchain node A 804a and / or indirectly through the BMF 802. At some point before 842, the BMF 802 may decide to wake up blockchain node A 804a earlier than the assigned offline schedule to keep the blockchain system operating normally, for example, if it detects that more other blockchain nodes are about to enter level 5 offline mode. Note that the BMF 802 may be able to communicate with blockchain node A 804a and wake up blockchain node A 804a when the offline level of blockchain node A 804a is, for example, offline level 1, offline level 2, offline level 3, or offline level 4. As a result, the BMF802 sends a wake-up command to the blockchain node A804a, which may include the identifier / address of the blockchain node A804a, the online start time of the blockchain node A804a, a new offline schedule, a synchronization command for the blockchain node A804a to synchronize itself with the normal blockchain, etc. Network entities in the underlying communication infrastructure, such as base stations and AMFs in the 5GS, may help relay the wake-up command to the blockchain node A804a via the underlying communication control signaling, such as application trigger services in the 5GS.

[0147] At 842, after a scheduled offline duration or triggered by the BMF 802 as part of 840, blockchain node A 804a may come back online.

[0148] At 844, blockchain node A 804a may send a message to the BMF 802 to announce that blockchain node A 804a is back online and to report its current blockchain capabilities and state. Blockchain node A 804a may also send the same message to its proxies (i.e., blockchain node B 804b) and its neighbors.

[0149] In 846, blockchain node A 804a may contact its proxy node (i.e., blockchain node B 804b) or other neighboring blockchain nodes to synchronize itself with the normal blockchain (e.g., to download normal blocks and transactions created when it was offline). If the BMF 802 maintains the entire normal blockchain, blockchain node A 804a may retrieve the missing transactions / blocks directly from the BMF 802, or since the BMF 802 knows the offline schedule of blockchain node A 804a, it may actively push the missing transactions / blocks to blockchain node A. If no proxy node was determined in 828, blockchain node A 804a may randomly select one of its neighboring nodes to retrieve the normal blockchain.

[0150] At 848, the BMF 802 optionally sends a message to clients of blockchain node A to inform them that blockchain node A 804a is now back online. As a result, these clients may switch to interact with blockchain node A 804a again.

[0151] 9 illustrates a passive off-chain BOOM. At 920, blockchain node A 904a may determine when to go offline according to its own offline schedule. Prior to 920, the BMF 902, blockchain nodes, and blockchain clients may have performed 820a, 820b, and / or 820c, as well as 822, and 824, as shown and discussed in FIG. 8. As a result, the BMF 902 may maintain a blockchain node repository and a blockchain client repository.

[0152] At 922, blockchain node A 904a may send a notification to the BMF 902 to indicate its own offline schedule (e.g., when it may go offline, at what offline level, and how long it may stay offline). Also, blockchain node A 904a may explicitly request the BMF 902 to select a proxy node for itself. If blockchain node A 904a must first go offline without sending such a notification to the BMF 902, its neighboring nodes may detect the offline state of blockchain node A 904a (e.g., when a neighboring blockchain node sends a transaction to blockchain node A and there is no response message from blockchain node A to its neighboring nodes) and notify the BMF 902 that blockchain node A 904a is now offline. In this case, 922, 924, and 926 may not be required. When a neighboring blockchain node sends such a notification to the BMF 902, the notification may include identifiers / addresses of both the neighboring blockchain node and blockchain node A 904a.

[0153] At 924, which is optional, the BMF 902 may determine one or more proxy nodes for blockchain node A 904a based on the information received from the notification at 922 and the information maintained in the blockchain node repository. The BMF 902 marks those proxy nodes (e.g., blockchain node B 904b) in the blockchain node repository. The BMF 902 may determine some new offline schedules for blockchain node A. The BMF 902 may also determine offline schedules (e.g., when to go offline, how long to stay offline, whether and how many times or for how long this offline schedule should be repeated, etc.) of one or more blockchain clients 906.

[0154] At 926, which is optional, the BMF 902 sends a response to the blockchain node A 904a. The response message may include the identifier / address of the proxy node determined for the blockchain node A 904a, or any instructions / hints that the blockchain node A 904a may use for blockchain synchronization when it wakes up in the future. The response may include the new offline schedule proposal that the BMF 902 determined at 924, and it may be up to the blockchain node A 904a to decide whether the blockchain node A 904a intends to stick to its own schedule or adopt the proposal from the BMF 902.

[0155] At 928, blockchain node A 904a may begin going offline for the offline duration.

[0156] At 930, the BMF 902 may send a message to each of blockchain node A 904a's neighboring nodes or its proxy nodes (i.e., blockchain node B 904b). This message may include the identifier / address of blockchain node A 904a, the assigned offline schedule of blockchain node A 904a (e.g., an offline start time indicating when blockchain node A 904a may begin to go offline, an assigned offline level of blockchain node A 904a, an offline duration indicating how long blockchain node A 904a may remain offline), a list of blockchain clients 906 that may migrate from blockchain node A 904a to blockchain node A's neighboring nodes or its proxy nodes, etc.

[0157] At 932, if there are any blockchain clients 906, such as blockchain applications, that directly interact with and / or are associated with blockchain node A 904a (e.g., issue transactions to blockchain node A 904a, query transaction / block information from blockchain node A 904a), the BMF 902 may also inform those clients 906 of the offline schedule (e.g., offline level, offline duration, offline start time) of blockchain node A 904a and its proxy node (e.g., identifier / address of blockchain node B). The BMF 902 instructs the clients of blockchain node A 904a to interact with its proxy node when blockchain node A 904a is offline. Alternatively, the BMF 902 may simply instruct the clients of blockchain node A 904a to switch to using the BMF 902 and blockchain middleware as proxies to indirectly interact with other blockchain nodes. Also, to improve reliability, the BMF 902 may request the blockchain client 906 to establish a connection with both the BMF and one or more proxy nodes of blockchain node A. If the BMF 902 selects some blockchain clients to be offline at 924, the BMF 902 may inform each of these selected blockchain clients of the determined offline schedule for them (e.g., when to go offline, how long to stay offline, whether and how many times the offline schedule may be repeated, etc.). The BMF 902 sends blockchain client instructions to the blockchain client 912 to instruct the blockchain client 912 with the options to follow. Alternatively, blockchain node A 904a may send these blockchain client instructions to the blockchain client 912. 932 is similar to 832 described in FIG. 8.

[0158] At 934, the blockchain client of blockchain node A 904a may send a hello or registration message to the proxy node of blockchain node A 904a.

[0159] Figure 10 shows on-chain BOOM, where blockchain nodes manage their offline schedules autonomously and decentralized, also leveraging online blockchain operations / mechanisms such as blockchain transactions and blockchain smart contracts.

[0160] The BMF 1002 may be optional and may be utilized to provide some offline management related policies or rules to the blockchain nodes 1002a-1002e, but may not maintain a blockchain node repository (or a blockchain client repository) and may not decide the next blockchain node to go offline. In other words, all offline decisions may be decided entirely in a decentralized manner based on a specific consensus protocol (implemented among blockchain nodes), as mentioned in the following text. A new blockchain (e.g., a designated channel in the Hyperledger Fabric), called a Management-Purpose Blockchain (MPB), may be designed and dedicated for such on-chain BOOM. Alternatively, the MPB may be the same as a regular blockchain that operates when online. Two on-chain BOOM approaches are proposed.

[0161] In one approach, shown in FIG. 11, blockchain node A 1104a may actively request to go offline and may solicit another blockchain node B 1104b as its proxy when node A 1104a goes offline. The other blockchain nodes may verify and approve such a request. Finally, blockchain node A 1104a may initiate its offline schedule. An offline management smart contract is designed to coordinate this process.

[0162] An offline management smart contract is created and stored in the MPB. When the blockchain node A1104a needs to go offline, it generates an offline management transaction and sends it to the MPB to trigger the existing offline management smart contract. As a result, the offline duration and proxy node for the blockchain node A1104a may be automatically determined based on the corresponding offline management smart contract.

[0163] In another approach shown in FIG. 12, each blockchain node 1204a, 1204b, and / or 1204c may periodically and independently report its blockchain capability and / or status to the MPB. A special consensus protocol may then be designed to autonomously select the appropriate blockchain nodes to go offline. For example, a Proof of Blockchain Capability (PoBC) may be designed to allow the blockchain nodes 1204a, 1204b, and / or 1204c with the minimum blockchain capability to be selected and go into offline mode for a certain amount of time. All blockchain nodes 1204a, 1204b, and / or 1204c may run such a special consensus protocol to reach a consensus on a new blockchain node and stay offline for a certain time interval, after which they may come back online.

[0164] In comparison, the first approach in FIG. 11 is based on smart contracts and requires creating and maintaining an offline management smart contract, which causes extra overhead, especially when there are not many blockchain nodes that require offline scheduling. For example, an existing offline management smart contract may expire, and as a result, a new smart contract needs to be created again since existing smart contracts on the MPB cannot be modified. However, one advantage of the first approach is that it has less overhead because the determination of offline nodes and their proxy nodes does not depend on the consensus protocol but is based on what is specified in the offline management smart contract, compared to the second approach.

[0165] The second approach of FIG. 12 does not use any smart contracts, but each blockchain node needs to periodically report its blockchain capabilities and / or status to the MPB to execute the protocol, which causes extra overhead, especially if such reporting needs to become more frequent. However, the second approach does not have the overhead of creating and maintaining an offline management smart contract. Also, if the offline management consensus protocol needs to be updated, it can be easily done by a software update, without the need to modify the MPB or create new transactions. In common, both approaches provide a decentralized and autonomous decision of blockchain nodes to go offline.

[0166] BMF / BOOM may be a logical functional entity and may perform the following functions in on-chain blockchain offline operation management: (1) configure blockchain nodes with some necessary configuration information, such as policies and rules for on-chain blockchain offline operation management, and (2) create offline management smart contracts and store them in the MPB.

[0167] In addition, BOOM in a blockchain node may be a logical functional entity and may perform the following functions in on-chain offline operation management: (1) receiving offline management related configuration information from BMF / BOOM, (2) generating offline management transactions to MPB to trigger offline management smart contracts, (3) verifying and executing offline management smart contracts, (4) generating offline management transactions to report the blockchain capabilities of the blockchain node to MPB for being known by all blockchain nodes, and (5) participating in the offline management consensus protocol to automatically determine offline management results in a decentralized and autonomous manner.

[0168] In on-chain blockchain offline operation management, BOOM in BMF may have much less functionality than BOOM in BMF for off-chain blockchain offline operation management. In on-chain blockchain offline operation management, BOOM in blockchain nodes act as the role of logical BOOM server and client. BMF and BMF / BOOM can be used interchangeably unless explicitly stated. Similarly, blockchain nodes have BOOM by default unless explicitly stated. The BOOM functionality proposed in this invention includes both BOOM in BMF and BOOM in blockchain nodes.

[0169] As an extension, the proposed BMF / BOOM may be defined as a logical role / function (instead of acting as a centralized physical node), i.e., the BMF / BOOM may be operated by different physical nodes. For example, different blockchain nodes may be considered as physical nodes, and among them, they may vote and select one node that is the node with BMF / BOOM and perform the proposed BOOM function as described above. For example, the physical nodes may perform a specific voting or consensus protocol to determine which physical blockchain node is acting as a BMF / BOOM node during a certain time interval. After such node is determined, all blockchain nodes may be notified. Such a BMF node selection process may be re-performed or triggered periodically. In addition, if the proposed BOOM makes any offline decision for a blockchain node, the decision may be made in a system-wide manner. For example, instead of determining whether a particular blockchain node should go offline or not, the BMF / BOOM may make a global decision for a list or group of blockchain nodes. Alternatively, when deciding whether a particular blockchain node should go offline, BMF / BOOM may take into account previous decisions made for other blockchain nodes.

[0170] FIG. 11 illustrates one proposed approach for on-chain BOOM. At 1120, which may be optional, the BMF 1102 may configure each blockchain node 1104a, 1104b, and 1104c with some necessary information for offline operation management. For example, the BMF 1102 may first inform each blockchain node 1104a, 1104b, and 1104c whether it is allowed to go offline or implement an offline schedule. The BMF 1102 may also configure some offline conditions under which a blockchain node may require an offline schedule. The BMF 1102 may also provision an offline schedule for blockchain nodes that are allowed to go offline.

[0171] At 1122, the BMF 1102 may formulate an offline management smart contract, create a new transaction including the offline management smart contract, and send the new transaction to the MPB. As a result, the offline management smart contract may eventually be stored in the MPB. The offline management smart contract may define a list of input parameters such as an offline schedule, a list of blockchain nodes that are allowed to go offline, offline conditions under which a blockchain node may request an offline schedule, proxy conditions under which a blockchain node may act as a proxy for one or more offline blockchain nodes, costs that blockchain node A 1104a must pay if blockchain node A 1104a goes offline, and rewards that another blockchain node B 1104b may collect from blockchain node A 1104a if blockchain node B 1104b acts as a proxy for blockchain node A 1104a when blockchain node B 1104b goes offline. The blockchain node may use the earned reward to request and pay for future offline schedules.

[0172] For example, the BMF 1102 may create one offline management smart contract for all blockchain nodes to use. The BMF 1102 may also create a different offline management smart contract for and to be used by each blockchain node. Alternatively, each blockchain node may create its own and similar offline management smart contract based on the requirements of each blockchain node and the information received from the BMF 1102 at 1120. The created smart contract may include information similar to that described above for the offline management smart contract created by the BMF 1102. For this scenario, the blockchain node A 1104a formulates the offline management smart contract, creates a new transaction including the offline management smart contract, and sends the new transaction to the MPB.

[0173] At 1124, the other blockchain nodes 1104a, 1104b, and / or 1104c may receive the offline management smart contract from the MPB and participate in the offline management according to the offline management smart contract. For example, each blockchain node 1104a, 1104b, and / or 1104c may start monitoring and collecting parameters, such as blockchain capabilities, as described in the offline management smart contract.

[0174] At 1126, if an offline condition is met in the blockchain node A 1104a (e.g., if the blockchain node has significantly reduced communication capabilities and / or reduced computation capabilities), the blockchain node A 1104a may generate a new offline management transaction with a certain probability, which may be specified in the offline management smart contract. As an example, a new offline management transaction that requests a longer offline period may be generated with a lower probability, so that a certain number of blockchain nodes may always be online. When a new offline management transaction is created, the blockchain node A 1104a sends the new offline management transaction to the MPB to address and trigger the target offline management smart contract stored in the MPB.

[0175] The purpose of sending this offline management transaction is to request that blockchain node A 1104a enter offline mode for a certain time interval. The time interval may be included in this offline management transaction and provided as an input parameter to the target offline management smart contract, or may be a fixed value specified by and included in the target offline management smart contract. This offline management transaction may include the expected offline level.

[0176] In this offline management transaction, the blockchain node A 1104a may designate another blockchain node B 1104b as its proxy after entering offline mode. The selection of the blockchain node B 1104b as the proxy may be included in the target offline management smart contract. For example, there may be multiple offline management smart contracts stored in the MPB, and each offline management smart contract has a different proxy node.

[0177] At 1128, the other blockchain nodes 1104a, 1104b, and / or 1104c may receive and validate the new offline management transaction. Invalid offline management transactions may be discarded without further processing. For example, if an offline management transaction does not include or provide a complete list of input parameters required by the target offline management smart contract, it may be considered invalid and may be discarded. Those input parameters then execute the offline management consensus protocol. The winner of the offline management consensus protocol may execute the corresponding target offline management smart contract (i.e., the one triggered by the offline management transaction) and act as a proxy for blockchain node A 1104a when it goes offline. The execution of the target smart contract may determine which blockchain nodes should go offline and the corresponding offline schedule (e.g., when to go offline, how long to go offline, whether and how many times or for how long this offline schedule should be repeated).

[0178] At 1130, as a result of the execution of the offline management consensus protocol and / or the target offline management smart contract, the offline schedule (e.g., offline level, offline start time, offline duration) and proxy node of blockchain node A 1104a may be agreed upon. Then, the winner (e.g., blockchain node B 1104b) adds the offline management transaction and the consensus result (i.e., the offline schedule and the proxy node) to the MPB and announces them to all other blockchain nodes. As an example, if a proxy node is specified in the offline management transaction at 1126, the proxy node may be the winner of the offline management consensus protocol.

[0179] At 1132, blockchain node A 1104a may receive the announcement sent by the winner of the offline management consensus protocol at 1130. Blockchain node A 1104a may go offline according to the agreed-upon offline schedule.

[0180] At 1134, if there are blockchain clients, such as blockchain applications, interacting with and / or associated with blockchain node A 1104a, blockchain node A 1104a may notify its offline schedule and its proxy nodes. In essence, blockchain node A instructs blockchain node A's clients to interact with blockchain node A's proxy nodes when blockchain node A is offline.

[0181] At 1136, blockchain node A 1104a may go offline for the time interval agreed upon and announced at 1130. During this period, blockchain node A 1104a may not receive or process regular blockchain transactions.

[0182] At 1138, which may be optional, the blockchain client 1106 of blockchain node A 1104a may send a hello or registration message to the proxy node of blockchain node A 1104a.

[0183] At 1140, after the scheduled offline duration, blockchain node A 1104a may come back online.

[0184] At 1142, blockchain node A 1104a may send a new transaction to the MPB to announce that blockchain node A 1104a is back online.

[0185] At 1144, blockchain node A 1104a may contact its proxy node (i.e., blockchain node B) to synchronize itself with the regular blockchain (e.g., to download regular transactions / blocks that were created when blockchain node A 1104a was offline). The process shown in FIG. 13 may be utilized for this synchronization.

[0186] At 1146, blockchain node A 1104a may optionally send a message to its clients 1106 informing them that it is now back online. As a result, these clients may switch to interact with blockchain node A 1104a again.

[0187] As shown in FIG. 11, the BMF 1102 may optionally be designed and implemented to have the full functionality of a blockchain node, in which case the BMF 1102 may receive transactions and blocks and host a blockchain including an MPB.

[0188] FIG. 12 shows another approach for on-chain BOOM. At 1220, the BMF 1202 may configure each blockchain node with some necessary information of offline management. This is optional and may be similar to 1120 of FIG. 11. For example, the BMF 1202 informs each blockchain node 1204a, 1204b, and / or 1204c whether it is allowed to go offline or implement an offline schedule. The BMF 1202 may configure some offline schedule conditions under which a blockchain node may request an offline schedule. The BMF 1202 may also provision offline schedules for the blockchain nodes 1204a, 1204b, and / or 1204c that are allowed to go offline. Only the blockchain nodes that are allowed to go offline may participate in the consensus process at 1224.

[0189] As 1222, each blockchain node 1204a, 1204b, and / or 1204c may report its current blockchain capability by sending a new transaction to the MPB. The new transaction may include the following information: blockchain node identifier, current time, expiration time, offline flag, earliest offline time, expected offline duration, expected offline duration, neighboring nodes, and expected offline level. The blockchain node identifier may refer to the identifier or address of the blockchain node sending this new transaction. The current time may refer to the current time when this new transaction is sent. The blockchain capability may refer to the blockchain capability of the blockchain node sending this new transaction. As mentioned above, the blockchain capability may be composed of multiple variables. The expiration time may refer to the lifespan of the reported blockchain capability. The offline flag may refer to the blockchain node sending this new transaction is allowed to go offline. The earliest offline time may refer to the earliest time when the blockchain node sending this new transaction can or is willing to go offline. The expected offline duration may refer to the period during which the blockchain node will be offline. The neighboring nodes may refer to a list of blockchain nodes that are one-hop neighbors of the blockchain node sending this new transaction. The expected offline level may refer to the expected offline level that the blockchain node may enter.

[0190] At 1224, each blockchain node 1204a, 1204b, and / or 1204c may implement the same offline management consensus protocol (e.g., PoBC) to determine the next blockchain node that may go offline.

[0191] As an example, at 1226, blockchain node A may win the consensus protocol. In other words, all other blockchain nodes agree that blockchain node A 1204a may be selected as the next blockchain node to go offline. As part of the completion of the consensus protocol, the offline duration of blockchain node A 1204a and optionally also a proxy node may be determined, which may be referred to as an offline management consensus result together with the identifier of blockchain node A 1204a.

[0192] At 1228, blockchain node A 1204a may generate a new block (referred to as an offline management block), which may include one or more transactions generated at 1222. Blockchain node A 1204a may send this new block to the MPB. The header of this new block may include the offline management consensus result, which may indicate the identifier or address of blockchain node A 1204a, the assigned offline level, the offline duration, the offline start time, whether this offline schedule may be repeated, how many times and for how long this offline schedule may be repeated, the identifier or address of a proxy node, etc.

[0193] At 1230, if there are blockchain clients, such as blockchain applications, interacting with and / or associated with blockchain node A 1204a, blockchain node A 1204a may inform blockchain node A 1204a's proxy node (e.g., blockchain node B 1204b) of blockchain node A 1204a's offline duration, where blockchain node A 1204a may instruct its clients 1206 to interact with blockchain node A 1204a's proxy node when blockchain node A 1204a is offline.

[0194] At 1232, blockchain node A may go offline for the offline duration determined at 1228. Blockchain node A may not receive or process any regular blockchain transactions.

[0195] As an option 1234, the blockchain client 1206 of blockchain node A 1204a may send a hello or registration message to the proxy node of blockchain node A 1204a.

[0196] At 1236, after the scheduled offline duration, blockchain node A 1204a may come back online.

[0197] At 1238, blockchain node A 1204a sends a new transaction to the MPB to announce that blockchain node A 1204a is back online and to report its current blockchain capabilities.

[0198] At 1240, blockchain node A 1204a contacts its proxy node (i.e., blockchain node B 1204b) to synchronize itself with the normal blockchain (e.g., to download normal transactions / blocks created when blockchain node A 1204a was offline). If no proxy node was determined at 1226, blockchain node A 1204a may randomly select one of its neighboring nodes to retrieve the normal blockchain. The process described in FIG. 13 may be utilized for this synchronization.

[0199] At 1242, which may be optional, blockchain node A 1204a may send a message to its clients informing them that it is now back online. As a result, these clients may switch back to interacting with blockchain node A 1204a.

[0200] 12, the BMF 1202 may optionally be designed and implemented to have the full functionality of a blockchain node, in which case the BMF 1202 may receive transactions and blocks and host a blockchain that includes an MPB.

[0201] When blockchain node A 1204a goes offline for a specified offline duration and then wakes up. Blockchain node B 1204b and blockchain node C 1204c are neighboring or proxy nodes when blockchain node A 1204a goes offline. BMF 1202 may maintain the blockchain capabilities and states of all blockchain nodes, including blockchain node B 1204b and blockchain node C 1204c. Now, blockchain node A 1204a may need to synchronize itself with the latest normal blockchain that blockchain node B 1204b and blockchain node C 1204c may have and act as a blockchain synchronization helper for blockchain node A 1204a. It should be noted that during synchronization, the synchronization helper should not go offline based on the offline operation management proposed in the present invention. For example, the helper should indicate to BMF 1202 that it has no intention of going offline for the ongoing synchronization process. The blockchain synchronization proposed in the present invention may be more efficient than all existing solutions because there is no coordination and offline operation management between different blockchain nodes.

[0202] FIG. 13 shows a procedure for blockchain node A 1304a to synchronize itself with a normal blockchain. At 1320, blockchain node A 1304a wakes up after staying offline for an offline duration. At 1322, which may be optional, if the BMF 1302 maintains a blockchain node repository, blockchain node A 1304a sends a request to the BMF 1302 to check the current state of its neighboring nodes or its proxy nodes. This request may also solicit a synchronization command from the BMF 1302. This request may include identifiers / addresses of blockchain node A 1304a's neighboring / proxy nodes (e.g., identifiers / addresses of blockchain node B 1304b and blockchain node C 1304c). If the procedure described at 1322 is not required, the procedures described at 1324, 1326, 1328, and 1330 may be skipped. The request may also include additional contextual information about blockchain node A 1304a, such as its current location and available communication connectivity / bandwidth, and the request may also include an identifier or sequence number of the most recent transaction / block stored by blockchain node A 1304a.

[0203] At 1324, the BMF 1302 may check the current capabilities and states of neighboring / proxy nodes of blockchain node A 1304a against the maintained capabilities and states of the blockchain nodes.

[0204] In 1326, the BMF 1302 may determine a synchronization command for blockchain node A 1304a by jointly considering multiple factors, including but not limited to the context information of blockchain node A 1304a (e.g., its current location and available communication connectivity / bandwidth), blockchain capabilities, and the state of blockchain node B 1304b and blockchain node C 1304c (e.g., the identifier or sequence number of the latest block they have, the identifier or sequence number of the unspent transaction they have stored, their current communication connectivity / bandwidth, their locations). If the BMF 1302 does not have the latest blockchain capabilities and state information for blockchain node B 1304b and blockchain node C 1304c, the BMF 1302 may send a request to them. As a result, blockchain node B 1304b and / or blockchain node C 1304c may each send a response to the BMF 1302 including their latest blockchain capabilities and states. The synchronization instructions may include a list of synchronization helpers, their addresses, available blocks and unspent transactions at each synchronization helper, and the order that blockchain node A1304a should use to contact the synchronization helpers. Similarly, previous neighbors / proxy nodes of blockchain node A1304a may be selected as synchronization helpers, but BMF1302 may use different algorithms to determine the appropriate helpers and synchronization instructions for blockchain node A1304a. For example, another blockchain node within the neighborhood of blockchain node A1304a may be preferred to be selected as a synchronization helper to reduce communication overhead. In another example, a blockchain node with higher processing power and more missing blocks / transactions may be selected as a preferred synchronization helper. In another example, a blockchain node with a lower probability of going offline in the future may be selected as a preferred synchronization helper.

[0205] At 1328, the BMF 1302 may contact each determined synchronization helper (e.g., blockchain node B 1304b and / or blockchain node C 1304c) and provide them with a synchronization token that may include or be based on the identifier / address of blockchain node A 1304a. The synchronization token may be unique to blockchain node A 1304a and may define how blockchain node A 1304a should contact the synchronization helper (e.g., at what time and for how long). As a result, the synchronization helper may utilize the synchronization token to verify that only blockchain node A 1304a is authorized to retrieve any missing blocks / transactions from the synchronization helper. If another blockchain node D requests to retrieve missing blocks / transactions from the synchronization helper (e.g., blockchain node B 1304b), the synchronization helper may reject the request if blockchain node D does not present a matching synchronization hint or token or if the way blockchain node D contacts the synchronization helper does not match what the synchronization token defines. Each synchronization helper may then evaluate the received synchronization token and determine whether or not it consents as a helper. Each synchronization helper may send a response to the BMF 1302 indicating consent or disagreement as a helper. If the synchronization helper disagrees, the manager node may remove the disagreement from the synchronization command sent to the blockchain node at 1330.

[0206] At 1330, the BMF 1302 may send a response to blockchain node A 1304a with the synchronization instructions determined at 1326 and 1328.

[0207] At 1332, blockchain node A 1304a contacts each synchronization helper to determine the longest branch of the blockchain. If 1322, 1324, 1328, and 1330 were skipped, blockchain node A 1304a may use the same process to contact its previous neighbor / proxy node to check the longest blockchain branch. First, blockchain node A 1304a may send a longest blockchain branch request to each synchronization helper. The request may include the identifier / address of blockchain node A 1304a, the identifier or sequence number of the most recent block that blockchain node A 1304a has, etc. Then, each synchronization helper sends a longest blockchain branch response to blockchain node A 1304a. The response includes the identifier / address of the last block of the longest blockchain branch.

[0208] At 1334, blockchain node A 1304a may select as the longest blockchain branch the blockchain branch reported by one or more synchronization helpers at 1332. The blockchain node that reported the longest blockchain branch may be selected as the final synchronization helper.

[0209] At 1336, blockchain node A 1304a contacts each final synchronization helper to retrieve the missing blocks and unspent transactions. First, blockchain node A 1304a may send a block / transaction request to each final synchronization helper. The request may include an identifier / address of blockchain node A 1304a, a range of missing blocks, a range of unspent transactions, etc. Then, each final synchronization helper sends a block / transaction response to blockchain node A 1304a. The response may include the contents of one or more missing blocks, one or more unspent transactions, etc.

[0210] At 1338, as an alternative to 1336 (particularly when there is no available synchronization helper or the process described at 1306 fails), blockchain node A 1304a may contact BMF 1302 to retrieve missing blocks and unspent transactions from BMF 1302 if BMF 1302 maintains and participates in normal blockchain operation. First, blockchain node A 1304a may send a block / transaction request to BMF 1302. The request may include an identifier / address of blockchain node A 1304a, a range of missing blocks, a range of unspent transactions, etc. Then, BMF 1302 may determine and contact other blockchain nodes to retrieve missing blocks and unspent transactions as requested by blockchain node A 1304a. Finally, BMF 1302 may send a block / transaction response to blockchain node A 1304a. The response may include the contents of one or more missing blocks, one or more unspent transactions, etc.

[0211] A blockchain node may go offline randomly without following a pre-scheduled offline schedule. Thus, other blockchain nodes may not be aware of the offline state of that blockchain node (particularly, they are in level 5 offline mode, for example). As part of the blockchain P2P routing protocol, each blockchain node maintains its neighboring blockchain nodes, which are neighboring blockchain nodes of other blockchain nodes. The neighboring blockchain nodes are appropriately positioned to detect and report offline blockchain nodes. Without loss of generality, assume that blockchain node A has two neighboring nodes, namely blockchain node B and blockchain node C. The following implementation is described for offline blockchain node detection.

[0212] In one implementation, neighboring blockchain nodes periodically and actively check their status with each other. Both blockchain node B and blockchain node C exchange periodic hello messages with blockchain node A. The hello messages may simply contain their identifiers / addresses and are used to verify each other's online status. For example, a hello message from blockchain node A to blockchain node B (or vice versa) may contain the identifiers / addresses of both nodes. If blockchain node A goes offline, there are several ways for blockchain node B (or blockchain node C) to detect this event.

[0213] If blockchain node A knows that it may go offline at a certain time t1, t1 may be included in a hello message to blockchain node B. After blockchain node B receives this hello message, blockchain node B may know when blockchain node A may go offline. Alternatively, blockchain node B may first send a hello message to blockchain node A. Then, blockchain node A may send a response message to blockchain node B and include t1 in the response message. Blockchain node B receives the response message and knows when blockchain node A may go offline.

[0214] If blockchain node A goes offline randomly, there will be no hello or reply message from blockchain node A to blockchain node B. In this case, blockchain node B may wait passively for a time interval and may consider blockchain node A an offline node if it does not receive a message from blockchain node A during that time interval. Alternatively, blockchain node B may send a hello message to blockchain node A requesting a reply. If blockchain node B does not receive a reply from blockchain node A, it may determine that blockchain node A is offline.

[0215] In another implementation, blockchain nodes passively estimate the state of their neighbors or themselves without using hello messages. If blockchain node A randomly goes offline at time t2, then at time t3, blockchain node B may receive a new transaction (or a new block), and blockchain node B forwards the new transaction (or a new block) to its neighbors, including blockchain node A, and expects to receive a response from each neighbor. If blockchain node B does not receive the expected response from blockchain node A within a period of time, blockchain node B may mark blockchain node A as an offline node.

[0216] In another implementation, blockchain node B is used to receive transactions (or blocks) from blockchain node A and other blockchain nodes. If blockchain node B suddenly stops receiving transactions (or blocks) from blockchain node A but not from other blockchain nodes, blockchain node B waits for a certain period of time. If the situation remains the same, blockchain node B may determine that blockchain node A is offline. If blockchain node B starts receiving any transactions / blocks from any other blockchain nodes for a long enough time, blockchain node B may consider itself an offline node.

[0217] In yet another implementation, the blockchain client helps detect offline blockchain nodes. If the blockchain client fails to interact with a current blockchain node, such as blockchain node A, it may select a new blockchain node B. The blockchain client may then inform blockchain node B that blockchain node A is no longer reachable. Blockchain node B may contact blockchain node A to confirm its status. If blockchain node B also cannot reach blockchain node A, blockchain node B may label blockchain node A as an offline node.

[0218] After blockchain node B detects that blockchain node A is offline, blockchain node B can take the following actions:

[0219] Blockchain node B may generate an offline node notification message that includes the identifier / address of blockchain node A. If blockchain node B knows the reason why blockchain node A is offline (e.g., suddenly offline, offline on schedule, etc.), it may also include the reason in the message. Blockchain node B may send that message to all neighboring nodes. The message may be forwarded by neighboring nodes so that all online blockchain nodes are aware of blockchain node A's offline state.

[0220] Blockchain node B may generate a special transaction that includes the identifier / address of blockchain node A and the reason why blockchain node A goes offline. Blockchain node B broadcasts this special transaction in the blockchain system. This special transaction may be received by all online blockchain nodes which validate it. A majority vote may be used for validation. For example, after receiving this special transaction, blockchain node C actively sends a hello message to blockchain node A to check and confirm its status as a neighbor node of blockchain node A. Blockchain node C may report the state of blockchain node A to the blockchain system. Other online blockchain nodes may do the same as blockchain node C. Finally, a majority rule may be used to determine the state of blockchain node A (i.e., online or offline). If more blockchain nodes confirm that blockchain node A goes offline, the final state of blockchain node A is offline. Otherwise, if blockchain node B reported that blockchain node A was offline, but more blockchain nodes confirm that blockchain node A is still reachable, the final state of blockchain node A is recorded as online. Finally, the online blockchain node (the node that wins the consensus protocol) may record the majority result (i.e., the final state of blockchain node A) in the blockchain, and all other online blockchain nodes will agree with this record. In this way, it is possible to prevent malicious nodes from falsely reporting the state of blockchain nodes.

[0221] When blockchain node B detects that it is offline or decides to go offline using its own offline schedule, it may contact the BMF to indicate blockchain node B's offline schedule and / or check whether the BMF can assign a proxy node to blockchain node B. If there is no BMF or assigned proxy node, blockchain node B may stay silent for a period of time after waking up to wait for any incoming transactions / blocks / messages from other blockchain nodes, and may periodically retry contacting blockchain node B's previous neighbors until it can connect with one of blockchain node B's neighbors. With such information from offline blockchain node detection, the BMF can know the latest status of all blockchain nodes and can implement more efficient blockchain offline operation management and blockchain synchronization.

[0222] Blockchain node B may add more other blockchain nodes as new neighboring nodes of blockchain node B. Blockchain node B may not immediately start forwarding transactions / blocks through these new neighboring nodes to avoid increasing communication overhead, but blockchain node B may use these new neighboring nodes as backups. In other words, when more old neighboring nodes become unavailable or unreachable, blockchain node B may start instructing the new neighboring nodes to forward (and / or receive) transactions / blocks through (and / or from) the new neighboring nodes.

[0223] 14 illustrates an example procedure for determining a proxy node for an offline blockchain node. In this scenario, it is assumed that (1) a blockchain client 1406 is associated with or interacts with blockchain node A 1404a, and (2) blockchain node A 1404a is currently offline or may become offline.

[0224] At 1420, the method for detecting an offline blockchain node described above is applied. Assume that blockchain node A 1404a is detected as an offline blockchain node or may become offline. Now, blockchain node A 1404a itself may indicate its preferred proxy nodes (e.g., blockchain node B 1404b and / or blockchain node C 1404c and / or other blockchain nodes with certain blockchain capabilities). Blockchain node B 1404b (and / or blockchain node C 1404c) may indicate its willingness to be a proxy node for blockchain node A 1404a or its willingness to be a proxy node for other blockchain nodes with certain blockchain capabilities. Blockchain client 1406 may indicate its preference for a proxy node for blockchain node A 1404a (e.g., an online blockchain node closer to the blockchain client may be preferred by the blockchain client).

[0225] Assume that blockchain node A 1404a is detected as offline or may be offline at 1422. Then, BMF 1402 may select a proxy node for blockchain node A 1404a according to the information derived at 1420 or some pre-configured proxy node selection rules. For example, if blockchain node A 1404a indicated blockchain node B 1404b as its preferred proxy node at 1420, BMF 1402 may simply select blockchain node B 1404b as the proxy node for blockchain node A 1404a. In another example, if a client of blockchain node A indicated that blockchain node C 1404c is a preferred proxy node when blockchain node A 1404a is offline at 1420, BMF 1402 may select blockchain node C 1404c as the proxy node for blockchain node B 1404b. In another example, BMF 1402 may select a proxy node based on the blockchain capabilities of online blockchain nodes. For example, in order to reduce blockchain synchronization overhead after blockchain node A 1404a wakes up, BMF 1402 may select blockchain node B 1404b (or blockchain node C 1404c) as a proxy node for blockchain node A 1404a if blockchain node B 1404b (or blockchain node C 1404a) is close to blockchain node A 1404a.

[0226] At 1424, as an alternative to the process described at 1422, the BMF 1402 may send a proxy node solicitation request to some or all of the currently online blockchain nodes (e.g., blockchain node B 1404b and / or blockchain node C 1404c) to check their willingness to be a proxy node for blockchain node A 1404a. The request may include the address / identifier of blockchain node A 1404a, the period of time to be a proxy node for blockchain node A 1404a, the number of blockchain clients that may be moved from blockchain node A 1404a, and the functions required as a proxy node (e.g., supporting blockchain clients, endorsing / validating transactions, participating in consensus protocols, and generating new blocks, etc.).

[0227] Then, blockchain node B 1404b (and / or blockchain node C 1404c) may send a proxy node solicitation response to the BMF 1402. This response indicates whether blockchain node B 1404b (or blockchain node C 1404c) is willing to be a proxy node for blockchain node A 1404a. This response may include the address / identifier of blockchain node B 1404b (or blockchain node C 1404c), the reason for refusing to be a proxy node, etc. Finally, if the BMF 1402 determines that blockchain node B 1404b (and / or blockchain node C 1404c) is a proxy node for blockchain node A 1404a, the BMF 1402 may send a proxy node solicitation confirmation to blockchain node B 1404b (and / or blockchain node C 1404c).

[0228] At 1426, as an alternative to the process described at 1422 or 1424, the BMF 1402 and the online blockchain nodes (e.g., blockchain node B 1404b and blockchain node C 1404c) may use smart contracts to select one or more proxy nodes in an autonomous and decentralized approach. For example, the BMF 1402 may first generate a proxy node selection smart contract and broadcast it over the blockchain system. Alternatively, blockchain node A 1404a may generate a proxy node selection smart contract and broadcast it over the blockchain system before going offline. The proxy node selection smart contract may include the address / identifier of blockchain node A 1404a, the cost that blockchain node A 1404a would like to pay to the selected proxy node, the number of proxy nodes that blockchain node A 1404a may require, the period required for the proxy, the blockchain capabilities required to be a proxy node, etc. All online blockchain nodes may receive the proxy node selection smart contract. If an online blockchain node (e.g., blockchain node B 1404b and / or blockchain node C 1404c) is willing to be a proxy node for blockchain node A 1404a, it executes a smart contract and participates in the consensus protocol. If the online blockchain node wins the consensus protocol, it generates a new transaction including the execution result of the proxy node selection smart contract and broadcasts it through the blockchain system. This blockchain node (blockchain node B 1404b and / or blockchain node C 1404c) that wins the consensus protocol may be automatically selected as a proxy node for blockchain node A 1404a. Blockchain node A may know the proxy node selected for blockchain node A, and therefore the process described in 1428 may not be required.

[0229] At 1428, a proxy node for blockchain node A 1404a is determined and known to the BMF 1402. The BMF 1402 may send a proxy node notification to blockchain node A 1404a. The request may include the address / identifier of the determined proxy node, the duration of the proxy, etc. The blockchain node A 1404a receives the notification and sends an acknowledgment to the BMF 1402. The blockchain node A 1404a may forward the notification to the blockchain client to instruct the blockchain client to interact with the determined proxy node when blockchain node A 1404a goes offline. The BMF 1402 may select itself as the proxy node for blockchain node A 1404a.

[0230] When a smart contract is executed, it usually needs to obtain some input data from an external entity (i.e., an oracle) in order to complete the execution of the smart contract. If the oracle goes offline or becomes inaccessible to the smart contract, all smart contracts that rely on this oracle may be affected and cannot execute successfully. Two methods have been proposed to solve this problem.

[0231] As shown in FIG. 15, multiple oracles (e.g., oracle-1 1502a, oracle-2 1502b, oracle-3 1502c) may be used. One oracle may be deployed as a primary oracle (e.g., oracle-1 1502a), and the other oracles may be secondary oracles (e.g., oracle-2 1502b and oracle-3 1502c) as backups for the primary oracle 1502a. These multiple oracles provide the same set of input data. When smart contract X is created and stored in the blockchain system (e.g., blockchain node A 1504), the addresses and / or access details of all these oracles (e.g., oracle-1 1502, oracle-2 1502b, oracle-3 1502c) may be included in smart contract X. Alternatively, blockchain node A 1504 may insert the addresses and / or access details of additional oracles into smart contract X 1506 when it wins the consensus protocol and begins adding smart contract X 1506 to new blocks.

[0232] In one example, oracle-1 1502a, oracle-2 1502b, and oracle-3 1502c first register (or announce themselves throughout the blockchain system) with blockchain node A 1508. A blockchain client then attempts to create smart contract X, which includes the address and / or access details of oracle-1 1502a, by sending a transaction including smart contract X to the blockchain system. Blockchain node A 1504 may then receive this transaction and identify that smart contact X 1506 depends on oracle-1. Blockchain node A 1504 may also identify that oracle-2 1502b and oracle-3 1502c provide similar input data as oracle-1 1502a does, meaning that oracle-2 1502b and oracle-3 1502c may be leveraged as backups when oracle-1 1502a goes offline and / or becomes unreachable. Blockchain node A 1504 then participates in the consensus protocol. Blockchain node A 1504 wins the consensus protocol and modifies smart contract X by adding the addresses and / or access details of oracle-2 1502b and oracle-3 1502c as backups for oracle-1 1502a. Here, smart contract X 1506 includes the addresses and / or access details of oracle-1 1502a, oracle-2 1502b, and oracle-3 1502c. Blockchain node A 1504 may create a new block that includes the modified smart contract X 1506 and broadcast the new block to other blockchain nodes. All blockchain nodes in the blockchain system receive the new block and store smart contract X 1506.When smart contract X 1506 is triggered, blockchain node A 1504 (or other blockchain node) may attempt to execute smart contract X 1506 by first contacting oracle-1 1502a to obtain some input data. If there is no response from oracle-1 1502a, blockchain node A 1504 (or other blockchain node) may contact oracle-2 1502b or oracle-3 1502c or other alternative oracles to obtain the same input data in order to successfully execute smart contract X 1506.

[0233] In another implementation, as shown in FIG. 16, an oracle proxy is proposed to interact with smart contract X 1606 on behalf of multiple original oracles (e.g., oracle-1 1602a, oracle-2 1602b, oracle-3 1602c). Each original oracle 1602a, 1602b, and 1602c may be registered with the oracle proxy 1608. Alternatively, the oracle proxy 1608 may advertise itself so that the original oracles 1602a, 1602b, and 1602c delegate themselves to the oracle proxy 1608. The oracle proxy 1608 may also actively search for other original oracles 1602a, 1602b, and 1602c and provide an "oracle proxy" service for them. As a result, the oracle proxy 1608 may maintain the addresses and / or access details of these original oracles 1602a, 1602b, and 1602c. When smart contract X 1606 is created, it may contain only the addresses and / or access details of oracle proxies 1602a, 1602b, and 1602c. When smart contract X 1606 is executed, blockchain node A 1604 (or other blockchain nodes) may contact the oracle proxy 1608 to obtain input data. The oracle proxy 1608 may contact oracle-1 1602a, oracle-2 1602b, or oracle-3 1602c to retrieve the requested input data and return it to blockchain node A 1604. If oracle-1 1602a goes offline, oracle proxy 1608 may contact oracle-2 1602b or oracle-3 1602c. If none of the maintained original oracles 1602a, 1602b, and / or 1602c are available, oracle proxy 1608 may search for other original oracles and retrieve the requested input data from them.Alternatively, if the input data provided by oracle-1 1602a, oracle-2 1602b, or oracle-3 1602c does not change rapidly, the oracle proxy 1608 may pre-fetch it from oracle-1 1602a, oracle-2 1602b, or oracle-3 1602c and buffer the pre-fetched input data locally, which may be used to service blockchain node A 1604 when it later retrieves the input data from the oracle proxy.

[0234] The proposed methods for blockchain offline operation management (e.g., off-chain BOOM, on-chain BOOM, blockchain synchronization, and offline blockchain node detection) may be deployed within 5G / 6G cellular networks.

[0235] 17 illustrates an example deployment in which a WTRU-A 1702, such as a smartphone, hosts a blockchain client X 1704, a WTRU-B 1706, such as a vehicle, hosts a blockchain node B 1708, and a blockchain node C 1712 is deployed within an edge network 1710 (e.g., hosted by an edge server). The blockchain node C 1712 may be accessed by the blockchain client X 1704. It may also be accessed by a 5G / 6G Network Function (NF) 1716, such as an AMF, NEF, etc.

[0236] Additionally, blockchain node D 1714 may be hosted in the 5G / 6G network 1718 or by a blockchain service provider, and blockchain client Y 1722 may be a remote client that may access the blockchain directly through blockchain node D 1714 or indirectly via the BMF 1718. The BMF / BOOM 1718 may be deployed as part of the 5G / 6G core network or outside the 5G / 6G core network (e.g., in the blockchain service provider's cloud).

[0237] All the proposed procedures may be implemented via the 5G / 6G data plane or control plane. For example, if the 5G / 6G control plane is used, the 5G / 6G NF 1716 may be utilized to relay messages between different entities, such as between the BMF 1720 and blockchain node C 1712, between the BMF 1720 and blockchain node B 1708, between the BMF 1720 and blockchain client X 1704, etc.

[0238] For example, assume that blockchain node B 1706 is currently offline, but WTRU-B 1706 may be triggerable by the 5G / 6G system (e.g., at offline level 3). If the BMF 1720 determines to wake up blockchain node B 1708 earlier than the previously determined offline duration, the BMF 1720 may be adapted to leverage a 5G / 6G application trigger service to wake up blockchain node B 1708 in the WTRU-B 1706. Specifically, the BMF 1720 may send a blockchain wake-up request to the 5G / 6G NF 1706 (e.g., NEF), which may relay the message to the WTRU-B via 5G / 6G device triggering signaling. After receiving the device triggering signaling from the NF 1716, the WTRU-B 1706 decodes the blockchain wake-up request and then wakes up the blockchain node B 1708 hosted thereon. Meanwhile, when the blockchain node B 1708 wakes up according to the previously determined offline schedule, it generates a notification message indicating the online status of the blockchain node B 1708. The WTRU-B 1706 may send the notification message to the 5G / 6G NF 1706 via 5G / 6G uplink signaling, and the 5G / 6G NF 1706 may forward the notification message to the BMF 1718.

[0239] In another example, the context information of the blockchain client X1704 is about or related to the context information of the WTRU-A1702, and the BMF1720 may obtain the context information of the WTRU-A1702 from the 5G / 6G NF1716 and infer the context information of the blockchain client X1704.

[0240] In another example, the BMF 1720 may also leverage the 5G / 6G NF 1716 to obtain context information of the WTRU-B 1706 and then estimate / obtain blockchain capability and state information of the blockchain node B 1708. In addition, the blockchain node B 1708 may leverage the 5G / 6G control plane and the 5G / 6G NF 1716 to relay the information to the BMF 1720 when reporting the blockchain capability and state information of the blockchain node B 1708 to the BMF 1720.

[0241] Although the features and elements are described above in certain combinations, one skilled in the art will understand that each feature or element may be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) 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 disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, a WTRU, a terminal, a base station, an RNC, or any host computer.

Claims

1. A method implemented by a first blockchain node, comprising: Sending a first message to a blockchain management function (BMF), the first message including information indicating a value indicating a time for the first blockchain node to change its state to offline and information indicating a capability of the first blockchain node; receiving a second message from the BMF, the second message including information indicating a blockchain proxy node selected for the first blockchain node; and transitioning to the offline state at the time indicated by the value.

2. The method of claim 1, wherein the first blockchain node is a wireless transmit / receive unit (WTRU).

3. The method of claim 1, wherein the first blockchain node sends the first message to the BMF.

4. The method of claim 1, wherein the first message indicates a preferred proxy node for the first blockchain node.

5. The method of claim 1, wherein a blockchain client indicates a preferred proxy node for the first blockchain node.

6. The method of claim 1, wherein the BMF selects a proxy node based on at least one of the capabilities of each node or the time at which the first blockchain node changes its state to offline.

7. The method described in claim 1, wherein the BMF includes a blockchain offline operations management (BOOM) as a logical function for managing offline operations of a blockchain node.

8. A first blockchain node, A receiver; A transmitter; a processor; The transmitter is configured to send a first message to a blockchain management function (BMF), the first message including information indicating a value indicating a time at which the first blockchain node changes its state to offline and information indicating a capability of the first blockchain node; The receiver is configured to receive a second message from the BMF, the second message including information indicating a blockchain proxy node selected for the first blockchain node; A first blockchain node, wherein the processor is configured to transition to the offline state at the time indicated by the value.

9. The first blockchain node of claim 8, wherein the first blockchain node is a wireless transmit / receive unit (WTRU).

10. The first blockchain node of claim 8, wherein the transmitter is further configured to transmit the first message to the BMF.

11. A first blockchain node as described in claim 8, wherein the first message indicates a preferred proxy node for the first blockchain node.

12. A first blockchain node as described in claim 8, wherein a blockchain client indicates a preferred proxy node of the first blockchain node.

13. The first blockchain node of claim 8, wherein the BMF selects a proxy node based on at least one of the capabilities of each node or the time at which the first blockchain node changes its state to offline.

14. The first blockchain node described in claim 8, wherein the BMF includes a blockchain offline operation management (BOOM) as a logical function for managing offline operation of the blockchain node.

15. A method performed by a first blockchain node, comprising: Sending a first message to a second blockchain node requesting a state of the second blockchain node; receiving a second message from the second blockchain node, the second message including information indicating a value indicating a time for the second blockchain node to change its state to offline; sending a third message to a third blockchain node, the third message including the state of the first blockchain node, the state of the second blockchain node, and the time at which the second blockchain node changes state to offline.

Images