Communication method and communication device based on blockchain

Abstract

Embodiments of the present application provide a communication method and communication device based on a blockchain, used for providing an implementation of a decentralized communication network. In the implementation, new nodes to be added to a blockchain in the decentralized communication network can be managed and controlled. The method comprises: a first device sends first request information to a management network element, wherein the first request information comprises functions corresponding to smart contracts (SCs) that the first device desires to deploy; on the basis of the first request information, the management network element sends first feedback information to the first device, wherein the first feedback information comprises address information of a second device, and SCs deployed by the second device comprise a first SC among the SCs that the first device desires to deploy; and on the basis of the address information of the second device, the first device acquires data of the first SC.

Description

A communication method and communication device based on blockchain Technical Field

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

[0002] Blockchain (BC) is a distributed ledger technology (DLT) that integrates cryptography, peer-to-peer (P2P) networks, distributed databases, and other technologies. It boasts characteristics such as immutability, consensus-based, and decentralization. Smart contracts (SC) leverage these BC characteristics, transforming SC-based code into a decentralized application (DAPP). This involves deploying agreed-upon rules or functions as executable code to an account address on the BC. When a call request is made to this address, it is verified and executed within the BC, subject to the constraints of a consensus mechanism. This ensures the determinism and uniqueness of the execution result.

[0003] Currently, a key evolutionary direction for next-generation 3rd Generation Partnership Project (3GPP) networks (such as 6th generation (6G) communication networks) is to integrate BC with 3GPP networks. This involves evolving 3GPP network functions (such as network functions (NFs)) towards decentralized applications (DAPPs), thereby building decentralized 3GPP networks. However, the specific implementation of decentralized 3GPP networks remains a pressing issue.

[0004] Summary of the Invention

[0005] The embodiments of the present application provide a blockchain-based communication method and communication device, which are used to provide an implementation solution for a decentralized communication network, and the implementation solution can manage and control new nodes to be added to the BC in the decentralized communication network.

[0006] In a first aspect, a communication system is provided, comprising: a first device and a management network element. The first device is configured to send a first request message to the management network element, the first request message including the functionality corresponding to the smart contract (SC) that the first device desires to deploy. The management network element is configured to send a first feedback message to the first device based on the first request message, the first feedback message including the address information of a second device, the SC deployed by the second device including a first SC among the SCs that the first device desires to deploy, the first SC being deployed on a first blockchain (BC). The first device is further configured to obtain data of the first SC based on the address information of the second device.

[0007] Because in the embodiment of the present application, the first device can send the function corresponding to the SC it expects to deploy to the management network element, and then receive the address information of the second device from the management network element, so that the first device can join the BC joined by the second device according to the address information of the second device, that is, the first BC, thereby obtaining the data of the first SC in the SC that the first device expects to deploy, in order to deploy the first SC. That is, for the first device to be added to the BC in the decentralized communication network, the first device does not perceive the nodes of the BC in the communication network and the information of the SC deployed by the BC. It obtains the address information of the second device through the management network element, and then determines the BC that the first device can join and the SC that can be deployed, that is, the BC joined by the first device and the deployed SC are managed and controlled by the management network element. Therefore, based on the communication method provided in the embodiment of the present application, the newly added nodes to be added to the BC can be managed and controlled in the decentralized communication network, so as to optimize the communication network services.

[0008] In one possible implementation, the first device may be a newly added node to be added to the BC. The newly added node to be added to the BC refers to a newly added node with respect to the BC. This means that the newly added node may be a node newly connected to the communication network, a node that has already joined the communication network but has not yet joined the BC, a node that has exited the BC and is about to join the BC, or a node that has not yet exited the current BC and is about to join a new BC. It should be understood that "to be added to the BC" may mean that the newly added node desires to join the BC. Alternatively, "to be added to the BC" may mean that the newly added node can join the BC in response to a request from a management network element or other network element or device.

[0009] In one possible implementation, the management network element has a management function, wherein the management function is used to manage the at least one BC, such as the deployment of the SC and the control of the newly added node to be added to the BC. The management network element can manage and control the BC added by the first device and the deployed SC. The management network element can be a core network (CN) network element. The management network element can be a management plane network element, or the management network element can be a control plane network element. It can be understood that the management network element can be a newly added network element in the CN, such as a ledger anchor function (LAF) network element. Further, the management network element can be a separately deployed CN network element. Alternatively, the management network element can be deployed in superposition with existing CN network elements, for example, the management network element can be deployed in superposition with an access and mobility management function network element, a network element, or a unified data management network element. It can be understood that the management network element can be deployed on the CN side or on the access network (radio access network, RAN) side. For example, the management network element can be deployed in a centralized unit (CU), a distributed unit (DU), an open centralized unit (O-CU), an open digital unit (O-DU), an open radio unit (O-RU), or an intelligent controller of an open radio access network (O-RAN or ORAN). In one possible implementation, the management network element can be independent of the BC. For example, the management network element can be a network element in the communication network that is not added to any BC. In other words, the above-mentioned management network element may not be a node within the BC, that is, the above-mentioned management function can be provided in a non-decentralized manner.

[0010] In one possible implementation, the management network element may be a node within a BC, and the SC deployed on the BC may correspond to the management functions of the aforementioned management network element. In other words, the management functions of the aforementioned management network element may be implemented by the SC, thereby providing the aforementioned management functions in a decentralized manner.

[0011] In a possible implementation, the communication network may include one or more operator networks, and the management network element may manage BCs in one or more operator networks. In other words, the management network element may manage BCs across operator networks.

[0012] In one possible implementation, at least one BC managed by the management network element is a BC within the communication network. The device type of each node within the at least one BC may include at least one of the following: a terminal device, a RAN device, a CN device, or an independent node (INN). An INN may refer to a node that has BC capabilities but does not participate in wireless communication services for terminal devices and / or RAN devices, such as an edge computing (EC) node.

[0013] Furthermore, the aforementioned RAN and CN devices are infrastructure within a communications network (e.g., a carrier network) and can jointly provide functions such as network functions (NFs), service functions, or network access and data transmission functions provided by the RAN. In other words, the SC deployed at the BC node can be used to implement communications network functions, such as network function-smart contracts, service function-smart contracts, and data transmission-smart contracts.

[0014] In one possible implementation, the first device obtains the data of the first SC based on the address information of the second device, including: the first device establishes a communication connection with the second device based on the address information of the second device, requests to establish a BC connection with the second device by deploying the BC protocol corresponding to the first BC, and then joins the first BC, and obtains the data of the first SC through BC data synchronization, wherein the first BC is the BC that deploys the first SC, that is, the BC that the second device joins. In other words, the first device establishes a BC connection with the second device to obtain the data of the first SC, so that the first device can deploy the first SC. Furthermore, the first device can establish a BC connection with the second device by pre-installing the BC protocol corresponding to the first BC.

[0015] In one possible implementation, the first device may obtain the BC protocol corresponding to the first BC from a registration network element or a management network element before establishing a BC connection with the second device. It is understood that the first device may also obtain the BC protocol corresponding to the first BC from other nodes other than the registration network element and the management network element, such as the second device.

[0016] In one possible implementation, the communication system further includes a second device. The first device is further configured to: send a second request message to the second device based on the address information of the second device, the second request message being used to request deployment of the first SC. The second device is configured to: send second feedback message to the first device based on the second request message, the second feedback message including data of the BC protocol corresponding to the first BC. The first and second devices are configured to: synchronize BC data based on the BC protocol corresponding to the first BC, the BC data including data of the first SC. In other words, by sending the second request message to the second device, the first device can receive BC protocol data from the second device and thereby obtain the BC protocol corresponding to the first BC. This means that the first device can establish a BC connection with the second device without having to previously install the BC protocol corresponding to the first BC. It will be appreciated that in this approach, the interactive signaling required to establish a BC connection between the first and second devices can be reused to obtain the BC protocol corresponding to the first BC, thereby eliminating the need for interaction with other network elements and reducing signaling overhead.

[0017] In one possible implementation, the functions corresponding to the SC that the first device expects to deploy may include multiple functions, wherein each of the multiple functions may correspond to one SC. In other words, the SC that the first device expects to deploy may be multiple SCs.

[0018] In a possible implementation, the multiple SCs that the first device desires to deploy may belong to the same BC, namely, the first BC. In other words, the first device can deploy the multiple SCs that it desires to deploy by joining one BC.

[0019] In a possible implementation, the multiple SCs that the first device desires to deploy may not belong to the same BC. That is, if there are multiple first BCs, the first device may join multiple first BCs and deploy multiple SCs belonging to different first BCs.

[0020] In one possible implementation, the first request information also includes at least one of the following: type information of the first device, operation information of the first device, or capability information of the first device. That is, the first request information can enable the management network element to match the SC suitable for the deployment of the first device from the SC that the first device expects to deploy, thereby reducing the impact on the quality of decentralized 3GPP network services. Optionally, the management network element can also obtain the type information, operation information, or capability information of the above-mentioned first device through other network elements. For example, the management network element can obtain the access and mobility management function registration information of the first device through the unified data management network element, and then obtain the type information of the first device.

[0021] In one possible implementation, the type information of the first device specifically includes: the device type of the first device, and / or the type of participation role of the first device in the SC that the first device expects to deploy. The device type of the first device may include: terminal device, RAN device, or CN device, etc. It can be understood that the management network element can determine whether the functions corresponding to the SC that the first device expects to deploy matches the first device based on the device type of the first device. For example, the first device is a terminal device, and the functions corresponding to the SC that the first device expects to deploy include access and mobility management functions and application functions. Due to the mobility of the terminal device, the 3GPP network may not expect the terminal device to deploy AMF-SC, and then the management network element can determine that the first device can deploy AF-SC.

[0022] In one possible implementation, the types of participating roles in an SC may include at least one of the following: a verification role, a transaction role, a backup role, or a network access provider role. The transaction role generates transaction requests. The verification role verifies the transaction request. The backup role does not participate in transactions or verification, but only backs up BC data. The network access role primarily provides network access services for users.

[0023] In one possible implementation, the first device expects to deploy multiple SCs, and the first device's participating role type in the SCs expected to be deployed by the first device may include: the participating role type corresponding to each SC in the multiple SCs. For example, the first device expects to deploy SCs: SC#1, SC#2, and SC#3, and the first device's participating role type in the SCs expected to be deployed by the first device may include: the participating role type in SC#1, the participating role type in SC#2, and the participating role type in SC#3.

[0024] In one possible implementation, the operation information of the first device specifically includes: the estimated online duration of the first device, and / or the estimated online time period of the first device. The online duration may refer to: the shortest network duration that the first device estimates can contribute in BC, such as 0.5 hours, 1 hour, or 1.5 hours, etc. The online time period estimated by the first device may refer to: the time period in which the first device estimates it can be online in BC, such as 10:00-12:00. It can be understood that in order to ensure the quality of decentralized network services, the network duration contributed by the nodes in the network in BC should be greater than or equal to the first time threshold. Exemplarily, the first time threshold may be 1 hour, 2 hours, 3 hours, or longer.

[0025] In one possible implementation, the capability information of the first device specifically includes at least one of the following: the computing capability of the first device, the storage capability of the first device, or the network connection capability of the first device. The computing capability of the first device may refer to the computing speed (e.g., CPU frequency) or computing capability of the first device. The storage capability of the first device may refer to the memory size, local storage size, or read / write rate (or read / write bandwidth) of the first device. The network connection capability of the first device may refer to the type of network connection provided by the first device, such as 3GPP access, Wi-Fi, Bluetooth, or wired connection.

[0026] In one possible implementation, the management network element is further configured to: determine the first SC from the candidate SC set based on the first request information and the matching condition corresponding to at least one SC in the candidate SC set; and determine the address information of the second device based on the first SC. It can be understood that the functions corresponding to the SCs in the candidate SC set are the same as the functions corresponding to the SCs that the first device expects to deploy. Each SC in the candidate SC set may have a matching condition; or some SCs in the candidate SC set may not have a matching condition.

[0027] In one possible implementation, the candidate SC set is obtained from a registration NE, which is used to store the SC deployed by each of the multiple BCs managed by the management NE. The registration NE can be the aforementioned UDM NE, an NRF NE, or another NE. In other words, the management NE can obtain the candidate SC set by querying the registration NE.

[0028] In one possible implementation, the matching condition corresponding to at least one SC in the candidate SC set is pre-configured; or, the matching condition corresponding to at least one SC in the candidate SC set is obtained from a registration network element, which is used to store the SC deployed by each of the multiple BCs managed by the management network element, as well as the matching condition corresponding to the SC deployed by each of the multiple BCs. The functions corresponding to the above-mentioned registration network element can also be implemented by the SC, thereby providing the registration function in a decentralized manner. That is, the candidate SC set, and / or, the matching condition corresponding to at least one SC in the candidate SC set can be obtained from the BC node that deploys the registration function-SC.

[0029] In a possible implementation, the matching condition may include at least one of the following: type information of the prohibited deployment corresponding to the SC, operation information of the prohibited deployment corresponding to the SC, and capability information of the prohibited deployment corresponding to the SC. It can be understood that the type information of the prohibited deployment corresponding to the SC can be replaced by the type information of the allowed deployment corresponding to the SC. The operation information of the prohibited deployment corresponding to the SC can be replaced by the operation information of the allowed deployment corresponding to the SC. The capability information of the prohibited deployment corresponding to the SC can be replaced by the capability information of the allowed deployment corresponding to the SC, etc. The type information may include: device type, and / or the type of participating role in the SC. The operation information may include: online duration, and / or online time period. The capability information may include: computing power, storage capacity, or network connection capacity.

[0030] In a possible implementation, the second device may be any node within the first BC.

[0031] In one possible implementation, the second device may be a node within the first BC that can establish a communication connection with the first device. For example, the device type of the first device is a 3GPP terminal device, and the second device may be a RAN device that is physically and / or logically topologically closest to the first device, or an AMF network element. For another example, the device type of the first device is a non-3GPP terminal device, and the second device may be an N3G-GW that is physically and / or logically topologically closest to the first device. For another example, the first device and the second device may be located in the same operator network or PLMN. That is to say, the management network element may select a node within the first BC that can directly establish a communication connection with the first device as the second device, thereby reducing communication latency and reducing the occupancy of network resources.

[0032] In one possible implementation, the first feedback information may further include information for indicating the first SC. The information for indicating the first SC may be, for example, the function corresponding to the first SC, the function type corresponding to the first SC, or the ID of the first SC, etc., and this embodiment of the present application does not specifically limit this. It can be understood that in the case where the SC that the first device expects to deploy is a plurality of SCs that the first device expects to deploy, the first device can determine which of the plurality of SCs are the SCs that the management network element agrees to deploy through the information for indicating the first SC.

[0033] In a possible implementation, there are multiple first SCs, and the information used to indicate the first SCs may include: information used to indicate each first SC in the multiple first SCs.

[0034] In a possible implementation, there are multiple first SCs, and the address information of the second device may include: address information of the second device corresponding to each first SC in the multiple first SCs.

[0035] In a possible implementation, the first feedback information further includes first identity information, where the first identity information is information indicating the identity of the first device. The second request information further includes the first identity information.

[0036] In one possible implementation, the management network element is further configured to: send second identity information to the second device, where the second identity information is information used by other devices to determine the identity of the first device, wherein the other device is a device other than the first device. The second device is further configured to: send second feedback information to the first device when it is determined that the identity authentication of the first device is successful based on the second identity information. It can be understood that the above-mentioned first identity information and second identity information can be complementary, that is, the second identity information can be used to verify whether the first identity information is correct. For example, the first identity information can be a token, and the second identity information can also be a token, and there is a one-to-one correspondence between the two. Alternatively, the first identity information can be the identity ID of the first device, and the second identity information can also be the identity ID of the first device. Then, when the second request information includes the identity ID of the first device, and the identity ID of the first device is the same as the identity ID of the first device sent to the second device by the management network element, the second device can determine that the identity authentication of the first device is successful.

[0037] In one possible implementation, the first device is further configured to send the first device's role in the first SC to a BC node within the first BC, where the role includes at least one of the following: verification role, transaction role, backup role, or network access provisioning role. It should be understood that in a decentralized network, when a newly added first device joins the first BC and deploys the first SC, the first BC that deploys the first SC changes. This implementation allows each node within the first BC to synchronize the state changes of the first BC and the first SC.

[0038] In one possible implementation, the first device is also configured to: send the estimated online time of the first device, capability information of the first device, etc. to the BC node within the first BC, so that other nodes within the first BC can synchronize the status of the first device, thereby facilitating the execution of the SC deployed within the first BC and improving the quality of decentralized 3GPP network services.

