Method and apparatus for blockchain-aware mobile vehicle communication

Abstract

This application relates to methods and apparatus for blockchain-aware mobile vehicle communications for 3GPP (Third Generation Partnership Project). A method of wireless communication performed by a user equipment (UE), such as a vehicle UE (VUE), includes receiving configuration information for a blockchain application, transmitting information associated with a candidate block for the blockchain application, and receiving a response related to the candidate block.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application generally relate to wireless communication technology, and more specifically, to methods and devices for blockchain-aware mobile vehicle communication for 3GPP (Third Generation Partnership Project). BACKGROUND

[0002] Vehicle-to-Everything (V2X) has been introduced into 5G wireless communication technology. In terms of channel structure for V2X communication, a direct link between two user equipments (UEs) is referred to as a sidelink (SL). The sidelink is a Long Term Evolution (LTE) feature introduced in 3GPP Release 12 and enables direct communication between nearby UEs, and data does not need to go through a base station (BS) or core network.

[0003] Next generation mobile communication systems such as, for example, B5G (beyond 5G) or even 6G, are expected to become a service framework in which data is collected, processed, and transmitted in an intelligent manner. In order to securely share and store data in the framework, decentralized trust is more attractive than a centralized trust architecture to accommodate various next generation mobile communication systems. Supporting a large number of user equipments (UEs) with services having various quality of service (QoS) or quality of experience (QoE) requirements requires various communication systems. A blockchain application system is a promising enabler of decentralized trust by utilizing a distributed consensus mechanism such as proof of work (PoW).

[0004] Currently, in 3GPP 5G, B5G, or even 6G systems or the like, details about how to adopt a blockchain application in a mobile vehicle communication network have not been explicitly discussed in 3GPP technology. SUMMARY

[0005] Some embodiments of the present application provide a wireless communication method. The method can be performed by a UE (e.g., a vehicle UE (VUE)). The method includes receiving configuration information of a blockchain application, transmitting information associated with a candidate block of the blockchain application, and receiving a response related to the candidate block.

[0006] Some embodiments of the present application also provide a wireless communication device. The device includes a non-transitory computer-readable medium having stored thereon computer-executable instructions, receiving circuitry, transmitting circuitry, and a processor coupled to the non-transitory computer-readable medium, the receiving circuitry, and the transmitting circuitry, wherein the computer-executable instructions cause the processor to implement the above-mentioned method performed by a UE.

[0007] Some embodiments of the present application provide a method of wireless communication. The method can be performed by an infrastructure node (e.g., a BS or a road side unit (RSU)). The method includes receiving, from a UE, information associated with a candidate block of a blockchain application; and transmitting a response related to the candidate block.

[0008] Some embodiments of the present application provide a device of wireless communication. The device includes a non-transitory computer-readable medium having computer-executable instructions stored thereon; receiving circuitry; transmitting circuitry; and a processor coupled to the non-transitory computer-readable medium, the receiving circuitry, and the transmitting circuitry, wherein the computer-executable instructions cause the processor to implement the above-mentioned method performed by an infrastructure node.

[0009] Some embodiments of the present application provide a method of wireless communication. The method can be performed by a UE or an infrastructure node (e.g., a BS or a RSU). The method includes receiving configuration information of a blockchain application; receiving, from a blockchain network node, information associated with a candidate block of the blockchain application; determining whether a validation operation is enabled; and in response to determining that the validation operation is enabled, performing the validation operation.

[0010] Some embodiments of the present application also provide a device of wireless communication. The device includes a non-transitory computer-readable medium having computer-executable instructions stored thereon; receiving circuitry; transmitting circuitry; and a processor coupled to the non-transitory computer-readable medium, the receiving circuitry, and the transmitting circuitry, wherein the computer-executable instructions cause the processor to implement the above-mentioned method performed by a UE or an infrastructure node. BRIEF DESCRIPTION OF DRAWINGS

[0011] In order to describe the manner in which the application can be obtained, a description of the application is presented in the following description and claims. This description is presented solely for the purpose of enabling a person skilled in the art to practice the application. Substantially, the application can be practiced without these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the application has not been described in detail so that the application is not unnecessarily obscured.

[0012] Figure 1 A diagram illustrating a vehicle network integrating a blockchain in accordance with some embodiments of the present application is shown.

[0013] Figure 2 An exemplary structure of a blockchain in accordance with some embodiments of the present application is shown.

[0014] Figure 3 A diagram illustrating the occurrence of a forking event in a blockchain network in accordance with some embodiments of the present application is shown.

[0015] Figure 4An exemplary flow diagram illustrating a method of wireless communication according to some embodiments of the present application.

[0016] Figure 5 Another flow diagram illustrating a method of wireless communication according to some embodiments of the present application.

[0017] Figure 6 Another exemplary flow diagram illustrating blockchain-aware mobile vehicle communication according to some embodiments of the present application.

[0018] Figure 7 Another exemplary flow diagram illustrating blockchain-aware mobile vehicle communication according to some embodiments of the present application.

[0019] Figure 8 And 9 A schematic diagram illustrating latency bound information in time domain according to some embodiments of the present application.

[0020] Figure 10 Yet another exemplary flow diagram illustrating blockchain-aware mobile vehicle communication according to some embodiments of the present application.

[0021] Figure 11A An exemplary flow diagram illustrating a method for broadcasting blockchain related information according to some embodiments of the present application.

[0022] Figure 11B Another exemplary flow diagram illustrating a method for broadcasting blockchain related information according to some embodiments of the present application.

[0023] Figure 12 An exemplary flow diagram illustrating a method for performing consistency calibration of a block of a blockchain according to some embodiments of the present application.

[0024] Figure 13 An exemplary flow diagram illustrating a method for updating a blockchain application according to some embodiments of the present application.

[0025] Figure 14 A flow diagram illustrating a method for verifying a candidate block of a blockchain application according to some embodiments of the present application.

[0026] Figure 15 A block diagram of an exemplary device according to some embodiments of the present application. DETAILED DESCRIPTION

[0027] The detailed description set forth below, in connection with the appended drawings and embodiments of the application, is intended as a description of the preferred embodiments of the application and is not intended to represent the only forms in which the present application can be practiced. It will be understood that the same or equivalent functions can be accomplished by different embodiments that are

[0028] Reference will now be made in detail to some embodiments of the application, examples of which are illustrated in the accompanying drawings. In order to facilitate the understanding of the embodiments, the embodiments are provided under a specific network architecture and new service scenarios, such as 3GPP 5G, 3GPP LTE Release 8, B5G, 6G, etc. It is contemplated that all the embodiments in the present application are also applicable to similar technical problems as the network architecture and new service scenarios are developed; and furthermore, the terms cited in the present application can change, which should not affect the principles of the present application.

[0029] Currently, in 3GPP 5G, B5G or even 6G systems or the like, the motivation of vehicle networks to adopt blockchain applications stems from the following features: on the one hand, vehicle networks need secure information sharing to achieve autonomous, connected and intelligent functions; and on the other hand, different vehicle network applications are usually limited within their own ecosystems, which makes it difficult to share authenticated information between different applications. The present application integrates blockchain applications into vehicle networks, as examples described below. The problems and solutions provided in the present application can also be applicable to other mobile communication systems, such as unmanned aerial vehicle networks, Internet of Things (IoT), etc.

