Communication method and communication device

Abstract

The invention discloses a communication method and a communication device, and relates to the technical field of communication. The method comprises the steps that a first node sends first request information, and the first request information comprises identification information of a first distributed account book and identification information of a second distributed account book and is used for requesting to join the second distributed account book; and the first node receives first response information, wherein the first response information indicates whether the first node is allowed to join the second distributed account book or not. By implementing the embodiment of the invention, the process of adding and exiting the distributed account book by the node can be simplified, the node is supported to flexibly add into the target distributed account book and exit from the source distributed account book, and the resource utilization rate of the node and the distributed account book is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of communication, and more particularly, to a communication method and a communication device. BACKGROUND

[0002] A distributed ledger (DL) is a database shared, replicated and synchronized among network members. The distributed ledger can record transactions between network participants, such as exchange of assets or data. In essence, the distributed ledger is a shared database, and the data or information stored therein has the characteristics of "unforgeable", "full trace", "traceable", "transparent", "collectively maintained", etc.

[0003] Some mainstream distributed ledgers at present, such as Bitcoin and Fabric, all use a hard-coded method to execute the process of adding a new node to the distributed ledger. For example, the new node inquires a hard-coded address, and obtains the addresses of all nodes in the distributed ledger according to the hard-coded address, and all nodes in the distributed ledger determine whether to accept the new node to join the distributed ledger. However, the above method is not flexible, and the node cannot dynamically join the distributed ledger on demand.

[0004] Therefore, how to simplify the process of adding and exiting the distributed ledger by the node with flexibility, and improve the resource utilization of the node and the distributed ledger are technical problems to be solved at present. SUMMARY

[0005] The present application provides a communication method and a communication device, which can support the node to flexibly apply to join the distributed ledger, simplify the process of adding and exiting the distributed ledger by the node, and improve the resource utilization of the node and the distributed ledger.

[0006] In a first aspect, a communication method is provided, comprising: sending first request information, the first request information being used for a first node to request to join a second distributed ledger, the first request information indicating identification information of a first distributed ledger to which the first node belongs and identification information of the second distributed ledger; and receiving first response information, the first response information being used for responding to the first request information, the first response information indicating whether the first node is allowed to join the second distributed ledger.

[0007] The execution subject of the scheme in the first aspect can be the first communication device, where the first communication device can be a first node, or a module, circuit or chip (such as a Modem chip, also known as a baseband chip, or a system on chip (SoC) chip or a system in package (SIP) chip containing a Modem core) in the first node, or a logical node, logical module or software capable of realizing all or part of the functions of the first node, which is not limited. For ease of description, the first node is described below as an example.

[0008] In the above scheme, when the first node wants to join the second distributed ledger, the first node sends first request information to the second node, which indicates the identity information of the first distributed ledger to which the first node belongs and the identity information of the second distributed ledger that the first node wants to join. The second node determines whether to allow the first node to join the second distributed ledger based on the configuration information corresponding to the two distributed ledgers, and sends response information indicating whether to allow the first node to join the second distributed ledger.

[0009] Optionally, the first response information is used to respond to the first request information, which can be understood as: the first response information is used to indicate whether to allow the first node to join the second distributed ledger, for example, the first response information is used to indicate that the first node is allowed to join the second distributed ledger, or the first response information is used to indicate that the first node is not allowed to join the second distributed ledger, and the like. It should be understood that the second distributed ledger can represent one or multiple, that is, the first node can simultaneously apply to join multiple distributed ledgers according to actual needs, which is not limited in the present application.

[0010] Through the above interaction process, the first node and the second node can interact the first distributed ledger identity information to which the first node belongs and the identity information of the second distributed ledger, the second node compares the configuration information of the first distributed ledger and the configuration information of the second distributed ledger, and determines whether to allow the first node to join the request of the second distributed ledger according to the comparison result. In this way, the embodiments of the present application can support the first node to more flexibly apply to join the target distributed ledger, simplify the process of the first node to join the second distributed ledger, and improve the resource utilization rate of the node and the distributed ledger.

[0011] In some implementations of the first aspect, the first response information indicates that the first node is allowed to join the second distributed ledger, and the first response information further indicates the identity information of the second distributed ledger.

[0012] When the first node is allowed to join the second distributed ledger, the second distributed ledger is indicated by the identification information, so that the first node determines the corresponding target distributed ledger, thereby correctly executing the subsequent process of joining the second distributed ledger.

[0013] In some implementations of the first aspect, the first response information further indicates at least one of: a permission of the first node in the second distributed ledger, configuration information of the second distributed ledger, or indication information, the configuration information of the second distributed ledger being used by the first node to communicate with other nodes contained in the second distributed ledger after joining the second distributed ledger, and the indication information being used to indicate that attribute information in the configuration information of the second distributed ledger is the same as attribute information in the configuration information of the first distributed ledger.

[0014] When the first node is allowed to join the second distributed ledger, the first node can perform corresponding functions in the second distributed ledger according to the permission of the first node in the second distributed ledger. In this way, this can support the first node to more targetedly perform business or functions or participate in the second distributed ledger. Moreover, this can improve the operation efficiency of the first distributed ledger, for example, only nodes with consensus permission participate in consensus, and nodes without consensus permission do not participate in consensus, which can shorten the time occupied by consensus and save resources; only nodes with ledger storage permission save the ledger, which can save storage resources, etc.

[0015] In addition, by indicating the configuration information of the second distributed ledger or the indication information, the first node can correctly join the second distributed ledger according to the configuration information of the second distributed ledger.

[0016] In some implementations of the first aspect, before receiving the first response information, the method further comprises: obtaining distributed ledger information, the distributed ledger information comprising identification information of one or more distributed ledgers and node information contained in the one or more distributed ledgers, the distributed ledgers comprising the first distributed ledger and the second distributed ledger, and the node information comprising addresses of one or more nodes.

[0017] The first node obtains the distributed ledger information in advance, so as to determine the identification information of the target distributed ledger to be joined and the node to be interacted with. The node can be any one of the node list of the second distributed ledger, or a node that has a telecommunication connection with the first node, so that the first node can correctly interact with the target distributed ledger.

[0018] In some implementations of the first aspect, the distributed ledger information further comprises attribute information in the configuration information of the second distributed ledger, and the attribute information in the configuration information comprises at least one of: a consensus mechanism, a security algorithm, or a ledger technology.

[0019] In this way, the first node extracts the configuration information of the second distributed ledger, and then can directly join the second distributed ledger according to the configuration information of the second distributed ledger, so that subsequent interaction of the second node with the configuration information of the second distributed ledger can be avoided, transmission resources are saved, the interaction process is simplified, and the efficiency of the first node joining the second distributed ledger is improved.

[0020] In some implementations of the first aspect, the first response information further indicates that the first distributed ledger maintains the connection with the first node, and the first response information further indicates the identification information of the first distributed ledger.

[0021] For the connection between the first distributed ledger and the first node, the first distributed ledger is also given a certain decision-making right. The first distributed ledger can decide whether to maintain the connection according to actual conditions, such as the number of nodes or the privacy of ledger data, so as to expand the application scenarios and ensure that the related business of the first distributed ledger can operate normally.

[0022] In some implementations of the first aspect, the first request information and the first response information are information transmitted between a terminal-side device and a network-side device; or the first request information and the first response information are information transmitted between network-side devices.

[0023] When the first request information and the first response information are information transmitted between devices in a communication network, the embodiments of the present application can support the introduction or application of distributed ledger technology in the communication network.

[0024] In some implementations of the first aspect, the method further includes: sending second indication information, the second indication information indicating that the first node exits the first distributed ledger, and the second indication information indicating the identification information of the first distributed ledger; or receiving third indication information, the third indication information indicating that the first node exits the first distributed ledger, and the third indication information indicating the identification information of the first distributed ledger.

[0025] In a second aspect, a communication method is provided, including: receiving first request information, the first request information being used for a first node to request to join a second distributed ledger, the first request information indicating identification information of a first distributed ledger to which the first node belongs and identification information of the second distributed ledger; and sending first response information, the first response information being used for responding to the first request information, and the first response information indicating whether the first node is allowed to join the second distributed ledger.

[0026] The execution subject of the scheme in the second aspect can be a second communication device, which can be a second node, a module, a circuit or a chip (such as a Modem chip, also known as a baseband chip, or a SoC chip or a SIP chip containing a Modem core) in the second node, and can also be a logical node, a logical module or software capable of realizing all or part of the functions of the second node, which is not limited. For ease of description, the second node is described below as an example.

[0027] The specific description can refer to the description of the beneficial effects of the first aspect, which will not be repeated.

[0028] In some implementations of the second aspect, before sending the first response information, the method further includes: obtaining configuration information of the first distributed ledger and configuration information of the second distributed ledger, and determining the first response information based on the configuration information of the first distributed ledger and the configuration information of the second distributed ledger.

[0029] In some implementations of the second aspect, if the attribute information in the configuration information of the first distributed ledger is the same as the attribute information in the configuration information of the second distributed ledger, or if the attribute information in the configuration information of the first distributed ledger includes all the attribute information in the configuration information of the second distributed ledger, the second node determines the first response information, and the first response information indicates that the first node is allowed to join the second distributed ledger, and the attribute information includes at least one of the following: a security algorithm, a consensus mechanism or a ledger technology.

[0030] The second node directly obtains a comparison result by comparing the configuration information of the first distributed ledger and the second distributed ledger, and then directly determines whether to allow the first node to join the second distributed ledger according to the comparison result, which is simple to implement and can effectively simplify the process of the first node joining the second distributed ledger and improve performance.

[0031] In some implementations of the second aspect, the first response information indicates that the first node is allowed to join the second distributed ledger, and the first response information further indicates identification information of the second distributed ledger.

[0032] In some implementations of the second aspect, the first response information further indicates at least one of the following: a permission of the first node in the second distributed ledger, configuration information of the second distributed ledger, or indication information, the configuration information of the second distributed ledger being used for the first node to join the second distributed ledger and communicate with other nodes contained in the second distributed ledger, and the indication information being used to indicate that the attribute information in the configuration information of the second distributed ledger is the same as the attribute information in the configuration information of the first distributed ledger.

[0033] In some implementations of the second aspect, the second node sends second request information, the second request information being used to request configuration information of the first distributed ledger, the second request information further indicating the identity information of the first distributed ledger and the first node identity information; receives second response information, the second response information being used to respond to the second request information, the second response information further indicating the configuration information of the first distributed ledger.

[0034] In the above scheme, when the second node cannot directly obtain the configuration information of the first distributed ledger, the second node can obtain the configuration information of the first distributed ledger by sending a request and receiving a response to other nodes connected thereto belonging to the first distributed ledger or managing the first distributed ledger, and then make an accurate judgment on whether to allow the first node to join the second distributed ledger.

[0035] In some implementations of the second aspect, the second response information further indicates the authority of the first node in the first distributed ledger.

[0036] In some implementations of the second aspect, the second response information further indicates whether the first distributed ledger continues to maintain a connection with the first node, the second response information further indicates the identity information of the first distributed ledger, and the second response information is related to the first response information.

[0037] In the above scheme, the second node can also obtain whether the first distributed ledger continues to maintain a connection with the first node by sending a request and receiving a response, that is, the first distributed ledger has a certain decision-making right and can independently decide whether to continue to maintain a connection, which can ensure that in some extreme cases, for example, the number of nodes in the first distributed ledger is less than a threshold, the first distributed ledger will maintain a connection with the first node, and ensure that the business can still run normally.

[0038] In some implementations of the second aspect, before sending the first response information, the second node sends third request information, the third request information being used to determine whether to allow the first node to join the second distributed ledger, the third request information further indicating the identity information of the first node and the identity information of the second distributed ledger; receives third response information, the third response information being used to respond to the third request information and being used to determine the first response information.

[0039] In the above scheme, the second node, without belonging to the second distributed ledger, can forward the request information sent by the first node to other nodes connected thereto belonging to the second distributed ledger or managing the second distributed ledger, and the other nodes can make a judgment and generate the third response information, and the second node can determine the first response information according to the third response information and send the first response information to the first node to indicate whether to allow the first node to join the second distributed ledger.

