Block chain-based data transmission methods and communication apparatus

Abstract

Provided in the embodiments of the present application are block chain-based data transmission methods and a communication apparatus, which are used for providing an implementation solution for deep fusion of block chain technology and wireless networks. By directly associating and interacting a block chain with data in a protocol stack of a wireless network, the implementation solution can fully utilize the credibility of the block chain to enhance the safety of the data in the protocol stack. A method comprises: sending first indication information and first data, the first indication information being used for indicating that the first data is block chain data to be subjected to consensus confirmation, the first data comprising data of a radio resource control (RRC) layer, and / or a transmission parameter used for transmitting control signaling and / or service data in a data link layer; acquiring a consensus confirmation result of the first data, the consensus confirmation result of the first data being used for indicating that the consensus confirmation of the first data is passed; and updating the first data to a local block chain.

Description

Data transmission method and communication device based on blockchain

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on January 16, 2024, with application number 202410068215.0 and application name “Blockchain-based data transmission method and communication device”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of communications, and in particular to a blockchain-based data transmission method and communication device. Background Art

[0003] Blockchain (BC) is a distributed ledger technology (DLT) that integrates cryptography, peer-to-peer (P2P) networks, distributed databases and other technologies. It has the characteristics of openness, transparency, immutability, full traceability, historical traceability, collective maintenance, and intelligent execution. It is very suitable for establishing multi-party collaborative trust in wireless communication environments where trust is lacking. The integration of blockchain and wireless networks has become an important evolutionary direction for future communication networks (such as the sixth generation (6G) communication network).

[0004] However, the current integration of blockchain and wireless networks remains at the level of a patchwork of mechanisms, making it difficult to fundamentally address the security issues inherent in complex and diverse wireless networks. Therefore, the specifics of how to achieve deep integration between blockchain and wireless networks remain to be explored. Summary of the Invention

[0005] The blockchain-based data transmission method and communication device provided in the embodiments of the present application are used to provide an implementation solution for the deep integration of blockchain technology and wireless networks. By directly associating and interacting the blockchain with the data in the protocol stack of the wireless network, this implementation solution can fully utilize the credibility of the blockchain to enhance the security of the data in the protocol stack.

[0006] To achieve the above objectives, the embodiments of the present application adopt the following technical solutions:

[0007] In a first aspect, a blockchain-based data transmission method is provided. The method can be performed by a first device. The first device can be the terminal device itself, or can refer to a processor, module, chip, or chip system in the terminal device that implements the method; alternatively, the first device can be the access network device itself, or can refer to a processor, module, chip, or chip system in the access network device that implements the method. The following description uses the method performed by the first device as an example. The method includes: sending first indication information and first data, the first indication information being used to indicate that the first data is blockchain data to be consensus-confirmed, the first data including data from the radio resource control (RRC) layer and / or transmission parameters in the data link layer for transmitting control signaling and / or service data; obtaining a consensus confirmation result for the first data, the consensus confirmation result for the first data being used to indicate that consensus confirmation of the first data has been passed; and updating the first data to the local blockchain.

[0008] Because in the embodiment of the present application, the first device can upload data in the protocol stack of the wireless network, such as the RRC layer or the data link layer, to the chain through the first indication information and the first data, thereby achieving direct association and interaction between the blockchain and the data in the protocol stack of the wireless network, thereby fully utilizing the credibility of the blockchain to enhance the security of the data in the protocol stack. Therefore, based on the blockchain-based data transmission method provided in the embodiment of the present application, the deep integration of blockchain technology and the wireless network can be achieved by directly associating and interacting the blockchain with the data in the protocol stack of the wireless network, thereby fully utilizing the credibility of the blockchain to enhance the security of the data in the protocol stack.

[0009] In one possible implementation, the method provided in the first aspect further includes: sending a first request, the first request being used to request access to a wireless network, the first request including second indication information, the second indication information being used to indicate at least one of the following: an identity of a terminal device, a capability of the terminal device, or a protocol layer of the terminal device having blockchain capabilities, the identity of the terminal device being used to determine permission to join a blockchain network, the capability of the terminal device being used to determine whether the terminal device supports joining a blockchain network, and the protocol layer of the terminal device having blockchain capabilities being used to determine the protocol layer corresponding to the first data; and receiving a first response, the first response including third indication information, the third indication information being used to indicate that the access network device has a protocol layer of blockchain capabilities. In other words, the first device is a terminal device, and the first device can exchange blockchain-related information with the access network device through the first request and the first response, thereby facilitating trusted interaction between the blockchain and the protocol stack.

[0010] In a second aspect, a blockchain-based data transmission method is provided. The method can be performed by a second device. The second device can be the terminal device itself, or can refer to a processor, module, chip, or chip system in the terminal device that implements the method; alternatively, the second device can be the access network device itself, or can refer to a processor, module, chip, or chip system in the access network device that implements the method. The following description takes the method performed by the second device as an example. The method includes: receiving first indication information and first data, the first indication information being used to indicate that the first data is blockchain data to be consensus-confirmed, the first data including data from the radio resource control (RRC) layer and / or transmission parameters in the data link layer for transmitting control signaling and / or service data; obtaining a consensus confirmation result for the first data, the consensus confirmation result for the first data being used to indicate that the consensus confirmation of the first data has been passed; and updating the first data to the local blockchain.

[0011] Among them, the technical effects of the second aspect can refer to the technical effects of the first aspect, and will not be repeated here.

[0012] In one possible implementation, the method provided in the second aspect further includes: receiving a first request, the first request being used to request access to a wireless network, the first request including second indication information, the second indication information being used to indicate at least one of the following: an identity of a terminal device, a capability of the terminal device, or a protocol layer of the terminal device that has blockchain capabilities, the identity of the terminal device being used to determine permission to join the blockchain network, the capability of the terminal device being used to determine whether the terminal device supports joining the blockchain network, and the protocol layer of the terminal device that has blockchain capabilities being used to determine the protocol layer corresponding to the first data; and sending a first response, the first response including third indication information, the third indication information being used to indicate that the access network device has a protocol layer of blockchain capabilities. In other words, the second device is an access network device, and the second device can exchange blockchain-related information with the access network device through the first request and the first response, thereby facilitating trusted interaction between the blockchain and the protocol stack.

[0013] In conjunction with the first or second aspect above, in one possible implementation, the transmission parameters include at least one of the following: scheduling parameters of the Media Access Control (MAC) layer, security parameters of the Packet Data Convergence Protocol (PDCP) layer, or Quality of Service (QoS) flow parameters of the Service Data Adaptation Protocol (SDAP) layer. In other words, by reaching consensus on the scheduling parameters of the MAC layer, the security parameters of the PDCP layer, or the QoS flow parameters of the SDAP layer, the transmission parameters of each of the aforementioned protocol layers can be recorded on the chain, thereby ensuring the integrity and security of the transmission parameters of each of the aforementioned protocol layers.

[0014] In conjunction with the first or second aspect above, in one possible implementation, the scheduling parameters include at least one of the following: a channel quality parameter, a modulation parameter, or a retransmission indication parameter. That is, by consensus-confirming the MAC layer scheduling parameters so that the scheduling parameters are recorded on the chain, integrity protection, multi-party trusted evidence, and traceability capabilities can be provided for the MAC layer scheduling parameters.

[0015] In combination with the first or second aspect above, in one possible implementation, the security parameters include a message authentication code for integrity protection of data within the PDCP layer, and / or an identifier of a key for encrypting data and / or the message authentication code within the PDCP layer. That is, by consensus-confirming the security parameters of the PDCP layer so that the security parameters are recorded on-chain, the security parameters of the PDCP layer can be combined with the security mechanisms and algorithms supporting the blockchain. In addition to achieving integrity protection, multi-party trusted evidence storage, and traceability, it is also possible to achieve linkage configuration of the key environment within a certain area, thereby enabling a more sensitive response and adjustment to environmental security.

[0016] In combination with the first or second aspect above, in one possible implementation, the QoS flow parameters include: a QoS flow identifier (QFI) and / or a reflective QoS flow to data radio bearer (DRB) mapping indication (RDI). That is, by consensus-confirming the QoS flow parameters at the SDAP layer so that the QoS flow parameters are recorded on-chain, the blockchain can be used to uniformly and conveniently count and analyze the QoS situation within a certain area, thereby facilitating the implementation of custom regional scopes and jointly recording QoS data from multiple operators. This allows for the detection of hotspots, and the issuance of adjustment instructions via the blockchain to achieve network QoS optimization adjustments within a certain area or even across operators.

[0017] For example, NF network elements within the core network (such as the network data analytics function (NWDAF), or operations, administration and management (OAM), etc.) can adjust the QoS policy in a certain area based on the multi-party QoS flow parameters on the blockchain, and notify the adjusted QoS policy to network elements such as the policy management function network element, access network devices, and user plane function network elements through the session management function network element.

[0018] For another example, the blockchain network where the first device and the second device are located is deployed with a smart contract for realizing QoS optimization and adjustment. After the security parameters in the first data are uploaded to the chain, the QoS optimization and adjustment indication information can be obtained based on the security parameters of multiple blockchain nodes on the blockchain by calling the smart contract, and the NF network element in the core network can be notified through the terminal device or access network device in the blockchain network, thereby realizing QoS optimization and adjustment.

[0019] In combination with the first or second aspect above, in one possible implementation, the data at the RRC layer includes at least one of the following: capability information of the terminal device, a measurement report of the terminal device, or system information. That is, by consensus-confirming the capability information, measurement report, or system information of the terminal device in the RRC layer, the capability information, measurement report, and global system information of the terminal device can be recorded on the chain, facilitating related applications such as wireless network access authentication and authorization, regulatory review, etc. for the terminal device, making distributed identity tracking of mobile users more convenient, and improving the operational stability of the blockchain established in the wireless network.

[0020] In combination with the first or second aspect above, in one possible implementation, the first indication information and the first data are carried by a first protocol layer protocol data unit (PDU), and the first indication information is further used to indicate the protocol layer corresponding to the first data, where the protocol layer corresponding to the first data includes at least one of the following: RRC layer, SDAP layer, PDCP layer, or MAC layer. In other words, the first indication information and the first data can be sent in the form of an encapsulated PDU, and the first indication information indicates the protocol layer corresponding to the first data, so that the blockchain sublayer on the receiving side can determine, through the first indication information, that the first PDU received this time contains blockchain data to be confirmed by consensus.

[0021] In conjunction with the first or second aspect above, in one possible implementation, the first data is determined based on blockchain parameter operation indication information, where the blockchain parameter operation indication information is used to indicate data to be confirmed by consensus at the RRC layer and / or transmission parameters for transmitting control signaling and / or service data to be confirmed by consensus at the data link layer. In other words, the first device can determine which data and / or transmission parameters to be confirmed by consensus based on the blockchain parameter operation indication information, and thereby determine the first data.

[0022] In combination with the first or second aspect above, in one possible implementation, the method provided by the first or second aspect further includes: obtaining adjustment indication information, the adjustment indication information being used to indicate adjustment of data to be agreed upon and confirmed in the RRC layer, and / or transmission parameters to be agreed upon and confirmed in the data link layer for transmitting control signaling and / or service data; and / or data to be adjusted in the RRC layer, and / or transmission parameters to be adjusted in the data link layer for transmitting control signaling and / or service data; and updating blockchain parameter operation indication information based on the adjustment indication information to obtain updated blockchain parameter operation indication information. In other words, the blockchain parameter operation indication information in the blockchain can be updated based on the adjustment indication information, thereby more flexibly adapting to wireless networks with dynamically changing channels.

[0023] In conjunction with the first or second aspect above, in one possible implementation, the adjustment instruction information is adjustment instruction information from a first smart contract (SC) for adjusting blockchain parameter operation instruction information. The method provided in the first or second aspect further includes: sending a first call request, the first call request being used to request the call of the first SC, the first SC being used to adjust the blockchain parameter operation instruction information; and receiving a first consensus message, the first consensus message being used to indicate that consensus confirmation of the first call request has been passed. In other words, a smart contract deployed on a blockchain can aggregate on-chain data from multiple blockchain nodes, allowing analysis and calculation to be performed to adjust the blockchain parameter operation instruction information, thereby affecting the functionality of the protocol stack based on the adjustment of the blockchain parameter instruction information.

[0024] In combination with the first or second aspect above, in one possible implementation, the updated blockchain operation indication information is used to indicate: data to be adjusted in the RRC layer, and / or transmission parameters to be adjusted in the data link layer for transmitting control signaling and / or service data; the method provided in the first or second aspect further includes: obtaining second data, the second data including data to be adjusted in the RRC layer, and / or transmission parameters to be adjusted in the data link layer for transmitting control signaling and / or service data; adjusting the second data according to the updated blockchain operation indication information to obtain third data; and sending the third data. In other words, when the first device and / or device transmits a PDU including parameters corresponding to the updated blockchain parameter operation indication information, it processes the PDU to enable the blockchain to enable the protocol stack functions.

