Communication method and communication device

Abstract

The invention discloses a communication method and a communication device, and relates to the technical field of communication. In the method, a first node and a second node can interact a distributed account book capability parameter of the first node, the distributed account book capability parameter of the first node indicates the distributed account book capability of the first node, and the second node determines whether a request of allowing the first node to join a distributed account book is allowed according to the distributed account book capability of the first node. Therefore, the embodiment of the invention can support the first node to apply for adding the distributed account book more flexibly.

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 currently adopt a hard-coded manner to perform a process of adding a new node to the distributed ledger. For example, the new node inquires a hard-coded address, and obtains addresses of all nodes in the distributed ledger according to the hard-coded address, and the all nodes in the distributed ledger determine whether to accept the new node to join the distributed ledger. However, the above manner is not flexible enough, and the node cannot dynamically join the distributed ledger on demand. Therefore, how to support the node to more flexibly apply to join the distributed ledger is a technical problem to be solved at present. SUMMARY

[0004] The present application provides a communication method and a communication device, which can support the node to more flexibly apply to join the distributed ledger.

[0005] 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 distributed ledger, and the first request information indicating a distributed ledger capability parameter of the first node; and receiving first response information, the first response information being used for responding to the first information, and the first response information being related to the distributed ledger capability parameter of the first node.

[0006] The execution subject of the scheme in the first aspect can be a first communication device, wherein the first communication device can be the 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 logic node, logic module or software capable of realizing all or part of the functions of the first node, and the present application is not limited in this regard. For ease of description, the first node is taken as an example in the following description.

[0007] In the above solution, when the first node wants to join the distributed ledger, the first node sends first request information to the second node, the first request information indicating a distributed ledger capability parameter of the first node, the distributed ledger capability parameter of the first node indicating a distributed ledger capability of the first node, the second node determining whether to allow the first node to join the distributed ledger according to the distributed ledger capability of the first node, and sending response information to the first node indicating whether to allow the first node to join the distributed ledger.

[0008] Optionally, the first response information is used for responding to the first request information, which can be understood as: the first response information is used for indicating whether to allow the first node to join the distributed ledger, for example, the first response information is used for indicating to allow the first node to join the first distributed ledger, or the first response information is used for indicating to not allow the first node to join the first distributed ledger, and the like.

[0009] Through the above interaction process, the first node and the second node can interact the distributed ledger capability parameter of the first node, and the second node determines whether to allow the first node to join the request of the distributed ledger according to the distributed ledger capability parameter of the first node. In this way, the embodiment of the present application can support the first node to more flexibly apply to join the distributed ledger.

[0010] In some implementations of the first aspect, the first response information indicates to allow the first node to join the first distributed ledger, and the first response information further indicates a permission of the first node in the first distributed ledger, and the first node meets the capability requirement of the first distributed ledger.

[0011] When the first node is allowed to join the first distributed ledger, by indicating the permission of the first node in the first distributed ledger, the first node can perform corresponding functions in the first distributed ledger according to the permission. In this way, this can support the first node to more targetedly perform business or functions in the first distributed ledger or participate in the first distributed ledger.

[0012] In addition, this can support improving the running efficiency of the first distributed ledger, for example, only the nodes with consensus permission participate in consensus, and the nodes without consensus permission do not participate in consensus, which can shorten the time occupied by consensus and save resources, only the nodes with ledger storage permission save the ledger, which can save storage resources, and the like.

[0013] In some implementations of the first aspect, the first response information further indicates a configuration file of the first distributed ledger, and the configuration file of the first distributed ledger is used for the first node to join the first distributed ledger.

[0014] By indicating the configuration file of the first distributed ledger, the first node can correctly join the first distributed ledger according to the configuration file of the first distributed ledger.

[0015] In some implementations of the first aspect, before receiving the first response information, the method further includes: receiving first indication information, the first indication information indicating an address of an installation package of the distributed ledger, the installation package of the distributed ledger being used to support the first node to meet a capability requirement of the first distributed ledger; and sending second response information, the second response information indicating that the first node is installed successfully or fails to be installed.

[0016] Optionally, the first indication information can indicate the installation package of the distributed ledger.

[0017] When the first node is unable to meet the capability requirement of the first distributed ledger, by indicating the installation package of the distributed ledger, the first node can meet the capability requirement of the first distributed ledger by installing the installation package of the distributed ledger, thereby supporting the first node to join the first distributed ledger.

[0018] In some implementations of the first aspect, the first request information further indicates at least one of identification information of the distributed ledger or type information of the distributed ledger.

[0019] In this way, the second node can determine the distributed ledger that the first node wants to join, and can determine whether to allow the first node to join the distributed ledger according to the capability requirement of the distributed ledger.

[0020] In some implementations of the first aspect, before sending the first request information, the method further includes: determining a distributed ledger list, the distributed ledger list including distributed ledgers corresponding to the identification information of the distributed ledger and / or the type information of the distributed ledger.

[0021] In this way, the first node can determine the distributed ledger that it wants to join through the distributed ledger list, thereby supporting the first node to apply to join the distributed ledger on demand.

[0022] In some implementations of the first aspect, the first request information further indicates identity information of the first node.

[0023] By indicating the identity information of the first node, this can support the second node to complete identity verification of the first node, thereby improving the security when allowing the first node to join the distributed ledger.

[0024] In some implementations of the first aspect, the first response information indicates that the first node is allowed to join the first distributed ledger, and the method further includes: sending third response information, the third response information indicating that the first node is joined successfully or fails to be joined.

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

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

[0027] 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 second distributed ledger, and the second indication information indicating identification information of the second distributed ledger.

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

[0029] In some implementations of the first aspect, the third indication information further indicates a reason value, the reason value indicating a reason for the first node to exit the second distributed ledger.

[0030] In the 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 distributed ledger, and the first request information indicating a distributed ledger capability parameter of the first node; and sending first response information, the first response information being used for responding to the first request information, and the first response information being related to the distributed ledger capability parameter of the first node.

[0031] The execution subject of the solution of the second aspect can be a second communication apparatus, 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, or a logical node, a logical module or software capable of realizing all or part of the functions of the second node, and is not limited in this regard. For ease of description, the second node is taken as an example in the following description.

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

[0033] In some implementations of the second aspect, the sending of the first response information includes: receiving second request information, the second request information being related to the first request information; sending fourth response information, the fourth response information being used for responding to the second request information, the fourth response information being related to the distributed ledger capability parameter of the first node, and the first response information being related to the fourth response information.

[0034] In the above scheme, the second node establishes a connection with the first node through the other node, for example, the first node sends first request information to the other node, the other node sends second request information to the second node, the second node determines fourth response information, and sends the fourth response information to the other node, the other node determines the first response information according to the fourth response information, and sends the first response information to the first node. Wherein, the other node can determine that the receiving object of the first request information is the second node, and send the second request information to the second node.

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

[0036] In some implementations of the second aspect, the fourth response information indicates that the first node is allowed to join the first distributed ledger, and the fourth response information further indicates the authority of the first node in the first distributed ledger, and the first node meets the capability requirement of the first distributed ledger.

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

[0038] In some implementations of the second aspect, sending the first response information comprises: in response to determining that the distributed ledger capability parameter of the first node meets the capability requirement of the first distributed ledger, sending third request information, the third request information requesting to determine whether to allow the first node to join the first distributed ledger, and the third request information further indicating the distributed ledger capability parameter of the first node and the identification information of the first distributed ledger; receiving fifth response information, the fifth response information being used for responding to the third request information, and the fifth response information being related to the distributed ledger capability parameter of the first node; and sending the first response information, the first response information being related to the fifth response information.

[0039] In the above scheme, the second node determines whether to allow the first node to join the first distributed ledger through the interaction between the second node and the other node in the first distributed ledger, which is beneficial to improve the security when allowing the first node to join the first distributed ledger.

[0040] In some implementations of the second aspect, the third request information further indicates the authority of the first node in the first distributed ledger, and the first node meets the capability requirement of the first distributed ledger.

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

[0042] In some implementations of the second aspect, the sending the first response information comprises: determining that the distributed ledger capability parameter of the first node does not satisfy the capability requirement of the first distributed ledger, sending first indication information, the first indication information indicating an address of an installation package of a distributed ledger, the installation package of the distributed ledger being used to support the first node to satisfy the capability requirement of the first distributed ledger; receiving second response information, the second response information indicating an installation result of the installation package of the distributed ledger; and sending the first response information, the first response information being related to the installation result of the installation package of the distributed ledger.

[0043] Optionally, the first indication information can also indicate the installation package of the distributed ledger. In this way, the first node installs the installation package of the distributed ledger according to the first indication information, which can reduce the interaction overhead of the first node to obtain the installation package of the distributed ledger, for example, without the need to obtain the installation package of the distributed ledger again through the address of the installation package of the distributed ledger.

[0044] The specific description can be referred to the description of the beneficial effects of the first aspect, and will not be repeated here.

[0045] In some implementations of the second aspect, before the sending the first indication information, the method further comprises: sending fourth request information, the fourth request information requesting an address of an installation package of a distributed ledger; and receiving sixth response information, the sixth response information indicating the address of the installation package of the distributed ledger.

[0046] Optionally, the fourth request information can also be used to request the installation package of the distributed ledger.

[0047] Optionally, the sixth response information indicates the installation package of the distributed ledger.

[0048] In this way, the second node can obtain the installation package used to support the first node to satisfy the capability requirement of the first distributed ledger from the management node or the node used to store the installation package of the distributed ledger, thereby being able to support the first node to join the first distributed ledger.

[0049] In some implementations of the second aspect, the sending the first response information comprises: determining the first response information according to whether the distributed ledger capability parameter of the first node satisfies the capability requirement of the first distributed ledger; and sending the first response information.

[0050] In the above method, the second node can directly determine whether to allow the first node to join the distributed ledger according to the distributed ledger capability parameter of the first node, which can reduce the interaction overhead between the second node and other nodes.

[0051] In some implementations of the second aspect, before the sending the first response information, the method further comprises: determining an identity verification result of the first node.

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

[0053] In some implementations of the second aspect, the first response information indicates that the first node is allowed to join the first distributed ledger, and the first node meets the capability requirement of the first distributed ledger, and the method further comprises: receiving third response information, the third response information indicating that the first node joins successfully or fails to join.

[0054] In some implementations of the second aspect, the first response information indicates that the first node is allowed to join the first distributed ledger, and the first response information further indicates the rights of the first node in the first distributed ledger, and the first node meets the capability requirement of the first distributed ledger.

[0055] In some implementations of the second aspect, the first response information further indicates a configuration file of the first distributed ledger, and the configuration file of the first distributed ledger is used for the first node to join the first distributed ledger.

[0056] In some implementations of the second aspect, the first request information further indicates at least one of identification information of the distributed ledger or type information of the distributed ledger.

[0057] In some implementations of the second aspect, the distributed ledger capability parameter of the first node does not meet the distributed ledger corresponding to the identification information of the distributed ledger, and the distributed ledger capability parameter of the first node meets the capability requirement of the first distributed ledger, and the first response information indicates that the first node is allowed to join the first distributed ledger.

[0058] In some implementations of the second aspect, the distributed ledger capability parameter of the first node meets the distributed ledger corresponding to the type information of the distributed ledger, and the first response information indicates that the first node is allowed to join the first distributed ledger, and the type of the first distributed ledger is the type indicated by the type information of the distributed ledger.

[0059] In some implementations of the second aspect, the distributed ledger capability parameter of the first node does not meet the distributed ledger indicated by the type information of the distributed ledger, and the first response information indicates that the first node is not allowed to join the distributed ledger indicated by the type information of the distributed ledger.

[0060] In some implementations of the second aspect, the first request information further indicates identity information of the first node.

[0061] In some implementations of the second aspect, the first response information indicates that the first node is allowed to join the first distributed ledger, and the first node meets the capability requirement of the first distributed ledger, and the method further comprises: updating a node list of the first distributed ledger.

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

[0063] In some implementations of the second aspect, the method further includes: determining that the first node exits the second distributed ledger; and updating a node list of the second distributed ledger.

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

[0065] In some implementations of the second aspect, the third indication information further indicates a reason value, the reason value indicating a reason why the first node exits the second distributed ledger.

[0066] In some implementations of the second aspect, determining that the first node exits the second distributed ledger includes: receiving second indication information, the second indication information indicating that the first node exits the second distributed ledger, and the second indication information further indicating identification information of the second distributed ledger.

[0067] In a third aspect, a communication method is provided, including: receiving fourth request information, the fourth request information requesting an address of an installation package of the distributed ledger; and sending sixth response information, the sixth response information indicating the address of the installation package of the distributed ledger. The installation package of the distributed ledger is used to support the first node to join the first distributed ledger.

[0068] The execution subject of the solution of the third aspect can be a third communication apparatus. The third communication apparatus can be a management node, or a module, circuit or chip (such as a Modem chip, also known as a baseband chip, or a SoC chip or SIP chip containing a Modem core) in the management node, or a logic node, logic module or software capable of realizing all or part of the functions of the management node, and is not limited in this regard. For ease of description, the following describes the management node as an example.

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

[0070] In some implementations of the third aspect, the method further includes: receiving fourth indication information, the fourth indication information indicating that the first node joins the first distributed ledger.

[0071] Optionally, the fourth indication information further indicates a permission of the first node in the first distributed ledger.

[0072] In a certain implementation form of the third aspect, the method further comprises updating a configuration file of the first distributed ledger.

[0073] In a certain implementation form of the third aspect, the method further comprises sending fifth indication information, the fifth indication information indicating the nodes in the first distributed ledger to update a node list of the first distributed ledger.

[0074] When it is determined that the first node joins the first distributed ledger, the management node notifies the nodes in the first distributed ledger to update a node list of the first distributed ledger.

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

