A data sharing system, a data sharing method thereof, and a storage medium

Abstract

The application discloses a data sharing system and a data sharing method thereof and a storage medium, and relates to the technical field of data sharing, which comprises the following steps: a data node acquires and stores slice MOS data, and sends the slice MOS data and an authorized write strategy to a consortium node; the consortium node determines an authorized read strategy, uploads the slice MOS data, the authorized write strategy and the authorized read strategy to a block chain; participates in block chain consensus and verification, stores a ledger recording the slice MOS data, stores a ledger recording the authorized write strategy and the authorized read strategy, and deploys an intelligent contract for executing the authorized write strategy and the authorized read strategy; according to a data viewing request, the slice MOS data, the authorized write strategy and the authorized read strategy in the block chain are viewed; and a data request node sends the data viewing request. By using the application, the synchronization of shared data among all related parties, i.e. vertical industries / third parties, telecommunication manufacturers, operators and the like, can be realized, and illegal uploading and illegal reading can be avoided.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of communication technology, in particular to a data sharing system and a data sharing method thereof, and a storage medium. BACKGROUND

[0002] 5G introduces NS (Network Slicing), which provides customized and dedicated network services for different industries based on shared physical infrastructure. This changes the 4G single network mode and creates a 5G network that supports function customization, security and resource isolation, and topology optimization, thereby meeting the needs of specific goals, specific service categories, and even specific customers. Network slicing services provide high-quality slicing services for 5G users, especially vertical industry 5G users, based on service terms agreed upon by a series of slice service providers (such as operators) and slice customers (such as content providers using slice to carry streaming media). SLA (Service Level Agreement) agreements are service terms agreed upon for the type of service provided, including slice orchestration, service area / time, and service level guarantees, which have a profound impact on the business model and pricing method of network slicing.

[0003] Slice SLA is usually monitored and evaluated by the slice manager based on the KPI (Key Performance Indicator) of the network slice, such as virtualized resource utilization, network and network slice instance registered user number, 5G network end-to-end latency, network and network slice instance uplink / downlink throughput, etc. This means that the slice manager itself can evaluate whether the slice service meets the agreed SLA requirements. In addition to end-to-end SLA guarantees, the 5G network control plane also needs to develop corresponding functions for more dynamic and finer-grained slice QoE (Quality of Experience) level monitoring and management. Industry suggests that it can be approached from the perspective of the end user (i.e. ASP (Application Service Provider)) who is most directly affected by the slice service.

[0004] Generally, ASP relies on a large number of QoE requirements to measure the perceived service quality, including but not limited to: the network service area of the ASP, MOS (Mean Opinion Score), the percentage of user traffic MOS satisfaction, such as 90% of users meeting or exceeding the specified traffic MOS requirements. In order to obtain the average traffic MOS and the percentage of users meeting the traffic MOS, the ASP needs to consider the relationship between the single user traffic MOS value and the main network attributes (such as upload / download capacity, jitter, maximum allowed latency, network availability, and dedicated service features, etc.) and design the corresponding MOS service model.

[0005] Generally, traffic MOS is dominated by one or more network attributes that have the greatest impact on user experience, so there are significant differences in traffic MOS structures for different industry applications. For example, from the perspective of game developers / publishers, there are obvious differences in the design of traffic MOS for different types of game slices, such as cloud gaming experience related to bandwidth, multi-player games more sensitive to latency, and e-sports focusing more on the consistency of user experience. ASP is most concerned about the experience and QoE of slice services, and also has a deep understanding of its own business logic, so different slice tenants have different requirements for the same communication service, which is also the reference baseline for slice SLA requirements. Slice QoE requirements and slice QoE statistics (e.g., average traffic MOS) are key factors to be considered in the definition and management of slice SLA.

[0006] Currently, the industry is promoting a MOS model training framework to support slice SLA protection, and SMM (Service MOS Model) can be trained by NWDAF (Network Data Analytics Function) for a specific service of the ASP.

[0007] Firstly, as the main data collection point of the 5G system, the NWDAF receives and stores the service MOS data from the ASP or slice tenant, and the network data provided by the slice manager and the core network corresponding to the service. The OAM (Operation, Administration and Maintenance) data provided by the slice manager includes UE (User Equipment) level MDT (Minimization of Drive Test) data, NF (Network Function) performance measurement data and network level KPI data. The data input from the 5G core network can be non-OAM data at the QoS (Quality of Service) flow level, UE level or even service level. The introduction of slice tenant service MOS value can assist the operator to intuitively and effectively monitor the quality of slice operation, so it plays a crucial role in the process of slice management / control.

[0008] Ideally, the service MOS perceived by the vertical industry / third party needs to be highly consistent with the QoE fitting analysis result of the operator, indicating that a good balance between slice service performance and operation and maintenance cost is achieved, so as to realize the win-win between the slice service provider and the user. With a large amount of service MOS and network data, the NWDAF can train and model the SMM (service MOS model) of the given service by using advanced AI (Artificial Intelligence) / ML (Machine Learning) algorithms.

[0009] The SMM is used to represent the relationship between the user service experience MOS value and the OAM and QoS flow data in the slice network, so that the operator can fit the user's service experience based on network management and control data, visualize the monitoring of slice operation quality, and assist slice configuration update and control management.

[0010] Due to the great difference in the operation and business mode of the industry and slice user, the SMM of different industry applications may be completely different. Therefore, the SMM of each slice tenant needs to be trained and verified specifically to capture the key network features that affect the quality of slice service.

[0011] In a dynamic business environment, the SMM itself may change over time, or there may be differences in different slice service areas. Therefore, it needs to be trained and reinforced by the user experience data and network management / control parameters provided by the user and the network to ensure the generalization ability and long-term applicability of the model.

[0012] Currently, the industry is promoting the identification of key SLA guarantee scenarios and corresponding stakeholders (such as vertical industries / third parties, telecom carriers, operators, etc.), and establishing close industry partnership among stakeholders to jointly develop data analysis methods and business MOS models.

[0013] The prior art has the following disadvantages: the existing slice management scheme only supports an operator to obtain experience data of a third party currently providing a network slice service by an NWDAF interface, the amount of information that the operator can obtain is very small, which is not conducive to model training and is not conducive to the maturity and development of the slice. SUMMARY

[0014] The application provides a data sharing system and a data sharing method thereof and a storage medium, to solve the problem that the amount of information that an operator can obtain is very small, which is not conducive to model training and is not conducive to the maturity and development of the slice.

[0015] The application provides the following technical solutions:

[0016] A data sharing system comprises a data node, an alliance node, a data request node, and a blockchain composed of the alliance node, wherein:

[0017] The data node is configured to acquire and store slice MOS data and an authorized write strategy of the slice MOS data, generate slice MOS metadata from the slice MOS data, and send the slice MOS metadata and the authorized write strategy of the slice MOS data to the alliance node, wherein the slice MOS metadata comprises a hash value of the slice MOS data and / or a storage address of the slice MOS data.

[0018] The alliance node is configured to perform one or a combination of the following processes:

[0019] determine an authorized read strategy of the slice MOS data, and upload the slice MOS metadata and the authorized write strategy and the authorized read strategy of the slice MOS data to the blockchain;

[0020] participate in consensus and verification of the blockchain, and determine whether to allow writing of a new record according to the authorized write strategy in a record with an associated relationship on the blockchain during the consensus;

[0021] store a ledger of the record slice MOS metadata;

[0022] store a ledger of the record authorized write strategy and the authorized read strategy;

[0023] deploy an intelligent contract for executing the authorized write strategy and the authorized read strategy;

[0024] view the slice MOS metadata and the authorized write strategy and the authorized read strategy in the blockchain according to a data viewing request.

[0025] The data request node is configured to send a data viewing request.

[0026] In an implementation, the data node is further configured to, after receiving the slice MOS data sharing request of the data request node, request the blockchain to determine whether to agree to read the slice MOS data according to a slice MOS data authorization reading strategy on the blockchain.

[0027] In an implementation, the data node includes an operator data node and an application service provider data node; the alliance node includes an operator alliance node and an application service provider alliance node, and the slice MOS data includes slice network data and / or service MOS data, wherein:

[0028] The operator data node is configured to provide, to the operator alliance node, slice network metadata corresponding to slice network data of one slice in one time period and / or slice network metadata collected by the NWDAF from the network during internal training and / or service MOS metadata corresponding to service MOS data.

[0029] The application service provider data node is configured to provide, to the application service provider alliance node, service MOS metadata corresponding to service MOS data of one slice in one time period.

[0030] In the same slice and the same time period, the slice network data and the service MOS data have an association relationship.

[0031] In an implementation, the operator data node is further configured to provide the slice network data including one or a combination of the following data:

[0032] The OAM data provided by the slice manager includes one or a combination of the following information: UE-level minimization of drive test data, network function performance measurement data, and network-level KPI data.

[0033] The data input from the 5G core network includes one or a combination of the following information: non-OAM data at the QoS flow level, UE level, and service level.

[0034] In an implementation, the application service provider data node is further configured to provide service MOS metadata corresponding to one or a combination of the following data:

[0035] A hash value of the service MOS data is provided.

[0036] A storage address of the service MOS data is provided.

[0037] In implementation, the operator data node is further configured to, when sending the authorized write policy to the federation node, add a public key of a relevant slice tenant to the data identifier to identify a slice tenant allowed to upload the business MOS data of the data identifier.

[0038] In implementation, the operator data node is further configured to use a hash value of the slice ID and a hash value of the timestamp as the data identifier, where the slice ID is an NSSAI or an SLA contract identifier.

[0039] In implementation, the federation node comprises an operator federation node and an application service provider federation node, wherein:

[0040] The operator federation node is configured to perform one or a combination of the following processes:

[0041] uploading slice network metadata and / or business MOS metadata to a blockchain;

[0042] determining an authorized read policy of slice network data and / or business MOS data, and uploading the slice network data and / or business MOS data and the authorized write policy and the authorized read policy of the slice network data and / or business MOS data to the blockchain;