[0040] Through the above process, the embodiment of the application can support the first node to establish a connection with other nodes belonging to the second distributed ledger through the second node, and determine whether to allow the first node to join the second distributed ledger.

[0041] In some implementations of the second aspect, the third request information further includes configuration information of the first distributed ledger and a right of the first node in the first distributed ledger.

[0042] In some implementations of the second aspect, the third response information indicates that the first node is allowed to join the second distributed ledger, and the third response information further indicates identification information of the second distributed ledger and identification information of the first node.

[0043] In some implementations of the second aspect, the third response information further indicates at least one of the following: a right of the first node in the second distributed ledger, configuration information of the second distributed ledger, or indication information, the configuration information of the second distributed ledger being used for the first node to join the second distributed ledger and communicate with other nodes contained in the second distributed ledger, and the indication information being used to indicate that the configuration information of the second distributed ledger is the same as the configuration information of the first distributed ledger.

[0044] In some implementations of the second aspect, the first response information further indicates whether the first distributed ledger continues to maintain a connection with the first node, and the first response information further indicates identification information of the first distributed ledger.

[0045] In some implementations of the second aspect, the first request information and the first response information are information transmitted between a terminal-side device and a network-side device; or the first request information and the first response information are information transmitted between network-side devices.

[0046] In some implementations of the second aspect, when the first response information indicates that the first node is allowed to join the second distributed ledger, the second node updates a node list of the second distributed ledger, and the updated node list contains the first node.

[0047] In some implementations of the second aspect, the second node determines that the first node exits the first distributed ledger, and updates a node list of the first distributed ledger, and the updated node list does not contain the first node.

[0048] In a third aspect, a communication device is provided, which can be a first node, or a device or a module for executing a function of the first node.

[0049] In a possible implementation, the communication apparatus can include a module or unit corresponding to each of the methods / operations / steps / actions described in the first aspect, which can be a hardware circuit, software, or a combination of hardware circuit and software.

[0050] In a fourth aspect, a communication apparatus is provided, which can be a second node, or a device or module for performing the functions of the second node.

[0051] In a possible implementation, the communication apparatus can include a module or unit corresponding to each of the methods / operations / steps / actions described in the second aspect, which can be a hardware circuit, software, or a combination of hardware circuit and software.

[0052] In a fifth aspect, a communication apparatus is provided, which includes a processor configured to cause the communication apparatus to perform the methods described in the first aspect and any possible implementation of the first aspect, or to perform the methods described in the second aspect and any possible implementation of the second aspect, by executing computer programs or instructions, or by a logic circuit.

[0053] In a possible implementation, the communication apparatus further includes a memory configured to store the computer programs or instructions.

[0054] Optionally, the memory and the processor are integrated.

[0055] In a possible implementation, the communication apparatus further includes a communication interface configured to input and / or output signals.

[0056] In a sixth aspect, a communication apparatus is provided, which includes a logic circuit and an input / output interface configured to input and / or output signals, and the logic circuit is configured to perform the methods described in the first aspect and any possible implementation of the first aspect, or to perform the methods described in the second aspect and any possible implementation of the second aspect.

[0057] In a seventh aspect, a computer readable storage medium is provided, which stores computer programs or instructions, and when the computer programs or the instructions are run on a computer, the methods described in the first aspect and any possible implementation of the first aspect are performed, or the methods described in the second aspect and any possible implementation of the second aspect are performed.

[0058] In an eighth aspect, a computer program product is provided, comprising instructions which, when executed on a computer, cause the method according to the first aspect and any possible implementation of the first aspect to be performed; or cause the method according to the second aspect and any possible implementation of the second aspect to be performed.

[0059] In a ninth aspect, a chip system is provided, comprising: a processor configured to execute a computer program or instructions in the memory, so that the chip system implements the method according to the first aspect and any possible implementation of the first aspect; or so that the chip system implements the method according to the second aspect and any possible implementation of the second aspect.

[0060] The description of the beneficial effects of any of the third aspect to the ninth aspect can refer to the description of the beneficial effects of the first aspect to the second aspect, and will not be repeated. BRIEF DESCRIPTION OF DRAWINGS

[0061] Figure 1 is a schematic diagram of a network architecture 100 to which embodiments of the present application are applicable.

[0062] Figure 2 is a schematic diagram of a distributed ledger anchoring function layer 200 of embodiments of the present application.

[0063] Figure 3 is a schematic diagram of another network architecture 300 to which embodiments of the present application are applicable.

[0064] Figure 4 is a schematic diagram of a communication system 400 to which embodiments of the present application are applicable.

[0065] Figure 5 is a schematic diagram of an interaction flow of a communication method of embodiments of the present application.

[0066] Figure 6 is a schematic diagram of an interaction flow of another communication method of embodiments of the present application.

[0067] Figure 7 is a schematic diagram of an interaction flow of another communication method of embodiments of the present application.

[0068] Figure 8 is a schematic diagram of an interaction flow of another communication method of embodiments of the present application.

[0069] Figure 9 is a schematic diagram of an interaction flow of another communication method of embodiments of the present application.

[0070] Figure 10 is a schematic diagram of an interaction flow of another communication method of embodiments of the present application.

[0071] Figure 11is an interaction flow diagram of another communication method of an embodiment of the present application.

[0072] Figure 12 is a schematic block diagram of a communication device 1200 of an embodiment of the present application.

[0073] Figure 13 is a schematic block diagram of a communication device 1300 of an embodiment of the present application. DETAILED DESCRIPTION

[0074] In order to facilitate understanding of the embodiments of the present application, the following points are first explained.

[0075] I. Unless otherwise stated, the meaning of "a plurality of or at least two" is two or more.

[0076] II. If there is no special description and no logical conflict, the terms and / or descriptions between different embodiments are consistent and can be referred to each other, and the technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationship.

[0077] III. The various digital numbers involved in the embodiments of the present application are only used for differentiation for the convenience of description, and do not limit the protection scope of the present application. The size of the serial numbers involved in the present application does not mean the execution order, and the execution order of each process should be determined according to its function and inherent logic. For example, the terms "first", "second", "third", "fourth" and other various term labels in the specification and claims of the present application and the drawings (if any) are used to distinguish similar objects, and do not have to be used to describe a specific order or sequence. Among them, the data thus used can be interchanged under appropriate circumstances, so that the embodiments described herein can be implemented in an order other than that illustrated or described herein.

[0078] At the same time, any embodiment or design scheme described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as more preferred or more advantageous than other embodiments or design schemes. Rather, the use of "exemplary" or "for example" is intended to present the relevant concept in a specific manner for ease of understanding.

[0079] IV. The terms "include" and "have" 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 does not have to be limited to those steps or units clearly listed, but can include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0080] Five, in the embodiments of the present application, "for indicating" can be understood as "enabling", and "enabling" can include direct enabling and indirect enabling. When describing that a certain information is used to enable A, it can include that the information directly enables A or indirectly enables A, and it does not mean that A is necessarily carried in the information.

[0081] The information enabled by the information is referred to as to-be-enabled information, and in the specific implementation process, there are many ways to enable the to-be-enabled information, for example, but not limited to, the to-be-enabled information can be directly enabled, such as the to-be-enabled information itself or an index of the to-be-enabled information. The to-be-enabled information can also be indirectly enabled by enabling other information, where the other information and the to-be-enabled information have an association relationship. The to-be-enabled information can also be enabled only in part, and the other part of the to-be-enabled information is known or agreed in advance. For example, the enabling of a specific information can also be achieved by means of the arrangement order of each information agreed in advance (for example, a protocol stipulates), thereby reducing the enabling overhead to a certain extent. At the same time, the common part of each information can also be identified and uniformly enabled to reduce the enabling overhead caused by separately enabling the same information.

[0082] Six, the "storage" or "saving" involved in the embodiments of the present application can mean saving in one or more memories. The one or more memories can be separately arranged or integrated in the encoder or decoder, processor, or communication device. The one or more memories can also be partially separately arranged and partially integrated in the decoder, processor, or communication device. The type of memory can be any form of storage medium, which is not limited.

[0083] Seven, the "protocol" involved in the embodiments of the present application can mean a standard protocol in the communication field, which can include, for example, a fourth generation (4th generation, 4G) communication network, a fifth generation (5th generation, 5G) communication network protocol, a new radio (new radio, NR) protocol, a 5.5G communication network protocol, and a related protocol applied to a future communication system, which is not limited in the present application.

[0084] Eight, the arrows or blocks shown by the dashed lines in the schematic diagrams in the drawing part of the present application specification represent optional steps or optional modules.

[0085] Nine, in the embodiments of the present application, unless otherwise specified, " / " represents that the objects associated before and after are in an "or" relationship, for example, A / B can represent A or B; "and / or" in the present application is only a description of the association relationship of the associated objects, which means that there can be three kinds of relationships, for example, A and / or B, which can represent: A exists alone, A and B exist together, and B exists alone, where A and B can be singular or plural.

[0086] Ten, in embodiments of the present application, indication includes direct indication (also known as explicit indication) and implicit indication. Direct indication of information A means that information A is included. Implicit indication of information A means that information A is indicated by the correspondence between information A and information B and direct indication of information B. The correspondence between information A and information B can be predefined, pre-stored, pre-burned, or pre-configured.

[0087] Eleven, in embodiments of the present application, information C used for determination of information D includes that information D is determined based on information C only, and includes that information D is determined based on information C and other information. In addition, information C used for determination of information D can also include the case of indirect determination, such as the case that information D is determined based on information E, and information E is determined based on information C.

[0088] Twelve, in embodiments of the present application, "apparatus A sends information A to apparatus B" can be understood as that the destination of the information A or the intermediate network element in the transmission path between the destination is apparatus B, which can include direct or indirect sending of information to apparatus B.

[0089] Thirteen, in embodiments of the present application, "apparatus B receives information A from apparatus A" can be understood as that the source of the information A or the intermediate network element in the transmission path between the source is apparatus A, which can include direct or indirect receiving of information from apparatus A. The information can be processed as necessary between the source and the destination of the information sending, for example, format change, etc., but the destination can understand the valid information from the source. Similar expressions in the present application can be understood similarly, which will not be described here.

[0090] Figure 1 is a schematic diagram of a network architecture 100 applicable to embodiments of the present application. The network architecture 100 includes one or more distributed ledger anchor function (DLAF) network elements (one is shown), one or more terminals (one is shown) deployed with a distributed ledger enabler (DLE) or a distributed ledger client (DL client), one or more (radio, R) access network (AN) devices (one is shown) deployed with a distributed ledger enabler or a distributed ledger client, one or more user plane functions (UPF) (one is shown), and a data network (DN).

[0091] Optionally, the network architecture can further include a DLE or a DL client as a standalone core network network function, and / or one or more core network network functions (NFs) deployed with the DLE or the DL client. The DLE as a standalone core network network function can provide distributed ledger agent services for other network functions. The DL client as a standalone core network network function can provide transaction proposal services for other network function network elements.

[0092] The NF network element described above can include network elements in existing standards, such as an access and mobility function management network element (AMF) and a session management function network element (SMF), and can also include network elements newly defined in future standards, etc., which are not limited. The AMF and the SMF can have other names in networks evolved after 5G, which are not limited in the present application. In addition, the embodiments of the present application do not specially limit the DN.

[0093] Figure 1 The number of each type of network element and terminal in the illustrated network architecture is not limited. Figure 1 The illustrated network architecture can be one example of a network architecture of a communication system evolved after 5G, Figure 1 Only part of the network architecture is shown. In this document, the DLE can be replaced by a distributed ledger capability. The core network network element deployed with the DLE can be referred to as a core network network element with (or supporting) distributed ledger capability. The terminal deployed with the DLE can be referred to as a terminal with (or supporting) distributed ledger capability. The access network device deployed with the DLE can be referred to as an access network device with (or supporting) distributed ledger capability. Among them, the distributed ledger can also be a blockchain or a distributed database or other types of databases, etc., which are not limited.