[0076] In a possible implementation form, the communication apparatus can include modules or units corresponding to the modules or units for performing the methods / operations / steps / actions described in the first aspect, which can be hardware circuits, software, or a combination of hardware circuits and software.

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

[0078] In a possible implementation form, the communication apparatus can include modules or units corresponding to the modules or units for performing the methods / operations / steps / actions described in the second aspect, which can be hardware circuits, software, or a combination of hardware circuits and software.

[0079] In a sixth aspect, a communication apparatus is provided, which can be the management node, or a device or module for performing the functions of the management node.

[0080] In a possible implementation form, the communication apparatus can include modules or units corresponding to the modules or units for performing the methods / operations / steps / actions described in the third aspect, which can be hardware circuits, software, or a combination of hardware circuits and software.

[0081] In a seventh 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 form of the first aspect, or to perform the methods described in the second aspect and any possible implementation form of the second aspect, or to perform the methods described in the third aspect and any possible implementation form of the third aspect, by executing computer programs or instructions, or by a logic circuit.

[0082] In a possible implementation, the communication apparatus further includes a memory for storing the computer program or instructions.

[0083] Optionally, the memory and the processor are integrated together.

[0084] In a possible implementation, the communication apparatus further includes a communication interface for inputting and / or outputting signals.

[0085] In an eighth aspect, a communication apparatus is provided, including a logic circuit and an input / output interface for inputting and / or outputting signals, and the logic circuit is configured to perform the method in the first aspect and any possible implementation of the first aspect, or the logic circuit is configured to perform the method in the second aspect and any possible implementation of the second aspect, or the logic circuit is configured to perform the method in the third aspect and any possible implementation of the third aspect.

[0086] In a ninth aspect, a computer readable storage medium is provided, and the computer readable storage medium stores a computer program or instructions, and when the computer program or the instructions are run on a computer, the method in the first aspect and any possible implementation of the first aspect is performed, or the method in the second aspect and any possible implementation of the second aspect is performed, or the method in the third aspect and any possible implementation of the third aspect is performed.

[0087] In a tenth aspect, a computer program product is provided, and the computer program product includes instructions, and when the instructions are run on a computer, the method in the first aspect and any possible implementation of the first aspect is performed, or the method in the second aspect and any possible implementation of the second aspect is performed, or the method in the third aspect and any possible implementation of the third aspect is performed.

[0088] In an eleventh aspect, a chip system is provided, and the chip system includes a processor configured to execute computer programs or instructions in the memory, so that the chip system implements the method in the first aspect and any possible implementation of the first aspect, or the chip system implements the method in the second aspect and any possible implementation of the second aspect, or the chip system implements the method in the third aspect and any possible implementation of the third aspect.

[0089] The beneficial effects of the fourth aspect to the eleventh aspect can be referred to the beneficial effects of the first aspect to the third aspect, and will not be described again. BRIEF DESCRIPTION OF DRAWINGS

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

[0091] Figure 2 is a schematic diagram of a distributed ledger anchoring function hierarchy 200 of embodiments of the application.

[0092] Figure 3 is a schematic diagram of a communication system 300 to which embodiments of the application are applicable.

[0093] Figure 4 is a schematic diagram of an interaction flow of a communication method 400 of embodiments of the application.

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

[0095] Figure 6 is a schematic diagram of an interaction flow of a communication method 600 of embodiments of the application.

[0096] Figure 7 is a schematic diagram of an interaction flow of a communication method 700 of embodiments of the application.

[0097] Figure 8 is a schematic diagram of an interaction flow of a communication method 800 of embodiments of the application.

[0098] Figure 9 is a schematic diagram of an interaction flow of a communication method 900 of embodiments of the application.

[0099] Figure 10 is a schematic diagram of an interaction flow of a communication method 1000 of embodiments of the application.

[0100] Figure 11 is a schematic diagram of an interaction flow of a communication method 1100 of embodiments of the application.

[0101] Figure 12 is a schematic diagram of an interaction flow of a communication method 1200 of embodiments of the application.

[0102] Figure 13 is a schematic diagram of an interaction flow of a communication method 1300 of embodiments of the application.

[0103] Figure 14 is a schematic diagram of an interaction flow of a communication method 1400 of embodiments of the application.

[0104] Figure 15 is a schematic diagram of an interaction flow of a communication method 1500 of embodiments of the application.

[0105] Figure 16 is a schematic diagram of an interaction flow of a communication method 1600 of embodiments of the application.

[0106] Figure 17is an interaction flow diagram of the communication method 1700 of an embodiment of the present application.

[0107] Figure 18 is an interaction flow diagram of the communication method 1800 of an embodiment of the present application.

[0108] Figure 19 is a schematic block diagram of the communication apparatus 1900 of an embodiment of the present application.

[0109] Figure 20 is a schematic block diagram of the communication apparatus 2000 of an embodiment of the present application. DETAILED DESCRIPTION

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

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

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

[0113] 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 number 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.

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

[0115] IV. The terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device containing 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 not clearly listed or inherent to these processes, methods, products or devices.

[0116] 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 must be carried in the information.

[0117] 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 other parts of the to-be-enabled information are 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.

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

[0119] 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 protocol, a fifth generation (5th generation, 5G) communication network protocol, a new radio (new radio, NR) protocol, a 5.5G communication network protocol, a sixth generation (6 th generation, 6G) communication network protocol, and a related protocol applied to a future communication system, which is not limited by the present application.

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

[0121] Nine, in the embodiments of the present application, unless otherwise specified, " / " represents that the objects before and after the correlation 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 relationships, for example, A and / or B can represent: A exists alone, A and B exist together, and B exists alone, wherein A and B can be singular or plural.

[0122] Ten, in the embodiments of the present application, indication includes direct indication (also known as explicit indication) and implicit indication. Direct indication information A means including the information A. Implicit indication information A means indicating information A by the corresponding relationship between information A and information B and directly indicating information B. The corresponding relationship between information A and information B can be pre-defined, pre-stored, pre-burned, or pre-configured.

[0123] Eleven, in the embodiments of the present application, information C is used for determination of information D, which includes that information D is determined only based on information C, 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.

[0124] Twelve, in the 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.

[0125] Thirteen, in the 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 similarly understood, which will not be described here.

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

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

[0128] The above-mentioned NF network elements can comprise network elements in existing standards, such as an access and mobility function management (AMF) network element and a session management function (SMF) network element, and can also comprise network elements newly defined in future standards, etc., and are not limited in this regard. 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 make special limitations on the DN.

[0129] When the DLAF has the capability of managing and configuring distributed ledgers within the telecommunications network infrastructure, the DLRF can be used to provide the storage function of the required software components. The DLRF collects the software library, tool kit and binary code of one or more distributed ledger implementations. The main function of the DLRF is to provide the corresponding software to the DLE when the DLE lacks a specific software capability. Specifically, the DLE sometimes does not have all the software required to run a distributed ledger network, such as a distributed consensus protocol. Therefore, when a certain DLE is selected but lacks a certain software, the DLAF will retrieve the software and install it on the target DLE, which can then run the distributed ledger service.

[0130] 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, such as 6G, Figure 1 Only part of the network elements in the network architecture are shown. Herein, the DLE can be replaced by a distributed ledger capability. The core network element deployed with the DLE can be referred to as a core network element with (or said to support) a distributed ledger capability. The terminal deployed with the DLE can be referred to as a terminal with (or said to support) a distributed ledger capability. The access network device deployed with the DLE can be referred to as an access network device with (or said to support) a distributed ledger capability. Among them, the distributed ledger can also be a blockchain or a distributed database or other types of databases, etc., which is not limited.