[0025] In a third aspect, a communication device is provided for implementing the various methods described above. The communication device may be the first device in any of the above aspects or any of its implementations, or a device including the first device, or a device included in the first device, such as a chip; or the communication device may be the second device in any of the above aspects or any of its implementations, or a device including the second device, or a device included in the second device, such as a chip. The communication device includes a module, unit, or means corresponding to the implementation of the above method, and the module, unit, or means may be implemented by hardware, software, or by executing the corresponding software implementation by hardware. The hardware or software includes one or more modules or units corresponding to the above functions.

[0026] In some possible designs, the communication device may include a processing module and a transceiver module. The transceiver module, also referred to as a transceiver unit, is configured to implement the transmitting and / or receiving functions described in any of the above aspects and any possible implementations thereof. The transceiver module may be comprised of a transceiver circuit, a transceiver, a transceiver, or a communication interface. The processing module may be configured to implement the processing functions described in any of the above aspects and any possible implementations thereof.

[0027] In some possible designs, the transceiver module includes a sending module and a receiving module, which are respectively used to implement the sending and receiving functions in any of the above aspects and any possible implementation methods.

[0028] In a fourth aspect, a communication device is provided, comprising: at least one processor; the processor is configured to execute a computer program or instruction so that the communication device executes the method described in any one of the above aspects.

[0029] In one possible implementation, the communication device further includes the memory. Optionally, the memory is coupled to the processor, the memory may be integrated with the processor, or the memory may be independent of the processor. Optionally, the processor is configured to execute computer programs or instructions stored in the memory.

[0030] In a possible implementation, the memory is independent of the communication device.

[0031] In one possible implementation, the communication device further includes a communication interface for communicating with a module outside the communication device. The communication device may be the first device in any of the aforementioned aspects or any of its implementations, or a device including the first device, or a device included in the first device, such as a chip.

[0032] In a fifth aspect, a computer-readable storage medium is provided, which stores a computer program or instruction. When the computer-readable storage medium is run on a communication device, the communication device can execute the method described in any of the above aspects or any of its implementation methods.

[0033] In a sixth aspect, a computer program product comprising instructions is provided, which, when executed on a communication device, enables the communication device to execute the method described in any one of the above aspects or any one of its implementations.

[0034] In a seventh aspect, a communication device is provided (for example, the communication device may be a chip or a chip system), which includes a processor for implementing the functions involved in any of the above aspects or any of its implementation methods.

[0035] In some possible designs, the communication device includes a memory for storing necessary program instructions and data.

[0036] In some possible designs, when the device is a chip system, it can be composed of a chip or include a chip and other discrete devices.

[0037] It can be understood that when the communication device provided in any one of the third to seventh aspects is a chip, the above-mentioned sending action / function can be understood as output, and the above-mentioned receiving action / function can be understood as input.

[0038] Among them, the technical effects brought about by any design method in the third to seventh aspects can refer to the technical effects brought about by different design methods in the above-mentioned first or second aspects, and will not be repeated here.

[0039] In an eighth aspect, a communication system is provided, comprising: the first device in the above-mentioned first aspect or any implementation thereof, and the second device in the above-mentioned second aspect or any implementation thereof. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] FIG1 is a schematic diagram of a protocol stack structure provided in an embodiment of the present application;

[0041] FIG2 is a schematic diagram of downlink data processing at a data link layer provided in an embodiment of the present application;

[0042] FIG3 is a flow chart of a method for deploying a blockchain in a communication network provided by an embodiment of the present application;

[0043] FIG4 is a schematic diagram of a system architecture for deploying a blockchain in a communication network according to an embodiment of the present application;

[0044] FIG5 is a second schematic diagram of a system architecture for deploying a blockchain in a communication network provided by an embodiment of the present application;

[0045] FIG6 is a schematic structural diagram of a communication system provided in an embodiment of the present application;

[0046] FIG7 is a flow chart of a data transmission method based on blockchain provided in an embodiment of the present application;

[0047] FIG8 is a schematic diagram of the structure of a blockchain sub-layer PDU provided in an embodiment of the present application;

[0048] FIG9 is a schematic diagram of a protocol stack structure in which a blockchain sublayer is deployed within a MAC layer according to an embodiment of the present application;

[0049] FIG10 is a schematic diagram of a protocol stack structure in which a blockchain sublayer is deployed within a PDCP layer according to an embodiment of the present application;

[0050] FIG11 is a schematic diagram of a protocol stack structure for deploying a blockchain sublayer within an SDAP layer according to an embodiment of the present application;

[0051] FIG12 is a schematic diagram of a protocol stack structure of a blockchain sublayer deployed within an RRC layer according to an embodiment of the present application;

[0052] FIG13 is a structural diagram of a communication device according to an embodiment of the present application;

[0053] FIG14 is a second structural diagram of a communication device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0054] To facilitate understanding of the technical solutions provided by the embodiments of this application, a brief introduction to the relevant technical terms of this application is first given. The brief introduction is as follows:

[0055] First, the protocol stack structure of the wireless network:

[0056] Communication entities in a wireless network may include terminal devices and radio access network (RAN) devices. The 3rd Generation Partnership Project (3GPP) defines the air interface protocol (also known as the air interface, or simply the air interface) between terminal devices and RAN devices. The air interface protocol stack can be divided into three layers and two planes. The three layers include the physical (PHY) layer (also known as layer 1 (L1)), the data link layer (also known as layer 2 (L2)), and the network layer (also known as layer 3 (L3)). The two planes include the control plane for transmitting control signaling and the user plane for transmitting service data.

[0057] Figure 1 is a schematic diagram of a protocol stack structure provided by an embodiment of the present application. As shown in (a) in Figure 1, the protocol stack structure of the control plane logically includes, from top to bottom, a network layer, a data link layer, and a PHY layer. Among them, the network layer may include a radio resource control (RRC) layer, and the RRC layer is responsible for processing the signaling interacting between the terminal device and the RAN device. For example, the functions supported by the RRC layer may include: broadcasting, paging, RRC management, radio bearer control, mobility management, quality of service (QoS) flow management, terminal-side measurement reporting and measurement reporting control, radio link failure detection and recovery, and transmission of non-access stratum (NAS) messages. Among them, NAS messages are generated by the NAS protocol layer, and the NAS protocol layer mainly supports functions such as authentication, mobility management, or security control of terminal devices.

[0058] The data link layer logically consists of the packet data convergence protocol (PDCP), radio link control (RLC), and media access control (MAC) layers, from top to bottom. Within the control plane, the MAC, RLC, and PDCP layers are responsible for the transmission, encryption, and integrity protection of radio bearer signaling. Radio bearers are categorized into two types: user-plane data radio bearers (DRBs) and control-plane signaling radio bearers (SRBs).

[0059] The PHY layer provides the functions required for bitstream transmission over the physical medium. For example, the PHY layer provides data transmission services to the MAC layer and higher layers. The services provided by the PHY layer can be described by transport channels, which describe the characteristics of the data transmitted by the PHY layer to the MAC layer and higher layers. The PHY layer can map transport channels to physical channels.

[0060] As shown in Figure 1(b), the user plane protocol stack logically consists of the data link layer and the physical layer (PHY) layer, from top to bottom. The difference between the data link layer and the control plane is that the user plane data link layer also includes the service data adaptation protocol (SDAP) layer above the PDCP layer. The SDAP layer is responsible for mapping QoS flows to DRBs.

[0061] The MAC, RLC, and PDCP layers of the user plane are similar to those of the control plane. The difference between the two is that in the user plane, the MAC, RLC, and PDCP layers are responsible for the transmission and encryption of service data. Furthermore, the PHY layer between the user and control planes is the same and will not be further described here.

[0062] It should be understood that the protocol stack structure shown in Figure 1 above is only the underlying protocol layer structure. The protocol stack structure can also include high-level protocol layers, such as the application layer. Among them, the application layer can provide user business data transmission services for various types of communication applications (applications, APPs). In addition, different types of applications correspond to different types of business data. For example, game apps correspond to game business data, video playback apps correspond to video business data, social apps correspond to social business data, etc.

[0063] As you can understand, in the protocol stack structure shown in (a) and (b) of Figure 1, the connection point between each protocol layer is called a service access point (SAP). The SDAP layer provides QoS flow-level services to upper layers, the PDCP layer provides radio bearer-level services to the SDAP layer, the MAC layer provides logical channel-level services to the RLC layer, and the PHY layer provides transport channel-level services to the MAC layer.

[0064] The following takes downlink data transmission on the user plane as an example to illustrate the data processing process of each protocol layer in the data link layer.

[0065] Figure 2 is a schematic diagram of downlink data processing at the data link layer according to an embodiment of the present application. As shown in Figure 2, the downlink data processing process is layer-by-layer from the SDAP layer to the MAC layer. The following describes the data processing of each layer from the SDAP layer to the MAC layer.

[0066] SDAP layer:

[0067] The service data submitted to the SDAP layer by the upper layer of the SDAP layer (e.g., the Internet Protocol (IP) layer) can be, for example, IP packets (or packets, or messages). The SDAP layer can complete the mapping of QoS flows in the IP packets to DRBs. For example, the SDAP layer can encapsulate the IP data in the IP packet into a protocol data unit (PDU) of the SDAP layer, i.e., an SDAP PDU. The SDAP PDU corresponds to one DRB. In addition, the IP packet can be encapsulated into multiple SDAP PDUs, and the multiple SDAP PDUs correspond to one DRB.

[0068] It can be understood that the service data transmission of the terminal device is transmitted through the PDU session established between the terminal device, the access network device, and the network function (NF) network element in the core network. Each independent PDU session can be configured with an SDAP entity to realize the mapping of the QoS flow of each PDU session to the DRB.

[0069] In one possible implementation, the SDAP PDU may include a header and an SDAP layer service data unit (SDU), the SDAP SDU may include IP data with QoS flow granularity, and the header of the SDAP PDU may include a QoS flow identifier (QoS flow ID, QFI) of the QoS flow, which is used to indicate which QoS flow the SDAP PDU belongs to.

[0070] In addition, the header of the SDAP PDU may also include a reflective QoS flow to DRB mapping indication (RDI) and / or a reflective QoS flow indication (RQI). Among them, RDI is used to indicate whether the mapping rule of the QoS flow to the DRB needs to be updated, and RQI is used to indicate whether to notify the NAS layer to update the mapping rule of the service data flow (SDF) to the QoS flow. It can be understood that the RAN device schedules services based on the granularity of QoS flow, and the network function (NF) network element in the core network connected to the RAN device processes service data based on the granularity of SDF, or in other words, the service data flow at the NAS layer is based on the granularity of SDF. Then, when the NF network element processes the service data, it can realize the mapping between SDF and QoS flow through RQI, thereby realizing the QoS quality of the service based on the granularity of QoS flow.

[0071] It should be understood that in some cases, the SDAP PDU may not include a header. For example, when the RDI and / or RQI do not need to be updated, the SDAP PDU may not include a header. For another example, when the configuration parameters corresponding to the SDAP layer (such as the parameter sdap-HeaderDL) do not configure an SDAP header, the SDAP PDU may not include a header.

[0072] PDCP layer:

[0073] After the SDAP PDU enters the PDCP layer, it becomes part of the SDU of the PDCP layer. The PDCP layer processes the SDU to generate a PDCP PDU. The PDCP layer's user-plane functions include robust header compression (ROHC), security processing, and service data transmission.

[0074] It should be understood that the security processing of the PDCP layer may include: encryption, decryption, or integrity protection, and the SDU of the PDCP layer may also include security information, which may include, for example, a message authentication code for integrity protection of the data (for example, a message authentication code – integrity (MAC-I)).

[0075] In addition, the PDCP PDU may include a header, which may include a PDCP serial number (SN). The PDCP SN may be used to reorder logical channels to higher layers in confirmation mode, deliver on demand, and detect duplicates of underlying SDU data.

[0076] It can be understood that the PDCP PDU of the control plane is similar to the PDCP PDU of the user plane mentioned above. The SDU in the PDCP PDU of the control plane may include SRB data or security information, etc., and this embodiment of the present application does not specifically limit this.

[0077] RLC layer:

[0078] After the PDCP PDU enters the RLC layer, the RLC layer entity processes it and generates an RLC PDU. The RLC layer supports three transmission modes: transparent mode, unacknowledged mode, and acknowledged mode. Transparent mode is primarily used for the transmission of paging messages, system information broadcasts, and signaling radio bearer (SRB) 0 signaling. Other SRB signaling is transmitted in acknowledged mode. DRBs used to transmit user data can be transmitted in acknowledged or unacknowledged mode depending on the service type.