[0039] In one possible implementation, the first device is further configured to send registration information to a registration network element or a management network element. The registration information includes at least one of the following: information identifying the BC to which the first device joins, information indicating the SC deployed by the first device, or the first device's role in the SC deployed by the first device. The information identifying the BC to which the first device joins may, for example, be the ID of the BC to which the first device joins, or information about nodes within the BC. The information indicating the SC deployed by the first device may, for example, include the ID of the SC, the function corresponding to the SC, or matching conditions corresponding to the SC. In other words, the first device sending the registration information to the registration network element or the management network element allows the management network element to directly obtain, or obtain through the registration management network element, the latest change information about the BC in the current 3GPP network. This allows the management network element to synchronize the latest change information about the BC in the 3GPP network, such as information about newly added nodes in the BC, the status of deployed SCs, and the role of the newly added nodes in the deployed SCs, thereby facilitating management and control of the BCs in the network and newly added nodes to be added to the BCs.

[0040] In one possible implementation, the first device is further configured to send a withdrawal message to a management network element, where the withdrawal message indicates the BC that the first device wishes to withdraw from. The management network element is further configured to delete the first device's registration information in the BC that the first device wishes to withdraw from based on the withdrawal message. In other words, when the first device wishes to withdraw from a BC, it can send the withdrawal message to the management network element responsible for managing the BC, allowing the management network element to synchronize the BC status in a timely manner, avoiding conflicts and thereby ensuring the quality of decentralized network services.

[0041] In one possible implementation, the management network element is further configured to: send a deregistration request message to the registration network element, the deregistration request message including information indicating the BC that the first device desires to exit; and receive a deregistration request confirmation message from the registration network element, the deregistration request confirmation message confirming that the registration information of the first device in the BC that the first device desires to exit has been deleted. It is understood that the management network element can store and centrally maintain data related to BCs within the 3GPP network, thereby reducing the storage burden on the management network element. The management network element can then delete the registration information of the first device in the BC that the first device desires to exit, and the deletion is performed through the registration network element.

[0042] In one possible implementation, the management network element is further configured to: send a network exit confirmation message to the first device, where the network exit confirmation message is used to confirm that the registration information of the first device in the BC that the first device wishes to exit has been deleted. The first device is further configured to: receive the network exit confirmation message from the management network element. It can be understood that after the management network element deletes the registration information of the first device in the BC that the first device wishes to exit, by sending the network exit confirmation message to the first device, it indicates that the network has made relevant preparations for the first device to exit the BC, and notifies the first device that it can exit the BC. It should be understood that the first device can delete the BC data of the BC that the first device wishes to exit, such as the account book data, based on the network exit confirmation message. The first device can stop the BC protocol program script corresponding to the BC that it wishes to exit. Optionally, the first device can also send a deletion confirmation message to the management network element. The deletion confirmation message is used to confirm that the BC data of the BC that the first device wishes to exit has been deleted.

[0043] In one possible implementation, after receiving the network exit information sent by the first device, the management network element can broadcast the network exit information to the BC that the first device wants to exit, so that each node in the BC that the first device wants to exit can synchronize the latest status of the BC.

[0044] In one possible implementation, the management network element is further configured to, based on the network exit information, send network exit instruction information to the second device. The network exit instruction information is used to instruct the first device to exit the BC that the first device desires to exit. The second device is further configured to receive the network exit instruction information from the management network element. In other words, the second device can receive the network exit instruction information from the management network element and thereby synchronize the latest BC status with the management network element.

[0045] In one possible implementation, the second device is further configured to: broadcast the network exit instruction information to other BC nodes, excluding the first device, in the BC that the first device desires to exit, based on the network exit instruction information. It should be understood that, to save storage overhead, the management network element or the registration network element may only store the address information of the entry node (i.e., the second device) corresponding to each BC, and then the management network element sends the network exit instruction information to the second device, causing the second device to broadcast the network exit instruction information to each node in the BC to synchronize the latest status of the BC.

[0046] In a second aspect, a communication method is provided. The method can be executed by a first device, or by a component of the first device, such as a processor, chip, or chip system of the first device, or by a logic module or software that can implement all or part of the functions of the first device. The following description takes the method executed by the first device as an example. The method includes: the first device sends a first request message to a management network element, the first request message includes the function corresponding to the smart contract SC that the first device expects to deploy; the first device receives first feedback information from the management network element, the first feedback information includes the address information of the second device, the SC deployed by the second device includes the first SC among the SCs that the first device expects to deploy, and the first SC is deployed in the first blockchain BC; the first device obtains data of the first SC based on the address information of the second device.

[0047] In a possible implementation manner, the first request information further includes at least one of the following: type information of the first device, operation information of the first device, or capability information of the first device.

[0048] In one possible implementation, the type information of the first device specifically includes: the device type of the first device, and / or the type of participating role of the first device in the SC where the first device expects to be deployed; the operation information of the first device specifically includes: the estimated online duration of the first device, and / or the estimated online time period of the first device; the capability information of the first device specifically includes at least one of the following: the computing power of the first device, the storage capacity of the first device, or the network connection capability of the first device.

[0049] In one possible implementation, the first device obtains data of the first SC based on the address information of the second device, including: the first device sends second request information to the second device based on the address information of the second device, and the second request information is used to request deployment of the first SC; the first device receives second feedback information from the second device, and the second feedback information includes data of the BC protocol corresponding to the first BC; the first device synchronizes BC data with the second device based on the BC protocol corresponding to the first BC, and the BC data includes data of the first SC.

[0050] In a possible implementation, the first feedback information further includes first identity information, where the first identity information is information indicating the identity of the first device; and the second request information further includes the first identity information.

[0051] In one possible implementation, the method provided in the second aspect further includes: the first device sends the participating role of the first device in the first SC to the BC node within the first BC, and the participating role includes at least one of the following: verification role, transaction role, backup role, or network access provision role.

[0052] In one possible implementation, the method provided by the second aspect further includes: the first device sends registration information to a registration network element or a management network element, the registration information including at least one of the following: information for identifying the BC joined by the first device, information for indicating the SC deployed by the first device, or the participating role of the first device in the SC deployed by the first device.

[0053] In a possible implementation, the method provided in the second aspect further includes: the first device sends network exit information to the management network element, where the network exit information is used to indicate the BC that the first device wants to exit.

[0054] In a possible implementation, the method provided in the second aspect further includes: the first device receives network exit confirmation information from the management network element, where the network exit confirmation information is used to confirm that the registration information of the first device in the BC that the first device expects to exit has been deleted.

[0055] Among them, the technical effects of the second aspect or any of its implementation methods can refer to the above-mentioned first aspect and will not be repeated here.

[0056] On the third aspect, a communication method is provided, which can be executed by a management network element, or by a component of the management network element, such as a processor, chip, or chip system of the management network element, or by a logic module or software that can realize all or part of the functions of the management network element. The following is an illustration of the method being executed by a management network element. The method includes: the management network element receives a first request message from a first device, the first request message includes the function corresponding to the smart contract SC that the first device expects to deploy; the management network element determines the address information of the second device based on the first request message, and the SC deployed by the second device includes the first SC in the SC that the first device expects to deploy; the management network element sends a first feedback message to the first device, and the first feedback message includes the address information of the second device.

[0057] In a possible implementation manner, the first request information further includes at least one of the following: type information of the first device, operation information of the first device, or capability information of the first device.

[0058] In one possible implementation, the type information of the first device specifically includes: the device type of the first device, and / or the type of participating role of the first device in the SC where the first device expects to be deployed; the operation information of the first device specifically includes: the estimated online duration of the first device, and / or the estimated online time period of the first device; the capability information of the first device specifically includes at least one of the following: the computing power of the first device, the storage capacity of the first device, or the network connection capability of the first device.

[0059] In one possible implementation, the management network element determines the address information of the second device based on the first request information, including: the management network element determines the first SC from the candidate SC set based on the first request information and the matching conditions corresponding to at least one SC in the candidate SC set; the management network element determines the address information of the second device based on the first SC.

[0060] In one possible implementation, the candidate SC set is obtained from a registration network element, which is used to store the SC deployed by each BC in multiple blockchain BCs managed by the management network element.

[0061] In one possible implementation, the matching conditions corresponding to at least one SC in the candidate SC set are pre-configured; or, the matching conditions corresponding to at least one SC in the candidate SC set are obtained from a registration network element, which is used to store the SC deployed by each of the multiple BCs managed by the management network element, and the matching conditions corresponding to the SC deployed by each of the multiple BCs.

[0062] In a possible implementation, the method provided in the third aspect further includes: the management network element sends second identity information to the second device, the second identity information is information used by other devices to determine the identity of the first device, and the other devices are devices other than the first device.

[0063] In a possible implementation, the first feedback information further includes first identity information, where the first identity information is information indicating the identity of the first device.

[0064] In one possible implementation, the method provided in the third aspect further includes: the management network element receives network exit information from the first device, where the network exit information is used to indicate the BC that the first device expects to exit; and the management network element deletes the registration information of the first device in the BC that the first device expects to exit based on the network exit information.

[0065] In one possible implementation, the management network element deletes the registration information of the first device in the BC that the first device expects to exit based on the network exit information, including: the management network element sends a deregistration request message to the registration network element, the deregistration request message includes information used to indicate the BC that the first device expects to exit; the management network element receives a deregistration request confirmation message from the registration network element, the deregistration request confirmation message is used to confirm that the registration information of the first device in the BC that the first device expects to exit has been deleted.

[0066] In a possible implementation, the method provided in the third aspect further includes: the management network element sending network exit indication information to the second device according to the network exit information, where the network exit indication information is used to instruct the first device to exit the BC that the first device expects to exit.

[0067] In a possible implementation, the method provided in the third aspect further includes: the management network element sends a network exit confirmation message to the first device, where the network exit confirmation message is used to confirm that the registration information of the first device in the BC that the first device expects to exit has been deleted.

[0068] Among them, the technical effects of the third aspect or any of its implementation methods can refer to the above-mentioned first aspect and will not be repeated here.

[0069] In a fourth aspect, a communication method is provided. This method can be performed by a second device, or by a component of the second device, such as a processor, chip, or chip system of the second device. It can also be implemented by a logic module or software that implements all or part of the functions of the second device. The following description uses the method performed by the second device as an example. The method includes: the second device receiving a second request message from a first device, the second request message being used to request the deployment of a first SC in a smart contract SC that the first device desires to deploy, the SC deployed by the second device including the first SC, which is deployed on a first blockchain BC; the second device sending second feedback message to the first device based on the second request message, the second feedback message including data from the BC protocol corresponding to the first BC; and the second device synchronizing BC data with the first device based on the BC protocol corresponding to the first BC, the BC data including data from the first SC.

[0070] In one possible implementation, the method provided in the fourth aspect further includes: the second device receives second identity information from the management network element, the second identity information is information used by other devices to determine the identity of the first device, the BC managed by the management network element includes the BC joined by the second device, and the other devices are devices other than the first device; accordingly, the second device sends second feedback information to the first device based on the second request information, including: when the second device determines that the identity authentication of the first device is successful based on the second identity information, the second device sends second feedback information to the first device.

[0071] In a possible implementation, the second request information further includes first identity information, where the first identity information is information indicating the identity of the first device.

[0072] In a possible implementation, the method provided in the fourth aspect further includes: the second device obtains network exit indication information, where the network exit indication information is used to instruct the first device to exit the BC that the first device desires to exit.

[0073] In one possible implementation, the network exit indication information is obtained from a management network element, and the BC managed by the management network element includes the BC joined by the second device; the method provided in the fourth aspect also includes: the second device broadcasts the network exit indication information to other BC nodes in the BC that the first device expects to exit, except the first device, based on the network exit indication information.

[0074] Among them, the technical effects of the fourth aspect or any of its implementation methods can refer to the above-mentioned first aspect and will not be repeated here.

[0075] In a fifth aspect, a communication device is provided for implementing the various methods described above. The communication device may be the first device in the second aspect or any implementation thereof, or a device including the first device, or a device included in the first device, such as a chip; or the communication device may be the management network element in the third aspect or any implementation thereof, or a device including the management network element, or a device included in the management network element, such as a chip; or the communication device may be the second device in the fourth aspect or any implementation thereof, or a device including the second device, or a device included in the second device, such as a chip. The communication device includes modules, units, or means corresponding to the implementation of the above methods, which may be implemented by hardware, software, or by hardware executing corresponding software. The hardware or software includes one or more modules or units corresponding to the above functions.

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

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

[0078] In a sixth aspect, a communication device is provided, comprising: at least one processor; the processor is used to execute a computer program or instruction stored in a memory through a logic circuit and / or communication, so that the communication device executes the method described in any one of the above aspects.

[0079] In a possible implementation, the communication device further includes the memory. Optionally, the memory is integrated with the processor, or the memory may be independent of the processor.

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

[0081] In a possible implementation, the communication device further includes a communication interface, which is used to communicate with a module outside the communication device.

[0082] The communication device may be the first device in the second aspect or any implementation thereof, or a device including the first device, or a device included in the first device, such as a chip; or the communication device may be the management network element in the third aspect or any implementation thereof, or a device including the management network element, or a device included in the management network element, such as a chip; or the communication device may be the second device in the fourth aspect or any implementation thereof, or a device including the second device, or a device included in the second device, such as a chip.

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

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

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

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

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

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

[0089] Among them, the technical effects brought about by any design method in the fifth to ninth aspects can refer to the technical effects brought about by the different design methods in the above-mentioned first aspect, and will not be repeated here.

[0090] In a tenth aspect, a communication method is provided, which includes: the method described in the second aspect or any implementation thereof, and the method described in the third aspect or any implementation thereof.

[0091] In some possible designs, the communication method also includes the method described in the fourth aspect above or any of its implementation methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0092] FIG1 is a schematic diagram of a communication architecture of a 3GPP network provided in an embodiment of the present application;

[0093] FIG2 is a schematic diagram of the architecture of a decentralized communication network provided in an embodiment of the present application;

[0094] FIG3 is a schematic diagram of a BC in which a new node is added to a decentralized communication network according to an embodiment of the present application;

[0095] FIG4 is a schematic diagram of the architecture of a communication system provided in an embodiment of the present application;

[0096] FIG5 is a schematic structural diagram of a communication device provided in an embodiment of the present application;

[0097] FIG6 is a flow chart of a communication method according to an embodiment of the present application;

[0098] FIG7 is a schematic diagram of a matching process provided in an embodiment of the present application;

[0099] FIG8 is a second flow chart of a communication method provided in an embodiment of the present application;

[0100] FIG9 is a third flow chart of a communication method provided in an embodiment of the present application;

[0101] FIG10 is a fourth flow chart of a communication method provided in an embodiment of the present application;

[0102] FIG11 is a schematic structural diagram of a first device provided in an embodiment of the present application;

[0103] FIG12 is a schematic structural diagram of a management network element provided in an embodiment of the present application;

[0104] FIG13 is a schematic structural diagram of a second device provided in an embodiment of the present application. DETAILED DESCRIPTION

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

[0106] First, blockchain (BC):

[0107] BC is a distributed ledger technology (DLT) that integrates cryptography, peer-to-peer (P2P) networks, distributed databases, and other technologies. It boasts characteristics such as immutability, consensus-based, and decentralization. A smart contract (SC) is an executable piece of code that can leverage these features of BC to transform the code built on SC into a decentralized application (DAPP). This involves deploying agreed-upon rules or functions as executable code to an account address on BC. When a call request is made to this address, it is verified and executed within BC under the constraints of a consensus mechanism, ensuring the determinism and uniqueness of the execution result.

[0108] The following introduces some solutions for adding new nodes to BC and deploying SC.

[0109] Second, nodes in the Internet join the BC scheme:

[0110] For new nodes that join the BC through the Internet, the way they join the BC and deploy the SC is a way of joining in an open environment without access conditions. For example, the new node can install the BC protocol corresponding to the BC it wishes to join in advance, and choose to install related configurations (such as digital signatures, or verification tools, etc.), and then establish a connection with the node in the BC that the new node wishes to join via the Internet, and then synchronize the BC data through the BC protocol, and deploy the SC included in the BC data through the BC data synchronization. Furthermore, after the new node joins the BC it wishes to join, it can configure the role of the new node in the SC by itself. It should be understood that one BC can deploy multiple SCs, that is, the new node can choose to deploy one or more SCs among the multiple SCs.

[0111] Third, the nodes in the alliance chain join the BC solution:

[0112] Unlike the open, no-entry-conditions approach described above, joining a consortium chain requires permission from the consortium members. This means that the consortium chain's node joining scheme is designed for nodes that are not members of the consortium. There is no corresponding control or management scheme for sub-nodes that are already members of the consortium.

[0113] Fourth, communication network services:

[0114] In an embodiment of the present application, a decentralized communication network is provided, for example, a decentralized 3GPP network, which can provide decentralized 3GPP network services (also referred to as 3GPP network functions or 3GPP network service functions). In the 3GPP network, functions may include NFs and service functions. NFs may include functions corresponding to the core network (CN), such as access and mobility management functions (AMFs), authentication server functions (AUSFs), session management functions (SMFs), network exposure functions (NEFs), network function repository functions (NF repository functions (NRFs), policy control functions (PCFs), unified data management (UDMs), application functions (AFs), user plane functions (UPFs), or network slice selection functions (NSSFs). Service functions may include functions corresponding to third-party services, such as Internet of Things services, satellite communication services, or cloud services, which are not specifically limited in the embodiments of the present application.

[0115] In a decentralized 3GPP network, decentralized 3GPP network services can refer to deploying 3GPP network functions in the form of decentralized applications (DAPPs) (i.e., SCs) on nodes with business continuity (BC) capabilities within the 3GPP network. Specifically, ledger functions are deployed on BC-capable nodes within the 3GPP network (e.g., terminal devices, radio access network (RAN) equipment, core network (CN) equipment, and functional network elements). Each node within the same BC within the 3GPP network synchronizes BC data (or ledger data), which includes SC data. This BC data enables each of these nodes to deploy SCs and, under the constraints of a consensus mechanism, execute the corresponding SC functions. The corresponding SC functions can include 3GPP network functions, i.e., network services are provided by the SCs deployed on each node. As can be understood, due to the decentralized nature of BCs, driven by the consensus mechanism, malicious or erroneous behavior of a single node will not affect the final execution of the SC, thereby enhancing the robustness and attack resistance of the 3GPP network.

[0116] Furthermore, due to the decentralized nature of the BC, each node within the 3GPP network will participate in the query, transaction, backup, consensus, or operation and maintenance of BC data to varying degrees. Considering the heterogeneous complexity and high dynamism of the nodes within the 3GPP network, in order to optimize 3GPP network services, the specific implementation of the decentralized 3GPP network requires the 3GPP network to manage and control the nodes that join the BC within the 3GPP network. For example, if a node within the 3GPP network changes, a new node to be added to the BC appears in the 3GPP network. If the device type of the new node does not meet the deployment requirements of the SC in the 3GPP network, it will be difficult to optimize 3GPP network services after the new node joins the BC and the SC is deployed.

[0117] For nodes in the Internet to join the BC scheme, joining the BC scheme is a spontaneous and voluntary behavior of the newly added nodes. There is no access and permission mechanism for the newly added nodes, that is, the BC network cannot control and admit the newly added nodes, nor can it control the deployment of specific SCs on the newly added nodes.

[0118] Furthermore, since the behavior of adding a new node to join the BC and the deployment of the SC are decided by the new node independently and cannot be controlled, for example, from the perspective of the deployment requirements of the SC in the 3GPP network, the above-mentioned BC joining solution is difficult to achieve the optimization of 3GPP network services.

[0119] For the node joining BC scheme in the alliance chain, a certain network has become a member of the BC alliance. The new nodes in the network, that is, the child nodes of the BC alliance member, are automatically regarded as members of the BC alliance. Therefore, the node joining scheme in the alliance chain mentioned above cannot control and manage the new nodes.

[0120] Furthermore, for 3GPP networks, the nodes within the network are characterized by high heterogeneity, complexity, and high dynamism. For example, a node within a 3GPP network can be a terminal device, which may be in a high-speed mobile state and thus constantly leave and join a cell. For another example, a node within a 3GPP network can also be a RAN device, and the number of terminal devices connected to it may be constantly changing, that is, the load on the RAN device is dynamically changing. In other words, due to the aforementioned characteristics of the nodes within the 3GPP network, newly added nodes in the 3GPP network may not currently meet the deployment requirements of the SC in the 3GPP network. In other words, in the aforementioned decentralized 3GPP network scenario, even if the newly added node is already a member of the BC alliance, it is still necessary to join the BC and deploy the SC on the BC to control and manage the newly added node.

[0121] In summary, the above-mentioned solutions for adding new nodes to BC lack specific solutions for decentralized 3GPP networks. Therefore, how to manage and control the new nodes added to BC in the decentralized 3GPP network remains an urgent problem to be solved.

[0122] Based on this, an embodiment of the present application provides a communication method that can manage and control new nodes to be added to the BC in a decentralized 3GPP network.

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

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

[0125] 1. In the embodiment of the present application, the 3GPP network may include an operator network, wherein the 3GPP network may include one or more operator networks.

[0126] 2. In the embodiments of the present application, "network element" and "node" can be logical entities or physical entities. In other words, in the embodiments of the present application, "device" can be used interchangeably with "network element" and will be described here as a unified description and will not be repeated below.

[0127] 3. In the embodiments of the present application, for the convenience of description, when numbering or indexing is involved, the consecutive numbering can start from 1, the consecutive numbering can also start from 0, or the numbering can start from any parameter.

[0128] 4. "Pre-definition," "pre-configuration," or "protocol agreement" may be implemented by pre-saving corresponding codes, tables, or other methods that can be used to indicate relevant information in a device (e.g., a first device, a management network element, or a second device). The embodiments of this application do not limit the specific implementation methods. "Saving" may mean storing in one or more memories.

[0129] 5. The “protocol” involved in the embodiments of the present application may refer to a standard protocol in the field of communications, such as the long term evolution (LTE) protocol, the new radio (NR) protocol, and related protocols used in future communication systems (such as 6G communication systems). The embodiments of the present application are not limited to this.

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

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

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

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

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

[0135] The communication architecture of the 3GPP network is introduced as an example below.

[0136] Figure 1 is a schematic diagram of a communication architecture of a 3GPP network provided by an embodiment of the present application. As shown in Figure 1, the communication architecture of the 3GPP network includes: an access network (AN) and a CN, and may also include: a terminal device.

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

[0138] In one possible implementation, the AN performs access-related functions, providing network access for authorized users in a specific area and determining transmission links of varying quality for user data transmission based on user level and service requirements. The AN forwards control data and user data between terminal devices and the CN. The AN may include radio access network equipment, also known as RAN equipment or RAN nodes.

[0139] Furthermore, in one possible implementation, the RAN device may be a transmission and reception point (TRP), a base station, a remote radio unit (RRU) or a baseband unit (BBU) of a separated base station (also referred to as a distributed unit (DU)), a broadband network gateway (BNG), an aggregation switch, a non-3GPP access device, a relay station or an access point, etc. The network device may 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 CRAN scenario. Optionally, the RAN device may also be a server, a wearable device, a vehicle or an on-board device, etc. For example, the RAN device in the V2X system may be a road side unit (RSU). In addition, the RAN device in the embodiment of the present application can be an eNB or eNodeB (evolutional NodeB) in LTE, a wireless controller in a CRAN scenario, a base station in a 5G communication system (such as the next generation Node B (gNodeB, gNB)), or a base station in a future evolution system (such as a 6G communication system), etc., and is not specifically limited here.

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

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

[0142] It should be understood that the CN is primarily responsible for maintaining mobile network subscription data and providing terminal devices with functions such as session management, mobility management, policy management, and security authentication. The CN may include the NF network elements described in the aforementioned "decentralized 3GPP network." The NF network elements in the CN may be deployed on one or more CN devices, which may be deployed on the network side or the cloud side, though this is not specifically limited in the present embodiment.

[0143] Furthermore, the NF network elements shown in Figure 1 may include control plane functions such as AMF network element, AUSF network element, SMF network element, UPF network element, UDM network element, NEF network element, NRF network element, NSSF network element, PCF network element, and AF network element. The above network elements can interact with each other using service-based interfaces. For example, the service-based interface provided by the AUSF network element is Nausf; the service-based interface provided by the AMF network element is Namf; the service-based interface provided by the SMF network element is Nsmf; the service-based interface provided by the NSSF network element is Nnssf; the service-based interface provided by the NEF network element is Nnef; the service-based interface provided by the NRF network element is Nnrf; the service-based interface provided by the PCF network element is Npcf; the service-based interface provided by the UDM network element is Nudm; and the service-based interface provided by the AF network element is Naf.

[0144] Among them, the AMF network element is mainly responsible for mobility management and access management. Among them, the AMF network element can receive non-access stratum (NAS) messages (including mobility management (MM) signaling and session management (SM) signaling) from terminal devices through the N1 interface and related signaling from RAN devices (for example, base station-level N2 signaling interacting with the AMF), complete the user registration process and forwarding of SM signaling and mobility management.

[0145] The AUSF network element can be used to support authentication for 3GPP access and non-3GPP access (such as wireless local area network (WLAN) access or satellite access). Among them, the AUSF network element can be used for authentication services and to generate keys to achieve two-way authentication of terminal devices. For example, during the primary authentication and key negotiation process between the AMF network element and the terminal device, the AUSF network element can complete the authentication of the terminal device.

[0146] The SMF network element is mainly used for session management in mobile networks, such as user plane network element selection, user plane network element redirection, Internet Protocol (IP) address allocation, bearer establishment, modification and release, and quality of service (QoS) control.

[0147] The UPF network element is used for packet routing and forwarding, QoS processing of user plane data, etc.

[0148] The UDM network element is used to process user identification, access authentication, service network element registration, or mobility management.

[0149] The NEF network element mainly provides services that enable the 3GPP network to securely provide network service capabilities to third-party service provider application function network elements.

[0150] The NRF network element can provide registration functions, such as supporting service discovery functions, that is, receiving NF discovery requests from NF network elements and providing the discovered NF information to the NF network element.

[0151] NSSF network element, used to select network slices for terminal devices, etc.

[0152] The PCF network element includes user contract data management functions, policy control functions, billing policy control functions, QoS control, etc. It is a unified policy framework used to guide network behavior and provide policy rule information for control plane function network elements (such as AMF network elements, etc.).

[0153] The AF network element is mainly used to provide application layer information to the 3GPP network. The AF network element may include, for example, a services capability server (SCS) or an application server (AS).

[0154] It should be understood that Figure 1 only exemplifies some examples of network elements or entities in a 5G network. The 5G network may also include some network elements or entities not shown in Figure 1, such as a network data analytics function (NWDAF), and the embodiments of the present application do not specifically limit this.

[0155] It should also be understood that in networks that evolve after 5G (e.g., 6G networks), other network functions may also be included, such as artificial intelligence (AI), computing, or perception-related functions. In addition, the names of the above network elements may change in networks that evolve after 5G, and this application does not limit them.

[0156] Furthermore, as shown in Figure 1, the terminal device accesses the CN through the RAN device, and the terminal device can communicate with the AMF network element through the N1 interface (referred to as N1); the RAN device communicates with the AMF network element through the N2 interface (referred to as N2); the RAN device communicates with the UPF network element through the N3 interface (referred to as N3); the SMF network element communicates with the UPF network element through the N4 interface (referred to as N4); different UPF network elements communicate through the N9 interface (referred to as N9); the UPF network element accesses the data network (DN) through the N6 interface (referred to as N6).

[0157] It should be understood that, as described above regarding AUSF network elements, terminal device access to the CN may include 3GPP access and non-3GPP access. Specifically, when a terminal device accesses the CN via 3GPP access technology, it accesses the CN via the RAN device; when a terminal device accesses the CN via non-3GPP access technology, it accesses the CN via a non-3GPP access gateway (N3G-GW).

[0158] It can be understood that in the embodiments of the present application, the terminal device that accesses the CN through the RAN device can be called a 3GPP terminal device; the terminal device that accesses the CN through the N3G-GW can be called a non-3GPP terminal device. This is explained uniformly here and will not be repeated below.

[0159] Furthermore, the terminal device in Figure 1 above can be multiple terminal devices. Among them, the multiple terminal devices can form a personal IoT network (PIN). PIN is a multi-node organization method, usually including member nodes, management nodes, and gateway nodes. Furthermore, the management node and the gateway node can be served by one member node. Member nodes can communicate with each other through non-3GPP access technology, and member nodes and CN can communicate through gateway nodes. The gateway node can have 3GPP access capabilities. For example, the member node can be the above-mentioned non-3GPP terminal device, and the gateway node can be the above-mentioned N3G-GW.

[0160] Alternatively, to improve communication efficiency between terminal devices that are close to each other, the multiple terminal devices may exchange data using short-range direct communication, such as through a proximity-based services (ProSe) mode. The ProSe mode may refer to direct data exchange between terminal devices or data exchange through the N3G-GW.

[0161] Based on the aforementioned 3GPP network communication architecture and SC deployment method, the following introduces the architecture of the decentralized 3GPP network.

[0162] FIG2 is a schematic diagram of the architecture of a decentralized 3GPP network provided in an embodiment of the present application. As shown in FIG2 , the architecture of the 3GPP network may include: a management network element and at least one BC managed by the management network element. The management network element has a management function, wherein the management function is used to manage the at least one BC, such as the deployment of SCs and the control of new nodes to be added to the BC. The at least one BC is a BC within the 3GPP network, that is, the device type of the node within each BC in the at least one BC may include: the above-mentioned terminal device, RAN device, or CN device.

[0163] It is understood that the nodes within the BC may also include independent nodes (INN). Among them, INN may refer to nodes that have BC capabilities but do not participate in wireless communication services of terminal devices and / or RAN devices, such as edge computing (EC) nodes.

[0164] Furthermore, the RAN and CN described above can be infrastructure within a 3GPP network (i.e., an operator network) and can jointly provide 3GPP functions, such as the aforementioned NFs, service functions, or network access and data transmission functions provided by the RAN. In other words, the SC deployed at the BC node can be used to implement communication network functions, such as network function-smart contracts, service function-smart contracts, and data transmission-smart contracts. For example, as shown in Figure 2, the NF described above can be implemented via a network function-smart contract (NF-SC), and the service functions described above can be implemented via a service function-smart contract. The NF-SC and service function-smart contract described above can be deployed in each of the at least one BC described above.

[0165] For example, as shown in Figure 2, at least one BC may include BC#1 to BC#n, and each BC in BC#1 to BC#n may deploy a different SC. Among them, BC#1 may deploy two NF-SCs, namely AMF-SC and AUSF-SC. BC#2 may deploy UDM-SC and NRF-SC. BC#3 may deploy SMF-SC and NEF-SC. BC#n may deploy AF-SC and business functions - smart contracts. Of course, the nodes in each BC in BC#1 to BC#n are not exactly the same. For example, a node in the 3GPP network may be a member of both BC#1 and BC#3. That is to say, in an embodiment of the present application, a node in the 3GPP network may join multiple BCs at the same time.

[0166] In one possible implementation, the management network element may be a CN network element. The management network element may be a management plane network element, or the management network element may be a control plane network element. It is understood that the management network element may be a newly added network element in the CN, such as a ledger anchor function (LAF) network element.

[0167] It should be understood that the BC deployment SC method shown in FIG2 is merely an example. For example, as the network evolves, the SCs deployed by different BCs may be at least partially identical. This embodiment of the present application does not impose any specific limitation on this.

[0168] Optionally, the management network element can be a separately deployed CN network element. Alternatively, the management network element can be deployed in conjunction with the aforementioned CN network element. For example, the management functions of the management network element can be deployed in conjunction with the aforementioned AMF network element. It is understood that the management network element can also be deployed on the RAN side. For example, the management network element can be deployed in a DU, CU, O-DU, O-CU, O-RU, or an O-RAN intelligent controller, etc. This embodiment of the present application does not specifically limit this.

[0169] Optionally, the management network element may be independent of the BC, for example, the management network element may be a network element in the 3GPP network that is not a member of any BC. In other words, the management network element may not be a node in the BC, that is, the management function may be provided in a non-decentralized manner.

[0170] Alternatively, the management network element may be a node within a BC, and the functions corresponding to the SC deployed by the BC include the management functions of the management network element. In other words, the management functions of the management network element may be implemented by the SC, thereby providing the management functions in a decentralized manner.

[0171] It should also be understood that in the embodiment of the present application, the 3GPP network may include one or more operator networks, and thus the management network element may manage BCs in one or more operator networks. In other words, the management network element may manage BCs across operator networks.

[0172] It can also be understood that in the embodiments of the present application, the management network element is only an exemplary expression and can also be replaced by BC management network element, BC control network element, BC management and control network element, SC management network element, SC control network element, SC management and control network element, or BC management controller, etc.

[0173] Figure 3 is a schematic diagram of a BC in a decentralized 3GPP network provided by an embodiment of the present application. As shown in Figure 3, the BCs managed by the BC management network element are BC#a, BC#b, and BC#c, and the existing nodes in the BC include: node #1 to node #K. Among them, node #K is located in BC#a and BC#b, node #K-1 is located in BC#b and BC#c, and node #1 is located in BC#c. The SCs deployed by BC#a to BC#b are different. The SCs deployed by BC#a include: SC#1 to SC#3, the SCs deployed by BC#b include: SC#4 to BC#6, and the SCs deployed by BC#c include: SC#7 to SC#9.

[0174] Node #a is a newly added node. Node #a can join BC #a under the control and management of the management network element, and SC #2 in BC #a is deployed.

[0175] It should be understood that the newly added node to be added to the BC is a newly added node with respect to the BC, that is, the newly added node can be a node newly connected to the communication network, or a node that has already joined the communication network but has not joined the BC, or a node that has exited the BC and is waiting to join the BC, or a node that has not exited the current BC and is waiting to join a new BC. It is understandable that the nodes in the communication network have the characteristics of high heterogeneity, complexity, and high dynamics. Therefore, for a node that has exited the BC and is waiting to join the BC, or a node that is waiting to join a new BC, its node status may also change, that is, it may not meet the deployment requirements of the SC in the communication network, and thus it is also necessary to join the BC for the node and to control and manage the SC deployed on the BC.

[0176] In an embodiment of the present application, for a newly added node, it can first access the communication network, and then the newly added node can obtain relevant information of the management network element (such as the address of the management network element, or the identifier of the management network element, etc.), or the management network element can perceive the newly added node through other network elements (such as the UDM network element), so that information exchange can be carried out between the newly added node and the management network element.

[0177] For example, for the decentralized 3GPP network shown in Figure 2, the 3GPP network has built multiple BCs. If the newly added node is a terminal device, the newly added node can first access the RAN and then access the 3GPP network through BC#1 deployed with AMF-SC.

[0178] It is understood that if the 3GPP network does not have a BC with an AMF-SC deployed, the AMF network element in the 3GPP network can be used to access the 3GPP network. Similarly, RAN equipment and core network equipment can access the 3GPP network through a BC with a corresponding NF-SC deployed, or use the corresponding network element in the 3GPP network to access the 3GPP network.

[0179] As shown in Figure 4, a schematic diagram of the architecture of a communication system applicable to the communication method provided in an embodiment of the present application is provided. The communication system may include a first device and a management network element. The first device may be the newly added node to be added to the BC mentioned above, and the management network element may manage and control the BC added by the first device and the deployed SC. Furthermore, the first device may be a logical entity or a physical entity. For example, the first device may be a terminal device or a chip of a terminal device. For another example, the first device may be a RAN device or a chip of a RAN device. For another example, the first device may be a CN device or a chip of a CN device, which is not specifically limited in the embodiment of the present application.

[0180] In one possible implementation, the first device sends a first request message to the management network element, the first request message includes the function corresponding to the SC that the first device expects to deploy; the first device receives first feedback message from the management network element, the first feedback message includes the address information of the second device, and the SC deployed by the second device includes the first SC among the SCs that the first device expects to deploy; the first device obtains the data of the first SC based on the address information of the second device.

[0181] Because in the embodiment of the present application, the first device can send the function corresponding to the SC it expects to deploy to the management network element, and then receive the address information of the second device from the management network element, so that the first device can join the BC joined by the second device according to the address information of the second device, thereby obtaining the data of the first SC in the SC that the first device expects to deploy, in order to deploy the first SC. That is, for the first device to be added to the BC in the decentralized communication network, the first device does not perceive the nodes of the BC in the communication network and the information of the SC deployed by the BC, and can obtain the address information of the second device through the management network element, and then determine the BC that the first device can join and the SC that can be deployed, that is, the BC joined by the first device and the deployed SC are managed and controlled by the management network element. Therefore, based on the communication method provided in the embodiment of the present application, the newly added nodes to be added to the BC can be managed and controlled in the decentralized communication network, so as to optimize the communication network services.

[0182] The specific implementation of the above solution will be described in detail in the following embodiments and will not be repeated here.

[0183] It is understood that the devices or network elements included in the communication system shown in Figure 4 are merely exemplary descriptions and do not limit the embodiments of the present application. In fact, in the communication system shown in Figure 4, the number of first devices can be one or more, and the number of management network elements can be one or more. Furthermore, the communication system shown in Figure 4 may also include other devices or network elements that have an interactive relationship with the devices or network elements shown in the figure, such as a second device, which is not specifically limited here.

[0184] In one possible implementation, the first device, management network element, and second device in the embodiment of the present application can also be referred to as a communication device, which can be a general device or a dedicated device, and the embodiment of the present application does not make specific limitations on this.

[0185] In one possible implementation, the related functions of the first device, the management network element, and the second device in the embodiment of the present application can be implemented by a single device, or can be implemented by multiple devices together, or can be implemented by one or more functional modules within a single device, and the embodiment of the present application does not specifically limit this. It is understandable that the above functions can be network elements in hardware devices, software functions running on dedicated hardware, or a combination of hardware and software, or virtualized functions instantiated on a platform (e.g., a cloud platform).

[0186] For example, the relevant functions of the first device, or the management network element, or the second device in the embodiment of the present application can be implemented by the communication device 500 in Figure 5. Figure 5 shows a schematic structural diagram of the communication device 500 provided in an embodiment of the present application. The communication device 500 includes one or more processors 501, a communication line 502, and at least one communication interface (Figure 5 is only exemplary and is described by taking the communication interface 504 and one processor 501 as an example), and may also include a memory 503.

[0187] The processor 501 may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of the program of the present application.

[0188] The communication line 502 may include a path for connecting different components.

[0189] Communication interface 504 may be a transceiver module for communicating with other devices or communication networks, such as Ethernet, RAN, or WLAN. For example, the transceiver module may be a device such as a transceiver or a transceiver. In one possible implementation, communication interface 504 may also be a transceiver circuit located within processor 501, used to implement signal input and output to the processor.

[0190] The memory 503 may be a device having a storage function. For example, it may be a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM) or other types of dynamic storage devices that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compact disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory may exist independently and be connected to the processor via a communication line 502. The memory may also be integrated with the processor.