[0131] The DLAF is the anchor point of the overall management and association of the distributed ledger (such as the 6G 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 of the distributed ledger, etc. The DLAF is generally deployed in the form of a network function in the core network, and there can be a hierarchical structure, such as deploying a sub DLAF (sub LAF) in the access network, which is managed by the DLAF. Herein, the DLAF can be a core network element or an access network device, and the DLAF hereinafter refers to a core network element or an access network device deployed with the DLAF.

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

[0133] 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 nodes deployed with the DLE can have one or more of the following functions: transaction proposal, transaction endorsement / execution, smart contract deployment and execution, consensus, transaction / block synchronization, ledger storage, etc. The DLE exists in various nodes in the telecommunications network, including UEs, access network devices (e.g., base stations), core network elements. That is, nodes that need to have distributed ledger capabilities can deploy the DLE. It should be noted that the DLE can not be a physical module (or hardware entity), and the various nodes in the telecommunications network can install (or deploy) the DLE through a mirror code installation package of the DLE. For example, the core network element deployed with the DLE can also serve as a separate network function to provide distributed ledger proxy capabilities for other core network elements.

[0134] The DL client accepts the configuration and management of the DLAF and performs the generation and transmission of distributed ledger transactions, 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 UEs, access network devices (e.g., base stations), core network elements. It should be noted that the DL client can not be a physical module (or hardware entity), and the various nodes in the telecommunications network can install (or deploy) the DL client through a mirror code installation package of the DL client. For example, the core network element deployed with the DL client can also serve as a separate network function to provide transaction proposal services for other core network elements.

[0135] In a possible implementation, 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 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.

[0136] When DLAF is deployed in the access network, DLAF has the characteristics of layering, that is, the DLAF deployed in the core network is at a high level and can manage and configure the sub-DLAF at a lower level (such as the sub-DLAF in the access network). The sub-DLAF can manage and configure the DLE and / or DL ​​client of the connected access network node, and can also manage and configure the DLE and / or DL ​​client of the terminal device. At this time, the access network nodes and terminal devices governed (or managed) by the sub-DLAF are called the "subdomain" to which the sub-DLAF belongs, that is, the subdomain associated with the sub-DLAF. The subdomain can refer to all nodes (including terminal devices and access network devices) with DLE and / or DL ​​client deployed under the jurisdiction of the sub-DLAF. One or more nodes (access network devices or terminal devices) with DLE and / or DL ​​client deployed can be set under a DLAF, and one or more subdomains can also be set; one or more nodes with DLE and / or DL ​​client deployed and one or more subdomains can also be set. For example, after DLAF sets up a subdomain, DLAF does not directly manage the nodes deployed with DLE and / or DL ​​client in the subdomain, nor does it need to perceive their specific information. It only needs to issue instructions to the sub-DLAF based on the entire subdomain, which can reduce the workload of DLAF.

[0137] Figure 2 FIG. 2 is a schematic diagram of a DLAF layer 200 according to an embodiment of the present application. Figure 2 The example shown could be Figure 1 A part of (not shown). Figure 2 As shown, the DLAF in the core network (CN) is equipped with a node with a DLE, a node with a DL client, a sub-DLAF 1 (ie Figure 2 sub DLAF1) and sub DLAF 2 (i.e. Figure 2In the figure, sub DLAF 1 governs sub-domain 1, which includes multiple nodes (only three are shown, each of which is deployed with DLE#1, DLE#2 and DL client#1 respectively), and sub DLAF 2 governs sub-domain 2, which includes multiple nodes (only three are shown, each of which is deployed with DLE#3, DLE#4 and DL client#2 respectively). 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 be a super cell, in which one access network device (e.g., a base station) deploys a DLAF to manage multiple access network devices. In one possible implementation, the access network can have a hierarchical architecture, i.e., 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.

[0138] In the embodiments of the present application, the terminal equipment can also be referred to as user equipment (UE), access terminal, subscriber unit, subscriber station, mobile station, mobile station (MS), remote station, remote terminal, mobile device, user terminal, terminal, wireless communication device, user agent or user device.

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

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

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

[0142] 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 next generation NodeB in a 6th generation (6G) mobile communication system, 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 aircraft 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 other IAB node.

[0143] In another possible scenario, a terminal accesses a wireless network by cooperation of multiple access network devices, and different access network devices implement part of functions of a base station. For example, an access network device can be a central unit (CU), a distributed unit (DU), a CU-control plane (CP), a CU-user plane (UP), or a radio unit (RU), etc. The CU and the DU can be separately configured, or can be included in a same network element, for example, a baseband unit (BBU). The RU can be included in a radio frequency device or a radio frequency unit, for example, a remote radio unit (RRU), an active antenna unit (AAU), or a remote radio head (RRH). It can be understood that the access network device can be a CU node, or a DU node, or a device including the CU node and the DU node. In addition, the CU can be divided into an access network device in a radio access network (RAN), or the CU can be divided into an access network device in a core network (CN), which is not limited herein.

[0144] In different systems, the CU (or CU-CP and CU-UP), the DU, or the RU can also have different names, but those skilled in the art can understand their meanings. For example, in an ORAN system, the CU can also be referred to as an O-CU (open CU), the DU can also be referred to as an O-DU, the CU-CP can also be referred to as an O-CU-CP, the CU-UP can also be referred to as an O-CU-UP, and the RU can also be referred to as an O-RU. For the convenience of description, the CU, the CU-CP, the CU-UP, the DU, and the RU are taken as examples for description in this application. Any one of the CU (or the CU-CP, the CU-UP), the DU, and the RU in this application can be implemented by a software module, a hardware module, or a combination of the software module and the hardware module. The embodiments of this application do not limit the specific technology and the specific device form of the access network device.

[0145] To solve the technical problems as described in the background, the application provides a communication method and a communication device, which can support that nodes can be more flexibly joined in a distributed ledger.

[0146] For the convenience of description and understanding, the following describes from aspects of a communication system, a communication method, and a communication device, respectively.

[0147] I. Communication system

[0148] Figure 3is a schematic diagram of a communication system 300 to which embodiments of the present application are applicable. The communication system 300 comprises a first node and a second node. Optionally, the communication system 300 can further comprise a first distributed ledger, the first distributed ledger comprising at least one node. The first distributed ledger can represent one or more distributed ledgers.

[0149] In the communication system 300, the first node and the second node are nodes supporting distributed ledger function, or in other words, the first node and the second node can be nodes deploying DLE or DLEC.

[0150] In one possible implementation, the first node can be a DLE, and the second node can also be a DLE; or the first node is a DLE, and the second node is a DLAF, etc.

[0151] In another possible implementation, the first node and the second node are terminals deploying DLE or DLEC; or the first node and the second node are access network devices deploying DLE or DLEC; or the first node and the second node are NFs deploying DLE or DLEC; or the first node and the second node are respectively a terminal and an access network device deploying DLE or DLEC, etc., which are not limited.

[0152] The first distributed ledger can be a distributed ledger allowing the first node to join, or the first distributed ledger can be a distributed ledger that the first node wants to join. For ease of description, when the first node is allowed to join the distributed ledger, the following is described by taking the first node being allowed to join the first distributed ledger as an example.

[0153] The first node is a node applying to join the distributed ledger, and the second node is a node related to whether the first node is allowed to join the distributed ledger, or the second node is a node having a function or capability of judging or determining whether the first node is allowed to join the distributed ledger.

[0154] An example:

[0155] The first node applies to join the first distributed ledger, the second node is a trusted node (or a management node) in the first distributed ledger or a normal node, and the second node determines whether the first node is allowed to join the first distributed ledger.

[0156] Another example:

[0157] The first node applies to join the first distributed ledger, the second node manages one or more distributed ledgers (such as a DLAF), the one or more distributed ledgers comprising the first distributed ledger, and the second node determines whether the first node is allowed to join the first distributed ledger.

[0158] When the first node is allowed to join the distributed ledger, in one example, the first node is allowed to join the first distributed ledger, the first node meets the capability requirement of the first distributed ledger on the node, for example, the first distributed ledger requires that the node that wants to join the first distributed ledger needs to support consensus mechanism 1, security algorithm 1, ledger structure 1, etc., or the distributed ledger capability of the first node matches or corresponds to the capability requirement of the first distributed ledger on the node.

[0159] The first node has a connection relationship with the second node, for example, the first node is directly connected with the second node, or the first node establishes a connection with the second node through other nodes (taking the third node as an example). Among them, the first node can join the distributed ledger to which the second node belongs, or can join the distributed ledger that does not include the second node, which is not limited.

[0160] When the first node connects with the second node through the third node, the third node can save a distributed ledger list, the distributed ledger list includes one or more distributed ledgers, and the third node forwards the information about the request to join the distributed ledger from the first node to the second node, which is a node in the one or more distributed ledgers.

[0161] When the first node wants to apply to join the distributed ledger, the first node sends request information to the second node, the request information includes or indicates the distributed ledger capability parameter of the first node (other terms such as distributed ledger capability, distributed ledger capability information, or distributed ledger parameter can also be used, which is not limited), the distributed ledger capability parameter of the first node indicates the distributed ledger capability of the first node, for example, the distributed ledger capability parameter of the first node indicates the consensus mechanism, security algorithm, ledger structure, etc. supported by the first node. The second node determines whether to allow the first node to join the distributed ledger according to the distributed ledger capability parameter of the first node, and sends response information to the first node, the response information is used to indicate whether to allow the first node to join the distributed ledger.

[0162] In summary, the first node and the second node can interact the distributed ledger capability parameter of the first node, and the second node determines whether to allow the first node to join the request of the distributed ledger according to the distributed ledger capability parameter of the first node. Through the above process, the embodiment of the application can support the first node to join the distributed ledger more flexibly.

[0163] II. Communication method

[0164] For the convenience of understanding and description, the communication method of the embodiments of the present application is described below by taking the interaction between the first node and the second node as an example, but this should not constitute a limitation on the execution subject of the communication method. For example, the method executed by the node (such as the first node and / or the second node) can also be executed by the module (such as a circuit, a chip, or a chip system, etc.) of the node, and can also be implemented by a logical node, a logical module, or software that can realize all or part of the functions of the node.

[0165] Figure 4 FIG. 4 is a schematic diagram of an interaction flow of the communication method 400 of the embodiments of the present application. As shown in FIG. 4, the communication method 400 includes: Figure 4

[0166] S401, the first node sends first request information to the second node. Correspondingly, the second node receives the first request information.

[0167] The first request information is used for the first node to request to join the distributed ledger, and the first request information indicates the distributed ledger capability parameter of the first node. Wherein, the first request information indicated by the first request information that the first node requests to join the distributed ledger can be understood as: the first node has the demand to request to join any one of the distributed ledgers. At the same time, the distributed ledger capability parameter of the first node indicated by the first request information can be used to determine whether there is a distributed ledger that matches the distributed ledger capability parameter of the first node.

[0168] ​In a possible implementation, the distributed ledger capability parameter of the first node includes, but is not limited to, at least one of the following parameters: a consensus mechanism parameter, a security algorithm parameter, a ledger structure parameter, an incentive mechanism parameter, a wallet type parameter, a computing capability parameter, or a storage space capability parameter, and the like. The consensus mechanism parameter indicates a consensus mechanism supported by the first node, for example, one of a proof of work (PoW) algorithm, a proof of stake (PoS) algorithm, a delegated proof of stake (DPoS) algorithm, a practical byzantine fault tolerance (PBFT), and the like. The security algorithm parameter indicates a security algorithm supported by the first node, for example, a hash algorithm, a signature algorithm, an encryption algorithm, and the like. The ledger structure parameter indicates a ledger structure supported by the first node, for example, whether to support an editable capability, whether to adopt privacy protection, and the like. The incentive mechanism parameter indicates an incentive mechanism supported by the first node, for example, no incentive or an incentive (for example, a reward for completing a task or a reward for participating). The wallet type parameter indicates a wallet type supported by the first node, for example, a digital currency, a virtual currency, and the like. The computing capability parameter indicates a computing capability of the first node, and the storage space capability parameter indicates a storage space capability of the first node, and the like. When the first node is directly connected to the second node, the first node directly sends the first request information 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 the third node.

[0169] When the first request information does not include the identification information of the distributed ledger requested to join by the first node, the second node determines whether to allow the first node to join the distributed ledger to which the second node belongs according to the distributed ledger capability parameter of the first node and the distributed ledger to which the second node belongs.

[0170] When the first request information does not include the identification information of the distributed ledger requested to join by the first node, the second node manages one or more distributed ledgers, and the second node determines whether to allow the first node to join any one of the one or more distributed ledgers according to the distributed ledger capability parameter of the first node and the one or more distributed ledgers managed by the second node.

[0171] S402, the second node determines the first response information.

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

[0173] Optionally, the second information is used for responding to the first information, and can also be understood as: the second information is used for indicating whether to allow the first node to join the request of the distributed ledger, for example, the second information is used for indicating to allow the first node to join the first distributed ledger, or the second information is used for indicating to not allow the first node to join the first distributed ledger, and the like.

[0174] Optionally, when the first response information indicates to allow the first node to join the distributed ledger, the first response information can also indicate identification information of the distributed ledger, such as identification information of the first distributed ledger.

[0175] The first response information is related to the distributed ledger capability parameter of the first node. For example:

[0176] For example, when there is a distributed ledger matching the distributed ledger capability of the first node, the first response information indicates to allow the first node to join the distributed ledger (which can carry identification information of the distributed ledger), such as the first response information indicating to allow the first node to join the first distributed ledger (which can carry identification information of the first distributed ledger).

[0177] For another example, when there is a distributed ledger matching the distributed ledger capability of the first node, the first response information indicates to allow the first node to join the distributed ledger (carrying identification information of the distributed ledger).

[0178] For another example, when there is no distributed ledger matching the distributed ledger capability of the first node, the first response information indicates to not allow the first node to join any distributed ledger.

[0179] For example, when there is a distributed ledger matching the distributed ledger capability of the first node, the first response information indicates that there is a distributed ledger matching the distributed ledger capability of the first node (which can be one or more distributed ledgers).

[0180] Optionally, the first response information can also indicate identification information of the distributed ledger, and the first node determines whether to join the distributed ledger according to the identification information of the distributed ledger.

[0181] For another example, when there is no distributed ledger matching the distributed ledger capability of the first node, the first response information indicates that there is no distributed ledger matching the distributed ledger capability of the first node, and the first node determines not to apply to join the distributed ledger according to the information.

[0182] In the embodiment of the application, the second node can determine the first response information by itself, or can determine the first response information through interaction with other nodes.

[0183] Taking the second node determining the first response information by itself as an example:

[0184] Mode a1:

[0185] The second node belongs to the first distributed ledger, and the first request information does not include the identification information of the distributed ledger that the second node wants to join. 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 first distributed ledger. The second node determines the distributed ledger capability of the first node according to the distributed ledger capability parameter of the first node, and compares the distributed ledger capability of the first node with the capability requirement of the first distributed ledger on the node, so as to determine whether to allow the first node to join the first distributed ledger. Correspondingly, the second node determines the first response information according to the comparison result.

[0186] Mode a2:

[0187] The second node manages one or more distributed ledgers, and the first request information does not include the identification information of the distributed ledger that the second node wants to join. The second node determines the distributed ledger capability of the first node according to the distributed ledger capability parameter of the first node, and compares the distributed ledger capability of the first node with the capability requirement of each distributed ledger in the one or more distributed ledgers on the node, so as to determine whether to allow the first node to join the distributed ledger. Correspondingly, the second node determines the first response information according to the comparison result.

[0188] Optionally, when the second node determines that the distributed ledger capability of the first node meets the capability requirement of part of the distributed ledgers in the one or more distributed ledgers, the first response information can indicate that the first node is allowed to join part or all of the part of the distributed ledgers (for example, the first response information can indicate the identification information of the part or all of the distributed ledgers, etc.). Wherein, the first node can determine the distributed ledgers that need to be joined according to its own needs, which is not limited.

[0189] Taking the second node determining the first response information by interacting with other nodes as an example:

[0190] Mode b1:

[0191] The second node belongs to the first distributed ledger, the first request information does not include identification information of a distributed ledger that the first node wants to join, and 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 first distributed ledger according to this. The second node interacts with part of nodes or all nodes in the first distributed ledger according to a consensus mechanism of the first distributed ledger. The second node determines whether to allow the first node to join the first distributed ledger according to an execution result of the consensus mechanism, or determines the first response information. For example, when more than a first threshold of nodes in the first distributed ledger agree that the first node joins the first distributed ledger, the second node determines to allow the first node to join the first distributed ledger.

[0192] Optionally, when the second node determines that the first node does not meet the capability requirement of the first distributed ledger, and the second node also belongs to a plurality of distributed ledgers, the second node can determine whether there is a distributed ledger in the plurality of distributed ledgers that matches the distributed ledger capability of the first node, and interact with part of nodes or all nodes in the matched distributed ledger according to a matching result, determine whether to allow the first node to join the first distributed ledger according to an execution result of the consensus mechanism, or determine the first response information.

[0193] In one possible embodiment, the second node saves a distributed ledger list. When the second node determines that the distributed ledger capability of the first node does not meet the capability requirement of the first distributed ledger, the second node can send the first request information to nodes in one or more distributed ledgers in the distributed ledger list, and the nodes in the one or more distributed ledgers determine the first response information.

[0194] S403, the second node sends the first response information to the first node. Correspondingly, the first node receives the first response information.

[0195] When the first node is directly connected to the second node, the second node directly sends the first response information 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 the third node.

[0196] Through the above process, the embodiment of the application can support the first node to more flexibly apply to join the distributed ledger.

[0197] In one possible implementation, the method 400 can further include:

[0198] S404, the first node sends the third response information to the second node. Correspondingly, the second node receives the third response information.

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

[0200] When the first response information indicates that the first node is allowed to join the first distributed ledger, the third response information indicates that the first node successfully joins the first distributed ledger, or the third response information indicates that the first node fails to successfully join the first distributed ledger.

[0201] When the third response information indicates that the first node successfully joins the first distributed ledger, the second node can update a node list of the first distributed ledger, for example, the second node adds the first node into the node list of the first distributed ledger (the second node belongs to the first distributed ledger, or the second node manages the first distributed ledger). When the third response information indicates that the first node fails to successfully join the first distributed ledger, the second node can ignore the request of the first node to join the distributed ledger.

[0202] When the first distributed ledger represents a plurality of distributed ledgers, the first node can select to join part of the plurality of distributed ledgers or all of the plurality of distributed ledgers, which is not limited.

[0203] In one possible embodiment, the manner in which the first node determines to join the distributed ledger includes but is not limited to:

[0204] When it is determined that the plurality of distributed ledgers can be joined, the first one of the plurality of distributed ledgers (the one ranked first) is selected to be joined;

[0205] According to a configuration file of each of the plurality of distributed ledgers, the distributed ledger consuming the least computing resource (the simplest consensus mechanism) is selected to be joined; or,

[0206] According to the authority of the first node in each of the plurality of distributed ledgers, the distributed ledger with the highest authority is selected to be joined.

[0207] In this way, the first node can select the distributed ledger to be joined.

[0208] In an embodiment of the present application, the role of the node in the distributed ledger can include a full node, a light node, a micro node, a client, and the like. The role of the node in the distributed ledger is used to define different permissions of the node in the distributed ledger. For example, the full node has the following permissions: querying / reporting transactions, generating blocks, participating in consensus, writing a ledger, and saving a ledger; the light node has the following permissions: querying / reporting transactions, generating a distributed ledger, participating in consensus, and writing a ledger; the micro node has the following permissions: querying / reporting transactions and generating a distributed ledger; and the client has the following permissions: querying / reporting transactions.

[0209] In one possible embodiment, the first response information indicates that the first node is allowed to join the first distributed ledger, and the first response information can also indicate the permission or role of the first node in the first distributed ledger. The permission or role of the first node in the first distributed ledger can be determined according to the distributed ledger capability of the first node.

[0210] For example, if the first node supports strong computing power, the permission assigned to the first node supports the consensus mechanism. If more than half of the consensus nodes already exist in the first distributed ledger, the permission assigned to the first node does not support the consensus mechanism.

[0211] For another example, if the first node has storage space and a secure storage environment, the permission assigned to the first node allows saving distributed ledger data and the like.

[0212] The permission of the first node in the first distributed ledger can be configured by the second node itself, or can be configured by the second node and other nodes in the first distributed ledger, or can be configured by the DLAF, and the present application is not limited in this regard.

[0213] The foregoing permission can also be understood as a role. For example, configuring the permission of the first node in the first distributed ledger can be understood as configuring the role of the first node in the first distributed ledger, or in other words, when the first node determines the permission in the first distributed ledger, the first node can determine the role in the first distributed ledger, or in other words, when the first node determines the role in the first distributed ledger, the first node can determine the permission in the first distributed ledger, and the present application is not limited in this regard. Therefore, the foregoing permission can also be replaced by the role.

[0214] In one possible embodiment, the first response information indicates that the first node is allowed to join the first distributed ledger, and the first response information can also indicate the configuration file of the first distributed ledger, which is used for the first node to correctly join the first distributed ledger.

[0215] The configuration file of the first distributed ledger can be configured by the second node, configured by the second node and other nodes in the first distributed ledger, or configured by the DLAF, and the configuration file is not limited.

[0216] The configuration file of the first distributed ledger includes, but is not limited to, a security algorithm used by the first distributed ledger, a consensus mechanism, a ledger structure, a node list of the first distributed ledger, and the like. Accordingly, the first node selects a corresponding security algorithm, consensus mechanism, ledger structure, and the like to join the first distributed ledger.

[0217] By indicating the configuration file of the first distributed ledger, the first node can correctly join the first distributed ledger according to the configuration file of the first distributed ledger.

[0218] In one possible embodiment, the first request information can also indicate at least one of identification information of the distributed ledger or type information (or function information) of the distributed ledger.

[0219] Accordingly, the second node determines the distributed ledger that the first node wants to join (for example, determines that the first node wants to join the first distributed ledger) according to the identification information of the distributed ledger and / or the type information of the distributed ledger.

[0220] In the embodiments of the present application, the type of the distributed ledger can include, but is not limited to, a distributed ledger for saving certificates and identities, a distributed ledger for resource sharing, a distributed ledger for log auditing, and the like.

[0221] After the second node determines the distributed ledger that the first node wants to join, the second node determines whether to allow the first node to join the distributed ledger that the first node wants to join according to whether the distributed ledger capability of the first node meets the capability requirement of the distributed ledger that the first node wants to join, and determines the first response information according to the comparison result.

[0222] For example, the second node belongs to the first distributed ledger or the second node manages one or more distributed ledgers, the one or more distributed ledgers include the first distributed ledger, and the first request information includes the identification information of the first distributed ledger. The second node determines that the first node requests to join the first distributed ledger according to the identification information of the first distributed ledger in the first request information, and determines whether to allow the first node to join the first distributed ledger according to whether the distributed ledger capability parameter of the first node matches the capability requirement of the first distributed ledger.

[0223] For example, the second node belongs to the first distributed ledger or the second node manages one or more distributed ledgers including the first distributed ledger, and the first request information includes type information of a distributed ledger that the first node wants to join. The second node determines one or more distributed ledgers that the first node wants to join according to the type information, and determines whether to allow the first node to join the one or more distributed ledgers according to whether the distributed ledger capability parameter of the first node matches capability requirements of the one or more distributed ledgers.

[0224] In this way, the second node can determine the distributed ledger that the first node wants to join, and can determine whether to allow the first node to join the distributed ledger according to the capability requirements of the distributed ledger.

[0225] In one possible embodiment, the distributed ledger capability parameter of the first node does not satisfy the distributed ledger corresponding to the identification information of the distributed ledger, and the distributed ledger capability parameter of the first node satisfies the capability requirements of the first distributed ledger, and the first response information indicates that the first node is allowed to join the first distributed ledger.

[0226] The above is an example in which the distributed ledger capability parameter of the first node satisfies the first distributed ledger and the first response information indicates that the first node is allowed to join the first distributed ledger. When there are multiple distributed ledgers of the same type as the first distributed ledger, the first response information can also indicate that the first node is allowed to join other distributed ledgers of the same type as the first distributed ledger.

[0227] In this way, the second node can recommend the distributed ledger that the distributed ledger capability parameter of the first node satisfies or corresponds to to the first node.

[0228] In one possible embodiment, the distributed ledger capability parameter of the first node satisfies the distributed ledger corresponding to the identification information of the distributed ledger, and the first response information indicates that the first node is allowed to join the distributed ledger.

[0229] In one possible embodiment, the distributed ledger capability parameter of the first node satisfies the distributed ledger corresponding to the type information of the distributed ledger, and the first response information indicates that the first node is allowed to join the first distributed ledger, and the type of the first distributed ledger is the type indicated by the type information of the distributed ledger.

[0230] The above is an example in which the first response information indicates that the first node is allowed to join the first distributed ledger. When there are multiple distributed ledgers of the same type as the first distributed ledger, the first response information can also indicate that the first node is allowed to join other distributed ledgers of the same type as the first distributed ledger.

[0231] In a possible implementation, the distributed ledger capability parameter of the first node does not satisfy the distributed ledger indicated by the type information of the distributed ledger, and the first response information indicates that the first node is not allowed to join the distributed ledger indicated by the type information of the distributed ledger.

[0232] Optionally, the first response information can further indicate a distributed ledger satisfying the distributed ledger capability parameter of the first node, an identity of the distributed ledger being different from an identity of the distributed ledger that the first node wants to join, but belonging to a same type.

[0233] In a possible implementation, the first node can determine a distributed ledger list, the distributed ledger list including the distributed ledgers corresponding to the identity information and / or the type information of the distributed ledger. The description about the distributed ledger list can refer to Table 1. The content shown in Table 1 is only as an example, and is not as a final limitation.

[0234] Table 1

[0235] Distributed ledger Identity Type Node list Capability requirement Distributed ledger 1 Identity 1 Type 1 Node 1, Node 3 Capability requirement 1 Distributed ledger 2 Identity 2 Type 1 Node 1, Node 2 Capability requirement 2 Distributed ledger 3 Identity 3 Type 2 Node 1, Node 2, Node 3 Capability requirement 3

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

[0237] Distributed ledger 1, the identity being identity 1, the type being type 1, the node list including node 1 and node 3, and the capability requirement being capability requirement 1;

[0238] Distributed ledger 2, the identity being identity 2, the type being type 1, the node list including node 1 and node 2, and the capability requirement being capability requirement 2;

[0239] Distributed ledger 3, the identity being identity 3, the type being type 3, the node list including node 1, node 2 and node 3, and the capability requirement being capability requirement 3.

[0240] There can be multiple different distributed ledgers belonging to or corresponding to a same type, and no limitation is made in this regard.

[0241] The first node can obtain the above-described distributed ledger list in the following ways:

[0242] Obtained through a homepage of an operator;

[0243] Obtained from other nodes (such as a second node) through a request and response process, etc.

[0244] obtained from other nodes (e.g., the second node) through subscription and notification process, etc.

[0245] obtained from other nodes (e.g., the second node) through a process of exposing information (e.g., the distributed ledger list is carried in a broadcast message), etc.

[0246] When the first node determines the distributed ledger list, the first node selects a distributed ledger that the first node wants to join from the distributed ledger list, and indicates the distributed ledger that the first node wants to join to the second node through the manner of indicating the identification information and / or type information of the distributed ledger. The second node can also obtain the distributed ledger list through the foregoing manner. In this way, this can support the first node to apply to join the distributed ledger that the first node wants to join.

[0247] In one possible implementation, the first request information further indicates the identity information of the first node, for example, identification information or address (e.g., internet protocol (IP) address) information, etc. The second node completes the verification of the first node according to the identity information of the first node.

[0248] For example, the second node and the first node perform mutual authentication to obtain the verification result corresponding to the first node.

[0249] For example, the second node obtains the verification result corresponding to the first node from other nodes, which is not limited.

[0250] By indicating the identity information of the first node, this can support the second node to complete the identity verification of the first node, thereby improving the security when allowing the first node to join the distributed ledger.

[0251] The following further describes the determination process of the first response information in the first response information. Figures 5 to 7 Figure 4

[0252] Figure 5 is a schematic diagram of an interaction process of a communication method 500 of an embodiment of the present application. Figure 5 In the first response information, the second node belongs to the first distributed ledger, the second node establishes a connection with the first node through the third node, and the second node determines the first response information by itself. As shown in Figure 5 The communication method 500 includes the following steps.

[0253] S501, the first node sends first request information to the third node. Correspondingly, the third node receives the first request information.

[0254] S502, the third node sends second request information to the second node. Correspondingly, the second node receives the second request information. ​​

[0255] The second request information is related to the first request information, or the second request information is determined according to the first request information, or the second request information includes all or part of the content indicated by the first request information.

[0256] As shown in the foregoing, the third node saves the distributed ledger list, and the third node can determine the second request information in the following manner:

[0257] 1- The first request information includes the identification information of the first distributed ledger and the distributed ledger capability parameter of the first node. The third node determines that the first distributed ledger includes the second node, and the second request information is the same as the first request information.

[0258] 2- The first request information includes the type information of the distributed ledger that the first node wants to join and the distributed ledger capability parameter of the first node. The third node determines that the type of the first distributed ledger to which the second node belongs belongs to the type indicated by the foregoing type information, and the second request information is the same as the first request information, or the second request information includes the identification information of one or more distributed ledgers and the distributed ledger capability parameter of the first node. The distributed ledger corresponding to the identification information of the one or more distributed ledgers is corresponding to the distributed ledger corresponding to the type information indicated in the first request information. By carrying the identification information of the one or more distributed ledgers in the second request information, the second node can determine that the first node requests to join the distributed ledger to which the second node belongs (the identification information of the one or more distributed ledgers includes the identification information of the distributed ledger to which the second node belongs).

[0259] 3- The first request information includes the distributed ledger capability parameter of the first node. The third node determines that the distributed ledger capability parameter of the first node matches the first distributed ledger according to the foregoing distributed ledger list, and determines that the second node belongs to the first distributed ledger. The second request information is the same as the first request information, or the second request information includes the distributed ledger capability parameter of the first node and the identification information of one or more distributed ledgers (including the identification information of the first distributed ledger), and the distributed ledger capability of the first node meets the capability requirement of the one or more distributed ledgers. The second node can belong to part or all of the one or more distributed ledgers, which is not limited.

[0260] S503, the second node determines fourth response information.

[0261] The second node determines whether to allow the first node to join the first distributed ledger according to the distributed ledger capability of the first node, and determines the fourth response information according to the same. The fourth response information is used to respond to the second request information, or the fourth response information indicates whether to allow the request of the first node.

[0262] For example, the first request information includes the identification information of the first distributed ledger and the distributed ledger capability parameter of the first node, the second request information is the same as the first request information, and the second node can determine that the first node requests to join the first distributed ledger according to the identification information of the first distributed ledger. The second node can determine whether to allow the first node to join the first distributed ledger according to the distributed ledger capability parameter of the first node.

[0263] For example, the first request information includes type information of a distributed ledger that the first node wants to join and a distributed ledger capability parameter of the first node, the second request information is the same as the first request information, the second node can determine that the first node requests to join the first distributed ledger according to the type information in the second request information, and the second node can determine whether to allow the first node to join the first distributed ledger according to the distributed ledger capability parameter of the first node.

[0264] For example, the first request information includes type information of a distributed ledger that the first node wants to join and a distributed ledger capability parameter of the first node, the second request information includes identification information of one or more distributed ledgers and the distributed ledger capability parameter of the first node. The second node can determine that the first node requests to join the first distributed ledger according to the identification information in the second request information, and the second node can determine whether to allow the first node to join the first distributed ledger according to the distributed ledger capability parameter of the first node.

[0265] For example, the first request information includes a distributed ledger capability parameter of the first node, and the second request information is the same as the first request information. The second node can determine that the first node requests to join the first distributed ledger according to the destination of the second request information being the second node. The second node can determine whether to allow the first node to join the first distributed ledger according to the distributed ledger capability parameter of the first node.

[0266] For example, the first request information includes a distributed ledger capability parameter of the first node, and the second request information includes the distributed ledger capability parameter of the first node and identification information of one or more distributed ledgers (including identification information of the first distributed ledger). The second node can determine that the first node requests to join the first distributed ledger according to the identification information in the second request information, and the second node can determine whether to allow the first node to join the first distributed ledger according to the distributed ledger capability parameter of the first node.

[0267] When the second node determines not to allow the first node to join the first distributed ledger, the fourth response information indicates not to allow the first node to join the distributed ledger. When the second node determines to allow the first node to join the first distributed ledger, the fourth response information indicates to allow the first node to join the first distributed ledger. Optionally, when the fourth information response information indicates to allow the first node to join the first distributed ledger, the fourth response information can also indicate the identification information of the first distributed ledger and the like.

[0268] S504, the second node sends fourth response information to the third node. Correspondingly, the third node receives the fourth response information.

[0269] The third node can determine the first response information according to 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, which is not limited.

[0270] S505, the third node sends the first response information to the first node. Correspondingly, the first node receives the first response information.

[0271] In the above process, the second node determines whether to allow the first node to join the distributed ledger, and sends information indicating whether to allow the first node to join the distributed ledger to the third node, and the third node can forward the information to the first node. Through the above process, the embodiment of the present application can support the first node to join the distributed ledger more flexibly.

[0272] Figure 6 is the interaction flow diagram of the communication method 600 of the embodiment of the present application. Figure 6 In the above process, the second node belongs to the first distributed ledger, the second node is directly connected with the first node, and the second node determines the first response information by interacting with other nodes in the first distributed ledger. As shown in Figure 6 The communication method 600 includes:

[0273] S601, the first node sends first request information to the second node. Correspondingly, the second node receives the first request information.

[0274] S602, the second node sends third request information to the fourth node. Correspondingly, the fourth node receives the third request information.

[0275] For example, the second node determines whether the first node meets the capability requirements of the first distributed ledger based on the distributed ledger capability parameters of the first node. After the second node determines that the first node meets the capability requirements of the first distributed ledger, the second node sends a third request message to the fourth node. The third request message is used to request the fourth node to determine whether to allow the first node to join the first distributed ledger. The third request message also indicates the identification information of the first distributed ledger and the distributed ledger capability parameters of the first node.

[0276] The second node and the fourth node both belong to the first distributed ledger. The fourth node represents one or more nodes (excluding the second node) in the first distributed ledger.

[0277] S603: The fourth node determines fifth response information, where the fifth response information is used to respond to the third request information.

[0278] The fourth node may determine whether to allow the first node to join the first distributed ledger based on the first node's distributed ledger capabilities. Exemplarily, if the fourth node determines that the first node's distributed ledger capabilities meet the capability requirements of the first distributed ledger, then the first node may be allowed to join the first distributed ledger. Furthermore, if the fourth node determines that the first node's distributed ledger capabilities do not meet the capability requirements of the first distributed ledger, then the first node may not be allowed to join the first distributed ledger.

[0279] Optionally, the fourth node may also determine whether to allow the first node to join the first distributed ledger based on the node quantity requirement of the first distributed ledger.

[0280] For example, if the fourth node determines that the first node meets the capability requirements of the first distributed ledger, but the number of nodes in the first distributed ledger exceeds a second threshold, it may be determined that the first node is not allowed to join the first distributed ledger.

[0281] For another example, if the fourth node determines that the first node meets the capability requirements of the first distributed ledger and the number of nodes in the first distributed ledger does not exceed the second threshold, it may determine to allow the first node to join the first distributed ledger, and so on.

[0282] S604: The fourth node sends fifth response information to the second node. Correspondingly, the second node receives the fifth response information.

[0283] When the fourth node determines that the distributed ledger capabilities of the first node meet the capability requirements of the first distributed ledger, the fifth response information indicates that the first node is allowed to join the first distributed ledger. When the fourth node determines that the distributed ledger capabilities of the first node do not meet the capability requirements of the first distributed ledger, the fifth response information indicates that the first node is not allowed to join the first distributed ledger, or the fifth response information indicates that the first node is not allowed to join the distributed ledger.

[0284] The second node determines the first response information according to the fifth response information. When the second node determines that more than a third threshold of nodes in the first distributed ledger (for example, more than two-thirds of the nodes) agree to allow the first node to join the first distributed ledger, the first response information indicates that the first node is allowed to join the first distributed ledger. When the second node determines that no more than two-thirds of the nodes in the first distributed ledger agree to allow the first node to join the first distributed ledger, the first response information indicates that the first node is not allowed to join the first distributed ledger.

[0285] In one possible implementation, the third request information further indicates a right of the first node in the first distributed ledger. In this way, the fourth node can confirm the right of the first node allocated by the second node in the first distributed ledger, and then determine whether to allow the first node to join the first distributed ledger according to the right.

[0286] For example, the second node allocates a right of the first node in the first distributed ledger to support consensus, and the fourth node determines that more than half of the nodes in the first distributed ledger support consensus, and then determines that the first node is not allowed to join the first distributed ledger.

[0287] For another example, the second node allocates a right of the first node in the first distributed ledger to support consensus, and the fourth node determines that less than half of the nodes in the first distributed ledger support consensus, and then determines that the first node is allowed to join the first distributed ledger.

[0288] S605, the second node sends the first response information to the first node. Correspondingly, the first node receives the first response information.

[0289] Through the above process, the embodiments of the present application can support that whether to allow the first node to join the first distributed ledger is determined by multiple nodes in the first distributed ledger, which is beneficial to improve the security when the first node joins the first distributed ledger.

[0290] Figure 6 Although the embodiments of the present application are described by taking that whether to allow the first node to join the first distributed ledger is determined by multiple nodes in the first distributed ledger as an example, the embodiments of the present application also support that whether to allow the first node to join the first distributed ledger is determined by the second node directly according to the distributed ledger capability parameter of the first node, which is beneficial to reduce the interaction overhead between nodes.

[0291] Figure 7 FIG. 7 is an interaction flow diagram of a communication method 700 according to an embodiment of the present application. Figure 7 In the embodiment, the second node belongs to the first distributed ledger, the second node is connected with the first node, and the second node determines the first response information by itself. As shown in FIG. 7, the communication method 700 includes: Figure 7 S701, the second node receives a third request information from the first node.

[0292] S701, the first node sends a first request to the second node. Correspondingly, the second node receives the first request information.

[0293] S702, the second node determines that the distributed ledger capability parameter of the first node does not meet the capability requirement of the first distributed ledger, and the second node determines the address of the installation package of the distributed ledger.

[0294] Optionally, the second node can also determine the installation package of the distributed ledger. For example, the second node stores one or more installation packages of the distributed ledger, the second node can determine the required installation package of the distributed ledger according to the demand, or the second node obtains one or more installation packages of the distributed ledger from other nodes, etc., which is not limited.

[0295] For example, the second node sends a fourth request information to the DLAF, the fourth request information is used to request to obtain the address of the installation package of the distributed ledger or the installation package of the distributed ledger; the DLAF sends a sixth response information to the second node, the sixth response information indicates the address of the installation package of the distributed ledger or the installation package of the distributed ledger.

[0296] The installation package of the distributed ledger can support the first node to meet the capability requirement of the first distributed ledger. The fourth request information can include the identification information of the first distributed ledger, and the DLAF determines the address of the installation package or the installation package of the distributed ledger which can support the capability requirement of the first distributed ledger according to the identification information.

[0297] In a possible implementation, the DLAF can obtain the address of the installation package of the distributed ledger or the installation package of the distributed ledger through interaction with the DLRF. The DLRF is used to store the address of the installation package of the distributed ledger or the installation package of the distributed ledger.

[0298] S703, the second node sends a first indication information to the first node. Correspondingly, the first node receives the first indication information.

[0299] The first indication information indicates the address of the installation package of the distributed ledger or the installation package of the distributed ledger. The first node determines the installation package of the distributed ledger according to the first indication information, and realizes the capability requirement of the first distributed ledger through the installation package of the distributed ledger.

[0300] S704, the first node sends a second response information to the second node. Correspondingly, the second node receives the second response information.

[0301] The second response information indicates an installation result of the installation package of the distributed ledger. For example, the second response information indicates that the first node successfully installs the installation package of the distributed ledger, or the second response information indicates that the first node fails to successfully install the installation package of the distributed ledger.

[0302] S705, the second node sends first response information to the first node. Correspondingly, the first node receives the first response information.

[0303] The first response information is related to an installation result of the installation package of the distributed ledger. For example, the second response information indicates that the first node successfully installs the installation package of the distributed ledger, and the first response information indicates that the first node is allowed to join the first distributed ledger; for example, the second response information indicates that the first node fails to successfully install the installation package of the distributed ledger, and the first response information indicates that the first node is not allowed to join the distributed ledger.

[0304] Through the above process, when the first node does not meet the capability requirement of the first distributed ledger, the second node sends an address of an installation package for supporting the first node to meet the capability requirement of the first distributed ledger or an installation package of the distributed ledger to the first node, and the first node meets the capability requirement of the first distributed ledger through the installation package of the distributed ledger, which can support the first node to join the first distributed ledger.

[0305] The method shown in Figure 8 and Figure 9 will be further described below. Figure 4

[0306] For ease of description, the first node is taken as DLE0, the second node is taken as DLE1, or the DLAF is taken as an example for description below.

[0307] Figure 8 is an interaction flow diagram of the communication method 800 of the embodiment of the application. Figure 8 In the communication method 800, the second node is DLE1, and DLE1 belongs to the first distributed ledger. As shown in Figure 8 , the communication method 800 includes the following steps.

[0308] Optionally, S801, the DLE0 determines a distributed ledger list, and the distributed ledger list includes the first distributed ledger.

[0309] S802, the DLE0 sends first request information to the DLE1. Correspondingly, the DLE1 receives the first request information.

[0310] The first request information indicates that the DLE0 joins the first distributed ledger, and the first request information indicates the identification information of the first distributed ledger and the distributed ledger capability parameter of the DLE0.

[0311] ​For example, the DLE1 judges whether the DLE0 matches the capability requirement of the first distributed ledger, for example, whether the DLE0 supports the consensus mechanism, security algorithm, ledger capability, and the like configured by the first distributed ledger. When the DLE1 determines that the DLE0 meets the capability requirement of the first distributed ledger, the DLE1 determines to allow the DLE0 to join the first distributed ledger.

[0312] Optionally, the DLE1 allocates the rights (such as reading, writing, saving the ledger, participating in consensus, and the like) of the DLE0 in the first distributed ledger. The rights allocated or configured by the DLE1 for the DLE0 can be no more than the rights of the DLE1, for example, the DLE1 supports reading and writing the ledger but does not support consensus, and the rights allocated by the DLE1 for the DLE0 are also reading and writing the ledger but do not support consensus.

[0313] Optionally, the DLE1 does not allocate the rights of the DLE0, but the DLAF allocates the rights of the DLE0 in the first distributed ledger.

[0314] Optionally, S803a, the DLE1 sends third request information to the nodes in the first distributed ledger. Correspondingly, the first distributed ledger receives the third request information.

[0315] The description of the third request information can be referred to the description in the method 600, and will not be repeated.

[0316] Optionally, S803b, the first distributed ledger sends fifth response information to the DLE1. Correspondingly, the DLE1 receives the fifth response information.

[0317] The description of the fifth response information can be referred to the description in the method 600, and will not be repeated.

[0318] S804, the DLE1 determines the first response information.

[0319] The description of S804 can be referred to the description in the method 600, and will not be repeated.

[0320] Optionally, S805a, the DLE1 sends fourth indication information to the DLAF. Correspondingly, the DLAF receives the fourth indication information.

[0321] The fourth indication information indicates that the DLE0 joins the first distributed ledger, and the fourth indication information further indicates the identification information of the first distributed ledger, the identification information of the DLE0, and the rights of the DLE0 in the first distributed ledger. Correspondingly, the DLAF can update the locally saved distributed ledger configuration file (if including the first distributed ledger).

[0322] Optionally, DLAF configures permissions for DLE0 in the first distributed ledger. For example, DLAF assigns permissions to DLE0 based on DLE0's distributed ledger capabilities and the operation of the distributed ledger in the network. For example, if DLE0 supports strong computing power, the permissions assigned by DLAF to DLE0 support consensus. However, if more than half of the consensus nodes already exist in the first distributed ledger, the permissions assigned by DLAF to DLE0 do not support consensus. The permissions configured by DLAF for DLE0 can be the same as or different from those configured by DLE1 for DLE0, and this is not limited to this.

[0323] Optionally, in S805b, the DLAF sends seventh response information to the DLE 1. Correspondingly, the DLE 1 receives the seventh response information.

[0324] The seventh response information indicates that the DLAF has updated the information of the locally stored distributed ledger configuration file.

[0325] S806: DLE1 sends a first response message to DLE0. Correspondingly, DLE0 receives the first response message.

[0326] Optionally, in S807, DLE0 sends third response information to DLE1. Correspondingly, DLE1 receives the third response information.

[0327] For the description of the third response information, please refer to the description of method 400 and will not be repeated here.

[0328] After DLE0 successfully joins the first distributed ledger, DLE1 and DLE0 can transfer data about the first distributed ledger. If DLE0's permissions or role are configured as a node that supports saving ledgers, such as a full node, DLE1 needs to synchronize the ledger data with DLE0.

[0329] Figure 9 It is a schematic diagram of the interaction flow of the communication method 900 according to an embodiment of the present application. Figure 9 In the example, the third node is DLE1 and the second node is DLAF. Figure 9 As shown, the communication method 900 includes:

[0330] Optionally, S901 and DLE0 determine a distributed ledger list, where the distributed ledger list includes a first distributed ledger.

[0331] S902: DLE0 sends a first request message to DLE1. Correspondingly, DLE1 receives the first request message.

[0332] The first request information instructs DLE0 to join the first distributed ledger, and the first request information indicates identification information of the first distributed ledger and distributed ledger capability parameters of DLE0.

[0333] S903, the DLE1 sends second request information to the DLAF. Correspondingly, the DLAF receives the second request information.

[0334] Optionally, the DLAF verifies the DLE0 and obtains a verification result about the DLE0. For example, after obtaining the authentication result of the DLE0, the DLAF can determine whether to re-initiate authentication for the DLE0. If the authentication result of the DLE0 in the core network exceeds the validity period, the DLAF needs to re-initiate authentication for the DLE0, and at this time, a bidirectional authentication process needs to be performed between the DLAF and the DLE0.

[0335] Optionally, the DLAF allocates the DLE0 a right in the first distributed ledger.

[0336] S904, the DLAF sends fourth response information to the DLE1. Correspondingly, the DLE1 receives the fourth response information. The fourth response information indicates whether the DLE0 is allowed to join the first distributed ledger.

[0337] Optionally, the fourth response information can carry identification information of the first distributed ledger.

[0338] Optionally, the fourth response information can further indicate a right of the DLE0 in the first distributed ledger and a configuration file of the first distributed ledger, etc.

[0339] S905, the DLE1 determines the first response information.

[0340] For example, the DLE1 determines the first response information according to the fourth response information. Illustratively, the fourth response information indicates that the DLE0 is allowed to join the first distributed ledger, the first response information indicates that the DLE0 is allowed to join the first distributed ledger, or the fourth response information indicates that the DLE0 is not allowed to join the first distributed ledger, the first response information indicates that the DLE0 is not allowed to join the first distributed ledger, etc.

[0341] S906, the DLE1 sends the first response information to the DLE0. Correspondingly, the DLE0 receives the first response information.

[0342] Optionally, the first response information can carry identification information of the first distributed ledger.

[0343] Optionally, the first response information can further indicate a right of the DLE0 in the first distributed ledger and a configuration file of the first distributed ledger, etc.

[0344] Optionally, S907, the DLE0 sends third response information to the DLE1. Correspondingly, the DLE1 receives the third response information.

[0345] Optionally, S908, DLE1 sends third response information to DLAF. Correspondingly, DLAF receives the third response information.

[0346] DLAF can determine whether DLE0 successfully joins the first distributed ledger according to the third response information.

[0347] Optionally, S909, DLAF sends fifth indication information to the nodes in the first distributed ledger. Correspondingly, the first distributed ledger receives the fifth indication information.

[0348] In one possible implementation, when it is determined that the first node successfully joins the first distributed ledger, the DLAF sends fifth indication information to the nodes in the first distributed ledger, the fifth indication information indicating that DLE0 successfully joins the first distributed ledger, and the fifth indication information also indicating the identity information of the first distributed ledger, the identity information of DLE0, and the authority of DLE0 in the first distributed ledger. Other nodes in the first distributed ledger list update the node list of the first distributed ledger. For example, S909 is executed after S908.

[0349] In one possible implementation, when the DLAF determines to allow DLE0 to join the first distributed ledger, the DLAF can also send fifth indication information to the nodes in the first distributed ledger, the fifth indication information indicating that DLE0 joins the first distributed ledger. The nodes in the first distributed ledger can update the node list of the first distributed ledger. Wherein, the nodes in the first distributed ledger can determine whether DLE0 successfully joins the first distributed ledger according to whether the data of DLE0 is received. When it is determined that DLE0 does not successfully join the first distributed ledger, the nodes in the first distributed ledger can delete DLE0 from the node list of the first distributed ledger. For example, S909 can be executed before S908.

[0350] After DLE0 successfully joins the first distributed ledger, DLE0 transmits data about the first distributed ledger with a certain node in the first distributed ledger. If DLE0 is configured as a full node, the node needs to synchronize the ledger data to DLE0.

[0351] When the DLAF does not indicate the node with which DLE0 establishes a connection relationship, DLE0 can select any node from the received node list in the first distributed ledger for communication.

[0352] Figure 9 Taking that DLE0 sends first request information to DLAF through DLE1 as an example, DLE0 can also directly send first request information to DLAF, and DLAF can also directly send fourth response information to DLE0, and the specific details are not repeated.

[0353] Figure 9 is taken as an example, the second node can also be a node in the first distributed ledger, which determines or judges whether to allow the DLE0 to join the first distributed ledger, which can be referred to as Figure 9 and Figure 5 , and details are not repeated.

[0354] The above is about how the first node joins the distributed ledger, and the following describes how the first node exits the distributed ledger.

[0355] The first node can exit the distributed ledger according to device usage (for example, the current other function occupies more resources, the distributed ledger is in low priority, and therefore needs to exit the distributed ledger to release the part of occupied computing and storage resources), the first node moves to cause disconnection with the DLAF or other nodes, or due to user demand, network administrator (operator) configuration and other factors, the first node decides to exit the distributed ledger. When the first node wants to exit the second distributed ledger (only as an example), the first node indicates to the second node that the first node exits the second distributed ledger, 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, the network administrator decides to delete the second distributed ledger. Details can be referred to as Figure 10 .

[0356] Figure 10 is an interaction flow diagram of the communication method 1000 of the embodiment of the application. As shown in Figure 10 , the communication method 1000 includes:

[0357] Optionally, S1001, the first node sends second indication information to the second node. Correspondingly, the second node receives the second indication information.

[0358] When the first node wants to exit the second distributed ledger, the first node can send second indication information to the second node, and the second indication information indicates that the first node exits the second distributed ledger. The second indication information can also indicate the identification information of the second distributed ledger, the identification information of the first node, etc. The second distributed ledger can be the same as or different from the first distributed ledger, which is not limited.

[0359] S1002, the second node determines that the first node exits the second distributed ledger.

[0360] In the embodiment of the application, the way in which the second node determines that the first node exits the second distributed ledger can include the following:

[0361] Method 1: The first node sends second indication information to the second node;

[0362] Manner 2: The second node does not receive data from the first node within a period of time.

[0363] Through the above method, the embodiment of the application can support the second node to determine that the first node exits the second distributed ledger.

[0364] Optionally, S1003, the second node sends third indication information to the first node. Correspondingly, the first node receives the third indication information.

[0365] The third indication information is used to indicate that the first node exits the second distributed ledger. Specifically, when the second distributed ledger is deleted or the first node cannot meet the capability requirement of the second distributed ledger, the second node can instruct the first node to exit the second distributed ledger.

[0366] Optionally, the third indication information can also indicate a reason value, which is used to indicate the reason for the first node to exit the second distributed ledger, etc. For example, the reason can include but is not limited to that the second distributed ledger has completed the task, or the first node cannot meet the capability requirement of the first distributed ledger, etc.

[0367] S1004, the second node updates the node list of the second distributed ledger.

[0368] When the second node determines that the first node exits the second distributed ledger, the second node can update the node list of the second distributed ledger.

[0369] Through the above scheme, the embodiment of the application can support establishing a mechanism for the first node to exit the distributed ledger, thereby supporting better management of the distributed ledger.

[0370] The following describes the method shown in Figure 11 and Figure 12 further. The following describes the first node as DLE0 and the second node as DLE1 or DLAF. Figure 10

[0371] Figure 11 is an interaction flow diagram of the communication method 1100 of the embodiment of the application. As shown in Figure 12 , the communication method 1100 includes:

[0372] Optionally, S1101, DLE0 sends second indication information to DLE1. Correspondingly, DLE1 receives the second indication information.

[0373] ​The second indication information indicates that the DLE0 exits the second distributed ledger. The second indication information can further indicate identification information of the second distributed ledger, identification information of the DLE0, and the like. The second distributed ledger can be the same as or different from the first distributed ledger, which is not limited.

[0374] The DLE1 belongs to the second distributed ledger.

[0375] S1102, The DLE1 determines that the DLE0 exits the second distributed ledger.

[0376] In the embodiment of the application, the manner in which the DLE1 determines that the DLE0 exits the second distributed ledger can include the following:

[0377] Manner 1: The DLE0 sends second indication information to the DLE1.

[0378] Manner 2: The DLE1 does not receive data from the DLE0 within a period of time.

[0379] Through the above method, the embodiment of the application can support the DLE1 to determine that the DLE0 exits the second distributed ledger.

[0380] S1103, The DLE1 sends sixth indication information to the nodes in the second distributed ledger. Correspondingly, the nodes in the second distributed ledger receive the sixth indication information.

[0381] The sixth indication information is used to indicate that the DLE0 exits the second distributed ledger. The nodes in the second distributed ledger can update a node list of the second distributed ledger, for example, delete the first node from the node list of the second distributed ledger.

[0382] Optionally, S1104, the DLE1 sends seventh indication information to the DLAF. Correspondingly, the DLAF receives the seventh indication information.

[0383] The seventh indication information is used to indicate that the DLE0 exits the second distributed ledger. The seventh indication information can further indicate identification information of the second distributed ledger and identification information of the DLE0, and the like. When the DLAF saves a configuration file of the second distributed ledger, the DLAF can update the configuration file of the second distributed ledger, for example, delete the DLE0 from a node list of the second distributed ledger, and the like.

[0384] Optionally, S1105, the DLE1 sends eighth response information to the DLE0. Correspondingly, the DLE0 receives the eighth response information.

[0385] The eighth response information is used for responding to the second indication information. For example, the eighth response information is used for indicating that the DLE1 determines that the DLE0 exits the second distributed ledger, and the like. Where the connection between the DLE0 and the DLE1 has been disconnected, the DLE1 can not send the eighth response information to the DLE0.

[0386] Figure 12 is an interaction flow diagram of the communication method 1200 of the embodiment of the present application. As shown in Figure 11 , the communication method 1200 includes the following steps.

[0387] S1201, the DLE0 sends second indication information to the DLE1. Correspondingly, the DLE1 receives the second indication information. The DLE1 sends the second indication information to the DLAF. Correspondingly, the DLAF receives the second indication information.

[0388] The second indication information indicates that the DLE0 exits the second distributed ledger. The second indication information further indicates identification information of the second distributed ledger, identification information of the DLE0, and the like. The second distributed ledger can be the same as or different from the first distributed ledger, which is not limited.

[0389] S1202, the DLAF determines that the DLE0 exits the second distributed ledger.

[0390] S1203, the DLAF sends eighth indication information to nodes in the second distributed ledger. Correspondingly, the nodes in the second distributed ledger receive the eighth indication information.

[0391] The eighth indication information is used for indicating that the DLE0 exits the second distributed ledger. The nodes in the second distributed ledger can update a node list of the second distributed ledger, for example, delete the first node from the node list of the second distributed ledger.

[0392] S1204, the DLAF sends ninth response information to the DLE0. Correspondingly, the DLE0 receives the ninth response information.

[0393] The ninth response information is used for responding to the second indication information, for example, for indicating that the DLAF determines that the DLE0 exits the second distributed ledger, and the like.

[0394] Figure 12 and Figure 13 to 18 The content shown in the above is described by taking the DLE0 actively exiting the second distributed ledger as an example. The DLE0 can also passively exit the second distributed ledger.

[0395] For example, the DLAF deletes the second distributed ledger, and sends third indication information to the DLE0, which is used for indicating that the DLE0 exits the second distributed ledger.

[0396] Optionally, the third indication information can further indicate a cause value, the cause value indicating a cause of the DLE0 exiting the second distributed ledger, and the like. For example, the cause includes, but is not limited to, that the second distributed ledger has completed a task, that the DLE0 cannot meet a capability requirement of the second distributed ledger, and the like.

[0397] In the embodiments of the present application, the first node and the second node can be devices in a communication network, for example, the first node is a terminal device or a network device, and the second node is a network device, and the like. Correspondingly, the above information can be information transmitted between devices in the communication network, for example, the first request information and the first response information are information transmitted between a terminal device and a network device (the network device includes an access network device and a core network element, and the like), or the first request information and the first response information are information transmitted between network devices. When the first information and the second information are information transmitted between devices in the communication network, the embodiments of the present application can support introducing or applying the distributed ledger technology in the communication network.

[0398] The following will be described in combination with Figure 13 to 18 for further description.

[0399] It should be noted that Figure 13 to 18 the information names, interface names and protocol names appearing in the embodiments of the present application are only examples and are not limited. Among them, Figure 13 the information names, interface names and protocol names in the existing standards appearing in the embodiments of the present application can also use new term names in future standards, which are not limited.

[0400] Figure 1 is an interaction flow diagram of the communication method 1300 of the embodiments of the present application. The first node is UE1, and the second node is RAN1. Among them, UE1 and RAN1 can be devices deployed with a DLE or a DLEC as described in the embodiments of the present application. Figure 13 Figure 14 As shown in the figure, the communication method 1300 includes the following steps.

[0401] S1301, UE1 sends first request information to RAN1. Correspondingly, RAN1 receives the first request information.

[0402] The first request information indicates that UE1 joins a first distributed ledger, identification information of the first distributed ledger, and a distributed ledger capability parameter of UE1.

[0403] For example, UE1 sends the first request information through a radio resource control (RRC) setup request (RRC setup request) message, or the first request information is carried in the RRC setup request message. ​

[0404] Another example, UE1 sends first request information through an access stratum (AS) security mode capability (AS Security mode cap) message (a newly added message, only as an example, not as a limitation), or the first request information is carried in the AS Security mode cap message.

[0405] In the above, the UE1 can obtain the distributed ledger list from the RAN1, and the distributed ledger list includes the first distributed ledger.

[0406] An example, the RAN1 broadcasts a system information block (SIB) to the UE1, and the SIB includes the distributed ledger list, and the distributed ledger list includes the distributed ledger to which the RAN1 belongs. Optionally, the UE1 can also obtain the distributed ledger list through interaction with the RAN1.

[0407] Another example, the RAN1 broadcasts an AS Security mode cap (a newly added message, only as an example, not as a limitation) message to the UE1, and the AS Security mode cap message includes the distributed ledger list, and the distributed ledger list includes the distributed ledger to which the RAN1 belongs.

[0408] S1302, the RAN1 verifies the UE1.

[0409] The RAN1 obtains the authentication result of the UE1. In this regard, the RAN1 can obtain the authentication result of the UE1 by the existing process of the authentication server function (AUSF), or can obtain the authentication result of the UE1 based on the existing cryptography technology and the UE1, and the authentication result of the UE1 is not limited.

[0410] S1303, the RAN1 determines the first response information.

[0411] When the RAN1 belongs to the first distributed ledger, the RAN1 determines whether to allow the UE1 to join the first distributed ledger by the method 400.

[0412] When the RAN 1 does not belong to the first distributed ledger, the RAN 1 sends the first request information or the second request information to the AMF. For example, the first request information or the second request information is sent to the AMF through a next generation application protocol (NGAP) protocol. The AMF belongs to the first distributed ledger. The AMF determines whether the UE 1 is allowed to join the first distributed ledger through the method 500. It should be noted that the embodiments of the present application can support adding a new information element in the NGAP protocol to carry the first request information.

[0413] If the AMF does not belong to the first distributed ledger, the AMF can send the first request information to the DLAF. For example, the first request information is sent through a service based interface (SBI). The DLAF can determine whether the UE 1 is allowed to join the first distributed ledger through the foregoing method.

[0414] S1304, the RAN 1 sends the first response information to the UE 1. Correspondingly, the UE 1 receives the first response information.

[0415] When the UE 1 sends the first request information through an RRC setup request message, the RAN 1 can send the first response information through an RRC setup response message, or the first response information can be carried in the RRC setup response message.

[0416] When the UE 1 sends the first request information through an AS Security mode cap message, the RAN 1 can send the first response information through an access stratum security mode command (AS Security mode command) (a new information, only as an example, not as a limitation) message, or the first response information is carried in the AS Security mode command message.

[0417] S1305, the UE 1 sends the third response information to the RAN 1. Correspondingly, the RAN 1 receives the third response information.

[0418] In one example, the UE 1 sends the third response information through an access stratum security mode complete (AS Security mode complete) (a new information, only as an example, not as a limitation) message, or the third response information is carried in the AS Security mode complete message.

[0419] When UE1 exits the second distributed ledger, UE1 can send an AS Security mode command message to RAN1, which carries the identity of the second distributed ledger and declares the action is exit.

[0420] Figure 14 is an interaction flow diagram of the communication method 1400 of the embodiment of the application. The first node is UE1, and the second node is AMF. As shown in Figure 15 the communication method 1400 includes the following steps.

[0421] S1402, UE1 sends first request information to AMF. Correspondingly, AMF receives the first request information.

[0422] In one example, UE1 sends the first request information through a non-access stratum (NAS) registration request message, or the first request information is carried in the NAS registration request message.

[0423] In another example, UE1 sends the first request information through a non-access stratum security mode cap (as a newly added information, only as an example, not as the final limitation), or the first request information is carried in the NAS security mode cap message.

[0424] Wherein, AMF can obtain the distributed ledger list from DLAF through the function of NEF exposure, or directly from DLAF. Wherein, AMF can also send the distributed ledger list to UE1, which is not limited.

[0425] S1402, AMF verifies UE1.

[0426] AMF obtains the authentication result of UE1. Wherein, AMF can obtain the authentication result of UE1 from AUSF through the existing process, or can perform mutual authentication with UE1 based on the existing cryptography to obtain the authentication result of UE1, which is not limited.

[0427] S1403, AMF determines the first response information.

[0428] When AMF belongs to the first distributed ledger, AMF determines whether to allow UE to join the first distributed ledger through the method 400.

[0429] When the AMF does not belong to the first distributed ledger, the AMF sends first request information to the DLAF through an SBI. The DLAF determines whether to allow the UE to join the first distributed ledger through the foregoing method.

[0430] S1404, the AMF sends first response information to the UE1. Correspondingly, the UE1 receives the first response information.

[0431] For example, the AMF sends the first response information through a NAS registration accept message, or the first response information is carried in the NAS registration accept message.

[0432] S1405, the UE1 sends third response information to the AMF. Correspondingly, the AMF receives the third response information.

[0433] For example, the UE1 sends the third response information through a non-access layer security mode complete (NAS Security mode complete) message, or the third response information is carried in the NAS Security mode complete message.

[0434] When the UE1 exits the second distributed ledger, the UE1 can send a non-access layer security mode command (NAS Security mode command) (new information, only as an example, not as a limitation) message to the AMF, the NAS Security mode command message carries the identity of the second distributed ledger, and declares the action is exit.

[0435] Figure 15 is an interaction flow diagram of a communication method 1500 of an embodiment of the application. The first node is RAN1, and the second node is RAN2.

[0436] As shown in Figure 16 , the communication method 1500 includes:

[0437] S1501, the RAN1 sends first request information to the RAN2. Correspondingly, the RAN2 receives the first request information.

[0438] The RAN1 can send the first request information through an Xn setup request message, or the first request information is carried in the Xn setup request message.

[0439] In the embodiments of the present application, RAN2 can perform an Xn interface establishment process with RAN1. Among them, the verification process can be completed between RAN1 and RAN2. For example, RAN2 determines that the locally saved RAN list includes RAN1, and RAN2 determines that RAN1 is a trusted RAN; or, RAN2 and RAN1 first perform mutual authentication, and then RAN2 determines that RAN1 is a trusted RAN.

[0440] After verification, RAN2 receives the first request information and determines the distributed ledger that RAN1 wants to join. Among them, the embodiments of the present application can support changes to the XnAP protocol so that the interaction between RAN1 and RAN2 about the first request information can be supported.

[0441] S1502, RAN2 verifies RAN1.

[0442] RAN2 can verify RAN1 through existing processes.

[0443] S1503, RAN2 determines the first response information.

[0444] When RAN2 belongs to the first distributed ledger, RAN2 determines whether to allow RAN1 to join the first distributed ledger through method 400.

[0445] When RAN2 does not belong to the first distributed ledger, RAN2 sends the first request information to the AMF through the NGAP protocol. If the AMF belongs to the first distributed ledger, the AMF determines whether to allow RAN1 to join the first distributed ledger through method 400.

[0446] If the AMF does not belong to the first distributed ledger, the AMF sends the first request information to the DLAF through SBI. The DLAF can determine whether to allow RAN1 to join the first distributed ledger according to method 800.

[0447] S1504, RAN2 sends the first response information to RAN1. Correspondingly, RAN1 receives the first response information.

[0448] For example, RAN2 sends the first response information through the Xn setup response message, or the first response information is carried in the Xn setup response message.

[0449] S1505, RAN1 sends the third response information to RAN2. Correspondingly, RAN2 receives the third response information.

[0450] When RAN1 exits the second distributed ledger, RAN1 can send information indicating that RAN1 exits the second distributed ledger through the XnAP protocol.

[0451] Figure 16 FIG. 16 is an interaction flow diagram of a communication method 1600 according to an embodiment of the present application. The first node is RAN1, and the second node is AMF.

[0452] As shown in FIG. 16, the communication method 1600 includes the following steps. Figure 17

[0453] S1601, RAN1 sends first request information to AMF. Correspondingly, the AMF receives the first request information.

[0454] For example, RAN1 sends the first request information through an NG establishment request message.

[0455] The AMF can perform an NG interface establishment process with RAN1. In this process, the AMF and RAN1 can complete an authentication process. For example, the AMF determines that the locally saved RAN list includes RAN1, and determines that RAN1 is a trusted RAN; or the AMF and RAN1 perform mutual authentication, and then the AMF determines that RAN1 is a trusted RAN.

[0456] After authentication, the AMF receives the first request information and determines the distributed ledger that RAN1 wants to join. In this embodiment of the present application, the NGAP protocol can be modified to support the interaction between the AMF and RAN1 regarding the first request information.

[0457] The AMF can obtain the distributed ledger list from the DLAF through the NEF exposure function, or directly from the DLAF. The AMF can also send the distributed ledger list to RAN1, which is not limited.

[0458] S1602, the AMF authenticates RAN1.

[0459] The AMF can authenticate RAN1 through an existing process.

[0460] S1603, the AMF determines first response information.

[0461] When the AMF belongs to the first distributed ledger, the AMF determines whether to allow RAN1 to join the first distributed ledger through method 400.

[0462] When the AMF does not belong to the first distributed ledger, the AMF sends the first request information to the DLAF through SBI. The DLAF determines whether to allow RAN1 to join the first distributed ledger through the method described above.

[0463] S1604, the AMF sends the first response information to RAN1. Correspondingly, RAN1 receives the first response information.​

[0464] For example, the AMF sends the first response information through the NG setup response message, or the first response information is carried in the NG setup response message.

[0465] S1605, the RAN 1 sends the third response information to the AMF. Correspondingly, the AMF receives the third response information.

[0466] When the RAN1 exits the second distributed ledger, the RAN1 can send information indicating that the RAN1 exits the second distributed ledger through the NGAP protocol.

[0467] Figure 17 FIG. 17 is an interaction flow diagram of a communication method 1700 according to an embodiment of the present application. The first node is NF1, and the second node is DLAF. As shown in FIG. 17, the communication method 1700 includes the following steps. Figure 18

[0468] S1701, the NF1 sends first request information to the DLAF. Correspondingly, the DLAF receives the first request information.

[0469] For example, the NF1 sends the first request information to the DLAF through the SBI.

[0470] It should be noted that the NF1 can obtain the distributed ledger list from the DLAF through the NEF exposure function, or directly from the DLAF.

[0471] S1702, the DLAF verifies the NF1.

[0472] The DLAF can verify the NF1 through an existing process.

[0473] S1703, the DLAF determines the first response information.

[0474] The DLAF determines whether to allow the NF1 to join the first distributed ledger through the method 400.

[0475] S1704, the DLAF sends the first response information to the NF1. Correspondingly, the NF1 receives the first response information.

[0476] For example, the DLAF sends the first response information through the SBI.

[0477] S1705, the NF1 sends the third response information to the DLAF. Correspondingly, the DLAF receives the third response information.

[0478] ​When the NF1 exits the second distributed ledger, the NF1 can send information indicating that the NF1 exits the second distributed ledger to the DLAF through the SBI.

[0479] Figure 18 is an interaction flow diagram of a communication method 1800 of an embodiment of the present application. The first node is UE1, and the second node is AMF. As shown in Figure 7 the communication method 1800 includes the following steps.

[0480] S1801, UE1 sends first request information to AMF. Correspondingly, the AMF receives the first request information.

[0481] In one example, UE1 sends the first request information through a NAS registration request message, or the first request information is carried in the NAS registration request message.

[0482] In another example, UE1 sends the first request information through a NAS Security mode cap message, or the first request information is carried in the NAS Security mode cap message.

[0483] S1802, the AMF authenticates UE1.

[0484] The AMF obtains the authentication result of UE1. The AMF can obtain the authentication result of UE1 by the existing process, or can obtain the authentication result of UE1 based on the existing cryptography technology and UE1, and the authentication result of UE1 is not limited.

[0485] S1803, the AMF sends information for requesting the address of the installation package of the distributed ledger to the DLRF. Correspondingly, the DLRF receives the information through the DLAF.

[0486] S1804, the DLRF sends the address of the installation package of the distributed ledger to the AMF. Correspondingly, the AMF receives the address of the installation package of the distributed ledger through the DLRF.

[0487] S1805, the AMF sends first indication information to UE1. Correspondingly, UE1 receives the first indication information.

[0488] S1806, UE1 sends second response information to AMF. Correspondingly, the AMF receives the second response information.

[0489] S1807, the AMF determines the first response information.

[0490] S1808, the AMF sends the first response information to UE1. Correspondingly, UE1 receives the first response information.

[0491] S1809, the UE1 sends third response information to the AMF. Correspondingly, the AMF receives the third response information.

[0492] The specific description can refer to the description of Figure 19 , and will not be repeated here.

[0493] When the UE1 exits the second distributed ledger, the UE1 can send a NAS Security mode command (non-access layer security mode command) message to the AMF, the NAS Security mode command message carrying the identifier of the second distributed ledger and declaring the action is exit.

[0494] III. Communication device

[0495] To implement the functions in the method provided in the present application, the first node and the second node can each include a hardware structure and / or a software module to implement the above functions in the form of hardware structure, software module, or hardware structure plus software module. Whether a certain function in the above functions is executed in the form of hardware structure, software module, or hardware structure plus software module depends on the specific application of the technical solution and the design constraint conditions.

[0496] Figure 19 is a schematic block diagram of the communication device 1900 of an embodiment of the present application. The communication device 1900 includes processing circuitry 1910 and transceiver circuitry 1920, which can be connected or coupled to each other, such as through a bus 1930. The communication device 1800 can be the first node or the second node.

[0497] Optionally, the communication device 1900 can further include a memory 1940. The memory 1940 includes but is not limited to a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), or a compact disc read-only memory (CD-ROM). The memory 1940 is any other medium capable of carrying or storing desired program code in the form of instructions or data structures and capable of being accessed by a computer, but is not limited thereto. The memory in the embodiments of the present application can also be a circuit or any other device capable of realizing a storage function, used for storing computer programs or instructions, and / or data.

[0498] The processing circuit 1910 can be all or part of one or more processors, or be one or more processors. The processor can be a central processing unit (CPU). In the case of the processing circuit 1910 being a CPU, the CPU can be a single core CPU, or a multi-core CPU. The processing circuit 1910 can be a signal processor, a chip, or other integrated circuits that can implement the method of the present application, or be part of the foregoing processor, chip or integrated circuit for processing functions. In addition, the transceiver circuit 1920 can also be a transceiver, or an input / output interface, an input / output interface for input or output of signals or data, and can also be referred to as an input / output circuit.

[0499] When the communication apparatus 1900 is the first node, the processing circuit 1910 is configured to perform the following operations, for example: sending the first request information, and receiving the first response information, etc.

[0500] When the communication apparatus 1900 is the second node, the processing circuit 1910 is configured to perform the following operations, for example: receiving the first request information, determining the first response information, sending the first response information, etc.

[0501] When the communication apparatus 1900 is the first node or the second node, it will be responsible for performing the methods or steps related to the first node or the second node in the foregoing method embodiments.

[0502] When the communication apparatus 1900 is the first node or the second node, the transceiver circuit 1920 can be a transceiver.

[0503] When the communication apparatus 1900 is a chip for the first node or the second node, the transceiver circuit 1920 can be an input / output circuit.

[0504] The foregoing description is only an exemplary description. The specific content can refer to the content shown in the foregoing method embodiments.

[0505] Figures 4 to 18 The implementation of each operation in the foregoing description can also correspond to the description of the method embodiments shown in Figure 20

[0506] Figure 20 is a schematic block diagram of a communication apparatus 2000 of an embodiment of the present application. The communication apparatus 2000 can be a first node or a second node, and is configured to implement the method related in the foregoing embodiments.

[0507] ​The communication device 2000 includes a transceiver unit 2010 and a processing unit 2020. The transceiver unit 2010 may include a transmitting unit and a receiving unit. The transmitting unit is configured to perform a transmitting operation of the communication device, and the receiving unit is configured to perform a receiving operation of the communication device. For ease of description, this embodiment of the application combines the transmitting unit and the receiving unit into a single transceiver unit. This is described here as a unified description and will not be repeated later.

[0508] When the communication device 2000 is a first node, illustratively, the transceiver unit 2010 is used to send first request information and receive first response information; the processing unit 2020 is used to determine the first request information, etc.

[0509] When the communication device 2000 is the second node, illustratively, the transceiver unit 2010 is used to: receive first request information and send first response information; the processing unit 2020 is used to determine the first response information, etc.

[0510] When the communication device 2000 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.

[0511] Optionally, the communication device 2000 further includes a storage unit 2030, which is used to store a program or code for executing the aforementioned method.

[0512] Figure 19 The transceiver unit in can correspond to Figure 20 The transceiver circuit in Figure 19 The processing units in can correspond to Figure 19 The processing circuit in .

[0513] Figure 20 and Figures 4 to 18 The device embodiment shown is for implementing Figure 19 The content described. Figure 20 and ​ The specific execution steps and methods of the device shown can refer to the contents described in the aforementioned method embodiment.

[0514] The present application also provides a chip including a processor configured to retrieve and execute instructions stored in a memory, so that a communication device equipped with the chip executes the methods described in the above examples. The memory may be integrated within the chip or located outside the chip.

[0515] The present 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 via an internal connection path, and the processing circuit is used to execute the code in the memory. When the code is executed, the processing circuit is used to execute the methods in the above examples.

[0516] Optionally, the chip further comprises a memory for storing computer programs or codes. The input interface and the output interface can be independent of each other, or can be integrated into an input / output interface.

[0517] The processing circuit can be all or part of one or more processors, or one or more processors.

[0518] The present application also provides a processor for coupling with a memory, for executing the method and functions of any of the above embodiments involving a network device or a terminal device.

[0519] In another embodiment of the present application, a computer program product containing instructions is provided, when the computer program product is run on a computer, the method of the above embodiments is implemented.

[0520] The present application also provides a computer program, when the computer program is run on a computer, the method of the above embodiments is implemented.

[0521] In another embodiment of the present application, a computer readable storage medium is provided, the computer readable storage medium stores a computer program, when the computer program is executed by a computer, the method of the above embodiments is implemented.

[0522] It should be understood that, in the embodiments of the present application, the processor can be a CPU, and the processor can also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor.

[0523] In addition, the processor may also include one or more combinations of 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 network processor (NPU).

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

[0525] The above-described embodiments can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented by software, the above-described embodiments can be implemented in whole or in part in the form of a computer program product. The 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, the processes or functions described in the embodiments of the present application are wholly or partially generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable apparatus. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center through a wired or wireless (such as infrared, wireless, microwave, etc.) manner. The computer-readable storage medium can be any available medium accessible by a computer or a data storage device such as a server, data center, etc. containing one or more available medium sets. The available medium can be a magnetic medium (such as a floppy disk, a hard disk, a magnetic tape), an optical medium (such as a DVD), or a semiconductor medium. The semiconductor medium can be a solid-state disk.

[0526] It should be understood that the size of the sequence number of each process described above in various embodiments of the present application does not mean the order of execution, and the execution order of each process should be determined according to its function and inherent logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0527] Those skilled in the art can appreciate that the units and algorithm steps of the examples described in combination with the embodiments disclosed herein can be realized by electronic hardware or a combination of computer software and electronic hardware. Whether the functions are realized 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 realize the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application. Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described system, device and unit can refer to the corresponding processes in the foregoing method embodiments, which will not be described here. In several embodiments provided in the present application, it should be understood that the disclosed system, device and method can be implemented in other ways. For example, the above-described device embodiments are only schematic, for example, the division of units is only a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units shown or discussed can be indirect coupling or communication connection through some interface, device or unit, and can be electrical, mechanical or other forms.

[0528] The units described as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, i.e. can be located in one place or can be distributed to multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiment according to actual needs. In addition, the functional units in each embodiment of the present application can be integrated in one processing unit, or each unit can be physically present alone, or two or more units can be integrated in one unit. When the above functions are realized in the form of software function units and sold or used as independent products, they can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application essentially or the parts that make contributions to the prior art or parts of the technical solutions can be embodied in the form of software products, which are stored in a storage medium and include a number of instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) execute all or part of the steps of the methods described in each embodiment of the present application. The foregoing storage medium includes: U disk, mobile hard disk, read-only memory, random access memory, magnetic disk or optical disk, and various program code storage media.