[0079] The main function of the RLC layer is to reorder, segment, reassemble, and concatenate PDCP PDUs. For example, the RLC layer can execute a feedback-based retransmission mechanism, such as the automatic repeat request (ARQ) mechanism. ARQ is a function in the RLC layer confirmation mode. The ARQ operation of the transmitter includes transmitting and retransmitting PDUs or segments, receiving status reports from the receiver, and receiving HARQ transmission failure indications sent by the next layer (such as the MAC layer). The ARQ operation of the receiver includes detecting whether the RLC layer PDU reception has failed, and regularly feeding back the data reception status to the transmitter through the RLC layer status report. The information contained in the status report includes the RLC SNs that the receiver has received and the SNs that have not been received. When the receiver detects packet loss, it notifies the transmitter through the RLC layer status report that a certain PDU or resegment in the confirmation mode has not been received, and requests the transmitter to retransmit the PDU. The relationship between the HARQ mechanism of the MAC layer and the ARQ mechanism of the RLC layer is that retransmission is performed through ARQ only when the hybrid automatic repeat request (HARQ) retransmission fails after reaching the maximum retransmission times.

[0080] MAC layer:

[0081] After the RLC PDU enters the MAC layer, the MAC layer entity processes the RLC PDU to generate a MAC PDU. The MAC layer processes the RLC PDUs of multiple RBs to generate a MAC PDU. The MAC layer supports mapping logical channels to transport channels, multiplexing and demultiplexing MAC SDUs from multiple logical channels (for example, multiplexing a MAC SDU to multiple terminal devices, such as user equipment (UE) 1 and UE2), and performing error correction, scheduling, or priority processing through HARQ.

[0082] For example, the MAC layer entity can determine the scheduling output information based on the channel state information (CSI), the RLC data buffer status, or the HARQ feedback status. Among them, the channel state information may include a channel quality indication (CQI). The RLC data buffer status can be used to indicate the amount of data (or data size) of the terminal device to be scheduled. The HARQ feedback status may include an acknowledgment, a negative-acknowledgment, or a discontinuous transmission, etc. The HARQ feedback status can be used to determine whether to transmit new data or retransmit data. The scheduling output information may include: the time domain resources, frequency domain resources, and modulation and coding scheme (MCS) allocated by the MAC layer entity to the physical channel (such as the physical downlink shared channel (PDSCH)).

[0083] It is understood that the MAC layer entity can determine the scheduling type based on the RLC data buffer status and / or HARQ feedback status. For example, if there is buffered data in the RLC layer, the MAC layer entity may determine that there is new data to be transmitted and determine this scheduling type as initial transmission scheduling. In addition, after the initial transmission scheduling is completed, if the HARQ feedback status of the downlink transmission data is ACK, it indicates that the initial transmission scheduling was successful. Furthermore, if there is still unscheduled RLC buffered data, the MAC layer entity will continue with the initial transmission scheduling.

[0084] If the HARQ feedback status of the downlink transmission data is NACK or DTX, it means that the initial transmission scheduling has failed and the data needs to be rescheduled, and this type of scheduling is determined as retransmission scheduling.

[0085] It is also understood that the MAC layer entity can determine the MCS based on the CQI. In addition, the MAC layer entity can determine whether the currently selected MCS deviates from the actual channel quality based on the HARQ feedback status, and adjust the MCS if a deviation is determined, so that the adjusted MCS matches the actual channel quality, thereby improving the transmission performance of downlink data.

[0086] It should be understood that for the control plane, the content encapsulated in the RRC PDU is an RRC message. The RRC message may include capability information of the terminal device, measurement configuration information, and master information block (MIB), etc. For details, please refer to the 3GPP technical specifications (TS) 38.331, which will not be repeated here.

[0087] Second, blockchain (BC):

[0088] Blockchain technology generates and stores data in blocks, chronologically organized into a chained data structure. All nodes in the blockchain network jointly participate in the verification, storage, and maintenance of data within the blockchain. For example, newly created blocks must be confirmed by consensus across the network's nodes and broadcast to all nodes for synchronized storage. Afterward, they cannot be altered or deleted. In other words, uploading data to the blockchain requires not only publishing the data but also obtaining consensus confirmation from the nodes within the blockchain and ensuring its storage by all nodes. Consensus confirmation by the nodes within the blockchain ensures that the data is accepted by all nodes, guaranteeing its consistency and accuracy. The fact that consensus-based data is stored by all nodes ensures that it is protected from loss and tampering, and that it is redundantly available.

[0089] In addition, smart contract (SC) technology can leverage the aforementioned characteristics of blockchain to deploy agreed-upon rules or business logic (or functions) as a piece of executable code (such as program code) to an account address on the blockchain. When a call request (or transaction) is initiated to this address, the call request will be verified in the blockchain under the constraints of the consensus mechanism and the code corresponding to the call request will be executed, thereby ensuring the certainty and uniqueness of the execution result.

[0090] It's understandable that blockchain, with its openness, transparency, immutability, full traceability, historical traceability, collective maintenance, and intelligent execution, is ideally suited to establishing multi-party collaborative trust in trustless wireless communication environments. The integration of blockchain and wireless networks is poised to become a key evolutionary direction for future communication networks. For example, blockchain can serve as a distributed trust medium, establishing trusted communication channels between equipment manufacturers, network operators, service providers, and a vast number of terminal devices within wireless networks. This can address numerous issues previously associated with a lack of trust, such as severe wireless network fragmentation, increased wireless communication security risks, and difficulties in network regulation and privacy protection. Furthermore, blockchain can empower various wireless network functions, including wireless resource management, terminal device access, authentication and authorization, as well as multi-dimensional applications in cellular networks, the Internet of Things, and the Internet of Vehicles, thereby enhancing the credibility, efficiency, and security of communication networks.

[0091] The following introduces some related solutions for deploying blockchain in communication networks.

[0092] Third, related solutions for deploying blockchain in communication networks:

[0093] Option 1:

[0094] FIG3 is a flow chart of a method for deploying a blockchain in a communication network provided by an embodiment of the present application. As shown in FIG3 , the method can be applied to a communication network including a first network element and one or more second network elements. The method flow mainly includes:

[0095] S301. A first network element obtains first information, where the first information includes information of a first blockchain. The first blockchain is used to carry data of the first network element and one or more second network elements.

[0096] S302. The first network element sends first information to the one or more second network elements.

[0097] S303. The one or more second network elements update local blockchain information based on the first information.

[0098] That is to say, the method shown in Figure 3 can enable multiple network elements performing the same communication service in the communication network to use blockchain technology by transmitting blockchain information in the communication network, thereby meeting the security requirements of the communication service and improving the security, privacy, and reliability of the communication service.

[0099] Option 2:

[0100] Figure 4 is a schematic diagram of a system architecture for deploying a blockchain in a communication network provided by an embodiment of the present application. As shown in Figure 4, the system is a blockchain system based on the data link layer, and the blockchain system includes: a first blockchain node, a second blockchain node, a first router and a second router. Among them, the first blockchain node may include: a first blockchain program and a first protocol stack, the first protocol stack may adopt a first end system routing protocol (end system routing protocol), and the first blockchain node corresponds to a first network service access point (NSAP) address identifier. The second blockchain node may include: a second blockchain program and a second protocol stack, the second protocol stack may adopt a second end system routing protocol, and the second blockchain node corresponds to a second NSAP address identifier. The first router may adopt a first intermediate system routing protocol (intermediate system routing protocol). The second router may adopt a second intermediate system routing protocol.

[0101] In the blockchain system shown in Figure 4, the first blockchain node can generate third data information through the first blockchain program, and use the first protocol stack to encapsulate the third data information in the first data message format to obtain the first data information.

[0102] In addition, the first blockchain node can determine the first router based on the first end-system routing protocol and the first intermediate system routing protocol, and send the first data information to the first router. After receiving the first data information sent by the first blockchain node, the first router can determine the second router based on the first intermediate system routing protocol and the second intermediate system routing protocol, and send the first data information to the second router. After receiving the first data information forwarded by the first router, the second router can perform routing addressing on the second NSAP address identifier based on the second intermediate system routing protocol and the second end-system routing protocol, determine the second blockchain node, and send the first data information to the second blockchain node. After receiving the first data information forwarded by the second router, the second blockchain node can utilize the second protocol stack and the second data message format to decapsulate the first data information to obtain fourth data information, and then, through the second blockchain program, check the fourth data information to determine the second data information. In this way, the second blockchain node can obtain a relatively complete second data information. In addition, since the first data information is completed in the data link layer during the transmission process, the first data information does not need to rely on protocols in other link layers, which simplifies the process of encapsulating and decapsulating the first data information, thereby reducing the performance loss of the blockchain system.

[0103] Option 3:

[0104] Figure 5 is a second schematic diagram of a system architecture for deploying blockchain in a communication network provided by an embodiment of the present application. As shown in Figure 5, the system architecture uses blockchain to manage business agreements, wireless resources, and network services between mobile network operators (MNOs). Specifically, the system architecture shown in Figure 3 can be divided into two layers, the upper layer being the MNO domain and the lower layer being the network infrastructure domain. The MNO domain can include multiple MNOs, such as MNO#1, MNO#2, and MNO#3 in Figure 5. The network infrastructure domain can include terminals, RANs, software defined networking (SDN) controllers, and blockchain controllers. Terminals can include subscribers of MNO#1, MNO#2, MNO#3, and local consumers of the RAN. The RAN can include multiple RAN devices that provide access services.

[0105] In the system architecture shown in Figure 5, the SDN controller decouples network operations into the control and data planes, simplifying network management and programmability through software. For example, the SDN controller can manage RAN devices and terminals, and the RAN devices can forward packets according to the rules provided by the SDN controller. Furthermore, communication between the SDN controller and forwarding devices can be accomplished through a programmable open flow switch.

[0106] As shown in Figure 5, the blockchain controller sits above the SDN controller in terms of logical design. It verifies transactions and agreements between MNOs. For example, the blockchain controller deploys a smart contract that defines the service agreement between the MNO and the subscriber. This smart contract automatically executes when trigger conditions are met.

[0107] For example, each terminal in Figure 5 can send a service request to the SDN controller through the RAN device to negotiate access to the network. The SDN controller initializes and triggers the service requested by the terminal by initiating a call request (i.e., a transaction) to the account address of the smart contract on the blockchain, and then passes the terminal's service request to the smart contract. Furthermore, if the call request meets the triggering conditions of the smart contract, the smart contract will automatically execute, that is, broadcast the transaction to the blockchain network. The nodes used for consensus verification in the blockchain network will verify the transaction, and after the transaction is confirmed by consensus, the data generated by the transaction will be encapsulated into a block and attached to the blockchain, thereby completing the chain.

[0108] However, the aforementioned solutions for deploying blockchain in communication networks are merely mechanism-splicing designs for the integration of blockchain and wireless networks. They fail to integrate blockchain with the protocol stack in wireless networks, and thus fail to fully utilize the credibility of blockchain to enhance the credibility and security of data or signaling.

[0109] For example, for the above-mentioned solution 1, the deployment of blockchain in the communication network is still limited to data at the application level. L1 to L3 in the air interface protocol stack are only used for forwarding and have no connection with the blockchain. As a result, there are still deficiencies in the trustworthy security protection of the communication network data source.

[0110] For another example, in Solution 2, blockchain technology is deployed at the data link layer of the wired network protocol stack, enabling blockchain data to be encapsulated and unencapsulated at the data link layer. In other words, Solution 2's application of blockchain technology remains solely at the deployment level. Beyond the newly deployed first protocol stack for transmitting blockchain data within the blockchain program, data in other protocol layers has no direct connection to the blockchain, failing to fully leverage blockchain's trusted security capabilities.

[0111] For another example, in the third solution mentioned above, the blockchain system is integrated with the wireless network as a network element, but the integration is not deployed from the perspective of the air interface protocol stack. As a result, the data in the protocol stack cannot be directly associated and interacted with the blockchain, and the blockchain's trustworthy security protection function for data cannot be fully utilized.

[0112] In summary, the embodiments of the present application provide a blockchain-based data transmission method and communication device, which are used to provide an implementation solution for the deep integration of blockchain and wireless networks. This implementation solution can fully utilize the credibility of the blockchain to enhance the credibility and security of the data in the protocol stack by directly associating and interacting the blockchain with the data of the protocol stack in the wireless network.

[0113] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

[0114] In order to facilitate understanding of the embodiments of the present application, the following explanations are made before introducing the embodiments of the present application.

[0115] 1. In the embodiments of the present application, for ease of description, when numbering or indexing is involved, the numbering can be started from 1 or from 0, or from any parameter.

[0116] 2. "Predefined," "predefined," "preconfigured (or pre-configured)," and "protocol agreement" may be used interchangeably, and pre-definition may be achieved by pre-saving corresponding codes, tables, or other methods that can be used to indicate relevant information in a device (e.g., the first device or the second device). The embodiments of this application do not limit the specific implementation methods. "Saved" may mean stored in one or more memories.

[0117] 3. The “protocol” involved in the embodiments of the present application may refer to a standard protocol in the field of communications, such as the long term evolution (LTE) protocol, the new radio (NR) protocol, wireless fidelity (Wi-Fi), and related protocols used in future communication systems (such as the sixth generation (6G) communication system). The embodiments of the present application are not limited to this.