[0191] The memory 503 is used to store computer-executable instructions for executing the solution of the present application, and the execution is controlled by the processor 501. The processor 501 is used to execute the computer-executable instructions stored in the memory 503, thereby implementing the communication method provided in the embodiment of the present application.

[0192] Alternatively, in an embodiment of the present application, the processor 501 may also perform functions related to the processing of the communication method provided in the following embodiments of the present application, and the communication interface 504 is responsible for communicating with other devices or communication networks, which is not specifically limited in the embodiment of the present application.

[0193] In a possible implementation, the memory 503 in the embodiment of the present application can also be used to store the information or parameters described in the following embodiments, such as the above-mentioned first request information, first feedback information, and data of the first SC.

[0194] The computer-executable instructions in the embodiments of the present application may also be referred to as application code, which is not specifically limited in the embodiments of the present application.

[0195] In a specific implementation, as an embodiment, the processor 501 may include one or more CPUs, such as CPU0 and CPU1 in FIG. 5 .

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

[0197] In a specific implementation, as an embodiment, the communication apparatus 500 may further include an output device 505 and an input device 506. The output device 505 communicates with the processor 501 and may display information in a variety of ways.

[0198] The communication device 500 may be a general device or a dedicated device. For example, the communication device 500 may be any possible terminal device or network device mentioned above, or a device in a terminal device or a network device.

[0199] The communication method provided in the embodiment of the present application will be described in detail below with reference to FIG6 .

[0200] It should be understood that the information names between the various devices or the names of the various parameters in the information in the following embodiments of the present application are only examples, and other names may be used in specific implementations. The embodiments of the present application do not specifically limit this.

[0201] Taking the interaction between the first device and the management network element shown in FIG6 as an example, as shown in FIG6 , a communication method provided in an embodiment of the present application includes the following steps:

[0202] S601: A first device sends a first request message to a management network element. Correspondingly, the management network element receives the first request message from the first device, wherein the first request message includes a function corresponding to the SC that the first device desires to deploy.

[0203] S602: The management network element determines the address information of the second device according to the first request information, wherein the SC deployed by the second device includes the first SC among the SCs expected to be deployed by the first device, and the first SC is deployed in the first BC.

[0204] S603: The management network element sends first feedback information to the first device. Correspondingly, the first device receives the first feedback information from the management network element. The first feedback information includes the address information of the second device.

[0205] S604: The first device obtains data of the first SC according to the address information of the second device.

[0206] The above steps S601 to S604 are described in detail below.

[0207] For step S601:

[0208] It should be understood that with respect to the aforementioned description of FIG4 , the first device may be a newly added node to be added to the BC in the decentralized 3GPP network. The first device may refer to a device in the 3GPP network, such as the description of the first device in FIG4 , which will not be repeated here.

[0209] Furthermore, as described in Figure 3 above, the newly added nodes can be nodes newly connected to the 3GPP network, nodes already connected to the 3GPP network but not yet joining a BC, nodes exiting a BC and waiting to join another BC, or nodes that have not yet exited the current BC and are waiting to join a new BC. In other words, for existing nodes in the 3GPP network, their joining a BC and the deployment of SCs on that BC also require management and control by the management network element.

[0210] It should be understood that the aforementioned "to be joined BC" may mean that the newly added node desires to join the BC. Alternatively, the aforementioned "to be joined BC" may mean that the newly added node can join the BC in response to a request from a management network element or other network element or device.

[0211] It is understood that the address information or identifier of the management network element may be configured or pre-configured. For example, when the first device accesses the 3GPP network, the address information or identifier of the management network element may be configured for the first device. The first device may then establish a communication connection with the management network element using the address information or identifier of the management network element, thereby enabling the first device to send the first request information to the management network element.

[0212] In a possible implementation, the address information of the management network element may be an Internet Protocol (IP) address, and the identifier of the management network element may include: a fully qualified domain name (FQDN) and / or a uniform resource identifier (URI).

[0213] It should be understood that the management network element in step S601 can refer to the relevant description of the management network element in Figure 2 above, and will not be repeated here.

[0214] It can be understood that the above-mentioned first device does not perceive the information of the BC nodes and the SC deployed by the BC in the 3GPP network, that is, for the first device, the address information of the BC nodes in the 3GPP network, the specific content and deployment status of the SC are unknown, and the corresponding management network element cannot predict the SC that the first device expects to deploy. The first device informs the management network element of the function corresponding to the SC it expects to deploy through the first request message, so that the management network element can determine the SC that the first device expects to deploy and the BC that it can join based on the first request message, thereby avoiding the first device from joining a BC that it does not expect to join, and avoiding the first device from deploying an SC that it does not expect to deploy. The content of the above-mentioned first request message is described in detail below.

[0215] It should be understood that the function corresponding to the SC that the first device in the first request information expects to deploy may be the NF and service function in the aforementioned "decentralized 3GPP network", wherein the NF and service function, specifically, the first request information may include the identifier or index of the aforementioned function.

[0216] In one possible implementation, the functions corresponding to the SC that the first device expects to deploy may include multiple functions, wherein each of the multiple functions may correspond to one SC. In other words, the SC that the first device expects to deploy may be multiple SCs.

[0217] In a possible implementation, the multiple SCs that the first device desires to deploy may belong to the same BC, namely, the first BC. In other words, the first device can deploy the multiple SCs that it desires to deploy by joining one BC.

[0218] Alternatively, in another possible implementation, the multiple SCs that the first device desires to deploy may not belong to the same BC. That is, if there are multiple first BCs, the first device may join multiple first BCs and deploy multiple SCs belonging to different first BCs.

[0219] It can be understood that the function corresponding to the SC that the first device expects to deploy can also be alternatively expressed as: the type of SC that the first device expects to deploy. The type of SC can refer to the type of function it implements, for example, the type of SC can be divided into AMF type, AUSF type, UDM type, or AF type, etc.

[0220] It should be understood that, as described in the aforementioned “Nodes in the Alliance Chain Joining BC Scheme”, the nodes within the network are highly dynamic, and the management network element can obtain relevant information about the first device to determine whether the functions corresponding to the SC that the first device expects to deploy match the first device, thereby ensuring the quality of decentralized 3GPP network services. For example, considering the mobility of the terminal device, it may constantly switch cells, and then when the first device is a terminal device, the first device is not suitable for deploying AMF-SC. For another example, if the first device estimates that the online time is only a few tens of minutes, the quality of the decentralized 3GPP network service cannot be guaranteed, and then the first device is not suitable for deploying SC. For another example, if the first device runs slowly, the first device is not suitable for deploying NF-SCs such as UPF and UDM that require higher computing power.

[0221] In one possible implementation, the first request information further includes at least one of the following: type information of the first device, operating information of the first device, or capability information of the first device. In other words, the first request information can enable the management network element to match the first device with an SC suitable for deployment from among the SCs that the first device desires to deploy, thereby reducing the impact on the quality of decentralized 3GPP network services.

[0222] In one possible implementation, the management network element may also obtain the type information, operation information, or capability information of the first device through other network elements. For example, the management network element may obtain the AMF registration information of the first device through the UDM network element, and thus obtain the type information of the first device.

[0223] In one possible implementation, the type information of the first device specifically includes: the device type of the first device, and / or the type of the participating role of the first device in the SC that the first device expects to deploy. Among them, the device type of the first device may include: terminal device, RAN device, or CN device, etc. It can be understood that the management network element can determine whether the function corresponding to the SC that the first device expects to deploy matches the first device based on the device type of the first device. For example, the first device is a terminal device, and the functions corresponding to the SC that the first device expects to deploy include AMF and AF. Due to the mobility of the terminal device, the 3GPP network may not expect the terminal device to deploy AMF-SC, and then the management network element can determine that the first device can deploy AF-SC.

[0224] In one possible implementation, the types of participating roles in an SC may include at least one of the following: a verification role, a transaction role, a backup role, or a network access provider role. The transaction role generates transaction requests. The verification role verifies the transaction request. The backup role does not participate in transactions or verification, but only backs up BC data. The network access role primarily provides network access services for users.

[0225] For example, taking the SC as an AMF-SC, during the initial NAS security context establishment process between the terminal device and the AMF, the AMF should select a NAS encryption algorithm and a NAS integrity protection algorithm. Then, within the BC deploying the AMF-SC, the transaction role within the BC can select a NAS encryption algorithm and a NAS integrity protection algorithm. According to the BC protocol corresponding to the first BC, the selected NAS encryption algorithm and NAS integrity protection algorithm are translated into a transaction request. The signature is then added to the transaction request and sent to the BC nodes within the first BC. Furthermore, after receiving the transaction request, the verification role performs consensus verification. Specifically, each of the multiple verification roles returns the voting result to the transaction role to complete the transaction consensus. The transaction role can then upload the transaction consensus result data to the chain. Each node within the BC then backs up this data and updates the SC state, completing the transaction request. If the transaction consensus result is that the NAS encryption algorithm and NAS integrity protection algorithm selected in the transaction request are accepted, the network access role within the BC can send the NAS encryption algorithm and NAS integrity protection algorithm to the terminal device.

[0226] In one possible implementation, the first device may desire to deploy multiple SCs. The first device's participating role types in the SCs desired to be deployed by the first device may include the participating role types corresponding to each of the multiple SCs. For example, the first device may desire to deploy SC#1, SC#2, and SC#3. The first device's participating role types in the SCs desired to be deployed by the first device may include the participating role type in SC#1, the participating role type in SC#2, and the participating role type in SC#3.

[0227] In one possible implementation, the operating information of the first device specifically includes: the estimated online duration of the first device and / or the estimated online time period of the first device. The online duration may refer to the minimum network duration that the first device estimates it can contribute to the BC, such as 0.5 hours, 1 hour, or 1.5 hours. The estimated online time period of the first device may refer to the estimated time period during which the first device is expected to be online in the BC, such as 10:00 AM to 12:00 PM.

[0228] It is understood that, as described above, to ensure the quality of decentralized network services, the network duration contributed by nodes in the network in BC should be greater than or equal to the first time threshold, where the first time threshold can be 1 hour, 2 hours, 3 hours, or longer.

[0229] It is also understood that to further ensure the quality of decentralized network services, at least some nodes within the network should be online to provide network services during peak network load periods. For example, the peak network load period may be 8:00 PM to 10:00 PM. If the first device's estimated online time period is 6:00 PM to 8:00 PM, then the first device is not suitable for deploying SC.

[0230] In one possible implementation, the capability information of the first device specifically includes at least one of the following: the computing capability of the first device, the storage capability of the first device, or the network connection capability of the first device. The computing capability of the first device may refer to the computing speed (e.g., CPU frequency) or computing capability of the first device. The storage capability of the first device may refer to the memory size, local storage size, or read / write rate (or read / write bandwidth) of the first device. The network connection capability of the first device may refer to the type of network connection provided by the first device, such as 3GPP access, Wi-Fi, Bluetooth, or wired connection.

[0231] It can be understood that in order to improve security, the legitimacy of the first device joining the BC can be verified.

[0232] In a possible implementation, the management network element may verify the legitimacy of the first device joining the BC. The management network element may determine the legitimacy of the first device joining the BC by verifying the identity of the first device.

[0233] For example, the first request information may further include an identifier (ID) of the first device. Thus, the management network element may verify the legitimacy of the first device joining the BC through the ID of the first device.

[0234] Table 1 exemplifies the specific content that may be included in the first request information. The first request information may include the first device's node ID, device type, estimated online duration, CPU frequency, memory size, storage size, network interface list, requested SC list, and participating role type list. It is understood that the functions of each of these parameters can be found in the aforementioned descriptions of the first device's type information, operating information, or capability information, and will not be further elaborated here.

[0235] Table 1

[0236] In one possible implementation, for the legitimacy verification of the first device joining the BC, the management network element may also request other network elements (such as a trusted anchor (TA)) or a communication entity to verify the legitimacy of the first device joining the BC. Alternatively, the management network element may also obtain the legitimacy verification results of the first device joining the BC by other network elements or communication entities. Among them, the other communication entity may be a server that records the identity information of the first device. In one possible implementation, for the legitimacy verification of the first device joining the BC, it may be before step S601. For details of the verification process between the management network element and the first device, please refer to the method flow shown in Figures 8 to 10 below.

[0237] For step S602:

[0238] Based on the received first request information, the management network element determines the first SC suitable for deployment of the first device, and then determines the address information of the second device based on the first SC. The address information of the second device can be an IP address, an FQDN, or a URI, which is not specifically limited in the embodiment of the present application. It can be understood that the address information of the second device can be used for the first device to join the BC corresponding to the first SC, and the second device can also be called an entry node.

[0239] Furthermore, the first request information can enable the management network element to feed back the address information of the second device, thereby enabling the first device to obtain the address information of the BC node, thereby joining the BC and deploying the SC it desires to deploy.

[0240] In a possible implementation, the management network element selects the first SC according to information of at least one BC and the function corresponding to the SC desired to be deployed in the first request information.

[0241] In another possible implementation, the management network element selects a first SC based on information about at least one BC, the functions corresponding to the desired SC, and the type information, operation information, and capability information. Specifically, the management network element may first select subsequent SCs based on the functions corresponding to the desired SC, and then select an SC from the candidate SCs that matches the type information, operation information, or capability information of the first device as the first SC.

[0242] In one possible implementation, the management network element obtaining information about at least one BC within the 3GPP network may include: the management network element receiving registration information from a node within each of the at least one BC within the 3GPP network. The registration information may include information about the node within the BC and information about the SC deployed by the BC. In other words, the management network element may store information about at least one BC within the 3GPP network and, based on the SC that the first device desires to deploy, determine, from the at least one BC, the address information of the node within the BC where the SC desired to be deployed by the first device is deployed.

[0243] In one possible implementation, the information of at least one BC may include one or more of the following: node information within each of the at least one BC, information about the SC deployed by each of the at least one BC, or the BC ID of each of the at least one BC. The node information within the BC may include at least one of the following: node ID, node device type, node address information, node location information, node PLMN ID, node PLMN type, or the node's role in the SC. The node's PLMN ID may be used to identify the operator network to which the node belongs. For example, the nodes within the BC may include node #1 and node #2. Node #1 and node #2 may belong to the same operator network (i.e., PLMN), or node #1 and node #2 may belong to two different operator networks. The node's PLMN type may refer to the PLMN type of a 3GPP terminal device. The PLMN type of a 3GPP terminal device may include a home PLMN and a visited PLMN. For example, if a 3GPP terminal device roams from the physical area corresponding to the home PLMN to another physical area, the 3GPP terminal device can access the 3GPP network through the RAN equipment in the visited PLMN corresponding to the other physical area. In other words, the current location range of the 3GPP terminal device can be determined by the PLMN type of the 3GPP terminal device.

[0244] In a possible implementation, the information of the SC deployed by the BC may include at least one of the following: the ID of the SC, the function corresponding to the SC, and the matching condition corresponding to the SC. The ID of the SC may be an account address.

[0245] In one possible implementation, the matching conditions corresponding to the SCs can be used by the management network element to match the SCs that the first device expects to deploy, so as to screen out the SCs suitable for deployment by the first device, thereby further ensuring the quality of decentralized 3GPP network services.

[0246] The following describes a specific method in which the management network element determines the address information of the second device in conjunction with the matching conditions corresponding to the SC.

[0247] In a possible implementation, the management network element determines the address information of the second device according to the first request information, including:

[0248] S602a. The management network element determines a first SC from the candidate SC set according to the first request information and a matching condition corresponding to at least one SC in the candidate SC set.

[0249] It is understood that the functions corresponding to the SCs in the candidate SC set are the same as the functions corresponding to the SCs that the first device desires to deploy. The multiple SCs deployed in the at least one BC include SCs in the candidate SC set; or, the SCs managed by the management network element include SCs in the candidate SC set; or, the SCs in the candidate SC set may be registered in the 3GPP network, and information about the BC deploying the SCs may be obtained by the management network element.

[0250] It can also be understood that each SC in the above-mentioned candidate SC set may have matching conditions; or, some SCs in the above-mentioned candidate SC set may not have matching conditions, and the embodiments of the present application do not make specific limitations on this.

[0251] In one possible implementation, the candidate SC set is obtained from a registration network element. The registration network element is used to store the SC deployed for each of the multiple BCs managed by the management network element. In other words, the management network element can obtain the candidate SC set by querying the registration network element. It is understood that the registration network element can be the aforementioned UDM network element, an NRF network element, or another network element, and this embodiment of the present application does not specifically limit this.

[0252] In a possible implementation, a matching condition corresponding to at least one SC in the candidate SC set is pre-configured.

[0253] Alternatively, in another possible implementation, the matching condition corresponding to at least one SC in the candidate SC set is obtained from a registration network element, wherein the registration network element is used to store the SC deployed by each of the multiple BCs managed by the management network element, and the matching condition corresponding to the SC deployed by each of the multiple BCs.

[0254] In one possible implementation, the functions corresponding to the aforementioned registration network element can also be implemented by the SC, thereby providing the registration function in a decentralized manner. That is, in the embodiment of the present application, the candidate SC set and / or the matching conditions corresponding to at least one SC in the candidate SC set can be obtained from the BC node where the registration function-SC is deployed.

[0255] In one possible implementation, the matching condition may include at least one of the following: type information corresponding to the SC for which deployment is prohibited, operational information corresponding to the SC for which deployment is prohibited, and capability information corresponding to the SC for which deployment is prohibited. It is understood that the type information corresponding to the SC for which deployment is prohibited may be replaced by type information corresponding to the SC for which deployment is permitted. The operational information corresponding to the SC for which deployment is prohibited may be replaced by operational information corresponding to the SC for which deployment is permitted. The capability information corresponding to the SC for which deployment is prohibited may be replaced by capability information corresponding to the SC for which deployment is permitted, etc.

[0256] In one possible implementation, the type information may include: device type and / or participating role type in the SC. The operation information may include: online duration and / or online time period. The capability information may include: computing power, storage capacity, or network connection capacity. The above type information, operation information, and capability information can be found in the description of step S601 above and will not be repeated here.

[0257] The following exemplifies how to determine the first SC from the candidate SC set based on a matching condition corresponding to at least one SC in the candidate SC set.

[0258] For example, the function corresponding to one SC in the candidate SC set is AMF, and the matching condition corresponding to the SC may be that the type information of the prohibited deployment corresponding to the SC is the prohibited deployment of terminal devices. If the device type of the first device is a terminal device, the SC does not match the first device; if the device type of the first device is a CN device, the SC may be the first SC.

[0259] For another example, the function corresponding to one of the SCs in the candidate SC set is UDM, and the matching conditions corresponding to the SC may be that the operating speed is greater than 1.55 GHz and the storage size is greater than or equal to 10 GB. If the operating speed of the first device is 1.7 GHz and the storage size of the first device is 10 GB, then the SC matches the first device, and the SC can be the first SC.

[0260] For another example, the function corresponding to an SC in the candidate SC set is AF, and the matching condition corresponding to the SC may be that the SC allows the participation role type to be a backup role. If the participation role type of the first device in the SC to be deployed is a verification role, then the SC does not match the first device, and the SC is not the first SC.

[0261] Table 2 provides an example of the specific content that can be included in the matching conditions. The matching conditions may include the SC ID, SC name, prohibited device type, minimum online duration, CPU frequency, memory size, storage size, allowed network connection type, second device address information, and participant role type. It is understood that the functions of each of these parameters can be found in the explanations of the parameters in Table 2 and will not be further elaborated here.

[0262] Table 2

[0263] Furthermore, based on the matching conditions shown in Table 2 above, the matching process of the candidate SC set is exemplarily described in conjunction with FIG7 .

[0264] As shown in Figure 7, the matching process includes the following steps:

[0265] S1: Determine whether the matching condition corresponding to the SC exists. If so, proceed to step S2. Otherwise, the matching fails. Determine whether the next SC exists in the candidate SC set. If so, re-enter step S1. Otherwise, the matching ends.

[0266] S2. Determine whether the device type of the first device is a device type prohibited from deployment by the SC. If not, proceed to step S3. Otherwise, the matching fails. Determine whether there is another SC in the candidate SC set. If so, proceed to step S1 again. Otherwise, the matching ends.

[0267] S3: Determine whether the online duration estimated by the first device meets the minimum online duration requirement of the SC. If so, proceed to step S4; otherwise, the matching fails. Determine whether the next SC exists in the candidate SC set. If so, re-enter step S1; otherwise, the matching ends.

[0268] S4: Determine whether the network connection capability of the first device matches the network connection type allowed by the SC. If so, proceed to step S5; otherwise, the matching fails. Determine whether there is another SC in the candidate SC set. If so, proceed to step S1 again; otherwise, the matching ends.

[0269] S5: Determine whether the computing power and storage capacity of the first device meet the minimum computing speed, minimum memory size, and minimum local storage size required by the SC. If so, proceed to step S6; otherwise, the matching fails. A determination is then made as to whether the next SC exists in the candidate SC set. If so, proceed to step S1 again; otherwise, the matching ends.

[0270] S6. Determine whether the participant role type of the first device in the SC that the first device desires to deploy is a participant role type allowed by the SC. If so, the match succeeds; otherwise, the match fails. After step S6, determine whether the next SC exists in the candidate SC set. If so, re-enter step S1; otherwise, the match ends.

[0271] It can be understood that after the above steps S1 to S6, the SC matching results can be summarized to determine the first SC.

[0272] It should be understood that the matching process shown in Figure 7 is only an example, and the present application does not limit the order of S1-S6. The management network element can process the steps in series as shown in Figure 7, or can process multiple steps in parallel, which is not specifically limited in the present embodiment.

[0273] In a possible implementation, there are multiple first SCs. It is understood that when the SCs that the first device expects to deploy are multiple SCs that the first device expects to deploy, the first SCs that meet the above matching conditions can be multiple different first SCs.

[0274] S602b: The management network element determines the address information of the second device according to the first SC.

[0275] The management network element may determine the first BC according to the first SC, and further determine the second device according to the nodes in the first BC, thereby determining the address information of the second device.

[0276] The following describes a situation where the management network element determines the second device according to the number of first SCs.

[0277] Case 1:

[0278] In the case that the number of the first SC is one, the management network element may determine one second device.

[0279] In a possible implementation, the second device may be any node within the first BC.

[0280] In another possible implementation, the second device may be a node within the first BC that can establish a communication connection with the first device. For example, the device type of the first device is a 3GPP terminal device, and the second device may be a RAN device that is physically and / or logically topologically closest to the first device, or an AMF network element. For another example, the device type of the first device is a non-3GPP terminal device, and the second device may be an N3G-GW that is physically and / or logically topologically closest to the first device. For another example, the second device may be a BC node in the same operator network or PLMN as the first device. For another example, the device type of the first device is a 3GPP terminal device, and the first device accesses the 3GPP network through a RAN device in a visited PLMN, and the second device may be a BC node in the visited PLMN. In other words, the management network element may select a node within the first BC that can directly establish a communication connection with the first device as the second device, thereby reducing communication latency and reducing the occupancy of network resources.

[0281] Case 2:

[0282] When the first SC is a plurality of first SCs, and each of the plurality of first SCs is deployed in a different BC, and the nodes in the different BCs are different, each of the plurality of first SCs can correspond to a second device, and the management network element can determine the address information of the second device corresponding to each of the plurality of first SCs.

[0283] For example, as shown in Figure 3, the multiple first SCs are: SC#2 and SC#7, SC#2 is deployed on BC#a, SC#7 is deployed on BC#c, and the nodes in BC#a include: node #a and node #K, and the nodes in BC#c include: node #K-1 to node #1, that is, the BC nodes between BC#a and BC#c are different, that is, the second device corresponding to SC#2 is different from the second device corresponding to SC#7.

[0284] It can be understood that for the second situation, the second device can also be determined in the manner described in the first situation.

[0285] Case 3:

[0286] In the case that the first SC is a plurality of first SCs, and the plurality of first SCs are deployed in the same BC, the management network element may determine a second device.

[0287] For example, as shown in Figure 3, BC#a can deploy three different SCs: SC#1, SC#2, and SC#3. In other words, the multiple first SCs can be deployed on the same BC. The management network element can then determine a second device based on the multiple first SCs, where the SCs deployed on the second device include the multiple first SCs.

[0288] It can be understood that for situation three, the second device can also be determined in the manner described in situation one.

[0289] Case 4:

[0290] When the first SC is a plurality of first SCs, and the plurality of first SCs are deployed on different BCs, but the same node exists between the different BCs, the management network element may determine one second device or a plurality of different second devices.

[0291] For example, as shown in Figure 3, SC#3 is deployed on BC#a, and SC#4 is deployed on BC#b. However, BC#a and BC#b share the same BC node, namely, Node #K. In other words, if each of the multiple first SCs is deployed on the same BC node, the management network element can determine that Node #K is the second device.

[0292] For another example, as shown in FIG3 , the management network element may select two second devices, namely, node a and node K.

[0293] It can be understood that when the capabilities of the first device (such as computing power and storage capacity) are not strong, in order to ensure the quality of decentralized 3GPP network services, it is not expected that the first device will take on too many network services. Furthermore, for the case of multiple first SCs, the management network element can also select one of the multiple first SCs, and then determine the second device based on the one first SC.

[0294] For step S603:

[0295] It is understood that when the first feedback information includes the address information of the second device, the first device can determine that the management network element agrees with the first device to deploy the SC that the first device expects to deploy. The SC that the first device expects to deploy can be one or more.

[0296] In one possible implementation, the first feedback information may further include information indicating the first SC. The information indicating the first SC may be, for example, a function corresponding to the first SC, a function type corresponding to the first SC, or an ID of the first SC, etc., which is not specifically limited in this embodiment of the present application.

[0297] It can be understood that in the case that the first device expects to deploy multiple SCs, the first device can determine which SCs among the multiple SCs are the SCs that the management network element agrees to deploy through the information used to indicate the first SC.

[0298] In a possible implementation, there are multiple first SCs, and the information for indicating the first SC may include: information for indicating each first SC in the multiple first SCs.

[0299] In one possible implementation, there are multiple first SCs, and the address information of the second device may include the address information of the second device corresponding to each of the multiple first SCs. It is understood that for the second scenario described above, the multiple first SCs may be deployed in different BCs, and thus different BCs may correspond to different second devices. The first device joins the BC through different second devices and obtains data from each of the multiple first SCs.

[0300] For step S604:

[0301] In one possible implementation, the first device obtains the data of the first SC based on the address information of the second device, including: the first device establishes a communication connection with the second device based on the address information of the second device, requests to establish a BC connection with the second device by deploying the BC protocol corresponding to the first BC, and then joins the first BC, and obtains the data of the first SC through BC data synchronization, wherein the first BC is the BC that deploys the first SC, that is, the BC that the second device joins. In other words, the first device obtains the data of the first SC by establishing a BC connection with the second device, so that the first device can deploy the first SC. Furthermore, the first device can establish a BC connection with the second device by pre-installing the BC protocol corresponding to the first BC.

[0302] In one possible implementation, the first device may obtain the BC protocol corresponding to the first BC from the registration network element or the management network element before establishing a BC connection with the second device. It is understood that the first device may also obtain the BC protocol corresponding to the first BC through other nodes other than the registration network element and the management network element, such as the second device. In addition, during the process of establishing a communication connection between the first device and the second device, the first device may request the deployment of the first SC, that is, simultaneously requesting the establishment of a BC connection and the deployment of the first SC; alternatively, the first device may first request the establishment of a BC connection and then request the deployment of the first SC, as explained below.

[0303] In a possible implementation, the first device obtains data of the first SC according to the address information of the second device, including:

[0304] S604-1: The first device sends a second request message to the second device according to the address information of the second device. Correspondingly, the second device receives the second request message from the first device, wherein the second request message is used to request the deployment of the first SC.

[0305] It can be understood that when a BC connection is not established between the first device and the second device, the second request information for requesting deployment of the first SC may include: the second request information is used to request establishment of a BC connection with the second device, and deployment of the first SC.

[0306] In a possible implementation, the second request information may include information for indicating the first SC. The information for indicating the first SC may be specifically described in the above step S603 and will not be repeated here.

[0307] S604-2: The second device sends second feedback information to the first device according to the second request information. Correspondingly, the first device receives the second feedback information from the second device. The second feedback information may include data of the BC protocol corresponding to the first BC.

[0308] That is, by sending a second request message to the second device, the first device can receive data of the BC protocol corresponding to the first BC from the second device, and thereby obtain the BC protocol corresponding to the first BC. That is, the first device does not need to have previously installed the BC protocol corresponding to the first BC to establish a BC connection with the second device. It can be understood that, compared to the first device obtaining the BC protocol from the registration network element or the management network element, the first device obtains the BC protocol corresponding to the first BC through the second device, and can reuse the interactive signaling required to establish a BC connection between the first device and the second device. Thus, there is no need to interact with the registration network element or the management network element, thereby reducing signaling overhead.

[0309] S604-3. The first device and the second device synchronize BC data according to the BC protocol corresponding to the first BC. The BC data includes data of the first SC.

[0310] It is understood that the first and second devices can perform a BC handshake according to the BC protocol corresponding to the first BC to establish a BC connection between the first and second devices, thereby completing preparations for BC data synchronization. The second request information is used to request deployment of the first SC, allowing the second device to determine the BC data to be synchronized. After BC data synchronization is completed between the first and second devices, the first device can complete deployment of the first SC.