[0094] The DLAF is an anchor point for the overall management and association of the distributed ledger, and performs functions such as management of the distributed ledger, registration management of the distributed ledger capability, creation of the distributed ledger, activation of the distributed ledger capability, access control to the distributed ledger, etc. The DLAF is generally deployed in the core network in the form of a network function, and can also have a hierarchical structure, for example, a sub DLAF (sub LAF) is deployed in the access network, and the sub DLAF is managed by the DLAF. In this document, the DLAF can be a core network network element or an access network device, and the DLAF hereinafter refers to a core network network element or an access network device deployed with the DLAF.

[0095] The DLE in the telecommunications network accepts the configuration and management of the DLAF, or the node (including the UE, the access network device, and the core network element) deployed with the DLE accepts the configuration and management of the DLAF, or the node (including the UE, the access network device, and the core network element) with the distributed ledger capability accepts the configuration and management of the DLAF.

[0096] In the embodiments of the present application, different node types (i.e., node types on the distributed ledger) can be distinguished according to the capabilities of the nodes. The node deployed with the DLE 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, and the like. The DLE exists in various nodes in the telecommunications network, including the UE, the access network device (e.g., the base station), and the core network element. That is, the node that needs to have the distributed ledger capability can deploy the DLE. It should be noted that the DLE can not be a physical module (or a hardware entity), and the nodes in the telecommunications network can install (or deploy) the DLE through the mirror code installation package of the DLE. For example, the core network element deployed with the DLE can also serve as an independent network function to provide the distributed ledger proxy capability for other core network elements.

[0097] The DL client accepts the configuration and management of the DLAF, performs the generation and transmission of the distributed ledger transaction, or the node (including the UE, the access network device, and the core network element) deployed with the DL client accepts the configuration and management of the DLAF. The DL client exists in various nodes in the telecommunications network, including the UE, the access network device (e.g., the base station), and the core network element. It should be noted that the DL client can not be a physical module (or a hardware entity), and the nodes in the telecommunications network can install (or deploy) the DL client through the mirror code installation package of the DL client. For example, the core network element deployed with the DL client can also serve as an independent network function to provide the transaction proposal service for other core network elements.

[0098] In a possible implementation manner, part of the DLAF is deployed in the core network, and the other part of the DLAF is deployed in the access network. The DLAF deployed in the access network can be named as a sub DLAF (sub DLAF), and the DLAF deployed in the core network can manage and configure the sub DLAF. The DLAF can be a core network element in the core network, and the sub DLAF can be an access network device in the access network.

[0099] When a DLAF is deployed in an access network, it exhibits a hierarchical structure. The DLAF deployed in the core network is at a higher level and can manage and configure lower-level sub-DLAFs (such as those in the access network). A sub-DLAF can manage and configure the DLE and / or DL ​​client of the access network nodes it connects to, as well as the DLE and / or DL ​​client of the terminal devices. The access network nodes and terminal devices governed (or managed) by the sub-DLAF are called its "subdomain," or the subdomain associated with it. A subdomain can refer to all nodes (including terminal devices and access network devices) with deployed DLE and / or DL ​​clients governed by the sub-DLAF. A single DLAF can have one or more nodes (access network devices or terminal devices) with deployed DLE and / or DL ​​clients, and can also have one or more subdomains; it can also have one or more nodes with deployed DLE and / or DL ​​clients and one or more subdomains. For example, after setting up a subdomain, the DLAF does not directly manage the nodes in the subdomain that have DLE and / or DL ​​client deployed, nor does it need to know their specific information. It only needs to issue instructions to the sub-DLAF on a per-subdomain basis, which can reduce the workload of the DLAF.