[0118] 4. In the embodiments of the present application, descriptions such as "when...", "in the case of...", "if" and "if" all mean that the device (such as the first device or the second device) will perform corresponding processing under certain objective circumstances. It does not limit the time, nor does it require the device to perform a judgment action when implementing it, nor does it mean that there are other limitations.

[0119] 5. In the embodiments of the present application, “sending information to…(first device)” can be understood as the destination of the information being the first device, and can include directly or indirectly sending information to the first device. “Receiving information from…(second device)” or “receiving information from…(second device)” can be understood as the source of the information being the second device, and can include directly or indirectly receiving information from the second device. The information may be processed as necessary between the source and destination of the information, such as format changes, but the destination can understand the valid information from the source. Similar expressions in this application can be understood similarly and will not be repeated here.

[0120] 6. In the description of the embodiments of the present application, unless otherwise specified, the "and / or" in the embodiments of the present application indicates that there may be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone, wherein A and B can be singular or plural. Moreover, "at least one of the following items" or similar expressions refers to any combination of these items, including any combination of single items or plural items. In addition, in order to facilitate the clear description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, words such as "first" and "second" are used to distinguish between identical or similar items with substantially the same functions and effects. Those skilled in the art will understand that words such as "first" and "second" do not limit the quantity and execution order, and words such as "first" and "second" do not necessarily limit them to be different. At the same time, in the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or descriptions.

[0121] The embodiments of the present application can be applicable to LTE systems or NR systems (also referred to as fifth generation (5G) systems), systems with hybrid LTE and NR networking, vehicle to everything (V2X) systems, device-to-device (D2D) systems, machine to machine (M2M) communication systems, Internet of Things (IoT) systems (such as narrowband Internet of Things (NB-IoT) systems), Wi-Fi systems, non-terrestrial networks (NTN) systems, 6G systems, and other next-generation communication systems. Alternatively, the communication system may also be an open radio access network (O-RAN or ORAN) or a cloud radio access network (CRAN), without limitation.

[0122] It can be understood that the embodiments of the present application can be applicable to a variety of different business scenarios, such as enhanced mobile broadband (eMBB), ultra-high reliability and ultra-low latency communication (URLLC), massive machine type communication (mMTC), immersive communication, massive communication, ubiquitous connections, integrated artificial intelligence and communication, or integrated sensing and communication, etc. In order to meet the further requirements of the above-mentioned different business application scenarios for latency, reliability, and coverage, more flexible resource allocation is required.

[0123] In addition, the communication architecture and business scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Ordinary technicians in this field can know that with the evolution of the communication architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0124] Figure 6 is a structural diagram of a communication system 600 provided in an embodiment of the present application. As shown in Figure 6, the communication system 600 includes at least one access network device (such as 610a or 610b in Figure 6), and at least one terminal device (such as 620a to 620j in Figure 6) connected to the access network device as an example for explanation. It should be understood that the access network device can be connected to the core network (CN) in a wireless or wired manner, and the CN equipment and the access network device in the CN can be different physical devices, or they can be the same physical device that integrates the CN logical function and the wireless access network logical function. It can be understood that the number of access network devices and terminal devices in Figure 6 is only an example, and can be more or less, and the embodiment of the present application does not specifically limit this.

[0125] In one possible implementation, the access network device in the embodiment of the present application may be a device that communicates with a terminal device. The access network device may also be referred to as a RAN device, an access node, a RAN entity, or a RAN node. As shown in FIG6 , multiple access network devices in the communication system 600 may be nodes of the same type or different types. In some scenarios, the roles of the access network device and the terminal device are relative. For example, the network element 620i in FIG6 may be a helicopter or a drone, which may be configured as a mobile base station. For the terminal devices 620j that access the communication system 600 through the network element 620i, the network element 620i may be the base station 610a; but for the base station 610a, the network element 620i is a terminal device. The access network device and the terminal device are sometimes referred to as communication devices. For example, the network elements 610a and 610b in FIG6 may be understood as communication devices with base station functions, and the network elements 620a-620j may be understood as communication devices with terminal functions.

[0126] In one possible scenario, the access network device may be a transmission and reception point (TRP), a base station, a remote radio unit (RRU) or a baseband unit (BBU) (also referred to as a digital unit (DU)) of a split base station, a broadband network gateway (BNG), an aggregation switch, a non-6GPP access device, a relay station or an access point, etc. The access network device may be a macro base station (such as the network element 610a in FIG6 ), a micro base station or an indoor station (such as the network element 610b in FIG6 ), a relay node or a donor node, or a wireless controller in a CRAN scenario. Optionally, the access network device may also be a server, a wearable device, a vehicle or an on-board device, etc. For example, the access network device in the V6X system may be a road side unit (RSU). In addition, the access network device in the embodiment of the present application can be an eNB or eNodeB (evolutional NodeB) in LTE, a wireless controller in a CRAN scenario, a base station in a 5G communication system (such as the next generation Node B (gNodeB, gNB)), or a base station in a future evolution system (such as a 6G communication system), etc., and is not specifically limited here.

[0127] In one possible implementation, in some deployments, a gNB may include a centralized unit (CU), a DU, a CU-control plane (CP), a CU-user plane (UP), or a radio unit (RU). The gNB may also include an active antenna unit (AAU). The CU implements some gNB functions, while the DU implements some gNB functions. For example, the CU is responsible for processing non-real-time protocols and services and implementing the functions of the radio resource control (RRC) and / or packet data convergence protocol (PDCP) layers. The DU is responsible for processing physical (PHY) layer protocols and real-time services and implementing the functions of the radio link control (RLC), media access control (MAC), and PHY layers. The AAU implements some physical layer processing functions, RF processing, and active antenna-related functions. Because RRC layer information ultimately becomes PHY layer information, or is converted from PHY layer information, in this architecture, high-layer signaling, such as RRC layer signaling, can also be considered to be sent by the DU, or by the DU+AAU. It is understood that the access network device can be a device including one or more of a CU node, a DU node, and an AAU node. Furthermore, the CU can be classified as an access network device in the RAN or as an access network device in the CN, and this is not limited in the embodiments of the present application.

[0128] In different systems, CU (or CU-CP and CU-UP), DU or RU may also have different names, but those skilled in the art can understand their meanings. For example, in the ORAN system, CU may also be called O-CU (Open CU), DU may also be called O-DU, CU-CP may also be called O-CU-CP, CU-UP may also be called O-CU-UP, and RU may also be called O-RU. For the convenience of description, the embodiments of the present application are described by taking CU, CU-CP, CU-UP, DU and RU as examples. Any unit of CU (or CU-CP, CU-UP), DU and RU in the embodiments of the present application can be implemented by a software module, a hardware module, or a combination of a software module and a hardware module.

[0129] In one possible implementation, the terminal device in the embodiment of the present application may be a device for implementing wireless communication functions, such as a terminal or a chip that can be used in a terminal. The terminal may be a user equipment (UE), an access terminal, a terminal unit, a terminal station, a mobile station, a mobile station, a remote station, a remote terminal, a mobile device, or a terminal agent in a 5G network or a future evolved public land mobile network (PLMN). The access terminal may be a cellular phone, a cordless phone, a Session Initiation Protocol (SIP) phone, a wireless local loop (WLL) station, a personal digital assistant (PDA), a handheld device with wireless communication capabilities, a computing device or other processing device connected to a wireless modem, an in-vehicle device, a wearable device, a VR terminal device, an AR terminal device, a wireless terminal in industrial control, a wireless terminal in self-driving, a wireless terminal in remote medical care, a wireless terminal in a smart grid, a wireless terminal in transportation safety, a wireless terminal in a smart city, a wireless terminal in a smart home, etc. In one possible implementation, the terminal device may be mobile or fixed, without limitation.

[0130] It can be understood that the above-mentioned communication system 600 can support a variety of different business application scenarios, such as enhanced mobile broadband (eMBB), ultra-high reliability and ultra-low latency communication (URLLC), massive machine type communication (mMTC), immersive communication, massive communication, ubiquitous connections, integrated artificial intelligence and communication, or integrated sensing and communication, etc., and the embodiments of the present application do not specifically limit this.

[0131] It should be understood that in a sidelink (SL) scenario, signaling and / or data can also be transmitted and received between multiple terminal devices in Figure 6 via the air interface PC5. For example, terminal device 620a and terminal device 620e can transmit and receive signaling and / or data via the PC5 interface. Furthermore, in the SL scenario, the protocol stack structure corresponding to PC5 is similar to that in Figure 1. For details, please refer to Figure 1 and its corresponding description, and will not be repeated here.

[0132] In addition, the access network device in Figure 6 (for example, 610a or 610b in Figure 6) and at least one terminal device connected to the access network device (for example, 620a~620j in Figure 6) belong to blockchain nodes within the same blockchain network.

[0133] The embodiment of the present application provides a blockchain-based data transmission method, the execution subject of which may be a first device. The first device may be the terminal device in FIG6 , or a module or unit of the terminal device (such as a chip, chip system, chip circuit, or circuit of the terminal device), or an access network device, or a module or unit of the access network device (such as a chip, chip system, chip circuit, or circuit of the access network device).

[0134] In one possible implementation, a first device sends a first indication message and first data, the first indication message being used to indicate that the first data is blockchain data to be consensus-confirmed, the first data including data at the RRC layer and / or transmission parameters in the data link layer for transmitting control signaling and / or service data; the first device obtains a consensus confirmation result for the first data, the consensus confirmation result for the first data being used to indicate that the consensus confirmation of the first data has been passed; and the first device updates the first data to a local blockchain. In this way, the first device can, through the first indication message and the first data, upload data in the protocol stack of a wireless network, such as the RRC layer and / or the data link layer, to the blockchain, thereby enabling direct association and interaction between the blockchain and the data in the protocol stack of the wireless network, thereby fully leveraging the credibility of the blockchain to enhance the security of the data in the protocol stack. Therefore, based on the blockchain-based data transmission method provided in the embodiment of the present application, the deep integration of blockchain technology and the wireless network can be achieved by directly associating and interacting the blockchain with the data in the protocol stack of the wireless network, thereby fully leveraging the credibility of the blockchain to enhance the security of the data in the protocol stack.

[0135] The above method provided in the embodiment of the present application will be described in detail below with reference to FIG7 .

[0136] It should be understood that the signals between the various devices or apparatuses, the names of the parameters in the signals, or the names of the information carried by the signals in the following embodiments of the present application are merely examples, and other names may also be used in specific implementations. The embodiments of the present application do not impose specific limitations on this.

[0137] It can be understood that the method provided in the embodiment of the present application can be applicable to the first device and the second device for execution.

[0138] In one possible implementation, the first device may be the terminal device in FIG. 6 , or a module or unit of the terminal device (such as a chip, a chip system, a chip circuit, or a circuit of the terminal device), and the second device may be the access network device in FIG. 6 , or a module or unit of the access network device (such as a chip, a chip system, a chip circuit, or a circuit of the access network device).

[0139] It can be understood that the first device can also be the access network device in Figure 6, and the second device can be the terminal device in Figure 6. The embodiment of the present application does not make specific limitations on this.

[0140] In another possible implementation, in the SL scenario, the first device and the second device may be different terminal devices, or modules or units of different terminal devices, wherein the air interface between the first device and the second device may be PC5.

[0141] It is understood that the first device can operate in a high-frequency band, such as a millimeter wave band or a terahertz band, or in a low-frequency band, such as a 700 MHz, 900 MHz, 2.1 GHz, 2.6 GHz, or 3.5 GHz band. It is understood that the first device can also operate in other frequency bands supported by the 6G system, and this embodiment of the application does not specifically limit this.

[0142] In addition, in the embodiment of the present application, the first device and the second device are blockchain nodes in the same blockchain network. The first device or the second device can serve as a maintenance node (or verification node, consensus node, etc.) in the blockchain network, and is used to verify and maintain blockchain data to be confirmed by consensus (or to be uploaded to the chain), or call requests (or transaction requests, business requests, etc.). It is understood that the first device or the second device can also serve as a broadcast node in the blockchain network, and is used to broadcast blockchain data or call requests to be confirmed by consensus in the blockchain; or, the first device or the second device can also serve as a storage node (or simple node, or ordinary node) in the blockchain network, and is used to synchronize blockchain data.

[0143] For ease of understanding, the following describes in detail the method flow shown in FIG7 by taking the interaction between the first device and the second device as an example.

[0144] FIG7 is a flow chart of a blockchain-based data transmission method provided in an embodiment of the present application. As shown in FIG7 , the method includes the following steps:

[0145] S701: A first device sends first indication information and first data to a second device. Correspondingly, the second device receives the first indication information and first data from the first device. The first indication information indicates that the first data is blockchain data to be confirmed by consensus, and the first data includes RRC layer data and / or data link layer transmission parameters for transmitting control signaling and / or service data.

[0146] S702: The first device obtains a consensus confirmation result of the first data.