[0030] In 3GPP standard documents, 25 use cases for advanced V2X services have been identified and classified into four use case groups; vehicle platooning, extended sensors, advanced driving and remote driving. In order to achieve these 25 use cases, data measurement, storage and exchange need to be carried out in a secure manner among vehicle UEs (VUEs) or between UEs and infrastructure nodes. The VUEs in the blockchain system can also be named VUE miners and miner VUEs. The infrastructure nodes can be road side units (RSUs), BSs or networks. An example system model of integrating blockchain into vehicle networks is shown in Figure 1 Description.

[0031] Figure 1 A schematic diagram of a vehicle network integrating blockchain according to some embodiments of the present application is shown.

[0032] In particular, for illustrative purposes, Figure 1 The vehicle network integrating blockchain in FIG. 1 includes four VUEs (i.e., VUE1, VUE2, VUE3 and VUE4), two BSs (i.e., BS1 and BS2) and one RSU. The BSs and RSU can be named by the joint name "infrastructure nodes". The RSU can be a UE-type RSU. Although Figure 1 Although a specific number of VUEs and BSs and RSUs are depicted in FIG. 1, it is contemplated that any number of VUEs and BSs and RSUs can be included in the vehicle network shown in FIG. 1. Figure 1

[0033] Figure 1 ​A VUE in a network can include a computing device, such as a desktop computer, a laptop computer, a personal digital assistant (PDA), a tablet computer, a smart television (e.g., a television with Internet connectivity), a set-top box, a game console, a security system (including security cameras), a vehicle computer, a network device (such as a router, switch, and modem), or the like. According to some embodiments of the present application, a VUE can include a portable wireless communication device, a smart phone, a cellular telephone, a flip phone, a device with a subscriber identity module, a personal computer, a selective call receiver, or any other device capable of sending and receiving communication signals on a wireless network.

[0034] In some embodiments of the present application, a VUE includes a wearable device, such as a smart watch, a fitness band, an optical head-mounted display, or the like. Further, a VUE can be referred to as a subscriber unit, a mobile device, a mobile station, a user, a terminal, a mobile terminal, a wireless terminal, a fixed terminal, a subscriber station, a user terminal, or a device, or described using other terminology used in the art. A VUE can communicate directly with a BS via an LTE or NR Uu interface.

[0035] Figure 1 A vehicle network in a network can be compatible with any type of network capable of sending and receiving wireless communication signals. For example, a vehicle network is compatible with a wireless communication network, a cellular telephone network, a time-division multiple access (TDMA) based network, a code-division multiple access (CDMA) based network, an orthogonal frequency-division multiple access (OFDMA) based network, an LTE network, a 3GPP based network, a 3GPP 5G network, a satellite communication network, a high altitude platform network, and / or other communication network.

[0036] In some embodiments of the present application, a vehicle network is compatible with 5G NR of the 3GPP protocol, where Figure 1 A BS in a network transmits data using an OFDM modulation scheme on the downlink (DL) and a VUE transmits data using a discrete Fourier transform-spread-orthogonal frequency-division multiplexing (DFT-S-OFDM) or a cyclic prefix-OFDM (CP-OFDM) scheme on the uplink (UL). However, more generally, Figure 1 A vehicle network in a network can implement some other open or proprietary communication protocol, such as WiMAX, among other protocols.

[0037] In some embodiments of the present application, Figure 1The BS can communicate using other communication protocols, such as the IEEE 802.11 series of wireless communication protocols. Furthermore, in some embodiments of this application, the BS can communicate via licensed spectrum, while in other embodiments, the BS can communicate via unlicensed spectrum. This application is not intended to limit itself to any particular wireless communication system architecture or protocol implementation. In still other embodiments of this application, the BS can communicate with the VUE using the 3GPP 5G protocol.

[0038] Specifically, Figure 1 The embodiments assume that, Figure 1 The VUE1, VUE2, and VUE3 shown are used as mining VUEs in a vehicle network integrating blockchain. They are categorized based on how they connect to infrastructure nodes. Infrastructure nodes include BS1, BS2, and RSUs connected via backhaul links. VUE1 is directly connected to its serving BS1 via a Uu link. That is, VUE1 operates in V2X mode 1. VUE2 is connected to a UE-type RSU via a side link. That is, VUE2 operates in V2X mode 2. VUE3 is outside the coverage area of ​​the BS and is connected to VUE4 via a side link. VUE4 acts as a relay to provide connectivity between VUE3 and BS2. VUE4 is a relay UE. That is, VUE3 and VUE4 operate in V2X mode 2 and V2X mode 1, respectively.

[0039] Figure 2 This application illustrates exemplary structures of blockchains according to some embodiments.

[0040] Figure 2 The examples illustrate the basic structure of a blockchain (or ledger). A blockchain may include one or more blocks. Each block includes a block header and a block body. The block header includes the hash value of the block associated with a previous block in the blockchain. The block body contains transaction records, which are named "data".