[0100] Figure 2 This is a schematic diagram of the distributed ledger anchoring function layer 200 in an embodiment of this application. Figure 2 The example shown can be Figure 1 A portion of it (not shown). For example... Figure 2 As shown, the DLAF in the core network (CN) has one node with DLE deployed, one node with DL client deployed, and a sub-DLAF 1 (i.e., Figure 2 sub DLAF1) and sub DLAF2 (i.e. Figure 2sub DLAF 1 governs sub-domain 1, and sub-domain 1 includes multiple nodes (only three are shown, each of which is deployed with DLE#1, DLE#2 and DL client#1), sub DLAF 2 governs sub-domain 2, and sub-domain 2 includes multiple nodes (only three are shown, each of which is deployed with DLE#3, DLE#4 and DL client#2). The nodes in a sub-domain can be access network devices or terminal devices. For example, a sub-domain includes multiple access network devices governed by a sub-DLAF and multiple terminal devices that access the core network through the access network devices in the sub-domain. For another example, a sub-domain includes multiple integrated access and backhaul (IAB) nodes governed by a sub-DLAF and multiple terminal devices that access the core network through the IAB nodes in the sub-domain. A sub-domain can exist in the following cases: super cell, one access network device (e.g., a base station) deploys a DLAF to manage multiple access network devices; in a possible implementation, the access network can have a hierarchical architecture, that is, there are multiple layers of DLAFs in the access network, and a DLAF at a higher layer can manage and configure a DLAF at a lower layer.

[0101] Figure 3 is another network architecture 300 to which the embodiments of the present application are applicable. The network architecture 300 includes one or more DLAF network elements (two are shown, DLAF1 and DLAF2), and one or more nodes deployed with DLE or DL client. Among them, DLE0 and DLE1 belong to the same distributed ledger (i.e., DL1), and all nodes in DL1 accept the configuration and management of DLAF1; DLE2 belongs to another distributed ledger (i.e., DL2), and all nodes in DL2 accept the configuration and management of DLAF2. There can be an inherent telecommunication network connection between DLE nodes of different DLs, for example, DLE1 and DLE2 are connected through a telecommunication network, which can be a connection between UEs, base stations, and NFs. DLEs in the same distributed ledger can not only establish a telecommunication network connection, but also a peer-to-peer (P2P) connection, for example, DLE0 and DLE1 establish a P2P connection, and can transmit data, transactions, blocks, etc. of the distributed ledger based on the connection. When DLE0 successfully joins DL2, a P2P connection will also be established between DLE0 and DLE2.

[0102] Figure 3 The number of each type of network element and terminal in the network architecture shown is not limited, Figure 3 only part of the network elements in the network architecture are shown. It should be noted that, Figure 3The shown DL1 and DL2 belong to DLAF1 and DLAF2 management and control respectively, in another possible scenario, DL1 and DL2 can belong to the same DLAF management and control, for example, belong to DLAF1 or DLAF2 management and control at the same time. In addition, DLAF1 and DLAF2 can be different network domains of the same operator, or belong to different operators, which is not limited, the connection between DLAFs is the connection between core network elements, for example, the connection between NFs, cross-operator connection, that is, the connection between DLAF1 and DLAF2 through a security edge protection proxy (SEPP).

[0103] In a possible implementation, the initial state is that DLE0 is in DL1, and DLE1 is connected, and DLE1 and DLE2 have an existing connection, which can be a telecommunication network connection, and there can also be a connection between DLE0 and DLE2, which can be a telecommunication network connection, but when DLE0 moves (for example, DLE2 broadcasts DLE2 identification information (ID), DL2 ID, and DLE0 receives and judges that the signal strength of DLE2 is greater than a preset threshold), the demand of DLE0 changes (for example, DL2 has stronger capability than DL1, or DL2 has more node quantity, the operator network to which it belongs is more reliable, the consensus is faster, etc.), the home organization of DLE0 changes (for example, the operator A to which DL1 belongs shares base stations, network equipment, etc. with the operator B to which DL2 belongs, and needs all DLE nodes contained in DL1 to join the DL2 corresponding to the operator B), at this time, DLE0 can join DL2 through DLE1 or DLE2, and optionally exit DL1, and after DLE0 successfully joins DL2, a higher layer connection (that is, a P2P connection) will be established between DLE0 and DLE2.

[0104] In the embodiments of the present application, the terminal equipment can 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 device, user agent or user device.

[0105] The terminal device can be a device that provides a wireless communication function, for example, a handheld device with a wireless connection function, a vehicle-mounted device, and the like. Currently, some examples of terminal devices are: a mobile phone, a satellite mobile terminal, a cellular phone, a smart phone, a tablet computer, a notebook computer, a palm computer, a mobile internet device (MID), a wearable device (for example, a smart watch, a smart bracelet, a pedometer, smart glasses, and the like), a vehicle-mounted device (for example, a car, a bicycle, an electric vehicle, an airplane, a ship, a train, a high-speed rail, and the like), a satellite terminal, a virtual reality (VR) device, an augmented reality (AR) device, a smart point of sale (POS) machine, a customer-premises equipment (CPE), a light user equipment (light UE), a reduced capability UE (REDCAP UE), a wireless terminal in industrial control, a wireless terminal in self driving, a wireless terminal in remote medical surgery, a wireless terminal in a smart grid, a wireless terminal in transportation safety, a wireless terminal in a smart city, a wireless terminal in a smart home (for example, a refrigerator, a television, an air conditioner, an electricity meter, and the like), a smart robot, a mechanical arm, a cellular phone, a cordless phone, a session initiation protocol (SIP) phone, a wireless local loop (WLL) station, a personal digital assistant (PDA), a handheld device with a wireless communication function, a computing device, or another processing device connected to a wireless modem, a flight device (for example, a smart robot, a hot air balloon, a drone, an airplane), a terminal device in a 5G network, or a terminal device in a future evolved public land mobile network (PLMN), and the like, and the present embodiments are not limited thereto.The terminal device can also be a vehicle device, such as a whole vehicle device, a vehicle-mounted module, a vehicle-mounted chip, an on board unit (OBU), a telematics box (T-BOX), or the like. As an example but not limitation, in the embodiments of the present application, the terminal device can also be a mobile termination (MT) in an IAB node. When the IAB node faces its parent node, it can be regarded as a terminal device, at this time, the IAB node plays the role of MT.

[0106] In the embodiments of the present application, the device for implementing the function of the terminal device can be a terminal device, or a device capable of supporting the terminal device to implement the function, such as a chip system, which can be installed in the terminal device or used in matching with the terminal device. In the embodiments of the present application, the chip system can be composed of a chip, or can include a chip and other discrete devices. In the embodiments of the present application, only the device for implementing the function of the terminal device is taken as an example for description, and the scheme of the embodiments of the present application is not limited.

[0107] The access network device in the embodiments of the present application can be a device for communicating with the terminal device, and the access network device can also be referred to as a network device or a radio access network device. The access network device in the embodiments of the present application can refer to a radio access network (RAN) node (or device) for accessing the terminal device to a wireless network.

[0108] In a possible scenario, the access network device 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 base station in a future mobile communication system, a satellite, or an access point (AP) in a WiFi system, an integrated access and backhaul (IAB) node, an access network device in a non-terrestrial network (NTN) communication system, i.e., can be deployed in a high-altitude platform or a satellite, etc. The access network device can be a macro base station, a micro base station, or an indoor station, a relay node or a donor node, or a wireless controller in a cloud radio access network (CRAN) scenario. The access network device can also be a device assuming a base station function in device to device (D2D) communication, vehicle-to-everything (V2X) communication, unmanned aerial vehicle (UAV) communication, or machine communication. Alternatively, the access network device can also be a server, a wearable device, a vehicle or a vehicle-mounted device, etc. For example, the access network device in V2X technology can be a road side unit (RSU). An IAB node integrates a mobile termination (MT) and a distributed unit (DU). When the IAB node faces its parent node, it can be regarded as a terminal, at this time, the IAB node plays the role of the MT; when the IAB node faces its child node (the child node can be a terminal or an MT of another IAB node), the IAB node can be regarded as an access network device. An IAB node can establish a backhaul connection between the MT part and at least one parent node of the IAB node. The DU part of an IAB node can provide access services for the MT part of a terminal or another IAB node.

[0109] In another possible scenario, multiple access network devices collaborate to assist terminals in achieving wireless access, with each device performing 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.

[0110] 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.

[0111] To address the technical problems described in the background section, this application provides a communication method and a communication device that can simplify the process of nodes joining and leaving a distributed ledger, thereby improving the resource utilization of nodes, i.e., the distributed ledger.

[0112] For ease of description and understanding, the following text will describe communication systems, communication methods, and communication devices.

[0113] I. Communication System

[0114] Figure 4This is a schematic diagram of a communication system 400 to which this application embodiment applies. The communication system 400 includes: a first node and a second node, as well as a first distributed ledger and a second distributed ledger, wherein the first distributed ledger includes the first node, and the second distributed ledger includes at least one node. Optionally, the first distributed ledger and the second distributed ledger may further include more nodes.

[0115] In the communication system 400, the first node and the second node are nodes that support the distributed ledger function, or in other words, the first node and the second node can be nodes that have deployed DLE or DLC.

[0116] One possible implementation is that the first node can be DLE and the second node can also be DLE; or, the first node can be DLE and the second node can be DLAF, etc.

[0117] Another possible implementation is that the first node and the second node are terminals with DLE or DLclient deployed; or, the first node and the second node are access network devices with DLE or DLclient deployed; or, the first node and the second node are NFs with DLE or DLclient deployed; or, the first node and the second node are respectively terminals and access network devices with DLE or DLclient deployed, etc., which are not limited.

[0118] The second distributed ledger can be a distributed ledger that the first node is allowed to join or that the first node wants to join. For ease of description, the following description will use the example of allowing the first node to join the second distributed ledger.

[0119] The first node is the node that applies to join the second distributed ledger. The second node is a node related to whether the first node is allowed to join the second distributed ledger. Alternatively, the second node is a node with the function or ability to judge or determine whether the first node is allowed to join the second distributed ledger.

[0120] An example:

[0121] The first node requests to join the second distributed ledger. The second node is either a trusted node or a regular node in the second distributed ledger. The second node determines whether to allow the first node to join the second distributed ledger.

[0122] Another example:

[0123] The first node requests to join the second distributed ledger. The second node manages one or more distributed ledgers (such as DLAF), which include the second distributed ledger. The second node determines whether to allow the first node to join the second distributed ledger.

[0124] When a first node is allowed to join a second distributed ledger, for example, the attribute information in the configuration information of the first distributed ledger is the same as the attribute information in the configuration information of the second distributed ledger. For example, the consensus mechanism, security algorithm, ledger technology supported by the first and second distributed ledgers are the same, or the attribute information in the configuration information of the first distributed ledger includes all the attribute information in the configuration information of the second distributed ledger, that is, the range of the attribute information in the configuration information of the first distributed ledger is greater than the range of the attribute information in the configuration information of the second distributed ledger.

[0125] There is a connection between the first node and the second node. For example, the first node is directly connected to the second node, or the first node establishes a connection with the second node through another node (taking the third node as an example). The first node and the third node can belong to the same distributed ledger, i.e., the first distributed ledger. Alternatively, the third node may not belong to any distributed ledger, but it and the first node are nodes of the same operator, and the first node can establish a connection and communicate with the second node through the third node.

[0126] When the first node connects to the second node through the third node, the third node can maintain a list of distributed ledgers, which includes one or more distributed ledgers. Based on this list, the third node forwards information from the first node regarding a request to join the second distributed ledger to the second node, which is a node in the second distributed ledger.

[0127] When a first node wants to join the second distributed ledger, it sends a request message to the second node. This request message includes or indicates the identification information of the first and second distributed ledgers to which the first node belongs. Based on the identification information of the first and second distributed ledgers sent by the first node, the second node obtains the configuration information of both the first and second distributed ledgers. Then, based on this configuration information, it determines whether to allow the first node to join the second distributed ledger and sends a response message to the first node indicating whether joining the second distributed ledger is permitted.

[0128] In summary, the first node and the second node can exchange the identification information of the source distributed ledger (first distributed ledger) and the target distributed ledger (second distributed ledger). The second node obtains the corresponding configuration information based on the identification information of the source and target distributed ledgers, and determines whether to allow the first node's request to join the target distributed ledger based on the obtained configuration information. Through the above process, the embodiments of this application can support the first node to join the target distributed ledger more flexibly, and simplify the process of the first node leaving the source distributed ledger and joining the target distributed ledger.

[0129] 2. Communication method

[0130] For ease of understanding and explanation, the communication method of this application embodiment is described below using the interaction between the first node and the second node as an example, but this should not limit the subject executing the communication method. For example, the method executed by a node (such as the first node and / or the second node) can also be executed by a module of that node (such as a circuit, chip, or chip system), or can be implemented by a logic node, logic module, or software that can implement all or part of the functions of that node.

[0131] Figure 5 This is a schematic diagram of the interaction flow of the communication method according to an embodiment of this application. For example... Figure 5 As shown, the communication methods include:

[0132] S501, The first node sends a first request message to the second node. Correspondingly, the second node receives the first request message.

[0133] The first request information is used by a first node to request joining a second distributed ledger. The first request information indicates the identification information of the first distributed ledger to which the first node belongs, and the identification information of the second distributed ledger. Specifically, the first request information indicates that the first node is requesting to join the second distributed ledger. For example, the first distributed ledger to which the first node previously belonged may not meet the first node's business requirements, thus requiring the first node to join the second distributed ledger; or, the first node may need to switch carrier networks, thus requiring the first node to join the second distributed ledger. Simultaneously, the identification information of the first and second distributed ledgers indicated in the first request information is used to determine the source distributed ledger corresponding to the first node and the target distributed ledger to which it is requesting to join.

[0134] In one possible implementation, the first node obtains distributed ledger information, which includes the identification information of one or more distributed ledgers and the node information contained in the one or more distributed ledgers. The distributed ledgers include a first distributed ledger and a second distributed ledger, and the node information includes the addresses of one or more nodes.

[0135] Specifically, the first node pre-acquires distributed ledger information. The acquired distributed ledgers can be managed by the same DLAF or by different DLAFs. After acquiring this information, the first node saves it to the distributed ledger list. In one possible implementation, the distributed ledger list may include one or more of the following information: the identifier of the distributed ledger, the type of the distributed ledger, the node list information of the distributed ledger, and the configuration information of the distributed ledger. A description of the distributed ledger list can be found in Table 1. The content shown in Table 1 is for illustrative purposes only and is not intended as a final limitation.

[0136] Table 1

[0137] Distributed ledger Identity Type Node list Configuration information Distributed ledger 1 Identity 1 Type 1 Node 1, Node 4 Configuration information 1 Distributed ledger 2 Identity 2 Type 1 Node 2, Node 3 Configuration information 2 Distributed ledger 3 Identity 3 Type 2 Node 2, Node 3, Node 4 Configuration information 3

[0138] As shown in Table 1, this distributed ledger list includes the following information:

[0139] Distributed ledger 1, identified as Identifier 1, type as Type 1, node list includes node 1 and node 4, configuration information is configuration information 1;

[0140] Distributed ledger 2, identified as identifier 2, type as type 1, node list includes node 2 and node 3, configuration information is configuration information 2;

[0141] Distributed ledger 3, identifier is identifier 3, type is type 2, node list includes node 2, node 3 and node 4, configuration information is configuration information 3.

[0142] There can be multiple different distributed ledgers belonging to or corresponding to the same type, without limitation. In addition, for each distributed ledger, the node list also includes the identification information or address (e.g., Internet Protocol (IP) address) of each node (not shown in Table 1).

[0143] Optionally, the configuration information for each distributed ledger may include attributes such as the consensus mechanism, security algorithm, and ledger technology supported by that distributed ledger. Specifically, the consensus mechanism information indicates the consensus mechanism supported by the distributed ledger, such as Proof-of-Work (PoW), Proof-of-Stake (PoS), Delegated Proof-of-Stake (DPoS), or Practical Byzantine Fault Tolerance (PBFT). The security algorithm information indicates the security algorithms supported by the distributed ledger, such as hash algorithms, signature algorithms, and encryption algorithms. The ledger technology information indicates the ledger structure supported by the distributed ledger, such as whether it supports editability and whether privacy protection is employed.

[0144] The first node can obtain the above list of distributed ledgers in the following way:

[0145] Obtain it through the operator's homepage;

[0146] Obtained from other nodes (such as a second node) through request and response processes;

[0147] Obtained from other nodes (such as second nodes) through subscription and notification processes;

[0148] Obtaining information from publicly available information from other nodes (such as a second node) (e.g., by carrying the list of distributed ledgers in a broadcast message).

[0149] Once the first node determines the list of distributed ledgers, it selects a distributed ledger to join (i.e., the second distributed ledger) from the list. The first node then indicates the desired distributed ledger to the second node in the second distributed ledger by specifying the ledger's identifier and / or type information. Alternatively, the second node can obtain the distributed ledger information and store it in the distributed ledger list using the aforementioned method. This allows the first node to apply to join the distributed ledger it wants.

[0150] It should be understood that when the first node is directly connected to the second node, the first node sends the first request information directly to the second node. When the first node is not directly connected to the second node, the first node sends the first request information to the second node through a third node.

[0151] S502, The second node determines the first response information.

[0152] The first response message is a response to the first request message. For example, the first response message indicates that the first node is not allowed to join the second distributed ledger, or the first response message indicates that the first node is allowed to join the second distributed ledger.

[0153] Optionally, when the first response information indicates that the first node is allowed to join the second distributed ledger, the first response information may also indicate the identification information of the second distributed ledger.

[0154] In one possible implementation, when the attribute information in the configuration information of the first distributed ledger is the same as the attribute information in the configuration information of the second distributed ledger, or when the attribute information in the configuration information of the first distributed ledger includes all the attribute information in the configuration information of the second distributed ledger, the first response information indicates that the first node is allowed to join the second distributed ledger (which may carry the identification information of the second distributed ledger).

[0155] For example, a first node belongs to a first distributed ledger. If the security algorithm, consensus mechanism, ledger technology, and other attribute information in the configuration information of the first distributed ledger are completely identical to those of a second distributed ledger, then the first node is considered capable of joining the second distributed ledger. Alternatively, the attribute information in the configuration information of the first distributed ledger may contain all the attribute information in the configuration information of the second distributed ledger. In other words, the attribute information in the configuration information of the second distributed ledger may be a subset of the attribute information in the configuration information of the first distributed ledger. For instance, if the security algorithm in the configuration information of the first distributed ledger is Post-Quantum Cryptography (PQC), the consensus mechanism is RAFT, and the ledger technology is editable, and the security algorithm in the configuration information of the second distributed ledger is PQC, the consensus mechanism is RAFT, and the ledger technology is non-editable, then it can be considered that all the attribute information in the configuration information of the second distributed ledger is included in the first distributed ledger, and the first node is capable of joining the second distributed ledger. The first node can join the second distributed ledger based on its identifier information.

[0156] In another possible implementation, when the attribute information in the configuration information of the first distributed ledger is different from the attribute information in the configuration information of the second distributed ledger, or when the attribute information in the configuration information of the first distributed ledger does not completely include all the attribute information in the configuration information of the second distributed ledger, i.e., the attribute information in the configuration information of the second distributed ledger is not a subset of the attribute information in the configuration information of the first distributed ledger, the first response information indicates that the first node is not allowed to join the second distributed ledger.

[0157] In another possible implementation, the first request information sent by the first node also indicates the capability information of the first node, which includes at least one of the security algorithms, consensus mechanisms, and ledger capabilities supported by the first node. The second node determines the first response information based on the capability information and the configuration information of the second distributed ledger.

[0158] Specifically, the second node compares the received capability information of the first node with the configuration information of the second distributed ledger. If the attribute information in the configuration information of the second distributed ledger is a subset of the capability information of the first node, it can be considered that the distributed ledger capability of the first node matches the second distributed ledger, and the first node has the capability to join the second distributed ledger. The determined first response information indicates that the first node is allowed to join the second distributed ledger. If the attribute information in the configuration information of the second distributed ledger is not a subset of the capability information of the first node, it is considered that the distributed ledger capability of the first node does not match the second distributed ledger, and the first node does not have the capability to join the second distributed ledger. The determined first response information indicates that the first node is not allowed to join the second distributed ledger.

[0159] In this embodiment of the application, the second node can determine the first response information on its own, or it can determine the first response information through interaction with other nodes.

[0160] Taking the second node determining the first response information on its own as an example:

[0161] Method a1:

[0162] The second node belongs to the second distributed ledger. The first request information includes the identification information of the first distributed ledger to which the first node belongs, and the identification information of the second distributed ledger. Since the first node sends the first request information to the second node, the second node can determine that the first node requests to join the second distributed ledger. The second node compares the configuration information of the first distributed ledger with the configuration information of the second distributed ledger, or, based on the comparison of the first node's capability information and the second distributed ledger's configuration information, to determine whether to allow the first node to join the second distributed ledger. Accordingly, the second node determines the first response information based on the above comparison results.

[0163] Method a2:

[0164] The second node manages one or more distributed ledgers (including a first distributed ledger and a second distributed ledger). The first request information includes the identification information of the first distributed ledger and the second distributed ledger. The second node compares the configuration information of the first distributed ledger and the second distributed ledger to determine whether to allow the first node to join the second distributed ledger. Accordingly, the second node determines the first response information based on the comparison result.

[0165] Taking the example of the second node determining the first response information through interaction with other nodes:

[0166] Method b1:

[0167] The second node belongs to the first distributed ledger. The first request information includes the identification information of the second distributed ledger. Since the first node sends the first request information to the second node, the second node can determine that the first node requests to join the second distributed ledger. The second node keeps a list of distributed ledgers. The second node finds the node of the second distributed ledger from the list of distributed ledgers and sends the first request information. The node in the second distributed ledger determines the first response information.

[0168] S503, the second node sends a first response message to the first node. Correspondingly, the first node receives the first response message.

[0169] When the first node is directly connected to the second node, the second node sends the first response information directly to the first node. When the first node is not directly connected to the second node, the second node sends the first response information to the first node through a third node.

[0170] Through the above process, the embodiments of this application can support the first node to apply to join the distributed ledger more flexibly, simplify the process of the first node joining the target distributed ledger, and improve the resource utilization of the first node and the distributed ledger.

[0171] One possible implementation, the method may also include:

[0172] S504. The first node sends a third response message to the second node. Correspondingly, the second node receives the third response message.

[0173] When the first node is directly connected to the second node, the first node sends the third response information directly to the second node. When the first node is not directly connected to the second node, the first node sends the third response information to the second node through the third node.

[0174] When the first response message indicates that the first node is allowed to join the second distributed ledger, the third response message indicates that the first node has successfully joined the second distributed ledger, or the third response message indicates that the first node has failed to join the second distributed ledger.

[0175] When the third response message indicates that the first node has successfully joined the second distributed ledger, the second node can update the node list of the second distributed ledger. For example, the second node can add the first node to the node list of the second distributed ledger (the second node belongs to the second distributed ledger, or the second node manages the second distributed ledger). When the third response message indicates that the first node has failed to join the second distributed ledger, the second node can ignore the first node's request to join the second distributed ledger.

[0176] In this embodiment, the roles of nodes in the distributed ledger can include full nodes, light nodes, micro nodes, and clients. These roles define the different permissions a node has within the distributed ledger. 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 a distributed ledger, participate in consensus, and write to the ledger; a micro node has the following permissions: query / report transactions and generate a distributed ledger; and a client has the following permissions: query / report transactions.

[0177] In one possible embodiment, the first response information indicates permission for the first node to join the second distributed ledger. The first response information may also indicate the first node's permissions or roles in the second distributed ledger. The permissions or roles of the first node in the second distributed ledger can be determined based on the first node's distributed ledger capabilities and the current state of the second distributed ledger, or by referring to the first node's permissions or roles in the first distributed ledger.

[0178] For example, if the first node supports powerful computing capabilities, then the permissions allocated to the first node support the consensus mechanism. If more than half of the consensus nodes already exist in the second distributed ledger, then the permissions allocated to the first node do not support the consensus mechanism.

[0179] For example, if the first node has storage space and a secure storage environment, then the permissions allocated to the first node are to allow saving distributed ledger data, etc. Or, if the permissions allocated to the first node in the first distributed ledger are to participate in consensus and write to the ledger, then the permissions allocated to the first node support the consensus mechanism and support writing to the ledger.

[0180] The permissions of the first node in the second distributed ledger can be configured by the second node itself, by the second node and other nodes in the second distributed ledger, or by DLAF; there are no restrictions on this.

[0181] The aforementioned permissions can also be understood as roles. For example, configuring permissions for the first node in the second distributed ledger can be understood as configuring the first node's role in the second distributed ledger. Alternatively, once the first node determines its permissions in the second distributed ledger, it can determine its role within the second distributed ledger; or, once the first node determines its role in the second distributed ledger, it can determine its permissions, and so on. Therefore, the aforementioned permissions can also be replaced with roles.

[0182] In one possible embodiment, the first response information indicates permission for the first node to join the second distributed ledger. The first response information may also indicate configuration information of the second distributed ledger, which is used to ensure that the first node can correctly join the second distributed ledger.

[0183] The configuration information of the second distributed ledger can be configured by the second node itself, or jointly configured by the second node and other nodes in the second distributed ledger, or configured by DLAF; there are no restrictions on this.

[0184] For example, the configuration information of the second distributed ledger includes, but is not limited to: the security algorithm, consensus mechanism, ledger technology used by the second distributed ledger, and the node list of the second distributed ledger. Accordingly, the second node selects the appropriate security algorithm, consensus mechanism, ledger technology, etc., to join the second distributed ledger.

[0185] By specifying the configuration information of the second distributed ledger, the first node can correctly join the second distributed ledger according to the configuration information of the second distributed ledger.

[0186] In one possible embodiment, the first response information may also indicate indication information, which indicates that the configuration information of the first distributed ledger is the same as the configuration information of the second distributed ledger.

[0187] Accordingly, the first node determines the configuration information of the second distributed ledger based on the instruction information, and then correctly joins the second distributed ledger according to the configuration information of the second distributed ledger.

[0188] Optionally, in this embodiment of the application, the type of distributed ledger may include, but is not limited to: a distributed ledger for storing certificates and identities, a distributed ledger for resource sharing, a distributed ledger for log auditing, etc.

[0189] In one possible embodiment, the first request information further indicates the identity information of the first node, such as identification information or address information. The second node verifies the first node based on the identity information of the first node.

[0190] For example, the second node performs two-way authentication with the first node in order to obtain the verification result of the corresponding first node.

[0191] For example, the second node may obtain the verification result of the corresponding first node from other nodes, and there are no restrictions on this.

[0192] By indicating the identity information of the first node, this allows the second node to complete the authentication of the first node, thereby improving the security when allowing the first node to join the distributed ledger.

[0193] The following text combines Figures 6 to 8 right Figure 5 The process of determining the first response information will be further described.

[0194] Figure 6 This is a schematic diagram of the interaction flow of another communication method according to an embodiment of this application. Figure 6 In this system, the first node belongs to the first distributed ledger, the second node belongs to the second distributed ledger, and the third node belongs to the first distributed ledger or manages one or more distributed ledgers (including the first distributed ledger). The second node is directly connected to the first node, and determines the first response information by interacting with other nodes in the first distributed ledger. For example... Figure 6 As shown, the communication method includes:

[0195] S601, The first node sends a first request message to the second node. Correspondingly, the second node receives the first request message.

[0196] Specifically, the first request information includes the identification information of the first distributed ledger and the identification information of the second distributed ledger. The second node queries the locally stored list of distributed ledgers to determine that the first node belongs to the first distributed ledger and that it itself belongs to the second distributed ledger. The first distributed ledger includes the third node or the third node manages the first distributed ledger.

[0197] S602, the second node sends a second request message to the third node. Correspondingly, the third node receives the second request message.

[0198] Specifically, if the second node cannot obtain the configuration information of the first distributed ledger or the distributed ledger capability information of the first node, and lacks a basis for making an accurate determination on whether to allow the first node to join the second distributed ledger, it can use the third node to obtain relevant information (i.e., the configuration information of the first distributed ledger or the distributed ledger capability information of the first node). Then, it sends a second request message to the third node, which carries the identification information of the first distributed ledger and the identification information of the first node.

[0199] S603, the third node determines the second response information.

[0200] Specifically, the third node determines the second response information based on the identification information of the first distributed ledger and the identification information of the first node. The second response information is used to respond to the second request information and indicates the configuration information of the first distributed ledger.

[0201] In one possible implementation, the second response information can also indicate the permissions of the first node in the first distributed ledger.

[0202] Specifically, during the process of the first node joining the second distributed ledger, in order to quickly complete the permission allocation for the first node, the second node can refer to the permissions of the first node in the first distributed ledger to allocate permissions for it in the second distributed ledger.

[0203] In another possible implementation, the second response information also indicates whether the first distributed ledger continues to maintain its connection with the first node, and the second response information also indicates the identification information of the first distributed ledger.

[0204] Specifically, the third node can determine whether to maintain its connection with the first node based on the real-time status of the first distributed ledger. For example, if the current number of nodes in the first distributed ledger is less than a first threshold (e.g., to execute the Byzantine Fault Tolerance (BFT) consensus algorithm, at least 3 nodes are required, and the first threshold can be set to 3), then the connection between the first distributed ledger and the first node needs to be maintained; or, if the current number of nodes in the first distributed ledger is greater than the first threshold, and the ledger data is private data, then the connection between the first distributed ledger and the first node does not need to be maintained.

[0205] Furthermore, the third node sends the judgment result to the second node through a second response message, which instructs the first distributed ledger to maintain its connection with the first node, or the second response message instructs the first distributed ledger not to maintain its connection with the first node.

[0206] S604. The third node sends a second response message to the second node. Correspondingly, the second node receives the second response message.

[0207] The second node can determine the first response information based on the second response information, or the first response information is related to the second response information, or the first response information includes all or part of the content indicated by the second response information, without limitation.

[0208] S605, the second node sends a first response message to the first node. Correspondingly, the first node receives the first response message.

[0209] In one possible implementation, after obtaining the configuration information of the first distributed ledger, the second node compares it with the configuration information of the second distributed ledger to obtain a comparison result. For example, if the attribute information of the configuration information of the first distributed ledger is the same as that of the second distributed ledger, or if the attribute information of the configuration information of the second distributed ledger is a subset of the attribute information of the first distributed ledger, the comparison result indicates that the first node has the ability to join the second distributed ledger, and the first node is allowed to join the second distributed ledger. The comparison result is then cached. When the second node receives a request from another node in the first distributed ledger, and the request carries the identification information of both the first and second distributed ledgers, the second node does not need to obtain the configuration information of the first distributed ledger again (e.g., obtain it from a third node through a second request). Instead, based on the cached comparison result, it can determine that all nodes included in the first distributed ledger have the ability to join the second distributed ledger, and directly sends a response to that node, indicating that it is allowed to join the second distributed ledger.

[0210] It is understandable that after the first comparison, the second node can cache the comparison result. In subsequent request processing, when nodes belonging to the same source distributed ledger request to join the same target distributed ledger, it is not necessary to judge each node separately. Instead, the response can be made directly based on the cached comparison result. In this way, the operational complexity of the second node can be reduced (from logn to log1, where n represents the number of nodes requesting to join the same target distributed ledger and belonging to the same source distributed ledger), which greatly improves the performance of the second node and increases its resource utilization.

[0211] In another possible implementation, the first response information also indicates the configuration information of the second distributed ledger. The second node can optionally send configuration information such as consensus mechanism, security algorithm, and ledger technology to the first node based on the permissions assigned to it by the first node in the second distributed ledger. The first node compares the received configuration information of the second distributed ledger with the configuration information of the first distributed ledger. If the attribute information in the second distributed ledger's configuration information is the same as that in the first distributed ledger's configuration information, the first node updates its current configuration file, modifies the permissions to those configured by the second distributed ledger, and modifies the node list to match the node list in the second distributed ledger, thus joining the second distributed ledger. If the attribute information in the second distributed ledger's configuration information is different from that in the first distributed ledger—for example, if the attribute information in the second distributed ledger's configuration information is a subset of the attribute information in the first distributed ledger's configuration information—the first node starts a new program (e.g., starts a new container) based on the configuration information of the second distributed ledger to join the second distributed ledger.

[0212] In another possible implementation, the first response information also includes an indication message indicating that the configuration information of the first distributed ledger is the same as that of the second distributed ledger. Upon receiving this indication message, the first node can directly update its current configuration file, modify its permissions to those configured for it by the second distributed ledger, and update its node list to match the node list in the second distributed ledger, thereby joining the second distributed ledger.

[0213] In another possible implementation, if the first response information also indicates that the first distributed ledger should not maintain a connection with the first node, the first node shuts down the program used for the first distributed ledger; or, if the first response information also indicates that the first distributed ledger should continue to maintain a connection with the first node, the first node determines that it does not need the services provided by the first distributed ledger, and the first node shuts down the program used for the first distributed ledger; or, if the first response information also indicates that the first distributed ledger should continue to maintain a connection with the first node, and the first node still needs to continue to obtain the services provided by the first distributed ledger, the first node continues to run the program used for the first distributed ledger.

[0214] As can be seen, regarding whether to maintain the connection between the first node and the source distributed ledger (i.e., the first distributed ledger), the embodiments of this application can take into account the wishes of both the first node and the first distributed ledger, and both the first node and the first distributed ledger have certain decision-making power. On the one hand, the connection between distributed ledger nodes is a P2P connection, which belongs to the higher-level connection and is basically not limited by geographical distance. For example, the first node is the UE, the second node is base station 2, and the third node is base station 1. The first node and the third node belong to the first distributed ledger, and the second node belongs to the second distributed ledger. The UE is initially located within the coverage area of ​​base station 1. Due to movement, the UE leaves the coverage area of ​​base station 1 and enters the coverage area of ​​base station 2. However, unlike the telecommunications network, although the telecommunications network connection between the UE and base station 1 is forced to disconnect due to the limitation of signal power, which prevents the physical layer signal from being directly transmitted, the higher-level connection between the UE and base station 1 is not affected. The UE can still maintain a P2P connection with base station 1 through the "UE-base station 2-base station 1" link. Therefore, this provides a connection basis for the first distributed ledger to allocate decision-making power. In addition, the first distributed ledger has the need to maintain connections (e.g., the consensus algorithm requires a certain number of nodes), so it is necessary to allocate certain decision-making power to the first distributed ledger to meet the actual needs of the first distributed ledger during operation.

[0215] In the above process, the second node determines whether to allow the first node to join the second distributed ledger and sends information to the first node indicating whether to allow the first node to join the second distributed ledger. Furthermore, the third node can decide whether to maintain the connection between the first distributed ledger and the first node, depending on actual needs, and forwards this instruction to the first node through the second node. Through this process, the embodiments of this application can support the first node to join the second distributed ledger more flexibly, simplifying the process of nodes joining and leaving the distributed ledger, and improving the resource utilization of nodes and the distributed ledger.

[0216] Figure 7 This is a schematic diagram of the interaction flow of another communication method according to an embodiment of this application. Figure 7 In this system, the first node belongs to the first distributed ledger, the second node belongs to the first distributed ledger, and the fourth node belongs to the second distributed ledger. The second node is directly connected to the first node, and determines the first response information by interacting with other nodes in the second distributed ledger. For example... Figure 7 As shown, the communication method includes:

[0217] S701, The first node sends a first request message to the second node. Correspondingly, the second node receives the first request message.

[0218] Specifically, the first request information includes the identification information of the first distributed ledger and the identification information of the second distributed ledger. The second node queries the locally stored list of distributed ledgers to determine that it belongs to the first distributed ledger and that the first node also belongs to the first distributed ledger. The fourth node belongs to the second distributed ledger or manages the second distributed ledger.

[0219] S702, the second node sends a third request message to the fourth node. Correspondingly, the fourth node receives the third request message.

[0220] The third request information is related to the first request information, or the third request information is determined based on the first request information, or the third request information includes all or part of the content indicated by the first request information.

[0221] Furthermore, by carrying the identification information of the first node and the second distributed ledger in the third request information, the fourth node can determine that the first node is requesting to join its own distributed ledger (i.e., the second distributed ledger).

[0222] In one possible implementation, the third request information also indicates the configuration information of the first distributed ledger or the distributed ledger capability information of the first node, so that the fourth node can make an accurate judgment on whether to allow the first node to join the second distributed ledger based on this information. It is understood that this approach avoids the fourth node repeatedly executing the step of obtaining the configuration information of the first distributed ledger or the distributed ledger capability information of the first node in subsequent judgment processes, simplifying the overall process and improving the efficiency of the first node joining the second distributed ledger.

[0223] In another possible implementation, the third request information also indicates the permissions of the first node in the first distributed ledger, and the fourth node can use this information to assign permissions to the first node in the second distributed ledger.

[0224] For example, if the first node's permissions in the first distributed ledger are read, write, save the ledger, and participate in consensus, then the fourth node's permissions for the first node in the second distributed ledger will also be read, write, save the ledger, and participate in consensus. Of course, the fourth node can also assign permissions to the first node based on the first node's capabilities and the current state of the second distributed ledger. However, it should be noted that the permissions assigned by the fourth node to the first node generally do not exceed the fourth node's own permissions. For example, if the fourth node supports reading and writing the ledger but does not support consensus, then the permissions assigned by the fourth node to the first node will also be read, write the ledger, and not support consensus.

[0225] S703, the fourth node determines the fourth response information. This fourth response information is used to respond to the third request information.

[0226] The fourth node can determine whether to allow the first node to join the second distributed ledger based on a comparison between the configuration information of the first and second distributed ledgers. For example, if the fourth node determines that the attribute information of the first and second distributed ledgers is the same, or that the attribute information of the second distributed ledger is a subset of the attribute information of the first distributed ledger, then the first node is allowed to join the second distributed ledger. Conversely, if the fourth node determines that the attribute information of the first and second distributed ledgers is different, or that the attribute information of the second distributed ledger is not a subset of the attribute information of the first distributed ledger, then the first node is not allowed to join the second distributed ledger.

[0227] In one possible implementation, the fourth node caches the comparison result. When it receives the same request information later, that is, when other nodes in the first distributed ledger request to join the second distributed ledger, it can use the cached comparison result to make a decision, thereby reducing complexity and improving performance and resource utilization.

[0228] In another possible implementation, the fourth response information also indicates the configuration information of the second distributed ledger and the permissions of the first node in the second distributed ledger. The fourth node can optionally send configuration information such as consensus mechanisms, security algorithms, and ledger technologies to the second node based on the permissions assigned to it by the first node in the second distributed ledger.

[0229] S704, the fourth node sends a fourth response message to the second node. Correspondingly, the second node receives the fourth response message.

[0230] When the fourth node determines that the attribute information of the configuration information of the first distributed ledger is the same as the attribute information of the configuration information of the second distributed ledger, or that the attribute information of the configuration information of the second distributed ledger is a subset of the attribute information of the configuration information of the first distributed ledger, the fourth response message indicates that the first node is allowed to join the second distributed ledger. When the fourth node determines that the attribute information of the configuration information of the first distributed ledger is different from the attribute information of the configuration information of the second distributed ledger, or that the attribute information of the configuration information of the second distributed ledger is not a subset of the attribute information of the configuration information of the first distributed ledger, the fourth response message indicates that the first node is not allowed to join the second distributed ledger.

[0231] The second node determines the first response information based on the fourth response information, or the first response information is related to the fourth response information, or the first response information includes all or part of the content indicated by the fourth response information, without limitation.

[0232] S705, the second node sends a first response message to the first node. Correspondingly, the first node receives the first response message.

[0233] In one possible implementation, the first response information also indicates whether the first distributed ledger should maintain its connection with the first node. The second node can determine whether to maintain the connection between the first distributed ledger and the first node based on the real-time status of the first distributed ledger (e.g., the current number of nodes, whether the ledger data is private, etc.).

[0234] Furthermore, when the first response information indicates that the first distributed ledger should not maintain a connection with the first node, the first node closes the program used by the first distributed ledger; or, when the first response information indicates that the first distributed ledger should continue to maintain a connection with the first node, and the first node does not need the services provided by the first distributed ledger, the first node closes the program used by the first distributed ledger; or, when the first response information indicates that the first distributed ledger should continue to maintain a connection with the first node, and the first node still needs to obtain the services provided by the first distributed ledger, the first node continues to run the program of the first distributed ledger.

[0235] Through the above process, the embodiments of this application can support the first node to join the second distributed ledger more flexibly, simplify the process of joining the distributed ledger, and improve the resource utilization of the node and the distributed ledger.

[0236] Figure 6 and Figure 7 The example described is based on multiple nodes jointly determining whether to allow the first node to join the second distributed ledger. This application embodiment also supports the second node directly determining whether to allow the first node to join the second distributed ledger based on the request information of the first node, which helps to reduce the interaction overhead between nodes.

[0237] Figure 8 This is a schematic diagram of the interaction flow of another communication method according to an embodiment of this application. Figure 8 In this model, the first node belongs to the first distributed ledger, and the second node is a DLAF (Distributed Ledger Automation System). The second node manages both the first and second distributed ledgers, and it connects to the first node. The second node independently determines the first response information. For example... Figure 8 As shown, the communication method includes:

[0238] S801, the first node sends a first request message to the second node. Correspondingly, the second node receives the first request message.

[0239] Optionally, in S802, the second node determines whether the identity of the first node is trustworthy.

[0240] For example, when the first node is a UE, the second node can obtain the UE's authentication result from the authentication server function (AUSF) to determine whether the first node's identity is trustworthy.

[0241] S803, the second node determines the first response information.

[0242] The second node, based on the stored list of distributed ledgers, obtains the configuration information of the first distributed ledger and the configuration information of the second distributed ledger. It compares the two. If the attribute information of the first distributed ledger's configuration information is the same as the attribute information of the second distributed ledger, or if the attribute information of the second distributed ledger's configuration information is a subset of the attribute information of the first distributed ledger, then it determines that the first node is allowed to join the second distributed ledger. If the attribute information of the first distributed ledger's configuration information is different from the attribute information of the second distributed ledger, or if the attribute information of the second distributed ledger's configuration information is not a subset of the attribute information of the first distributed ledger, then it determines that the first node is not allowed to join the second distributed ledger. Based on the comparison results, the first response information is determined.

[0243] S804, The second node updates the node list of the second distributed ledger.

[0244] Optionally, the second node configures the node list stored by all nodes in the second distributed ledger by issuing control signaling, and adds the IP, ID or other parameters that can uniquely identify the first node to the node list to add the first node to the second distributed ledger.

[0245] Optionally, S805, the second node updates the node list of the first distributed ledger.

[0246] Optionally, the second node can configure the list of nodes stored by all nodes in the first distributed ledger by issuing control signaling, and remove the IP of the first node from the list of nodes to remove the first node from the first distributed ledger.

[0247] S806, the second node sends a first response message to the first node. Correspondingly, the first node receives the first response message.

[0248] The first response information is related to the comparison result of the configuration information of the distributed ledger. For example, if the attribute information of the configuration information of the first distributed ledger is the same as the attribute information of the configuration information of the second distributed ledger, or if the attribute information of the configuration information of the second distributed ledger is a subset of the attribute information of the configuration information of the first distributed ledger, the first response information indicates that the first node is allowed to join the second distributed ledger; if the attribute information of the configuration information of the first distributed ledger is different from the attribute information of the configuration information of the second distributed ledger, or if the attribute information of the configuration information of the second distributed ledger is not a subset of the attribute information of the configuration information of the first distributed ledger, the first response information indicates that the first node is not allowed to join the second distributed ledger.

[0249] In one possible implementation, the first response information also indicates the first node's permissions in the second distributed ledger. Optionally, the second node may assign permissions to the first node in the second distributed ledger by referring to the first node's permissions in the first distributed ledger.

[0250] In another possible implementation, the first response information also indicates the configuration information of the second distributed ledger. The second node can optionally send configuration information such as consensus mechanism, security algorithm, and ledger technology to the first node based on the permissions allocated to it in the second distributed ledger, so that the first node can join the second distributed ledger according to this configuration information. For example, if the permissions allocated by the second node to the first node include supporting consensus algorithms, then the configuration information sent might include "consensus = RAFT"; or, if the permissions allocated by the second node to the first node include saving the ledger, then the configuration information sent might include "ledger technology = editable".

[0251] Through the above process, the embodiments of this application can support the rapid addition of the first node to the second distributed ledger, effectively reduce the interaction overhead between nodes, simplify the process of nodes joining and leaving the distributed ledger, and improve the performance and resource utilization of nodes and the distributed ledger.

[0252] The following text combines Figure 9 and Figure 10 right Figure 5 The method shown will be described in further detail.

[0253] Figure 9 This is a schematic diagram of the interaction flow of another communication method according to an embodiment of this application. Figure 8 In this system, the first node is DLE0, the second node is DLE2, and the third node is either DLE1 or DLAF1. DLE0 and DLE1 belong to the first distributed ledger, while DLE2 belongs to the second distributed ledger.

[0254] like Figure 9 As shown, the communication method includes:

[0255] S901 and DLE0 obtain distributed ledger information and save it to the distributed ledger list.

[0256] Specifically, the distributed ledger information pre-acquired by DLE0 includes the identification information of the first and second distributed ledgers, as well as node information, which includes the addresses (e.g., IP addresses) of one or more nodes.

[0257] S902, DLE0 sends a first request message to DLE2. Correspondingly, DLE2 receives the first request message.

[0258] The first request message instructs DLE0 to join the first distributed ledger, and the first request message also instructs the identification information of the first distributed ledger and the identification information of the second distributed ledger.

[0259] DLE2 determines whether DLE0 has the capability to join the second distributed ledger. For example, it checks whether the attribute information in the configuration information of the first distributed ledger to which DLE0 belongs is the same as the attribute information in the configuration information of the second distributed ledger, or whether the attribute information in the configuration information of the second distributed ledger is a subset of the attribute information in the configuration information of the first distributed ledger. When DLE2 determines that DLE0 has the capability to join the second distributed ledger, DLE2 allows DLE0 to join.

[0260] Optionally, S903a and DLE2 send a second request message to DLE1. Correspondingly, DLE1 receives the second request message.

[0261] For a description of the second request information, please refer to the above. Figure 6 The descriptions in the method embodiments shown will not be repeated.

[0262] Optionally, S903b and DLE1 determine whether to maintain the connection between DLE0 and the first distributed ledger.

[0263] Optionally, S903c and DLE1 send a second response message to DLE2. Correspondingly, DLE2 receives the second response message.

[0264] For a description of the second response information, please refer to the above. Figure 6 The descriptions in the method embodiments shown will not be repeated.

[0265] S904 and DLE2 determine the first response information.

[0266] For a description of S904, please refer to the above. Figure 6 The descriptions in the method embodiments shown will not be repeated.

[0267] S905 and DLE2 send the first response information to DLE0. Correspondingly, DLE0 receives the first response information.

[0268] S906, DLE0 executes the addition of the second distributed ledger.

[0269] Specifically, DLE0 updates the current configuration file or starts a new program to join the second distributed ledger based on the configuration information issued by DLE2.

[0270] Optionally, S907 and DLE0 can exit the first distributed ledger.

[0271] Once DLE0 successfully joins the second distributed ledger, DLE0 and DLE2 can transfer data about the second distributed ledger. If DLE0's permissions or role are configured to support nodes that store the ledger, such as a full node, then DLE2 needs to synchronize the ledger data with DLE0.

[0272] It should be noted that the above Figure 9 In this context, DLE0 can be a UE, DLE1 can be a base station, and DLE2 can be an NF. DLE0 and DLE1 can be directly connected (as described above). Figure 9 As shown in the figure, DLE1 and DLE2 can also be indirectly connected through other base stations or NFs (not shown in the figure). Similarly, DLE1 and DLE2 can be directly connected or indirectly connected through other base stations or NFs. For example, DLE0 is UE1, DLE1 is base station 1, and DLE2 is network element 1. UE1 is connected to base station 1 through base station 2, that is, communication between UE1 and base station 1 needs to be relayed through base station 2. In addition, there is network element 2 between base station 1 and network element 1, that is, base station 1 communicates with network element 1 through network element 2.

[0273] Figure 10 This is a schematic diagram of the interaction flow of another communication method according to an embodiment of this application. Figure 10 In this distributed ledger, the first node is DLE0, the second node is DLE1, and the fourth node is either DLE2 or DLAF2. DLE0 and DLE1 belong to the first distributed ledger, and DLE2 belongs to the second distributed ledger. For example... Figure 10 As shown, the communication method includes:

[0274] S1001 and DLE0 retrieve distributed ledger information and save it to the distributed ledger list.

[0275] S1002, DLE0 sends a first request message to DLE1. Correspondingly, DLE1 receives the first request message.

[0276] The first request message instructs DLE0 to join the second distributed ledger, and the first request message also indicates the identification information of the first distributed ledger and the identification information of the second distributed ledger.

[0277] S1003, DLE1 sends a third request message to DLE2. Correspondingly, DLE2 receives the third request message.

[0278] Optionally, the third request information may also indicate the configuration information of the first distributed ledger or the distributed ledger capability information of DLE1.

[0279] Optionally, the third request information may also indicate DLE0's permissions in the first distributed ledger.

[0280] S1004 and DLE2 determine the fourth response information.

[0281] For a description of S1004, please refer to the above. Figure 7 The descriptions in the method embodiments shown will not be repeated.

[0282] S1005, DLE2 sends a fourth response message to DLE1. Correspondingly, DLE1 receives the fourth response message. The fourth response message indicates whether DLE0 is allowed to join the second distributed ledger.

[0283] Optionally, the fourth response information may carry the identification information of DLE0 and the identification information of the second distributed ledger.

[0284] Optionally, the fourth response information may also indicate DLE0's permissions in the second distributed ledger and the configuration information of the second distributed ledger.

[0285] S1006 and DLE1 determine the first response information.

[0286] For example, DLE1 determines the first response information based on the fourth response information. For instance, the fourth response information indicates that DLE0 is allowed to join the second distributed ledger, and the first response information indicates that DLE0 is allowed to join the second distributed ledger; or, the fourth response information indicates that DLE0 is not allowed to join the second distributed ledger, and the first response information indicates that DLE0 is not allowed to join the second distributed ledger, and so on.

[0287] Optionally, S1007 and DLE1 determine whether to maintain the connection between DLE0 and the first distributed ledger.

[0288] S1008, DLE1 sends the first response information to DLE0. Correspondingly, DLE0 receives the first response information.

[0289] Optionally, the first response information may carry identification information of the second distributed ledger.

[0290] Optionally, the first response information may also indicate DLE0's permissions in the second distributed ledger and the configuration information of the second distributed ledger.

[0291] S1009, DLE0 executes the addition of the second distributed ledger.

[0292] Optionally, S1010 and DLE0 can exit the first distributed ledger.

[0293] After DLE0 successfully joins the first distributed ledger, it transfers data about the first distributed ledger with a node in the second distributed ledger. If DLE0 is configured as a full node, that node needs to synchronize its ledger data with DLE0.

[0294] When there is no node to which DLE0 is instructed to establish a connection, DLE0 can choose any node from the list of nodes in the second distributed ledger to communicate with.

[0295] Optionally, the specific forms and connection relationships of DLE0, DLE1, and DLE2 can be referred to the above. Figure 9 The relevant descriptions in the text can be directly or indirectly connected, which will not be elaborated here.

[0296] The above describes how the first node joins the distributed ledger; the following describes how the first node leaves the distributed ledger.

[0297] The first node may decide to exit the distributed ledger based on factors such as device usage (e.g., other functions are consuming more resources, the distributed ledger is of low priority, therefore it needs to exit the distributed ledger to release the occupied computing and storage resources), the first node's movement causing it to disconnect from DLAF or other nodes in the first distributed ledger, or user needs, network administrator (operator) configuration, etc. When the first node wants to exit the second distributed ledger (for example only), it instructs the second node to exit, or the first node can directly exit the second distributed ledger. Optionally, the first node can also passively exit the second distributed ledger, for example, when the network administrator decides to delete the second distributed ledger. See details in [link to relevant documentation]. Figure 10 The content shown.

[0298] Figure 11 This is a schematic diagram of the interaction flow of another communication method according to an embodiment of this application. For example... Figure 11 As shown, the communication method includes:

[0299] Optionally, in step S1101, the first node sends a second indication message to the second node. Correspondingly, the second node receives the second indication message.

[0300] When the first node wants to exit the first distributed ledger, it can send a second instruction message to the second node, instructing the first node to exit the first distributed ledger. The second instruction message can also include the identification information of the first distributed ledger, the identification information of the first node, etc.

[0301] S1102, The second node determines that the first node exits the first distributed ledger.

[0302] In this embodiment of the application, the method by which the second node determines that the first node has exited the second distributed ledger may include the following:

[0303] Method 1: The first node sends a second instruction message to the second node;

[0304] Method 2: The second node does not receive data from the first node for a period of time.

[0305] Using the above method, the embodiments of this application can support the second node in determining whether the first node exits the second distributed ledger.

[0306] Optionally, in step S1103, the second node sends a third indication message to the first node. Correspondingly, the first node receives the third indication message.

[0307] The third instruction is used to instruct the first node to exit the first distributed ledger. Specifically, when the first distributed ledger is deleted or the first node cannot meet the capability requirements of the first distributed ledger, the second node can instruct the first node to exit the first distributed ledger.

[0308] Optionally, the third indication information may also indicate a reason value, which is used to indicate the reason why the first node exits the first distributed ledger. For example, the reason may include, but is not limited to: the first distributed ledger has completed its task, or the first node is unable to meet the capability requirements of the first distributed ledger.

[0309] S1104. The second node updates the node list of the first distributed ledger.

[0310] Once the second node determines that the first node has exited the first distributed ledger, the second node can update the node list of the first distributed ledger.

[0311] Through the above scheme, the embodiments of this application can support the establishment of a mechanism for the first node to exit the distributed ledger, thereby enabling better management of the distributed ledger.

[0312] In this embodiment, both the first node and the second node can be devices in a communication network. For example, the first node can be a terminal device or a network device, and the second node can be a network device. Correspondingly, the aforementioned information can be information transmitted between devices in the communication network. For example, the first request information and the first response information can be information transmitted between a terminal device and a network device (network devices include access network devices and core network elements, etc.), or the first request information and the first response information can be information transmitted between network devices. When the first information and the second information are information transmitted between devices in the communication network, this embodiment can support the introduction or application of distributed ledger technology in the communication network.

[0313] III. Communication Devices

[0314] To achieve the functions of the method provided in this application, both the first node and the second node may include hardware structures and / or software modules, implementing the above functions in the form of hardware structures, software modules, or a combination of hardware structures and software modules. Whether a particular function is executed in the form of hardware structures, software modules, or a combination of hardware structures and software modules depends on the specific application and design constraints of the technical solution.

[0315] Figure 12 This is a schematic block diagram of a communication device 1200 according to an embodiment of this application. The communication device 1200 includes a processing circuit 1210 and a transceiver circuit 1220, which can be interconnected or coupled to each other, for example, through a bus 1230. The communication device 1200 can be a first node or a second node.

[0316] Optionally, the communication device 1200 may further include a memory 1240. The memory 1240 includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or compact disc read-only memory (CD-ROM). The memory 1240 is any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but is not limited thereto. The memory in this embodiment may also be a circuit or any other device capable of implementing storage functions for storing computer programs or instructions, and / or data.

[0317] The processing circuit 1210 may be all or part of the processing circuitry in one or more processors, or it may be one or more processors. The processor may be a central processing unit (CPU). If the processing circuit 1210 is a CPU, the CPU may be a single-core CPU or a multi-core CPU. The processing circuit 1210 may be a signal processor, a chip, or other integrated circuit capable of implementing the methods of this application, or a portion of the circuitry within the aforementioned processor, chip, or integrated circuit that performs processing functions. Additionally, the transceiver circuit 1220 may be a transceiver, or an input / output interface. An input / output interface is used for inputting or outputting signals or data and may also be referred to as an input / output circuit.

[0318] When the communication device 1200 is the first node, exemplarily, the processing circuit 1210 is used to perform the following operations: sending a first request message and receiving a first response message, etc.

[0319] When the communication device 1200 is the second node, exemplarily, the processing circuit 1210 is configured to perform the following operations: receive first request information; determine first response information; send first response information, etc.

[0320] When the communication device 1200 is the first node or the second node, it will be responsible for executing the methods or steps related to the first node or the second node in the aforementioned method embodiments.

[0321] When the communication device 1200 is the first node or the second node, the transceiver circuit 1220 can be a transceiver.

[0322] When the communication device 1200 is a chip used for the first node or the second node, the transceiver circuit 1220 can be an input / output circuit, pins, etc.

[0323] The above description is merely exemplary. For details, please refer to the content shown in the above method embodiments.

[0324] Figure 12 The implementation of each operation can also be found by referring to... Figures 5 to 11 The corresponding description of the method embodiments shown.

[0325] Figure 13 This is a schematic block diagram of a communication device 1300 according to an embodiment of this application. The communication device 1300 can be a first node or a second node, used to implement the methods involved in the above embodiments.

[0326] The communication device 1300 includes a transceiver unit 1310 and a processing unit 1320. The transceiver unit 1310 may include a sending unit and a receiving unit. The sending unit performs the sending action of the communication device, and the receiving unit performs the receiving action of the communication device. For ease of description, the sending unit and the receiving unit are combined into a single transceiver unit in this embodiment. This will be explained uniformly here and will not be repeated later.

[0327] When the communication device 1300 is the first node, for example, the transceiver unit 1310 is used to send first request information and receive first response information; the processing unit 1320 is used to determine the first request information, etc.

[0328] When the communication device 1300 is the second node, exemplarily, the transceiver unit 1310 is used to: receive first request information and send first response information; the processing unit 1320 is used to determine the first response information, etc.

[0329] When the communication device 1300 is the first node or the second node, it will be responsible for executing one or more of the methods or steps related to the first node or the second node in the aforementioned method embodiments.

[0330] Optionally, the communication device 1300 further includes a storage unit 1330 for storing programs or code for executing the aforementioned methods.

[0331] Figure 13 The transceiver unit in the middle can correspond to Figure 12 The transceiver circuit in the middle, Figure 13 The processing unit in the middle can correspond to Figure 12 The processing circuitry within.

[0332] Figure 12 and Figure 13 The illustrated device embodiment is used to implement Figures 5 to 11 The content described. Figure 12 and Figure 13 The specific execution steps and methods of the device shown can be found in the content described in the foregoing method embodiments.

[0333] This application also provides a chip, including a processor, for calling and executing instructions stored in a memory, causing a communication device on which the chip is installed to perform the methods described in the examples above. The memory may be integrated within the chip or located externally.

[0334] This application also provides another chip, including: an input interface, an output interface, and a processing circuit, wherein the input interface, the output interface, and the processor are connected through an internal connection path, and the processing circuit is used to execute code in memory. When the code is executed, the processing circuit is used to execute the methods in the above examples.

[0335] Optionally, the chip also includes a memory for storing computer programs or code. The input and output interfaces can be independent of each other, or they can be integrated into a single input / output interface.

[0336] The processing circuitry can be all or part of the processing circuitry in one or more processors, or one or more processors.

[0337] This application also provides a processor for coupling with a memory for performing the methods and functions of a network device or terminal device involved in any of the above embodiments.

[0338] In another embodiment of this application, a computer program product containing instructions is provided, which, when run on a computer, enables the implementation of the methods described in the foregoing embodiments.

[0339] This application also provides a computer program that, when run on a computer, enables the implementation of the methods described in the foregoing embodiments.

[0340] In another embodiment of this application, a computer-readable storage medium is provided, which stores a computer program that, when executed by a computer, implements the methods described in the foregoing embodiments.

[0341] It should be understood that in the embodiments of this application, the processor can be a CPU, but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0342] In addition, the processor may include one or more of the following: a central processing unit (CPU), a baseband processor, a digital signal processor (DSP), a microprocessor unit (MPU), a microcontroller unit (MCU), a graphics processing unit (GPU), a field programmable gate array (FPGA), an artificial intelligence processor (AI processor), or a neural processing unit (NPU).

[0343] It should also be understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be a cache, random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0344] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0345] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0346] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for example, the division of units is merely a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