[0043] participating in blockchain consensus and verification, and determining whether to allow writing a new record according to the authorized write policy in a record with an association relationship on the blockchain during consensus;

[0044] storing a ledger of slice network data in slice MOS metadata records;

[0045] storing a ledger of authorized write policies and authorized read policies;

[0046] deploying a smart contract for executing the authorized write policy and the authorized read policy;

[0047] viewing slice network data corresponding to slice MOS metadata and the authorized write policy and the authorized read policy in the blockchain according to a data viewing request;

[0048] The application service provider federation node is configured to perform one or a combination of the following processes:

[0049] uploading slice MOS metadata to a blockchain;

[0050] determining an authorized read policy of business MOS data corresponding to the slice MOS metadata, and uploading the business MOS data corresponding to the slice MOS metadata and the authorized write policy and the authorized read policy of the business MOS data corresponding to the slice MOS metadata to the blockchain;

[0051] Participate in blockchain consensus and verification, and determine whether to allow writing of a new record according to an authorized write strategy in a record associated with the blockchain during consensus;

[0052] A ledger for storing service MOS data in record slice MOS metadata;

[0053] A ledger for storing authorized write strategies and authorized read strategies;

[0054] Deploying a smart contract for executing authorized write strategies and authorized read strategies;

[0055] According to a data viewing request, viewing service MOS data corresponding to slice MOS metadata and authorized write strategies and authorized read strategies in the blockchain.

[0056] In implementation, the alliance node is further configured to sign and distribute the slice MOS metadata, the authorized read strategy of the data corresponding to the slice MOS metadata, and the authorized write strategy of the data corresponding to the slice MOS metadata to the blockchain network node as a record; or,

[0057] The alliance node signs and distributes the slice MOS metadata to the blockchain network node as a record, and signs and broadcasts the authorized read strategy of the data corresponding to the slice MOS metadata and the authorized write strategy of the data corresponding to the slice MOS metadata to other blockchain nodes as a transaction; or,

[0058] The slice MOS metadata is signed and distributed to the blockchain network node as a record, and the authorized read strategy of the data corresponding to the slice MOS metadata and the authorized write strategy of the data corresponding to the slice MOS metadata are signed and broadcast to other blockchain nodes as a transaction.

[0059] A data sharing method based on the system, comprising:

[0060] The data node acquires and stores slice MOS data and authorized write strategies of the slice MOS data, generates slice MOS metadata from the slice MOS data, and sends the slice MOS metadata and the authorized write strategies of the slice MOS data to the alliance node, wherein the slice MOS metadata includes a hash value of the slice MOS data and / or a storage address of the slice MOS data;

[0061] The alliance node performs one or a combination of the following processes:

[0062] Determining the authorized read strategy of the slice MOS data, and uploading the slice MOS metadata and the authorized write strategies and authorized read strategies of the slice MOS data to the blockchain;

[0063] Participate in blockchain consensus and verification, and determine whether to allow writing of a new record according to an authorized write strategy in a record associated with the blockchain during consensus;

[0064] A ledger for storing record slice MOS metadata;

[0065] A ledger for storing record authorized write strategies and authorized read strategies;

[0066] Deploying a smart contract for executing authorized write strategies and authorized read strategies;

[0067] Viewing slice MOS metadata and authorized write strategies and authorized read strategies in the blockchain according to a data viewing request;

[0068] The data request node sends a data viewing request.

[0069] In implementation, when uploading slice MOS metadata and authorized write strategies and authorized read strategies of the slice MOS data to the blockchain, the following steps are included:

[0070] The alliance node signs and distributes slice MOS metadata, authorized read strategies of data corresponding to the slice MOS metadata, and authorized write strategies of data corresponding to the slice MOS metadata to blockchain network nodes as a record; or,

[0071] The alliance node signs and distributes slice MOS metadata to blockchain network nodes as a record, signs and broadcasts authorized read strategies of data corresponding to the slice MOS metadata and authorized write strategies of data corresponding to the slice MOS metadata to other blockchain nodes as a transaction; or,

[0072] The alliance node signs and distributes slice MOS metadata to blockchain network nodes as a record, signs and broadcasts authorized read strategies of data corresponding to the slice MOS metadata and authorized write strategies of data corresponding to the slice MOS metadata to other blockchain network nodes as a transaction; or,

[0073] In implementation, the alliance node signs and distributes slice MOS metadata, authorized read strategies of data corresponding to the slice MOS metadata, and authorized write strategies of data corresponding to the slice MOS metadata to blockchain network nodes as a record, and the distribution to blockchain network nodes includes one or a combination of the following information:

[0074] Slice MOS data hash value, slice MOS data storage address, data identifier, public key of an application service provider authorized to write associated data, and public key of an alliance member authorized to read the slice MOS metadata; or,

[0075] a hash value of the slice network data, a storage address of the slice network data, a data identifier, a public key of an application service provider authorized to write the associated data, and a public key of a consortium member authorized to read the slice network data; or

[0076] a hash value of the service MOS data, a storage address of the service MOS data, a data identifier, a public key of an operator authorized to write the associated data, and a public key of a consortium member authorized to read the service MOS data.

[0077] In an implementation, the method further includes:

[0078] The node on the blockchain checks the format and signature of the received data, checks whether there is a record with the data identifier on the blockchain, and if not, adds the data as a record.

[0079] If there is a record, the node checks whether the signature corresponds to the public key authorized to write, and if so, adds the data as a record, and if not, discards the data as false data.

[0080] The node on the blockchain uses a consensus mechanism in the blockchain to encapsulate the records obtained within a period of time into a new block and broadcast the block.

[0081] In an implementation, the consortium node signs the slice MOS metadata as a record and distributes it to the blockchain network nodes, and signs the slice MOS metadata as a record and distributes it to the blockchain network nodes, including one or a combination of the following information:

[0082] a hash value of the slice MOS metadata, a storage address of the slice MOS metadata, and a data identifier;

[0083] a hash value of the slice network data, a storage address of the slice network data, and a data identifier;

[0084] a hash value of the service MOS data, a storage address of the service MOS data, and a data identifier;

[0085] The authorization read policy of the data corresponding to the slice MOS metadata and the authorization write policy of the data corresponding to the slice MOS metadata are signed as a transaction and broadcast to other blockchain nodes, and the authorization read policy and the authorization write policy are signed as a transaction and broadcast to other blockchain nodes, including one or a combination of the following information:

[0086] The authorization read policy and the authorization write policy are signed as a transaction and broadcast to other blockchain nodes, and the authorization read policy and the authorization write policy transaction includes a hash value of the slice ID, a public key of an application service provider of the slice, a public key of an operator of the slice, and a public key of a consortium member authorized to read the data corresponding to the slice MOS metadata of the slice.

[0087] In an implementation, the method further includes:

[0088] The node on the blockchain checks the format and signature of the received data;

[0089] For metadata transactions, check whether there is a record containing the metadata identifier on the chain. If not, it is treated as a record. If there is, judge whether the signature corresponds to the public key authorized to write. If so, it is treated as a record. If not, it is treated as false data and discarded;

[0090] For authorized read strategy and authorized write strategy transactions, judge whether the transaction signature corresponds to the public key of the application service provider and / or operator in the transaction. Judge whether the public key corresponds to the signature of the record in which the slice identifier first appears in the blockchain. If not, it is considered as a false authorized strategy and the transaction is discarded. If it is satisfied, it is treated as a record;

[0091] The node on the blockchain uses the consensus mechanism in the blockchain to encapsulate the records obtained within a period of time into a new block and broadcast and publish the block.

[0092] In implementation, after the data request node issues a data viewing request, it further includes:

[0093] The data request node accesses the alliance node to apply to view the slice MOS metadata stored on the blockchain, including: applying to read the slice MOS metadata hash value; or, finding the hash value of the slice network data or the hash value of the business MOS data through the data identifier; or, calling the smart contract to read the slice MOS metadata;

[0094] The data request party applies to the data node for the slice MOS data corresponding to the data identifier according to the read data address;

[0095] The data node reads the authorized read strategy for the slice MOS metadata from the blockchain through the alliance node to determine whether to send the slice MOS metadata to the data request party;

[0096] The data request party verifies whether the obtained original data is correct according to the data hash in the read record.

[0097] In implementation, when the authorized read strategy of the slice MOS metadata and the authorized write strategy and verification of the slice MOS metadata are written into the smart contract and deployed to the blockchain,

[0098] The authorized write strategy logic is: for the slice identified by the slice ID hash value, the identity of the operator and the application service provider allowed to write the metadata of the slice to the chain is agreed. Judge whether the signature carried in the metadata write request of the slice matches the public key. If so, allow writing. If not, do not allow writing;

[0099] The authorized reading strategy logic is: for the slice identified by the slice ID hash value, the public key of the identity of the alliance member allowed to read the off-chain original data thereof, and the reading constraint condition are agreed; it is judged whether the signature of the original data reading request is the data provider, if so, the identity of the member allowed to read is returned, if the signature matches the public key authorized to read, the identity of the member allowed to read is returned.

[0100] In implementation, the data node sends the slice MOS metadata to the alliance node, including:

[0101] The data node collects and stores the slice MOS data for model training;

[0102] The slice MOS metadata is generated after processing the slice MOS data, and the slice MOS metadata includes: a hash value and / or a storage address of the original slice MOS data;

[0103] The metadata is sent to the alliance node.

[0104] In implementation, when the alliance node deploys the authorized reading strategy of the data corresponding to the slice MOS metadata and the authorized writing strategy of the data corresponding to the slice MOS metadata to the smart contract on the blockchain:

[0105] The alliance node calls the smart contract with the received slice MOS metadata and data identifier as parameters;

[0106] The smart contract executes the writing of the slice MOS metadata transaction, and the slice MOS metadata transaction written in the chain has one or a combination of the following data:

[0107] The hash value of the slice MOS data, the storage address of the slice MOS data, and the data identifier; or,

[0108] The hash value of the slice network data, the storage address of the slice network data, and the data identifier; or,