[0311] It can be understood that the communication connection between the above-mentioned first device and the second device can be established by the NF network element in 3GPP. For example, the communication connection can be a NAS connection, a protocol data unit (PDU) session, or an IP connection, etc.

[0312] It should be understood that in the embodiment of the present application, the second request information in step S604-1 may not require the deployment of the first SC, but may also obtain the BC protocol data corresponding to the first BC by requesting the establishment of a BC connection.

[0313] In another possible implementation, the first device obtains data of the first SC according to the address information of the second device, including:

[0314] Step A: The first device sends a second request message to the second device according to the address information of the second device. Correspondingly, the second device receives the second request message from the first device. The second request message is used to request to establish a BC connection.

[0315] Step B: The second device sends second feedback information to the first device according to the second request information. Correspondingly, the first device receives the second feedback information from the second device. The second feedback information may include data of the BC protocol corresponding to the first BC.

[0316] Furthermore, after the first device obtains the BC protocol data corresponding to the first BC, the first device may perform BC interaction with the second device, such as performing a BC handshake.

[0317] Step C: The first device and the second device perform a BC handshake according to the BC protocol corresponding to the first BC.

[0318] It can be understood that the BC handshake between the first device and the second device can establish a BC connection between the first device and the second device, thereby completing the preparation before BC data synchronization.

[0319] Step D: The first device sends a third request message to the second device. Correspondingly, the second device receives the third request message from the first device. The third request message is used to request the deployment of the first SC.

[0320] Step E: The first device and the second device synchronize BC data, wherein the BC data includes data of the first SC.

[0321] That is, the first device may also first send a BC connection establishment request to the second device, and after establishing the BC connection with the second device, request the second device to deploy the first SC, and then deploy the first SC through BC data synchronization.

[0322] It should be understood that for communication between the first device and the second device, to improve security, the first device and the second device may complete security verification by verifying identity. The management network element may send information for identity verification to the first device and the second device respectively.

[0323] In one possible implementation, the first feedback information further includes first identity information, wherein the first identity information is information indicating the identity of the first device. Furthermore, the second request information further includes the first identity information.

[0324] In one possible implementation, as shown in FIG6 , the communication method provided in the embodiment of the present application further includes:

[0325] S605: The management network element sends the second identity information to the second device. Accordingly, the second device receives the second identity information from the management network element. The second identity information is information used by other devices to determine the identity of the first device. Other devices are devices other than the first device.

[0326] Accordingly, the second device sends second feedback information to the first device based on the second request information (i.e., the above-mentioned step S604-2, or step B), which may include: when the second device determines that the identity authentication of the first device is successful based on the second identity information, the second device sends the second feedback information to the first device.

[0327] It is understood that the first identity information and the second identity information can be complementary, that is, the second identity information can be used to verify whether the first identity information is correct. For example, the first identity information can be a token, and the second identity information can also be a token, and there is a one-to-one correspondence between the two. Alternatively, the first identity information can be the identity ID of the first device, and the second identity information can also be the identity ID of the first device. Then, when the second request information includes the identity ID of the first device, and the identity ID of the first device is the same as the identity ID of the first device sent by the management network element to the second device, the second device can determine that the identity authentication of the first device is successful.

[0328] In one possible implementation, as shown in FIG6 , the method provided in the embodiment of the present application further includes:

[0329] S606. The first device sends the participating role of the first device in the first SC to the BC node in the first BC. The participating role includes at least one of the following: verification role, transaction role, backup role, or network access provision role.

[0330] It should be understood that in a decentralized 3GPP network, when a newly added first device joins a BC and deploys a first SC, changes to the first BC may occur. However, because there is no centralized management center to uniformly manage the BC, the nodes within the BC and the first device are out of sync with changes to the BC. Therefore, the first device needs to synchronize changes to the current BC.

[0331] That is to say, after joining the first BC, the first device can declare to each node in the first BC that the first device has joined the BC and the participating role of the first device in the first SC, so that each node in the first BC can synchronize the status changes of the first SC.

[0332] It is understood that the first device may send the first device's participation role in the first SC to the BC nodes within the first BC by broadcasting, that is, the first device sends the first device's participation role in the first SC to each node within the BC. Alternatively, the first device may send the first device's participation role in the first SC to several nearby BC nodes and notify the nearby BC nodes to send the first device's participation role in the first SC to other nodes within the BC.

[0333] Furthermore, the first device can also send the estimated online time of the first device, capability information of the first device, etc. to the BC node within the first BC, so that other nodes within the BC can synchronize the status of the first device, thereby facilitating the execution of the SC deployed within the BC and improving the quality of decentralized 3GPP network services.

[0334] It should be understood that step S606 may be performed after the first device synchronizes the BC data, for example, after step S604-3. Alternatively, step S606 may be performed after the first device completes the handshake, for example, after step S604-6. This embodiment of the present application does not specifically limit this.

[0335] In one possible implementation, as shown in FIG6 , the method provided in the embodiment of the present application further includes:

[0336] S607. The first device sends registration information to the registration network element or the management network element. The registration information includes at least one of the following: information for identifying the BC joined by the first device, information for indicating the SC deployed by the first device, or the participating role of the first device in the SC deployed by the first device.

[0337] It should be understood that the information used to identify the BC to which the first device joins may be, for example, the ID of the BC to which the first device joins, or node information within the BC. For details, see the relevant description of the aforementioned step S602. Furthermore, the information used to indicate the SC deployed by the first device may include, for example, the ID of the SC, the function corresponding to the SC, or the matching condition corresponding to the SC.

[0338] That is to say, the first device sends registration information to the registration network element or the management network element, so that the management network element can directly obtain or obtain the latest change information of the BC in the current 3GPP network through the registration management network element, and then synchronize the latest change information of the BC in the 3GPP network, such as the information of the newly added nodes in the BC, the status of the deployed SC, the participation role of the newly added nodes in the deployed SC, etc., so that the management network element can manage and control the BC in the network and the new nodes to be added to the BC.

[0339] The following describes the BC node network exit process provided by the embodiment of the present application.

[0340] In one possible implementation, as shown in FIG6 , the communication method provided in the embodiment of the present application further includes:

[0341] S608: The first device sends network exit information to the management network element. Correspondingly, the management network element receives the network exit information from the first device. The network exit information is used to indicate the BC that the first device wishes to exit.

[0342] It is understood that the BC that the first device expects to exit may be one or more. For example, the first device has joined three BCs and currently expects to exit two of them.

[0343] Furthermore, the information used to indicate the BC that the first device expects to exit may include at least one of the following: the ID of the BC that the first device expects to exit, the ID of the SC deployed by the BC that the first device expects to exit, or the address of the entry node corresponding to the BC that the first device expects to exit.

[0344] S609: The management network element deletes the registration information of the first device in the BC that the first device wants to exit based on the network exit information.

[0345] That is, when a first device wishes to exit a BC, it sends a withdrawal message to the management network element responsible for managing the BC, so that the management network element can synchronize the BC status in a timely manner, thereby ensuring that the management network element manages and controls the nodes to be added to the BC. For example, if a node is about to join a BC that a first device wishes to exit, and the first device sends a withdrawal message, the BC management network element can determine that the first device wishes to exit the BC and cannot serve as the entry node (i.e., the second device) for the node to be added, and thus will not feedback the first device's address information to the node, thereby avoiding the node's access failure.

[0346] In one possible implementation, the management network element deletes the registration information of the first device in the BC that the first device expects to exit based on the network exit information, which may include: the management network element sends a cancellation request message to the registration network element, the cancellation request message includes information used to indicate the BC that the first device expects to exit; the management network element receives a cancellation request confirmation message from the registration network element, and the cancellation request confirmation message is used to confirm that the registration information of the first device in the BC that the first device expects to exit has been deleted.

[0347] It can be understood that the management network element can put the BC-related data in the 3GPP network into the registration network element for unified storage and maintenance, thereby reducing the storage burden of the management network element. The management network element can delete the registration information of the first device in the BC that the first device expects to exit, and it can be deleted through the registration network element.

[0348] In one possible implementation, as shown in FIG6 , the communication method provided in the embodiment of the present application further includes:

[0349] S610: The management network element sends a network exit confirmation message to the first device. Correspondingly, the first device receives the network exit confirmation message from the management network element. The network exit confirmation message is used to confirm that the registration information of the first device in the BC that the first device wishes to exit has been deleted.

[0350] It can be understood that after the management network element deletes the registration information of the first device in the BC that the first device wants to exit, it sends a network exit confirmation message to the first device, indicating that the network has made relevant preparations for the first device to exit the BC, and notifies the first device that it can exit the BC.

[0351] It should be understood that the first device may, based on the network exit confirmation information, delete the BC data, such as account data, of the BC that the first device wishes to exit. Specifically, the first device may terminate the BC protocol script corresponding to the BC that the first device wishes to exit. For another example, if the first device's participating role is to provide network access, the first device provides BC access services by configuring a local wireless interface. Therefore, when the first device exits the network, the first device may, based on the network exit confirmation information, shut down the local wireless interface.

[0352] In a possible implementation, the first device may further send a deletion confirmation message to the management network element, wherein the deletion confirmation message is used to confirm that the BC data of the first device in the BC that the first device desires to exit has been deleted.

[0353] It can be understood that BC is a decentralized network. After receiving the exit information, the management network element can broadcast the exit information to the BC that the first device wants to exit, so that each node in the BC that the first device wants to exit can synchronize the latest status of the BC.

[0354] In one possible implementation, as shown in FIG6 , the communication method provided in the embodiment of the present application further includes:

[0355] S611: The management network element sends a network exit instruction message to the second device based on the network exit information. Correspondingly, the second device receives the network exit instruction message from the management network element. The network exit instruction message is used to instruct the first device to exit the BC that the first device desires to exit.

[0356] It should be understood that in order to save storage overhead, the management network element or registration network element may only store the address information of the entry node (i.e., the second device) corresponding to each BC, and then the management network element sends the exit instruction information to the second device, so that the second device broadcasts the exit instruction information to each node within the BC, so as to synchronize the latest status of the BC.

[0357] In a possible implementation, the communication method provided in the embodiment of the present application further includes: the second device acquiring network exit instruction information, wherein the network exit instruction information is used to instruct the first device to exit the BC that the first device desires to exit.

[0358] Further, the network exit indication information may be obtained from a management network element; or, the network exit indication information may be obtained from the first device.

[0359] S612: The second device broadcasts the network exit instruction information to other BC nodes in the BC that the first device wants to exit, except the first device, according to the network exit instruction information.

[0360] It should be understood that step S611 may be performed after the above step S608, for example, step S611 may be performed before or after the above step S609, or step S611 may be performed simultaneously with step S609.

[0361] In another possible implementation, when the first device sends network exit information to the management network element, it can also broadcast network exit indication information to the BC that the first device expects to exit, so that the management network element and each node within the BC that the first device expects to exit can synchronize the latest status of the BC that the first device expects to exit. That is, there is no need for the management network element to interact with the nodes within the BC that the first device expects to exit to synchronize the latest status of the BC that the first device expects to exit, which can save signaling overhead.

[0362] Because in the embodiment of the present application, the first device can send the function corresponding to the SC it expects to deploy to the management network element, and then receive the address information of the second device from the management network element, so that the first device can join the BC joined by the second device according to the address information of the second device, that is, the first BC, and thereby obtain the data of the first SC in the SC that the first device expects to deploy, in order to deploy the first SC. That is, for the first device to be added to the BC in the decentralized communication network, the first device does not perceive the nodes of the BC in the communication network and the information of the SC deployed by the BC, but obtains the address information of the second device through the management network element, and then determines the BC that the first device can join and the SC that can be deployed, that is, the BC joined by the first device and the deployed SC are managed and controlled by the management network element. Therefore, based on the communication method provided in the embodiment of the present application, the newly added nodes to be added to the BC can be managed and controlled in the decentralized communication network, so as to optimize the communication network services.

[0363] Among them, the action of the first device in the above steps S601 to S612 can be performed by the processor 501 in the communication device 500 shown in Figure 5 calling the application code stored in the memory 503 to instruct the communication device 500 to execute, the action of the management network element in the above steps S601 to S612 can be performed by the processor 501 in the communication device 500 shown in Figure 5 calling the application code stored in the memory 503 to instruct the communication device 500 to execute, and the action of the second device in the above steps S601 to S612 can be performed by the processor 501 in the communication device 500 shown in Figure 5 calling the application code stored in the memory 503 to instruct the communication device 500 to execute. The embodiment of the present application does not impose any restrictions on this.

[0364] As described in the aforementioned step S601 regarding the legitimacy verification of the first device joining the BC, this legitimacy verification can be performed before step S601. Below, taking the first device as a CN device and the second device as a CN device as an example, combined with the legitimacy verification process between the management network element and the first device, the communication method provided in the embodiment of the present application is exemplarily described. Figure 8 is a schematic diagram of another communication method provided in the embodiment of the present application, as shown in Figure 8, including the following steps:

[0365] S801: A first device sends a network access request to a management network element. Accordingly, the management network element receives the network access request from the first device. The network access request may include the identity ID of the first device.

[0366] S802. The management network element sends the network access request result to the first device. Accordingly, the first device receives the network access request result from the management network element. The network access request result is determined based on the verification result of the identity ID of the first device. For example, when the identity ID of the first device is verified, the network access request result is used to indicate that the network access request of the first device is approved. For another example, when the identity ID of the first device is not verified, the network access request result is used to indicate that the network access request of the first device is rejected. It can be understood that the management network element can configure the identity authentication function of the first device, that is, the management network element can locally verify the identity ID of the first device, and then determine the legitimacy of the first device joining the BC. It can also be understood that since the CN device and the RAN device belong to the infrastructure of the 3GPP network element, the management network element can determine the authority of the CN device and the RAN device to join the BC.

[0367] Furthermore, optionally, when the identity ID of the first device is verified successfully, the network access request result may include the first identity information, wherein the first identity information may be a network access permission certificate (eg, a token).

[0368] It can be understood that the above steps S801 to S802 are the relevant process of the first device joining the BC. After the first device passes the legality verification of joining the BC, the first device can send a first request message to the management network element (ie step S601).

[0369] S803: The first device sends a BC joining and SC deployment request to the management network element. Accordingly, the management network element receives the BC joining and SC deployment request from the first device. The BC joining and SC deployment request includes first request information, i.e., the function corresponding to the SC that the first device desires to deploy.

[0370] The specific implementation of step S803 may refer to the aforementioned step S601 and will not be repeated here.

[0371] S804. The management network element determines the address information of the second device and the first SC according to the BC joining and SC deployment request.

[0372] The specific implementation of step S804 can refer to the aforementioned step S602 and will not be repeated here.

[0373] Optionally, the management network element may obtain query results from the registration network element. The query results include the SCs currently deployed in the network and the address information of the entry node corresponding to the BC that deployed the SCs. It is understood that the SCs currently deployed in the network may be the candidate SC set in step S601.

[0374] S805: The management network element sends a first feedback result to the first device. Accordingly, the first device receives the first feedback result from the management network element. The first feedback result includes multiple first SCs and the address information of the second device corresponding to each of the multiple first SCs. The specific implementation of step S805 can be found in step S603 above and will not be repeated here.

[0375] Optionally, the management network element may further send second identity information to the second device. Accordingly, the second device receives the second identity information from the management network element. The second identity information may inform the second device that the first device intends to establish a BC connection with the second device. The second identity information may include identity information of the first device, such as the address of the first device, or the identity ID of the first device (such as the node ID in Table 1 above). It will be understood that the specific implementation of the management network element sending the second identity information to the second device can be referred to the aforementioned step S605 and will not be repeated here.

[0376] S806: The first device sends a connection request to the second device. Correspondingly, the second device receives the connection request from the first device. The connection request may include the first identity information, which may be the network access permission certificate in step S802.

[0377] It can be understood that the specific implementation of step S806 can refer to the aforementioned step S604-1 or step A, which will not be repeated here.

[0378] Optionally, the second device may verify the network access permission credential in the connection request based on the identity information of the first device.

[0379] Furthermore, optionally, when the second device determines, based on the second identity information, that the identity authentication of the first device is successful, the second device sends second feedback information to the first device. This second feedback information may be used to indicate consent to establish a BC connection with the first device. The second feedback information may include data regarding the BC protocol corresponding to the first BC. It should be understood that the specific implementation of the second device sending the second feedback information to the first device can be found in step S604-2 or step B above and will not be further described here.

[0380] It can be understood that, for the above BC protocol, the first device can obtain the above BC protocol through a registration network element or a management network element before sending a connection request to the second device.

[0381] It is also understood that if the second device determines, based on the second identity, that the first device's identity verification has failed, the second device sends second feedback information to the first device. This second feedback information may be used to indicate a refusal to establish a BC connection with the first device. Of course, the second device may also not send any feedback information to the first device to indicate a refusal to establish a BC connection with the first device. Alternatively, if the second device determines, based on the second identity information, that the first device's identity verification has succeeded, a BC handshake may be performed between the first and second devices, i.e., step S807.