[0529] Those skilled in the art can realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be realized in electronic hardware, or a combination of computer software and electronic hardware. Whether the functions are realized in hardware or software depends on specific applications and design constraints of the technical solutions. Those skilled in the art can use different methods to realize the described functions for each specific application, but such implementation should not be considered beyond the scope of the present 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 distributed ledger, the first request information indicating a distributed ledger capability parameter of the first node; receiving first response information, the first response information being used for responding to the first request information, the first response information being related to the distributed ledger capability parameter of the first node.

2. The method of claim 1, wherein, The first response information indicates that the first node is allowed to join a first distributed ledger, and the first response information further indicates a right of the first node in the first distributed ledger, the first node meeting a capability requirement of the first distributed ledger.

3. The method of claim 2, wherein, The first response information further indicates a configuration file of the first distributed ledger, the configuration file of the first distributed ledger being used for the first node to join the first distributed ledger.

4. The method according to any one of claims 1 to 3, characterized in that, Before the receiving of the first response information, the method further comprises: receiving first indication information, the first indication information indicating an address of an installation package of a distributed ledger, the installation package of the distributed ledger being used for supporting the first node to meet the capability requirement of the first distributed ledger; sending second response information, the second response information indicating that the first node is successfully installed or fails to be installed.

5. The method according to any one of claims 1 to 4, characterized in that The first request information further indicates at least one of identification information of the distributed ledger or type information of the distributed ledger.