[0109] The hash value of the business MOS data, the storage address of the business MOS data, and the data identifier.

[0110] In implementation, after the data request node issues a data viewing request, further including:

[0111] The data request node accesses the alliance node to apply to view the slice MOS metadata stored on the blockchain, including: applying to read the hash value of the data corresponding to the slice MOS metadata; or, finding the hash value of the slice network data or the hash value of the business MOS data through the data identifier; or, calling the smart contract to read the slice MOS metadata;

[0112] The data requester applies for slice MOS metadata corresponding to the slice MOS data identifier according to the read data address, or carries a read permission flag in the application;

[0113] If the read permission flag verification is successful, the data node sends the original data to the requester; if the verification is unsuccessful, the data node reads the read permission membership for the original data from the blockchain through the alliance node calling the smart contract, and judges whether to send the original data to the requester;

[0114] The data requester verifies whether the obtained original data is correct according to the data hash in the record.

[0115] A computer readable storage medium stores a computer program for executing the above data sharing method.

[0116] The present application has the following advantages:

[0117] In the technical scheme provided by the embodiments of the present application, the slice MOS data authorization sharing is realized based on the blockchain, so that the decentralized slice MOS data authorization sharing can be provided, the privacy protection can be enhanced, the integrity verification can be supported, and the authorized access can be supported.

[0118] According to the nature of the data, the corresponding authorized write strategy and / or authorized read strategy are matched, so that the distributed data consistency can be ensured, and the sharing data of the alliance members, the vertical industry / third party, the telecom manufacturer and the operators can be synchronized.

[0119] Further, the authorized read strategy and the authorized write strategy are broadcasted to other blockchain nodes after being signed as a transaction, the authorized read strategy and the authorized write strategy transaction are the hash value of the slice ID, the public key of the application service provider of the slice, the public key of the operator of the slice, the public key of the alliance member authorized to read the slice MOS data of the slice, the related party authorized to write the slice and the object authorized to read the slice are relatively stable, the related party authorized to write the slice at different time stamps is the same, and compared with being included in each time stamp record, being recorded alone can save storage space, so that the storage space occupation on the chain can be reduced.

[0120] Further, since the slice MOS data and the authorized write strategy and the authorized read strategy of the slice MOS data are uploaded to the blockchain at the same time, and the data and the strategy are formulated by the authorized party, the authorized strategy is ensured to be public and correctly executed; the slice MOS data on the chain is ensured to come from the correct data provider, and illegal uploading and illegal reading are avoided. BRIEF DESCRIPTION OF DRAWINGS

[0121] The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiments of the application and together with the description serve to explain the application. In the drawings:

[0122] Figure 1 A schematic diagram of a data sharing system structure in an embodiment of the application;

[0123] Figure 2 A schematic diagram of a data sharing system structure in an embodiment of the application;

[0124] Figure 3 A schematic diagram of a data sharing method based on a data sharing system in an embodiment of the application;

[0125] Figure 4 A schematic diagram of a MOS data authorized viewing in a mode one slice in an embodiment of the application;

[0126] Figure 5 A schematic diagram of a MOS data authorized viewing in a mode two slice in an embodiment of the application. DETAILED DESCRIPTION

[0127] The inventor noticed during the invention process that:

[0128] Since the slice service has not yet been fully landed and commercialized, the amount of information that the operator can obtain is very small, which is not conducive to model training and is not conducive to the maturity and development of the slice. More extensive sharing of business experience MOS data between various stakeholders and OAM and QoS flow data in the slice network will help operators better guarantee the quality of service expected by each slice user while deploying a large number of slice services on the shared 5G infrastructure, but the data shared by multiple parties is managed by which platform is a problem. The characteristics of block chain in establishing multi-party trust, maintaining consistency and decentralization make it very suitable for solving this problem.

[0129] The embodiments of the application provide a scheme for sharing MOS data authorized by slices based on block chain, and use distributed ledgers and smart contracts to ensure trusted storage and trusted execution of authentication and authorization, thereby ensuring the privacy sharing of data.

[0130] Specifically, in the scheme, the original data and the authorization policy are stored and processed separately, the "authorized write" policy controls the data from the correct data provider, and the "authorized read" policy informs the data requestor that the original data can be accessed. The metadata (storage address, hash, etc.) is stored on the blockchain to ensure the trusted storage of the slice MOS metadata, and the authorized read and write policies can be stored using a distributed ledger or a smart contract to ensure the trusted execution of the authorization. The authorization write policy controlled by the association relationship ensures that the correct provider writes data to the chain; the requestor and the provider access the blockchain in turn to obtain the storage address and authorization status of the original data, and the addressing-authorization-verification ensures the privacy sharing of the data.

[0131] The specific embodiments of the application will be described below with reference to the accompanying drawings.

[0132] Figure 1 A schematic diagram of the data sharing system structure is shown in the figure, which can include: a data node, an alliance node, a data request node, and a blockchain composed of alliance nodes, wherein:

[0133] The data node is configured to obtain and store slice MOS data and an authorized write policy of the slice MOS data, generate slice MOS metadata from the slice MOS data, and send the slice MOS metadata and the authorized write policy of the slice MOS data to the alliance node, wherein the slice MOS metadata includes a hash value of the slice MOS data and / or a storage address of the slice MOS data.

[0134] The alliance node is configured to perform one or a combination of the following processes:

[0135] determine an authorized read policy of the slice MOS data, and upload the slice MOS metadata, the authorized write policy and the authorized read policy of the slice MOS data to the blockchain;

[0136] participate in the consensus and verification of the blockchain, and determine whether to allow writing a new record according to the authorized write policy in the record with an association relationship on the blockchain during the consensus;

[0137] store a ledger of the record slice MOS metadata;

[0138] store a ledger of the authorized write policy and the authorized read policy;

[0139] deploy a smart contract for executing the authorized write policy and the authorized read policy;

[0140] view the slice MOS metadata and the authorized write policy and the authorized read policy in the blockchain according to a data viewing request;

[0141] The data request node is configured to issue a data viewing request.

[0142] The following is a brief description of the order of the embodiments.

[0143] In the following examples, each functional entity will be described first, and then the alliance nodes will be divided into operator alliance nodes and application service provider alliance nodes, and the data nodes will be divided into operator data nodes and application service provider data nodes for description. Correspondingly, the operator data nodes process slice network data in slice MOS data, and the application service provider data nodes process service MOS data in slice MOS data.

[0144] The system can also include a query system.

[0145] For the sake of understanding and simplicity, the user using the data request node will also be referred to as a data requestor, and the slice MOS data will be referred to as metadata when it is specifically expressed as initial data.

[0146] After introducing the system, the data sharing method based on the system will be described. There are three ways to share data: way one, the authorization policy and the metadata are written as a record in the ledger, way two, the authorization policy and the metadata are written as records, and way three, the authorization policy is written in a smart contract. The content of the description mainly includes: slice MOS data writing; slice MOS data authorization viewing.

[0147] The following will begin to explain.

[0148] In the implementation, the alliance nodes include: operator alliance nodes and application service provider alliance nodes.

[0149] The data request node is located on the operator alliance node and / or the application service provider alliance node.

[0150] That is, the operator alliance node or the application service provider alliance node can also serve as a data request node for data requestors to use.

[0151] In the implementation, it can further include:

[0152] The query system is used for relevant parties to access one or a combination of the following information: network data, network data corresponding slice MOS data, and information based on slice MOS data.

[0153] In the specific implementation, the alliance nodes include: operator alliance nodes and application service provider alliance nodes.

[0154] The query system is located on the operator alliance node and / or the application service provider alliance node.

[0155] That is, the operator alliance node or the application service provider alliance node can also serve as a query system for data queryors to use.

[0156] In an implementation, the data nodes include: operator data nodes and application service provider data nodes; the federation nodes include: operator federation nodes and application service provider federation nodes; the slice MOS data includes: slice network data and / or service MOS data, wherein:

[0157] The operator data nodes are configured to provide slice network metadata corresponding to the slice network data of one slice in one time period and / or service MOS metadata corresponding to the service MOS data collected by the NWDAF from the network during internal training; and / or,

[0158] The application service provider data nodes are configured to provide service MOS metadata corresponding to the service MOS data of one slice in one time period.

[0159] In one time period, the slice network data and the service MOS data of the same slice have a correlation relationship.

[0160] Specifically, the operator data nodes and / or the application service provider data nodes are configured to provide the slice network data and the corresponding service MOS data of one slice in one time period, and correspondingly, two records (both are called related data) on the chain need to be associated.

[0161] In an implementation, the operator data nodes are further configured to provide the slice network data including one or a combination of the following data:

[0162] The OAM data provided by the slice manager includes one or a combination of the following information: UE-level minimization of drive test data, network function performance measurement data, and network-level KPI data.

[0163] The data input from the 5G core network includes one or a combination of the following information: non-OAM data at the QoS flow level, UE level, and service level.

[0164] Specifically, the slice network data, wherein the OAM (Operation, Administration and Maintenance) data provided by the slice manager includes UE (User Equipment) level MDT (Minimization of Drive Test) data, NF (Network Function) performance measurement data, network level KPI (Key Performance Indicator) data, and the like; the data input from the 5G core network can be QoS (Quality of Service) flow level, UE level, or even service level non-OAM data, and the like; and other operator nodes can provide slice network data collected by the NWDAF (Network Data Analytics Function) from the network when performing internal training and service MOS data collected from application service providers, and the like.

[0165] In implementation, the application service provider data node is further configured to provide service MOS metadata including one or a combination of the following data:

[0166] a hash value of the service MOS data;

[0167] a storage address of the service MOS data.

[0168] Specifically, the application service provider data node is responsible for collecting and storing its own service MOS data, and is responsible for providing metadata of the data, such as a hash value of the service MOS data, a storage address of the service MOS data, and the like.

[0169] In implementation, the data node is further configured to, after receiving a slice MOS data sharing request of the data request node, request the blockchain whether to agree to read the slice MOS data according to a slice MOS data authorization read strategy on the blockchain.

