A mobile blockchain-based indoor location information management method
Patent Information
- Application Number
- CN202410005825.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-01-03
- Publication Date
- 2026-09-29
- Estimated Expiration
- 2044-01-03
AI Technical Summary
传统的室内位置信息管理方式是数据中心化集中处理,这种基于中心服务器的室内位置信息管理方法存在安全可靠传输、个人隐私泄露、位置信息篡改和计算存储负荷问题,严重影响了基于室内位置信息的各类个性化业务发展
[0047]第一,利用区块链的去中心化和不可篡改性,用户能够更好地掌控其位置信息,提升了隐私保护水平。同时,确保了模型参数在传输和存储过程中的安全性。第二,充分利用了边缘计算和区块链的分布式特性,用户可以在本地设备上进行模型训练,或者将任务卸载到MEC服务器上进行训练。这种分布式计算方式降低了对中心服务器的依赖,减少了通信开销,优化了资源利用,提高了系统的扩展性。第三,通过区块链智能合约建立了激励机制,奖励为网络贡献室内定位模型的用户。通过全局模型的共识更新机制,MEC服务器之间可以在本地聚合和共享模型,提高了模型的准确性和性能。这一激励机制激发了用户积极参与模型上传和更新,增强了系统的稳定性和鲁棒性。
Smart Images