[0147] S703. The first device updates the first data to the local blockchain.

[0148] S704: The second device obtains a consensus confirmation result of the first data.

[0149] S705. The second device updates the first data to the local blockchain.

[0150] The above steps S701 to S705 are described in detail below.

[0151] For step S701:

[0152] It is understood that by sending the first indication information and the first data, the first device can enable the second device to determine that the first data is blockchain data to be confirmed by consensus. In this way, the second device can initiate a consensus confirmation process for the first data in the blockchain based on the participating role in the blockchain network (such as a maintenance node, a broadcast node, or a storage node), or broadcast the first data to other blockchain nodes in the blockchain network. The other blockchain nodes can, for example, be terminal devices or access network devices other than the first and second devices in the blockchain network. In addition, when the second device acts as a storage node, the second device can cache the first data and update the local blockchain based on the consensus confirmation result of the first data.

[0153] It should be understood that "pending consensus confirmation" can be replaced by "pending consensus" or "pending on-chain", and blockchain data can be replaced by "blocks", which is not specifically limited in the embodiments of the present application.

[0154] It can be understood that in the embodiment of the present application, the data in the RRC layer may be an RRC PDU, and the RRC PDU may carry an RRC message. For example, the RRC message may include a downlink RRC message and an uplink RRC message. Among them, the downlink RRC message may include, for example, a downlink common RRC message, a downlink dedicated RRC message of the terminal device, a system RRC message, or a paging RRC message. The downlink common RRC message may include, for example, an RRC reconfiguration message, an RRC recovery message, a security mode signaling, or a UE capability reporting indication. The dedicated RRC message of the terminal device may include an RRC establishment message, or an RRC rejection message. The system RRC message may include a system information block (system information block) X (for example, SIB1 to SIB19), or an MIB, etc.

[0155] In addition, the uplink RRC message may include, for example, an uplink common RRC message and an uplink dedicated RRC message of the terminal device. The uplink common RRC message may include, for example, capability information of the terminal device, a measurement report of the terminal device, or an RRC reconfiguration complete message, etc., which is not specifically limited in the embodiments of the present application.

[0156] In one possible implementation, the RRC layer data includes at least one of the following: terminal device capability information, terminal device measurement reports, or system information. That is, by reaching consensus on the terminal device capability information, terminal device measurement reports, or system information in the RRC layer, the terminal device capability information, measurement reports, and global system information can be recorded on the blockchain, facilitating applications such as wireless network access authentication and authorization for terminal devices, regulatory review, and other related applications. This can make distributed identity tracking of mobile users more convenient and improve the operational stability of blockchains established in wireless networks.

[0157] It should be understood that the system information may include SIBX and / or MIB. Table 1 shows the capability information of the terminal device, the measurement report of the terminal device, and related descriptions of the system information.

[0158] Table 1

[0159] Furthermore, uploading terminal device capability information to the blockchain facilitates applications such as wireless access authentication and authorization, regulatory review, and more. Uploading terminal device measurement reports to the blockchain facilitates distributed identity tracking for mobile users. Uploading system information to the blockchain enables global system record management, thereby improving the operational stability of blockchains built on wireless networks.

[0160] It can be understood that Table 1 is only an example, and the data of the RRC layer can also be an RRC message, which is not specifically limited in the embodiments of the present application.

[0161] The following introduces the transmission parameters used for transmitting control signaling and / or service data in the data link layer.

[0162] It should be understood that the control signaling may be, for example, control plane signaling, such as the control signaling or data carried by the above-mentioned RRC message. The service data may be, for example, service data of the user plane (or data plane).

[0163] In one possible implementation, the transmission parameters include at least one of the following: MAC layer scheduling parameters, PDCP layer security parameters, or SDAP layer QoS flow parameters. In other words, by reaching consensus on the MAC layer scheduling parameters, PDCP layer security parameters, or SDAP layer QoS flow parameters, the transmission parameters of each of the above protocol layers can be recorded on the chain, thereby ensuring the integrity and security of the transmission parameters of each of the above protocol layers.

[0164] In one possible implementation, the scheduling parameters include at least one of the following: a channel quality parameter, a modulation parameter, or a retransmission indication parameter. In other words, by consensus-based confirmation of the MAC layer scheduling parameters and enabling them to be recorded on the chain, integrity protection, multi-party trusted evidence, and traceability capabilities can be provided for the MAC layer scheduling parameters.

[0165] It is understood that the channel quality parameter can be used to indicate the channel status, and may include, for example, the CQI of the MAC layer in Figure 2, or the signal-to-noise ratio. Modulation parameters may include the modulation order, modulation mode, or target code rate, and may include, for example, the MCS of the MAC layer in Figure 2. The retransmission indication parameter is used to indicate HARQ information, such as whether the MAC layer enables HARQ and the maximum number of HARQ retransmissions.

[0166] For example, Table 2 shows the specific contents and related descriptions of the scheduling parameters.

[0167] Table 2

[0168] It can be understood that Table 2 is only an example, and the scheduling parameters of the MAC layer may also include RLC data buffer status, HARQ feedback status, precoding matrix indication, or rank indication, etc., which is not specifically limited in the embodiments of the present application.

[0169] In one possible implementation, the security parameters include a message authentication code (MAC) used to protect the integrity of data within the PDCP layer, and / or an identifier for a key used to encrypt data and / or the MAC within the PDCP layer. In other words, by consensus-based confirmation of the PDCP layer's security parameters, which are then recorded on-chain, the PDCP layer's security parameters can be combined with the blockchain's supporting security mechanisms and algorithms. This allows for the coordinated configuration of key environments within a specific area, while also enabling a more responsive response and adjustment to environmental security.

[0170] For example, the message authentication code may be the MAC-I in the PDCP layer in FIG2 . For another example, the key used to encrypt the data and / or message authentication code in the PDCP layer may be the key K used for encrypting the unicast communication session in the PC5 interface. NRP-sess .

[0171] For example, Table 3 shows the specific contents and related descriptions of the security parameters.

[0172] Table 3

[0173] It can be understood that the PDCP layer is used for K in the SL scenario. NRP-sess The ID can be recorded on the chain, thereby achieving integrity protection, multi-party trusted evidence, and tracking and tracing. It is not limited to a pair of terminal devices and access network devices. Data transmitted between different terminal devices can also achieve integrity protection, multi-party trusted evidence, and tracking and tracing.

[0174] In addition, Table 3 is only an example. The security parameters of the PDCP layer may also include NRP-sess The identifier of other encryption keys other than , is not specifically limited in this embodiment of the present application.

[0175] In one possible implementation, QoS flow parameters include: a QoS flow identifier (QFI) and / or a reflective QoS flow to data radio bearer (DRB) mapping indication (RDI). In other words, by achieving consensus on the QoS flow parameters at the SDAP layer and recording them on the blockchain, blockchain can be used to conveniently and uniformly count and analyze QoS conditions within a specific area, facilitating the implementation of custom regional scopes and jointly recording QoS data from multiple operators. This allows for the detection of hotspots, issuing adjustment instructions via the blockchain, and achieving network QoS optimization and adjustment within a specific area or even across operators.

[0176] For example, NF network elements within the core network (such as the network data analytics function (NWDAF), or operations, administration and management (OAM), etc.) can adjust the QoS policy in a certain area based on the multi-party QoS flow parameters on the blockchain, and notify the adjusted QoS policy to network elements such as the policy management function network element, access network devices, and user plane function network elements through the session management function network element.

[0177] For another example, the blockchain network where the first device and the second device are located is deployed with a smart contract for realizing QoS optimization and adjustment. After the security parameters in the first data are uploaded to the chain, the QoS optimization and adjustment indication information can be obtained based on the security parameters of multiple blockchain nodes on the blockchain by calling the smart contract, and the NF network element in the core network can be notified through the terminal device or access network device in the blockchain network, thereby realizing QoS optimization and adjustment.

[0178] Table 4

[0179] It can be understood that Table 4 is only an example, and the QoS flow parameters of the SDAP layer may also include related parameters of other QoS flows, such as the RQI of the SDAP layer in Figure 2. This embodiment of the present application does not specifically limit this.

[0180] It can also be understood that the transmission parameters in the embodiment of the present application may also include parameters carried by the RLC PDU of the RLC layer, such as the segmentation parameters of the RLC layer, or the serial number of the SDAP SDU, etc., and the embodiment of the present application does not specifically limit this.

[0181] In addition, the data to be confirmed by consensus included in the first data may also include data or parameters that are not transmitted in the PDU of the protocol stack, such as information that can be scheduled by the protocol stack, such as a scheduling request, cache status report, or power margin that can be obtained by the MAC layer; for example, a QoS configuration (QoS profile) or QoS rule (QoS rule) that can be scheduled by the SDAP layer, etc. The embodiments of the present application do not specifically limit this.

[0182] It should be understood that the transmission parameters of the data link layer included in the above-mentioned first data may be predefined by the protocol, or negotiated in advance between the first device and the second device, or indicated by the network, and the embodiments of the present application do not specifically limit this.

[0183] In one possible implementation, the first data is determined based on blockchain parameter operation indication information, where the blockchain parameter operation indication information refers to data to be confirmed by consensus at the RRC layer and / or transmission parameters for transmitting control signaling and / or service data to be confirmed by consensus at the data link layer. In other words, the first device can determine which data and / or transmission parameters to be confirmed by consensus based on the blockchain parameter operation indication information, and thereby determine the first data.

[0184] For example, the first device may determine the first data based on the blockchain parameter operation indication information. The blockchain parameter operation indication information may indicate the first operation and the parameter corresponding to the first operation. The first operation may include consensus confirmation (or on-chain), retrieval, copying, or adjustment of parameter values. Retrieval may, for example, mean deleting the parameter from the PDU in which it is located, or retrieving the header of the PDU (for example, reserved bits in the header may be used to carry the retrieved parameter), etc., which is not specifically limited in the embodiments of the present application.

[0185] For example, the blockchain parameter operation instruction information can be stored in the form of a table. As shown in Table 5, the blockchain parameter operation instruction information indicates the operation of MAC-I and K NRP-sess The first device can then determine the first data including MAC-I and K according to the blockchain operation instruction information. NRP-sess ID.

[0186] Table 5

[0187] It can be understood that the blockchain parameter operation indication information can be pre-configured, or negotiated between the first device and the second device, or indicated by the network, and the embodiments of the present application do not specifically limit this.

[0188] For example, the second device may also obtain blockchain parameter operation instruction information in advance, and then the second device may also determine the first data in the received data based on the blockchain operation instruction information.

[0189] In one possible implementation, the protocol stack of the first device includes a blockchain sublayer. The protocol stack of the first device includes a control plane protocol stack and / or a user plane protocol stack. In other words, by deploying the blockchain sublayer within the control plane protocol stack and / or the user plane protocol stack, the deep integration of wireless networks and blockchain can be effectively promoted at the protocol layer level.

[0190] In one possible implementation, a blockchain sublayer is deployed in the RRC layer and / or data link layer of the first device. The data link layer includes the SDAP layer, PDCP layer, RLC layer, and MAC layer. The blockchain sublayer is deployed in one or more of the SDAP, PDCP, RLC, and MAC layers. In other words, deploying the blockchain sublayer at the source of signaling and / or transmission parameters, thereby protecting them with the blockchain's security mechanisms, can fundamentally improve the credibility and security of the signaling and / or transmission parameters.

[0191] It should be understood that the blockchain sublayer in the embodiments of the present application may support some of the blockchain's functions, such as supporting the block structure. Furthermore, the blockchain sublayer may also support at least one of the following: transaction structure, consensus algorithm, or smart contracts. In other words, the blockchain sublayer in the embodiments of the present application may not support all blockchain functions, thereby reducing the deployment complexity of the blockchain sublayer at the RRC layer and / or data link layer.

[0192] It is understood that the blockchain sublayer can configure blockchain parameter operation indication information. For example, the blockchain parameter operation information can be used as a variable of the blockchain sublayer, and then the blockchain sublayer entity can transparently transmit or open the PDU submitted by the upper and lower layers based on the blockchain parameter operation information.

[0193] For example, if the blockchain sub-layer entity determines, based on the blockchain parameter operation information, that the header of the PDU submitted by the upper layer contains parameters that require consensus confirmation, the blockchain sub-layer entity may extract the header of the PDU and encapsulate it into a block. It is understood that if the blockchain sub-layer entity determines, based on the blockchain parameter operation information, that the header of the PDU submitted by the upper layer does not contain parameters that require consensus confirmation, the blockchain sub-layer entity may transparently transmit the PDU.

[0194] For another example, the blockchain sublayer entity may also interact with the RRC layer and / or the data link layer to obtain parameters that should be subject to consensus confirmation.

[0195] It can be understood that the first device can obtain the parameters that should be consensus-confirmed based on the packet header of the PDU submitted by the upper layer and / or other protocol layer interactions, and the embodiments of the present application do not specifically limit this.