[0170] Specifically, the slice MOS data sharing request of the data request node is supported, the blockchain is requested to read an authorization read strategy, and whether to agree to read the original data is decided according to a slice MOS data authorization read strategy on the blockchain.

[0171] In implementation, the operator data node is further configured to, when sending the authorization write strategy to the alliance node, add a public key of a related slice tenant to a data identifier, so as to identify a slice tenant allowed to upload service MOS data of the data identifier.

[0172] In a specific implementation, the operator data node is further configured to use a hash value of the slice ID and a hash value of the timestamp as the data identifier, where the slice ID is an NSSAI or an SLA contract identifier.

[0173] Specifically, the operator data node can be configured as follows: the node is responsible for providing an authorized write policy of a related party of the slice MOS data association, which can be a data identifier plus a public key of a related slice tenant, representing that the slice tenant owning the public key is allowed to upload the business MOS data of the data identifier, where the data identifier can be (a hash value of a slice ID + a hash value of a timestamp), the slice ID can be an NSSAI (Network Slice Selection Assistance Information) or an SLA (Service Level Agreement) contract identifier, and the hash value is used to avoid illegal users occupying the data position of the slice ID on the chain by forging the slice ID, and at the same time, the hash value is used to find and associate the slice MOS data without exposing the slice ID.

[0174] In an implementation, the alliance node includes an operator alliance node and an application service provider alliance node, where:

[0175] The operator alliance node is configured to perform one or a combination of the following processes:

[0176] Upload slice network metadata and / or business MOS metadata to the blockchain;

[0177] Determine an authorized read policy of the slice network data and / or the business MOS data, and upload the slice network data and / or the business MOS data, and the authorized write policy and the authorized read policy of the slice network data and / or the business MOS data to the blockchain;

[0178] Participate in blockchain consensus and verification, and determine whether to allow writing a new record according to the authorized write policy in the record with an association relationship on the blockchain during consensus;

[0179] Store a ledger of the slice network data in the recorded slice MOS metadata;

[0180] Store a ledger of the authorized write policy and the authorized read policy;

[0181] Deploy an intelligent contract for executing the authorized write policy and the authorized read policy;

[0182] According to a data viewing request, view the slice network data corresponding to the slice MOS metadata and the authorized write policy and the authorized read policy in the blockchain;

[0183] An application service provider alliance node is configured to perform one or a combination of the following processes:

[0184] Uploading slice MOS metadata to a blockchain;

[0185] Determining an authorized read policy of service MOS data corresponding to the slice MOS metadata, uploading the service MOS data corresponding to the slice MOS metadata and the authorized write policy and the authorized read policy of the service MOS data corresponding to the slice MOS metadata to the blockchain;

[0186] Participating in blockchain consensus and verification, and determining whether to allow writing a new record according to the authorized write policy in the record with an associated relationship on the blockchain during consensus;

[0187] Storing a ledger of service MOS data in the slice MOS metadata;

[0188] Storing a ledger of authorized write policies and authorized read policies;

[0189] Deploying a smart contract for executing the authorized write policy and the authorized read policy;

[0190] Viewing the service MOS data corresponding to the slice MOS metadata and the authorized write policy and the authorized read policy in the blockchain according to a data viewing request.

[0191] Specifically, the operator alliance node can be as follows: belonging to an operator providing a slice network, serving as a participating node of a blockchain network, ①serving as an access point of a data provider, receiving metadata and an authorized write policy provided by an operator data node, and receiving an authorized read policy of slice MOS data (such as a public key of an authorized party, that is, an authorized object, or a characteristic value of the authorized party), ②responsible for distributing the metadata + authorized write policy + authorized read policy as a record after signing to blockchain network nodes, or distributing the metadata as a record to blockchain network nodes, and writing the authorized read and write policies and verification as a smart contract to the blockchain.

[0192] The application service provider alliance node can be as follows: belonging to a vertical industry application service provider renting a slice network, serving as a participating node of a blockchain network, ①serving as an access point of a data provider, responsible for receiving service MOS metadata and an authorized write policy, responsible for receiving an authorized read policy of service MOS data (such as a public key of an authorized party, that is, an authorized object, or a characteristic value of the authorized party), and responsible for receiving an authorized read policy of slice MOS data; responsible for distributing the metadata + authorized write policy + authorized read policy as a record after signing to blockchain network nodes, or distributing the metadata as a record to blockchain network nodes, and writing the authorized read and write policies and verification as a smart contract to the blockchain.

[0193] In implementation, the alliance node is further configured to distribute the slice MOS metadata, the authorized read policy of the data corresponding to the slice MOS metadata, and the authorized write policy of the data corresponding to the slice MOS metadata as a record after signing, to a blockchain network node; or,

[0194] The alliance node distributes the slice MOS metadata as a record after signing, to a blockchain network node, and broadcasts the authorized read policy of the data corresponding to the slice MOS metadata and the authorized write policy of the data corresponding to the slice MOS metadata as a transaction after signing, to other blockchain nodes; or,

[0195] The slice MOS metadata is distributed as a record after signing, to a blockchain network node, and the authorized read policy of the data corresponding to the slice MOS metadata and the authorized write policy of the data corresponding to the slice MOS metadata and the verification are written as a smart contract and deployed to the blockchain.

[0196] Specifically, the operator alliance node can be as follows: responsible for distributing the metadata + authorized write policy + authorized read policy as a record after signing, to a blockchain network node; or distributing the metadata as a record to a blockchain network node, and writing the authorized read and write policies and the verification as a smart contract and deploying to the blockchain.

[0197] The following is described by way of example, in which the architecture of the operator and the application service provider will be mainly described.

[0198] Figure 2 A schematic diagram of a data sharing system structure II is shown in the figure, which includes the following components:

[0199] The operator data node: the data capable of generating modeling value should include the slice network data and the corresponding business MOS data in a time period for a slice, the combination of the two is called slice MOS data, and the slice network data and the corresponding business MOS data can come from the operator and the application service provider respectively (both can be referred to as related parties), and the corresponding two records on the chain (both can be referred to as related data) need to be associated.

[0200] The operator data node belongs to the operator providing the slice network, and the functions can be as follows:

[0201] ①As a data provider, it is responsible for collecting and storing raw data for model training. The raw data can be network data provided by the slice manager and the core network corresponding to the business, i.e. slice network data. The operation, administration and maintenance (OAM) data provided by the slice manager includes UE-level minimization of drive test (MDT) data, network function (NF) performance measurement data and network-level KPI data, etc. The data input from the 5G core network can be non-OAM data at the QoS flow level, UE level or even business level, etc. Other operator nodes can provide slice network data collected by NWDAF from the network during internal training and business MOS data collected from application service providers, etc.

[0202] ②The node is responsible for providing metadata of the above data, such as hash value of slice network data / slice MOS data, and storage address of slice network data / slice MOS data, etc.

[0203] ③The node is responsible for providing authorization write strategy of related parties associated with slice MOS data. The strategy can be data identifier plus public key of related slice tenant, representing that the slice tenant owning the public key is allowed to upload business MOS data of the data identifier, wherein the data identifier can be (hash value of slice ID + hash value of timestamp), and the slice ID can be NSSAI (Network Slice Selection Assistance Information) or SLA contract identifier. The reason for using hash value is to avoid illegal users occupying the data position on the chain by forging slice ID, and at the same time, the hash value is used to find and associate slice MOS data without exposing slice ID.

[0204] ④As a client, send metadata and authorization write strategy to operator alliance node;

[0205] ⑤Support slice MOS data sharing request of data request party, request authorization read strategy from blockchain, and decide whether to agree to read raw data according to slice MOS data authorization read strategy on the chain.

[0206] Operator alliance node: belonging to the operator providing slice network, as a participant node of blockchain network, the function can be as follows:

[0207] ① As a data provider, the access point is responsible for receiving the metadata and authorization write strategy provided by the operator data node, and is responsible for receiving the authorized read strategy of the slice MOS data (such as the public key of the authorized party, that is, the authorized object, or the characteristic value of the authorized party);

[0208] ② Responsible for distributing the metadata + authorization write strategy + authorization read strategy as a record after signing to the blockchain network node, or distributing the metadata as a record to the blockchain network node, and writing the authorization read and write strategy and verification as a smart contract to the blockchain;

[0209] ③ Participate in blockchain consensus and verification, store the account book of slice MOS data metadata record, store the account book of authorization strategy record, and deploy and execute the smart contract of authorization strategy;

[0210] ④ Support (data provider) to view the authorization strategy;

[0211] ⑤ As a data requester, the access point supports viewing the slice MOS data metadata and authorization strategy or object in the blockchain, and can also serve as a data requester.

[0212] Application service provider data node: belonging to the vertical industry application service provider renting the slice network, as a data provider, responsible for collecting and storing its own business MOS data; responsible for providing the metadata of these data, such as the hash value of business MOS data and the storage address of business MOS data; the node is responsible for providing the authorization write strategy of the related party associated with the business MOS data, which can be the data identifier plus the public key of the related operator, representing the permission of the operator with the public key to upload the slice network data of the data identifier; as a client, send the metadata and authorization write strategy to the application service provider alliance node; support receiving business MOS data sharing requests from data requesters, requesting to read authorization read strategy from the blockchain, and deciding whether to agree to read the original data according to the business MOS data authorization read strategy in the chain.

[0213] Application service provider alliance node: belonging to the vertical industry application service provider renting the slice network, which is a participating node of the blockchain network, and its functions can be as follows:

[0214] ① As a data provider access point, responsible for receiving service MOS metadata and authorized write strategy, responsible for receiving authorized read strategy of service MOS data (such as public key of authorized party, authorized object, or characteristic value of authorized party, etc.); responsible for receiving authorized read strategy of slice MOS data; responsible for distributing metadata + authorized write strategy + authorized read strategy as a record after signing to the blockchain network node, or distributing metadata as a record to the blockchain network node, and writing authorized read and write strategy and verification as a smart contract deployed to the blockchain; participate in blockchain consensus and verification, store record slice MOS data metadata ledger, store record authorized strategy or object ledger, deploy and execute authorized strategy smart contract; support (data provider) to view authorized strategy;

