Communication method and related product
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- HUAWEI TECH CO LTD
- Filing Date
- 2023-10-25
- Publication Date
- 2026-08-06
Smart Images
Figure CN2023126535_06082026_PF_FP_ABST
Abstract
Description
Communication methods and related products Technical Field
[0001] This application relates to the field of communications, and in particular to communication methods and related products. Background Technology
[0002] In essence, blockchain is a shared database where data or information is stored, possessing characteristics such as "unforgeable," "fully traceable," "transparent," and "collectively maintained." Blockchain technology may be introduced into telecommunications networks.
[0003] Current mainstream blockchains, such as Bitcoin and Hyperledger, integrate all blockchain functions into a single protocol stack, which is inconsistent with the characteristics of telecommunications networks (or communication networks) that divide protocols into management plane (MP), control plane (CP), and user plane (UP). Other blockchains, such as Ethereum, divide blockchain functions into two main categories: connection and transaction transmission. Currently, existing blockchain protocols and protocol stacks cannot be simply and directly applied to telecommunications networks. Therefore, it is necessary to research solutions for applying blockchain to telecommunications networks.
[0004] Summary of the Invention
[0005] This application discloses communication methods and related products in order to apply blockchain in telecommunications networks.
[0006] In a first aspect, embodiments of this application provide a communication method applied to a first node in a telecommunications network. The method includes: sending a first message, the first message being used for at least one of the following: management of blockchain capabilities, deployment of blockchain capabilities, management of blockchain clients, deployment of blockchain clients, establishment of a blockchain, deletion of a blockchain, update of a blockchain, configuration of a blockchain, acquisition of blockchain parameters, deployment of a subdomain blockchain, or configuration of a subdomain blockchain; and receiving a second message, the second message being used in response to the first message.
[0007] Existing blockchain protocols and protocol stacks cannot be directly applied to telecommunications networks. In this embodiment, the first node sends a first message to the second node; at least one of the following can be implemented in the telecommunications network: management of blockchain capabilities, deployment of blockchain capabilities, establishment of blockchain, deletion of blockchain, update of blockchain, configuration of blockchain, acquisition of blockchain parameters, deployment of subdomain blockchain, or configuration of subdomain blockchain.
[0008] In one possible implementation, the first message for managing blockchain capabilities includes: the first message for deleting, activating, updating, locking, or closing the blockchain capability.
[0009] This implementation allows for at least one of the following actions to be performed in a telecommunications network: deletion, activation, update, locking, or closure of the blockchain capabilities of a node.
[0010] In one possible implementation, the first message for managing the blockchain client includes: the first message being used for at least one of deleting, activating, updating, locking, or closing the blockchain client.
[0011] In this implementation, at least one of the following can be achieved: deletion, activation, update, locking, or shutdown of the blockchain client deployed on the node in the telecommunications network.
[0012] In one possible implementation, the first message for activating blockchain capabilities includes: the first message for activating the blockchain capabilities of a second node in the telecommunications network, the first message carrying information indicating the blockchain capabilities of the second node; or, the first message for activating the blockchain capabilities of one or more nodes within a first subdomain, the first subdomain including one or more nodes managed by the second node, the second node being managed by the first node, the first message carrying information indicating the blockchain capabilities of the one or more nodes, and information indicating the number of nodes supporting blockchain capabilities within the first subdomain.
[0013] In this implementation, the blockchain capabilities of nodes can be activated within the telecommunications network.
[0014] In one possible implementation, the first message for deploying blockchain capabilities includes: the first message for deploying blockchain capabilities of a second node in the telecommunications network, the first message carrying an installation package for deploying blockchain capabilities of the second node and first configuration information, the first configuration information being used to indicate the blockchain capabilities of the second node; or, the first message for deploying blockchain capabilities of one or more nodes within a first subdomain, the first subdomain including one or more nodes managed by the second node, the second node being managed by the first node, the first message carrying an installation package for deploying blockchain capabilities of the one or more nodes, second configuration information, and information indicating the number of nodes supporting blockchain capabilities within the first subdomain, the second configuration information being used to indicate the blockchain capabilities of the one or more nodes.
[0015] In this implementation, if the first message is used to deploy the blockchain capabilities of a second node in the telecommunications network or to deploy the blockchain capabilities of one or more nodes in the first subdomain, blockchain capabilities can be deployed for nodes in the telecommunications network.
[0016] In one possible implementation, the first message for deploying a blockchain client includes: the first message for deploying a blockchain client on a second node in the telecommunications network, the first message carrying an installation package for deploying the blockchain client on the second node and first configuration information, the first configuration information indicating the blockchain capabilities of the blockchain client on the second node; or, the first message for deploying a blockchain client on one or more nodes within a first subdomain, the first subdomain including one or more nodes managed by the second node, the second node being managed by the first node, the first message carrying an installation package for deploying the blockchain client on the one or more nodes, second configuration information, and information indicating the number of nodes within the first subdomain that support the deployment of blockchain clients, the second configuration information indicating the blockchain capabilities of the blockchain client on the one or more nodes.
[0017] In this implementation, if the first message is used for the deployment of a blockchain client for a second node in the telecommunications network or for the deployment of a blockchain client for one or more nodes in the first subdomain, a blockchain client can be deployed for the nodes in the telecommunications network.
[0018] In one possible implementation, the first message is used to establish a blockchain in the telecommunications network that includes a second node, and the first message carries configuration information of the blockchain that includes the second node; or, the first message is used to establish one or more blockchains in a first subdomain, the first subdomain including one or more nodes managed by the second node, the second node being managed by the first node, and the first message carrying configuration information of the one or more blockchains.
[0019] This implementation method enables the establishment of a blockchain within a telecommunications network.
[0020] In one possible implementation, the first message is used for updating a blockchain in the telecommunications network that includes a second node, and the first message carries configuration information for updating the blockchain that includes the second node; or, the first message is used for updating one or more blockchains in a first subdomain, the first subdomain including one or more nodes managed by the second node, the second node being managed by the first node, and the first message carrying configuration information for updating the one or more blockchains.
[0021] In this implementation, the blockchain in the telecommunications network can be updated.
[0022] In one possible implementation, the first message for configuring the blockchain includes: the first message for configuring the blockchain connection, wherein the configuration of the blockchain connection includes at least one of configuring the blockchain connection method, configuring the blockchain network topology, and configuring the blockchain node list.
[0023] In this implementation, the configuration of the blockchain connection can be implemented in the telecommunications network.
[0024] In one possible implementation, the first message for configuring the blockchain includes: the first message for configuring a blockchain node, wherein the configuration of the blockchain node includes at least one of configuring blockchain node attributes, configuring blockchain node roles, or configuring blockchain node operating status.
[0025] In this implementation, blockchain nodes can be configured within a telecommunications network.
[0026] In one possible implementation, the first message used to obtain blockchain parameters includes: the first message being used to request blockchain configuration information, subscribe to blockchain configuration information, request blockchain identifier, request blockchain type, request blockchain capability information, or subscribe to blockchain capability information, at least one of the following:
[0027] In this implementation, at least one of the following can be implemented in a telecommunications network: requesting blockchain configuration information, subscribing to blockchain configuration information, requesting blockchain identifier, requesting blockchain type, requesting blockchain capability information, or subscribing to blockchain capability information.
[0028] In one possible implementation, sending the first message includes: the first node sending the first message to the second node via a non-access stratum protocol, wherein the first node is a core network element and the second node is a terminal device; or, the first node sending the first message to the second node via a radio resource control protocol, wherein the first node is an access network device and the second node is a terminal device; or, the first node sending the first message to the second node via a next-generation application protocol, wherein the first node is a core network element and the second node is an access network device; or, the first node sending the first message to the second node via an Xn interface application flow protocol, wherein the first node and the second node are different access network devices.
[0029] In this implementation, the existing protocol is reused to send the first message, which requires minimal changes to the network, has high compatibility, and low implementation complexity.
[0030] In one possible implementation, sending the first message includes: the first node sending the first message through a blockchain control protocol, wherein the blockchain control protocol is a protocol between different core network elements, or, the blockchain control protocol is a protocol between a core network element and a terminal device, or, the blockchain control protocol is a protocol between a core network element and an access network device, or, the blockchain control protocol is a protocol between an access network device and a terminal device, or, the blockchain control protocol is a protocol between different access network devices.
[0031] In this implementation, the first node sends the first message through the blockchain control protocol, which enables blockchain management functions.
[0032] In one possible implementation, the blockchain control protocol is located above the second protocol layer, which includes some or all of the following protocol layers: a protocol layer for data packet processing, a protocol layer for transmission, a protocol layer for establishing connections, and a protocol layer for establishing channels.
[0033] In this implementation, the blockchain control protocol is located above the second protocol layer, so that blockchain nodes can rely on the second protocol layer to establish communication.
[0034] In one possible implementation, when the second node is a terminal device, sending the first message includes: when the first node is a core network element, sending the first message to the second node through a first blockchain control protocol; or, when the first node is an access network device, sending the first message to the second node through a second blockchain control protocol, wherein the second blockchain control protocol is different from the first blockchain control protocol.
[0035] In this implementation, when the first node is a core network element, it sends a first message to the second node through the first blockchain control protocol; when the first node is an access network device, it sends a first message to the second node through the second blockchain control protocol, thus realizing blockchain management functions.
[0036] In this implementation, the blockchain control protocol is divided into a first blockchain control protocol and a second blockchain control protocol. On the one hand, it can better adapt to the characteristics of telecommunications networks. On the other hand, after receiving the blockchain control protocol message, the access network equipment (such as base stations) can determine whether to unpack it locally based on the protocol type, making the processing logic simpler.
[0037] In one possible implementation, the method further includes: receiving a third message, the third message being used to request the establishment of a blockchain, the third message carrying blockchain service requirement parameters; or, the third message being used to deregister the blockchain capability of a second node; or, the third message being used to register the blockchain capability of a second node.
[0038] In this implementation, requests to establish a blockchain, register a blockchain capability, or deregister a blockchain capability can be made within a telecommunications network.
[0039] Secondly, embodiments of this application provide another communication method, which is applied to a second node in a telecommunications network. The method includes: receiving a first message, the first message being used for at least one of the following: management of blockchain capabilities, deployment of blockchain capabilities, management of blockchain clients, deployment of blockchain clients, establishment of blockchain, deletion of blockchain, update of blockchain, configuration of blockchain, acquisition of blockchain parameters, deployment of subdomain blockchain, or configuration of subdomain blockchain; and sending a second message, the second message being used to respond to the first message.
[0040] Existing blockchain protocols and protocol stacks cannot be simply and directly applied to telecommunications networks. In this embodiment, the second node receives the first message; at least one of the following can be implemented in the telecommunications network: management of blockchain capabilities, deployment of blockchain capabilities, establishment of a blockchain, deletion of a blockchain, updating of a blockchain, configuration of a blockchain, acquisition of blockchain parameters, deployment of a subdomain blockchain, or configuration of a subdomain blockchain.
[0041] In one possible implementation, the first message for managing blockchain capabilities includes: the first message for deleting, activating, updating, locking, or closing the blockchain capability.
[0042] This implementation allows for at least one of the following actions to be performed in a telecommunications network: deletion, activation, update, locking, or closure of the blockchain capabilities of a node.
[0043] In one possible implementation, the first message for deploying blockchain capabilities includes: the first message for deploying blockchain capabilities of a second node in the telecommunications network, the first message carrying an installation package for deploying blockchain capabilities of the second node and first configuration information, the first configuration information being used to indicate the blockchain capabilities of the second node; or, the first message for deploying blockchain capabilities of one or more nodes within a first subdomain, the first subdomain including one or more nodes managed by the second node, the second node being managed by the first node, the first message carrying an installation package for deploying blockchain capabilities of the one or more nodes, second configuration information, and information indicating the number of nodes supporting blockchain capabilities within the first subdomain, the second configuration information being used to indicate the blockchain capabilities of the one or more nodes.
[0044] In this implementation, if the first message is used to deploy the blockchain capabilities of a second node in the telecommunications network or to deploy the blockchain capabilities of one or more nodes in the first subdomain, blockchain capabilities can be deployed for nodes in the telecommunications network.
[0045] In one possible implementation, the first message for activating blockchain capabilities includes: the first message for activating the blockchain capabilities of a second node in the telecommunications network, the first message carrying information indicating the blockchain capabilities of the second node; or, the first message for activating the blockchain capabilities of one or more nodes within a first subdomain, the first subdomain including one or more nodes managed by the second node, the second node being managed by the first node, the first message carrying information indicating the blockchain capabilities of the one or more nodes, and information indicating the number of nodes supporting blockchain capabilities within the first subdomain.
[0046] In this implementation, the blockchain capabilities of nodes can be activated within the telecommunications network.
[0047] In one possible implementation, the first message is used to establish a blockchain in the telecommunications network that includes a second node, and the first message carries configuration information of the blockchain that includes the second node; or, the first message is used to establish one or more blockchains in a first subdomain, the first subdomain including one or more nodes managed by the second node, the second node being managed by the first node, and the first message carrying configuration information of the one or more blockchains.
[0048] This implementation method enables the establishment of a blockchain within a telecommunications network.
[0049] In one possible implementation, the first message is used for updating a blockchain in the telecommunications network that includes a second node, and the first message carries configuration information for updating the blockchain that includes the second node; or, the first message is used for updating one or more blockchains in a first subdomain, the first subdomain including one or more nodes managed by the second node, the second node being managed by the first node, and the first message carrying configuration information for updating the one or more blockchains.
[0050] In this implementation, the blockchain in the telecommunications network can be updated.
[0051] In one possible implementation, the first message for configuring the blockchain includes: the first message for configuring the blockchain connection, wherein the configuration of the blockchain connection includes at least one of configuring the blockchain connection method, configuring the blockchain network topology, and configuring the blockchain node list.
[0052] In this implementation, the configuration of the blockchain connection can be implemented in the telecommunications network.
[0053] In one possible implementation, the first message for configuring the blockchain includes: the first message for configuring a blockchain node, wherein the configuration of the blockchain node includes at least one of configuring blockchain node attributes, configuring blockchain node roles, or configuring blockchain node operating status.
[0054] In this implementation, blockchain nodes can be configured within a telecommunications network.
[0055] In one possible implementation, the first message used to obtain blockchain parameters includes: the first message being used to request blockchain configuration information, subscribe to blockchain configuration information, request blockchain identifier, request blockchain type, request blockchain capability information, or subscribe to blockchain capability information, at least one of the following:
[0056] In this implementation, at least one of the following can be implemented in a telecommunications network: requesting blockchain configuration information, subscribing to blockchain configuration information, requesting blockchain identifier, requesting blockchain type, requesting blockchain capability information, or subscribing to blockchain capability information.
[0057] In one possible implementation, receiving the first message includes: the second node receiving the first message from the first node via a non-access stratum protocol, where the first node is an access network device and the second node is a terminal device; or, the first node receiving the first message from the first node via a radio resource control protocol, where the first node is an access network device and the second node is a terminal device; or, the first node receiving the first message from the first node via a next-generation application protocol, where the first node is a core network element and the second node is an access network device; or, the first node receiving the first message from the first node via an Xn interface application flow protocol, where the first node and the second node are different access network devices.
[0058] In this implementation, the existing protocol is reused to receive the first message, which requires minimal changes to the network, has high compatibility, and low implementation complexity.
[0059] In one possible implementation, receiving the first message includes: the second node receiving the first message through a blockchain control protocol, wherein the blockchain control protocol is a protocol between different core network elements, or a protocol between a core network element and a terminal device, or a protocol between a core network element and an access network device, or a protocol between an access network device and a terminal device, or a protocol between different access network devices.
[0060] In this implementation, the second node receives the first message through the blockchain control protocol, enabling blockchain management functions.
[0061] In one possible implementation, the blockchain control protocol is located above the second protocol layer, which includes some or all of the following protocol layers: a protocol layer for data packet processing, a protocol layer for transmission, a protocol layer for establishing connections, and a protocol layer for establishing channels.
[0062] In one possible implementation, receiving the first message includes: the second node receiving the first message from the first node via a first blockchain control protocol, wherein the second node is a terminal device and the first node is a core network element; or, the second node receiving the first message from the first node via a second blockchain control protocol, wherein the second node is a terminal device and the first node is an access network device, and the second blockchain control protocol is different from the first blockchain control protocol.
[0063] In this implementation, when the second node is a terminal device and the first node is a core network element, the second node receives the first message from the first node through the first blockchain control protocol; when the second node is a terminal device and the first node is an access network device, the second node receives the first message from the first node through the second blockchain control protocol. This makes it easier for the terminal device to determine whether the message comes from the core network or the access network, and the changes to the existing technology are relatively small compared to using a single-layer protocol.
[0064] In one possible implementation, the method further includes: sending a third message, the third message being used to request the establishment of a blockchain, the third message carrying blockchain service requirement parameters; or, the third message being used to deregister the blockchain capability of the second node; or, the third message being used to register the blockchain capability of the second node.
[0065] In this implementation, requests to establish a blockchain, register a blockchain capability, or deregister a blockchain capability can be made within a telecommunications network.
[0066] Thirdly, embodiments of this application provide another communication method applied to a second node in a telecommunications network. The method includes: sending a third message, wherein the third message is used to request the establishment of a blockchain, the third message carrying blockchain service requirement parameters, or the third message is used to deregister the blockchain capability of the second node, or the third message is used to register the blockchain capability of the second node; and receiving a fourth message, wherein the fourth message is used to respond to the third message.
[0067] In this embodiment of the application, it is possible to request the establishment of a blockchain, register a blockchain capability, or cancel a blockchain capability in a telecommunications network.
[0068] In one possible implementation, sending the third message includes: the second node sending the third message to the first node via a non-access stratum protocol, wherein the second node is a terminal device and the first node is a core network element; or, the second node sending the third message to the first node via a radio resource control protocol, wherein the second node is a terminal device and the first node is an access network device; or, the second node sending the third message to the first node via a next-generation application protocol, wherein the second node is an access network device and the first node is an access network device; or, the second node sending the third message to the first node via an Xn interface application flow protocol, wherein the second node and the first node are different access network devices.
[0069] In this implementation, existing protocols are reused to send third messages, requiring minimal network modifications, offering high compatibility, and low implementation complexity.
[0070] In one possible implementation, sending the third message includes: the second node sending the third message through a blockchain control protocol, wherein the blockchain control protocol is a protocol between different core network elements, or a protocol between a core network element and a terminal device, or a protocol between a core network element and an access network device, or a protocol between an access network device and a terminal device, or a protocol between different access network devices.
[0071] In this implementation, the first node sends a third message through the blockchain control protocol, which enables blockchain management functions.
[0072] In one possible implementation, the blockchain control protocol is located above the second protocol layer, which includes some or all of the following protocol layers: a protocol layer for data packet processing, a protocol layer for transmission, a protocol layer for establishing connections, and a protocol layer for establishing channels.
[0073] In this implementation, the blockchain control protocol is located above the second protocol layer, so that blockchain nodes can rely on the second protocol layer to establish communication.
[0074] In one possible implementation, sending the third message includes: when the first node is a core network element, the second node sends the third message to the first node through a first blockchain control protocol; or, when the first node is an access network device, the second node sends the third message to the first node through a second blockchain control protocol, wherein the second blockchain control protocol is different from the first blockchain control protocol.
[0075] In this implementation, the blockchain control protocol is divided into a first blockchain control protocol and a second blockchain control protocol. On the one hand, it can better adapt to the characteristics of telecommunications networks. On the other hand, after receiving the blockchain control protocol message, the access network equipment (such as base stations) can determine whether to unpack it locally based on the protocol type, making the processing logic simpler.
[0076] Fourthly, embodiments of this application provide another communication method, which is applied to a first node in a telecommunications network. The method includes: receiving a third message, the third message being used to request the establishment of a blockchain, the third message carrying blockchain service requirement parameters, or the third message being used to deregister the blockchain capability of a second node, or the third message being used to register the blockchain capability of a second node; and sending a fourth message, the fourth message being used to respond to the third message.
[0077] In this embodiment of the application, it is possible to request the establishment of a blockchain, register a blockchain capability, or cancel a blockchain capability in a telecommunications network.
[0078] In one possible implementation, receiving the third message includes: the first node receiving the third message from the second node via a non-access stratum protocol, wherein the second node is a terminal device and the first node is a core network element; or, the second node receiving the third message from the second node via a radio resource control protocol, wherein the second node is a terminal device and the first node is an access network device; or, the second node receiving the third message from the second node via a next-generation application protocol, wherein the second node is an access network device and the first node is an access network device; or, the second node receiving the third message from the second node via an Xn interface application flow protocol, wherein the second node and the first node are different access network devices.
[0079] In this implementation, existing protocols are reused to receive third-party messages, requiring minimal network modifications, exhibiting high compatibility, and low implementation complexity.
[0080] In one possible implementation, receiving the third message includes: the first node receiving the third message through a blockchain control protocol, wherein the blockchain control protocol is a protocol between different core network elements, or a protocol between a core network element and a terminal device, or a protocol between a core network element and an access network device, or a protocol between an access network device and a terminal device, or a protocol between different access network devices.
[0081] In this implementation, the first node receives third messages through the blockchain control protocol in order to enable blockchain management functions.
[0082] In one possible implementation, the blockchain control protocol is located above the second protocol layer, which includes some or all of the following protocol layers: a protocol layer for data packet processing, a protocol layer for transmission, a protocol layer for establishing connections, and a protocol layer for establishing channels.
[0083] In this implementation, the blockchain control protocol is located above the second protocol layer, so that blockchain nodes can rely on the second protocol layer to establish communication.
[0084] In one possible implementation, receiving the third message includes: when the first node is a core network element, the first node receives the third message through a first blockchain control protocol; or, when the first node is an access network device, the first node receives the third message through a second blockchain control protocol, wherein the second blockchain control protocol is different from the first blockchain control protocol.
[0085] In this implementation, the blockchain control protocol is divided into a first blockchain control protocol and a second blockchain control protocol. On the one hand, it can better adapt to the characteristics of telecommunications networks. On the other hand, after receiving the blockchain control protocol message, the access network equipment (such as base stations) can determine whether to unpack it locally based on the protocol type, making the processing logic simpler.
[0086] In one possible implementation, the first node is an access network device. After receiving the third message, the method further includes: when the first node has blockchain capabilities and has deployed a blockchain control function, parsing the third message, wherein the blockchain control function is a function for managing and / or configuring the blockchain; or, when the first node has blockchain capabilities but has not deployed a blockchain control function, forwarding the third message to a third node to which the first node belongs, wherein the third node has deployed the blockchain control function; or, when the first node does not have blockchain capabilities, forwarding the third message to a node that has deployed the blockchain control function. For example, the first node is an access network device.
[0087] In this implementation, the first node either parses the third message itself or forwards the third message to a node with blockchain control functionality, so that the third message can be processed by the node with blockchain control functionality.
[0088] Fifthly, embodiments of this application provide a communication device that has the function of implementing the behavior described in the first aspect of the method embodiments. The communication device may be a network device, a component of a network device (e.g., a processor, chip, or chip system), or a logic module or software capable of implementing all or part of the functions of the network device. The function of the communication device can be implemented by hardware or by hardware executing corresponding software, the hardware or software including one or more modules or units corresponding to the above functions. In one possible implementation, the communication device includes a transceiver module and a processing module, wherein: the processing module is used to generate a first message; the transceiver module is used to send the first message, the first message being used for at least one of the following: blockchain capability management, blockchain capability deployment, blockchain client management, blockchain client deployment, blockchain establishment, blockchain deletion, blockchain update, blockchain configuration, blockchain parameter acquisition, subdomain blockchain deployment, or subdomain blockchain configuration; and to receive a second message, the second message being used to respond to the first message.
[0089] In one possible implementation, the transceiver module is specifically configured to send the first message to the second node via a non-access stratum protocol, wherein the first node is a core network element and the second node is a terminal device; or, send the first message to the second node via a radio resource control protocol, wherein the first node is an access network device and the second node is a terminal device; or, send the first message to the second node via a next-generation application protocol, wherein the first node is a core network element and the second node is an access network device; or, send the first message to the second node via an Xn interface application flow protocol, wherein the first node and the second node are different access network devices.
[0090] In one possible implementation, the transceiver module is specifically used to send the first message via a blockchain control protocol, wherein the blockchain control protocol is a protocol between different core network elements, or a protocol between a core network element and a terminal device, or a protocol between a core network element and an access network device, or a protocol between an access network device and a terminal device, or a protocol between different access network devices.
[0091] In one possible implementation, when the second node is a terminal device, the transceiver module is specifically used to send the first message to the second node through a first blockchain control protocol when the first node is a core network element; or, when the second node is a terminal device, the transceiver module is specifically used to send the first message to the second node through a second blockchain control protocol when the first node is an access network device, wherein the second blockchain control protocol is different from the first blockchain control protocol.
[0092] In one possible implementation, the transceiver module is further configured to receive a third message, which is used to request the establishment of a blockchain and carries blockchain service requirement parameters; or, the third message is used to deregister the blockchain capability of a second node; or, the third message is used to register the blockchain capability of a second node.
[0093] For possible implementations of the communication device in the fifth aspect, please refer to the various possible implementations in the first aspect.
[0094] For the technical effects of the various possible implementations of the fifth aspect, please refer to the introduction of the technical effects of the various possible implementations of the first aspect.
[0095] Sixthly, embodiments of this application provide another communication device that has the function of implementing the behavior described in the second aspect of the method embodiments. This communication device may be a network device, a component of a network device (e.g., a processor, chip, or chip system), or a logic module or software capable of implementing all or part of the functions of the network device. Alternatively, the communication device may be a terminal device, a component of a terminal device (e.g., a processor, chip, or chip system), or a logic module or software capable of implementing all or part of the functions of the terminal device. In this application, the network device may include access network equipment (e.g., a base station), core network equipment, etc. The function of the communication device can be implemented by hardware or by hardware executing corresponding software, and the hardware or software includes one or more modules or units corresponding to the above functions. In one possible implementation, the communication device includes a transceiver module and a processing module, wherein: the transceiver module is configured to receive a first message, the first message being used for at least one of the following: blockchain capability management, blockchain capability deployment, blockchain client management, blockchain client deployment, blockchain establishment, blockchain deletion, blockchain update, blockchain configuration, blockchain parameter acquisition, subdomain blockchain deployment, or subdomain blockchain configuration; the processing module is configured to generate a second message; and the transceiver module is further configured to send the second message, the second message being used in response to the first message.
[0096] In one possible implementation, the transceiver module is specifically configured to receive the first message from a first node via a non-access stratum protocol, wherein the first node is a core network element and the second node is a terminal device; or, receive the first message from the first node via a radio resource control protocol, wherein the first node is an access network device and the second node is a terminal device; or, receive the first message from the first node via a next-generation application protocol, wherein the first node is a core network element and the second node is an access network device; or, receive the first message from the first node via an Xn interface application flow protocol, wherein the first node and the second node are different access network devices.
[0097] In one possible implementation, the transceiver module is specifically configured to receive the first message via a blockchain control protocol, wherein the blockchain control protocol is a protocol between different core network elements, or a protocol between a core network element and a terminal device, or a protocol between a core network element and an access network device, or a protocol between an access network device and a terminal device, or a protocol between different access network devices.
[0098] In one possible implementation, the transceiver module is specifically used to receive the first message from the first node via a first blockchain control protocol, wherein the second node is a terminal device and the first node is a core network element; or, to receive the first message from the first node via a second blockchain control protocol, wherein the second node is a terminal device and the first node is an access network device, and the second blockchain control protocol is different from the first blockchain control protocol.
[0099] In one possible implementation, the transceiver module is further configured to send a third message, which is used to request the establishment of a blockchain and carries blockchain service requirement parameters; or, the third message is used to deregister the blockchain capability of the second node; or, the third message is used to register the blockchain capability of the second node.
[0100] For possible implementations of the communication device in the sixth aspect, please refer to the various possible implementations in the second aspect.
[0101] For the technical effects of the various possible implementations of the sixth aspect, please refer to the introduction of the technical effects of the various possible implementations of the second aspect.
[0102] In a seventh aspect, embodiments of this application provide another communication device that has the function of implementing the behavior described in the third aspect of the method embodiments. This communication device may be a network device, a component of a network device (e.g., a processor, chip, or chip system), or a logic module or software capable of implementing all or part of the functions of the network device. Alternatively, the communication device may be a terminal device, a component of a terminal device (e.g., a processor, chip, or chip system), or a logic module or software capable of implementing all or part of the functions of the terminal device. In this application, the network device may include access network equipment (e.g., a base station), core network equipment, etc. The function of the communication device can be implemented by hardware or by hardware executing corresponding software, and the hardware or software includes one or more modules or units corresponding to the above functions. In one possible implementation, the communication device includes a transceiver module and a processing module, wherein: the processing module is used to generate a third message; the transceiver module is used to send the third message, which is used to request the establishment of a blockchain, the third message carrying blockchain service requirement parameters, or the third message is used to deregister the blockchain capability of the second node, or the third message is used to register the blockchain capability of the second node; and to receive a fourth message, which is used to respond to the third message.
[0103] In one possible implementation, the transceiver module is specifically configured to send the third message to the first node via a non-access stratum protocol, wherein the second node is a terminal device and the first node is a core network element; or, send the third message to the first node via a radio resource control protocol, wherein the second node is a terminal device and the first node is an access network device; or, send the third message to the first node via a next-generation application protocol, wherein the second node is an access network device and the first node is an access network device; or, send the third message to the first node via an Xn interface application flow protocol, wherein the second node and the first node are different access network devices.
[0104] In one possible implementation, the transceiver module is specifically used to send the third message via a blockchain control protocol, wherein the blockchain control protocol is a protocol between different core network elements, or a protocol between a core network element and a terminal device, or a protocol between a core network element and an access network device, or a protocol between an access network device and a terminal device, or a protocol between different access network devices.
[0105] In one possible implementation, when the first node is a core network element, the transceiver module is specifically used to send the third message to the first node through a first blockchain control protocol; or, when the first node is an access network device, the transceiver module is specifically used to send the third message to the first node through a second blockchain control protocol, wherein the second blockchain control protocol is different from the first blockchain control protocol.
[0106] For possible implementations of the communication device in the seventh aspect, please refer to the various possible implementations in the third aspect.
[0107] For the technical effects of the various possible implementations of the seventh aspect, please refer to the introduction of the technical effects of the various possible implementations of the third aspect.
[0108] Eighthly, embodiments of this application provide another communication device that has the function of implementing the behavior described in the fourth aspect of the method embodiments. This communication device may be a network device, a component of a network device (e.g., a processor, chip, or chip system), or a logic module or software capable of implementing all or part of the functions of the network device. Alternatively, the communication device may be a terminal device, a component of a terminal device (e.g., a processor, chip, or chip system), or a logic module or software capable of implementing all or part of the functions of the terminal device. In this application, the network device may include access network equipment (e.g., a base station), core network equipment, etc. The function of the communication device can be implemented by hardware or by hardware executing corresponding software, and the hardware or software includes one or more modules or units corresponding to the above functions. In one possible implementation, the communication device includes a transceiver module and a processing module, wherein: the transceiver module is used to receive a third message, the third message being used to request the establishment of a blockchain, the third message carrying blockchain service requirement parameters, or the third message being used to deregister the blockchain capability of a second node, or the third message being used to register the blockchain capability of a second node; the processing module is used to generate a fourth message; the transceiver module is used to send the fourth message, the fourth message being used to respond to the third message.
[0109] In one possible implementation, the transceiver module is specifically used to receive the third message through a blockchain control protocol, wherein the blockchain control protocol is a protocol between different core network elements, or a protocol between a core network element and a terminal device, or a protocol between a core network element and an access network device, or a protocol between an access network device and a terminal device, or a protocol between different access network devices.
[0110] In one possible implementation, when the first node is a core network element, the transceiver module is specifically used to receive the third message through a first blockchain control protocol; or, when the first node is an access network device, the transceiver module is specifically used to receive the third message through a second blockchain control protocol, which is different from the first blockchain control protocol.
[0111] In one possible implementation, the processing module is further configured to parse the third message when the first node has blockchain capabilities and has deployed blockchain control functions, wherein the blockchain control functions are functions for managing and / or configuring the blockchain; or, when the first node has blockchain capabilities but has not deployed blockchain control functions, the transceiver module is further configured to forward the third message to a third node to which the first node belongs, wherein the third node has deployed the blockchain control functions; or, when the first node does not have blockchain capabilities, the transceiver module is further configured to forward the third message to a node that has deployed the blockchain control functions.
[0112] For possible implementations of the communication device in the eighth aspect, please refer to the various possible implementations in the fourth aspect.
[0113] For the technical effects of the various possible implementations of the eighth aspect, please refer to the introduction of the technical effects of the various possible implementations of the fourth aspect.
[0114] Ninthly, embodiments of this application provide another communication device, the communication device including one or more processors for processing information (including data and / or signaling) to enable the methods of any one of the first to fourth aspects described above to be implemented.
[0115] Optionally, the communication device further includes a memory storing programs or instructions that, when executed by the processor, cause the communication device to perform the methods described in the first or second aspect above. For example, the communication device may be a chip, the processor may be a processing circuit within the chip, and the memory may be a random access memory or cache within the chip.
[0116] In this embodiment of the application, during the execution of the above method, the process of sending information (or signals) can be understood as a process of outputting information based on processor instructions. When outputting information, the processor outputs the information to the transceiver for transmission. After being output by the processor, the information may undergo further processing before reaching the transceiver. Similarly, when the processor receives input information, the transceiver receives the information and inputs it into the processor. Furthermore, after receiving the information, the transceiver may undergo further processing before inputting it into the processor.
[0117] Unless otherwise specified, or unless their actual function or internal logic in the relevant description is contradicted, the sending and / or receiving operations involved by the processor can generally be understood as processor instruction output.
[0118] In implementation, the processor described above can be a processor specifically designed to execute these methods, or it can be a processor that executes computer instructions stored in memory to execute these methods, such as a general-purpose processor. For example, the processor can also be used to execute a program stored in memory, which, when executed, causes the communication device to perform the methods as shown in the first aspect or any possible implementation thereof.
[0119] In one possible implementation, the memory is located outside the aforementioned communication device. In another possible implementation, the memory is located inside the aforementioned communication device.
[0120] In one possible implementation, the processor and memory may be integrated into a single device; that is, the processor and memory may be integrated together.
[0121] In one possible implementation, the communication device further includes a transceiver for receiving or transmitting signals, etc.
[0122] In a tenth aspect, this application provides another communication device, which includes a processing circuit and an interface circuit, the interface circuit being used to acquire data or output data; the processing circuit being used to perform the method as shown in any one of the first to fourth aspects above.
[0123] Eleventhly, this application provides a computer-readable storage medium storing a computer program, the computer program including program instructions that, when executed, cause a computer to perform the method as described in any one of the first to fourth aspects above.
[0124] In a twelfth aspect, this application provides a computer program product comprising a computer program including program instructions that, when executed, cause a computer to perform the method as described in any one of the first to fourth aspects above.
[0125] In a thirteenth aspect, this application provides a chip including a communication interface and a processor; the communication interface is used for signal transmission and reception of the chip; the processor is used to execute computer program instructions to cause a communication device including the chip to perform the method shown in any one of the first to fourth aspects above.
[0126] In a fourteenth aspect, embodiments of this application provide a communication system including the communication device described in the fifth aspect or any possible implementation thereof, and the communication device described in the sixth aspect or any possible implementation thereof.
[0127] In a fifteenth aspect, embodiments of this application provide another communication system, including the communication device described in the seventh aspect or any possible implementation thereof, and the communication device described in the eighth aspect or any possible implementation thereof. Attached Figure Description
[0128] To more clearly illustrate the technical solutions in the embodiments of this application or the background art, the accompanying drawings used in the embodiments of this application will be described below.
[0129] Figure 1 is a schematic diagram of a network architecture provided in an embodiment of this application;
[0130] Figure 2 is an example of a ledger anchoring function LAF hierarchy and subdomains provided in an embodiment of this application;
[0131] Figure 3 is an example of a protocol stack based on functional partitioning provided in an embodiment of this application;
[0132] Figure 4 shows an example of a protocol stack partitioning based on node type provided in an embodiment of this application;
[0133] Figure 5 shows an example of a protocol stack partitioned based on message type according to an embodiment of this application;
[0134] Figure 6 is an example of a blockchain control protocol stack provided in an embodiment of this application;
[0135] Figure 7 shows an example of another blockchain control protocol stack provided in the embodiments of this application;
[0136] Figure 8 shows an example of another blockchain control protocol stack provided in the embodiments of this application;
[0137] Figure 9 shows an example of another blockchain control protocol stack provided in the embodiments of this application;
[0138] Figure 10 is an example of a state transition diagram of a blockchain capability provided in an embodiment of this application;
[0139] Figure 11 is a flowchart of a communication method according to an embodiment of this application;
[0140] Figure 12 is an interactive flowchart of another communication method provided in an embodiment of this application;
[0141] Figure 13 is an interactive flowchart of another communication method provided in an embodiment of this application;
[0142] Figure 14 is an interactive flowchart of another communication method provided in an embodiment of this application;
[0143] Figure 15 is an interactive flowchart of another communication method provided in an embodiment of this application;
[0144] Figure 16 is an interactive flowchart of another communication method provided in an embodiment of this application;
[0145] Figure 17 is an interactive flowchart of another communication method provided in an embodiment of this application;
[0146] Figure 18 is an interactive flowchart of another communication method provided in an embodiment of this application;
[0147] Figure 19 is an interactive flowchart of another communication method provided in an embodiment of this application;
[0148] Figure 20 is an interactive flowchart of another communication method provided in an embodiment of this application;
[0149] Figure 21 is an interactive flowchart of another communication method provided in an embodiment of this application;
[0150] Figure 22 is an interactive flowchart of another communication method provided in an embodiment of this application;
[0151] Figure 23 is an interactive flowchart of another communication method provided in an embodiment of this application;
[0152] Figure 24 is an interactive flowchart of another communication method provided in an embodiment of this application;
[0153] Figure 25 is an interactive flowchart of another communication method provided in an embodiment of this application;
[0154] Figure 26 is an interactive flowchart of another communication method provided in an embodiment of this application;
[0155] Figure 27 is an interactive flowchart of another communication method provided in an embodiment of this application;
[0156] Figure 28 is an interactive flowchart of another communication method provided in an embodiment of this application;
[0157] Figure 29 is an interactive flowchart of another communication method provided in an embodiment of this application;
[0158] Figure 30 is an interactive flowchart of another communication method provided in an embodiment of this application;
[0159] Figure 31 is an interactive flowchart of another communication method provided in an embodiment of this application;
[0160] Figure 32 is an interactive flowchart of another communication method provided in an embodiment of this application;
[0161] Figure 33 is an interactive flowchart of another communication method provided in an embodiment of this application;
[0162] Figure 34 is an interactive flowchart of another communication method provided in an embodiment of this application;
[0163] Figure 35 is an interactive flowchart of another communication method provided in an embodiment of this application;
[0164] Figure 36 is a structural schematic diagram of a communication device 3600 provided in an embodiment of this application;
[0165] Figure 37 is a schematic diagram of another device 370 provided in an embodiment of this application. Detailed Implementation
[0166] The terms "first" and "second," etc., used in the specification, claims, and drawings of this application are only used to distinguish different objects and not to describe a specific order. It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application. The order of the process numbers does not imply the order of execution; the execution order of each process should be determined by its function and inherent logic. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.
[0167] The term "embodiment" as used herein means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.
[0168] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” and “the” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to and includes any or all possible combinations of one or more of the listed items. For example, “A and / or B” can mean: the presence of only A, the presence of only B, and the presence of both A and B, where A and B can be singular or plural. The term “multiple” as used in this application refers to two or more. In the textual description of this application, the character “ / ” generally indicates that the preceding and following objects are in an “or” relationship.
[0169] It is understood that in the various embodiments of this application, "B corresponding to A" means that there is a correspondence between A and B, and B can be determined based on A. However, it should also be understood that determining (or generating) B based on (or on) A does not mean that B is determined (or generated) solely based on (or on) A; B can also be determined (or generated) based on (or on) A and / or other information.
[0170] It should be understood that in this application, the indication includes direct indication (also known as explicit indication) and implicit indication. Direct indication information A refers to information A being included; implicit indication information A refers to information A being indicated through the correspondence between information A and information B, and through direct indication information B. The correspondence between information A and information B can be predefined, pre-stored, pre-burned, or pre-configured.
[0171] It should be understood that in this application, information C is used to determine information D, including both situations where information D is determined solely based on information C and situations where it is determined based on information C and other information. Furthermore, information C can also be used to determine information D indirectly, for example, where information D is determined based on information E, and information E is determined based on information C.
[0172] Furthermore, in the embodiments of this application, "network element A sends information A to network element B" can be understood as network element B being the destination of information A or an intermediate network element in the transmission path between the destination and network element B, which may include sending information directly or indirectly to network element B. "Network element B receives information A from network element A" can be understood as network element A being the source of information A or an intermediate network element in the transmission path between the source and network element A, which may include receiving information directly or indirectly from network element A. Information may undergo necessary processing between the source and destination, such as format changes, but the destination can understand the valid information from the source. Similar expressions in this application can be understood in a similar way and will not be elaborated upon here. As described in the background section, existing blockchain protocols and protocol stacks cannot be simply and directly applied to telecommunications networks. Therefore, it is necessary to study how to apply blockchain to telecommunications networks. The following section first introduces the communication system to which the technical solution provided in this application is applicable.
[0173] Figure 1 is a schematic diagram of a network architecture provided in an embodiment of this application. As shown in Figure 1, the network architecture includes: one or more ledger anchor function (LAF) network elements (only one shown, hereinafter referred to as LAF), one or more user equipment (UE) devices (only one shown) deployed with a blockchain enabler or blockchain client, one or more access network devices (only one shown) deployed with a blockchain enabler or blockchain client, one or more UPF devices (only one shown), and a data network (DN). Optionally, it also includes a blockchain enabler or blockchain client as an independent core network function, and / or one or more core network elements deployed with a blockchain enabler or blockchain client. The blockchain enabler as an independent core network function can provide blockchain proxy services for other network function (NF) network elements. The blockchain client as an independent core network function can provide transaction proposal services for other network function network elements. The number of various network elements and UEs in the network architecture shown in Figure 1 is not limited. The network architecture shown in Figure 1 can be an example of the network architecture of communication systems evolving from the fifth generation (5G) and beyond, such as the sixth generation (6G). Figure 1 only shows a portion of the network elements in the network architecture. In this paper, the blockchain enabling module can be replaced with blockchain capability. A core network element with a blockchain enabling module can be called a core network element that has (or supports) blockchain capability. A UE with a blockchain enabling module can be called a UE that has (or supports) blockchain capability. An access network device with a blockchain enabling module can be called an access network device that has (or supports) blockchain capability.
[0174] A Local Area Network (LAF) serves as the anchor point for the overall management and association of a blockchain (such as a 6G blockchain). It performs functions such as blockchain management, registration and management of blockchain capabilities (or blockchain enabling modules), blockchain creation, activation of blockchain capabilities (or blockchain enabling modules), and access control of the blockchain. LAFs are typically deployed in the core network as network functions, but may also have a hierarchical structure, such as deploying sub-LAFs in the access network, which are managed by the primary LAF. In this article, LAF can be a core network element or an access network device; below, LAF refers to a core network element or access network device with an deployed LAF.
[0175] The blockchain enabling module in the telecommunications network is configured and managed by the LAF (Local Application Framework). Alternatively, nodes (including UEs, access network equipment, and core network elements) with deployed blockchain enabling modules are configured and managed by the LAF. Or, nodes (including UEs, access network equipment, and core network elements) with (or supporting) blockchain capabilities are configured and managed by the LAF. In this application, different on-chain node types (i.e., node types on the blockchain) can be distinguished based on the node's capabilities. Nodes with deployed blockchain enabling modules can have one or more of the following functions: transaction proposal, transaction endorsement / execution, deployment and execution of smart contracts, consensus, transaction / block synchronization, ledger storage, etc. The blockchain enabling module exists in various nodes in the telecommunications network, including UEs, access network equipment (e.g., base stations), and core network elements. That is, nodes requiring blockchain capabilities can deploy the blockchain enabling module. It should be noted that the blockchain enabling module does not necessarily have to be a physical module (or hardware entity). Various nodes in the telecommunications network can install (or deploy) the blockchain enabling module through its image code installation package. For example, a core network element with a blockchain-enabled module can also serve as an independent network function, providing blockchain proxy capabilities to other core network elements.
[0176] A blockchain client, configured and managed by the LAF (Local Application Framework), executes the generation and transmission of blockchain transactions. In other words, nodes (including UEs, access network equipment, and core network elements) with deployed blockchain clients receive configuration and management from the LAF. Blockchain clients exist at various nodes in the telecommunications network, including UEs, access network equipment (e.g., base stations), and core network elements. It should be noted that a blockchain client does not necessarily have to be a physical module (or hardware entity). Various nodes in the telecommunications network can install (or deploy) the blockchain client using its image code installation package. For example, a core network element with a deployed blockchain client can also function as an independent network function, providing transaction proposal services to other core network elements.
[0177] In one possible implementation, some LAFs are deployed in the core network, and others in the access network. The LAFs deployed in the access network can be named sub-LAFs, and the LAFs deployed in the core network can manage and configure the sub-LAFs. An LAF can be a core network element in the core network, and a sub-LAF can be an access network device in the access network. When LAFs are deployed in the access network, they exhibit a hierarchical structure; the LAFs deployed in the core network are at a higher level and can manage and configure the lower-level sub-LAFs (such as those in the access network). Sub-LAFs can manage and configure the blockchain enabling modules and / or blockchain clients of the access network nodes they connect to, as well as the blockchain enabling modules and / or blockchain clients of terminal devices. In this case, the access network nodes and terminal devices governed (or managed) by the sub-LAF are called the "subdomain" to which the sub-LAF belongs, i.e., the subdomain associated with the sub-LAF. A subdomain can refer to all nodes (including terminal devices and access network devices) governed by the sub-LAF that have deployed blockchain enabling modules and / or blockchain clients. A single LAF can have one or more nodes (access network devices or terminal devices) deployed with blockchain enabling modules and / or blockchain clients, and can also have one or more subdomains. Furthermore, it can have one or more nodes deployed with blockchain enabling modules and / or blockchain clients, along with one or more subdomains. For example, after setting up subdomains, the LAF does not directly manage the nodes within those subdomains that have deployed blockchain enabling modules and / or blockchain clients, nor does it need to be aware of their specific information. It only needs to issue instructions to the sub-LAF on a per-subdomain basis, thus reducing the workload of the LAF. Figure 2 shows an example of LAF layering and subdomains provided in an embodiment of this application. The example shown in Figure 2 can be a part of Figure 1 (not shown). As shown in Figure 2, the core network (CN) has a LAF with one node deployed with a blockchain enabling module, one node deployed with a blockchain client, a sub-LAF 1 (i.e., sub LAF1 in Figure 2), and a sub-LAF 2 (i.e., sub LAF2 in Figure 2). Sub-LAF 1 governs subdomain 1, which includes multiple nodes (only three are shown, deployed with blockchain enabling module #1, blockchain enabling module #2, and blockchain client #1, respectively). Sub-LAF 2 governs subdomain 2, which includes multiple nodes (only three are shown, deployed with blockchain enabling module #3, blockchain enabling module #4, and blockchain client #2, respectively). Nodes in a subdomain can be access network devices or terminal devices. For example, a subdomain may include multiple access network devices and multiple terminal devices governed by a sub-LAF, and these terminal devices access the core network through the access network devices within that subdomain.For example, a subdomain may include multiple integrated access & backhaul (IAB) nodes and multiple terminal devices managed by a sub-LAF. These terminal devices access the core network through the IAB nodes within the subdomain. Possible scenarios for a subdomain include: a supercell where one access network device (e.g., a base station) deploys an LAF to manage multiple access network devices; or, in another possible implementation, the access network may have a hierarchical architecture, with multiple layers of LAFs, where higher-level LAFs can manage and configure lower-level LAFs.
[0178] In the embodiments of this application, terminal equipment may also be referred to as user equipment (UE), access terminal, subscriber unit, user station, mobile station, mobile station (MS), remote station, remote terminal, mobile device, user terminal, terminal, wireless communication equipment, user agent, or user device.
[0179] A terminal device can be a device that provides wireless communication capabilities, such as a handheld device or an in-vehicle device with wireless connectivity. Currently, examples of terminal devices include: mobile phones, satellite mobile terminals, cellular phones, smartphones, tablets, laptops, PDAs, mobile internet devices (MIDs), wearable devices (such as smartwatches, smart bracelets, pedometers, smart glasses, etc.), in-vehicle equipment (such as cars, bicycles, electric vehicles, airplanes, ships, trains, high-speed trains, etc.), satellite terminals, virtual reality (VR) devices, augmented reality (AR) devices, smart point-of-sale (POS) machines, customer-premises equipment (CPE), wireless terminals in industrial control, wireless terminals in self-driving cars, wireless terminals in remote medical surgery, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, and wireless terminals in smart homes. The embodiments of this application do not limit the scope of the application to wireless terminals in the home (e.g., refrigerators, televisions, air conditioners, electricity meters, etc.), intelligent robots, robotic arms, cellular phones, cordless phones, session initiation protocol (SIP) phones, wireless local loop (WLL) stations, personal digital assistants (PDAs), handheld devices with wireless communication capabilities, computing devices or other processing devices connected to a wireless modem, flying devices (e.g., intelligent robots, hot air balloons, drones, airplanes), terminal devices in 5G networks, or terminal devices in future evolved public land mobile networks (PLMNs). As an example and not a limitation, in the embodiments of this application, the terminal device can also be a mobile termination (MT) in an IAB node. When an IAB node faces its parent node, it can be considered a terminal device; in this case, the IAB node acts as an MT.
[0180] In this embodiment, the device for implementing the functions of the terminal device can be the terminal device itself, or it can be any device capable of supporting the terminal device in implementing those functions, such as a chip system. This device can be installed in or used in conjunction with the terminal device. In this embodiment, the chip system can be composed of chips or may include chips and other discrete components. This embodiment only uses the terminal device as an example to illustrate the device for implementing the functions of the terminal device, and does not constitute a limitation on the solution of this embodiment.
[0181] The access network device in this application embodiment can be a device used to communicate with terminal devices. This access network device can also be called a network device or a wireless access network device. In this application embodiment, the access network device can refer to a radio access network (RAN) node (or device) that connects the terminal device to the wireless network.
[0182] In one possible scenario, access network equipment can be a base station, an evolved NodeB (eNodeB), a transmitting and receiving point (TRP), a transmitting point (TP), a next-generation NodeB (gNB), a next-generation base station in a 6th-generation (6G) mobile communication system, a base station in a future mobile communication system, an access point (AP) in a satellite or WiFi system, an integrated access and backhaul (IAB) node, or an access network device in a mobile switching center non-terrestrial network (NTN) communication system, i.e., it can be deployed on high-altitude platforms or satellites. Access network equipment can be a macro base station, a micro base station or an indoor station, a relay node or a donor node, or a radio controller in a cloud radio access network (CRAN) scenario. Access network equipment can also function as a base station in device-to-device (D2D) communication, vehicle-to-everything (V2X) communication, drone communication, and machine-to-machine (M2M) communication. Optionally, access network equipment can also be servers, wearable devices, vehicles, or in-vehicle equipment. For example, in vehicle-to-everything (V2X) technology, the access network equipment can be a roadside unit (RSU). An IAB node integrates a mobile termination (MT) and a distributed unit (DU). When an IAB node faces its parent node, it can be considered a termination, in which case the IAB node acts as an MT. When an IAB node faces its child node (which may be a termination or the MT of another IAB node), it can be considered an access network device. An IAB node can establish a backhaul connection with at least one parent node through its MT portion. The DU portion of an IAB node can provide access services to a termination or the MT portion of another IAB node.
[0183] In another possible scenario, multiple access network devices collaborate to assist terminals in achieving wireless access, with each device implementing a portion of the base station's functions. For example, access network devices can be central units (CUs), distributed units (DUs), CU-control plane (CPs), CU-user plane (UPs), or radio units (RUs). CUs and DUs can be separate entities or included in the same network element, such as a baseband unit (BBU). RUs can be included in radio equipment or radio units, such as remote radio units (RRUs), active antenna units (AAUs), or remote radio heads (RRHs). It is understood that access network devices can be CU nodes, DU nodes, or devices comprising both CU and DU nodes. Furthermore, CUs can be classified as access network devices within the RAN (RAN) or the CN (CN), without limitation.
[0184] In different systems, CU (or CU-CP and CU-UP), DU, or RU may have different names, but those skilled in the art will understand their meaning. For example, in an ORAN system, CU can also be called O-CU (Open CU), DU can also be called O-DU, CU-CP can also be called O-CU-CP, CU-UP can also be called O-CU-UP, and RU can also be called O-RU. For ease of description, this application uses CU, CU-CP, CU-UP, DU, and RU as examples. Any of the units among CU (or CU-CP, CU-UP), DU, and RU in this application can be implemented through software modules, hardware modules, or a combination of software modules and hardware modules. The embodiments of this application do not limit the specific technology or specific device form used in the access network equipment.
[0185] In order to introduce blockchain technology into telecommunications networks, this application defines new blockchain functions, namely, blockchain management functions, blockchain control functions, blockchain dynamic connection functions, and blockchain data functions, and provides four possible protocol stack designs for blockchain functions suitable for telecommunications networks.
[0186] An example of the functions implemented by each of the blockchain management function, blockchain control function, blockchain dynamic connection function, and blockchain data function is as follows:
[0187] Blockchain management functions: Deploy and manage the blockchain capabilities of nodes, including installing / removing blockchain capabilities (i.e., blockchain enablement modules and / or blockchain clients), activating, updating, locking, and deactivating the blockchain capabilities of nodes.
[0188] Blockchain control functions include the deployment and configuration of the blockchain, such as transmitting blockchain establishment requests, creating / updating / deleting blockchains, and configuring blockchain connection / node attributes. The blockchain control functions also include the transmission of important parameters, such as requests / subscriptions / notifications for blockchain information and blockchain capability information.
[0189] The blockchain dynamic connection function enables connections to be established between blockchain nodes. Nodes dynamically configure their blockchain connections, including joining / leaving the chain, checking connection status, and node election. Dynamic configuration of a node's blockchain connection refers to the dynamic configuration of that connection, including joining / leaving the chain. A node seeking to join the blockchain can use the node discovery process within the dynamic connection function to send its own information to a specific blockchain node (the blockchain node's internet protocol (IP) address may be obtained through existing communication network control plane protocols) to join the blockchain. For example, if a base station establishes a connection with another base station via the XnAP protocol and wants to join the other base station's blockchain, it expresses this intention through the node discovery process. The other base station can verify if they belong to the same operator. If both base stations belong to the same operator, the blockchain profile is updated, adding the first base station's information to the block's profile. The updated blockchain profile is then sent to the first base station and broadcast to other blockchain nodes.
[0190] Blockchain data functions: Transmission of blockchain data between blockchain nodes, including requesting / sending / responding to blockchain data, querying blockchain data, etc.
[0191] It should be noted that this application does not limit the functions implemented by the blockchain management function, blockchain control function, blockchain dynamic connection function, and blockchain data function. Some functions implemented by the blockchain control function can be implemented by the blockchain management function. For example, the blockchain management function implements the creation / updating / deletion of blockchains. In this document, blockchain can be simply referred to as "chain". For example, the chain name in the following text refers to the name of the blockchain.
[0192] The following example, using a node in a telecommunications network, illustrates the relationship between the four main functions: First, a node deploys / activates its blockchain capabilities through the blockchain management function, and this node can then be called a blockchain node. LAF executes the blockchain control function to establish a blockchain, and only nodes with blockchain capabilities can join this chain. LAF can also configure existing blockchains or nodes joining blockchains through the blockchain control function. Nodes can dynamically leave or join a blockchain through the blockchain dynamic connection function. Nodes participating in the blockchain synchronize data through the blockchain data function.
[0193] Different blockchain functions can be mapped to different 3GPP protocol stacks ("mapped" means placing a blockchain function on a specific facet, i.e., making that facet support that blockchain function). This application designs three different schemes for dividing blockchain protocol faces.
[0194] Option 1: Blockchain management function, blockchain control function, blockchain dynamic connection function, and blockchain data function correspond to the 3GPP management plane (MP), the 3GPP control plane (CP), the blockchain dynamic connection function, and the 3GPP user plane (UP) (or data plane), respectively.
[0195] Figure 3 illustrates an example of a function-based protocol stack provided in this application. As shown in Figure 3, the blockchain management function corresponds to 3GPP-MP, the blockchain control function corresponds to 3GPP-CP, the blockchain dynamic connection function corresponds to the plane, and the blockchain data function corresponds to 3GPP-UP. The plane corresponding to the blockchain dynamic connection function refers to the plane in 6G networks or future communication networks that corresponds to the blockchain dynamic connection function; a similar plane does not exist in 5G communication networks. The fused new CP in Figure 3 addresses the possible future fusion of the management plane and control plane. That is, if the management plane and control plane are merged, the merged plane will support both blockchain management and blockchain control functions.
[0196] Option 1 facilitates protocol stack deployment. LAF deploys the management plane protocol (supporting blockchain management functions) and the control plane protocol (supporting blockchain control functions). Nodes with blockchain enablement modules and / or blockchain clients deploy all four planes of the protocol. Option 1 sets different planes for different blockchain functions, conforming to the protocol plane division principle and providing a clearer division of protocol plane functions.
[0197] Option 2: The blockchain management function corresponds to the 3GPP management plane, the blockchain control function corresponds to the 3GPP control plane, and the blockchain dynamic connection function and blockchain data function correspond to the 3GPP user plane. Option 2 adopts the three-plane design of 3GPP, and the blockchain dynamic connection function and blockchain data function will be merged into one plane.
[0198] Figure 4 illustrates an example of protocol stack partitioning based on node type provided in this application. As shown in Figure 4, in Scheme 2, the blockchain management function and blockchain control function are separated into independent planes. That is, the blockchain management function corresponds to the 3GPP management plane, the blockchain control function corresponds to the 3GPP control plane, and the blockchain dynamic connection function and blockchain data function both correspond to the user plane. In other words, the protocol stacks for the blockchain dynamic connection function and the blockchain data function are both placed on the user plane. The blockchain management function and blockchain control function are both LAF-related, while the blockchain dynamic connection function and blockchain data function are only related to nodes that have deployed blockchain enabling modules and / or blockchain clients. Therefore, this scheme allows LAF to deploy only the blockchain functions relevant to itself, namely the blockchain management function and the blockchain control function. Scheme 2 uses the same protocol to implement the blockchain dynamic connection function and data function. This scheme facilitates protocol stack deployment; each node only needs to deploy the protocol stack relevant to itself. For example, LAF only deploys the protocol stacks for the blockchain management function and the blockchain control function, while nodes with blockchain enabling modules and / or blockchain clients deploy the protocols for all four planes.
[0199] Option 3: The blockchain management function corresponds to the 3GPP management plane, the blockchain control function and blockchain dynamic connection function correspond to the 3GPP control plane, and the blockchain data function corresponds to the 3GPP user plane. Option 3 divides the protocol stack based on message type, merging the blockchain control function and the blockchain dynamic connection function into one plane. That is, the protocol stacks of the blockchain control function and the blockchain dynamic connection function are placed on the same plane, while the blockchain data function remains independent. This ensures that control plane interaction messages do not contain blockchain data, while service plane interaction messages only contain blockchain data.
[0200] Figure 5 illustrates an example of a protocol stack partitioned based on message type, as provided in this application. As shown in Figure 5, the blockchain management function corresponds to the 3GPP management plane, the blockchain control function and the blockchain dynamic connection function correspond to the 3GPP control plane, and the blockchain data function corresponds to the 3GPP user plane.
[0201] The above three schemes for dividing the protocol stack are only examples. Other methods can also be used to divide the protocol stack of blockchain functions, and this application does not limit them.
[0202] In one possible implementation, the telecommunications network establishes a trusted surface (or "security surface," both meaning the same thing, referring to a protocol surface where security functions are independently designed). The four types of blockchain functions would then correspond to this trusted surface. If the trusted surface is further divided into a trusted management surface, a trusted control surface, and a trusted service surface (which respectively execute the management, configuration, and data transmission of security functions), then the blockchain functions can also be mapped to the trusted management surface (corresponding to the management surface in Figures 3 to 5), the trusted control surface (corresponding to the control surface in Figures 3 to 5), and the trusted service surface (corresponding to the user surface in Figures 3 to 5) as shown in Figures 3 to 5.
[0203] The following section provides examples of protocol stacks (including the Trustworthiness Blockchain Control Protocol, TBCP) deployed on different types of nodes in telecommunications networks. TBCP can be a protocol that supports blockchain control functions. In one possible implementation, 3GPP management plane functions can be implemented using control signaling, in which case TBCP also supports blockchain management functions.
[0204] Example 1: Nodes (including UEs and access network devices) and the LAF (Local Area Function) with deployed blockchain enabling modules and / or blockchain clients all deploy TBCP. UEs with deployed blockchain enabling modules and / or blockchain clients communicate with the LAF in the core network via the TBCP protocol; access network devices with deployed blockchain enabling modules and / or blockchain clients communicate with the LAF in the core network via TBCP. The TBCP deployed on each node can be deployed on top of the respective connection-establishing protocols, such as PDCP, SCTP, Transmission Control Protocol (TCP), User Datagram Protocol (UDP), etc. In one possible implementation, the UE's TBCP is deployed at the highest layer of the protocol stack, the access network device's TBCP is deployed at the highest layer of the protocol stack, and the LAF's TBCP is deployed at the highest layer of the protocol stack.
[0205] As mentioned in the previous introduction to subdomains, the access network can deploy LAF. During the transition from 5G to 6G, introducing LAF, blockchain enabling modules, and / or blockchain clients into the telecommunications network may not be a one-step process; LAF can initially be introduced only in the core network. In one possible implementation, the access network may not have LAF, i.e., there is no sub-LAF in the telecommunications network. Figure 6 shows an example of a blockchain control protocol stack provided in an embodiment of this application. As shown in Figure 6, nodes (including UEs and access network devices) and LAFs deployed with blockchain enabling modules and / or blockchain clients both deploy TBCP, and the TBCP protocol is at the highest layer of the protocol stack. The protocols deployed at each node in Figure 6, excluding TBCP, such as Radio Resource Control (RRC), Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Media Access Control (MAC), Service Data Adaptation Protocol (SDAP), Physical Layer (PHY), Stream Control Transport Protocol (SCTP), Internet Protocol, and Data Link Protocol, can be found in 3GPP standards or future 3GPP standards and will not be detailed here. This application uses the protocols below TBCP that are already adopted in 5G. If future 6G adds / deletes / replaces protocols, this application can simply use the new protocols. In other words, regardless of how the underlying protocols evolve, TBCP always supports blockchain control functions and remains at a higher level. This application does not limit the protocol stack below TBCP shown in Figure 6; Figure 6 is merely an example.
[0206] Example 2: Nodes (including UEs and access network devices) and LAFs deployed with blockchain enabling modules and / or blockchain clients all deploy TBCP. The UE, access network device, and LAF can all use the same TBCP layer. An LAF exists within the access network. Figure 7 illustrates another example of a blockchain control protocol stack provided in this application embodiment. As shown in Figure 7, the UE communicates with the access network device (e.g., gNB) deployed with a sub-LAF via TBCP. The access network device communicates with the LAF in the core network via TBCP. The UE communicates with the LAF in the core network by forwarding TBCP-related control signaling (or TBCP signaling) through the access network device. The TBCP deployed by each node can be deployed on top of its respective connection establishment protocol, such as PDCP, SCTP, TCP, UDP, etc. Communication between the access network device and the access network device with the sub-LAF, and between the NF and the LAF, is achieved through TBCP. In one possible implementation, the TBCP of the UE, the TBCP of the access network equipment, the TBCP of the NF, and the TBCP of the LAF are deployed at the highest layer of the protocol stack. The descriptions of the protocols deployed at each node in Figure 7, excluding TBCP, can be found in the 3GPP standard or future 3GPP standards, and will not be detailed here. This application uses the existing 5G protocols for the protocols below TBCP. If future 6G adds / deletes / replaces protocols, this application can simply use the new protocols. In other words, regardless of how the underlying protocols evolve, TBCP always supports blockchain control functions and remains at a high level.
[0207] In one possible implementation, when the protocol stacks deployed by each network element in the power grid network are as shown in Figure 7, the UE's blockchain enabling module and / or blockchain client follow the access network device's blockchain enabling module and / or blockchain client to select LAF. That is, the UE is not aware whether the access network device has LAF. The UE's blockchain enabling module and / or blockchain client send messages to LAF, regardless of whether LAF is in the access network or the core network. The access network device processes TBCP signaling (i.e., signaling generated through TBCP) as follows:
[0208] Access network devices can parse TBCP signaling, meaning they have a blockchain enabling module and / or a blockchain client deployed, support blockchain functionality, and have deployed the blockchain protocol. They process received TBCP signaling in the following manner:
[0209] If the access network device itself has LAF deployed, the access network device can unpack the received TBCP signaling, that is, parse the TBCP signaling;
[0210] If the access network device itself does not deploy a LAF, the access network device can send the received TBCP signaling to the LAF to which the blockchain enabling module and / or blockchain client of the access network device belong. The LAF to which the blockchain enabling module and / or blockchain client of the access network device belongs may be a sub LAF of other RAN nodes or a LAF in the core network.
[0211] If the access network device cannot parse TBCP, that is, the access network device has not deployed a blockchain enabling module and / or a blockchain client, the access network device will forward the received TBCP signaling to the LAF in the core network.
[0212] Example 3: The UE is deployed with a two-layer blockchain protocol stack, namely TBCP-core network and TBCP-Radio Access Network (RAN). The access network equipment is deployed with TBCP-RAN, and the LAF is deployed with TBCP-core. Figure 8 shows another example of a blockchain control protocol stack provided in this application embodiment. As shown in Figure 8, the UE communicates with the access network equipment through the TBCP-RAN protocol, and the UE communicates with the LAF in the core network through the TBCP-core protocol. There can be sub-LAFs in the access network. The access network equipment can distinguish whether a message should be unpacked locally or sent to the core network through different protocol types.
[0213] In one possible implementation, when the protocol stacks deployed by various network elements in the telecommunications network are as shown in Figure 8, the blockchain enabling module and / or blockchain client in the UE can select LAF in the following manner:
[0214] The UE can choose the LAF in the access network and the LAF in the core network, and communicate with the LAF by generating signaling of different protocol types;
[0215] After a UE joins the network, the LAF in the core network assigns it a specific LAF. If a sub-LAF in the access network is assigned, the UE will communicate with it via the TBCP-RAN protocol; if a LAF in the core network is assigned, the UE will communicate with the LAF in the core network via TBCP-core.
[0216] In Examples 1, 2, and 3, a new protocol (TCBP) is used to set up an independent protocol for blockchain-related functions. The protocol can be downloaded / activated / deactivated / deleted along with the blockchain enabling module and / or blockchain client, which is conducive to the independent configuration of blockchain capabilities.
[0217] Example 4: Reusing existing 5G protocol layers to implement blockchain functionality. Figure 9 shows another example of a blockchain control protocol stack provided in this application embodiment. As shown in Figure 9, the UE and the LAF in the core network transmit blockchain-related signaling through a non-access stratum (NAS) protocol, with the NAS adding blockchain control functions (and possibly blockchain management functions); the UE and access network equipment transmit blockchain-related signaling through the RRC protocol, with the RRC adding blockchain control functions (and possibly blockchain management functions); the access network equipment and the LAF in the core network can reuse the NG interface, using the next generation application protocol (NGAP) to transmit blockchain-related signaling, with the NGAP adding blockchain control functions (and possibly blockchain management functions); or, a new interface is defined between the access network equipment and the LAF, using the new interface to transmit blockchain-related signaling; the access network equipment can reuse the Xn interface, using the Xn interface application protocol (Xn application... The XnAP protocol is used to transmit blockchain-related signaling. XnAP adds blockchain control functions (and possibly blockchain management functions); alternatively, a new interface is defined between access network devices, and the new interface is used to transmit blockchain-related signaling; NFs in the core network directly reuse the service-based interface (SBI) to transmit blockchain-related signaling. Due to the modification of the existing protocol, NAS* / RRC* / NGAP* / XnAP* is used in Figure 9 to represent the modified NAS / RRC / NGAP / XnAP.
[0218] In Example 4, by reusing the NAS / RRC / NGAP / XnAP protocols, blockchain functionality can be introduced into the telecommunications network with minimal modifications to the network.
[0219] The aforementioned protocol and protocol stack scheme for blockchain control functions facilitates the introduction of blockchain technology into telecommunications networks. This application designs a new architecture for introducing blockchain into telecommunications networks and defines new blockchain functions; it is not simply a combination of blockchain technology and telecommunications networks.
[0220] A key concept of the technical solution in this application is that LAF serves as the anchor point for the overall management and association of the blockchain, performing functions such as blockchain management, blockchain capability registration management, blockchain creation, blockchain capability activation, and blockchain access control, which aligns with the characteristics of telecommunications networks that divide protocols into management plane, control plane, and user plane.
[0221] The following describes the blockchain management and control functions mentioned above.
[0222] Blockchain management functions refer to the deployment and management of the blockchain capabilities of nodes, which can be divided into two categories: capability deployment and capability management.
[0223] Capability deployment can include installing and deleting blockchain capabilities. Installing a blockchain capability involves adding a blockchain capability to a node. Deleting a blockchain capability involves removing (or deleting) an existing blockchain capability from a node.
[0224] Capability management can include blockchain capability activation, blockchain capability update, blockchain capability locking / unlocking, and blockchain capability deactivation. Blockchain capability activation involves activating an existing blockchain enabling module or blockchain client on a node. Blockchain capability update involves setting new blockchain capability information for a node. Blockchain capability locking prevents a node's blockchain capabilities from being updated (e.g., while the capability is being invoked or in the process of being updated). Blockchain capability unlock allows a node's blockchain capabilities to be updated, restoring it from a locked state. Blockchain capability deactivation prevents a node's blockchain capabilities from being invoked or updated.
[0225] To enable on-demand orchestration and flexible assembly of blockchain capabilities, nodes can acquire blockchain capabilities in two ways. If a node initially lacks blockchain functionality (or does not possess blockchain capabilities), LAF can enable the node to acquire blockchain capabilities by installing the functionality. If a node comes pre-installed with blockchain functionality, LAF can configure the node's blockchain capabilities through activation for subsequent use.
[0226] Blockchain capability locking means that a blockchain capability cannot be updated. Blockchain capability disabling means that a blockchain capability cannot be updated or invoked. If a node's blockchain capability has its state set as a parameter, the state transition is shown in Figure 10. Figure 10 is an example of a state transition diagram for a blockchain capability provided in an embodiment of this application. As shown in Figure 10, when a node's blockchain capability is installed / activated, the node enters the configured state, indicating that the node's blockchain capability can be invoked / updated at any time; when the node's blockchain capability is locked, it enters the locked state. At this time, an unlocking operation can be performed to restore the blockchain function from the locked state to the configured state, or a disabling operation can be performed to make the blockchain enter the disabled state; when the node's blockchain capability is disabled, it enters the disabled state (which can be called the inactive state), at which point it can only be invoked / updated after reactivation.
[0227] The blockchain management function may provide the following instruction set:
[0228] (Sub)BC enabler load request / response: (Subdomain) BC capability installation request / response;
[0229] (Sub)BC client load request / response: (Subdomain)BC client load request / response;
[0230] (Sub)BC enabler delete request / response: (Subdomain)BC capability deletes request / response;
[0231] (Sub)BC enabler enable request / response: (Subdomain) BC capability activation request / response;
[0232] (Sub)BC enabler update request / response: (Subdomain) BC capability update request / response;
[0233] (Sub)BC client update request / response: (Subdomain)BC client update request / response;
[0234] (Sub)BC enabler lock request / response: (Subdomain) BC capability lock request / response;
[0235] (Sub)BC enabler disable request / response: (Subdomain)BC capability disables request / response.
[0236] The above instruction set is only a partial example; the blockchain management function may provide other instructions, which are not limited here. The following describes the information carried by the instructions that the blockchain management function may provide.
[0237] The BC enabler load request can carry information for the node to install the BC enabler module, i.e., information for the node to deploy blockchain capabilities. The BC enabler load response can carry the parameter "success / failure". Success indicates that the node successfully installed the blockchain enabler module, while failure indicates that the node failed to install the blockchain enabler module. In one possible implementation, the BC enabler load request can also carry information for the node to install the BC client, i.e., information for the node to deploy the blockchain client; the BC enabler load response can also carry the parameter "success / failure". Success indicates that the node successfully installed the blockchain client, while failure indicates that the node failed to install the blockchain client. For example, the installation of the blockchain enabler module and the blockchain client can be deployed in the same way, i.e., both are deployed through the BC enabler load request.
[0238] The Sub-BC enabler load request can carry information for installing the blockchain enabler module (subBC enabler) on nodes within a sub-domain; the Sub-BC enabler load response can carry the parameter "success / failure". Success indicates that all nodes within the sub-domain have successfully installed the blockchain enabler module, while failure indicates that at least one node within the sub-domain has failed to install the blockchain enabler module. In one possible implementation, the Sub-BC enabler load request can also carry information for installing the blockchain client (BC client) on nodes within a sub-domain; the Sub-BC enabler load response can carry the parameter "success / failure". Success indicates that all nodes within the sub-domain have successfully installed the blockchain client, while failure indicates that at least one node within the sub-domain has failed to install the blockchain client.
[0239] The BC client load request / response can carry information for the node to install the blockchain client (BC client), i.e., information for the node to deploy the blockchain client; the BC client load response can carry the parameter "success / failure". Success indicates that the node has successfully installed the blockchain client, and failure indicates that the node has failed to install the blockchain client.
[0240] The subdomain BC client load request / response can carry information about installing the blockchain client (BC client) on nodes within a subdomain; the subdomain BC client load response can carry the parameter "success / failure". Success indicates that all nodes within the subdomain have successfully installed the blockchain client, while failure indicates that at least one node within the subdomain has failed to install the blockchain client.
[0241] A BC enabler delete request can carry information instructing a node to delete a blockchain capability; a BC enabler delete response can carry the parameter "success / failure". Success indicates that the node successfully deleted the blockchain capability, while failure indicates that the node did not successfully delete the blockchain capability.
[0242] A Sub-BC enabler delete request can carry information instructing a sub-LAF to delete the blockchain capabilities of nodes within its associated sub-domain; a Sub-BC enabler delete response can carry the parameter "success / failure". Success indicates that the sub-LAF successfully deleted the blockchain capabilities of nodes within its associated sub-domain, while failure indicates that the sub-LAF did not successfully delete the blockchain capabilities of nodes within its associated sub-domain.
[0243] The BC enabler enable request can carry information indicating the blockchain capability to be activated by the node; the BC enabler enable response can carry the parameter "success / failure". Success indicates that the node has successfully activated the blockchain capability, and failure indicates that the node has not successfully activated the blockchain capability.
[0244] The Sub-BC enabler enable request can carry information indicating the activation of blockchain capabilities for nodes within the sub-domain (i.e., the sub-BC enabler profile); the Sub-BC enabler enable response can carry the parameter "success / failure". Success indicates that the node within the sub-domain has successfully activated the blockchain capability, while failure indicates that the node within the sub-domain has not successfully activated the blockchain capability.
[0245] A BC enabler update request can carry either blockchain enabler module configuration information (i.e., BC enabler profile) or updated blockchain enabler module configuration information (i.e., partially updated blockchain enabler module configuration information); a BC enabler update response can carry the parameter "success / failure". Success indicates successful update of the blockchain enabler module, i.e., successful update of the node's blockchain capabilities; failure indicates unsuccessful update of the blockchain enabler module. The blockchain enabler module configuration information (i.e., BC enabler profile) can refer to the attributes of the blockchain node, including the blockchain node's own capabilities and the blockchain capabilities of the blockchain node. In one possible implementation, a BC enabler update request can carry either blockchain client configuration information (i.e., BC client profile) or updated blockchain client configuration information (i.e., partially updated blockchain client configuration information); a BC enabler update response can carry the parameter "success / failure". Success indicates successful update of the blockchain client, i.e., successful update of the node's blockchain capabilities; failure indicates unsuccessful update of the blockchain client.
[0246] BC client update requests / responses can carry blockchain client configuration information (i.e., BC clientprofile) or updated blockchain client configuration information (i.e., partially updated blockchain client configuration information); BC enabler update responses can carry the parameter "success / failure". Success indicates a successful update of the blockchain client, i.e., a successful update of the node's blockchain capabilities; failure indicates an unsuccessful update of the blockchain client. It should be noted that the methods for deploying, updating, locking, and disabling the blockchain client can be similar to or the same as those for deploying, updating, locking, and disabling the blockchain enabler module, and will not be elaborated further here. The following description uses the deployment, updating, locking, and disabling of the blockchain enabler module as an example.
[0247] A Sub-BC enabler update request can carry either the blockchain enabler profile of nodes within the same sub-domain or updated configuration information of the blockchain enabler (i.e., the updated configuration information of a portion of the sub-domain's blockchain enabler). A Sub-BC enabler update response can carry the parameter "success / failure". Success indicates that the blockchain enabler profiles of all nodes within the sub-domain have been successfully updated; failure indicates that the blockchain enabler profiles of all nodes within the sub-domain have not been successfully updated.
[0248] A BC enabler lock request can carry the parameter "lock reason," such as: BC capability upgrade (requiring temporary locking of the blockchain enabler module to prevent its invocation); a BC enabler lock response can carry the parameter "success / failure." Success indicates successful locking of the blockchain enabler module; failure indicates unsuccessful locking of the blockchain enabler module. A success message in a subdomain BC enabler lock response indicates successful locking of the blockchain enabler module for each node within the subdomain; a failure message in a subdomain BC enabler lock response indicates unsuccessful locking of the blockchain enabler module for each node within the subdomain.
[0249] A BC enabler disable request can carry the parameter "reason for disablement," such as: the network has stopped providing blockchain services. A BC enabler disable response can carry the parameter "success / failure." Success indicates that the blockchain enabler module was successfully disabled; failure indicates that the blockchain enabler module was not successfully disabled. A success message in a subdomain BC enabler disable response indicates that the blockchain enabler module was successfully disabled for all nodes within the subdomain; a failure message in a subdomain BC enabler disable response indicates that the blockchain enabler module was not successfully disabled for all nodes within the subdomain.
[0250] Blockchain control functions refer to the deployment and configuration of the blockchain, as well as the transmission of some blockchain parameters. They can be divided into the following five categories: blockchain deployment, blockchain configuration, blockchain node configuration, transmission of blockchain information, and transmission of blockchain capability information.
[0251] Blockchain deployment can include: nodes sending blockchain requests, establishing a blockchain, deleting a blockchain, and updating a blockchain. A node sending a blockchain request can be: a node sends a blockchain service request to LAF, requesting the establishment of a blockchain. LAF executes the blockchain establishment process, sending blockchain parameters to all selected nodes (those with blockchain enabling modules or blockchain clients deployed) to establish the blockchain. Establishing a blockchain can be: LAF decides to establish a blockchain based on requests from nodes or upper-layer applications, determining the nodes included in the blockchain, the functions the blockchain should have, and the specific algorithms used, and actively establishes the blockchain. Deleting a blockchain can be: LAF deletes an already established blockchain. Updating a blockchain can be: LAF selects the algorithm used in the new blockchain and updates the blockchain parameters, such as transaction / ledger format, peer-to-peer (P2P) protocol, consensus mechanism, and security algorithm.
[0252] Blockchain configuration can include blockchain connection configuration and blockchain node configuration. Blockchain connection configuration can involve configuring blockchain connection parameters, such as connection method, network topology, and configuring the blockchain node list. For example, one way to configure a blockchain connection is through the blockchain control function, where LAF configures each node, achieving a centralized configuration method. Blockchain node configuration can involve configuring the attributes of blockchain nodes, such as node role, node running status, and whether it is a super node. It should be noted that blockchain configuration can involve configuring multiple parameters at once, or configuring a specific parameter at a time.
[0253] The transmission of blockchain information can include sending blockchain information requests and subscribing to / notifying about blockchain information. Sending a blockchain information request can be: LAF requests to obtain information about the blockchain to which a node belongs, such as blockchain configuration information (BC profile). Subscribing to / notifying about blockchain information, such as the BC profile, can be: subscribing to / notifying about blockchain information. Blockchain configuration information (BC profile) can refer to blockchain attributes, including the specific algorithm used by the blockchain and node information on the blockchain.
[0254] The transmission of blockchain capability information can include: blockchain capability information registration / deregistration, blockchain capability information acquisition, and blockchain capability information subscription / notification. Blockchain capability information registration can be: a node registering its own blockchain capability information with the network when joining. Blockchain capability information deregistration can be: a node deregistering its own blockchain capability information when leaving the network. Blockchain (BC) capability information acquisition can be: LAF acquiring a node's blockchain capability information. Blockchain capability information subscription / notification can be: subscribing to / notifying a node of its blockchain capability information, such as BC enablerprofile. It should be noted that the transmission of blockchain information / blockchain capability information can acquire multiple parameters at once, or it can acquire a specific parameter at once.
[0255] The blockchain control functionality may provide the following instruction set:
[0256] BC service request: Used to request blockchain services;
[0257] BC setup request / response: Used to create a blockchain;
[0258] BC remove request / response: Used to delete a blockchain.
[0259] BC update request / response: Used to update the blockchain;
[0260] Subdomain BC request / response: A subdomain BC request is used to indicate the requirements of the subdomain blockchain, such as requiring the subdomain to have a chain containing N nodes;
[0261] BC connection configuration request / response: Used to configure the blockchain connection;
[0262] BC connection method configuration request / response: Used to configure the blockchain connection method;
[0263] Blockchain node list configuration request / response: Used to configure the blockchain node list;
[0264] BC node config request / response: Used to configure chain node properties;
[0265] Chain node role configuration request / response: Used to configure the chain node role;
[0266] Chain node status configuration request / response: Used to configure the running status of the chain node, such as the activation, suspension, and cancellation of transaction reporting;
[0267] Subdomain blockchain configuration request / response: Used to configure the subdomain blockchain, such as requiring the subdomain blockchain to configure N full nodes;
[0268] (Sub)BC profile request / response: Used to request (sub)BC configuration information;
[0269] (Sub)BC profile subscribe / notify: Used to subscribe to / notify (sub)BC profile configuration information;
[0270] (Sub)BC name / ID request / response: Used to request the (sub)BC name / ID;
[0271] (Sub)BC type request / response: Used to request (sub)BC type requests;
[0272] (Sub)BC enabler registration request / response: Used to register (sub)BC capabilities;
[0273] (Sub)BC enabler de-registration request / response: Used to deregister (sub)BC capabilities;
[0274] (Sub)BC enabler capability request / response: Used to obtain (sub)BC capability information;
[0275] (Sub)BC enabler capability subscribe / notify: Used to subscribe to / notify (sub)BC capability information.
[0276] The preceding section provided some examples of the instruction sets that the blockchain control function may provide. Other instructions may also be provided, which are not limited here. The following section describes the information carried by the instructions that the blockchain control function may provide.
[0277] A BC service request can carry the parameter "Blockchain Function (identity, spectrum sharing, etc.)" to request to join a chain or to request LAF to establish a chain (if no chain of that type exists).
[0278] A BC setup request can carry blockchain configuration information (i.e., a BC profile); a BC setup response can carry the parameter "success / failure". Success indicates that the blockchain was successfully established; failure indicates that the blockchain was not successfully established.
[0279] A BC remove request can carry the blockchain name or ID; a BC remove response can carry the parameter "success / failure". Success indicates that the blockchain was successfully deleted; failure indicates that the blockchain was not successfully deleted.
[0280] A BC update request can carry blockchain configuration information (i.e., the BC profile) or partial configuration information for updating the blockchain; a BC update response can carry the parameter "success / failure". Success indicates that the blockchain was successfully updated; failure indicates that the blockchain was not successfully updated.
[0281] A sub-BC request can carry sub-BC profile configuration information; a sub-BC response can carry the parameter "success / failure". Success indicates that the blockchain was successfully established; failure indicates that the blockchain was not successfully established.
[0282] The BC connection configuration request can carry parameters such as connection method, network topology, and blockchain node list; the BC connection configuration response can carry the parameter "success / failure". Success indicates that the blockchain connection was successfully configured; failure indicates that the blockchain connection was not successfully configured.
[0283] The BC connection method configuration request can carry the parameter "connection method" (supports centralized connection only, or also blockchain dynamic connection); the BC connection method configuration response can carry the parameter "success / failure". Success indicates successful configuration of the blockchain connection method; failure indicates unsuccessful configuration. Centralized connection refers to LAF configuring a node list for the blockchain node, i.e., the IP addresses and other information of other blockchain nodes that the node can connect to, thereby helping the node establish connections with other nodes. Blockchain dynamic connection refers to the node joining the blockchain network through interaction with other nodes on the blockchain, i.e., the aforementioned blockchain dynamic connection function, without requiring LAF to configure it through the blockchain control function.
[0284] The BC connection node list config request can carry the parameter "blockchain node list"; the BC connection node list config response can carry the parameter "success / failure". Success indicates that the blockchain node list has been successfully configured; failure indicates that the blockchain node list has not been successfully configured.
[0285] The BC node config request can carry parameters such as node role, node running status, and whether it is a super node; the BC node config response can carry the parameter "success / failure". Success indicates that the node attributes (attributes of nodes on the blockchain) have been successfully configured; failure indicates that the node attributes have not been successfully configured.
[0286] The BC node role config request can carry the parameter "node role (full node, light node, micro node, client, etc.)"; the BC node role config response can carry the parameter "success / failure". Success indicates that the node role (the role of a node on the blockchain) has been successfully configured; failure indicates that the node role has not been successfully configured.
[0287] The BC node status config request can carry the parameter "node status (configured status, locked status, disabled status, etc.)"; the BC node status config response can carry the parameter "success / failure". Success indicates that the node status (the running status of a node on the blockchain) has been successfully configured; failure indicates that the node status has not been successfully configured.
[0288] The Sub-BC config request can carry sub-BC blockchain configuration information (i.e., sub-BC profile). This sub-BC profile refers to the attributes of the sub-BC blockchains, including the specific algorithms used by all blockchains within the sub-domain and node information. The sub-BC configuration information is used to configure the blockchains within the sub-domain and can contain information about all blockchains within the sub-domain. The Sub-BC config response can carry the parameter "success / failure". Success indicates that the blockchain within the sub-domain was successfully established; failure indicates that the blockchain within the sub-domain was not successfully established.
[0289] Subdomain data configuration request (BC data configrequest / response): This involves configuring the blockchain data functionality, including configuring the data transmission format and the mapping between the air interface BC data type (BC bearer) and the Quality of Service (QoS) stream. The BC data configrequest can carry the configuration for the blockchain data functionality. The subdomain data configuration response (BC data configresponse) can carry the parameter "success / failure". Success indicates successful configuration of the blockchain data functionality; failure indicates unsuccessful configuration of the blockchain data functionality.
[0290] The (Sub)BC profile request can carry the name / ID of the (Sub)Blockchain; the (Sub)BC profile response can carry the (Sub)Blockchain configuration information (i.e., sub BC profile).
[0291] The (Sub)BC profile subscribe function can carry the name / ID of the (Sub)BC blockchain; the (Sub)BC profile notify function can carry the (Sub)BC blockchain configuration information (i.e., the sub BC profile).
[0292] The (Sub)BC name / ID response can carry the (Sub)Blockchain name / ID.
[0293] (Sub)BC type response can carry (sub)blockchain type, such as consortium blockchain / public blockchain / private blockchain.
[0294] The Sub-Blockchain Enabler Registration Request (CBEN) can carry Sub-Blockchain Enabler Profile information. This profile refers to Sub-Blockchain Enabler attributes, including the Sub-Blockchain's own capabilities, its blockchain capabilities, and node information within the Sub-Blockchain. For example, node information might include the types of nodes (UE, base station, NF) that support blockchain capabilities and the corresponding number of each type. The CBEN configuration information can also specify the blockchain algorithms supported by the Sub-Blockchain Enabler. The Sub-Blockchain Enabler Registration Response (CBRN) can carry the parameter "Success / Failure." Success indicates successful registration of the blockchain enabler within the Sub-Blockchain; failure indicates unsuccessful registration. The CBEN registration request can also carry CBEN profile information. The success message carried in the Blockchain Enabler Registration Response (BC enabler registration response) indicates that the node's blockchain enabler module has been successfully registered; the failure message carried in the BC enabler registration response indicates that the node's blockchain enabler module has not been successfully registered. In a communication system, after a node joins the network, it initiates a registration process with the core network elements. In some embodiments of this application, the node can also report its supported blockchain capabilities during registration (if the node already possesses blockchain capabilities). This scenario is applicable when a node is not accessing the network for the first time, or when a node accesses operator 2 after operator 1 has already obtained blockchain capabilities, and then reports its supported blockchain capabilities. This process is not mandatory, because some core networks may not support blockchain functionality and therefore do not need to obtain the node's blockchain capability information, or, to improve the efficiency of node access registration, blockchain capability information may not be registered, but only requested before application.
[0295] The (Sub)BC enabler de-registration request can carry the ID / IP address of the (Sub)BC enabler node. The (Sub)BC enabler de-registration response can carry the parameter "success / failure". Success indicates successful deregistration of the blockchain enabler module within the subdomain; failure indicates unsuccessful deregistration. A success message in the BC enabler de-registration response indicates successful deregistration of the node's blockchain enabler module; a failure message in the BC enabler de-registration response indicates unsuccessful deregistration of the node's blockchain enabler module.
[0296] The Sub-BC enabler capability request can carry the sub-domain's identifier. The BC enabler capability request can also carry the node's identifier. The Sub-BC enabler capability response can carry the blockchain capability information of the nodes within the sub-domain. The BC enabler capability response can also carry the node's blockchain capability information. Although the BC enabler is configured by LAF when a node first joins the network, the node may dynamically update the BC enabler according to its own needs, generating a new profile; or, when a node joins a new network, it may not have carried blockchain capability information in the registration message. In certain scenarios, the network may need to call the blockchain service and request the node's blockchain capability information before further configuration or chain establishment can be performed.
[0297] Subdomain BC enabler capability subscribe can carry the subdomain's identifier information; Subdomain BC enabler capability notify can carry the blockchain capability information of nodes within the subdomain. BC enabler capability subscribe can carry the node's identifier information; BC enabler capability notify can carry the node's blockchain capability information. Subdomain BC enabler capability subscribe / notify is suitable for scenarios where the network requires nodes to periodically report the blockchain capabilities they support.
[0298] As can be seen, many commands involve operations on the blockchain capabilities of nodes, as well as operations on subdomains. Operations on subdomains can disregard node details. Some commands in the command set that the blockchain control function may provide can be moved to the command set that the blockchain management function may provide. For example, the command set that the blockchain management function may provide may include BC setup request / response, BC remove request / response, and BC update request / response, while the command set that the blockchain control function may provide may not include BC setup request / response, BC remove request / response, and BC update request / response.
[0299] The following description, with reference to Figure 11, illustrates how LAF implements blockchain management and control functions.
[0300] Figure 11 is a flowchart of a communication method according to an embodiment of this application. The first node in Figure 11 is a LAF or sub-LAF in a telecommunications network, and the second node is a node in the telecommunications network to be deployed or with a blockchain enabling module or blockchain client deployed. The method shown in Figure 11 is applied to a telecommunications network. As shown in Figure 11, the method includes:
[0301] 1101. The first node sends the first message to the second node.
[0302] Accordingly, the second node receives a first message from the first node. This first message is used for at least one of the following: blockchain capability management, blockchain capability deployment, blockchain client management, blockchain client deployment, blockchain creation, blockchain deletion, blockchain update, blockchain configuration, blockchain parameter acquisition, subdomain blockchain deployment, or subdomain blockchain configuration. The first message can be an instruction from the instruction set that the aforementioned blockchain management function may provide, or it can be an instruction from the instruction set that the aforementioned blockchain control function may provide.
[0303] For example, the first node can be a LAF in the core network, and the second node is a node with a blockchain enabling module or blockchain client deployed, such as a terminal device, access network device, or NF. The first message is used for at least one of the following: blockchain capability management, blockchain establishment, blockchain deletion, blockchain update, blockchain configuration, and blockchain parameter acquisition. For example, the first node can be an LAF in the core network or a sub-LAF in the access network, and the second node is a node without a blockchain enabling module or blockchain client deployed, i.e., a node that does not support blockchain capabilities. The first message is used for blockchain capability deployment. For example, the first node can be an LAF in the core network, and the second node is a sub-LAF in the access network. The first message is used for subdomain blockchain deployment or subdomain blockchain configuration. For example, the first node can be a sub-LAF in the access network, and the second node is a node with a blockchain enabling module or blockchain client deployed, such as a terminal device, access network device, or NF. The first message is used for at least one of the following: blockchain capability management, blockchain establishment, blockchain deletion, blockchain update, blockchain configuration, and blockchain parameter acquisition.
[0304] Referring to Figure 6, one example of step 1101 is as follows: The first node sends the aforementioned first message through a blockchain control protocol. This blockchain control protocol is either a protocol between a core network element and a terminal device, or a protocol between a core network element and an access network device. Referring to Figure 7, another example of step 1101 is as follows: The first node sends the aforementioned first message through a blockchain control protocol. This blockchain control protocol is either a protocol between different core network elements, or a protocol between a core network element and an access network device, or a protocol between an access network device and a terminal device, or a protocol between different access network devices. Referring to Figure 8, when the second node is a terminal device, one example of step 1101 is as follows: When the first node is a core network element, it sends the aforementioned first message to the second node through the first blockchain control protocol; another example of step 1101 is as follows: When the first node is an access network device, it sends the aforementioned first message to the second node through a second blockchain control protocol, where the second blockchain control protocol is different from the first blockchain control protocol. Referring to Figure 9, one example of step 1101 is as follows: The first node sends the aforementioned first message to the second node through a non-access stratum protocol, where the first node is a core network element and the second node is a terminal device; another example of step 1101 is as follows: The first node sends the aforementioned first message to the second node through a radio resource control protocol, where the first node is an access network device and the second node is a terminal device; another example of step 1101 is as follows: The first node sends the aforementioned first message to the second node through a next-generation application protocol, where the first node is a core network element and the second node is an access network device; yet another example of step 1101 is as follows: The first node sends the aforementioned first message to the second node through an Xn interface application flow protocol, where the first node and the second node are different access network devices.
[0305] 1102. The second node sends a second message to the first node.
[0306] Accordingly, the first node receives a second message from the second node. This second message is used in response to the first message. The protocol used by the second node to send the second message to the first node can be the same as the protocol used by the first node to send the first message to the second node, and will not be elaborated here.
[0307] In one possible implementation, the first message is used for at least one of deleting, activating, updating, locking, or closing a blockchain capability. Alternatively, the first message is used by the second node to delete, activate, update, lock, or close a blockchain capability. Or, the first message is used to delete, activate, update, lock, or close a second node's blockchain capability. For example, the first message is for deleting a blockchain capability, i.e., a BC enabler delete request; the second message is for indicating whether the deletion of the second node's blockchain capability was successful or failed, i.e., a BC enabler delete response. For example, the first node is an LAF, the second node is a sub-LAF, the first message is for updating the subdomain's blockchain capability, i.e., a Sub BC enabler update request; the second node can update the blockchain capabilities of some or all nodes within its associated subdomain based on the first message, and the second message is for indicating whether the subdomain's blockchain capability update was successful or failed, i.e., a Sub BC enabler update response. For example, the first node is a LAF (Local Blockchain Enabler), and the second node is a sub-LAF. The first message is a message for disabling the subdomain blockchain capability, i.e., a Sub BC enabler disable request. Based on the first message, the second node can disable the blockchain capabilities of some or all nodes within its associated subdomain. The second message is a message indicating whether the disabling of the second node's subdomain blockchain capability was successful or unsuccessful, i.e., a Sub BC enabler disable response. This implementation can achieve at least one of the following: deletion, activation, update, locking, or disabling of a node's blockchain capability in a telecommunications network.
[0308] In one possible implementation, the aforementioned first message is used for blockchain deletion. In this document, a blockchain associated with a node refers to the blockchain including that node. For example, the first node is an LAF, the second node is a sub-LAF, and the first message is a message used by the second node to delete one or more blockchains within its associated subdomain, i.e., a sub-BC remove request. The second node can delete one or more blockchains within its associated subdomain based on this first message. The second message is used to indicate whether the second node successfully deleted one or more blockchains within its associated subdomain; for example, the second message is a sub-BC remove response. In this implementation, the first message is used for at least one of blockchain establishment, blockchain deletion, and blockchain update, which can realize at least one of blockchain establishment, blockchain deletion, and blockchain update in a telecommunications network.
[0309] In one possible implementation, the first message is used to configure the blockchain connection or the blockchain node. The blockchain connection configuration can include at least one of the following: blockchain connection method configuration, blockchain network topology configuration, and blockchain node list configuration. For example, one blockchain connection method supports only centralized connections, while another supports both centralized and dynamic blockchain connections. An example of configuring the blockchain network topology is that it includes supernodes, which are nodes responsible for authenticating and authorizing nodes joining the chain and maintaining the complete blockchain ledger. The blockchain node configuration can include at least one of the following: blockchain node attribute configuration, blockchain node role configuration, or blockchain node running status configuration. Blockchain node attributes can include node role, node running status, and whether the node is a supernode. Blockchain node roles can include full node, light node, micro node, and client. Blockchain node roles are used to limit the different permissions of blockchain nodes. For example, a full node has the following permissions: query / report transactions, generate blocks, participate in consensus, write to the ledger, and save the ledger; a light node has the following permissions: query / report transactions, generate blocks, participate in consensus, and write to the ledger; a micro node has the following permissions: query / report transactions and generate blocks; and a client has the following permissions: query / report transactions. The operating status of a blockchain node can include configured, locked, and disabled states. For example, the first node is LAF, and the second node is a node with a blockchain enabling module or blockchain client deployed. The first message is a message used by the second node to configure its blockchain connection, i.e., a BC connection config request; the second node can configure its blockchain connection based on the first message, i.e., configure its blockchain connection method, blockchain network topology, and blockchain node list; the second message is a message used to indicate whether the second node's blockchain connection configuration was successful or failed, i.e., a BC connection config response. For example, the first node is a LAF (Local Area Framework), and the second node is a sub-LAF. The first message is a SubBC config request used by the second node to configure the blockchain within its associated subdomain. Based on the first message, the second node can configure the blockchain within its associated subdomain, for example, configuring N full nodes for the blockchain within its associated subdomain. The second message is a SubBC config response used to indicate whether the second node has successfully configured the blockchain within its associated subdomain. In this implementation, the configuration of blockchain connections or blockchain nodes in a telecommunications network can be achieved.
[0310] In one possible implementation, the first message is used to request at least one of the following: requesting blockchain configuration information, subscribing to blockchain configuration information, requesting a blockchain identifier, requesting a blockchain type, requesting blockchain capability information, or subscribing to blockchain capability information. For example, the first node is an LAF (Local Area Framework), and the second node is a node with a blockchain enabling module or blockchain client deployed. The first message is a message requesting configuration information of the blockchain containing the second node's information, i.e., a BC profile request; the second message is a message carrying configuration information of the blockchain containing the second node's information, i.e., a BC profile response. For example, the first node is an LAF, and the second node is a sub-LAF. The first message is a message requesting the type of blockchain within a subdomain associated with the second node, i.e., a Sub BC type request; the second message indicates the type of blockchain within the subdomain associated with the second node, for example, a Sub BC type response. In this implementation, the first node can obtain the corresponding blockchain parameters by sending the first message, thereby enabling better blockchain management and / or configuration.
[0311] Existing blockchain protocols and protocol stacks cannot be directly applied to telecommunications networks. In this embodiment, the first node sends a first message to the second node; at least one of the following can be implemented in the telecommunications network: management of blockchain capabilities, deployment of blockchain capabilities, establishment of blockchain, deletion of blockchain, update of blockchain, configuration of blockchain, acquisition of blockchain parameters, deployment of subdomain blockchain, or configuration of subdomain blockchain.
[0312] Figure 12 is a flowchart of another communication method provided in an embodiment of this application. The method flow in Figure 12 is an example of the method described in Figure 11. Figure 12 is an example flow of LAF or sub-LAF deploying a blockchain enabling module or blockchain client for nodes (UE, base station, NF, etc.) that do not support blockchain capabilities. As shown in Figure 12, the method includes:
[0313] 1201. The first node determines the blockchain capabilities that the second node should possess and generates blockchain enabling module or blockchain client configuration information.
[0314] In one possible implementation: After determining that the second node needs to install a blockchain enabling module or a blockchain client based on requirements, the first node determines the blockchain capabilities that the second node should possess (transaction / ledger format, P2P protocol, consensus mechanism, incentive mechanism, wallet type, security algorithm, etc.) and generates blockchain enabling module configuration information (BC enabler profile). For example, the LAF receives requirements from upper-layer services (e.g., using blockchain for node authentication) and determines that nodes in the telecommunications network should have blockchain capabilities. If the requirements state that the blockchain should have a high security level, the LAF can select various post-quantum encryption algorithms as the node's security algorithms. The LAF can generate a BC enabler profile based on the selected blockchain capabilities and the capabilities reported by the node during registration. If a node reports during registration that it does not have a BC enabler, the LAF initiates the process, i.e., the method flow in Figure 12. Step 1201 is optional; this application does not limit the way the first node obtains the blockchain enabling module configuration information.
[0315] 1202. The first node sends a blockchain enabler load request message to the second node.
[0316] Correspondingly, the second node receives a blockchain capability installation request message from the first node.
[0317] The blockchain capability installation request message is used to request a second node to deploy a blockchain enablement module or blockchain client, i.e., to request the second node to install blockchain capabilities. This message may carry an installation package for deploying blockchain capabilities on the second node, as well as first configuration information indicating the blockchain capabilities of the second node.
[0318] The Blockchain Enabler Load Request (BC enabler load request) message is an example of the first message in Figure 11. For instance, the first node is LAF, and the second node is a node that does not support blockchain capabilities (UE, base station, NF, etc.).
[0319] For example, the installation package for deploying blockchain capabilities on the second node includes a blockchain protocol and the node's internal processing logic. The internal processing logic refers to the code implementation of the blockchain's transaction / ledger format, P2P protocol, consensus mechanism, incentive mechanism, wallet type, security algorithm, etc., and the code for running blockchain functions. For example, the blockchain capability installation request message may also include a download address for the image code of the blockchain enabling module or blockchain client. For example, the aforementioned first configuration information may include the node's own capabilities (e.g., the capabilities of the second node itself) and the node's blockchain capabilities (e.g., the blockchain capabilities to be deployed on the second node).
[0320] A node's own capabilities may include one or more of the following: node identity (ID), node address, node type, node's own security capabilities, and node's own trust credentials.
[0321] The node type can be, for example, one of UE, gNB, NF, or blockchain appliance. The node's own security capabilities include, for example, having a trusted execution environment and supporting privacy protection mechanisms. The node's own trust credentials can be, for example, a public key.
[0322] A node's blockchain capabilities may include one or more of the following:
[0323] Node roles: one of the following: full node, light node, micro node, client, etc.
[0324] Node status: such as configured, locked, or disabled;
[0325] Supported P2P protocols for the node: For example, it supports P2P protocols based on Gossip or hash tables;
[0326] Consensus mechanisms supported by the node: one of the following algorithms: Proof of Work (PoW), Proof of Stake (PoS), Delegated Proof of Stake (DPoS), and Practical Byzantine Fault Tolerance (PBFT);
[0327] Incentive mechanisms supported by nodes: no incentive or incentive (e.g., rewards for completing tasks, rewards for participation);
[0328] Supported wallet types for the node: such as digital currency, virtual currency, etc.
[0329] Node supported transaction / ledger formats: for example, whether it supports editability, whether it adopts privacy protection, etc.;
[0330] The node supports the following security algorithms: such as hash algorithms, signature algorithms, encryption algorithms, etc.
[0331] The smart contracts supported by the node: such as a list of built-in smart contracts, and whether developers are allowed to upload new contracts.
[0332] 1203. The second node installs blockchain capabilities based on the blockchain capability installation request message.
[0333] Installing blockchain capabilities can involve deploying a blockchain enabler module or a blockchain client, and configuring the deployed blockchain enabler module or blockchain client according to the blockchain enabler profile.
[0334] 1204. The second node sends a blockchain capability installation response message to the first node.
[0335] Accordingly, the first node receives a blockchain enabler load response message from the second node. This response message may carry the result of the second node's blockchain enabler installation, including whether the installation was successful or failed.
[0336] In this embodiment, the first node requests the second node to deploy blockchain capabilities by sending a blockchain capability installation request message to the second node; blockchain capabilities can be installed for nodes in a telecommunications network.
[0337] Figure 13 is a flowchart of another communication method provided in an embodiment of this application. The method flow in Figure 13 is an example of the method described in Figure 11. Figure 13 is an example flow of an LAF requesting (or instructing) a sub-LAF to deploy a blockchain enabling module or blockchain client for nodes in the subdomain associated with that sub-LAF. As shown in Figure 13, the method includes:
[0338] 1301. The first node determines the blockchain capabilities that the first subdomain under the jurisdiction of the second node should possess, and generates the subdomain blockchain enabling module configuration information.
[0339] In one possible implementation, after the first node determines the requirements for installing a blockchain enabling module or blockchain client on nodes within the first subdomain, it determines the blockchain capabilities that nodes within the first subdomain should possess and generates subdomain blockchain enabling module configuration information (sub BC enabler profile). Step 1301 is optional, and this application does not limit the method by which the first node obtains the subdomain blockchain enabling module configuration information.
[0340] 1302. The first node sends a subdomain blockchain capability installation request message to the second node.
[0341] Correspondingly, the second node receives a sub-BC enabler load request message from the first node. For example, the first node is an LAF, and the second node is a sub-LAF. The sub-BC enabler load request message is an example of the first message in Figure 11. The sub-BC enabler load request message is used to deploy blockchain capabilities on one or more nodes within a first sub-domain. The first sub-domain includes one or more nodes managed by the second node, which is managed by the first node. The sub-BC enabler load request message carries an installation package for deploying blockchain capabilities on the one or more nodes, second configuration information, and information indicating the number of nodes within the first sub-domain that support blockchain capabilities. The second configuration information indicates the blockchain capabilities of the one or more nodes. Alternatively, the second configuration information indicates the blockchain capabilities of the sub-domain, such as the blockchain algorithms supported by the sub-domain. The second configuration information, i.e., the sub-BC enabler profile, can be used to configure a blockchain enabler module or blockchain client so that it can be invoked.
[0342] For example, the installation package for deploying blockchain capabilities on one or more of the aforementioned nodes includes a blockchain protocol and internal node processing logic. For example, the aforementioned second configuration information includes: subdomain's own capabilities and subdomain blockchain capabilities. In one possible implementation, the aforementioned second configuration information also includes the information used to indicate the number of nodes supporting blockchain capabilities within the aforementioned first subdomain. For example, the information used to indicate the number of nodes supporting blockchain capabilities within the aforementioned first subdomain includes: the number of nodes that should support blockchain capabilities within the subdomain (e.g., the first subdomain); the number of UEs that should support blockchain capabilities within the subdomain (optional); the number of base stations that should support blockchain capabilities within the subdomain (optional); and the number of NFs that should support BC capabilities within the subdomain (optional). The subdomain blockchain enabling module configuration information is used to indicate (or describe) the subdomain blockchain capability information, i.e., the blockchain algorithms supported by the subdomain. The subdomain blockchain enabling module configuration information may include the following: subdomain's own capabilities, subdomain blockchain capabilities, and subdomain node information.
[0343] For example, the capabilities of a subdomain itself may include the following:
[0344] Sub-LAF ID, which is the ID of the second node; Sub-LAF IP address, which is the IP address of the second node;
[0345] Network security capabilities include, for example, a trusted execution environment and support for privacy protection mechanisms.
[0346] For example, subdomain blockchain capabilities may include the following:
[0347] Network (i.e., subdomain network) topology: such as centralized, purely distributed, hybrid, hierarchical, etc.
[0348] Network-supported P2P protocols: For example, it supports P2P protocols based on Gossip or hash tables;
[0349] The consensus mechanism supported by the network is one of the following: PoW, PoS, DPoS, PBFT, etc.
[0350] Network-supported incentive mechanisms: for example, no incentives or incentives;
[0351] Supported wallet types: digital currency, virtual currency, etc.
[0352] Network-supported transaction / ledger formats: such as whether they are editable and whether they employ privacy protection measures;
[0353] Network-supported security algorithms: such as hash algorithms, transaction encryption algorithms, ledger encryption algorithms, etc.
[0354] Network-supported smart contracts: such as built-in smart contracts, and whether new contracts can be uploaded by developers.
[0355] For example, subdomain node information may include: node types that support blockchain capabilities (UE, base station, NF) and the number of each node type that supports blockchain capabilities.
[0356] 1303. The second node installs blockchain capabilities for one or more nodes in the first subdomain based on the subdomain blockchain capability installation request message.
[0357] Installing blockchain capabilities can be used to deploy blockchain enabling modules.
[0358] In one possible implementation, the second node determines one or more nodes within the first subdomain that need to have a blockchain enabling module installed, and sends a blockchain capability installation request message to the one or more nodes, as described in step 1202 above; the one or more nodes install the blockchain capability based on the blockchain capability installation request message, as described in step 1203 above; the one or more nodes respectively send a blockchain capability installation response message to the second node, as described in step 1204 above.
[0359] 1304. The second node sends a subdomain blockchain capability installation response message to the first node.
[0360] Accordingly, the first node receives a sub-BC enabler load response message from the second node. This message may contain the result of the second node installing the blockchain capability for one or more nodes within the first sub-domain, indicating success or failure. This result is determined based on the blockchain capability load response messages sent by one or more nodes within the first sub-domain.
[0361] In this embodiment of the application, the first node requests the installation of blockchain capabilities for one or more nodes within the first subdomain by sending a subdomain blockchain capability installation request message to the second node; blockchain capabilities can be installed for nodes within a subdomain in a telecommunications network.
[0362] Figure 14 is a flowchart of another communication method provided in an embodiment of this application. The method flow in Figure 14 is an example of the method described in Figure 11. Figure 14 is an example flow of activating the blockchain capabilities of LAF or sub-LAF nodes. As shown in Figure 14, the method includes:
[0363] 1401. The first node determines the blockchain capabilities that the second node should possess and generates blockchain enabling module configuration information.
[0364] Step 1401 is optional, and this application does not limit the way the first node obtains the blockchain enabling module configuration information. Step 1401 can be referred to as step 1201 in Figure 12.
[0365] 1402. The first node sends a blockchain enable module activation request message to the second node.
[0366] Correspondingly, the second node receives a Blockchain Enabler Enable Request (BC enable request) message from the first node. For example, the first node is an LAF or a sub-LAF, and the second node is a node (UE, base station, NF, etc.) with a deployed blockchain enabler module. The Blockchain Enabler Enable Request message is an example of the first message in Figure 11. The Blockchain Enabler Enable Request message is used to activate the blockchain capabilities of the second node in the aforementioned telecommunications network. The Blockchain Enabler Enable Request message may carry information indicating the blockchain capabilities of the second node, or in other words, it may carry information for configuring the blockchain capabilities of the second node. For example, the Blockchain Enabler Enable Request message carries Blockchain Enabler Profile information, which is used to configure the blockchain enabler module so that it can be invoked. The Blockchain Enabler Profile information carried in the Blockchain Enabler Enable Request message may be the same as the Blockchain Enabler Profile information carried in the Blockchain Enabler Installation Request message, or it may be a subset of the Blockchain Enabler Profile information carried in the Blockchain Enabler Installation Request message, i.e., only activating a portion of the blockchain capabilities. For a description of the configuration information for the blockchain enabling module, please refer to step 1202, which will not be repeated here.
[0367] 1403. The second node activates the blockchain capability based on the blockchain enablement module activation request message.
[0368] Configuring your own blockchain capabilities allows you to configure (or activate) the deployed blockchain enabling module. After the second node configures its own blockchain capabilities, the second node's blockchain capabilities become active, meaning the blockchain enabling module becomes active.
[0369] 1404. The second node sends a blockchain enable module activation response message to the first node.
[0370] Accordingly, the first node receives a Blockchain Enabler Enable Response (BC enable response) message from the second node. This message carries the result of the second node activating its own blockchain capability, indicating either success or failure.
[0371] In this embodiment, the first node requests the second node to activate its own blockchain capability by sending a blockchain enable module activation request message to the second node; the activation of the node's blockchain capability can be achieved in a telecommunications network.
[0372] Figure 15 is a flowchart of another communication method provided in an embodiment of this application. The method flow in Figure 15 is an example of the method described in Figure 11. Figure 15 is an example flow of LAF requesting a node with a blockchain enabling module to establish a blockchain. As shown in Figure 15, the method includes:
[0373] 1501. The first node determines the attributes of the blockchain to be established, generates blockchain configuration information (BC profile), and determines the nodes included in the blockchain to be established.
[0374] In one possible implementation, after the first node determines the blockchain to be established based on the requirements, it determines the attributes of the blockchain (chain type, topology, P2P protocol, consensus mechanism, incentive mechanism, wallet type, transaction ledger format, security algorithm, smart contract, trust certificate, etc.) and generates blockchain configuration information. For example, the first node (e.g., LAF) receives a request from the upper-layer service and decides to establish a blockchain, for example, containing n UEs and m base stations. For example, if the upper-layer service request declares that the blockchain should have a high security level, the LAF selects post-quantum encryption as the chain's security algorithm. If the selected UE has poor computing power, the LAF decides to set it as a client; if the selected base station has strong computing power, the LAF decides to set it as a full node. The LAF generates blockchain configuration information based on the selected blockchain capabilities and nodes and sends it to the selected n UEs and m base stations. Step 1501 is optional; the first node can obtain the blockchain configuration information through other means, which is not limited in this application.
[0375] 1502. The first node sends a blockchain establishment request message to the second node.
[0376] Correspondingly, the second node receives a blockchain setup request (BC) message from the first node.
[0377] A blockchain establishment request message is used to establish a blockchain in a telecommunications network that includes a second node. In one possible implementation, the first node sends a blockchain establishment request message to all nodes in the blockchain to be established, and the second node is one of the nodes in the blockchain to be established.
[0378] A blockchain establishment request message can be an example of the first message in Figure 11. The blockchain establishment request message carries blockchain configuration information, which is the configuration information of the blockchain including the aforementioned second node. The blockchain configuration information can be used to describe which algorithms a particular blockchain uses and related information about that blockchain. For example, the blockchain configuration information includes blockchain information and blockchain node information.
[0379] For example, blockchain information includes one or more of the following:
[0380] Chain name / ID: Used to distinguish different blockchains; a node may belong to multiple chains.
[0381] Chain types: Consortium blockchain / Public blockchain / Private blockchain;
[0382] The chain adopts the following topologies: centralized / purely distributed / hybrid / hierarchical.
[0383] The chain uses a P2P protocol, such as a Gossip-based P2P protocol or a hash table-based P2P protocol.
[0384] The consensus mechanism used by the chain is one of the following: PoW, PoS, DPoS, PBFT, etc.
[0385] The incentive mechanism used by the chain: no incentive / with incentive;
[0386] The wallet types used by the chain are: digital currency / virtual currency / walletless;
[0387] The transaction / ledger format used by the chain: for example, whether it is editable and whether it employs privacy protection;
[0388] The security algorithms used by the blockchain include hash algorithms, signature algorithms, transaction encryption algorithms, ledger encryption algorithms, etc.
[0389] The smart contracts used by the chain: such as built-in smart contracts, and whether new contracts can be uploaded by developers;
[0390] Trust credentials used by the chain: such as the chain's root certificate.
[0391] For example, blockchain node information includes one or more of the following for one or more nodes: node ID, address, type, role.
[0392] Node A: Node A ID, Node A address, Node A type, Node A role;
[0393] Node B: Node B ID, Node B address, Node B type, Node B role.
[0394] 1503. The second node is configured based on the blockchain configuration information.
[0395] In one possible implementation, the second node invokes the algorithm specified in the blockchain configuration information to run the BC enabler. If the blockchain configuration information requires the use of the Gossip protocol, then for all transactions generated by that chain, Gossip is invoked to send them to all other nodes on the same chain that can be connected. If the blockchain configuration information specifies a security algorithm, then for all transactions generated by that chain, the security algorithm is invoked for signing or encryption. After each node in the blockchain to be established by the first node performs an operation similar to step 1503, a blockchain can be established.
[0396] 1504. The second node sends a blockchain establishment response message to the first node.
[0397] Accordingly, the first node receives a blockchain setup response message from the second node. This response message can carry the result of the second node's blockchain setup, indicating whether the setup was successful or failed.
[0398] In this embodiment, the first node requests the second node to establish a blockchain by sending a blockchain establishment request message to the second node; the establishment of the blockchain can be realized in a telecommunications network.
[0399] Figure 16 is a flowchart of another communication method provided in an embodiment of this application. The method flow in Figure 16 is an example of the method described in Figure 11. Figure 16 is an example flow of LAF requesting a node with a blockchain enabling module deployed to update the blockchain. The method flow in Figure 16 can be executed after the method flow in Figure 15. As shown in Figure 16, the method includes:
[0400] 1601. The first node sends a blockchain update request message to the second node.
[0401] Correspondingly, the second node receives a Blockchain Update Request (BC) message from the first node. The BC message is used to update the blockchain in the telecommunications network that includes the second node. Alternatively, the BC message is used by the second node in the telecommunications network to update the blockchain it has joined. The BC message can be an example of the first message in Figure 11. The BC message can carry blockchain configuration information, which may include the configuration information for updating the blockchain joined by the second node. The blockchain configuration information can be used to describe which algorithms a particular blockchain uses and related information about that blockchain. For details on the blockchain configuration information, please refer to the description of the blockchain configuration information in step 1502. Before executing step 1601, the first node can perform the following operations: Based on changes in the scenario, business changes, or requirements received from upper-layer applications, the first node determines that the blockchain joined by the second node needs to be updated and generates updated blockchain configuration information.
[0402] 1602. The second node establishes a request message based on the blockchain and updates the blockchain it has joined.
[0403] The second node establishes a request message based on the blockchain, updating the blockchain it joins. This can be updating blockchain information such as the blockchain name, chain type, topology, and wallet type, or updating the node information of the blockchain it joins.
[0404] 1603. The second node sends a blockchain update response message to the first node.
[0405] Accordingly, the first node receives a Blockchain Update Response (BC) message from the second node. This BC message can carry the result of the second node updating the blockchain it joined, indicating whether the update was successful or failed.
[0406] In this embodiment, the first node requests the second node to update the blockchain by sending a blockchain update request message to the second node; the blockchain update can be implemented in a telecommunications network.
[0407] In the method flow of Figure 15, the blockchain establishment request message carries blockchain configuration information. In the method flow of Figure 16, the blockchain update request message also carries blockchain configuration information. Blockchain configuration information can also be transmitted via requests, subscriptions, and notifications. Figure 17 shows an example flow of sending blockchain configuration information via requests. The method flow of Figure 17 is an example of the method described in Figure 11. As shown in Figure 17, the method includes:
[0408] 1701. The first node sends a blockchain configuration information request message to the second node.
[0409] Accordingly, the second node receives a Blockchain Profile Request (BC) message from the first node. For example, the first node is an LAF (Local Application Framework), and the second node is a node or sub-LAF with a deployed blockchain enabling module. The BC profile request message requests configuration information for the first blockchain, and carries the name / ID of the first blockchain.
[0410] 1702. The second node sends a blockchain configuration information response message to the first node based on the blockchain configuration information request message.
[0411] Accordingly, the first node receives a Blockchain Configuration Profile (BC) response message from the second node. This response message may carry a Blockchain Configuration Profile (BC) message, which includes the configuration information of the first blockchain.
[0412] In this embodiment of the application, the first node can actively obtain the configuration information of the blockchain by sending a blockchain configuration information request message to the second node.
[0413] Figure 18 is a flowchart of another communication method provided in an embodiment of this application. The method flow in Figure 18 is an example of the method described in Figure 11. Figure 18 is an example flow of an LAF requesting a sub-LAF to establish a subdomain blockchain (i.e., a blockchain within a subdomain). As shown in Figure 18, the method includes:
[0414] 1801. The first node determines the attributes of the subdomain blockchain to be established and generates the subdomain blockchain configuration information.
[0415] One possible implementation of step 1801 is as follows: After the first node determines the subdomain blockchain to be established based on the requirements, it determines the attributes of the subdomain blockchain to be established (chain type, topology, P2P protocol, consensus mechanism, incentive mechanism, wallet type, transaction ledger format, security algorithm, smart contract, trust certificate, number of chain nodes, etc.) and generates subdomain blockchain configuration information. An example of the first node determining the subdomain blockchain to be established based on requirements is as follows: LAF receives a requirement from an upper-layer application (e.g., using blockchain to implement node authentication / resource sharing, etc.), and LAF decides to establish two blockchains in the subdomain network. The parameters of each blockchain are determined similarly to the previous process. The number of blockchain nodes can be determined by referring to the registration information of the nodes when they join the network and the node's BC enabler. Step 1801 is optional; the first node can obtain the subdomain blockchain configuration information through other means, which is not limited in this application.
[0416] 1802. The first node sends a subdomain blockchain request message to the second node.
[0417] Correspondingly, the second node receives a sub-BC request message from the first node.
[0418] Sub-Blockchain Request messages can include either a Sub-Blockchain Setup Request message or a Sub-Blockchain Update Request message.
[0419] For example, the first node is an LAF, and the second node is a sub-LAF. A subdomain blockchain request message is used to establish / update one or more blockchains within the first subdomain. Alternatively, the subdomain blockchain request message is used by the second node to establish / update one or more blockchains within the first subdomain. The first subdomain includes one or more nodes managed by the second node, and the second node is managed by the first node. For example, when the second node receives a subdomain blockchain request message for the first time (i.e., no blockchain has been established within the subdomain associated with the second node), the subdomain blockchain request message is used to establish one or more blockchains within the first subdomain, and the first message carries the configuration information of the one or more blockchains. When the second node receives a subdomain blockchain request message after the first time (i.e., a blockchain has been established within the subdomain associated with the second node), the subdomain blockchain request message is used to update one or more blockchains within the first subdomain, and the first message carries the configuration information for the update of the one or more blockchains. The subdomain blockchain request message may carry subdomain blockchain configuration information (sub-BC profile), which includes the configuration information of the one or more blockchains within the first subdomain. The subdomain blockchain request message can be an example of the first message in Figure 11. The subdomain blockchain configuration information can be used to describe information about all blockchains within the first subdomain. For example, the subdomain blockchain configuration information includes information about one or more blockchains (i.e., information about one or more blockchains) and node information for one or more blockchains, such as the number of chain nodes (or more specifically, node type-node role-number).
[0420] 1803. The second node establishes / updates the blockchain within the first subdomain based on the subdomain blockchain request message.
[0421] In one possible implementation, the second node determines the nodes included in the blockchain to be established based on the subdomain blockchain configuration information carried in the subdomain blockchain request message, and executes the blockchain building process shown in Figure 15 with these nodes.
[0422] 1804. The second node sends a subdomain blockchain response message to the first node.
[0423] Accordingly, the first node receives a sub-BC response message from the second node. This sub-BC response message can carry the result of the second node's blockchain creation, indicating whether the creation / update of the blockchain was successful or failed.
[0424] In this embodiment, the first node requests the second node to establish a blockchain by sending a subdomain blockchain request message to the second node; the establishment / updating of the blockchain within a subdomain can be realized in a telecommunications network.
[0425] In the method flow of Figure 18, the subdomain blockchain request message carries the subdomain blockchain configuration information (subBC profile). The subdomain blockchain configuration information (subBC profile) can also be sent via request, subscription, or notification. Figure 19 shows an example flow of sending subdomain blockchain configuration information via request. The method flow in Figure 19 is an example of the method described in Figure 11. As shown in Figure 19, the method includes:
[0426] 1901. The first node sends a request message for subdomain blockchain configuration information to the second node.
[0427] Correspondingly, the second node receives a sub-BC profile request message from the first node. For example, the first node is an LAF (Local Application Framework), and the second node is a sub-LAF. The sub-BC profile request message requests configuration information for blockchains within the first sub-domain managed by the second node. The message carries the ID of the first sub-domain and / or the names / IDs of multiple blockchains within that sub-domain.
[0428] 1902. The second node sends a subdomain blockchain configuration information response message to the first node based on the subdomain blockchain configuration information request message.
[0429] Accordingly, the first node receives a subdomain blockchain profile response message from the second node. This response message may carry subdomain blockchain configuration information (subBC profile). For example, when the subdomain blockchain configuration information request message carries the ID of the first subdomain, the subdomain blockchain configuration information (subBC profile) includes the configuration information of each blockchain within the first subdomain. For example, when the subdomain blockchain configuration information request message carries the name / ID of one or more blockchains within the first subdomain, the subdomain blockchain configuration information (subBC profile) includes the configuration information of those one or more blockchains.
[0430] In this embodiment of the application, the first node can actively obtain the configuration information of the blockchain within the subdomain by sending a subdomain blockchain configuration information request message to the second node.
[0431] Figures 11 to 19 above illustrate the method flow for a first node to actively send messages to a second node, which can realize at least one of the following: blockchain capability management, blockchain capability deployment, blockchain establishment, blockchain deletion, blockchain update, blockchain configuration, blockchain parameter acquisition, subdomain blockchain deployment, or subdomain blockchain configuration. The following describes the method flow for a second node to actively send messages to a first node, which can realize requesting blockchain establishment, registering blockchain capabilities, or deregistering blockchain capabilities. Figure 20 is an interactive flowchart of another communication method provided in an embodiment of this application. As shown in Figure 20, the method includes:
[0432] 2001. The second node sends a third message to the first node.
[0433] Correspondingly, the first node receives a third message from the second node. The second node is a sub-LAF or a node with a blockchain enabling module deployed, and the first node is an LAF. The third message is used to request the establishment of a blockchain, carrying blockchain service requirement parameters. Alternatively, the third message can be used to deregister the blockchain capability of the second node. Or, the third message can be used to register the blockchain capability of the second node. The protocol used by the second node to send the third message to the first node can be the same as the protocol used by the first node to send the first message to the second node in Figure 11, and will not be repeated here.
[0434] For example, when the first node is a core network element, the second node can send the third message to the first node through the first blockchain control protocol; or, when the first node is an access network device, the second node can send the third message to the first node through the second blockchain control protocol, wherein the second blockchain control protocol is different from the first blockchain control protocol.
[0435] 2002. The first node sends a fourth message to the second node based on the third message.
[0436] The fourth message is used in response to the third message mentioned above. For example, the third message is used to request the establishment of a blockchain, and the fourth message is used to instruct the first node to accept or reject the second node's request to establish a blockchain. For example, the third message is used to register the blockchain capability of the second node, and the fourth message is used to instruct the second node whether the registration of the blockchain capability was successful or failed. For example, the third message is used to deregister the blockchain capability of the second node, and the fourth message is used to instruct the second node whether the deregistration of the blockchain capability was successful or failed.
[0437] In this embodiment of the application, the second node sends a third message to the first node, which can realize the request to establish a blockchain, register a blockchain capability, or cancel a blockchain capability in a telecommunications network.
[0438] Figure 21 is a flowchart of another communication method provided in an embodiment of this application. The method flow in Figure 21 is an example of the method described in Figure 20. Figure 21 is an example flow of a second node requesting the establishment of a blockchain from a first node. As shown in Figure 21, the method includes:
[0439] 2101. The second node sends a service request message to the first node.
[0440] Correspondingly, the first node receives a service request message from the second node. This service request message is an example of the third message in Figure 20; it requests the establishment of a blockchain and carries blockchain service requirement parameters. For example, the second node is a terminal device, the first node is LAF, and the service request message in step 2101 adds the blockchain service type to the service type information element of the service request message in the NAS protocol and adds the blockchain service requirement parameters. The purpose of the NAS protocol's service request process is for the terminal device to request services from the core network.
[0441] 2102. The first node sends a service acceptance / rejection message to the second node based on the service request message.
[0442] Accordingly, the second node receives service accept / rejection messages from the first node. A service accept message indicates that the first node accepts the second node's request to establish a blockchain. A service reject message indicates that the first node rejects the second node's request to establish a blockchain.
[0443] In this embodiment of the application, the second node sends a service request message to the first node, which can request the establishment of a blockchain in the telecommunications network.
[0444] Figure 22 is a flowchart of another communication method provided in an embodiment of this application. The method flow in Figure 22 is an example of the method described in Figure 20. Figure 22 is an example flow of a second node registering blockchain capabilities. As shown in Figure 22, the method includes:
[0445] 2201. The second node sends a blockchain capability registration request message to the first node.
[0446] Accordingly, the first node receives a Blockchain Enabler Registration Request (BC enabler registration request) message from the second node. This message is used to register the blockchain capabilities of the second node. The BC enabler registration request message is an example of the third message in Figure 20. The message may carry blockchain enabler module configuration information (i.e., BC enabler profile). For details on the blockchain enabler module configuration information, please refer to the description in step 1202; it will not be repeated here.
[0447] In existing 5G networks, UEs need to register with the core network when joining the network. Similarly, in this embodiment, nodes with specific blockchain capabilities can register with LAF when joining the network. Figure 12 illustrates a method for LAF to deploy blockchain capabilities (BC enabler) to nodes, where registration involves the node sending its blockchain enabler module configuration information (i.e., BC enabler profile) to LAF. One possible scenario requiring registration is: a node's blockchain enabler module is configured by LAF1, which stores the configuration information. Subsequently, when the node leaves the network, it performs a deregistration process with LAF1; when it joins a new network, it performs a registration process with LAF2.
[0448] 2202. The first node sends a blockchain capability registration response message to the second node.
[0449] Accordingly, the second node receives a Blockchain Enabler Registration Response (BC) message from the first node. This message carries the result of the second node registering its blockchain capabilities.
[0450] In this embodiment of the application, the second node sends a blockchain capability registration request message to the first node, which can register the blockchain capability in the telecommunications network.
[0451] Figure 23 is a flowchart of another communication method provided in an embodiment of this application. The method flow in Figure 23 is an example of the method described in Figure 20. Figure 23 is an example flow of subdomain registration blockchain capability. As shown in Figure 23, the method includes:
[0452] 2301. The second node sends a subdomain blockchain capability registration request message to the first node.
[0453] Correspondingly, the first node receives a sub-BC enabler registration request message from the second node. This message is used to register the blockchain capabilities of nodes within the sub-domain managed by the second node. The sub-BC enabler registration request message is an example of the third message in Figure 20. It may carry sub-BC enabler profile configuration information. For details on sub-BC enabler profile configuration information, please refer to the description in step 1302; it will not be repeated here.
[0454] 2302. The first node sends a subdomain blockchain capability registration response message to the second node.
[0455] Accordingly, the second node receives a sub-BC enabler registration response message from the first node. This message carries the result of the second node registering the blockchain capabilities of nodes within its managed sub-domain.
[0456] In this embodiment of the application, the second node sends a subdomain blockchain capability registration request message to the first node, which can realize the registration of the blockchain capabilities of nodes within the subdomain in the telecommunications network.
[0457] Figure 24 is a flowchart of another communication method provided in an embodiment of this application. The method flow in Figure 24 is an example of the method described in Figure 20. Figure 24 is an example flow of the second node's ability to cancel the blockchain. As shown in Figure 24, the method includes:
[0458] 2401. The second node sends a blockchain capability cancellation request message to the first node.
[0459] Correspondingly, the first node receives a Blockchain Enabler Deregistration Request (BC enabler de-registration request) message from the second node. This message is used to deregister the blockchain capabilities of the second node. The BC enabler deregistration request message is an example of the third message in Figure 20. The message may carry the identification information of the second node. For details on the blockchain enabler module configuration information, please refer to the description in step 1202; it will not be repeated here.
[0460] A scenario where blockchain capabilities need to be deregistered could be: a node's blockchain enabling module is configured by LAF1, LAF1 stores the blockchain enabling module configuration information, and subsequently, the node leaves the network and performs a deregistration process with LAF1.
[0461] 2402. The first node sends a blockchain capability cancellation response message to the second node.
[0462] Accordingly, the second node receives a Blockchain Enabler Deregistration Response (BC enabler de-registration response) message from the first node. This response message carries the result of the second node deregistering its blockchain enabler.
[0463] In this embodiment of the application, the second node sends a blockchain capability cancellation request message to the first node, which can cancel the blockchain capability in the telecommunications network.
[0464] Figure 25 is an interactive flowchart of another communication method provided in an embodiment of this application. The method flowchart in Figure 25 is an example of the method described in Figure 20. Figure 25 is an example flowchart of the blockchain capability of a node within a subdomain being deregistered by a sub-LAF. As shown in Figure 25, the method includes:
[0465] 2501. The second node sends a subdomain blockchain capability cancellation request message to the first node.
[0466] Correspondingly, the first node receives a sub-BC enabler de-registration request message from the second node. The second node is a sub-LAF, and the first node is an LAF. The sub-BC enabler de-registration request message is used to deregister the blockchain capabilities of nodes within the sub-domain governed by the second node. The sub-BC enabler de-registration request message is an example of the third message in Figure 20. In one possible implementation, the sub-BC enabler de-registration request message may carry the identification information of the second node, and is used to deregister the blockchain capabilities of all nodes within the sub-domain governed by the second node. In another possible implementation, the sub-BC enabler de-registration request message may carry the identification information of the second node and the identification information of one or more nodes within the sub-domain governed by the second node, and is used to deregister the blockchain capabilities of those one or more nodes. For information on the sub-BC enabler module configuration information, please refer to the description of the sub-BC enabler module configuration information in step 1302, which will not be repeated here.
[0467] 2502. The first node sends a subdomain blockchain capability cancellation response message to the second node.
[0468] Correspondingly, the second node receives a sub-BC enabler de-registration response message from the first node. This message carries the result of the second node deregistering the blockchain capabilities of nodes within its managed sub-domain.
[0469] In this embodiment of the application, the second node sends a subdomain blockchain capability cancellation request message to the first node, which can realize the cancellation of the blockchain capability of the node in the subdomain in the telecommunications network.
[0470] Figure 9 illustrates an example of a protocol stack in a telecommunications network where nodes reuse existing protocols to implement blockchain control functions (which may include blockchain management functions). Existing protocols such as NAS, RRC, XnAP, and NGAP do not support blockchain control functions (which may include blockchain management functions). The following describes an example of modifications to the NAS, RRC, XnAP, and NGAP protocols provided in this application to enable these protocols to support blockchain control functions (which may include blockchain management functions).
[0471] The modifications to the NAS protocol are as follows:
[0472] 1) Activation of UE's blockchain capabilities
[0473] The purpose of the NAS protocol's security mode command (securitymodecommand) procedure is to determine the security algorithm used between the UE and the core network. For networks evolving after 5G, blockchain capability is one of the security technologies, and the selected security algorithm can include blockchain capability. Therefore, this application proposes to add blockchain enabler profile (BC enabler profile) to the Selected NAS security algorithms information element to enable LAF to activate the UE's blockchain capability. Figure 26 is an interactive flowchart of another communication method provided by an embodiment of this application. Figure 25 is an example flow of reusing existing protocols to implement LAF to activate the UE's blockchain capability. The method flow in Figure 26 is an example of the method described in Figure 11. As shown in Figure 26, the method includes:
[0474] 2601. LAF sends a safe mode command to UE.
[0475] Accordingly, the UE receives a security mode command from the LAF. The LAF is an example of the first node in Figure 11, and the UE is an example of the second node in Figure 11. The Selected NAS security algorithms information cell in the security mode command contains blockchain enabler profile information. This profile is used to activate the UE's blockchain capabilities.
[0476] 2602. The UE sends a security mode completion / failure message to the LAF.
[0477] Accordingly, LAF receives security mode completion / failure messages from the UE. A security mode completion message indicates that the UE has successfully activated the blockchain capability. A security mode failure message indicates that the UE has not successfully activated the blockchain capability.
[0478] In this embodiment, the existing protocol is reused to realize the blockchain capability of LAF to activate UE, which requires less network modification, has high compatibility, and low implementation complexity.
[0479] 2) UE's blockchain capability management
[0480] The purpose of the NAS protocol configuration process is to configure the capabilities of the UE. This application proposes adding blockchain configuration information, such as the transaction / ledger format, P2P protocol, consensus mechanism, and security algorithm mentioned above, to the UE's blockchain management capabilities via LAF. Figure 27 is a flowchart of another communication method provided in this application embodiment. Figure 27 is an example flow of reusing existing protocols to implement LAF's blockchain management capabilities for the UE. The method flow in Figure 27 is an example of the method described in Figure 11. As shown in Figure 27, the method includes:
[0481] 2701. The LAF sends a configuration update command to the UE.
[0482] Correspondingly, the UE receives a configuration update command from the LAF. The LAF is an example of the first node in Figure 11, and the UE is an example of the second node in Figure 11. The UE security header type information element of the configuration update command contains some or all of the blockchain configuration information (or parameters of the blockchain capability, BC enablerprofile), which is used to manage (or configure) the UE's blockchain capabilities.
[0483] 2702. The UE sends a configuration update completion message to the LAF.
[0484] Correspondingly, LAF receives a configuration update complete message from the UE. The configuration update complete message is used to instruct the UE to complete the configuration of blockchain capabilities.
[0485] In this embodiment, existing protocols are reused to implement the blockchain capabilities of LAF in managing UEs, which requires minimal network modifications, has high compatibility, and low implementation complexity.
[0486] 3) UE requests to establish a blockchain
[0487] The purpose of the NAS protocol's service request process is for the UE to request services from the core network. This application proposes adding a blockchain service type to the service type information element of the service request and adding blockchain service requirement parameters, thereby enabling the UE to request the LAF to establish a blockchain, as shown in Figure 21. The LAF blockchain establishment process can be seen in the method flow in Figure 15, where LAF is an example of the first node in Figure 15, and the UE is an example of a second node in Figure 15.
[0488] 4) Registration of UE's blockchain capabilities
[0489] The purpose of the NAS protocol's registration request process is for the UE to register with the core network upon network access. This application provides a method to add blockchain enabler profile (BCenabler profile) to the UE security capability information element of the registration request, thereby enabling the UE's blockchain capability to register with the LAF. Figure 28 is an interactive flowchart of another communication method provided in this application embodiment. Figure 28 is an example flow of reusing an existing protocol to implement the UE's blockchain capability registration with the LAF. The method flow in Figure 28 is an example of the method described in Figure 20. As shown in Figure 28, the method includes:
[0490] 2801. The UE sends a registration request to the LAF.
[0491] Accordingly, the LAF receives a registration request from the UE. The UE is an example of the second node in Figure 20, and the LAF is an example of the first node in Figure 20. The UE security capability information element in the registration request includes blockchain enabler profile information, which is used to register the UE's blockchain capabilities with the LAF.
[0492] 2802. LAF sends a registration accept / reject message to the UE.
[0493] Accordingly, the UE receives a registration acceptance / rejection message from the LAF. A registration acceptance message indicates that the LAF accepts the UE's registration, while a registration rejection message indicates that the LAF rejects the UE's registration.
[0494] In this embodiment, the existing protocol is reused to enable the UE's blockchain capabilities to register with LAF, which requires minimal network modifications, has high compatibility, and low implementation complexity.
[0495] The modifications to the RRC protocol are as follows:
[0496] 1) Activation of UE's blockchain capabilities
[0497] The security mode command (securitymodecommand) process of the RRC protocol is similar to that of NAS, and its purpose is to determine the security algorithm used between the UE and the access network. This application proposes adding some or all of the blockchain enabler profile (BC enabler profile) to the security mode command to enable the LAF in the access network to activate the UE's blockchain capability. Figure 29 is an interactive flowchart of another communication method provided in an embodiment of this application. Figure 29 is an example flow of reusing existing protocols to implement the LAF-activated UE's blockchain capability. The method flow in Figure 29 is an example of the method described in Figure 11. As shown in Figure 29, the method includes:
[0498] 2901. The access network device sends a security mode command to the UE.
[0499] Accordingly, the UE receives a security mode command from the access network device. The access network device is an example of the first node in Figure 11, and the UE is an example of the second node in Figure 11. The security mode command contains some or all of the blockchain enabler profile information, which is used to activate the UE's blockchain capabilities.
[0500] 2902. The UE sends a security mode completion / failure message to the access network device.
[0501] Accordingly, the access network device receives a security mode completion / failure message from the UE. A security mode completion message indicates that the UE has successfully activated the blockchain capability. A security mode failure message indicates that the UE has not successfully activated the blockchain capability.
[0502] In this embodiment, existing protocols are reused to activate the blockchain capability of the UE, which requires minimal network modifications, has high compatibility, and low implementation complexity.
[0503] 2) UE's blockchain capability information request
[0504] The RRC protocol's User Equipment Capability Enquiry (UECapabilityEnquiry) process involves an access network device (e.g., a base station) requesting UE capability information. This application proposes adding some or all of the Blockchain Enabler Profile (BC enabler profile) to the UE Capability Information, thereby enabling the UE to report blockchain capability information to the LAF in the access network. Figure 30 is a flowchart of another communication method provided in this application embodiment. Figure 29 is an example flow of reusing an existing protocol to implement UE reporting blockchain capability information to the LAF. The method flow in Figure 30 is an example of the method described in Figure 11. As shown in Figure 30, the method includes:
[0505] 3001. The access network device sends a user equipment capability query message to the UE.
[0506] Accordingly, the UE receives a User Equipment Capability Query message from the access network device. The access network device is an example of the first node in Figure 11, and the UE is an example of the second node in Figure 11. The User Equipment Capability Query message is used to request (or instruct) the UE to report its blockchain capability information.
[0507] 3002. The UE sends user equipment capability information to the access network equipment.
[0508] Correspondingly, the access network equipment receives user equipment capability information from the UE. The user equipment capability information (UECapabilityInformation) contains some or all of the blockchain enabler profile information, which is used by the UE to report blockchain capability information to the LAF in the access network.
[0509] In this embodiment, the existing protocol is reused to enable the UE to report blockchain capability information to LAF, which requires minimal network modification, has high compatibility, and low implementation complexity.
[0510] The modifications to the NGAP protocol are as follows:
[0511] 1) Blockchain capability configuration for access network devices
[0512] The purpose of the NGAP protocol's NG reset (RESET) procedure is to configure the interface. This application proposes adding blockchain capability parameters, such as the transaction / ledger format, P2P protocol, consensus mechanism, and security algorithm mentioned above, to the NG reset message to enable LAF to configure the blockchain capabilities of access network devices. Figure 31 is a flowchart of another communication method provided in this application embodiment. Figure 31 is an example flow of reusing existing protocols to implement blockchain capability configuration of access network devices. The method flow in Figure 31 is an example of the method described in Figure 11. As shown in Figure 31, the method includes:
[0513] 3101. LAF sends an NG reset message to the access network equipment.
[0514] Accordingly, the LAF receives NG reset messages from the access network device. The LAF is an example of the first node in Figure 11, and the access network device is an example of the second node in Figure 11. The NG reset message is used for the blockchain capability configuration of the access network device. The NG reset message contains blockchain capability parameters (or blockchain capability parameters). For example, the NG reset message contains some or all of the blockchain enabler profile (BC enabler profile).
[0515] 3102. The access network device sends an NG reset feedback message to the LAF.
[0516] Correspondingly, LAF receives NG reset acknowledge messages from the access network devices. NG reset acknowledge messages indicate whether the access network devices have successfully or unsuccessfully configured blockchain capabilities.
[0517] In this embodiment, existing protocols are reused to configure the blockchain capabilities of access network devices, which requires minimal network modifications, has high compatibility, and low implementation complexity.
[0518] 2) Registration of blockchain capabilities for access network devices
[0519] The purpose of the NGAP protocol's NG setup request process is to establish an interface so that access network devices can send information to the core network. This application proposes adding blockchain enabler profile (BC enabler profile) information to the NG setup request message to enable the access network device's blockchain capabilities to register with the LAF in the core network. Figure 32 is a flowchart of another communication method provided in this application embodiment. Figure 32 is an example flow of reusing existing protocols to implement the registration of the access network device's blockchain capabilities with the LAF in the core network. The method flow in Figure 32 is an example of the method described in Figure 20. As shown in Figure 32, the method includes:
[0520] 3201. The access network device sends an NG configuration request message to the LAF.
[0521] Accordingly, the LAF receives NG setup request messages from the access network devices. The access network device is an example of the second node in Figure 20, and the LAF is an example of the first node in Figure 20. The NG setup request message includes blockchain enabler profile information, which is used by the access network device to register its blockchain capabilities with the LAF in the core network.
[0522] 3202. LAF sends NG setup response / failure messages to the access network equipment.
[0523] Accordingly, the access network device receives NG setup response / failure messages from LAF. An NG setup response message indicates that the access network device has successfully registered its blockchain capability. An NG setup failure message indicates that the access network device has failed to register its blockchain capability.
[0524] In this embodiment, existing protocols are reused to enable the blockchain capabilities of access network devices to register with LAF in the core network. This requires minimal network modification, has high compatibility, and low implementation complexity.
[0525] 3) Notification of blockchain capabilities of access network devices
[0526] The purpose of the RAN configuration update process in the NGAP protocol is for access network devices (e.g., base stations) to inform the core network of their updated information. This application proposes adding blockchain enabler profile (BC) information to the RAN configuration update message to enable access network devices to inform (or notify) access network devices that have deployed LAF (Local Area Function). Figure 33 is a flowchart of another communication method provided in this application embodiment. Figure 33 is an example flow of reusing existing protocols to inform the core network LAF of the access network device's blockchain capabilities. The method flow in Figure 33 is an example of the method described in Figure 20. As shown in Figure 33, the method includes:
[0527] 3301. The access network device sends a RAN configuration update message to the LAF.
[0528] Accordingly, the LAF receives RAN configuration update messages from the access network devices. The access network device is an example of the second node in Figure 20, and the LAF is an example of the first node in Figure 20. The RAN configuration update message includes blockchain enabler profile information, which is used to inform the LAF of the access network device's blockchain capabilities.
[0529] 3302. LAF sends RAN configuration update feedback messages to access network devices.
[0530] Correspondingly, the access network device receives a RAN configuration update feedback message from the LAF. The RAN configuration update feedback message is used to indicate to the LAF that it has received the RAN configuration update feedback message sent by the access network device.
[0531] In this embodiment, existing protocols are reused to enable the access network device's blockchain capability to notify the LAF in the core network. This requires minimal network modification, has high compatibility, and low implementation complexity.
[0532] The XnAP protocol was modified as follows:
[0533] 1) Registration of blockchain capabilities for access network devices
[0534] The purpose of the XnAP protocol's Xn setup request process is to establish an interface, allowing one access network device to send its own information to another. This application proposes adding blockchain enabler profile (BC) information to the Xn setup request message to enable the access network device's blockchain capabilities to register with the LAF in the access network. Figure 34 is a flowchart of another communication method provided in this application embodiment. Figure 34 is an example flow of reusing existing protocols to register the access network device's blockchain capabilities with the LAF in the core network. The method flow in Figure 34 is an example of the method described in Figure 20. As shown in Figure 34, the method includes:
[0535] 3401. The first access network device sends an Xn setting request message to the second access network device.
[0536] Correspondingly, the second access network device receives an Xn setup request message from the first access network device. The first access network device is an example of the second node in Figure 20, and the second access network device is an example of the first node in Figure 20; that is, the second access network device deploys LAF. The Xn setup request message is used to register the first access network device's blockchain capabilities with the LAF in the access network. The Xn setup request message may include blockchain enabler profile (BC enabler profile).
[0537] 3402. The second access network device sends an Xn setting response / failure message to the first access network device.
[0538] Accordingly, the first access network device receives an Xn setup response / failure message from the second access network device. The Xn setup response message indicates at least that the first access network device has successfully registered its blockchain capability. The Xn setup failure message indicates that registration has failed.
[0539] In this embodiment, existing protocols are reused to enable the blockchain capabilities of access network devices to register with LAF in the access network. This requires minimal network modification, has high compatibility, and low implementation complexity.
[0540] 2) Notification of blockchain capability information for access network devices
[0541] The purpose of the NG-RAN node configuration update process in the XnAP protocol is for access network devices to inform other access network devices of their updated information. This application proposes adding blockchain enabler profile (BC) information to the NG-RAN node configuration update message to enable access network devices to inform the LAF (Local Access Provider) of their blockchain capabilities. Figure 35 is a flowchart of another communication method provided in this embodiment. Figure 35 is an example flow of reusing an existing protocol to inform the LAF of the access network device's blockchain capabilities. The method flow in Figure 35 is an example of the method described in Figure 20. As shown in Figure 35, the method includes:
[0542] 3501. The first access network device sends an NG-RAN node configuration update message to the second access network device.
[0543] Correspondingly, the second access network device receives an NG-RAN node configuration update message from the first access network device. The first access network device is an example of the second node in Figure 20, and the second access network device is an example of the first node in Figure 20; that is, the second access network device deploys a Blockchain Enabler (LAF). The NG-RAN node configuration update message is used to inform the LAF in the access network of the access network device's blockchain capability information. The NG-RAN node configuration update message may include blockchain enabler profile (BC enabler profile).
[0544] 3502. The second access network device sends an NG-RAN node configuration update feedback message to the first access network device.
[0545] Correspondingly, the first access network device receives an NG-RAN node configuration update acknowledge message from the second access network device. The NG-RAN node configuration update acknowledge message indicates that the second access network device has received an NG-RAN node configuration update message from the first access network device.
[0546] In this embodiment, existing protocols are reused to inform the LAF in the core network of the blockchain capability information of the access network device. This requires minimal network modification, has high compatibility, and low implementation complexity.
[0547] In addition, other blockchain functions such as: creating, deleting, and updating chains; BC configuration; requesting, subscribing to, and notifying about blockchain configuration information (BC profile); and requesting, subscribing to, and notifying about blockchain enabler module configuration information (BC enabler profile) require the addition of new signaling procedures.
[0548] The structure of a communication device that can implement the communication method provided in the embodiments of this application is described below with reference to the accompanying drawings. Only a brief description of the communication device is given below; for details of the implementation, please refer to the description of the method embodiments above, which will not be repeated hereafter.
[0549] Figure 36 is a schematic diagram of the structure of a communication device 3600 provided in an embodiment of this application. The communication device 3600 can correspondingly implement the functions or steps implemented by the first node in the above-described method embodiments, and can also correspondingly implement the functions or steps implemented by the second node in the above-described method embodiments. The communication device may include a processing module 3610 and a transceiver module 3620. In one possible implementation, a storage unit may also be included, which can be used to store instructions (code or program) and / or data. The processing module 3610 and the transceiver module 3620 can be coupled to the storage unit. For example, the processing module 3610 can read the instructions (code or program) and / or data in the storage unit to implement the corresponding method. The above-described units can be set independently, or partially or completely integrated. For example, the transceiver module 3620 may include a transmitting module and a receiving module. The transmitting module can be a transmitter, and the receiving module can be a receiver. The entity corresponding to the transceiver module 3620 can be a transceiver circuit, such as a transceiver or a communication interface.
[0550] In some possible implementations, the communication device 3600 can correspondingly implement the behavior and functions of the first node in the above method embodiments. For example, the communication device 3600 can be the first node, or it can be a component (e.g., a chip or circuit) applied in the first node. The transceiver module 3620 can, for example, be used to perform all the receive or send operations performed by the first node in the embodiments of FIG11 to FIG25. The processing module 3610 can, for example, be used to perform all the operations performed by the first node in the embodiments of FIG11 to FIG25 except for the receive and send operations.
[0551] In some possible implementations, the communication device 3600 can correspondingly implement the behavior and functions of the second node in the above method embodiments. For example, the communication device 3600 can be the second node, or it can be a component (e.g., a chip or circuit) applied in the second node. The transceiver module 3620 can, for example, be used to perform all the receive or send operations performed by the second node in the embodiments of FIG11 to FIG25. The processing module 3610 can, for example, be used to perform all the operations performed by the second node in the embodiments of FIG11 to FIG25 except for the receive and send operations.
[0552] Figure 37 is a schematic diagram of another device 370 provided in an embodiment of this application. The device in Figure 37 can be the first node or a chip used for the first node, or it can be the second node or a chip used for the second node. As shown in Figure 37, the device 370 includes a processing circuit 3710 and a transceiver circuit 3720.
[0553] In some embodiments of this application, the processing circuit 3710 and the transceiver circuit 3720 can be used to perform functions or operations performed by the first node. For example, the transceiver circuit 3720 is used to perform all the receive or transmit operations performed by the first node in the embodiments of Figures 11 to 25. For example, the processing circuit 3710 is used to perform all operations performed by the first node in the embodiments of Figures 11 to 25, except for the receive and transmit operations.
[0554] In some embodiments of this application, the processing circuit 3710 and the transceiver circuit 3720 can be used to perform functions or operations performed by the second node. For example, the transceiver circuit 3720 is used to perform all the receive or send operations performed by the second node in the embodiments of Figures 11 to 25. For example, the processing circuit 3710 is used to perform all operations performed by the second node in the embodiments of Figures 11 to 25, except for the receive and send operations.
[0555] In one possible implementation, the transceiver circuit 3720 includes at least one transceiver, and the processing circuit 3710 includes at least one processor, or at least one processor with circuitry for processing or control.
[0556] A transceiver is used for communication with other devices / appliances via a transmission medium. The processor utilizes the transceiver to send and receive data and / or signaling, and to implement the methods described in the above-described method embodiments. The processor can implement the functions of processing module 3610, and the transceiver can implement the functions of transceiver module 3620. Optionally, the transceiver may include radio frequency (RF) circuitry and an antenna. The RF circuitry is mainly used for converting baseband signals to RF signals and processing RF signals. The antenna is mainly used for sending and receiving RF signals in the form of electromagnetic waves. Input / output devices, such as touchscreens, displays, and keyboards, are mainly used for receiving user input data and outputting data to the user.
[0557] Optionally, device 370 may further include at least one memory for storing program instructions and / or data. The memory and processor are coupled. The coupling in this embodiment is an indirect coupling or communication connection between devices, units, or modules, which may be electrical, mechanical, or other forms, for information exchange between devices, units, or modules. The processor may operate in conjunction with the memory. The processor may execute program instructions stored in the memory. At least one of the at least one memory may be included in the processor.
[0558] The processor can read software programs from memory, interpret and execute the instructions of the software programs, and process the data of the software programs. When data needs to be transmitted wirelessly, the processor performs baseband processing on the data to be transmitted and outputs the baseband signal to the radio frequency (RF) circuit. The RF circuit then processes the baseband signal and transmits the RF signal outward in the form of electromagnetic waves through the antenna. When data is sent to device 370, the RF circuit receives the RF signal through the antenna, converts the RF signal into a baseband signal, and outputs the baseband signal to the processor. The processor converts the baseband signal back into data and processes the data.
[0559] In another implementation, the aforementioned radio frequency circuitry and antenna can be set up independently of the processor performing baseband processing. For example, in a distributed scenario, the radio frequency circuitry and antenna can be arranged remotely, independent of device 370.
[0560] The specific connection medium between the transceiver, processor, and memory described above is not limited in the embodiments of this application.
[0561] In the embodiments of this application, the processor can be one of the following devices: a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component, or all or part of the circuitry in the aforementioned devices used for processing functions. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or being executed by a combination of hardware and software modules within the processor.
[0562] In one possible implementation, the processing circuit 3710 includes at least one logic circuit, and the transceiver circuit 3720 includes at least one interface. The processing module 3610 in Figure 36 can be implemented using logic circuits, and the transceiver module 3620 in Figure 36 can be implemented using an interface. The logic circuit can be a chip, processing circuit, integrated circuit, or system-on-chip (SoC) chip, etc., and the interface can be a communication interface, input / output interface, etc. In this embodiment, the logic circuit and the interface can also be coupled to each other. The specific connection method of the logic circuit and the interface is not limited in this embodiment.
[0563] This application also provides a computer-readable storage medium storing a computer program or instructions that, when run on a computer, cause the computer to perform the methods of the above embodiments.
[0564] This application also provides a computer program product, which includes instructions or a computer program that, when run on a computer, causes the methods in the above embodiments to be executed.
[0565] This application also provides a communication system, including the first node and the second node described above.
[0566] This application also provides a chip, which includes: a communication interface and a processor; the communication interface is used for signal transmission and reception of the chip; the processor is used to execute computer program instructions, causing a communication device including the chip to perform the methods as described in the above embodiments.
[0567] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented, in whole or in part, as a computer program product. The aforementioned computer program product includes one or more computer programs or instructions. When the aforementioned computer program or instructions are loaded and executed on a computer, the processes or functions described in the embodiments of this application are performed, in whole or in part. The aforementioned computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment, or other programmable device. The aforementioned computer program or instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, the aforementioned computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The aforementioned computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center integrating one or more available media. The aforementioned available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; it can also be an optical medium, such as a digital video optical disc; or it can be a semiconductor medium, such as a solid-state drive. The computer-readable storage medium may be a volatile or non-volatile storage medium, or may include both types of storage media.
[0568] In the various embodiments of this application, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions of different embodiments are consistent and can be referenced by each other. The technical features of different embodiments can be combined to form new embodiments according to their inherent logical relationship.
Claims
A communication method characterized by comprising: The method is applied to a first node in a telecommunications network, and the method includes: Send a first message, which is used for at least one of the following: blockchain capability management, blockchain capability deployment, blockchain client management, blockchain client deployment, blockchain creation, blockchain deletion, blockchain update, blockchain configuration, blockchain parameter acquisition, subdomain blockchain deployment, or subdomain blockchain configuration. Receive a second message, which is used in response to the first message. The method of claim 1, wherein The first message used for managing blockchain capabilities includes: The first message is used for at least one of the following: deletion, activation, update, locking, or closure of blockchain capabilities. The method according to claim 2, characterized in that The first message used for activating blockchain capabilities includes: The first message is used to activate the blockchain capability of the second node in the telecommunications network, and the first message carries information for indicating the blockchain capability of the second node; Alternatively, the first message may be used to activate the blockchain capabilities of one or more nodes within a first subdomain, the first subdomain including one or more nodes managed by a second node, the second node being managed by the first node, the first message carrying information indicating the blockchain capabilities of the one or more nodes, and information indicating the number of nodes within the first subdomain that support blockchain capabilities. The method according to any one of claims 1 to 3, characterized in that The first message used for deploying blockchain capabilities includes: The first message is used to deploy the blockchain capability of the second node in the telecommunications network. The first message carries an installation package for deploying the blockchain capability of the second node and first configuration information, which is used to indicate the blockchain capability of the second node. Alternatively, the first message is used to deploy blockchain capabilities of one or more nodes within a first subdomain, the first subdomain including one or more nodes managed by a second node, the second node being managed by the first node, the first message carrying an installation package for deploying blockchain capabilities on the one or more nodes, second configuration information, and information for indicating the number of nodes supporting blockchain capabilities within the first subdomain, the second configuration information being used to indicate the blockchain capabilities of the one or more nodes. The method according to any one of claims 1 to 4, characterized in that The first message is used to establish a blockchain in the telecommunications network that includes a second node, and the first message carries configuration information of the blockchain that includes the second node; Alternatively, the first message may be used to establish one or more blockchains within a first subdomain, the first subdomain including one or more nodes managed by a second node, the second node being managed by the first node, and the first message carrying configuration information of the one or more blockchains. The method according to any one of claims 1 to 5, characterized in that The first message is used for updating the blockchain of the telecommunications network that includes the second node, and the first message carries configuration information including the blockchain update of the second node; Alternatively, the first message may be used for updating one or more blockchains within a first subdomain, the first subdomain including one or more nodes managed by a second node, the second node being managed by the first node, and the first message carrying configuration information for the one or more blockchain updates. The method according to any one of claims 1 to 6, characterized in that The first message used for blockchain configuration includes: The first message is used for configuring the blockchain connection, which includes at least one of the following: configuring the blockchain connection method, configuring the blockchain network topology, and configuring the blockchain node list. The method according to any one of claims 1 to 7, characterized in that The first message used for blockchain configuration includes: The first message is used for configuring the blockchain node, and the configuration of the blockchain node includes at least one of the following: configuring blockchain node attributes, configuring blockchain node roles, or configuring blockchain node running status. The method according to any one of claims 1 to 8, characterized in that The first message used to obtain blockchain parameters includes: The first message is used to request at least one of the following: requesting blockchain configuration information, subscribing to blockchain configuration information, requesting blockchain identifier, requesting blockchain type, requesting blockchain capability information, or subscribing to blockchain capability information. The method according to any one of claims 1 to 9, characterized in that Sending the first message includes: The first node sends the first message to the second node via a non-access stratum protocol. The first node is a core network element, and the second node is a terminal device. Alternatively, the first node sends the first message to the second node via the Radio Resource Control Protocol, where the first node is an access network device and the second node is a terminal device; Alternatively, the first node sends the first message to the second node through a next-generation application protocol, where the first node is a core network element and the second node is an access network device; Alternatively, the first node may send the first message to the second node through the Xn interface application process protocol, wherein the first node and the second node are different access network devices. The method according to any one of claims 1 to 9, characterized in that Sending the first message includes: The first node sends the first message through a blockchain control protocol, which can be a protocol between different core network elements, or a protocol between a core network element and a terminal device, or a protocol between a core network element and an access network device, or a protocol between an access network device and a terminal device, or a protocol between different access network devices. The method of claim 11, wherein The blockchain control protocol is located above the second protocol layer, which includes some or all of the following protocol layers: a protocol layer for data packet processing, a protocol layer for transmission, a protocol layer for establishing connections, and a protocol layer for establishing channels. The method according to any one of claims 1 to 9, characterized in that When the second node is a terminal device, sending the first message includes: When the first node is a core network element, the first message is sent to the second node through the first blockchain control protocol; Alternatively, when the first node is an access network device, the first message is sent to the second node through a second blockchain control protocol, which is different from the first blockchain control protocol. The method according to any one of claims 1 to 13, characterized in that The method further includes: Receive a third message, the third message being used to request the establishment of a blockchain, the third message carrying blockchain service requirement parameters, or, the third message being used to deregister the blockchain capability of the second node, or, the third message being used to register the blockchain capability of the second node; A fourth message is sent in response to the third message. A communication method characterized by comprising: The method is applied to a second node in a telecommunications network, and the method includes: Receive a first message, which is used for at least one of the following: blockchain capability management, blockchain capability deployment, blockchain client management, blockchain client deployment, blockchain establishment, blockchain deletion, blockchain update, blockchain configuration, blockchain parameter acquisition, subdomain blockchain deployment, or subdomain blockchain configuration. Send a second message, which is a response to the first message. The method of claim 15, wherein The first message used for managing blockchain capabilities includes: The first message is used for at least one of the following: deletion, activation, update, locking, or closure of blockchain capabilities. The method of claim 16, wherein The first message used for activating blockchain capabilities includes: The first message is used to activate the blockchain capability of the second node in the telecommunications network, and the first message carries information for indicating the blockchain capability of the second node; Alternatively, the first message may be used to activate the blockchain capabilities of one or more nodes within a first subdomain, the first subdomain including one or more nodes managed by a second node, the second node being managed by the first node, the first message carrying information indicating the blockchain capabilities of the one or more nodes, and information indicating the number of nodes within the first subdomain that support blockchain capabilities. The method according to any one of claims 15-17, characterized in that The first message used for deploying blockchain capabilities includes: The first message is used to deploy the blockchain capability of the second node in the telecommunications network. The first message carries an installation package for deploying the blockchain capability of the second node and first configuration information, which is used to indicate the blockchain capability of the second node. Alternatively, the first message is used to deploy blockchain capabilities of one or more nodes within a first subdomain, the first subdomain including one or more nodes managed by a second node, the second node being managed by the first node, the first message carrying an installation package for deploying blockchain capabilities on the one or more nodes, second configuration information, and information for indicating the number of nodes supporting blockchain capabilities within the first subdomain, the second configuration information being used to indicate the blockchain capabilities of the one or more nodes. The method according to any one of claims 15-18, characterized in that The first message is used to establish a blockchain within the telecommunications network, and the first message carries configuration information of the blockchain including the second node; Alternatively, the first message may be used to establish one or more blockchains within a first subdomain, the first subdomain including one or more nodes managed by a second node, the second node being managed by the first node, and the first message carrying configuration information of the one or more blockchains. The method according to any one of claims 15-19, characterized in that The first message is used for updating the blockchain of the telecommunications network that includes the second node, and the first message carries configuration information including the blockchain update of the second node; Alternatively, the first message may be used for updating one or more blockchains within a first subdomain, the first subdomain including one or more nodes managed by a second node, the second node being managed by the first node, and the first message carrying configuration information for the one or more blockchain updates. The method according to any one of claims 15-20, characterized in that The first message used for blockchain configuration includes: The first message is used for configuring the blockchain connection, which includes configuring the blockchain connection method and the blockchain network. At least one of the following: network topology configuration and blockchain node list configuration. The method according to any one of claims 15-21, characterized in that The first message used for blockchain configuration includes: The first message is used for configuring the blockchain node, and the configuration of the blockchain node includes at least one of the following: configuring blockchain node attributes, configuring blockchain node roles, or configuring blockchain node running status. The method according to any one of claims 15-22, characterized in that The first message used to obtain blockchain parameters includes: The first message is used to request at least one of the following: requesting blockchain configuration information, subscribing to blockchain configuration information, requesting blockchain identifier, requesting blockchain type, requesting blockchain capability information, or subscribing to blockchain capability information. The method according to any one of claims 15 to 23, characterized in that The receipt of the first message includes: The second node receives the first message from the first node via a non-access stratum protocol. The first node is an access network device, and the second node is a terminal device. Alternatively, the first node receives the first message from the second node via the Radio Resource Control Protocol, where the first node is an access network device and the second node is a terminal device; Alternatively, the first node receives the first message from the first node via a next-generation application protocol, where the first node is a core network element and the second node is an access network device; Alternatively, the first node receives the first message from the second node through the Xn interface application process protocol, wherein the first node and the second node are different access network devices. The method according to any one of claims 15 to 23, characterized in that The receipt of the first message includes: The second node receives the first message through a blockchain control protocol, which can be a protocol between different core network elements, or a protocol between a core network element and a terminal device, or a protocol between a core network element and an access network device, or a protocol between an access network device and a terminal device, or a protocol between different access network devices. The method of claim 25, wherein The blockchain control protocol is located above the second protocol layer, which includes some or all of the following protocol layers: a protocol layer for data packet processing, a protocol layer for transmission, a protocol layer for establishing connections, and a protocol layer for establishing channels. The method according to any one of claims 15 to 23, characterized in that The receipt of the first message includes: The second node receives the first message from the first node through the first blockchain control protocol. The second node is a terminal device, and the first node is a core network element. Alternatively, the second node receives the first message from the first node through a second blockchain control protocol, where the second node is a terminal device, the first node is an access network device, and the second blockchain control protocol is different from the first blockchain control protocol. The method according to any one of claims 15 to 27, characterized in that The method further includes: Send a third message, which is used to request the establishment of a blockchain and carries blockchain service requirement parameters; or, the third message is used to deregister the blockchain capability of the second node; or, the third message is used to register the blockchain capability of the second node. A communication method characterized by comprising: The method is applied to a second node in a telecommunications network, and the method includes: Send a third message, which is used to request the establishment of a blockchain and carries blockchain service requirement parameters; or, the third message is used to cancel the blockchain capability of the second node; or, the third message is used to register the blockchain capability of the second node. A fourth message is received, which is used in response to the third message. The method of claim 29, wherein The sending of the third message includes: The second node sends the third message to the first node via a non-access stratum protocol. The second node is a terminal device, and the first node is a core network element. Alternatively, the second node sends the third message to the first node via the Radio Resource Control Protocol, where the second node is a terminal device and the first node is an access network device; Alternatively, the second node sends the third message to the first node via a next-generation application protocol, where the second node is an access network device and the first node is an access network device. Alternatively, the second node may send the third message to the first node via the Xn interface application process protocol, wherein the second node and the first node are different access network devices. The method of claim 29, wherein The sending of the third message includes: The second node sends the third message via a blockchain control protocol, wherein the blockchain control protocol is a protocol between different core network elements, or a protocol between a core network element and a terminal device, or a blockchain control protocol for core network elements. The blockchain control protocol is a protocol between the network elements and the access network devices, or it is a protocol between the access network devices and the terminal devices, or it is a protocol between different access network devices. The method of claim 31, wherein The blockchain control protocol is located above the second protocol layer, which includes some or all of the following protocol layers: a protocol layer for data packet processing, a protocol layer for transmission, a protocol layer for establishing connections, and a protocol layer for establishing channels. The method of claim 29, wherein The sending of the third message includes: When the first node is a core network element, the second node sends the third message to the first node through the first blockchain control protocol; Alternatively, when the first node is an access network device, the second node sends the third message to the first node through a second blockchain control protocol, which is different from the first blockchain control protocol. A communication method characterized by comprising: The method is applied to a first node in a telecommunications network, and the method includes: Receive a third message, the third message being used to request the establishment of a blockchain, the third message carrying blockchain service requirement parameters, or, the third message being used to deregister the blockchain capability of the second node, or, the third message being used to register the blockchain capability of the second node; A fourth message is sent in response to the third message. The method of claim 34, wherein The receipt of the third message includes: The first node receives the third message from the second node via a non-access stratum protocol, where the second node is a terminal device and the first node is a core network element. Alternatively, the second node receives the third message from the second node via the Radio Resource Control Protocol, where the second node is a terminal device and the first node is an access network device; Alternatively, the second node receives the third message from the second node via a next-generation application protocol, where the second node is an access network device and the first node is an access network device; Alternatively, the second node receives the third message from the first node via the Xn interface application process protocol, wherein the second node and the first node are different access network devices. The method of claim 34, wherein The receipt of the third message includes: The first node receives the third message through a blockchain control protocol, which is a protocol between different core network elements, or a protocol between a core network element and a terminal device, or a protocol between a core network element and an access network device, or a protocol between an access network device and a terminal device, or a protocol between different access network devices. The method of claim 36, wherein The blockchain control protocol is located above the second protocol layer, which includes some or all of the following protocol layers: a protocol layer for data packet processing, a protocol layer for transmission, a protocol layer for establishing connections, and a protocol layer for establishing channels. The method according to claim 35 or 36, characterized in that The receipt of the third message includes: When the first node is a core network element, the first node receives the third message through the first blockchain control protocol; Alternatively, when the first node is an access network device, the first node receives the third message through a second blockchain control protocol, which is different from the first blockchain control protocol. The method according to any one of claims 34 to 38, characterized in that The first node is an access network device; after receiving the third message, the method further includes: When the first node has blockchain capabilities and deploys blockchain control functions, it parses the third message. The blockchain control functions are functions for managing and / or configuring the blockchain. Alternatively, when the first node has blockchain capabilities but has not deployed blockchain control functions, the third message is forwarded to the third node to which the first node belongs, and the third node has deployed the blockchain control functions. Alternatively, when the first node does not have blockchain capabilities, the third message can be forwarded to a node that has the blockchain control function deployed. A communication device, characterized by Includes modules or units for implementing the method of any one of claims 1 to 14 or any one of claims 34 to 39. A communication device, characterized by Includes modules or units for implementing the method of any one of claims 15 to 33. A computer-readable storage medium, characterized by, The computer-readable storage medium stores a computer program, the computer program including program instructions that, when executed by a processor, cause the method of any one of claims 1 to 39 to be performed. A communication device characterized by comprising: Includes a processor, which, when executing instructions, causes the communication device to perform the method as described in any one of claims 1 to 39. A computer program product, characterized by The computer program product includes a computer program, the computer program including program instructions that, when executed, cause the computer to perform the method as described in any one of claims 1 to 39. A chip characterized by include: A communication interface is used for signal transmission and reception of the chip. A processor for executing computer program instructions, causing a communication device including the chip to perform the method as described in any one of claims 1 to 39. A communication system characterized by It includes the communication device as described in claim 40 and the communication device as described in claim 41.