[0041] like Figure 2 As shown, the blockchain comprises multiple blocks, each containing three blocks (Block#n, Block#n+1, and Block#n+2). Each of Block#n, Block#n+1, and Block#n+2 includes a block header and a block body. Specifically, the block header of Block#n includes the hash of #n-1, the block header of Block#n+1 includes the hash of #n, and the block header of Block#n+2 includes the hash of #n+1.

[0042] Taking Bitcoin as an example, the block header has 80 bytes, which includes a 4-byte version number, a 32-byte hash value of the previous block, a 32-byte Merkle root hash value, a 4-byte timestamp (current time), a 4-byte computation difficulty value, and a 4-byte random number.

[0043] Blockchain can also be named ledger or blockchain application. Running a blockchain in a vehicle network mainly includes the following steps:

[0044] 1. Collect new data into a candidate block of the blockchain. The candidate block can be named new block or prospective block.

[0045] 2. Perform PoW computation procedure on the candidate block.

[0046] 3. When the PoW computation procedure is completed, the candidate block will be broadcast to the blockchain network. The blockchain network includes all network nodes involved in the blockchain and the connections among them. The network nodes can include creating nodes, maintaining nodes, storage nodes, transmission nodes, etc.

[0047] 4. If the candidate block is verified as valid, it will be accepted as a formal block of the blockchain.

[0048] 5. If the candidate block is accepted, it will be stored in the blockchain and will be used as a previous block on which future formal blocks will be created and accepted.

[0049] In the context of a vehicle network in which nodes run the above five steps of running a blockchain according to their execution, there can be different structures, for example, the following three structures:

[0050] (1) Each node (VUE and infrastructure node) performs the complete operation of the above steps 1 to 5.

[0051] (2) VUE collects data and transmits data to infrastructure nodes. Infrastructure nodes generate candidate blocks, perform PoW computation procedures for candidate blocks, perform verification procedures for candidate blocks, and store candidate blocks if they are accepted.

[0052] (3) VUE collects data into a candidate block, processes PoW computation for the candidate block, and then transmits the candidate block to infrastructure nodes. Infrastructure nodes broadcast the candidate block to other infrastructure nodes or nodes that perform verification procedures for the candidate block.

[0053] The node performing verification can be an infrastructure node, an edge computing node co-located with the infrastructure node, or other VUE connected to the network. If any VUE wants to update the blockchain or ledger, it can request information from the infrastructure node.

[0054] In the above-mentioned structure (3), the VUEs own the computing power to perform the PoW computation; block transmission (rather than transmission of raw data) will significantly reduce the radio resources used between the VUEs and the infrastructure nodes; and the infrastructure nodes can guarantee stable storage of the blockchain or ledger compared to the VUEs that remain mobile in the vehicular network. However, a blockchain fork event can occur in the running blockchain network under structure (3). Therefore, how to solve the problem of the fork event reinforced by the transmission between the VUEs and the infrastructure nodes needs to be solved under structure (3). The details about how to solve this problem have not been defined.

[0055] In particular, in a vehicular network integrated with a blockchain, when any miner VUE completes the PoW computation, the miner VUE will send the message of the block to the infrastructure node, which will broadcast the message within the blockchain network to reach the nodes performing the verification. Any node to perform the verification will verify the first received message. If the block with the shortest PoW delay cannot be the first one to reach the nodes performing the verification, a blockchain fork event occurs. An example of the occurrence of the fork event can be illustrated by Figure 3

[0056] Figure 3 An illustration of the occurrence of a fork event in a blockchain network according to some embodiments of the present application is illustrated.

[0057] Figure 3 The embodiments of FIG. 1 assume that Block#n is the last block in the current unified blockchain (or ledger) in the blockchain network. A candidate block can be denoted as cBlock. Figure 3 The embodiments of FIG. 1 further assume that cBlock#i and cBlock#j are created by different miners of UE1 and UE2, respectively, and these two blocks take Block#n as the previous block during the creation. These two candidate blocks (i.e., cBlock#i and cBlock#j) are created at times Ti and Tj, respectively. Ti and Tj are close to each other, and Ti is earlier than Tj.

[0058] As marked in FIG. 2, each of UE1 and UE2 is a VUE and can have the same function as the VUE as shown and explained in FIG. 1. Figure 3 As marked in FIG. 2, each of UE1 and UE2 is a VUE and can have the same function as the VUE as shown and explained in FIG. 1. Figure 1 As marked in FIG. 2, each of UE1 and UE2 is a VUE and can have the same function as the VUE as shown and explained in FIG. 1. Figure 1 As marked in FIG. 2, each of UE1 and UE2 is a VUE and can have the same function as the VUE as shown and explained in FIG. 1.

[0059] ​Due to different transmission delays, different infrastructure nodes can have different perspectives of the blockchain. For example, N1 receives cBlock#i first, validates the data in cBlock#i for validity, and links cBlock#i to the blockchain; while N2 receives cBlock#j first, validates the data in cBlock#j for validity, and links cBlock#j to the blockchain. Later, when cBlock#i arrives at N2, N2 will have to add cBlock#i to the link. Since both cBlock#i and cBlock#j use Block#n as the previous block and Ti is earlier than Tj, N2 sees two chains after Block#n. Thus, a fork event occurs in this case.

[0060] However, only one blockchain can be maintained as the blockchain. If a fork event occurs, the blockchain system has to recover it by repeating the PoW computation of the forked block and thus introduces more latency and computation and energy consumption. Considering the distinct connectivity and channel quality of the infrastructure nodes of each mining procedure VUE, the chance of the occurrence of a fork event will be significantly increased. Therefore, the present application focuses on solving the problem of the significant increase of fork events.

[0061] Embodiments of the present application aim to accelerate the reporting of the result of PoW computation from the VUE mining procedure to the infrastructure node, and thus reduce the chance of the occurrence of fork events. Some embodiments of the present application provide a blockchain-aware resource request and allocation mechanism, in which an indication of block information is transmitted with a scheduling request of resources from the VUE mining procedure to the infrastructure node. The infrastructure node can determine whether to schedule resources based on the indication and information of other blocks received from the blockchain network.

[0062] Figure 4 An exemplary flowchart illustrating a method of wireless communication according to some embodiments of the present application is described. Figure 4 Embodiments of the present application can be performed by a UE or a VUE (e.g., Figure 1 VUE1, VUE2, VUE3, or VUE4) described and shown in

[0063] In the exemplary method 400 as shown in Figure 4 In the exemplary method 400 as shown in

[0064] The configuration information can include latency bound information. The start time of the latency bound information can be the end time of the PoW computation of the previous block of the blockchain application. The end time of the PoW computation can also be named as the completion time of the PoW computation. Alternatively, the start time of the latency bound information can be the start time of the PoW computation of the candidate block. In an embodiment, the UE reserves resources for transmission of the candidate block and determines whether to use the reserved resources to transmit the candidate block based on the latency bound information included in the configuration information received in operation 401.

[0065] In an example, the UE determines to use the reserved resources to transmit the candidate block only if the following three conditions are met:

[0066] 1) when the completion time of the PoW computation of the candidate block is before the end time of the latency bound information in time domain;

[0067] 2) when the reserved resources are later than the completion time of the PoW computation of the candidate block in time domain; and

[0068] 3) when the reserved resources are not later than the end time of the latency bound information in time domain.

[0069] In another example, the UE determines to use the reserved resources to transmit the candidate block only if the following two conditions are met:

[0070] 1) when the completion time of the PoW computation of the candidate block is not later than the end time of the latency bound information in time domain; and

[0071] 2) when the reserved resources are later than the completion time of the PoW computation of the candidate block in time domain.

[0072] In operation 402, the UE transmits information associated with the candidate block of the blockchain application. The information associated with the candidate block can be transmitted using one of uplink control information (UCI), MAC control element (CE), and physical uplink control channel (PUSCH) transmission.

[0073] In some embodiments of the present application, the information associated with the candidate block includes an indication of the candidate block to indicate the existence of the candidate block. The indication of the candidate block can indicate the time of the completion of the block PoW computation. For example, the indication is a time stamp or a time offset. One example of the indication is a time stamp in the block header of the candidate block. However, a full-size time stamp will greatly increase the overhead. Another example of the indication can be a time offset or time deviation from the time of the PoW completion to the time of the scheduling request (SR) transmission. In this case, the indication can be expressed in symbols, slots, or ms, for example.

[0074] In some other embodiments of the present application, the information associated with the candidate block includes content of the candidate block. The content of the candidate block can also be named as block information of the candidate block or actual content of the candidate block.

[0075] In operation 403, the UE receives a response related to the candidate block, e.g., from the BS or the RSU.

[0076] In some embodiments of the present application, the UE transmits an SR to request resources for transmitting the candidate block. In these embodiments, the response received in operation 403 is a scheduling response, and the scheduling response includes a resource allocation result for the candidate block. For example, if the scheduling response includes resources allocated for the candidate block, the UE can transmit the content of the candidate block using the resources allocated for the candidate block. If the scheduling response does not include resources, the UE can discard the candidate block.