[0215] ② As a data requester access point, support viewing slice MOS data metadata and authorized strategy or object in the blockchain; itself can also be a data requester.

[0216] Query system: related parties can access to query the network data of a certain business and its corresponding MOS data and other statistical information based on it.

[0217] Data requester: a party that requests to obtain and store slice MOS data, which can access operator alliance nodes or application service provider alliance nodes, and the operator alliance nodes or application service provider alliance nodes themselves can also be data requesters.

[0218] The following describes the implementation of the data sharing method based on the data sharing system.

[0219] Figure 3 The implementation flowchart of the data sharing method based on the data sharing system is shown in the figure, which can include:

[0220] Step 301, the data node obtains and stores slice MOS data, and the authorized write strategy of the slice MOS data, generates slice MOS metadata according to the slice MOS data, and sends the slice MOS metadata and the authorized write strategy of the slice MOS data to the alliance node, wherein the slice MOS metadata includes a hash value of the slice MOS data and / or a storage address of the slice MOS data;

[0221] Step 302, the alliance node performs one of the following processes or a combination thereof:

[0222] determine the authorized read strategy of the slice MOS data, and upload the slice MOS metadata, the authorized write strategy and the authorized read strategy of the slice MOS data to the blockchain;

[0223] Participate in blockchain consensus and verification, and determine whether to allow writing new records according to the authorization write strategy in the record associated with the blockchain during consensus.

[0224] A ledger for storing record slice MOS metadata;

[0225] A ledger for storing record authorization write strategy and authorization read strategy;

[0226] Deploying a smart contract for executing the authorization write strategy and the authorization read strategy;

[0227] Viewing slice MOS metadata and authorization write strategy and authorization read strategy in the blockchain according to a data viewing request;

[0228] Step 303, the data request node issues a data viewing request.

[0229] In implementation, when uploading slice MOS data and authorization write strategy and authorization read strategy of the slice MOS data to the blockchain, the following steps are included:

[0230] Method one: the alliance node distributes the slice MOS metadata, the authorization read strategy of the data corresponding to the slice MOS metadata, and the authorization write strategy of the data corresponding to the slice MOS metadata as a record after signing, to the blockchain network node; or,

[0231] Method two: the alliance node distributes the slice MOS metadata as a record after signing to the blockchain network node, and broadcasts the authorization read strategy of the data corresponding to the slice MOS metadata and the authorization write strategy of the data corresponding to the slice MOS metadata as a transaction after signing to other blockchain nodes; or,

[0232] Method three: the alliance node distributes the slice MOS metadata as a record after signing to the blockchain network node, and deploys the authorization read strategy of the data corresponding to the slice MOS metadata and the authorization write strategy of the data corresponding to the slice MOS metadata and verification as a smart contract on the blockchain.

[0233] Specifically, the authorization strategy can be written into the ledger of the blockchain as a record together with the metadata, and the alliance node views the authorization strategy in the record on the chain as the basis for subsequent behavior; the authorization strategy can also be written into the ledger of the blockchain as a record alone; the authorization strategy can also be written as a smart contract deployed on the blockchain, and the alliance node needs to call the smart contract when writing and reading.

[0234] The system flow mainly has two parts: 1) slice MOS data writing; 2) slice MOS data authorization viewing. There are mainly three ways, which are described below.

[0235] The first mode is that the authorization policy and the metadata are written as a record in the ledger.

[0236] 1. Implementation of slice MOS data writing.

[0237] In the implementation, the slice MOS metadata, the authorization read policy of the data corresponding to the slice MOS metadata, and the authorization write policy of the data corresponding to the slice MOS metadata are signed as a record and distributed to the blockchain network nodes. The distributed record to the blockchain network nodes includes one or a combination of the following information:

[0238] a hash value of the slice MOS data, a storage address of the slice MOS data, a data identifier, a public key of an application service provider authorized to write the associated data, and a public key of a consortium member authorized to read the slice MOS metadata; or

[0239] a hash value of the slice network data, a storage address of the slice network data, a data identifier, a public key of an application service provider authorized to write the associated data, and a public key of a consortium member authorized to read the slice network data; or

[0240] a hash value of the service MOS data, a storage address of the service MOS data, a data identifier, a public key of an operator authorized to write the associated data, and a public key of a consortium member authorized to read the service MOS data.

[0241] For details, see the implementation of Example 2) below.

[0242] In the implementation, the following can be further included:

[0243] The node on the blockchain checks the format and signature of the received data, checks whether there is a record containing the data identifier on the blockchain, and if not, regards it as a record.

[0244] If there is, it is determined whether the signature corresponds to the public key authorized to write. If yes, it is regarded as a record. If not, it is regarded as false data and discarded.

[0245] The node on the blockchain uses the consensus mechanism in the blockchain to encapsulate the records obtained within a period of time into a new block and broadcast the block.

[0246] For details, see the implementation of Example 3) below.

[0247] 1) For the operator data node, it collects and stores the original slice MOS data such as slice network data or slice MOS data for model training, and generates metadata after processing, which can include the hash value, storage address and other information of the original data, provides the authorized write strategy of the related party associated with the slice MOS data, which can be the data identifier plus the public key of the slice tenant using the slice, representing the slice tenant with the public key is allowed to upload the service MOS data of the data identifier, wherein the data identifier can be the hash value of (slice ID + timestamp), the slice ID can be NSSAI (Network Slice Selection Assistance Information) or SLA contract identifier, the reason for using the hash value of the data identifier is to avoid illegal users occupying the data position on the chain of the slice ID by forging the slice ID, and at the same time, the hash value is used to find and associate the slice MOS data without exposing the slice ID.

[0248] The metadata and the authorized write strategy are sent to the operator alliance node; for the application service provider data node, it collects and stores the original service MOS data for model training, and generates metadata after processing, which can include the hash value, storage address and other information of the original data, provides the authorized write strategy of the related party associated with the service MOS data, which can be the data identifier plus the public key of the operator providing the slice, representing the operator with the public key is allowed to upload the slice MOS data of the data identifier. The metadata and the authorized write strategy are sent to the application service provider alliance node.

[0249] 2) The operator alliance node and the application service provider alliance node broadcast the metadata and the authorized read-write strategy received by each other as a transaction signature to other blockchain nodes; there are three transactions corresponding to 1):

[0250] ① Slice MOS data hash value, slice MOS data storage address, data identifier, public key of the application service provider authorized to write associated data, public key of the alliance member authorized to read the slice MOS data;

[0251] ② Hash value of slice network data and other data, storage address of slice network data and other data, data identifier, public key of the application service provider authorized to write associated data, public key of the alliance member authorized to read the slice network data;

[0252] ③ Hash value of service MOS data and other data, storage address of service MOS data and other data, data identifier, public key of the operator authorized to write associated data, public key of the alliance member authorized to read the service MOS data.

[0253] 3) other blockchain nodes check the format and signature of the received data, see if there is a record on the chain with the data identifier, if not, it is regarded as a record;

[0254] If there is, it is determined whether the signature corresponds to the public key authorized to write, that is, whether it is the data uploaded by the relevant party, if so, it is regarded as a record, if not, it is regarded as false data and discarded.

[0255] The node uses the consensus mechanism in the blockchain to encapsulate the records obtained within a period of time into a new block and broadcast the block;

[0256] 4) other nodes in the network receive the new block, verify the format of the block and each record in the block, and whether the block meets the requirements of the consensus mechanism, if correct, then add the new block to the locally saved blockchain and forward; otherwise, discard the new block.

[0257] 2, implementation of slice MOS data authorization view.

[0258] In the implementation, after the data request node sends a data view request, further comprising:

[0259] The data request node accesses the alliance node to apply for viewing the slice MOS metadata stored on the blockchain, including: applying to read the slice MOS metadata hash value; or, find the hash value of the slice network data or the hash value of the business MOS data through the data identifier; or, call the smart contract to read the slice MOS metadata;

[0260] The data request party applies for the slice MOS metadata corresponding to the data identifier to the data node according to the read data address;

[0261] The data node reads the public key of the alliance member allowed to read the authorization read strategy of the slice MOS metadata from the blockchain through the alliance node, judges whether it is the public key of the data request party, and judges whether to send the slice MOS metadata to the data request party;

[0262] The data request party verifies whether the obtained original data is correct according to the data hash in the read record.

[0263] The following is illustrated by an example as follows.

[0264] Figure 4 The implementation schematic diagram of the way slice MOS data authorization view is shown in the figure, which mainly includes:

[0265] 1) The entity that needs to train the slice MOS model, i.e., the data requester, accesses the alliance node to apply for viewing the slice MOS metadata stored on the blockchain, and can read the complete slice MOS data pair, i.e., record ①, or find the corresponding network data and business MOS data, i.e., the associated data pairs of records ② and ③, through the data identifier.

[0266] 2) The data requester applies for the original data corresponding to the data identifier to the data node according to the read data address.

[0267] 3) The data node reads the authorized reading strategy, i.e., the public key of the alliance member allowed to read, of the original data from the blockchain through the alliance node, judges whether it is the public key of the requester, and thus judges whether to send the original data to the requester.

[0268] 4) The requester verifies whether the obtained original data is correct according to the data hash in the read record.

[0269] Method two, the authorization strategy and the metadata are written as records respectively:

[0270] 1. Implementation of slice MOS data writing.

[0271] In the implementation, the alliance node distributes the slice MOS data as a record after signing to the blockchain network node, and distributes the slice MOS data as a record after signing to the blockchain network node, which includes one or a combination of the following information:

[0272] Slice MOS data hash value, slice MOS data storage address, data identifier;

[0273] Hash value of slice network data, storage address of slice network data, data identifier;

[0274] Hash value of business MOS data, storage address of business MOS data, data identifier;