6. The method of claim 5, wherein, Before the sending of the first request information, the method further comprises: determining a distributed ledger list, the distributed ledger list comprising distributed ledgers corresponding to the identification information of the distributed ledger and / or the type information of the distributed ledger.

7. The method according to any one of claims 1 to 6, characterized in that, The first request information further indicates identity information of the first node.

8. The method according to any one of claims 2 to 7, characterized in that, The first response information indicates that the first node is allowed to join the first distributed ledger, and the method further comprises: sending third response information, the third response information indicating that the first node is successfully joined or fails to be joined.

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

10. The method according to any one of claims 1 to 9, characterized in that, The method further comprises: sending second indication information, the second indication information indicating that the first node exits a second distributed ledger, the second indication information indicating identification information of the second distributed ledger.

11. The method according to any one of claims 1 to 9, characterized in that, The method further comprises: receiving third indication information, the third indication information indicating that the first node exits a second distributed ledger, the third indication information comprising identification information of the second distributed ledger.

12. The method of claim 11, wherein, The third indication information further indicates a reason value, the reason value indicating a reason why the first node exits the second distributed ledger.

13. A method of communication, comprising: The method comprises: receiving first request information, the first request information being used for a first node to request to join a distributed ledger, the first request information indicating a distributed ledger capability parameter of the first node; The first response information is sent, the first response information being used for responding to the first request information, and the first response information being related to the distributed ledger capability parameter of the first node.