[0347] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. If the above functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory, random access memory, magnetic disks, or optical disks.

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

Claims

1. A communication method characterized by comprising: The method comprises: sending first request information, the first request information being used for a first node to request to join a second distributed ledger, the first request information indicating identity information of a first distributed ledger to which the first node belongs and identity information of the second distributed ledger; receiving first response information, the first response information being used for responding to the first request information, the first response information indicating whether the first node is allowed to join the second distributed ledger.

2. The method of claim 1, wherein, The first response information indicates that the first node is allowed to join the second distributed ledger, and the first response information further indicates identity information of the second distributed ledger.

3. The method of claim 2, wherein, The first response information further indicates at least one of the following: a permission of the first node in the second distributed ledger, configuration information of the second distributed ledger, or indication information, the configuration information of the second distributed ledger being used for the first node to join the second distributed ledger and communicate with other nodes contained in the second distributed ledger, and the indication information being used for indicating that attribute information in the configuration information of the second distributed ledger is the same as attribute information in configuration information of the first distributed ledger.

4. The method according to any one of claims 1 to 3, characterized in that, Before the sending of the first request information, the method further comprises: obtaining distributed ledger information, the distributed ledger information comprising identity information of one or more distributed ledgers and node information of the one or more distributed ledgers, the distributed ledgers comprising the first distributed ledger and the second distributed ledger, and the node information comprising addresses of one or more nodes.