[0275] The authorized reading strategy of the slice MOS data and the authorized writing strategy of the slice MOS data are signed as a transaction and broadcast to other blockchain nodes, and the authorized reading strategy and the authorized writing strategy are signed as a transaction and broadcast to other blockchain nodes, which includes one or a combination of the following information:

[0276] The authorized reading strategy and the authorized writing strategy are signed as a transaction and broadcast to other blockchain nodes, and the authorized reading strategy and the authorized writing strategy transaction is the hash value of the slice ID, the public key of the application service provider of the slice, the public key of the operator of the slice, and the public key of the alliance member authorized to read the slice MOS data of the slice.

[0277] See the implementation of Example 2) below for details.

[0278] In an implementation, further comprising:

[0279] The node on the blockchain checks the format and signature of the received data;

[0280] For metadata transactions, check if there is a record containing the metadata identifier on the chain, if not, it is a record; if there is, judge whether the signature corresponds to the public key authorized to write, if yes, it is a record, if not, it is considered as false data and discarded;

[0281] For authorized read strategy and authorized write strategy transactions, judge whether the transaction signature corresponds to the public key of the application service provider and / or operator in the transaction, judge whether the public key corresponds to the signature of the record in which the slice identifier first appears in the blockchain, if not, it is considered as false authorized strategy and the transaction is discarded, if it is satisfied, it is a record;

[0282] The node on the blockchain uses the consensus mechanism in the blockchain to encapsulate the records obtained within a period of time into a new block and broadcast and publish the block.

[0283] See the implementation of the following example 3) for details.

[0284] The following is illustrated by examples.

[0285] 1) For the operator data node, it collects and stores the original slice MOS data used for model training, such as slice network data or slice MOS data, etc., and generates metadata after processing, which can include the hash value, storage address, etc. of the original data, and provides the authorized write strategy of the related party associated with the slice MOS data. The strategy can be the data identifier plus the public key of the slice tenant using the slice, representing that the slice tenant owning the public key is allowed to upload the business MOS data of the data identifier, where the data identifier can be the hash value of (slice ID + timestamp), and the slice ID can be NSSAI (Network Slice Selection Assistance Information) or SLA contract identifier. The reason for using the hash value of the data identifier is to avoid illegal users occupying the data position of the slice ID on the chain by forging the slice ID, and at the same time, the hash value is used to find and associate the slice MOS data without exposing the slice ID.

[0286] The metadata and the authorized write strategy are sent to the operator alliance node; for the application service provider data node, it collects and stores the original business MOS data for model training, and generates metadata after processing, which can include the hash value, storage address and other information of the original data, and the authorized write strategy of the related party associated with the business MOS data. The strategy can be a data identifier plus the public key of the operator providing the slice, representing the operator owning the public key to upload the slice MOS data of the data identifier. The metadata and the authorized write strategy are sent to the application service provider alliance node.

[0287] 2) The operator alliance node and the application service provider alliance node broadcast the metadata and the data identifier received by each other as a transaction signature to other blockchain nodes; there are three kinds of metadata transactions:

[0288] ① Slice MOS data hash value, slice MOS data storage address, data identifier;

[0289] ② Hash value of slice network data and other data, storage address of slice network data and other data, data identifier;

[0290] ③ Hash value of business MOS data and other data, storage address of business MOS data and other data, data identifier.

[0291] The operator alliance node and / or the application service provider alliance node can also broadcast the strategy as a transaction to other blockchain nodes, and the strategy transaction is the hash value of the slice ID, the public key of the application service provider and / or the operator of the slice (i.e. the authorized party that can upload data related to the slice), and the public key of the alliance member authorized to read the slice MOS data of the slice.

[0292] Compared with mode one, the related parties authorized to write the slice (i.e. the operator and the application service provider of a certain slice) and the objects authorized to read are relatively stable, and the related parties authorized to write under different time stamps of the same slice are the same, which can save storage space compared with being included in each time stamp record.

[0293] 3) Other blockchain nodes check the format and signature of the received data, and for metadata transactions, check whether there is a record containing the data identifier on the chain, if not, it is regarded as a record; if there is, it is judged whether the signature corresponds to the public key authorized to write, i.e. whether it is the data uploaded by the associated party, if so, it is regarded as a record, if not, it is regarded as false data and discarded;

[0294] For policy transactions, it is determined whether the transaction signature corresponds to the public key of the application service provider and / or operator in the transaction, and whether the public key corresponds to the signature of the record in which the slice identifier first appears in the blockchain; the reason is that only the operator and ASP of the slice know the slice identifier, and only the hash value of the slice identifier is publicly disclosed. Due to the collision resistance of the hash value, it is difficult for people who do not know the slice identifier to forge the hash value of the slice identifier, so the signer of the record containing the slice identifier first appearing can be considered as the real related party of the slice, and the slice identifier can also first appear in the policy transaction;

[0295] If the above conditions are not met, the transaction is considered as a false authorized policy and discarded, and if the conditions are met, it is considered as a record; the node uses the consensus mechanism in the blockchain to encapsulate the records obtained within a period of time into a new block and broadcast the block;

[0296] 4) After receiving the new block, the other nodes in the network verify whether the block and each record in the block are correct and complete, whether the block meets the requirements of the consensus mechanism, and if so, the new block is added to the locally saved blockchain and forwarded; otherwise, the new block is discarded.

[0297] 2, slice MOS data authorization view:

[0298] In implementation, after the data request node sends a data viewing request, further comprising:

[0299] The data request node accesses the alliance node to apply for viewing the slice MOS metadata stored on the blockchain, including: applying to read the hash value of the data corresponding to the slice MOS metadata; or, finding the hash value of the slice network data or the hash value of the business MOS data through the data identifier; or, calling the smart contract to read the slice MOS metadata;

[0300] The data request party applies for the slice MOS data corresponding to the data identifier to the data node according to the read data address;

[0301] The data node reads the authorization reading policy for the slice MOS metadata from the blockchain through the alliance node to determine whether to send the slice MOS metadata to the data request party;

[0302] The data request party verifies whether the obtained original data is correct according to the data hash in the read record.

[0303] The following is illustrated by an example.

[0304] Figure 5 For the implementation diagram of the second way of slice MOS data authorization view, as shown in the figure, it mainly includes:

[0305] 1) The entity that needs to train the slice MOS model, i.e., the data requester, accesses the alliance node to apply to view the slice MOS metadata stored on the blockchain, and can read the complete slice MOS data pair, i.e., record ①, or find the corresponding network data and business MOS data, i.e., the associated data pairs of records ② and ③, through the data identifier.

[0306] 2) The data requester applies to the data node for the original data corresponding to the data identifier according to the read data address.

[0307] 3) The data node reads the authorized reading strategy for the original data from the blockchain through the alliance node.

[0308] 4) The data node judges whether to send the original data to the requester based on the authorized object read on the chain.

[0309] 5) The requester verifies whether the obtained original data is correct according to the data hash in the read record.

[0310] Method three, write the authorization strategy into the smart contract:

[0311] 1. Implementation of slice MOS data writing.

[0312] In the implementation, the authorization reading strategy and the authorization writing strategy and verification of the slice MOS data are written into the smart contract and deployed on the blockchain,

[0313] The authorization writing strategy logic is: for the slice identified by the slice ID hash value, the identity public key of the operator and the application service provider allowed to write the metadata of the slice to the chain is agreed; it is judged whether the signature carried in the metadata writing request of the slice matches the public key, if yes, the writing is allowed, if not, the writing is not allowed;

[0314] The authorization reading strategy logic is: for the slice identified by the slice ID hash value, the identity public key of the alliance member allowed to read the off-chain original data of the slice, and the reading constraint condition are agreed; if the signature of the original data reading request is the data provider, the identity of the member allowed to read is returned, if it is the data requester and the signature matches the authorized reading public key, the reading allowed flag is returned.

[0315] Specifically, when the operator provides slice services to the application service provider of the vertical industry, the read-write authorization strategy is written into the smart contract, signed by the relevant parties, and deployed on the blockchain. The logic of the write authorization strategy is:

[0316] For the slice identified by the slice ID hash value, the identity of the operator and the application service provider allowed to write the metadata of the slice to the chain, such as the public key, is agreed;

[0317] determining whether the signature carried in the metadata write request of the slice matches the public key, if yes, allowing writing, if not, not allowing writing;

[0318] The logic of reading the authorization policy is that for the slice identified by the slice ID hash value, the identity of the alliance member allowed to read the off-chain original data of the slice is agreed, such as a public key, and other conditions, such as the time range allowed to read, etc.

[0319] If the signature of the original data read request is the data provider, the identity of the member allowed to read is returned, if the signature matches the public key authorized to read, the token allowed to read is returned.

[0320] Compared with mode one, the parties authorized to write the slice (i.e. the operator and application service provider of a slice) and the objects authorized to read are relatively stable, and the parties authorized to write and read under different time stamps of a slice are the same, which can save storage space compared with being included in each time stamp record.

[0321] The difference between mode two and mode three is that the policy of mode two exists in the form of a block transaction, and the policy execution is completed by the verification program of each node, while the policy of mode three exists in the form of a smart contract parameter, and the policy execution is completed by the smart contract. The language of the contract is Turing complete, which can better support complex logic. In addition, writing logic to a smart contract can facilitate decoupling from the underlying blockchain platform. Mode two needs to compile the verification function into the node program when developing the blockchain, which is difficult to update, while the smart contract mode is more flexible and can be developed and deployed after the blockchain platform is running.

[0322] In implementation, the data node sends the slice MOS data to the alliance node, including:

[0323] The data node collects and stores the slice MOS data used for model training;

[0324] The slice MOS data is processed to generate slice MOS metadata, and the slice MOS metadata includes: hash value and / or storage address of the original slice MOS data;

[0325] The metadata is sent to the alliance node.

[0326] Specifically, for the operator data node, it collects and stores the original slice MOS data used for model training, such as slice network data or slice MOS data, etc., and generates metadata after processing. The metadata can include hash value, storage address, etc. of the original data;