Figure CN117956448B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of indoor positioning information management technology, and more specifically, to an indoor location information management method based on mobile blockchain. Background Technology
[0002] As 6G further promotes the development of personalized services, the demand for indoor positioning is becoming increasingly strong, resulting in a huge market size. In various industry application scenarios, such as museums, smart supermarkets, transportation hubs, enterprises, and medical institutions, location information is needed to provide services such as indoor navigation, exhibition services, employee attendance, and location monitoring of special groups. However, while the initiative for location services in these scenarios should ideally lie with the user, in reality, operators control user location information, necessitating respect for and protection of personal location privacy. Traditional indoor location information management methods rely on centralized data processing. This central server-based approach suffers from issues such as insecure and unreliable transmission, privacy breaches, location information tampering, and excessive computational and storage loads, severely impacting the development of various personalized services based on indoor location information.
[0003] 6G new services have increasingly stringent requirements for bandwidth, latency, and security, making the centralized deployment of traditional cloud computing insufficient. Edge computing can address the latency, congestion, and security issues of 6G networks by providing cloud computing and wireless network capabilities at the wireless network edge, with application services and content deployed locally at the edge. Blockchain technology aims to break the current transaction model that relies on centralized trust endorsements and is one of the most advanced trust technologies supporting 6G. It helps 6G address some shortcomings in underlying communication protocols, such as security attacks and privacy leaks, using cryptographic methods to provide technical support for decentralized transactions, privacy protection of transaction information, anti-tampering of historical records, and traceability of records. Against this backdrop, mobile blockchain, a technology that integrates edge computing and blockchain, is expected to overcome the problems of traditional centralized server-based indoor location information management methods, simultaneously complete the construction of a decentralized indoor location information management network, reserve secure and reliable core location information capabilities, and provide a new technological path for the future development of indoor location information management. Summary of the Invention
[0004] Purpose of the invention: To address the above problems, this invention proposes an indoor location information management method based on mobile blockchain. It fully utilizes the excellent low latency, decentralization, and tamper-proof characteristics of edge computing and blockchain to design a secure and efficient indoor location information management method, thereby promoting the rich development of various personalized services based on indoor location information.
[0005] Technical solution: To achieve the objectives of this invention, the technical solution adopted is as follows:
[0006] A method for managing indoor location information based on mobile blockchain, comprising the following steps:
[0007] Step 1: First, the user trains the indoor positioning model locally, or uninstalls it to the MEC server for training.
[0008] Step 2: The user uploads the parameters of the positioning model to the nearby MEC server via blockchain.
[0009] Step 3: Each MEC server aggregates its trained indoor positioning model and the local model uploaded by the user, and exchanges the aggregated models between MEC servers to achieve consensus updates of the global model among MEC servers.
[0010] Step 4: Randomly select an MEC server as the leader and broadcast the positioning model transactions.
[0011] Step 5: The user or MEC server, as a participating node, packages the location model transaction into an unverified block, which contains the global model parameters for indoor positioning achieved by all MEC servers; the user or MEC server, as a participating node, runs the block verification task.
[0012] Step 7: After receiving the unverified block, the first user to successfully verify it adds its block to the blockchain and uses the IPFS mechanism to store the block containing the indoor positioning model.
[0013] Step 8: The user downloads the verified block via IPFS and uses it for local location model synchronization.
[0014] Furthermore, the mobile blockchain architecture is a blockchain architecture based on edge computing, specifically as follows:
[0015] There are M MEC servers and N mobile users running indoor positioning applications. The sets of servers and users are represented as follows: and
[0016] There exist K global aggregation rounds of federated learning, denoted as...
[0017] In global aggregation round k, the offload association between user n and MEC server m is represented by binary variables. express, This means that user n is associated with MEC server m, that is, user n offloads the local indoor positioning model training task and block verification task to MEC server m; This indicates that user n and MEC server m have no offloading relationship; during the model training phase, the total central processing unit operation frequency for user n is:
[0018]
[0019] in This represents the local CPU frequency of user n. This indicates that user n borrows the CPU frequency of MEC server m; during the block verification phase, user n's total hash power is:
[0020]
[0021] in This represents the local hash power of user n. This indicates that user n borrows the hash power of MEC server m.
[0022] Furthermore, after the indoor positioning model training in step 1 is completed, the user uploads their local model parameters to a nearby MEC server via the blockchain; the smart contract on the blockchain records the model parameters uploaded by the user and designs a reward mechanism to reward users who contribute indoor positioning models to the network.
[0023] Each MEC server aggregates its trained indoor positioning model and the local model uploaded by the user; then the MEC servers exchange their aggregated indoor positioning models with each other through a blockchain-supported P2P communication link to achieve consensus updates of the global model among the MEC servers.
[0024] Furthermore, the FL method is adopted in indoor location information management to achieve collaborative learning among mobile users and build a global model from distributed data sources. There are N mobile users running indoor positioning applications, each with their own local dataset. In federated learning, the training process of the global model is divided into K rounds, and the steps in each round of training include:
[0025] (1) Global model initialization: Initially, the parameters w of the global model are initialized. (k) Initialized by the central server.
[0026] (2) Local model update: Each user calculates a local loss function using their own local data. And update the local model parameters.
[0027] (3) Local model aggregation: Each MEC server collects the local model parameters associated with itself and calculates their average or adopts other aggregation strategies to update the local model.
[0028] (4) Global Model Update: After each MEC server aggregates and updates its local model, it exchanges its local model with other MEC servers. The formula for updating the global model parameters is:
[0029]
[0030] in, These are global model parameters. These are some of the model parameters aggregated by the m-th MEC server.
[0031] (5) Repeated iteration: Repeat steps (1) to (4) until the stopping condition is met.
[0032] Furthermore, users can purchase hash calculation services through nearby MEC servers to run block verification tasks.
[0033] Furthermore, upon receiving an unverified block, the first user to successfully verify it adds their block to the blockchain and receives a reward; transactions for the indoor positioning model are executed by a smart contract that automatically verifies transactions and triggers the distribution of rewards to participating nodes; then the block containing the positioning model is stored using the IPFS mechanism; each user downloads the verified positioning model block via IPFS and uses it for local positioning model synchronization to begin the next round of model training.
[0034] Furthermore, the storage and retrieval process for location data based on the IPFS mechanism includes:
[0035] Location files are stored on each IoT node via the IPFS mechanism. The hash value of the location information is transmitted to the edge gateway, and after data integration, it is stored on the blockchain. The hash value after the transaction is stored on the cloud server.
[0036] Consumers of location services obtain the hash value after a location service transaction, retrieve and obtain the content hash value of the location information in the blockchain, the edge network transmits the content hash value to the cloud server, uses the content hash value to download and verify the file, and sends the file to the consumer of the location service.
[0037] Furthermore, in the global aggregation round k, the updated indoor positioning global model parameters are stored on IPFS and used as the starting point for the next round of local model training, by taking the following steps:
[0038] (1) Parameter format conversion: Convert the global model parameter w (k) Convert to a suitable file format for storage.
[0039] (2) Unique Content Identifier Generation: A unique content identifier (CID) is generated for the file using a cryptographic hash function.
[0040] CID k =IPFS_Store(w (k) )
[0041] CID k For the parameters w of the global model (k) The generated CID, IPFS_Store(·), is a function that publishes a file to the IPFS network and returns the CID.
[0042] (3) Storing files: The files are published to the IPFS network by splitting the files into blocks, creating a Merkle directed acyclic graph structure, and linking them using cryptographic hashes.
[0043] (4) File Recovery: After a file is added to the IPFS network, the CID is returned as a reference to the stored file. Nodes in the network use this CID to recover the file. The recovery process is described below:
[0044] CID k =IPFS_Retrieve(w (k) )
[0045] IPFS_Retrieve(·) is a function that restores the global model parameter file associated with a given CID.
[0046] Beneficial effects: Compared with the prior art, the technical solution of the present invention has the following beneficial technical effects:
[0047] First, leveraging the decentralization and immutability of blockchain, users gain greater control over their location information, enhancing privacy protection. Simultaneously, it ensures the security of model parameters during transmission and storage. Second, fully utilizing the distributed characteristics of edge computing and blockchain, users can train models on local devices or offload tasks to MEC servers. This distributed computing approach reduces reliance on central servers, minimizes communication overhead, optimizes resource utilization, and improves system scalability. Third, an incentive mechanism is established through blockchain smart contracts to reward users who contribute indoor positioning models to the network. Through a global model consensus update mechanism, MEC servers can aggregate and share models locally, improving model accuracy and performance. This incentive mechanism encourages active user participation in model uploading and updates, enhancing system stability and robustness. Attached Figure Description
[0048] Figure 1 This is a flowchart of the indoor location information management method based on mobile blockchain of the present invention.
[0049] Figure 2 This is a schematic diagram of a mobile blockchain architecture.
[0050] Figure 3 This is a diagram of an indoor location information management architecture based on mobile blockchain.
[0051] Figure 4 This is a flowchart of the data storage and query process of the IPFS mechanism. Detailed Implementation
[0052] The present invention will be further illustrated below with reference to the accompanying drawings and specific embodiments. It should be understood that these examples are only used to explain the present invention and to facilitate understanding, and are not intended to limit the scope of the present invention. After reading the present invention, any modifications made by those skilled in the art to the present invention in various equivalent forms shall fall within the scope defined by the appended claims.
[0053] The present invention discloses an indoor location information management method based on mobile blockchain, such as... Figure 1 As shown, the interaction process between users, MEC servers, and blockchain components includes the following steps:
[0054] Step 1: Indoor positioning task local training or unloading. First, the user trains the indoor positioning model locally, or unloads it to the MEC server for training.
[0055] like Figure 2 As shown, this invention provides a novel blockchain architecture based on edge computing, also known as a "mobile blockchain architecture." The mobile blockchain architecture mainly consists of resource-constrained IoT (Internet of Things) devices and MEC servers. Each IoT device can access the MEC server to enhance its ability to run indoor positioning tasks, compute hash puzzles, and store block content. By adding more participating nodes such as IoT devices, the robustness and security of the blockchain-based 6G network are naturally greatly improved.
[0056] Based on a mobile blockchain architecture, this invention proposes an indoor location information management method based on mobile blockchain, the architecture of which is as follows: Figure 3 As shown, the interaction between users, MEC servers, and blockchain components involves M servers and N mobile users running indoor positioning applications. The sets of servers and users are represented as follows: and There exist K global aggregation rounds of federated learning (FL), denoted as... In the global aggregation round k, the offloading association between user n and MEC server m can be represented by binary variables. To indicate, This means that user n is associated with MEC server m, that is, user n offloads the local indoor positioning model training task and block verification task to MEC server m. This indicates that user n and MEC server m have no uninstallation association.
[0057] During the model training phase, the total central processing unit (CPU) operating frequency for user n can be expressed as:
[0058]
[0059] in This represents the local CPU frequency of user n. This indicates that user n borrows the CPU frequency of MEC server m. Similarly, during the block verification phase, user n's total hash power can be expressed as:
[0060]
[0061] in This represents the local hash power of user n. This indicates that user n borrows the hash power of MEC server m.
[0062] Each mobile user can train indoor localization tasks locally using the datasets available on their device, such as location classification, location prediction, route planning, activity recognition, and user tracking. If a user's local computing resources are limited, they can offload the indoor localization tasks to a nearby MEC server for training.
[0063] The dataset used can include various types of data, depending on the nature and requirements of the localization task. Examples include Wi-Fi signal strength, map data, user location, and route tags. The actual data used will vary depending on the specific localization task.
[0064] Step 2: Local Positioning Model Upload. Users upload the parameters of their positioning model to a nearby MEC server via the blockchain. A smart contract on the blockchain records the uploaded model parameters and designs a mechanism to reward users who contribute indoor positioning models to the network.
[0065] Smart contracts are validated according to certain rules and conditions. If a user's upload meets specific contribution conditions (such as contribution rewards, task completion rewards, incentives for cooperation, etc.), the smart contract triggers the distribution of rewards.
[0066] Step 3: Location Model Aggregation and Consensus Update. Each MEC server aggregates its trained indoor location model and the local model uploaded by the user, and exchanges the aggregated models with each other to achieve global model consensus update among MEC servers.
[0067] Federated learning (FL) is a distributed machine learning method designed to build a global model from distributed data sources while protecting user privacy. In this invention, FL is applied to indoor location information management to enable collaborative learning among mobile users. There are N mobile users running indoor location applications, each with their own local dataset. In federated learning, the training process of the global model is divided into K rounds (called FL rounds). The steps in each round of training include:
[0068] (1) Global model initialization: Initially, the parameters w of the global model are initialized. (k) Initialized by the central server.
[0069] (2) Local model update: Each user calculates a local loss function using their own local data. And update the local model parameters.
[0070] (3) Local model aggregation: Each MEC server collects the local model parameters associated with itself and calculates their average or adopts other aggregation strategies to update the local model.
[0071] (4) Global Model Update: Each MEC server is responsible for aggregating a portion of the model and then exchanging its local model with other MEC servers. The formula for updating global model parameters can be expressed as:
[0072]
[0073] in, These are global model parameters. These are some of the model parameters aggregated by the m-th MEC server.
[0074] (5) Repeated iteration: Repeat steps (1) to (4) until the stopping condition is met.
[0075] The stopping conditions are set based on the training objectives, performance requirements, or computational resources. Several specific stopping conditions can be selected: 1) Reaching a predetermined global model performance: After each iteration, the performance of the global model on the validation or test set can be evaluated. If the global model's performance meets the predetermined standard, training stops. 2) Model parameter convergence: Changes in global model parameters can be monitored. If the changes in model parameters are small, it indicates that the model parameters have converged, and the training process can stop. 3) Reaching a set upper limit for training epochs: A maximum number of training epochs is preset. Training stops when this upper limit is reached. 4) Resource exhaustion: If computational, storage, or communication resources reach a preset upper limit, training can be stopped. 5) Meeting privacy or security conditions: Training can stop if privacy or security conditions are met during training. For example, reaching a certain level of user privacy protection. 6) Reaching a predetermined communication epoch: Federated learning typically involves communication between multiple participants. A predetermined communication epoch can be set, and training stops when this epoch is reached. 7) Other custom conditions: Depending on the specific application scenario and requirements, other custom stopping conditions can be defined.
[0076] Step 4: Positioning Model Transaction Broadcast. Based on the global model consensus update in Step 3, one MEC server will be randomly selected from multiple MEC servers to act as the leader and broadcast the positioning model transaction.
[0077] Transactions related to indoor positioning models refer to the transmission and recording of information related to indoor positioning models on the blockchain, including parameter information of the global model, consensus updates, and other model-related operations. Among these, the parameters of the global model are the most important information, including the parameters of the indoor positioning model jointly agreed upon by all MEC servers.
[0078] Step 5: Block Packaging. Participating nodes package the location model transactions into an unverified block. This block contains the global model parameters for indoor positioning achieved by all MEC servers. Users and MEC servers in the system can both act as participating nodes in the blockchain, witnessing the verification process of the location model.
[0079] This unverified block contains the aggregated model of user block verification and other transactions related to the location model. This block has not yet been verified by the entire blockchain network because its validity and consistency require confirmation through the consensus algorithm on the blockchain. Once this unverified block is verified through the consensus algorithm and receives unanimous approval from the network, it will be added to the blockchain, becoming a verified block containing the transaction information of the location model. In this way, the state of the entire blockchain is updated, and the transactions of the location model become valid and immutable.
[0080] Step 6: Block Verification. Users or MEC servers can act as participating nodes to run block verification tasks. Users can also purchase hash calculation services from nearby MEC servers to run block verification tasks.
[0081] Block verification refers to the process in a blockchain network where participating nodes create new blocks and add them to the blockchain by solving complex mathematical problems or performing specific computational tasks. Block verification is a consensus mechanism in a blockchain that ensures the validity, security, and consistency of transactions across the network. Different consensus mechanisms result in different block verification tasks.
[0082] The difference between users and MEC servers acting as participating nodes lies in the limitations and capabilities of their computing resources, which determines the types and scale of block verification tasks they are better suited to perform. User devices typically have relatively limited computing resources, making them more suitable for lightweight block verification tasks, such as verifying simple transactions or participating in consensus algorithms. When a user's local computing resources are limited, they can offload block verification tasks to an MEC server. MEC servers, on the other hand, typically have abundant computing resources, including processing power and storage capacity, making them more suitable for complex, computationally intensive block verification tasks, such as executing consensus algorithms and aggregating global models.
[0083] When the MEC server acts as a participating node, the reward for successful block verification is random and uncertain. However, when the MEC server receives a block verification task from a user, the reward is guaranteed. This demonstrates the rationale behind the "mobile blockchain" architecture, where both users and MEC can act as participating nodes.
[0084] Step 7: IPFS Storage. Upon receiving an unverified block, the first user or MEC server to successfully verify it adds the block to the blockchain and receives a reward. Transactions related to the indoor positioning model are executed by a smart contract, which automatically verifies transactions and triggers the distribution of rewards to participating nodes. The block containing the positioning model is then stored using the IPFS mechanism.
[0085] The unverified block is received by either the user or the MEC server, but the verification and addition to the blockchain, as well as subsequent reward and storage operations, are usually performed by the user (or MEC server) who successfully verifies it.
[0086] Step 8: Localization Model Update. Each user downloads the verified localization model block via IPFS and uses it for local localization model synchronization to begin the next round of model training.
[0087] The IPFS mechanism was introduced to address the shortcomings of blockchain itself, such as small block size and poor scalability, which cannot meet the high-precision positioning calculation and location data storage needs of multiple IoT nodes, thus providing reliable data for applications based on indoor location information. IPFS is a multi-node distributed file system that integrates ideas from traditional P2P systems, including distributed hash tables, the BitTorrent protocol, version control systems, and self-certifying file systems.
[0088] Indoor positioning information is stored on a cloud server based on the IPFS mechanism, using distributed hash tables and other structural components. The storage and retrieval process for location data was researched and designed, such as... Figure 4 As shown, the storage and query process of location data based on the IPFS mechanism includes: the location file is stored on each IoT node through the IPFS mechanism, the content hash value of the location information is transmitted to the edge gateway, and after data integration, it is stored on the blockchain. The hash value after the transaction is stored on the cloud server. The consumer of the location service obtains the hash value after the location service transaction, retrieves and obtains the content hash value of the location information in the blockchain, the edge network transmits the content hash value to the cloud server, uses the content hash value to download and verify the file, and sends the file to the consumer of the location service.
[0089] In global aggregation round k, to store the updated indoor positioning global model parameters on IPFS and use them as the starting point for the next round of local model training, the following steps can be taken:
[0090] (1) Parameter format conversion: Convert the global model parameter w (k) Convert to a suitable file format for storage (e.g., binary or serialized format).
[0091] (2) Unique Content Identifier Generation: A unique content identifier (CID) is generated for the file using a cryptographic hash function such as SHA-256. The stored procedure is represented as follows:
[0092] CID k =IPFS_Store(w (k) )
[0093] CID k For the parameters w of the global model (k) The generated CID, IPFS_Store(·), is a function that publishes a file to the IPFS network and returns the CID.
[0094] (3) Storing files: Publishing files to the IPFS network is accomplished by splitting the files into smaller chunks, creating a Merkle directed acyclic graph structure, and linking them using cryptographic hashes.
[0095] (4) File Recovery: Once a file is added to the IPFS network, the CID is returned as a reference to the stored file. Any node in the network can use this CID to recover the file. The recovery process is described below:
[0096] CID k =IPFS_Retrieve(w (k) )
[0097] IPFS_Retrieve(·) is a function that restores the global model parameter file associated with a given CID.
[0098] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the present invention is not limited to the above embodiments. Within the scope of knowledge possessed by those skilled in the art, various changes can be made without departing from the spirit of the present invention.
Claims
1. A method for managing indoor location information based on mobile blockchain, characterized in that the steps include... include: Step 1: First, the user trains the indoor positioning model locally, or offloads it to the MEC server for training; Step 2: The user uploads the location model parameters to a nearby MEC server via blockchain; Step 3: Each MEC server aggregates its trained indoor positioning model and the user-uploaded local model, and exchanges the aggregated models with each other to achieve consensus updates of the global model among MEC servers; Step 4: Randomly select one MEC server as the leader and broadcast the positioning model transactions; Step 5: The user or MEC server, as a participating node, packages the location model transaction into an unverified block, which contains the global model parameters for indoor positioning achieved by all MEC servers; Step 6: The user or MEC server runs the block verification task as a participating node; Step 7: Upon receiving an unverified block, the first user to successfully verify it adds their block to the blockchain, using the IPFS mechanism to store the block containing the indoor positioning model; Step 8: The user downloads the verified block via IPFS and uses it for local location model synchronization; the mobile blockchain architecture is based on edge computing, specifically: It has One MEC server and The set of mobile users, servers, and users running an indoor positioning application is represented as follows: and ; exist The global aggregation rounds of federated learning are represented as follows: ; In the global aggregation round In the middle, users and MEC server The uninstallation association between them is represented by binary variables. express, Refers to users and MEC server Related, meaning user n offloads the local indoor positioning model training task and block verification task to the MEC server. ; Indicates user and MEC server There is no uninstallation associated with it; during the model training phase, the user... The total central processing unit operating frequency is: , in Indicates user Local CPU frequency, Indicates user Borrowing MEC server CPU frequency; during the block verification phase, the user The total hash power is: , in Indicates user Local hashing power Indicates user Borrowing MEC server The hash computing power.
2. The indoor location information management method based on mobile blockchain according to claim 1, characterized in that, After the indoor positioning model training in step 1 is completed, the user uploads their local model parameters to a nearby MEC server via the blockchain; the smart contract on the blockchain records the model parameters uploaded by the user and designs a reward mechanism to reward users who contribute indoor positioning models to the network; each MEC server aggregates its trained indoor positioning model and the local model uploaded by the user; then the MEC servers exchange their aggregated indoor positioning models with each other through a blockchain-supported P2P communication link to achieve consensus updates of the global model among the MEC servers.
3. The indoor location information management method based on mobile blockchain according to claim 1, characterized in that, The FL method is used in indoor location information management to enable collaborative learning among mobile users and build a global model from distributed data sources. have A mobile user is running an indoor positioning application, and each user has their own local dataset; in federated learning, the training process of the global model is divided into... Each round of training consists of the following steps: (1) Global model initialization: Initially, the parameters of the global model are initialized. Initialized by the central server; (2) Local model update: Each user uses their own local data to calculate a local loss function. And update the local model parameters; (3) Local model aggregation: Each MEC server collects the local model parameters associated with itself and calculates their average to update the local model; (4) Global Model Update: After each MEC server aggregates and updates its local model, it exchanges its local model with other MEC servers. The formula for updating the global model parameters is: , in, These are global model parameters. It is the first Some model parameters aggregated from a single MEC server; (5) Repeated iteration: Repeat steps (1) to (4) until the stopping condition is met.
4. The indoor location information management method based on mobile blockchain according to claim 1, characterized in that, Users purchase hash calculation services through a nearby MEC server to run block verification tasks.
5. The indoor location information management method based on mobile blockchain according to claim 1, characterized in that, Upon receiving an unverified block, the first user to successfully verify it adds their block to the blockchain and receives a reward; transactions for the indoor positioning model are executed by a smart contract that automatically verifies transactions and triggers the distribution of rewards to participating nodes; then the block containing the positioning model is stored using the IPFS mechanism; each user downloads the verified positioning model block via IPFS and uses it for local positioning model synchronization to begin the next round of model training.
6. The indoor location information management method based on mobile blockchain according to claim 1, characterized in that, The storage and retrieval process for location data based on the IPFS mechanism includes: location files are stored on each IoT node via the IPFS mechanism; the content hash value of the location information is transmitted to the edge gateway; after data integration, it is stored on the blockchain; and the hash value after the transaction is stored on the cloud server. The consumer of the location service obtains the hash value after the location service transaction, retrieves and obtains the content hash value of the location information from the blockchain, the edge network transmits the content hash value to the cloud server, uses the content hash value to download and verify the file, and sends the file to the consumer of the location service.
7. The indoor location information management method based on mobile blockchain according to claim 5 or 6, characterized in that, In the global aggregation round In this process, the updated indoor positioning global model parameters are stored on IPFS and used as the starting point for the next round of local model training. The following steps are taken: (1) Parameter format conversion: Convert global model parameters Convert to a suitable file format for storage; (2) Unique Content Identifier Generation: A unique content identifier (CID) is generated for the file using a cryptographic hash function. , in Parameters of the global model The generated CID, This is a function that publishes a file to the IPFS network and returns its CID; (3) Storing files: Publishing files to the IPFS network is accomplished by splitting files into blocks, creating a Merkle directed acyclic graph structure, and linking them using cryptographic hashes; (4) File Recovery: After a file is added to the IPFS network, the CID will be returned as a reference to the stored file. Nodes in the network use this CID to recover the file. The recovery process is described below: , in It is a function that restores the global model parameter file associated with a given CID.
Citation Information
Patent Citations
Methods and systems for micropayment support to blockchain incentivized, decentralized data streaming and delivery
CA3149688A1
Indoor room-level positioning method based on block chain and mobile crowd sensing
CN111988844A