5. The method of claim 4, wherein, The distributed ledger information further comprises attribute information in configuration information of the second distributed ledger, the attribute information in the configuration information comprising at least one of the following: a consensus mechanism, a security algorithm, or a ledger technology.

6. The method according to any one of claims 1 to 5, characterized in that, The first response information further indicates that the first distributed ledger remains connected with the first node, and the first response information further indicates identity information of the first distributed ledger.

7. The method of any one of claims 1 to 6, wherein: the first request information and the first response information are information transmitted between a terminal-side device and a network-side device; or the first request information and the first response information are information transmitted between network-side devices.

8. The method according to any one of claims 1 to 7, characterized in that, The method further comprises: sending second indication information, the second indication information indicating that the first node exits the first distributed ledger, the second indication information indicating identity information of the first distributed ledger; or receiving third indication information, the third indication information indicating that the first node exits the first distributed ledger, the third indication information indicating identity information of the first distributed ledger.

9. A communication method characterized by comprising: The method comprises: receiving first request information, the first request information being used for a first node to request to join a second distributed ledger, the first request information indicating identity information of a first distributed ledger to which the first node belongs and identity information of the second distributed ledger; sending first response information, the first response information being used for responding to the first request information, and the first response information indicating whether the first node is allowed to join the second distributed ledger.