[0327] The metadata is sent to the operator alliance node; for the application service provider data node, it collects and stores original business MOS data for model training, and generates metadata after processing, which can include hash value, storage address, etc. Information of original data; send the metadata to the application service provider alliance node.

[0328] In implementation,

[0329] When the alliance node deploys the authorization read strategy of the data corresponding to the slice MOS metadata and the authorization write strategy and verification of the data corresponding to the slice MOS metadata to the blockchain as a smart contract:

[0330] The alliance node calls the smart contract with the received slice MOS metadata and data identifier as parameters;

[0331] The smart contract executes the write of the slice MOS metadata transaction, and the slice MOS metadata transaction written to the chain has one of the following data or a combination thereof:

[0332] Slice MOS data hash value, slice MOS data storage address, data identifier; or,

[0333] Hash value of slice network data, storage address of slice network data, data identifier; or,

[0334] Hash value of business MOS data, storage address of business MOS data, data identifier.

[0335] Specifically, the operator alliance node and the application service provider alliance node call the smart contract with the received metadata and data identifier as parameters; the contract executes the write of the metadata transaction, and the metadata transaction written to the chain has three kinds:

[0336] ① Slice MOS data hash value, slice MOS data storage address, data identifier;

[0337] ② Hash value of slice network data and other data, storage address of slice network data and other data, data identifier;

[0338] ③ Hash value of business MOS data and other data, storage address of business MOS data and other data, data identifier.

[0339] 2. Slice MOS data authorization viewing implementation.

[0340] In implementation, after the data request node issues a data viewing request, further comprising:

[0341] The data request node accesses the alliance node to apply to view the slice MOS data stored on the blockchain, including: applying to read the slice MOS data hash value; or, finding the hash value of the slice network data or the hash value of the business MOS data and other data through the data identifier; or, calling the smart contract to read the slice MOS data;

[0342] The data request party applies to the data node for the slice MOS data corresponding to the data identifier according to the read data address; or, the data request party carries the read permission flag in the application;

[0343] If the read permission flag verification is successful, the data node sends the original data to the request party; if the verification is not successful, the data node calls the smart contract through the alliance node to read the read permission membership for the original data from the blockchain, and judges whether to send the original data to the request party;

[0344] The data request party verifies whether the obtained original data is correct according to the data hash in the read record.

[0345] The following is described by taking an example.

[0346] The third mode of slice MOS data authorization viewing mainly includes:

[0347] 1) The entity that needs to perform slice MOS model training, that is, the data request party accesses the alliance node, applies to view the slice MOS metadata stored on the blockchain, and can read the complete slice MOS data pair, that is, record ①, or find the corresponding network data and business MOS data and other data, that is, the associated data pairs of records ② and ③. The request party can also call the smart contract to read, and if the authorization is successful, a read token can be obtained.

[0348] 2) The data request party applies to the data node for the original data corresponding to the data identifier according to the read data address; if the token is obtained in 1), the token can be written in the request.

[0349] 3) If the token is verified successfully, the data node sends the original data to the request party; if there is no token, the data node calls the smart contract through the alliance node to read the read permission membership for the original data from the blockchain, and judges whether to send the original data to the request party;

[0350] 4) The request party verifies whether the obtained original data is correct according to the data hash in the read record.

[0351] Based on the same inventive concept, the embodiments of the present application also provide a computer storage medium, and the implementation of the devices can be referred to the implementation of the method, and the repeated parts will not be described herein.

[0352] The embodiments of the present application also provide a computer readable storage medium, which stores a computer program for executing the above data sharing method.

[0353] The implementation can be referred to the implementation of the data sharing method based on the data system.

[0354] In summary, in the technical solution provided by the embodiments of the present application, the authorized read-write strategy is written into the blockchain, the alliance node judges whether to allow the metadata to be written into the blockchain according to the authorized write strategy, the data requester alliance node queries the metadata on the blockchain to obtain the original data storage address and applies for the original data to the data node, that is, the data provider; whether to send the original data to the application entity is decided according to the authorized read strategy on the chain, and whether the original data is correct is verified by the application entity according to the hash on the chain.

[0355] Three forms of authorization strategies are provided, which correspond to three processes respectively: ① the authorized strategy and the metadata are written into the blockchain as a record, ② the authorized strategy and the metadata are written into the blockchain as a strategy transaction and a metadata transaction respectively, and ③ the authorized strategy is written into a smart contract.

[0356] In the scheme of the authorized write strategy for ensuring the correct source of the chained metadata: the authorized write strategy contains the hash of the slice data identifier and the identity (public key) of the authorized write related party, and the verification process of the authorized write strategy is that the node checks whether there is a record containing the data identifier on the chain, if not, it is taken as a record; if yes, it is judged whether the signature corresponds to the public key of the authorized write, that is, whether it is the data uploaded by the associated related party, if yes, it is taken as a record, if not, it is regarded as false data and discarded.

[0357] At least one of the following effects is achieved:

[0358] A decentralized slice MOS data authorization sharing system is provided, privacy protection is enhanced, integrity verification is supported, and authorized access is supported.

[0359] Distributed data consistency is ensured: the shared data of the alliance between the related parties, such as vertical industries / third parties, telecom manufacturers, and various operators, is synchronized.

[0360] The storage space occupation on the chain is reduced.

[0361] The authorized strategy is ensured to be public and correctly executed.

[0362] Ensure the slice MOS data on the chain comes from the correct data provider, avoid illegal upload and illegal read.

[0363] Those skilled in the art will appreciate that embodiments of the application can be devised for a method, a system, or a computer program product. Accordingly, the present application can be embodied in the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present application can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, and the like) embodying computer-readable program code.

[0364] The present application is described in reference to the flowchart illustrations and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart illustrations and / or block diagrams. Figure 1 one or more functions specified in the flowchart illustrations and / or block diagrams. Figure 1 means for performing each of the functions specified in the flowchart illustrations and / or block diagrams.

[0365] These computer program instructions can also be stored in a computer- readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the functions specified in the flowchart illustrations and / or block diagrams. Figure 1 one or more functions specified in the flowchart illustrations and / or block diagrams. Figure 1 means for performing each of the functions specified in the flowchart illustrations and / or block diagrams.

[0366] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart illustrations and / or block diagrams. Figure 1 one or more functions specified in the flowchart illustrations and / or block diagrams. Figure 1 means for performing each of the functions specified in the flowchart illustrations and / or block diagrams.

[0367] Obviously, numerous modifications and variations of the present application are possible in light of the above teachings. It is therefore to be understood that within the scope of the appended claims and their legal equivalents, the application can be practiced otherwise than as specifically described.

Claims

1. A data sharing system, characterized by, The application relates to a data node, a consortium node, a data request node and a blockchain composed of the consortium node, wherein the data node is used for acquiring and storing slice average subjective opinion score (MOS) data and an authorized write strategy of the slice average subjective opinion score (MOS) data, generating slice MOS metadata from the slice MOS data, and sending the slice MOS metadata and the authorized write strategy of the slice MOS data to the consortium node, wherein the slice MOS metadata comprises a hash value of the slice MOS data and / or a storage address of the slice MOS data; the consortium node is used for executing one or a combination of the following processes: determining an authorized read strategy of the slice MOS data, uploading the slice MOS metadata and the authorized write strategy and the authorized read strategy of the slice MOS data to the blockchain, participating in blockchain consensus and verification, judging whether a new record is allowed to be written according to the authorized write strategy in a record with an associated relationship on the blockchain during consensus, storing a ledger of record slice MOS metadata, storing a ledger of record authorized write strategy and authorized read strategy, deploying an intelligent contract for executing the authorized write strategy and the authorized read strategy, and viewing slice MOS metadata and the authorized write strategy and the authorized read strategy in the blockchain according to a data viewing request; the data request node is used for issuing a data viewing request; wherein the data node comprises an operator data node and an application service provider data node; the consortium node comprises an operator consortium node and an application service provider consortium node; the slice MOS data comprises slice network data and / or service MOS data; the authorized write strategy logic is that, for a slice identified by a slice ID hash value, the identity of an operator and an application service provider allowed to write metadata of the slice to the blockchain is agreed; whether a signature carried in a metadata write request of the slice matches the identity of the operator and the application service provider is judged, if yes, the write is allowed, and if not, the write is not allowed; the authorized read strategy logic is that, for the slice identified by the slice ID hash value, the identity of a consortium member allowed to read original data of the slice offline is agreed, and a read constraint condition is agreed; if a signature of an original data read request is of a data provider, the identity of the member allowed to read is returned, and if the signature is of a data requestor and matches the identity of the authorized read, a read allowed flag is returned; the data node is further used for, after receiving a slice MOS data sharing request of the data request node, requesting the blockchain to determine whether to agree to read the slice MOS data according to the authorized read strategy of the slice MOS data on the blockchain; wherein the operator data node is used for providing, to the operator consortium node, slice network metadata corresponding to slice network data in a time period and / or slice network metadata corresponding to slice network data collected from a network by a network data analysis function (NWDAF) during internal training and / or service MOS metadata corresponding to service MOS data; and / or the application service provider data node is used for providing, to the application service provider consortium node, service MOS metadata corresponding to service MOS data in a time period. ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ 2. The system of claim 1, wherein, ​ 3. The system of claim 1, wherein, ​ ​ ​ ​ The slice network data and the service MOS data in the same slice in the same time period have a correlation relationship.

4. The system of claim 3, wherein, The operator data node is further configured to provide slice network data including one or a combination of the following data: The OAM data provided by the slice manager includes one or a combination of the following information: The non-OAM data input from the 5G core network includes one or a combination of the following information:

5. The system of claim 3, wherein, The application service provider data node is further configured to provide service MOS metadata corresponding to one or a combination of the following data: A hash value of the service MOS data is provided. A storage address of the service MOS data is provided.

6. The system of claim 3, wherein, The operator data node is further configured to add a public key of a relevant slice tenant to a data identifier when sending an authorized write policy to the alliance node, so as to identify a slice tenant allowed to upload service MOS data of the data identifier.