14. The method of claim 13, wherein, The first response information is sent, the first response information being used for responding to the first request information, and the first response information being related to the distributed ledger capability parameter of the first node. Second request information is received, the second request information being related to the first request information. Fourth response information is sent, the fourth response information being used for responding to the second request information, the fourth response information being related to the distributed ledger capability parameter of the first node, and the fourth response information being related to the first response information.

15. The method of claim 14, wherein, The fourth response information indicates that the first node is allowed to join a first distributed ledger, and the fourth response information further indicates a right of the first node in the first distributed ledger, and the first node meets a capability requirement of the first distributed ledger.

16. The method of claim 13, wherein, The first response information is sent, the first response information being used for responding to the first request information, and the first response information being related to the distributed ledger capability parameter of the first node. Third request information is sent in response to a determination that the distributed ledger capability parameter of the first node meets a capability requirement of a first distributed ledger, the third request information requesting a determination of whether the first node is allowed to join the first distributed ledger, and the third request information further indicating the distributed ledger capability parameter of the first node and identification information of the first distributed ledger. Fifth response information is received, the fifth response information being used for responding to the third request information, and the fifth response information being related to the distributed ledger capability parameter of the first node. The first response information is sent, the first response information being related to the fifth response information.

17. The method of claim 16, wherein, The third request information further indicates the right of the first node in the first distributed ledger.