[0382] S807: The first device and the second device perform a BC handshake according to the BC protocol corresponding to the first BC.

[0383] The specific implementation of step S807 can refer to the aforementioned step C and will not be repeated here.

[0384] S808: The first device sends one or more IDs of the first SC to the second device. Correspondingly, the second device receives the one or more IDs of the first SC from the first device.

[0385] The specific implementation of step S808 can be found in the aforementioned step D, which will not be repeated here.

[0386] S809. The first device sends the participating role of the first device in the first SC to the BC node in the first BC.

[0387] The specific implementation of step S809 can refer to the aforementioned step S606 and will not be repeated here.

[0388] S810: The first device and the second device synchronize BC data, wherein the BC data includes data of one or more first SCs.

[0389] The specific implementation of step S810 can refer to the aforementioned step E and will not be repeated here.

[0390] It can be understood that after steps S803 to S810, the first device completes joining the first BC and deploying the first SC. After the first device completes deploying the first SC, it can register information about the BC joined by the first device with the 3GPP network so that the management network element can obtain the latest status of the BC in the current 3GPP network, thereby facilitating the management network element to manage and control the BC in the 3GPP network and the newly added nodes to be added to the BC.

[0391] S811: The first device sends registration information to the registration network element. Correspondingly, the registration network element receives the registration information from the first device.

[0392] The specific implementation of step S811 can refer to the aforementioned step S607 and will not be repeated here.

[0393] Because in the embodiment of the present application, the management network element can improve the security of node access to BC in the decentralized 3GPP network by verifying the legitimacy of the first device joining BC. Furthermore, after the first device passes the legitimacy verification of joining BC, it can send the function corresponding to the SC it expects to deploy to the management network element, and then receive the address information of the second device from the management network element, so as to join the BC joined by the second device to deploy the first SC, that is, the BC joined by the first device and the deployed SC are managed and controlled by the management network element. Therefore, based on the communication method provided in the embodiment of the present application, the newly added nodes to be added to BC can be managed and controlled in the decentralized network to facilitate the optimization of network services. Among them, the action of the first device in the above steps S801 to S811 can be performed by the processor 501 in the communication device 500 shown in Figure 5 calling the application code stored in the memory 503 to instruct the communication device 500 to execute, the action of the management network element in the above steps S801 to S811 can be performed by the processor 501 in the communication device 500 shown in Figure 5 calling the application code stored in the memory 503 to instruct the communication device 500 to execute, and the action of the second device in the above steps S801 to S811 can be performed by the processor 501 in the communication device 500 shown in Figure 5 calling the application code stored in the memory 503 to instruct the communication device 500 to execute. The embodiment of the present application does not impose any restrictions on this.

[0394] It should be understood that the legitimacy of the first device joining the BC can be verified not only locally by the management network element but also by the device management node. For example, for a terminal device in a non-3GPP network infrastructure, the management network element may not have configured the terminal device with permission to join the BC. In this case, the legitimacy of the terminal device joining the BC can be verified by the device management node. The following example illustrates the communication method provided in the embodiments of the present application, taking the first device as a 3GPP terminal device and the second device as a CN device as an example.

[0395] FIG9 is a flow chart of another communication method provided in an embodiment of the present application. As shown in FIG9 , the method includes the following steps: S901 to S914 , wherein steps S906 to S912 may refer to the aforementioned steps S804 to S810 and are not described again here.

[0396] Steps S901 to S905 are described below.

[0397] S901: A first device sends a network access request to a device management node. Correspondingly, the device management node receives the network access request from the first device. The network access request may include the identity ID of the first device.

[0398] It should be understood that the device management node is a communication entity that verifies the legitimacy of the first device's joining the BC. The device management node performs authentication for the first device and configures the first device's access permissions to the BC. The device management node can be deployed on the CN side, the RAN side, or the cloud side. Furthermore, the device management node can be an independent node that does not perform wireless communication functions.

[0399] It should also be understood that in the embodiments of the present application, with the evolution of the 3GPP network, the subscriber identity module (SIM) of the terminal device, the network access permission code of the terminal device, or the international mobile equipment identity (IMEI) of the terminal device, etc., can be bound to the terminal device's permission to join the BC, and the management network element can also verify the legitimacy of the 3GPP terminal device joining the BC. For example, the management network element can verify the legitimacy of the 3GPP terminal device joining the BC through the SIM of the 3GPP terminal device.

[0400] S902: The device management node verifies the identity ID of the first apparatus.

[0401] It can be understood that the device management node can determine whether the first device is allowed to join the BC based on the permission configuration of the first device to join the BC and the identity ID of the first device.

[0402] S903: The device management node sends the network access request result to the first device. Correspondingly, the first device receives the network access request result from the device management node. The network access request result can be specifically described in the relevant description of the aforementioned step S802 and will not be repeated here.

[0403] Optionally, the device management node may send the verification result of the first device to the management network element. Accordingly, the management network element receives the verification result from the device management node. In other words, the management network element may obtain the legitimacy verification result of the first device joining the BC from the device management node.

[0404] S904: The first device sends a BC joining and SC deployment request to the management network element. Correspondingly, the management network element receives the BC joining and SC deployment request from the first device.

[0405] The difference between step S904 and the aforementioned step S803 is that the BC joining and SC deployment request further includes the first identity information in the aforementioned step S903, ie, the network access permission certificate.

[0406] S905: The management network element verifies the authenticity of the network access permission certificate of the first device.

[0407] In one possible implementation, the management network element can verify the authenticity of the network access permission certificate of the first device based on the verification result from the device management node. The verification result of the device management node can be specifically referred to the relevant description of step S903 above, which will not be repeated here.

[0408] In another possible implementation, the management network element may send a verification request to the device management node. Accordingly, the device management node receives the verification request from the management network element. The verification request is used to verify the authenticity of the network access permission certificate of the first device. The verification request includes the network access permission certificate.

[0409] Furthermore, the device management node sends the verification result to the management network element. Accordingly, the management network element receives the verification result from the device management node. The management network element can verify the authenticity of the network access permission certificate of the first device based on the verification result from the device management node. It can be understood that if the verification result indicates that the network access permission certificate of the first device is not authentic, the management network element can reject the BC joining and SC deployment request of the first device; if the verification result indicates that the network access permission certificate of the first device is authentic, the management network element can determine the address information of the second device and the first SC based on the BC joining and SC deployment request (i.e., step S906).

[0410] Step S913 and step S914 are described below.

[0411] S913. The first device configures a wireless interface. The wireless interface is used to provide access services. It is understood that if the device type of the first device is a 3GPP terminal device and the first device's role is to provide network access, the first device can provide BC access services by configuring a local wireless interface, such as a Wi-Fi hotspot.

[0412] It can be understood that step S913 is an optional step. When the participating role of the first device is not to provide network access, the first device may not configure a wireless interface.

[0413] S914: The first device sends registration information to the device management node. Accordingly, the device management node receives the registration information from the first device. In other words, the device management node can obtain information about 3GPP terminal devices and their corresponding BCs in the current 3GPP network, thereby facilitating the management network element to manage and control nodes of the newly added 3GPP terminal device type.

[0414] The specific description of the registration information can be found in step S607 and will not be repeated here.

[0415] Optionally, the device management node can send registration information to the registration network element. Accordingly, the registration network element receives the registration information from the device management node. In other words, by sending registration information from the device management node to the registration network element, the registration network element can obtain the latest status of the BC within the current 3GPP network, thereby facilitating the management network element's management and control of the BC within the 3GPP network and new nodes to be added to the BC.

[0416] Because in the embodiment of the present application, the management network element can determine the legitimacy of the first device joining the BC through the device management node, thereby improving the security of the node accessing the BC in the decentralized 3GPP network. Furthermore, after the first device passes the legitimacy verification of joining the BC, it can send the function corresponding to the SC it expects to deploy to the management network element, and then receive the address information of the second device from the management network element, so as to join the BC joined by the second device to deploy the first SC, that is, the BC joined by the first device and the deployed SC are managed and controlled by the management network element. Therefore, based on the communication method provided in the embodiment of the present application, the newly added nodes to be added to the BC can be managed and controlled in the decentralized network to facilitate the optimization of network services.

[0417] Among them, the action of the first device in the above steps S901 to S914 can be performed by the processor 501 in the communication device 500 shown in Figure 5 calling the application code stored in the memory 503 to instruct the communication device 500 to execute, the action of the management network element in the above steps S901 to S914 can be performed by the processor 501 in the communication device 500 shown in Figure 5 calling the application code stored in the memory 503 to instruct the communication device 500 to execute, and the action of the second device in the above steps S901 to S914 can be performed by the processor 501 in the communication device 500 shown in Figure 5 calling the application code stored in the memory 503 to instruct the communication device 500 to execute. The embodiment of the present application does not impose any restrictions on this.

[0418] It should be understood that for the first device whose device type is a non-3GPP terminal device, it joins the BC in the 3GPP network and can access the 3GPP network through the gateway node. Below, taking the first device as a non-3GPP terminal device and the second device as a non-3GPP terminal device as an example, the communication method provided in the embodiment of the present application is exemplified.

[0419] FIG10 is a flow chart of another communication method provided in an embodiment of the present application. As shown in FIG10 , the method includes the following steps: S1001 to S1014 , wherein step S1013 may refer to the aforementioned step S913 and will not be repeated here.

[0420] Furthermore, steps S1001 to S1005 and S1014 are similar to the aforementioned steps S901 to 905 and S914. The difference between the two is that the interaction between the first device and the device management node, as well as the interaction between the first device and the management network element, are all forwarded by the gateway node. The gateway node may be a 3GPP terminal device. It is understood that the first device and the gateway node can be networked through the PIN standard process, or the ProSe mode in the relevant description of Figure 1 above, which will not be repeated here. It is also understood that the PIN standard process can refer to the relevant description of the PIN standard, which will not be repeated here.

[0421] For example, for step S1001, the first device sends a network access request to the device management node, specifically: the first device sends a network access request to the gateway node; accordingly, the gateway node receives the network access request from the first device and forwards it to the device management node through the 3GPP access network.

[0422] It should be understood that in some cases, the second device may be the aforementioned gateway node. For example, when the first SC is deployed on a gateway node and the gateway node is relatively close to the first device, the gateway node may be the second device.

[0423] Furthermore, in the case where the second device is the above-mentioned gateway node, the specific implementation of steps S1006 to S1012 can refer to the aforementioned steps S906 to S912, which will not be repeated here.

[0424] It should also be understood that the second device may not be the aforementioned gateway node. In this case, steps S1006-S1012 are similar to steps S906-912, differing in that the interaction between the first and second devices is forwarded by the gateway node. For example, a connection request sent by the first device to the second device may be forwarded via the gateway node.

[0425] Similarly, in the network exit process shown in FIG6 , such as steps S608 to S612 , the interaction between the first device and the management network element can be completed by the gateway node. The figure shows steps S1006 to S1012 , which will not be described in detail.

[0426] Among them, the action of the first device in the above steps S1001 to S1014 can be performed by the processor 501 in the communication device 500 shown in Figure 5 calling the application code stored in the memory 503 to instruct the communication device 500 to execute, the action of the management network element in the above steps S1001 to S1014 can be performed by the processor 501 in the communication device 500 shown in Figure 5 calling the application code stored in the memory 503 to instruct the communication device 500 to execute, and the action of the second device in the above steps S1001 to S1014 can be performed by the processor 501 in the communication device 500 shown in Figure 5 calling the application code stored in the memory 503 to instruct the communication device 500 to execute, and the embodiment of the present application does not impose any restrictions on this.

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

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

[0429] For example, taking the communication device as the first device in the above method embodiment, FIG11 shows a schematic structural diagram of the first device 110. The first device 110 includes a transceiver module 1101 and a processing module 1102. The transceiver module 1101, which may also be referred to as a transceiver unit, is used to implement transceiver functions, and may be, for example, a transceiver circuit, a transceiver, a transceiver, or a communication interface.

[0430] Among them, the transceiver module 1101 is used to send a first request message to the management network element, and the first request message includes the function corresponding to the smart contract SC that the first device expects to deploy; the transceiver module 1101 is also used to receive first feedback information from the management network element, and the first feedback information includes the address information of the second device, and the SC deployed by the second device includes the first SC among the SCs expected to be deployed by the first device; the processing module 1102 is used to obtain the data of the first SC based on the address information of the second device.

[0431] Among them, the transceiver module 1101 can be used to implement the transceiver function corresponding to the first device in the above method embodiment, and the processing module 1102 can be used to implement the processing function corresponding to the first device in the above method embodiment. Furthermore, all relevant contents of each step involved in the above method embodiment can be referred to the functional description of the corresponding functional module, and will not be repeated here.

[0432] In the embodiment of the present application, the first device 110 is presented in the form of various functional modules divided in an integrated manner. Here, "module" can refer to a specific ASIC, circuit, processor and memory that executes one or more software or firmware programs, integrated logic circuit, and / or other devices that can provide the above functions. In a simple embodiment, those skilled in the art can imagine that the first device 110 can take the form of the communication device 500 shown in Figure 5.

[0433] For example, the processor 501 in the communication device 500 shown in FIG5 can call the computer-executable instructions stored in the memory 503 to enable the communication device 500 to execute the communication method in the above method embodiment.

[0434] Specifically, the functions / implementation processes of the transceiver module 1101 and the processing module 1102 in FIG11 can be implemented by the processor 501 in the communication device 500 shown in FIG5 calling computer-executable instructions stored in the memory 503. Alternatively, the functions / implementation processes of the processing module 1102 in FIG11 can be implemented by the processor 501 in the communication device 500 shown in FIG5 calling computer-executable instructions stored in the memory 503, and the functions / implementation processes of the transceiver module 1101 in FIG11 can be implemented by the communication interface 504 in the communication device 500 shown in FIG5.

[0435] Since the first device 110 provided in the embodiment of the present application can execute the above-mentioned communication method, the technical effects that can be obtained can refer to the above-mentioned method embodiment and will not be repeated here.

[0436] Alternatively, for example, taking the communication device as the management network element in the above method embodiment, FIG12 shows a schematic structural diagram of a management network element 120. The management network element 120 includes a transceiver module 1201 and a processing module 1202. The transceiver module 1201, also referred to as a transceiver unit, is used to implement transceiver functions and can be, for example, a transceiver circuit, a transceiver, a transceiver, or a communication interface.

[0437] Among them, the transceiver module 1201 is used to receive a first request information from the first device, and the first request information includes the function corresponding to the smart contract SC that the first device expects to deploy; the processing module 1202 is used to determine the address information of the second device based on the first request information, and the SC deployed by the second device includes the first SC in the SC expected to be deployed by the first device; the transceiver module 1201 is also used to manage the network element to send first feedback information to the first device, and the first feedback information includes the address information of the second device.

[0438] Among them, the transceiver module 1201 can be used to implement the transceiver function corresponding to the management network element in the above method embodiment, and the processing module 1202 can be used to implement the processing function corresponding to the management network element in the above method embodiment. Furthermore, all relevant contents of each step involved in the above method embodiment can be referred to the functional description of the corresponding functional module, and will not be repeated here.

[0439] In the embodiment of the present application, the management network element 120 is presented in the form of various functional modules divided in an integrated manner. "Module" here can refer to a specific ASIC, circuit, processor and memory that executes one or more software or firmware programs, integrated logic circuit, and / or other devices that can provide the above-mentioned functions. In a simple embodiment, those skilled in the art will appreciate that the management network element 120 can take the form of the communication device 500 shown in Figure 5.

[0440] For example, the processor 501 in the communication device 500 shown in FIG5 can call the computer-executable instructions stored in the memory 503 to enable the communication device 500 to execute the communication method in the above method embodiment.

[0441] Specifically, the functions / implementation processes of the transceiver module 1201 and the processing module 1202 in FIG12 can be implemented by the processor 501 in the communication device 500 shown in FIG5 calling computer-executable instructions stored in the memory 503. Alternatively, the functions / implementation processes of the processing module 1202 in FIG12 can be implemented by the processor 501 in the communication device 500 shown in FIG5 calling computer-executable instructions stored in the memory 503, and the functions / implementation processes of the transceiver module 1201 in FIG12 can be implemented by the communication interface 504 in the communication device 500 shown in FIG5.

[0442] Since the management network element 120 provided in this embodiment can execute the above communication method, the technical effects that can be obtained can refer to the above method embodiments and will not be repeated here.

[0443] Alternatively, for example, taking the communication device as the second device in the above method embodiment, FIG13 shows a schematic structural diagram of the second device 130. The second device 130 includes a transceiver module 1301 and a processing module 1302. The transceiver module 1301, also known as a transceiver unit, is used to implement transceiver functions and can be, for example, a transceiver circuit, a transceiver, a transceiver, or a communication interface.