[0196] In one possible implementation, the first indication information and the first data are carried by a first PDU. The first indication information is further used to indicate the protocol layer corresponding to the first data, where the protocol layer corresponding to the first data includes at least one of the following: RRC layer, SDAP layer, PDCP layer, or MAC layer. In other words, the first indication information and the first data can be sent by encapsulating them into a PDU, and the first indication information indicates the protocol layer corresponding to the first data, so that the blockchain sublayer on the receiving side can determine, through the first indication information, that the first PDU received this time contains blockchain data to be confirmed by consensus.

[0197] For example, the first device sends the first indication information and the first data (ie, step S701), including: the first device encapsulates the first indication information and the first data to obtain a first PDU, and sends the first PDU.

[0198] It can be understood that the header of the first PDU can be used to carry the first indication information, and the SDU in the first PDU can be used to carry the first data.

[0199] In a possible implementation, the first PDU includes a first field, and the first field is used to carry first indication information.

[0200] Optionally, the first PDU also includes a second field and / or a third field, where the second field is used to indicate the serial number (SN) corresponding to the first PDU, which is the hash value in the blockchain message, and the third field is used to indicate the size of the data area in the first PDU used to carry the block or consensus message. It can be understood that the serial number indicated by the second field can be used to perform blockchain verification on the first data. The third field can be used to indicate where the data area where the first data is located ends, so that the first data can be better received.

[0201] In addition, the above-mentioned second field and / or third field are only optional. The serial number indicated by the second field can be maintained by the first device and the second device respectively, for example, by maintaining the order of the blockchain message to determine the hash value. For example, the same random seed can be pre-configured between the first device and the second device, and then the first device and the second device can determine the same random number and determine the hash value in the blockchain message based on the random number. The embodiments of the present application do not specifically limit this.

[0202] In addition, the size of the data area used to carry blocks or consensus messages in the first PDU is fixed, and the size of the data area is pre-configured by the protocol, so there is no need to indicate the size of the data area through the third field.

[0203] For example, the PDU structure of the blockchain sublayer is described by taking the first PDU including the first field to the third field as an example.

[0204] Figure 8 is a schematic diagram of the structure of a blockchain sublayer PDU provided in an embodiment of the present application. As shown in Figure 8 (a), the header of the blockchain sublayer PDU includes three fields, namely the first field to the third field. The blockchain sublayer SDU may include the first data. It is understood that the first device may embed the blockchain sublayer PDU into the PDU of the upper protocol layer of the blockchain sublayer to obtain the first PDU.

[0205] For example, as shown in (b) of Figure 8, the SDU of the blockchain sublayer also includes the header information of the PDU of the upper protocol layer of the blockchain sublayer. In this way, the PDU of the blockchain sublayer can be used as the PDU header of the upper protocol layer of the blockchain sublayer to obtain the first PDU, and then the first PDU is delivered to the lower protocol layer of the blockchain sublayer, thereby sending the first PDU. In other words, for the second device to receive the first data, the logical position of the blockchain sublayer of the second device should be the same as that of the blockchain sublayer of the first device. After parsing the first PDU, the blockchain sublayer entity can obtain the PDU of the upper protocol layer of the blockchain sublayer and deliver the PDU to the upper protocol layer of the blockchain sublayer.

[0206] For another example, as shown in (c) in FIG8 , the PDU of the blockchain sublayer shown in (a) in FIG8 can be used as the header of the PDU of the upper protocol layer of the blockchain sublayer.

[0207] It can be understood that the PDU of the blockchain sublayer shown in (a) in Figure 8 can also be spliced ​​with the PDU of the upper protocol layer of the blockchain sublayer, and this embodiment of the present application does not specifically limit this.

[0208] In one possible implementation, the first PDU is determined based on the second PDU, the RRC layer data and / or data link layer transmission parameters included in the first data belong to the second PDU, and the first PDU also includes data carried by the second PDU. In other words, the first data to be confirmed by consensus is obtained from the second PDU and sent along with the second PDU.

[0209] In another possible implementation, the first PDU is determined based on the second PDU. The RRC layer data and / or data link layer transmission parameters carried by the first data belong to the second PDU. The first PDU does not include any other data carried by the second PDU other than the RRC layer data and / or data link layer transmission parameters included in the first data. In other words, the first PDU is not sent along with the second PDU. For example, the first PDU can be sent after the second PDU, thereby reducing service latency.

[0210] It can be understood that the second device can also upload the data of the RRC layer and / or the transmission parameters in the data link layer for transmitting control signaling and / or business data, and then the second device can also use the above-mentioned first PDU sending method to send uplink data.

[0211] The following are several examples to illustrate how the blockchain sublayer processes PDUs submitted by the upper and / or lower layers.

[0212] Example A: The blockchain sublayer is deployed within the MAC layer.

[0213] Figure 9 is a schematic diagram of a protocol stack structure for deploying a blockchain sublayer within a MAC layer, as provided by an embodiment of the present application. As shown in Figure 9, the blockchain sublayer can logically be deployed at the bottom of the MAC layer. In this way, the blockchain sublayer can obtain MAC PDUs and, based on the packet header in the MAC PDUs, obtain scheduling parameters or other MAC layer information.

[0214] As shown in Figure 9, assuming that the first device sends service data, the IP data packet corresponding to the service data is processed in sequence by the SDAP layer, PDCP layer, RLC layer, and MAC layer to obtain MAC PDU#1. After receiving MAC PDU#1, the blockchain sublayer entity determines that the parameters that should be consensus-confirmed are HARQ_I and MCS based on the blockchain parameter indication information. The blockchain sublayer entity determines that the header of MAC PDU#1 includes HARQ_I and MCS. The blockchain sublayer entity will extract the parameters HARQ_I and MCS from the header and assemble them into blocks. The blockchain sublayer entity can store the assembled unverified blocks locally (e.g., a blockchain copy).

[0215] Among them, the blockchain sublayer entity will extract the MAC PDU#1 with the parameters HARQ_I and MCS and submit it to the PHY layer (i.e. continue to transmit MAC PDU#1), and add the above-mentioned unverified block to MAC PDU#2 after MAC PDU#1 as the SDU of the first PDU, so as to avoid delaying the sending of MAC PDU#1.

[0216] Furthermore, upon receiving MAC PDU #2, the second device may extract the block information from the first PDU submitted by the PHY layer of the second device based on the blockchain parameter indication information and the first indication information, and submit the first PDU with the extracted block information to the upper protocol layer of the blockchain sublayer. It is understood that the blockchain sublayer may also add unverified blocks to MAC PDU #1, from which the HARQ_I and MCS parameters have been extracted.

[0217] In addition, the above-mentioned unverified blocks are added to MAC PDU#1 or MAC PDU#2. For details, please refer to (b) and (c) in Figure 8, which will not be repeated here.

[0218] In addition, the above-mentioned extraction of parameters from the PDU header is only an example. It is also possible to copy the parameters from the PDU header without changing the PDU, thereby reducing changes to the PDU and reducing the complexity of blockchain sub-layer deployment.

[0219] It should be understood that the process for the second device to send the first data to be confirmed by consensus is similar to the process for the first device to send the first data to be confirmed by consensus, and will not be repeated here.

[0220] Example B: The blockchain sublayer is deployed within the PDCP layer.

[0221] Figure 10 is a schematic diagram of a protocol stack structure for deploying a blockchain sublayer within a PDCP layer according to an embodiment of the present application. As shown in Figure 10, logically, the blockchain sublayer can be deployed at the bottom of the PDCP layer.

[0222] As shown in Figure 10, assuming that the first device sends service data, the IP data packet corresponding to the service data is processed by the SDAP layer and the PDCP layer in sequence to obtain PDCP PDU#1. After receiving PDCP PDU#1, the blockchain sublayer entity determines that the parameters to be confirmed by consensus are MAC-I and K according to the blockchain parameter indication information. NRP-sess ID, the blockchain sub-layer entity can call the relevant parameters of the PDCP layer, such as MAC-I and / or K NRP-sess ID, the blockchain sub-layer entity can use MAC-I and / or K NRP-sess The IDs are assembled into blocks. The blockchain sublayer entity can store the assembled unverified blocks locally (e.g., a blockchain copy).

[0223] It can be understood that the specific method of sending the above blocks can be found in the relevant description of Figure 9, which will not be repeated here.

[0224] Example C: The blockchain sublayer is deployed within the SDAP layer.

[0225] Figure 11 is a schematic diagram of a protocol stack structure for deploying a blockchain sublayer within an SDAP layer, as provided by an embodiment of the present application. As shown in Figure 11, the blockchain sublayer can logically be deployed at the bottom of the SDAP layer. This allows the blockchain sublayer to obtain SDAP PDUs and, based on the headers in the SDAP PDUs, obtain scheduling parameters or other SDAP layer information.

[0226] As shown in Figure 11, assuming the first device sends service data, the IP data packet corresponding to the service data is processed by the SDAP layer, resulting in SDAP PDU#1. After receiving SDAP PDU#1, the blockchain sublayer entity determines, based on the blockchain parameter indication, that the parameters subject to consensus confirmation are QFI and RDI. The blockchain sublayer entity extracts the QFI and RDI parameters from the SDAP PDU#1 header and assembles them into blocks. The blockchain sublayer entity may store these assembled, unverified blocks locally (e.g., as a blockchain replica).

[0227] It can be understood that the specific method of sending the above blocks can be found in the relevant description of Figure 9, which will not be repeated here.

[0228] Example D: The blockchain sublayer is deployed within the SDAP layer.

[0229] Figure 12 is a schematic diagram of a protocol stack structure for deploying a blockchain sublayer within an RRC layer, as provided by an embodiment of the present application. As shown in Figure 12, the blockchain sublayer can be logically deployed at the bottom of the RRC layer, so that the blockchain sublayer can obtain RRC PDUs and, based on the header in the RRC PDUs, obtain RRC messages.

[0230] As shown in Figure 12, assume that the first device sends an RRC message. After processing at the RRC layer, RRC PDU#1 is obtained. After receiving RRC PDU#1, the blockchain sublayer entity determines, based on the blockchain parameter indication information, that the RRC layer data that should undergo consensus confirmation is the capability information and measurement report of the first device. The blockchain sublayer entity extracts the capability information and measurement report from RRC PDU#1 and assembles them into blocks. The blockchain sublayer entity may store the assembled, unverified blocks locally (e.g., in a blockchain replica).

[0231] It can be understood that the specific method of sending the above blocks can be found in the relevant description of Figure 9, which will not be repeated here.

[0232] For steps S702 and S703:

[0233] It is understood that if the first device is a storage node in a blockchain network or does not support a consensus algorithm, the first device may receive the consensus result of the first data from a blockchain node in the blockchain network it has joined. Alternatively, if the first device is a maintenance node in a blockchain network, the first device may determine the consensus confirmation result of the first data based on the votes regarding the consensus confirmation of the first data from multiple blockchain network nodes participating in the consensus in the blockchain network. Alternatively, if the first device is a node participating in the consensus vote in the blockchain network, the first device may send a vote to the maintenance node in the blockchain network and receive the consensus confirmation result of the first data from the broadcast node in the blockchain.

[0234] Similarly, if the second device is a broadcast node, the second device can broadcast the first data. If the second device is a storage node, the second device stores the first data. If the second device is a maintenance node, the second device can determine the consensus confirmation result of the first data based on the consensus confirmation votes of multiple blockchain network nodes participating in the consensus within the blockchain network.

[0235] For step S704 and step S705:

[0236] It can be understood that after the first data is confirmed by consensus, the first data can be stored in the local blockchain (or called a local blockchain copy), which can avoid loss and unilateral tampering, and achieve redundant availability.

[0237] It should be understood that the blockchain parameter operation indication information in the embodiments of the present application may also indicate a second operation and a parameter corresponding to the second operation. The second operation may refer to adjusting the parameter corresponding to the second operation. For example, if the parameter corresponding to the second operation is MCS, the blockchain parameter operation indication information may be used to indicate adding n, subtracting n, or multiplying the MCS by a certain proportional coefficient, etc., where n can be an integer or other numerical value, and is not specifically limited in the embodiments of the present application.

[0238] In addition, the blockchain parameter operation indication information can also be used to indicate the execution of a third operation on other parameters. For example, for the blockchain sub-layer PDU shown in (a) of Figure 8, the blockchain parameter operation indication information can be used in the first field to indicate a storage operation, etc., which is not specifically limited in this embodiment of the present application.

[0239] It can be understood that if the blockchain parameter operation indication information has not yet been uploaded to the chain, the blockchain parameter operation indication information needs to be uploaded to the chain. After consensus confirmation, the first device or the second device can adjust the data to be adjusted in the RRC layer, and / or the transmission parameters to be adjusted in the data link layer for transmitting control signaling and / or business data.

[0240] In a possible implementation, the method shown in FIG7 further includes:

[0241] S706. The first device and / or the second device obtains adjustment indication information. The adjustment indication information is used to indicate adjustment of data to be agreed upon and confirmed in the RRC layer, and / or transmission parameters to be agreed upon and confirmed in the data link layer for transmitting control signaling and / or service data. And / or, data to be adjusted in the RRC layer and / or transmission parameters to be adjusted in the data link layer for transmitting control signaling and / or service data.

[0242] S707. The first device and / or the second device updates the blockchain parameter operation instruction information according to the adjustment instruction information to obtain updated blockchain parameter operation instruction information.

[0243] That is to say, the blockchain parameter operation indication information in the blockchain can be updated according to the adjustment indication information, thereby being able to more flexibly adapt to wireless networks with dynamically changing channels.

[0244] It can be understood that the adjustment indication information can be a call request initiated by a node in the blockchain network, and after the call request is confirmed by consensus, it is broadcast to each node in the blockchain network, and then the first device and / or the second device can receive the adjustment indication information broadcast in the blockchain network.

[0245] In addition, at least some of the nodes within the blockchain network can deploy a first SC for adjusting blockchain parameter operation instruction information. By calling the first SC, the first SC can be automatically executed, and then the first device and / or the second device can obtain the adjustment instruction information.

[0246] The following description will be made by taking the deployment of the first SC by the first device as an example.

[0247] In one possible implementation, the adjustment instruction information is adjustment instruction information from a first SC for adjusting blockchain parameter operation instruction information; the method shown in FIG7 further includes:

[0248] S708: The first device sends a first call request to the first blockchain node. Accordingly, the first blockchain node receives the first call request from the first device. The first call request is used to request the call of a first SC, which is used to adjust blockchain parameter operation instruction information.

[0249] It is understood that the first blockchain node may include: a maintenance node and / or a broadcast node within the blockchain network. In addition, the second device may be a maintenance node, a broadcast node, or a storage node within the blockchain network, which is not specifically limited in the embodiments of the present application.

[0250] S709: The first blockchain node sends a first consensus message to the first device. Accordingly, the first device receives the first consensus message from the first blockchain node. The first consensus message indicates that the first call request has been confirmed by consensus.

[0251] It is understood that the first device can perform a consensus confirmation process with multiple nodes in the blockchain network to achieve consensus confirmation of the first call request. For example, if the first device is a node other than the maintenance node in the blockchain network, the first device can receive the first consensus message from the first blockchain node.

[0252] In addition, when the first device is a maintenance node in the blockchain network, the first device can determine whether the consensus confirmation of the first call request is passed based on the voting result of the consensus confirmation of the first call request.

[0253] It should be understood that in the embodiment of the present application, the second device may also deploy the first SC and execute steps S708 and S709, which will not be repeated here.

[0254] In another possible implementation, the invocation of the first SC is triggered based on the blockchain status of the first data. That is, if consensus on the first data is successful, the blockchain status (or transaction status) corresponding to the first data will change. For example, if the blockchain status of the first data indicates that the transaction has reached consensus, this can trigger the first device to invoke the first SC. Furthermore, triggering the invocation of the first SC based on the blockchain status of the first data can reduce the number of steps required to invoke the first SC.

[0255] It can be understood that the first SC is a piece of automatically executed code, and then when the first call request consensus is confirmed, the first call request can trigger the automatic execution of the first SC. The first SC can determine the adjustment indication information based on the RRC layer data and / or data link layer transmission parameters of multiple parties on the blockchain. In this way, new protocol stack functions can be enabled through the data or transmission parameters of the protocol stacks of multiple wireless network entities in a secure manner.

[0256] In other words, by deploying smart contracts on the blockchain, the on-chain data of multiple blockchain nodes can be collected, and then analysis and calculation can be performed to adjust the blockchain parameter operation indication information, thereby affecting the function of the protocol stack based on the adjustment of the blockchain parameter indication information.

[0257] The following are some examples to illustrate the updated blockchain parameter operation instructions.

[0258] Table 6

[0259] Table 6 is a comparative example of the blockchain parameter operation instruction information before and after the update provided by the embodiment of the present application. Among them, some parameters after the update may no longer continue consensus confirmation (on the chain), such as K NRP-sess Parameters with long-term changes, such as ID, terminal device capability information, MIB, or HARQ_I, can be uplinked once and then no longer, or no longer uplinked while the RRC connection is maintained. In addition, some parameters (such as QFI, CQI, or measurement reports) should continue to be uplinked due to their rapid changes.

[0260] It can be understood that the blockchain can include the on-chain data of multiple wireless network entities, and the blockchain's ability to unite multiple trusted parties can be used to adjust the parameters in the protocol stack, thereby improving transmission performance or service QoS performance, etc., and enabling new protocol stack functions.

[0261] For example, the updated blockchain operation indication information in Table 6 indicates that HARQ_N is reduced, which can improve the transmission throughput by reducing the maximum number of HARQ retransmissions. In addition, the updated blockchain operation indication information can also indicate that HARQ_N is increased to improve the reliability of transmission.

[0262] For another example, the updated blockchain operation instruction information in Table 6 indicates an MCS increase, which can increase or decrease the transmission rate. It can be understood that the first SC can determine the current channel quality based on the on-chain parameters of multiple parties on the blockchain and, if the channel quality is good, instruct to increase the MCS to increase the transmission rate. Alternatively, if the channel quality is poor, the first SC can instruct to decrease the MCS to ensure transmission reliability.

[0263] It can be understood that Table 6 is only an example. The updated blockchain parameter operation indication information may also indicate a specific value by which HARQ_N is reduced or a specific value by which MCS is increased. This embodiment of the present application does not specifically limit this.

[0264] In addition, the updated blockchain parameter operation indication information may also indicate the addition of new RRC layer data, and / or transmission parameters in the data link layer for transmitting control signaling and / or business data, which is not specifically limited in this embodiment of the present application.

[0265] For example, the first SC can optimize and adjust the regional or cross-operator network QoS based on the QoS parameters of multiple parties uplinked, and then the first SC can instruct the QoS configuration (QoS profile) or QoS rules (QoS rule) to be adjusted, thereby optimizing and adjusting the QoS.

[0266] It can be understood that after the first device and / or the second device updates the blockchain operation indication information, the first device and / or the second device can adjust the sent PDU according to the updated blockchain operation indication information. The following explanation is given by taking the first device sending the third data as an example.

[0267] In one possible implementation, the updated blockchain operation indication information is used to indicate: data to be adjusted in the RRC layer, and / or transmission parameters to be adjusted in the data link layer for transmitting control signaling and / or service data; the method shown in FIG7 further includes:

[0268] S710: The first device obtains second data, wherein the second data includes data to be adjusted in the RRC layer and / or transmission parameters to be adjusted in the data link layer for transmitting control signaling and / or service data.

[0269] It can be understood that the second data can be a PDU in the RRC layer and / or the data link layer, or the second data can be a transmission parameter called by the RRC layer and / or the data link layer. The embodiments of the present application do not specifically limit this.

[0270] S711. The first device adjusts the second data according to the updated blockchain operation instruction information to obtain third data.

[0271] For example, taking the protocol stack structure shown in Figure 9 as an example, assuming that MAC PDU #3 carries the MCS, and the updated blockchain operation indication information indicates that the MCS is increased by 1, the blockchain sublayer entity adjusts the MCS value corresponding to the MCS field in the MAC PDU #3 header by 1, obtaining the third data, namely, the MAC PDU #3 with the MCS field changed. Furthermore, the blockchain sublayer entity passes MAC PDU #3 to the physical layer.

[0272] S712: The first device sends third data to the second device. Correspondingly, the second device receives the third data from the first device.

[0273] It can be understood that after the second device receives the third data, when the PDU carrying the third data passes through the blockchain sublayer, the blockchain sublayer entity can adjust the third data according to the updated blockchain operation instruction information in step S711, and thus obtain the fourth data.

[0274] In addition, continuing with the example of step S711, the blockchain sublayer of the second device may add 1 again to the MCS value +1 in the second data.

[0275] That is to say, when the first device and / or device transmits a PDU including parameters corresponding to the updated blockchain parameter operation indication information, it processes the PDU to enable the blockchain to enable the protocol stack function.

[0276] It is understandable that the second device can also perform the above steps S710 to S712, which will not be repeated here.

[0277] It should be understood that before the first device and the second device establish a wireless connection, the first device and the second device may join the same blockchain network. Furthermore, when the first device establishes a wireless connection with the second device, the first device and the second device may also join the blockchain network by establishing the wireless connection, or complete preparations for the first device and the second device to join the blockchain network.

[0278] The following takes the first device as a terminal device and the second device as an access network device as an example to illustrate the process of the first device accessing the second device.

[0279] In a possible implementation, the method shown in FIG7 further includes:

[0280] S713. The first device sends a first request to the second device. Accordingly, the second device receives the first request from the first device. The first request is used to request access to a wireless network, and the first request includes second indication information. The second indication information is used to indicate at least one of the following: an identity of the terminal device, a capability of the terminal device, or a protocol layer of the terminal device with blockchain capabilities. The identity of the terminal device is used to determine permission to join the blockchain network, the capability of the terminal device is used to determine whether the terminal device supports joining the blockchain network, and the protocol layer of the terminal device with blockchain capabilities is used to determine the protocol layer corresponding to the first data.

[0281] It is understood that the first request may be an RRC setup request, which also requests to establish an RRC connection. The first request may also carry a cause value for the RRC setup.

[0282] In addition, the identity of the terminal device may include an identifier of the terminal device. The capabilities of the terminal device may include data storage capacity, computing capacity, and communication capacity. For example, data storage capacity may include storage size or storage rate (also known as read / write rate, read / write bandwidth, etc.). Computing capacity may include computing frequency. Communication capabilities may include the types of network connections supported by the terminal device.

[0283] It should be understood that the second device can verify whether the first device has permission to join the blockchain network based on the first device's identity information. Alternatively, the second device can determine whether the first device supports joining the blockchain network based on the first device's capabilities. Furthermore, the second device can determine at which layer the first device's blockchain data is processed based on the protocol layer at which the first device has blockchain capabilities.

[0284] In addition, when the second device can determine that the first device can access based on the information carried in the first request, it can send a first response to the first device to indicate the accessed resources and blockchain information to the first device.

[0285] S714: The second device sends a first response to the first device. Accordingly, the first device receives the first response from the second device. The first response includes third indication information, where the third indication information is used to indicate that the access network device has a blockchain-capable protocol layer.

[0286] It is understood that the first response may be an RRC establishment message, and the first response may also include configuration information of SRB1 resources. In addition, the first device may determine at which layer the blockchain data of the first device is processed through the third indication information.

[0287] It should be understood that, as shown in Figures 9 to 12, the first request in step S713 and the first response in step S714 are interacted at the RRC layer, and the protocol layer with blockchain capabilities between the first device and the second device is peer-to-peer. In addition, in an embodiment of the present application, the protocol layer with blockchain capabilities between the first device and the second device may be unequal. For example, the protocol layer with blockchain capabilities of the first device may be at the MAC layer, and the protocol layer with blockchain capabilities of the second device may be at the RLC layer. This embodiment of the present application does not specifically limit this.

[0288] That is, when the first device establishes a connection with the second device, relevant information of the blockchain can be exchanged between the two through the first request and the first response, so as to facilitate trusted interaction between the blockchain and the protocol stack.

[0289] Because in the embodiment of the present application, the first device can upload data in the protocol stack of the wireless network, such as the RRC layer or the data link layer, to the chain through the first indication information and the first data, thereby achieving direct association and interaction between the blockchain and the data in the protocol stack of the wireless network, thereby fully utilizing the credibility of the blockchain to enhance the security of the data in the protocol stack. Therefore, based on the blockchain-based data transmission method provided in the embodiment of the present application, the deep integration of blockchain technology and the wireless network can be achieved by directly associating and interacting the blockchain with the data in the protocol stack of the wireless network, thereby fully utilizing the credibility of the blockchain to enhance the security of the data in the protocol stack.

[0290] The above description primarily describes the solutions provided by the embodiments of the present application from the perspective of the interaction between a first device and a second device. Accordingly, embodiments of the present application also provide a communication device for implementing the various methods described above. The communication device may be the first device in the method embodiments described above, or a device that includes the first device, or a component that can be used with the first device; alternatively, the communication device may be the second device in the method embodiments described above, or a device that includes the second device, or a component that can be used with the second device. It will be understood that, to implement the aforementioned functions, the communication device includes hardware structures and / or software modules corresponding to the respective functions. Those skilled in the art will readily appreciate that, in conjunction with the various exemplary units and algorithm steps described in the embodiments disclosed herein, the present application can be implemented in hardware or a combination of hardware and computer software. Whether a function is implemented in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0291] The embodiment of the present application can divide the functional modules of the communication device according to the above method embodiment. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one processing module. The above integrated modules can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiment of the present application is schematic and is only a logical functional division. In actual implementation, there may be other division methods.