10. The method of claim 9, wherein, Before the sending of the first response information, the method further includes: obtaining configuration information of the first distributed ledger and configuration information of the second distributed ledger; determining the first response information based on the configuration information of the first distributed ledger and the configuration information of the second distributed ledger.

11. The method of claim 10, wherein, The determining of the first response information based on the configuration information of the first distributed ledger and the configuration information of the second distributed ledger includes: if attribute information in the configuration information of the first distributed ledger is same as attribute information in the configuration information of the second distributed ledger, or if the attribute information in the configuration information of the first distributed ledger includes all attribute information in the configuration information of the second distributed ledger, determining the first response information, the first response information indicating that the first node is allowed to join the second distributed ledger, and the attribute information including at least one of the following: a security algorithm, a consensus mechanism or a ledger technology.

12. The method according to any one of claims 9 to 11, characterized in that, The first response information indicates that the first node is allowed to join the second distributed ledger, and the first response information further indicates identification information of the second distributed ledger.

13. The method of claim 12, wherein, The first response information further indicates at least one of the following: a permission of the first node in the second distributed ledger, configuration information of the second distributed ledger, or indication information, the configuration information of the second distributed ledger being used for the first node to join the second distributed ledger and communicate with other nodes contained in the second distributed ledger, and the indication information being used for indicating that attribute information in the configuration information of the second distributed ledger is same as attribute information in the configuration information of the first distributed ledger.