18. The method of claim 13, wherein, The first response information is sent, the first response information being used for responding to the first request information, and the first response information being related to the distributed ledger capability parameter of the first node. Second response information is received, the second response information indicating an installation result of the installation package of the distributed ledger. The first response information is sent, the first response information being related to the installation result of the installation package of the distributed ledger. Before the first indication information is sent, the method further includes:

19. The method of claim 18, wherein, Fourth request information is sent, the fourth request information requesting an address of the installation package of the distributed ledger. Sixth response information is received, the sixth response information indicating the address of the installation package of the distributed ledger. The first response information is sent, the first response information being used for responding to the first request information, and the first response information being related to the distributed ledger capability parameter of the first node.

20. The method of claim 13, wherein, The first response information is sent, the first response information being used for responding to the first request information, and the first response information being related to the distributed ledger capability parameter of the first node. The first response information indicates that the first node is allowed to join a first distributed ledger, and the first node meets a capability requirement of the first distributed ledger, and the method further includes: Third response information is received, the third response information indicating that the first node joins successfully or fails to join.

21. The method according to any one of claims 13 to 20, characterized in that, ​ ​ 22. The method of any one of claims 13-21, wherein, The first response information indicates that the first node is allowed to join the first distributed ledger, and the first response information further indicates a permission of the first node in the first distributed ledger, and the first node meets a capability requirement of the first distributed ledger.