[0077] In some embodiments of the present application, the UE transmits a calibration request for the candidate block, e.g., to an infrastructure node. Then, the UE receives a calibration response for the candidate block, e.g., from the infrastructure node.

[0078] In some embodiments of the present application, the UE transmits an update request for the candidate block, e.g., to an infrastructure node. Then, the UE receives an update response for the candidate block, e.g., from the infrastructure node.

[0079] As Figures 1 to 3 the details described in the embodiments explained and shown in Figure 4 , especially the content related to specific operations of the UE in the blockchain network, are applicable to the embodiments as Figure 4 explained and shown in Figures 1 to 3 . Furthermore, Figure 4 the details described in the embodiments of Figures 1 to 3 are applicable to all embodiments of

[0080] Figure 5 Another flowchart of a method of wireless communication according to some embodiments of the present application is explained. Figure 5 The embodiments of Figure 1 may be performed by an infrastructure node (e.g., a BS, a RSU, or a UE) or a blockchain network node. The blockchain node can be a BS, a RSU, a UE, and a relay UE.

[0081] In the exemplary method 500 as Figure 5 shown in, in operation 501, the infrastructure node receives information associated with a candidate block of a blockchain application from a UE. In some embodiments, the information associated with the candidate block includes an indication to indicate the existence of the candidate block. The indication can be a timestamp or a time offset (e.g., time deviation).

[0082] In some other embodiments, the information associated with the candidate block includes content of the candidate block. The infrastructure node can further determine whether to broadcast the content of the candidate block based on the content of the candidate block and the information associated with one or more additional candidate blocks of the blockchain application. Upon determining to broadcast the content of the candidate block, the infrastructure node can broadcast the content of the candidate block.

[0083] In some embodiments, the UE is a VUE operating in V2X Mode 1 or V2X Mode 2, and the UE performs the PoW computation for the candidate block. In an embodiment, the infrastructure node determines whether the UE is a first equipment to complete the PoW computation for the candidate block generated based on a same block (i.e., a last block in a current unified blockchain (or ledger) in the blockchain network). If the UE is the first equipment to complete the PoW computation for the candidate block, the infrastructure node can determine to broadcast the content of the candidate block.

[0084] In some other embodiments, the UE is a relay UE (e.g., Figure 1 The VUE 4 described and shown above), and the information associated with the candidate block is received by the relay UE from another UE performing the PoW computation for the candidate block. The relay UE can be configured to receive the content of the candidate block from the other UE mentioned above performing the PoW computation for the candidate block. The relay UE can be configured to transmit an indication to the blockchain network to indicate the presence of the candidate block. The relay UE can be configured to perform and transmit another response to the other UE mentioned above in accordance with the response related to the candidate block.

[0085] In operation 502, the infrastructure node transmits a response related to the candidate block. In some embodiments, the infrastructure node receives configuration information of the blockchain application before transmitting the response. In an embodiment, the infrastructure node receives a scheduling request (SR) to request resources for transmitting the candidate block and determines a resource allocation result of the candidate block. For example, the resources can be in PUSCH. The response in operation 502 can be a scheduling response, and the scheduling response can include the resource allocation result of the candidate block.

[0086] For example, the infrastructure node determines the resource allocation result of the candidate block based on the information associated with the candidate block and the information associated with one or more additional candidate blocks of the blockchain application. The information associated with the one or more additional candidate blocks can be received from a blockchain network node.

[0087] In some embodiments, the infrastructure node generates tentative block information associated with the candidate block based on an indication in the information associated with the candidate block, broadcasts the tentative block information, receives the content of the candidate block on the allocated resource, and broadcasts the content of the candidate block. For example, the resource can be in a PUSCH. In some cases, the infrastructure node first determines whether the UE is the first equipment to complete the PoW computation for the candidate block generated based on the same block (i.e., the last block in the current unified blockchain (or ledger) in the blockchain network). If the UE is the first equipment to complete the PoW computation for the candidate block, then the infrastructure node will generate the tentative block associated with the candidate block.

[0088] The content in the tentative block information is defined and indicated by the blockchain application. The tentative block information can include one or more of the following:

[0089] a) the time at which the PoW computation for the candidate block is completed.

[0090] b) a VUE identification (ID), which can be the ID of the VUE in the blockchain application.

[0091] c) an indication of when the indication of the corresponding block information will be received. The indication can be a time offset between the time of the tentative information transmission and the time of the transmission of the block information from the VUE (or the block information is received). The indication can be expressed, for example, in symbols, time slots, or ms.

[0092] d) information of the previous block. The information of the previous block helps to identify on which block the candidate block is generated. For example, the information of the previous block can be the full-size sequence number of the previous block, a portion of the sequence number of the previous block, a hash value of the previous block, a timestamp of the previous number, etc.

[0093] In some embodiments, the infrastructure node receives a request for calibration of the candidate block, e.g., from the VUE, calibrates the consistency of the candidate block, and then transmits a response for calibration of the candidate block, e.g., to the VUE.

[0094] As Figures 1 to 4 the details described in the embodiments illustrated and shown in Figure 5 are applicable to the embodiments illustrated and shown in Figure 5 the details described in the embodiments of Figures 1 to 4 are applicable to all embodiments of Figures 6 to 14 the details described in the embodiments of