14. The method according to any one of claims 10 to 13, characterized in that, The obtaining of the configuration information of the first distributed ledger and the configuration information of the second distributed ledger includes: sending second request information, the second request information being used for requesting the configuration information of the first distributed ledger, and the second request information further indicating identification information of the first distributed ledger and identification information of the first node; receiving second response information, the second response information being used for responding to the second request information, and the second response information further indicating the configuration information of the first distributed ledger.

15. The method of claim 14, wherein, The second response information further indicates a permission of the first node in the first distributed ledger.

16. The method according to claim 14 or 15, characterized in that The second response information further indicates whether the first distributed ledger continues to maintain a connection with the first node, and the second response information further indicates identification information of the first distributed ledger, the second response information being related to the first response information.

17. The method of claim 9, wherein, Before the sending of the first response information, the method further includes: sending third request information, the third request information being used for requesting to determine whether the first node is allowed to join the second distributed ledger, and the third request information further indicating identification information of the first node and identification information of the second distributed ledger; receive third response information, the third response information being used for responding to the third request information, the third response information being used for determining the first response information.

18. The method of claim 17, wherein, The third request information further comprises configuration information of the first distributed ledger and a right of the first node in the first distributed ledger.

19. The method of claim 17 or 18, wherein, The third response information indicates that the first node is allowed to join the second distributed ledger, and the third response information further indicates identification information of the second distributed ledger and identification information of the first node.

20. The method of claim 19, wherein, The third response information further indicates at least one of the following: a right of the first node in the second distributed ledger, configuration information of the second distributed ledger, or indication information, the configuration information of the second distributed ledger being used for the first node to join the second distributed ledger and communicate with other nodes contained in the second distributed ledger, and the indication information being used for indicating that the configuration information of the second distributed ledger is the same as the configuration information of the first distributed ledger.

21. The method according to any one of claims 17 to 20, characterized in that, The first response information further indicates whether the first distributed ledger continues to maintain a connection with the first node, and the first response information further indicates identification information of the first distributed ledger.

22. The method of any one of claims 9-21, wherein The first request information and the first response information are information transmitted between a terminal-side device and a network-side device; or The first request information and the first response information are information transmitted between network-side devices.

23. The method of any one of claims 9 to 22, wherein, The first response information indicates that the first node is allowed to join the second distributed ledger, and the method further comprises: updating a node list of the second distributed ledger, the updated node list containing the first node.

24. The method of any one of claims 9 to 23, wherein, The method further comprises: determining that the first node exits the first distributed ledger; updating a node list of the first distributed ledger, the updated node list not containing the first node.

25. A communications device, characterized by comprising units or modules for performing the method of any one of claims 1-24.

26. A communications device, characterized by comprising a processor configured to cause the communication device to perform the method of any one of claims 1-24 by executing computer programs or instructions, and / or by a logic circuit.

27. The communication apparatus according to claim 26, wherein The communication device further comprises a memory configured to store the computer programs or instructions.

28. The communication apparatus according to claim 26 or 27, wherein, The communication device further comprises a communication interface configured to input and / or output signals.

29. A computer-readable storage medium, characterized in that, The computer readable storage medium has stored thereon computer programs or instructions which, when executed on a computer, cause the method of any one of claims 1-24 to be performed.

30. A computer program product, characterised in that, comprising instructions which, when executed on a computer, cause the method of any one of claims 1-24 to be performed.

Images