7. The system of claim 6, wherein, The operator data node is further configured to use a hash value of a slice identifier ID and a hash value of a timestamp as a data identifier, wherein the slice ID is a NSSAI or a SLA contract identifier.

8. The system of claim 1, wherein, The operator alliance node is configured to perform one or a combination of the following processes: The slice network metadata and / or the service MOS metadata are uploaded to the blockchain. The authorized read policy of the slice network data and / or the service MOS data is determined, and the slice network data and / or the service MOS data, the authorized write policy and the authorized read policy of the slice network data and / or the service MOS data are uploaded to the blockchain. The slice network data in the slice MOS metadata record is stored in a ledger. The authorized write policy and the authorized read policy are stored in a ledger. An intelligent contract for executing the authorized write policy and the authorized read policy is deployed. The slice network data corresponding to the slice MOS metadata in the blockchain and the authorized write policy and the authorized read policy are viewed according to a data viewing request. The application service provider alliance node is configured to perform one or a combination of the following processes: The slice MOS metadata is uploaded to the blockchain. The authorized read policy of the service MOS data corresponding to the slice MOS metadata is determined, and the service MOS data corresponding to the slice MOS metadata and the authorized write policy and the authorized read policy of the service MOS data corresponding to the slice MOS metadata are uploaded to the blockchain. The slice network data in the slice MOS metadata record is stored in a ledger. The authorized write policy and the authorized read policy are stored in a ledger. An intelligent contract for executing the authorized write policy and the authorized read policy is deployed. ​ ​ ​ According to the data viewing request, the slice MOS metadata corresponding to the business MOS data in the blockchain and the authorized write strategy and the authorized read strategy are viewed.

9. The system of claim 1, wherein, The alliance node is further used for signing and distributing the slice MOS metadata, the authorized read strategy of the data corresponding to the slice MOS metadata, and the authorized write strategy of the data corresponding to the slice MOS metadata to the blockchain network node as a record. Or, The alliance node signs and distributes the slice MOS metadata to the blockchain network node, signs and broadcasts the authorized read strategy of the data corresponding to the slice MOS metadata and the authorized write strategy of the data corresponding to the slice MOS metadata to other blockchain nodes as a transaction. Or, The slice MOS metadata is signed and distributed to the blockchain network node, and the authorized read strategy of the data corresponding to the slice MOS metadata and the authorized write strategy of the data corresponding to the slice MOS metadata are signed and broadcast to other blockchain nodes as a transaction.

10. A data sharing method based on the system according to any one of claims 1 to 9, characterized in that, It includes: The data node acquires and stores the slice MOS data and the authorized write strategy of the slice MOS data, generates slice MOS metadata according to the slice MOS data, and sends the slice MOS metadata and the authorized write strategy of the slice MOS data to the alliance node, wherein the slice MOS metadata includes a hash value of the slice MOS data and / or a storage address of the slice MOS data. The alliance node performs one or a combination of the following processes: Determine the authorized read strategy of the slice MOS data, upload the slice MOS metadata and the authorized write strategy and the authorized read strategy of the slice MOS data to the blockchain; Participate in the consensus and verification of the blockchain, and determine whether to allow writing a new record according to the authorized write strategy in the records with an associated relationship on the blockchain during the consensus; Store the record slice MOS metadata; Store the record authorized write strategy and the authorized read strategy; Deploy the smart contract for executing the authorized write strategy and the authorized read strategy; According to the data viewing request, the slice MOS metadata and the authorized write strategy and the authorized read strategy in the blockchain are viewed. The data request node issues a data viewing request.

11. The method of claim 10, wherein, When uploading the slice MOS metadata and the authorized write strategy and the authorized read strategy of the slice MOS data to the blockchain, it includes: The alliance node signs and distributes the slice MOS metadata, the authorized read strategy of the data corresponding to the slice MOS metadata, and the authorized write strategy of the data corresponding to the slice MOS metadata to the blockchain network node as a record; or The alliance node signs and distributes the slice MOS metadata to the blockchain network node, signs and broadcasts the authorized read strategy of the data corresponding to the slice MOS metadata and the authorized write strategy of the data corresponding to the slice MOS metadata to other blockchain nodes as a transaction; or The alliance node signs and distributes the slice MOS metadata to the blockchain network node, signs and broadcasts the authorized read strategy of the data corresponding to the slice MOS metadata and the authorized write strategy of the data corresponding to the slice MOS metadata to other blockchain nodes as a transaction.

12. The method of claim 11, wherein, The alliance node distributes the slice MOS metadata, the authorized read strategy of the data corresponding to the slice MOS metadata, and the authorized write strategy of the data corresponding to the slice MOS metadata to the blockchain network node after signing the record, and the data distributed to the blockchain network node includes one or a combination of the following information: The hash value of the slice MOS data, the storage address of the slice MOS data, the data identifier, the public key of the application service provider authorized to write the associated data, and the public key of the alliance member authorized to read the slice MOS metadata. Or, The hash value of the slice network data, the storage address of the slice network data, the data identifier, the public key of the application service provider authorized to write the associated data, and the public key of the alliance member authorized to read the slice network data. Or, 13. The method of claim 12, wherein, The hash value of the service MOS data, the storage address of the service MOS data, the data identifier, the public key of the operator authorized to write the associated data, and the public key of the alliance member authorized to read the service MOS data. Further comprising: The node on the blockchain checks the format and signature of the received data, checks whether there is a record containing the data identifier on the blockchain, and if not, it is regarded as a record. If there is, it is determined whether the signature corresponds to the public key authorized to write, if yes, it is regarded as a record, if not, it is regarded as false data and discarded.

14. The method of claim 11, wherein, The node on the blockchain uses the consensus mechanism in the blockchain to encapsulate the records obtained within a period of time into a new block and broadcast the block. The alliance node distributes the slice MOS metadata to the blockchain network node after signing the record, and the record signed after being distributed to the blockchain network node includes one or a combination of the following information: The hash value of the slice MOS metadata, the storage address of the slice MOS metadata, and the data identifier. The hash value of the slice network data, the storage address of the slice network data, and the data identifier. The hash value of the service MOS data, the storage address of the service MOS data, and the data identifier. The authorized read strategy of the data corresponding to the slice MOS metadata and the authorized write strategy of the data corresponding to the slice MOS metadata are signed as a transaction and broadcast to other blockchain nodes, and the data broadcast to other blockchain nodes after being signed as a transaction includes one or a combination of the following information:

15. The method of claim 14, wherein, The authorized read strategy and the authorized write strategy are signed as a transaction and broadcast to other blockchain nodes, and the authorized read strategy and the authorized write strategy transaction include the hash value of the slice ID, the public key of the application service provider of the slice, the public key of the operator of the slice, and the public key of the alliance member authorized to read the data corresponding to the slice MOS metadata of the slice. Further comprising: The node on the blockchain checks the format and signature of the received data. For metadata transactions, check whether there is a record containing the metadata identifier on the chain, if not, it is regarded as a record; if there is, it is determined whether the signature corresponds to the public key authorized to write, if yes, it is regarded as a record, if not, it is regarded as false data and discarded. For authorized read strategy and authorized write strategy transactions, it is judged whether the transaction signature corresponds to the public key of the application service provider and / or operator in the transaction, whether the public key corresponds to the signature of the record in which the slice identifier first appears in the blockchain, and if not, it is considered a false authorized strategy and the transaction is discarded, and if it is satisfied, it is taken as a record; The nodes on the blockchain use the consensus mechanism in the blockchain to encapsulate the records obtained within a period of time into a new block and broadcast and publish the block.

16. The method of claim 10, wherein, After the data request node issues a data viewing request, further comprising: The data request node accesses the alliance node to apply to view the slice MOS metadata stored on the blockchain, including: applying to read the hash value of the slice MOS metadata; or, finding the hash value of the slice network data or the hash value of the business MOS data through the data identifier; or, calling the smart contract to read the slice MOS metadata; The data request party applies to the data node for the slice MOS data corresponding to the data identifier according to the read data address; The data node reads the authorized read strategy for the slice MOS metadata from the blockchain through the alliance node to determine whether to send the slice MOS metadata to the data request party; The data request party verifies whether the obtained original data is correct according to the data hash in the read record.

17. The method of claim 12, wherein, The data node sends the slice MOS metadata to the alliance node, including: The data node collects and stores the slice MOS data used for model training; After processing the slice MOS data, the slice MOS metadata is generated, including: the hash value and / or storage address of the original slice MOS data; Send the metadata to the alliance node.

18. The method of claim 17, wherein, When the alliance node deploys the smart contract of the authorized read strategy of the data corresponding to the slice MOS metadata and the authorized write strategy and verification of the data corresponding to the slice MOS metadata to the blockchain: The alliance node calls the smart contract with the received slice MOS metadata and data identifier as parameters; The smart contract executes the write of the slice MOS metadata transaction, and the slice MOS metadata transaction written to the chain has one or a combination of the following data: Slice MOS data hash value, slice MOS data storage address, data identifier; Or, Hash value of slice network data, storage address of slice network data, data identifier; or Hash value of business MOS data, storage address of business MOS data, data identifier.

19. The method of claim 10, wherein, After the data request node issues a data viewing request, further comprising: The data request node accesses the alliance node to apply to view the slice MOS metadata stored on the blockchain, including: applying to read the hash value of the data corresponding to the slice MOS metadata; or, finding the hash value of the slice network data or the hash value of the business MOS data through the data identifier; or, calling the smart contract to read the slice MOS metadata; The data request party applies to the data node for the slice MOS data corresponding to the data identifier according to the read data address; or, the data request party carries a read permission flag in the application; If the verification of the read permission flag succeeds, the data node sends the original data to the requester; if the verification fails, the data node calls the smart contract through the alliance node to read the read permission membership for the original data from the blockchain, and determines whether to send the original data to the requester; The data requester verifies whether the obtained original data is correct according to the data hash in the read record.

20. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program for executing any one of the methods of claims 10 to 19.

Images