[0095] Figure 6 Another exemplary flow diagram illustrating blockchain-aware mobile vehicle communication according to some embodiments of the present application is illustrated.Figure 6 The embodiments demonstrate VUE (e.g., in Figure 1 The description and demonstration in the text illustrate VUE1 and BS (e.g., V2X mode 1) working. Figure 1 The signal flow between BS1 is explained and demonstrated in the text.

[0096] In step 601, when the VUE collects new data required by the blockchain application for candidate blocks, the VUE can perform a PoW computation on this candidate block. Details regarding data requirements, how data is collected, and how the PoW computation is performed on the block are defined and instructed by the blockchain application. The PoW computation will take previous block information as input. If the VUE does not have the most recent previous block information, then the VUE will request information from the BS. Details are in... Figure 13 Described in the text.

[0097] In step 602, when the VUE completes the PoW calculation for the candidate block, the VUE can request resources for uplink data transmission from the candidate block to the BS by sending an SR. For example, the resources can be in the PUSCH. The VUE can also send an indication of the existence of the candidate block along with other information defined in the SR as specified in the 3GPP standard document. The indication can be transmitted using either uplink control information (UCI) or MAC control element (CE).

[0098] In step 603, after receiving the SR and the indication of candidate blocks, the BS immediately determines the resource allocation based on both the indication and information on other candidate blocks received from the blockchain network. Specifically, the following situations may exist:

[0099] - If the BS does not receive any other candidate block information or provisional block information from the blockchain network after accepting the last block in the current unified blockchain (or ledger) of the blockchain network, then the VUE that sent the SR will be considered as the first rig used to complete the PoW computation of candidate blocks generated based on the last block in the current unified blockchain (or ledger) of the blockchain network. The BS will allocate resources for uplink data transmission to the VUE.

[0100] - If the BS receives some other block information or other provisional block information from other candidate blocks in the blockchain network, and the information indicates that the VUE is the first to perform the PoW computation on the candidate block generated from the last block in the current unified blockchain (or ledger) in the blockchain network, then the BS will allocate resources for uplink data transmission to the VUE.

[0101] Otherwise, BS will not allocate resources to VUE.

[0102] If the VUE is considered as the first to complete the PoW computation for the candidate block generated based on the last block in the current consensus blockchain, the BS will generate tentative block information for the VUE and broadcast the tentative block information to the blockchain network. Details are depicted in Figure 11A and 11B .

[0103] In step 604, the BS will send a determined scheduling response indicating the resource allocation result to the VUE. The scheduling response contains the allocated resource for the uplink data transmission of the candidate block. Otherwise, the scheduling response indicates no resource is allocated for the candidate block.

[0104] In step 605, after receiving the scheduling response, the VUE immediately performs according to the information in the scheduling response. For example, if the scheduling response contains the allocated resource, the VUE uses the allocated resource to transmit the content of the candidate block to the BS. Alternatively, if the scheduling response indicates no resource, the VUE will discard the candidate block.

[0105] Figure 7 Another exemplary flow chart of blockchain-aware mobile vehicle communication according to some embodiments of the present application is illustrated. Figure 7 Embodiments of the present application show the signal flow between a VUE (e.g., VUE2 working in V2X mode 2, illustrated and shown in Figure 1 ) and a RSU (e.g., RSU, illustrated and shown in Figure 1 ).

[0106] In step 701, the VUE collects new data required by the candidate lock and performs PoW computation for this candidate block. In addition, the VUE selects and reserves resources for transmitting the candidate block.

[0107] In step 702, the VUE transmits the content of the candidate block to the RSU if certain conditions are met. Details are depicted in Figure 8 and 9 .

[0108] In step 703, after receiving the candidate block from the VUE, the RSU immediately determines whether to broadcast the candidate block based on the content of the candidate block and the information of other candidate blocks received from the blockchain network. Specifically, there can be the following cases:

[0109] - If the RSU does not receive the content of other candidate blocks from the blockchain network and does not receive other tentative block information after accepting the last block in the current consensus blockchain (or ledger) in the blockchain network, the VUE sending the content of the candidate block will be considered as the first to complete the PoW computation for the candidate block generated based on the last block in the current consensus blockchain (or ledger) in the blockchain network.

[0110] - If the RSU receives some content of other candidate blocks or tentative block information of other candidate blocks from the blockchain network, and the information of the candidate block received from the VUE indicates that the VUE is the first one to find the PoW for the candidate block generated based on the last block in the current unified blockchain (or ledger) in the blockchain network, the VUE sending the content of the candidate block will be considered as the first one to complete the PoW computation for the candidate block generated based on the last block.

[0111] If the VUE is considered as the first one to complete the PoW computation for the candidate block generated based on the last block, the RSU will broadcast the content of the candidate block to the blockchain network. Details are depicted in Figure 11A and 11B .

[0112] In step 704, the RSU will send a response back to the VUE to indicate whether the candidate block is broadcasted or discarded according to the determination made in step 703.

[0113] Figure 8 and 9 illustrates a schematic diagram of the latency bound information in time domain according to some embodiments of the present application.

[0114] Figure 8 and 9 Embodiments of demonstrate two possible cases where the condition for the VUE to transmit the content of the candidate block to the RSU is satisfied. In these embodiments, both the end time of the PoW computation (i.e., the completion time of the PoW computation) denoted by T1and the reserved resource time applicable to the block denoted by T2are within the latency bound. The start time of the latency bound is denoted by T LBS . The end time of the latency bound is denoted by T LBE . The latency bound can be defined and indicated by a higher layer of the VUE.

[0115] In one possible case as demonstrated in Figure 8 , the latency bound is defined as the reserved resource time (i.e., T2) for the candidate block should not be later than the end of the latency bound (i.e., T LBE ), i.e., T2<= T LBE . In this case, to guarantee a successful transmission of the candidate block, the end time of the PoW computation should be before the reserved resource time, i.e., T1< T2. Therefore, if the PoW computation can be completed before T LBE , and a suitable resource can be reserved between T1and T LBE , i.e., T1< T2<= T LBE , the content of the candidate block can be transmitted by the VUE. Otherwise, the candidate block should be discarded by the VUE.

[0116] In another possible case as shown in Figure 9 , the latency bound is defined as the end time of the PoW computation should not be later than the end of the latency bound, i.e., T1<=T LBE In this case, in order to guarantee a successful transmission of the candidate block, the VUE can reserve the resource after the PoW computation is completed, i.e., T1

[0117] Since there is no constraint for T2, T2may be in the range of T1 LBE , as shown by Figure 8 , or in the range of T2>T LBE , as shown by Figure 9 . Therefore, if the PoW computation can be completed no later than T LBE and the appropriate resource can be reserved after T1, i.e., T1<=T LBE and T1 , the content of the candidate block can be transmitted. Otherwise, the candidate block should be discarded.

[0118] Figure 10 Another exemplary flowchart of blockchain-aware mobile vehicle communication according to some embodiments of the present application is illustrated. Figure 10 Embodiments of Figure 1 illustrate and show a signal flow between a VUE (e.g., VUE3 operating in V2X Mode 2 as illustrated and shown in Figure 1 illustrate and show a relay VUE (e.g., VUE4 as illustrated and shown in Figure 1 illustrate and show a BS (e.g., BS2 as illustrated and shown in

[0119] In step 1001, VUE1 (e.g., VUE3 as illustrated and shown in Figure 1 collects new data required by a candidate block and performs a PoW computation for this candidate block. In addition, the VUE can select and reserve a resource for transmission of the candidate block. For example, the VUE selects and reserves a resource of a sidelink between the VUE and a relay VUE for transmission of the candidate block. The details of this step are the same as those described for step 701 in embodiments of Figure 7

[0120] In step 1002, the VUE transmits the content of the candidate block to the connected relay VUE if certain conditions are met. The details of this step are the same as those described for step 702 in embodiments of Figure 7

[0121] In step 1003, upon receiving the block, the relay VUE immediately requests a resource for the candidate block to the BS (e.g., BS2) by sending a SR.​The uplink transmission of BS2) is illustrated and demonstrated in the middle. The relay VUE can send the indication indicating the existence of the candidate block together with the SR and other information defined for requesting resources as specified by 3GPP standard documents. The details of this step are the same as described for step 602 in the embodiment of Figure 6 .

[0122] In step 1004, after receiving the SR and the indication of the candidate block, the BS determines the resource allocation based on both the indication and other information of candidate blocks received from the network immediately. For example, the BS will allocate resources for uplink data transmission to the relay VUE for the transmission of the candidate block. The details of this step are the same as described for step 603 in the embodiment of Figure 6 .

[0123] In step 1005, the BS will send a scheduling response to the relay VUE indicating the determination of the resource allocation result. For example, the scheduling response contains the allocated resources or indicates that no resources are allocated for the block transmission. The details of this step are the same as described for step 604 in the embodiment of Figure 6 .

[0124] In step 1006, after receiving the scheduling response, the relay VUE performs according to the information in the scheduling response immediately. If the scheduling response contains the allocated resources, the relay VUE transmits the content of the block to the BS using the allocated resources. If the scheduling response indicates no resources, the relay VUE discards the candidate block. The details of this step are the same as described for step 605 in the embodiment of Figure 6 .

[0125] In step 1007, the relay VUE sends a response to indicate to the VUE whether the candidate block is transmitted to the BS (i.e., to the blockchain network) or discarded.

[0126] Figure 11A An exemplary flowchart for broadcasting blockchain-related information according to some embodiments of the present application is illustrated. Figure 11A The embodiment of the BS (e.g., Figure 1 The embodiment of BS1) is illustrated and demonstrated in the middle. The embodiment of the blockchain network node (e.g., Figure 1 The embodiment of any one of VUE1, VUE2, VUE3, VUE4, RSU, and BS2) is illustrated and demonstrated in the middle.

[0127] At step 1101, if the VUE is considered the first to finish the PoW computation for the candidate block generated based on the last block in the current unified blockchain (or ledger) in the blockchain network, the BS generates tentative block information associated with the candidate block for the VUE. The BS is expected to receive the corresponding block information transmitted on the allocated resource. At step 1103, immediately after generating the tentative block information, the BS broadcasts the tentative block information to the blockchain network nodes. At step 1105, the BS receives the content of the candidate block on the allocated resource. At step 1107, the BS broadcasts the content of the candidate block to the blockchain network.

[0128] Figure 11B Another exemplary flow diagram for broadcasting blockchain-related information according to some embodiments of the present application is illustrated. Figure 11B Embodiments of the present application demonstrate an RSU (e.g., Figure 1 illustrated and demonstrated in FIG. 1 1 1 1, and any one of VUE1, VUE2, VUE3, VUE4, BS1, and BS2 illustrated and demonstrated in FIG. 1 1 1 2) and a blockchain network node (e.g., Figure 1 illustrated and demonstrated in FIG. 1 1 1 1, and any one of VUE1, VUE2, VUE3, VUE4, BS1, and BS2 illustrated and demonstrated in FIG. 1 1 1 2) between them.

[0129] At step 1102, the RSU receives the content of the candidate block from the VUE. Then, the RSU determines whether to broadcast the content of the candidate block according to Figure 7 At step 1104, after determining to broadcast the content of the candidate block, the RSU broadcasts the content of the candidate block to the blockchain network.

[0130] Figure 12 An exemplary flow diagram for performing consistency calibration of a block of a blockchain according to some embodiments of the present application is illustrated. Figure 12 Embodiments of the present application provide a consistency calibration procedure of a candidate block performed between an infrastructure node (e.g., Figure 1 illustrated and demonstrated in FIG. 1 1 1 1, and any one of VUE1, VUE2, VUE3, VUE4, BS1, and BS2 illustrated and demonstrated in FIG. 1 1 1 2) and a VUE (e.g., Figure 1 illustrated and demonstrated in FIG. 1 1 1 1, and any one of VUE1, VUE2, VUE3, VUE4, BS1, and BS2 illustrated and demonstrated in FIG. 1 1 1 2) between them.

[0131] At step 1201, if a VUE needs a calibration procedure for its latest accepted block, the VUE can send a calibration request to its serving infrastructure node. As an example, the VUE can be a VUE that has participated in the generation or verification of the latest accepted block and wants to verify the consistency of the result. The calibration request can contain the block header of the block accepted by the VUE.

[0132] In step 1202, after receiving this calibration request, the infrastructure node immediately performs a consistency calibration procedure. The calibration procedure can be done by comparing the block header of the latest accepted block received from the VUE with the block header of the last block in the infrastructure node's blockchain. There can be the following possible comparison results:

[0133] (1) If the comparison indicates that the block headers of the two blocks are the same, the infrastructure node can set the consistency status to "Yes" in the calibration response.

[0134] (2) If the comparison indicates that the two blocks are different, the infrastructure node can calibrate its blockchain with other infrastructure nodes and send feedback to the VUE.

[0135] - If the block accepted by the infrastructure is correct, the infrastructure node will set the consistency status to "No" in the calibration response and contain the correct block.

[0136] - If the block accepted by the VUE is correct, the infrastructure node will replace the last block in its blockchain with the correct candidate block and set the consistency status to "Yes" in the calibration response.

[0137] In step 1203, the infrastructure node feeds back the calibration response to the VUE. After receiving the calibration response, the following operations are immediately performed:

[0138] - If the consistency status is set to "Yes", the VUE does nothing.

[0139] - If the consistency status is set to "No", the VUE replaces the last block in its blockchain with the correct block contained in the calibration response.

[0140] Figure 13 An exemplary flowchart for updating a blockchain application according to some embodiments of the present application is illustrated. Figure 13 Embodiments of the present application provide an updating procedure of a candidate block or a blockchain performed between an infrastructure node (e.g., BS1, BS2, or RSU) illustrated and shown in FIG. 1 and a VUE (e.g., VUE1, VUE2, or VUE3) illustrated and shown in FIG. 1. Figure 1 Embodiments of the present application provide an updating procedure of a candidate block or a blockchain performed between an infrastructure node (e.g., BS1, BS2, or RSU) illustrated and shown in FIG. 1 and a VUE (e.g., VUE1, VUE2, or VUE3) illustrated and shown in FIG. 1. Figure 1 Embodiments of the present application provide an updating procedure of a candidate block or a blockchain performed between an infrastructure node (e.g., BS1, BS2, or RSU) illustrated and shown in FIG. 1 and a VUE (e.g., VUE1, VUE2, or VUE3) illustrated and shown in FIG. 1.

[0141] In step 1301, if the VUE needs information of a block or a blockchain, the VUE can send an updating request to its serving infrastructure node. As one example, the VUE can be a new comer to the blockchain network or a VUE that resumes connection to the blockchain network. As another example, the VUE can be a VUE that keeps connection to the blockchain network but has not participated in the generation or verification of blocks.

[0142] In step 1302, upon receiving this request, the infrastructure node immediately feeds back a response of the latest accepted block or blockchain according to the request.

[0143] Figure 14 A flowchart of a method for verifying a candidate block of a blockchain application according to some embodiments of the present application is illustrated. Figure 14 Embodiments of the present application provide a verification, acceptance and storage procedure of a candidate block performed by a verification node. The verification node can be any blockchain network node, such as a UE, a BS, a RSU and a relay UE.

[0144] In the exemplary method 1400 shown in FIG. 14A, in operation 1401, the verification node receives configuration information of the blockchain application. Figure 14

[0145] In operation 1402, the verification node receives information associated with a candidate block of the blockchain application from other blockchain network nodes. In operation 1403, the verification node determines whether a verification operation is enabled. In operation 1404, if the verification node determines that the verification operation is enabled, the verification node performs the verification operation.

[0146] In some embodiments, the information associated with the candidate block includes content of the candidate block. The content of the candidate block includes full-size information of the block, including a completion time (i.e., end time) of a PoW computation performed on the candidate block.

[0147] In some embodiments, the information associated with the candidate block includes tentative block information associated with the candidate block. The tentative block information associated with the candidate block (e.g., cBlock#i) includes one or more of the following:

[0148] - a completion time of a PoW computation performed on the candidate block;

[0149] - an ID of a UE, wherein the PoW computation is performed on the candidate block by the UE;

[0150] - a time offset between a time at which the blockchain network node transmits the tentative block information associated with the candidate block and a time at which the blockchain network node receives the content of the candidate block; and

[0151] - information of a previous block of the blockchain application.

[0152] For example, the verification can be performed by the blockchain node (e.g., bNode#m) only if both of the following trigger conditions are satisfied.

[0153] 1. When the blockchain node (e.g., bNode#m) is enabled as a verification node. The verification node can be a BS, a RSU, a UE or a relay UE.​

[0154] 2. When the information associated with a candidate block (e.g., cBlock#i) of the blockchain application is received by a node (e.g., bNode#m).

[0155] - The blockchain node can receive a plurality of candidate blocks generated with the last block (e.g., block#n) in the blockchain as a previous block. The candidate block (e.g., cBlock#i) generated with the last block in the blockchain as a previous block is the first one of the plurality of candidate blocks received by the blockchain node.

[0156] - The information associated with the candidate block can be tentative block information associated with the candidate block or the actual content of the candidate block.

[0157] The specific validation operation performed by the blockchain node (e.g., bNode#m) includes the following steps:

[0158] (1) Step 1: The validation node (e.g., bNode#m) keeps receiving information associated with candidate blocks.

[0159] 1) The validation node sets up a timer (e.g., timer A) to receive information associated with one or more additional candidate blocks (e.g., cBlock#j, #x, #y, etc.) when the validation node determines to perform the validation procedure. The value of the timer is defined and indicated by the specific configuration information of the blockchain application.

[0160] The information associated with the additional candidate blocks can include the content of the additional candidate blocks, which includes the full size information of the blocks, including the completion time of the PoW computation performed on the additional candidate blocks.

[0161] The information associated with the additional candidate blocks can include tentative block information associated with the additional candidate blocks. The items included in the tentative block information associated with the additional candidate blocks (e.g., cBlock#j, #x, #y, etc.) are similar to the items of the tentative block information associated with the candidate block (e.g., cBlock#i).

[0162] 2) The validation node adds both the information associated with the candidate block (e.g., cBlock#i) and the information received during the timer A (e.g., the information associated with cBlock#j, #x, #y, etc.) to a list of one or more information units (e.g., the set of S).

[0163] The list can be initially set to empty. Each information unit in the list can include the block information of a candidate block or the tentative block information associated with a candidate block.

[0164] (2) Step 2: The verifying node determines which candidate block is acceptable according to the received information associated with the candidate blocks when timer A expires.

[0165] 1) Step 2.1 The verifying node keeps in S the information associated with one or more candidate blocks that have the shortest PoW latency and are generated with the last block in the blockchain as the previous block. That is, the verifying node removes other information from S. For example, the verifying node compares the completion time of PoW computation in each information unit in S, keeps one or more information units that have the shortest completion time of PoW computation and are generated with the last block in the blockchain as the previous block in S, and removes other information units from S.

[0166] 2) Step 2.2 The verifying node determines the acceptance of the candidate block according to the following flow:

[0167] • P0. Pre-processing: The verifying node checks the information in S; and if the verifying node finds that both the tentative block information associated with any candidate block and the block information of this candidate block are contained in S, the verifying node removes the tentative block information from S. For example, if two information units in S have the same shortest completion time of PoW computation and are generated with the last block in the blockchain application as the previous block, one information unit contains the content of one candidate block, and another information unit contains the tentative block information associated with one candidate block, the verifying node removes the other information unit mentioned above from S.

[0168] • P1. If S is empty, end the verification.

[0169] • P2. If the verifying node finds that only one information unit (e.g., the block information of one candidate block) is left in S and if the blockchain application requires data validity verification, the verifying node verifies the validity of the data in this candidate block. If the data is valid, the candidate block is accepted as an official block of the blockchain; otherwise, the verifying node discards the candidate block. Then, the verification ends.

[0170] • P3. If multiple information units of the block information of the candidate block are left in S, the verifying node can accept one of them according to the strategy defined and indicated by the blockchain application. For example, the configuration information of the blockchain application includes an acceptance strategy, and the acceptance strategy indicates that if the candidate block related to the information unit contains valid data and maximized data amount, the information unit is accepted. Then, the verification ends.

[0171] • P4. If at least one information unit of tentative block information remains in Sset, the validating node sets another timer (e.g., timer B) according to the time offset contained in the tentative block information and keeps receiving information associated with another (further) candidate block during timer B. In particular, before timer B expires, the validating node receives information associated with one or more further candidate blocks of the blockchain application or tentative block information associated with a further candidate block.

[0172] When timer B expires, the validating node adds the information received during timer B to Sset, deletes all tentative block information from Sset, and deletes the information unit that did not result from the last block in the blockchain as a previous block. Thereafter, the following cases can exist:

[0173] a) If Sset is empty, go to PI, as described above.

[0174] b) If only one information unit of block information of a candidate block remains in Sset, go to P2, as described above.

[0175] c) If multiple information units of block information of a candidate block remain in Sset, go to P3, as described above.

[0176] d) Then, the validation ends.

[0177] Figure 15 A block diagram illustrating an exemplary device according to some embodiments of the present application is described. Referring to Figure 15 , device 1500 includes reception circuitry 1502, transmission circuitry 1504, processor 1506, and non-transitory computer-readable medium 1508. Processor 1506 is coupled to non-transitory computer-readable medium 1508, reception circuitry 1502, and transmission circuitry 1504.

[0178] It is contemplated that, for simplicity, Figure 15 some components are omitted in FIG. 15. In some embodiments, reception circuitry 1502 and transmission circuitry 1504 can be integrated into a single component (e.g., a transceiver).

[0179] In some embodiments, non-transitory computer-readable medium 1508 can have stored thereon computer-executable instructions causing the processor to perform operations with respect to a UE as described above. For example, upon execution of the computer-executable instructions stored in non-transitory computer-readable medium 1508, processor 1506, reception circuitry 1502, and transmission circuitry 1504 immediately perform Figure 4a method of claim 1, the method comprising: receiving, by the receiving circuitry 1502, configuration information for a blockchain application; transmitting, by the transmitting circuitry 1504, information associated with a candidate block for the blockchain application; and receiving, by the receiving circuitry 1502, a response related to the candidate block.

[0180] In some embodiments, the non-transitory computer-readable medium 1508 can store computer-executable instructions to cause a processor to implement operations related to a UE or an infrastructure node (e.g., a BS or RSU) as described above. For example, upon execution of the computer-executable instructions stored in the non-transitory computer-readable medium 1508, the processor 1506, the receiving circuitry 1502, and the transmitting circuitry 1504 immediately perform a method of claim 1. Figure 5 a method of claim 1, the method comprising: receiving, by the receiving circuitry 1502, information associated with a candidate block for a blockchain application; and transmitting, by the transmitting circuitry 1504, a response related to the candidate block.

[0181] In some embodiments, the non-transitory computer-readable medium 1508 can store computer-executable instructions to cause a processor to implement operations related to a UE or an infrastructure node (e.g., a BS or RSU) as described above. For example, upon execution of the computer-executable instructions stored in the non-transitory computer-readable medium 1508, the processor 1506, the receiving circuitry 1502, and the transmitting circuitry 1504 immediately perform a method of claim 1. Figure 14 a method of claim 1, the method comprising: receiving, by the receiving circuitry 1502, configuration information for a blockchain application; receiving, by the receiving circuitry 1502, information associated with a candidate block for the blockchain application; determining, by the processor 1506, whether a verification operation is enabled; and in response to determining that the verification operation is enabled, performing, by the processor 1506, the verification operation.

[0182] The methods of this application can be implemented on a programmed processor. However, the controller, flow charts, and modules can also be implemented on a general-purpose or a special purpose computer, a programmed microprocessor or microcontroller and peripheral integrated circuit elements, an integrated circuit, a hardware electronic or logic circuit such as a discrete element circuit, a programmable logic device, or the like. In general, any device that can function according to the methods of the application is suitable.

[0183] Those of ordinary skill in the art will appreciate that the steps of a method described in connection with the aspects disclosed herein can be embodied directly in hardware, in software modules executed by a processor, or in a combination of the two. A software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. Additionally, in some aspects, the steps of a method can reside as one or any combination or set of codes and / or instructions on a non-transitory computer-readable medium which can be incorporated into a computer program product.

[0184] Although the present disclosure has been described with reference to specific embodiments thereof, it is evident that many alternative, modifications and variations will become apparent to those skilled in the art. For instance, various components of the embodiments can be interchanged, added, or removed in other embodiments. Also, not all of the elements of each figure are necessary for operation of the disclosed embodiments. For example, one of ordinary skill in the art of the disclosed embodiments will be able to construct and use the teachings of the present disclosure by simply adopting the essential claims. Accordingly, the embodiments of the present disclosure set forth herein are intended to be illustrative, not limiting. Various changes can be made without departing from the spirit and scope of the present disclosure.

[0185] In this document, the terms "comprises", "comprising", or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element preceded by "a" or "an" or similar referent is not limited to a single instance of the element but rather can include one or more instances of the element. Furthermore, the term "another" is defined as at least a second or more. The terms "including", "having", and the like, as used herein, are defined as "comprising".

Claims

1. A method performed by a user equipment (UE), the method comprising: receiving configuration information for a blockchain application; performing proof of work (PoW) computation on a candidate block of the blockchain application according to the configuration information; transmitting information associated with the candidate block, wherein the information includes a request for resources for communicating the candidate block based on the configuration information; and receiving a response related to the candidate block, wherein the response includes a resource allocation result for the candidate block based on the request, the configuration information, and information of other candidate blocks of the blockchain application, wherein the information of the other candidate blocks indicates that the UE is a first device performing the PoW computation on the candidate block generated based on a last block in a blockchain of the blockchain application.

2. The method of claim 1, wherein the information associated with the candidate block includes one of a timestamp or a time offset indicating a presence of the candidate block.

3. The method of claim 1, further comprising: transmitting a scheduling request (SR) to request the resources for transmitting the candidate block.

4. The method of claim 1, wherein the response is a scheduling response including the resource allocation result for the candidate block, and the method further comprises at least one of: in response to the scheduling response including the resources allocated for the candidate block, transmitting content of the candidate block using the resources allocated for the candidate block; or in response to the scheduling response not including resources, discarding the candidate block.

5. The method of claim 1, wherein the configuration information includes latency bound information, and the method further comprises: reserving resources for transmitting the information associated with the candidate block; and determining whether to transmit the information associated with the candidate block using the reserved resources based on the latency bound information.

6. A user equipment (UE) for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the UE to: receive configuration information for a blockchain application; perform proof of work (PoW) computation on a candidate block of the blockchain application according to the configuration information; transmit information associated with the candidate block, wherein the information includes a request for resources for communicating the candidate block based on the configuration information; and receive a response related to the candidate block, wherein the response includes a resource allocation result for the candidate block based on the request, the configuration information, and information of other candidate blocks of the blockchain application, wherein the information of the other candidate blocks indicates that the UE is a first device performing the PoW computation on the candidate block generated based on a last block in a blockchain of the blockchain application.

7. The UE of claim 6, wherein the information associated with the candidate block includes one of a timestamp or a time offset indicating a presence of the candidate block.

8. The UE of claim 6, wherein the at least one processor is configured to cause the UE to transmit a scheduling request (SR) to request the resources for transmitting the candidate block.

9. The UE of claim 6, wherein: the response is a scheduling response including the resource allocation result for the candidate block; and the at least one processor is configured to cause the UE to at least one of: in response to the scheduling response including the resources allocated for the candidate block, transmit content of the candidate block using the resources allocated for the candidate block; or in response to the scheduling response not including resources, discard the candidate block.

10. The UE of claim 6, wherein: the configuration information includes latency bound information; and the at least one processor is configured to cause the UE to: reserve resources for transmitting the information associated with the candidate block; and determine whether to transmit the information associated with the candidate block using the reserved resources based on the latency bound information.

11. The UE of claim 6, wherein the at least one processor is configured to cause the UE to: transmit a calibration request for the candidate block; and receive a calibration response for the candidate block.

12. An infrastructure node for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the infrastructure node to: receive, from a user equipment (UE), information associated with a candidate block of a blockchain application, wherein the information includes a request for resources for communicating the candidate block based on configuration information of the blockchain application; and transmit a response related to the candidate block, wherein the response includes a resource allocation result for the candidate block based on the request / the configuration information of the blockchain application and information of other candidate blocks of the blockchain application, wherein the information of the other candidate blocks indicates that the UE is a first device to perform a proof of work (PoW) computation for the candidate block generated based on a last block in a blockchain of the blockchain application.

13. The infrastructure node of claim 12, wherein the at least one processor is configured to cause the infrastructure node to: receive a scheduling request (SR) to request the resources for transmitting the candidate block; and determine the resource allocation result for the candidate block.

14. The infrastructure node of claim 12, wherein: the information associated with the candidate block includes an indication of a presence of the candidate block; and the at least one processor is configured to cause the infrastructure node to: generate tentative block information associated with the candidate block based on the indication; broadcast the tentative block information; receive content of the candidate block on the allocated resources; and broadcasting the content of the candidate block.

15. The infrastructure node of claim 12, wherein: the information associated with the candidate block includes content of the candidate block; and the at least one processor is configured to cause the infrastructure node to: determine to broadcast the content of the candidate block based at least in part on a determination of whether the UE is the first device for completing the PoW computation for the candidate block.

16. The infrastructure node of claim 12, wherein the at least one processor is configured to cause the infrastructure node to receive the configuration information for the blockchain application.

17. The infrastructure node of claim 12, wherein the at least one processor is configured to cause the infrastructure node to: receive a request for attestation of the candidate block; attest to the consistency of the candidate block; and transmit a response to the attestation of the candidate block.

Images