[0444] Among them, the transceiver module 1301 is used to receive a second request information from the first device, and the second request information is used to request the deployment of the first SC in the smart contract SC that the first device expects to deploy, and the SC deployed by the second device includes the first SC; the transceiver module 1301 is also used to send second feedback information to the first device according to the second request information, and the second feedback information includes data of the BC protocol corresponding to the first BC; the processing module 1302 is used to synchronize BC data with the first device according to the BC protocol corresponding to the first BC, and the BC data includes data of the first SC.

[0445] Among them, the transceiver module 1301 can be used to implement the transceiver function corresponding to the second device in the above method embodiment, and the processing module 1302 can be used to implement the processing function corresponding to the second device in the above method embodiment. Furthermore, all relevant contents of each step involved in the above method embodiment can be referred to the functional description of the corresponding functional module, and will not be repeated here.

[0446] In the embodiment of the present application, the second device 130 is presented in the form of various functional modules divided in an integrated manner. The "module" here can refer to a specific ASIC, circuit, processor and memory that executes one or more software or firmware programs, integrated logic circuit, and / or other devices that can provide the above functions. In a simple embodiment, those skilled in the art will appreciate that the second device 130 can take the form of the communication device 500 shown in Figure 5.

[0447] For example, the processor 501 in the communication device 500 shown in FIG5 can call the computer-executable instructions stored in the memory 503 to enable the communication device 500 to execute the communication method in the above method embodiment.

[0448] Specifically, the functions / implementation processes of the transceiver module 1301 and the processing module 1302 in FIG13 can be implemented by the processor 501 in the communication device 500 shown in FIG5 calling computer-executable instructions stored in the memory 503. Alternatively, the functions / implementation processes of the processing module 1302 in FIG13 can be implemented by the processor 501 in the communication device 500 shown in FIG5 calling computer-executable instructions stored in the memory 503, and the functions / implementation processes of the transceiver module 1301 in FIG13 can be implemented by the communication interface 504 in the communication device 500 shown in FIG5.

[0449] Since the second device 130 provided in this embodiment can execute the above communication method, the technical effects that can be obtained can refer to the above method embodiments and will not be repeated here.

[0450] It should be understood that one or more of the above modules or units can be implemented by software, hardware, or a combination of the two. When any of the above modules or units is implemented in software, the software exists in the form of computer program instructions and is stored in a memory, and a processor can be used to execute the program instructions and implement the above method flow. The processor can be built into an SoC (system on chip) or an ASIC, or it can be an independent semiconductor chip. In addition to the core used to execute software instructions to perform calculations or processing within the processor, it can further include necessary hardware accelerators, such as field programmable gate arrays (FPGAs), PLDs (programmable logic devices), or logic circuits that implement dedicated logic operations.

[0451] When the above modules or units are implemented in hardware, the hardware can be any one or any combination of a CPU, a microprocessor, a digital signal processing (DSP) chip, a microcontroller unit (MCU), an artificial intelligence processor, an ASIC, a SoC, an FPGA, a PLD, a dedicated digital circuit, a hardware accelerator or a non-integrated discrete device, which can run the necessary software or not rely on the software to execute the above method flow.

[0452] Optionally, an embodiment of the present application further provides a communication device (for example, the communication device may be a chip or a chip system), which includes a processor for implementing the method in any of the above method embodiments. In one possible design, the communication device also includes a memory. The memory is used to store necessary program instructions and data, and the processor can call the program code stored in the memory to instruct the communication device to execute the method in any of the above method embodiments. Of course, the memory may not be in the communication device. When the communication device is a chip system, it may be composed of a chip, or it may include a chip and other discrete devices, which is not specifically limited in the embodiment of the present application.

[0453] In one possible implementation, an embodiment of the present application also provides a computer-readable storage medium, which stores a computer program or instruction. When the computer program or instruction is run on a communication device, the communication device can execute the method described in any of the above method embodiments or any of its implementations.

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

[0455] Further, optionally, the communication system also includes the second device described in the above method embodiment.

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

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

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

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

Claims

1. A communication method, characterized in that: The method comprises: The first device sends a first request message to the management network element, where the first request message includes a function corresponding to the smart contract SC that the first device expects to deploy; The management network element sends first feedback information to the first device according to the first request information, where the first feedback information includes address information of the second device, the SC deployed by the second device includes a first SC among the SCs expected to be deployed by the first device, and the first SC is deployed in a first BC; The first device obtains data of the first SC according to the address information of the second device.

2. The method according to claim 1, characterized in that The first device acquires data of the first SC according to the address information of the second device, including: the first device sends second request information to the second device according to the address information of the second device, where the second request information is used to request deployment of the first SC; The second device sends second feedback information to the first device according to the second request information, where the second feedback information includes data of a BC protocol corresponding to the first BC; The first device and the second device perform BC data synchronization via a BC protocol corresponding to the first BC, and the BC data includes data of the first SC.

3. The method according to claim 1 or 2, characterized in that: The first request information further includes at least one of the following: type information of the first device, operation information of the first device, or capability information of the first device.

4. The method according to claim 3, characterized in that The type information of the first device specifically includes: a device type of the first device, and / or a participating role type of the first device in the SC in which the first device is expected to be deployed; The operation information of the first device specifically includes: an estimated online duration of the first device, and / or an estimated online time period of the first device; The capability information of the first device specifically includes at least one of the following: a computing capability of the first device, a storage capability of the first device, or a network connection capability of the first device.

5. The method according to any one of claims 1 to 4, characterized in that The method further comprises: Determine the first SC from the candidate SC set according to the first request information and a matching condition corresponding to at least one SC in the candidate SC set; Determine address information of the second device according to the first SC.

6. The method according to claim 5, characterized in that The candidate SC set is obtained from a registration network element, and the registration network element is used to store the SC deployed by each BC in the multiple BCs managed by the management network element.

7. The method according to claim 5 or 6, characterized in that: The matching condition corresponding to at least one SC in the candidate SC set is pre-configured; or, the matching condition corresponding to at least one SC in the candidate SC set is obtained from a registration network element, and the registration network element is used to store the SC deployed by each of the multiple BCs managed by the management network element, and the matching condition corresponding to the SC deployed by each of the multiple BCs.

8. The method according to any one of claims 2 to 7, characterized in that: The method further comprises: The management network element sends second identity information to the second device, where the second identity information is information used by other devices to determine the identity of the first device, and the other devices are devices other than the first device; Correspondingly, the second device sends second feedback information to the first device according to the second request information, including: when it is determined according to the second identity information that the identity authentication of the first device is successful, the second device sends the second feedback information to the first device.

9. The method according to any one of claims 2 to 8, characterized in that: The first feedback information also includes first identity information, where the first identity information is information used to indicate the identity of the first device; the second request information also includes the first identity information.

10. The method according to any one of claims 1 to 9, characterized in that The method further comprises: The first device sends a participating role of the first device in the first SC to a BC node in the first BC, where the participating role includes at least one of the following: a verification role, a transaction role, a backup role, or a network access providing role.

11. The method according to any one of claims 1 to 10, characterized in that The method further comprises: The first device sends registration information to the registration network element or the management network element, and the registration information includes at least one of the following: information used to identify the BC joined by the first device, information used to indicate the SC deployed by the first device, or the participating role of the first device in the SC deployed by the first device.

12. The method according to any one of claims 1 to 11, characterized in that The method further comprises: The first device sends network exit information to the management network element, where the network exit information is used to indicate the BC that the first device expects to exit; The management network element deletes the registration information of the first device in the BC from which the first device expects to exit according to the network exit information.

13. The method according to claim 12, characterized in that The management network element deletes the registration information of the first device in the BC from which the first device expects to exit according to the network exit information, including: The management network element sends a deregistration request message to the registration network element, wherein the deregistration request message includes information indicating the BC that the first device wishes to exit; The management network element receives a deregistration request confirmation message from the registration network element, where the deregistration request confirmation message is used to confirm that the registration information of the first device in the BC from which the first device expects to exit has been deleted.

14. The method according to claim 12 or 13, characterized in that The method further comprises: The management network element sends network exit confirmation information to the first device, where the network exit confirmation information is used to confirm that the registration information of the first device in the BC that the first device expects to exit has been deleted; The first device receives the network exit confirmation information from the management network element.

15. The method according to any one of claims 12 to 14, characterized in that: The method further comprises: The management network element sends network exit instruction information to the second device according to the network exit information, where the network exit instruction information is used to instruct the first device to exit the BC that the first device expects to exit; The second device receives the network exit instruction information from the management network element.

16. The method according to claim 15, characterized in that The method further comprises: The second device broadcasts the network exit indication information to other BC nodes except the first device in the BC that the first device expects to exit according to the network exit indication information.

17. A communication method, characterized in that: The method comprises: The first device sends a first request message to the management network element, where the first request message includes a function corresponding to the smart contract SC that the first device expects to deploy; The first device receives first feedback information from the management network element, the first feedback information includes address information of the second device, the SC deployed by the second device includes a first SC among the SCs expected to be deployed by the first device, and the first SC is deployed in a first BC; The first device obtains data of the first SC according to the address information of the second device.

18. The method according to claim 17, characterized in that The first request information further includes at least one of the following: type information of the first device, operation information of the first device, or capability information of the first device.

19. The method according to claim 18, characterized in that The type information of the first device specifically includes: a device type of the first device, and / or a participating role type of the first device in the SC in which the first device is expected to be deployed; The operation information of the first device specifically includes: an estimated online duration of the first device, and / or an estimated online time period of the first device; The capability information of the first device specifically includes at least one of the following: a computing capability of the first device, a storage capability of the first device, or a network connection capability of the first device.

20. The method according to any one of claims 17 to 19, characterized in that The first device acquires data of the first SC according to the address information of the second device, including: The first device sends second request information to the second device according to the address information of the second device, where the second request information is used to request deployment of the first SC; The first device receives second feedback information from the second device, where the second feedback information includes data of a BC protocol corresponding to the first BC; The first device performs BC data synchronization with the second device according to a BC protocol corresponding to the first BC, and the BC data includes data of the first SC.

21. The method according to claim 20, characterized in that The first feedback information also includes first identity information, where the first identity information is information used to indicate the identity of the first device; the second request information also includes the first identity information.

22. The method according to any one of claims 17 to 21, characterized in that The method further comprises: The first device sends a participating role of the first device in the first SC to a BC node in the first BC, where the participating role includes at least one of the following: a verification role, a transaction role, a backup role, or a network access providing role.

23. The method according to any one of claims 17 to 22, characterized in that The method further comprises: The first device sends registration information to the registration network element or the management network element, and the registration information includes at least one of the following: information used to identify the BC joined by the first device, information used to indicate the SC deployed by the first device, or the participating role of the first device in the SC deployed by the first device.

24. The method according to any one of claims 17 to 23, characterized in that The method further comprises: The first device sends network exit information to the management network element, where the network exit information is used to indicate the BC that the first device expects to exit.

25. The method according to claim 24, characterized in that The method further comprises: The first device receives network exit confirmation information from the management network element, where the network exit confirmation information is used to confirm that registration information of the first device in the BC from which the first device expects to exit has been deleted.

26. A communication method, characterized in that: The method comprises: The management network element receives first request information from the first device, where the first request information includes a function corresponding to the smart contract SC that the first device expects to deploy; The management network element determines, according to the first request information, address information of a second device, wherein the SC deployed by the second device includes a first SC among the SCs expected to be deployed by the first device; The management network element sends first feedback information to the first device, where the first feedback information includes address information of the second device.

27. The method according to claim 26, characterized in that The first request information further includes at least one of the following: type information of the first device, operation information of the first device, or capability information of the first device.

28. The method according to claim 27, characterized in that The type information of the first device specifically includes: a device type of the first device, and / or a participating role type of the first device in the SC in which the first device is expected to be deployed; The operation information of the first device specifically includes: an estimated online duration of the first device, and / or an estimated online time period of the first device; The capability information of the first device specifically includes at least one of the following: a computing capability of the first device, a storage capability of the first device, or a network connection capability of the first device.

29. The method according to any one of claims 26 to 28, characterized in that The management network element determines the address information of the second device according to the first request information, including: The management network element determines the first SC from the candidate SC set according to the first request information and a matching condition corresponding to at least one SC in the candidate SC set; The management network element determines the address information of the second device according to the first SC.

30. The method according to claim 29, characterized in that The candidate SC set is obtained from a registration network element, and the registration network element is used to store the SC deployed by each BC in the multiple blockchain BCs managed by the management network element.

31. The method according to claim 29 or 30, characterized in that The matching condition corresponding to at least one SC in the candidate SC set is pre-configured; or, the matching condition corresponding to at least one SC in the candidate SC set is obtained from a registration network element, and the registration network element is used to store the SC deployed by each of the multiple BCs managed by the management network element, and the matching condition corresponding to the SC deployed by each of the multiple BCs.

32. The method according to any one of claims 26 to 31, characterized in that The method further comprises: The management network element sends second identity information to the second device, where the second identity information is information used by other devices to determine the identity of the first device, and the other devices are devices other than the first device.

33. The method according to any one of claims 26 to 32, characterized in that The first feedback information further includes first identity information, where the first identity information is information used to indicate the identity of the first device.

34. The method according to any one of claims 26 to 33, characterized in that The method further comprises: The management network element receives network exit information from the first device, where the network exit information is used to indicate a BC that the first device expects to exit; The management network element deletes the registration information of the first device in the BC from which the first device expects to exit according to the network exit information.

35. The method according to claim 34, characterized in that The management network element deletes the registration information of the first device in the BC from which the first device expects to exit according to the network exit information, including: The management network element sends a deregistration request message to the registration network element, wherein the deregistration request message includes information indicating the BC that the first device wishes to exit; The management network element receives a deregistration request confirmation message from the registration network element, where the deregistration request confirmation message is used to confirm that the registration information of the first device in the BC from which the first device expects to exit has been deleted.

36. The method according to claim 34 or 35, characterized in that The method further comprises: The management network element sends network exit indication information to the second device according to the network exit information, where the network exit indication information is used to instruct the first device to exit the BC that the first device expects to exit.

37. The method according to any one of claims 34 to 36, characterized in that The method further comprises: The management network element sends network exit confirmation information to the first device, where the network exit confirmation information is used to confirm that registration information of the first device in the BC that the first device expects to exit has been deleted.

38. A communication method, characterized in that: The method comprises: The second device receives second request information from the first device, where the second request information is used to request deployment of a first SC in the smart contract SC that the first device expects to deploy, where the SC deployed by the second device includes the first SC, and the first SC is deployed in the first blockchain BC; The second device sends second feedback information to the first device according to the second request information, where the second feedback information includes data of a BC protocol corresponding to the first BC; The second device performs BC data synchronization with the first device according to a BC protocol corresponding to the first BC, and the BC data includes data of the first SC.

39. The method according to claim 38, characterized in that The method further comprises: The second device receives second identity information from the management network element, where the second identity information is information used by other devices to determine the identity of the first device, the other devices are devices other than the first device, and the BCs managed by the management network element include the BCs joined by the second device; Correspondingly, the second device sends second feedback information to the first device according to the second request information, including: When the second device determines, based on the second identity information, that the identity authentication of the first device is successful, the second device sends the second feedback information to the first device.

40. The method according to claim 38 or 39, characterized in that The second request information further includes first identity information, where the first identity information is information used to indicate the identity of the first device.

41. The method according to any one of claims 38 to 40, characterized in that The method further comprises: The second device obtains network exit indication information, where the network exit indication information is used to instruct the first device to exit the BC that the first device expects to exit.

42. The method according to claim 41, characterized in that The network exit indication information is obtained from a management network element, and the BC managed by the management network element includes the BC joined by the second device; the method further includes: The second device broadcasts the network exit indication information to other BC nodes except the first device in the BC that the first device expects to exit according to the network exit indication information.

43. A communication device, characterized in that: The communication device comprises a module or a unit for executing the method according to any one of claims 17-25.

44. A communication device, characterized in that: The communication device comprises a module or a unit for executing the method of any one of claims 26-37.

45. [Corrected 10.10.2023 in accordance with Rule 91] A communication device, characterized in that The communication device comprises a module or a unit for executing the method of any one of claims 38-42.

46. ​​A communication device, characterized in that: The communication device includes a processor, which is used to enable the communication device to execute the communication method according to any one of claims 17-25, or enable the communication device to execute the communication method according to any one of claims 26-37, or enable the communication device to execute the communication method according to any one of claims 38-42 through logic circuits and / or execution instructions.

47. The device according to claim 46, characterized in that Also included is a memory for storing the instructions.

48. The device according to claim 46 or 47, characterized in that Also included is a communication interface, which is used to input and / or output signaling and / or data.

49. A computer-readable storage medium, characterized in that The computer-readable storage medium comprises instructions, which, when executed by a processor, enable the communication method according to any one of claims 17 to 25, or the communication method according to any one of claims 26 to 37, or the communication method according to any one of claims 38 to 42 to be implemented.

50. A computer program product, characterized in that The computer program product comprises instructions, which, when executed on a computer, cause the computer to execute the communication method according to any one of claims 17 to 25, or cause the computer to execute the communication method according to any one of claims 26 to 37, or cause the computer to execute the communication method according to any one of claims 38 to 42.

Images