[0292] Taking the communication device as the first device or the second device in the above method embodiment as an example, Figure 13 is a schematic diagram of the structure of a communication device provided in an embodiment of the present application. As shown in Figure 13, communication device 1300 includes: a processing module 1301 and a transceiver module 1302. The processing module 1301 is used to perform the processing functions of the first device or the second device in the above method embodiment. The transceiver module 1302 is used to perform the transceiver functions of the first device or the second device in the above method embodiment.

[0293] Among them, all relevant contents of each step involved in the above method embodiment can be referred to the functional description of the corresponding functional module and will not be repeated here.

[0294] Since the communication device 1300 provided in this embodiment can execute the above-mentioned blockchain-based data transmission method, the technical effects that can be obtained can refer to the above-mentioned method embodiments and will not be repeated here.

[0295] In one possible design solution, the transceiver module 1302 may include a receiving module and a sending module (not shown in FIG13 ). The transceiver module is used to implement the sending function and the receiving function of the communication device 1300 .

[0296] In one possible design, communication device 1300 may further include a storage module (not shown in FIG13 ) storing a program or instruction. When processing module 1301 executes the program or instruction, communication device 1300 may perform the functions of the first device or the second device in any of the methods shown in FIG6 to FIG12 .

[0297] It should be understood that the processing module 1301 involved in the communication device 1300 can be implemented by a processor or a processor-related circuit component, which can be a processor or a processing unit; the transceiver module 1302 can be implemented by a transceiver or a transceiver-related circuit component, which can be a transceiver or a transceiver unit.

[0298] For example, FIG14 is a schematic diagram of the structure of another communication device provided in an embodiment of the present application. The communication device may be a first device or a second device, or a chip (system) or other component or assembly that can be provided in the first device or the second device. As shown in FIG14 , the communication device 1400 may include a processor 1401. In one possible design scheme, the communication device 1400 may further include a memory 1402 and / or a transceiver 1403. The processor 1401 is coupled to the memory 1402 and the transceiver 1403, such as by a communication bus.

[0299] The following is a detailed introduction to the various components of the communication device 1400 with reference to FIG14 :

[0300] The processor 1401 is the control center of the communication device 1400 and can be a single processor or a collective term for multiple processing elements. For example, the processor 1401 can be one or more central processing units (CPUs), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application, such as one or more digital signal processors (DSPs) or one or more field programmable gate arrays (FPGAs).

[0301] In one possible design, the processor 1401 may execute various functions of the communication device 1400 by running or executing software programs stored in the memory 1402 and calling data stored in the memory 1402 .

[0302] In a specific implementation, as an embodiment, the processor 1401 may include one or more CPUs, such as CPU0 and CPU1 shown in FIG14 .

[0303] In a specific implementation, as an embodiment, the communication device 1400 may also include multiple processors, such as the processor 1401 and the processor 1404 shown in FIG14 . Each of these processors may be a single-core processor (single-CPU) or a multi-core processor (multi-CPU). The processor herein may refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0304] The memory 1402 is used to store the software program for executing the solution of the present application, and the execution is controlled by the processor 1401. The specific implementation method can refer to the above method embodiment and will not be repeated here.

[0305] In one possible design, the memory 1402 may be a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (RAM) or other type of dynamic storage device that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compact disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 1402 may be integrated with the processor 1401, or may exist independently and be coupled to the processor 1401, and this is not specifically limited in the embodiments of the present application.

[0306] Transceiver 1403 is used for communication with other communication devices. For example, if communication device 1400 is a first device, transceiver 1403 can be used to communicate with a second device, or a first blockchain node. For another example, if communication device 1400 is a second device, transceiver 1403 can be used to communicate with a first device, or a first blockchain node.

[0307] In one possible design, transceiver 1403 may include a receiver and a transmitter (not separately shown in FIG14 ), wherein the receiver is configured to implement a receiving function, and the transmitter is configured to implement a transmitting function.

[0308] In one possible design solution, the transceiver 1403 may be an input / output interface or an interface circuit for inputting and / or outputting signals.

[0309] In one possible design scheme, the transceiver 1403 can be integrated with the processor 1401, or it can exist independently and be coupled to the processor 1401. This embodiment of the present application does not specifically limit this.

[0310] It should be noted that the structure of the communication device 1400 shown in FIG14 does not constitute a limitation on the communication device. An actual communication device may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0311] In addition, the communication device 1400 can execute the above-mentioned information transmission method, so the technical effects that can be obtained can refer to the above-mentioned method embodiments and will not be repeated here.

[0312] In one possible implementation, an embodiment of the present application further provides a computer-readable storage medium having a computer program or instructions stored thereon, which implements the functions of the above-mentioned method embodiment when the computer program or instructions are executed by a computer.

[0313] In a possible implementation, an embodiment of the present application further provides a computer program product, which implements the functions of the above method embodiment when executed by a computer.

[0314] In a possible implementation, an embodiment of the present application further provides a communication system, which includes the first device and the second device described in the above method embodiment.

[0315] In one possible implementation, the communication system also includes the first blockchain node described in the above method embodiment.

[0316] In a possible implementation, an embodiment of the present application further provides a communication method, which includes the method described in any of the above method embodiments or any of its implementations.

[0317] In the above embodiments, all or part of the embodiments can be implemented by software, hardware, firmware, or any combination thereof. When implemented using a software program, all or part of the embodiments can be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions according to the embodiments of the present application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more available media. The available media can be magnetic media (e.g., floppy disk, hard disk, tape), optical media, or semiconductor media (e.g., solid state drive (SSD)).

[0318] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0319] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0320] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0321] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0322] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0323] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0324] Although the present application is described herein in conjunction with various embodiments, in the process of implementing the claimed application, those skilled in the art may understand and implement other variations of the disclosed embodiments by reviewing the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude multiple situations. A single processor or other unit may implement several functions listed in the claims. Certain measures are recorded in different dependent claims, but this does not mean that these measures cannot be combined to produce good results.

[0325] Although the present application has been described with reference to specific features and embodiments thereof, it is apparent that various modifications and combinations may be made thereto without departing from the scope of the present application. Accordingly, this specification and the drawings are merely illustrative of the present application as defined by the appended claims and are deemed to cover any and all modifications, variations, combinations or equivalents within the scope of the present application. Obviously, those skilled in the art may make various modifications and variations to the present application without departing from the scope of the present application. Thus, the present application is intended to encompass such modifications and variations as fall within the scope of the claims of the present application and their equivalents.

Claims

1. A data transmission method based on blockchain, characterized in that, The method includes: Sending first indication information and first data, where the first indication information is used to indicate that the first data is blockchain data to be consensus-confirmed, and the first data includes data of the radio resource control (RRC) layer, and / or transmission parameters in the data link layer for transmitting control signaling and / or service data; Obtaining a consensus confirmation result of the first data, where the consensus confirmation result of the first data is used to indicate that the first data has passed the consensus confirmation; Updating the first data to the local blockchain.

2. The method according to claim 1, wherein The method further includes: Sending a first request, where the first request is used to request access to a wireless network, and the first request includes second indication information, where the second indication information is used to indicate at least one of the following: the identity of the terminal device, the capabilities of the terminal device, or the protocol layer of the terminal device with blockchain capabilities. The identity of the terminal device is used to determine the permission to join the blockchain network, the capabilities of the terminal device are used to determine whether the terminal device supports joining the blockchain network, and the protocol layer of the terminal device with blockchain capabilities is used to determine the protocol layer corresponding to the first data; Receiving a first response, where the first response includes third indication information, and the third indication information is used to indicate the protocol layer of the access network device with blockchain capabilities.

3. A data transmission method based on blockchain, characterized in that, The method includes: Receiving first indication information and first data, where the first indication information is used to indicate that the first data is blockchain data to be consensus-confirmed, and the first data includes data of the radio resource control (RRC) layer, and / or transmission parameters in the data link layer for transmitting control signaling and / or service data; Obtaining a consensus confirmation result of the first data, where the consensus confirmation result of the first data is used to indicate that the first data has passed the consensus confirmation; Updating the first data to the local blockchain.

4. The method according to claim 3, wherein The method further includes: Receiving a first request, where the first request is used to request access to a wireless network, and the first request includes second indication information, where the second indication information is used to indicate at least one of the following: the identity of the terminal device, the capabilities of the terminal device, or the protocol layer of the terminal device with blockchain capabilities. The identity of the terminal device is used to determine the permission to join the blockchain network, the capabilities of the terminal device are used to determine whether the terminal device supports joining the blockchain network, and the protocol layer of the terminal device with blockchain capabilities is used to determine the protocol layer corresponding to the first data; Sending a first response, where the first response includes third indication information, and the third indication information is used to indicate the protocol layer of the access network device with blockchain capabilities.

5. The method according to any one of claims 1-4, characterized in that, The transmission parameters include at least one of the following: scheduling parameters of the media access control (MAC) layer, security parameters of the packet data convergence protocol (PDCP) layer, or quality of service (QoS) flow parameters of the service data adaptation protocol (SDAP) layer.

6. The method according to claim 5, wherein The scheduling parameters include at least one of the following: channel quality parameters, modulation parameters, or retransmission indication parameters.

7. The method according to claim 5 or 6, characterized in that, The security parameters include a message authentication code for integrity protection of data within the PDCP layer, and / or an identifier of a key for encrypting the data within the PDCP layer and / or the message authentication code.

8. The method according to any one of claims 5-7, characterized in that The QoS flow parameters include: a QoS flow identifier QFI, and / or a reflection QoS flow to data radio bearer DRB mapping indication RDI.

9. The method according to any one of claims 1-8, characterized in that The data of the RRC layer includes at least one of the following: capability information of the terminal device, a measurement report of the terminal device, or system information.

10. The method according to any one of claims 1-9, characterized in that, The first indication information and the first data are carried by a protocol data unit PDU of a first protocol layer, and the first indication information is further used to indicate the protocol layer corresponding to the first data, and the protocol layer corresponding to the first data includes at least one of the following: the RRC layer, the SDAP layer, the PDCP layer, or the MAC layer.

11. The method according to any one of claims 1-10, characterized in that, The first data is determined according to blockchain parameter operation indication information, and the blockchain parameter operation indication information is used to indicate data to be consensus-confirmed in the RRC layer, and / or transmission parameters for transmitting control signaling and / or service data to be consensus-confirmed in the data link layer.

12. The method according to claim 11, wherein The method further includes: Obtaining adjustment indication information, where the adjustment indication information is used to indicate adjustment of data to be consensus-confirmed in the RRC layer, and / or transmission parameters for transmitting control signaling and / or service data to be consensus-confirmed in the data link layer; and / or The data to be adjusted in the RRC layer, and / or the transmission parameters for transmitting control signaling and / or service data to be adjusted in the data link layer; Updating the blockchain parameter operation indication information according to the adjustment indication information to obtain updated blockchain parameter operation indication information.

13. The method according to claim 12, wherein The adjustment indication information is adjustment indication information from a first smart contract SC for adjusting blockchain parameter operation indication information; the method further includes: Sending a first call request, where the first call request is used to request to call the first SC, and the first SC is used to adjust blockchain parameter operation indication information; Receiving a first consensus message, where the first consensus message is used to indicate that the first call request has passed the consensus confirmation.

14. The method according to claim 12 or 13, characterized in that, The updated blockchain operation indication information is used to indicate: the data to be adjusted in the RRC layer, and / or the transmission parameters for transmitting control signaling and / or service data to be adjusted in the data link layer; the method further includes: Obtaining second data, where the second data includes the data to be adjusted in the RRC layer, and / or the transmission parameters for transmitting control signaling and / or service data to be adjusted in the data link layer; Adjusting the second data according to the updated blockchain operation indication information to obtain third data; Sending the third data.

15. A communication device, characterized in that, The communication device includes a module or unit for executing the method according to any one of claims 1-2, 5-14, or includes a module or unit for executing the method according to any one of claims 3-4, 5-14.

16. A communication device, characterized in that, The communication device includes a processor, and the processor is configured to cause the communication device to execute the method according to any one of claims 1-2, 5-14 through logic circuits and / or executing instructions, or to cause the communication device to execute the method according to any one of claims 3-4, 5-14.

17. The communication device according to claim 16, wherein The communication device further includes a memory, and the memory is configured to store the instructions.

18. The communication device according to claim 16 or 17, characterized in that, The communication device further includes a communication interface, and the communication interface is configured to input and / or output signaling and / or data.

19. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes instructions, and when the instructions are run by a processor, the method according to any one of claims 1-2, 5-14 is implemented, or the method according to any one of claims 3-4, 5-14 is implemented.

20. A computer program product, characterized in that, The computer program product includes instructions, and when the instructions are run on a computer, the computer is caused to execute the method according to any one of claims 1-2, 5-14, or the computer is caused to execute the method according to any one of claims 3-4, 5-14.

21. A communication system, characterized in that, The communication system includes a first device and a second device, the first device is configured to execute the method according to any one of claims 1-2, 5-14, and the second device is configured to execute the method according to any one of claims 3-4, 5-14.

Images