23. The method of claim 22, wherein, The first response information further indicates a configuration file of the first distributed ledger, and the configuration file of the first distributed ledger is used for the first node to join the first distributed ledger.

24. The method of any one of claims 13-23, wherein, The first request information further indicates at least one of identification information of the distributed ledger or type information of the distributed ledger.

25. The method of claim 24, wherein, The distributed ledger capability parameter of the first node does not meet a distributed ledger corresponding to the identification information of the distributed ledger, and the distributed ledger capability parameter of the first node meets a capability requirement of the first distributed ledger, and the first response information indicates that the first node is allowed to join the first distributed ledger.

26. The method of claim 24, wherein, The distributed ledger capability parameter of the first node meets a distributed ledger corresponding to the type information of the distributed ledger, and the first response information indicates that the first node is allowed to join the first distributed ledger, and the first distributed ledger is of a type indicated by the type information of the distributed ledger.

27. The method of claim 24, wherein, The distributed ledger capability parameter of the first node does not meet a distributed ledger indicated by the type information of the distributed ledger, and the first response information indicates that the first node is not allowed to join the distributed ledger indicated by the type information of the distributed ledger.

28. The method of any one of claims 13-27, wherein, The first request information further indicates identity information of the first node.

29. The method of claim 28, wherein, Before the first response information is sent, the method further includes: According to the identity information of the first node, a result of identity authentication of the first node is determined.

30. The method of any one of claims 13-29, wherein, The first response information indicates that the first node is allowed to join the first distributed ledger, and the first node meets a capability requirement of the first distributed ledger, and the method further includes: A node list of the first distributed ledger is updated.

31. The method of any one of claims 13 to 30, wherein The first request information and the first response information are information transmitted between a terminal device and a network device; or The first request information and the first response information are information transmitted between network devices.

32. The method of any one of claims 13-31, wherein, The method further includes: It is determined that the first node exits a second distributed ledger. A node list of the second distributed ledger is updated.

33. The method of claim 32, wherein, The method further includes: Third indication information is sent, the third indication information indicating that the first node exits the second distributed ledger, and the third indication information further indicating identification information of the second distributed ledger.

34. The method of claim 33, wherein, The third indication information further indicates a reason value, and the reason value indicates a reason why the first node exits the second distributed ledger.

35. The method of any one of claims 32-34, wherein, The determination that the first node exits a second distributed ledger includes: Second indication information is received, the second indication information indicating that the first node exits a second distributed ledger, and the second indication information further indicating identification information of the second distributed ledger.

36. A communications device, characterized by The communication device comprises a processor for causing the communication device to perform the method of any one of claims 1 to 35 by executing computer programs or instructions, or by logic circuitry.

37. The communication apparatus of claim 36, wherein The communication device further comprises a memory for storing the computer programs or instructions.

38. The communication apparatus according to claim 36 or 37, wherein, The communication device further comprises a communication interface for inputting and / or outputting signals.

39. A communications device, characterized by The logic circuitry is for performing the method of any one of claims 1 to 35 and the input / output interface is for inputting and / or outputting signals.

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

41. A computer program product, characterised in that, The computer readable storage medium has stored thereon computer programs or instructions that, when executed on a computer, cause the method of any one of claims 1 to 35 to be performed.

Images