Low-altitude airspace usage recording method based on block chain

Abstract

The invention discloses a block chain-based low-altitude airspace usage recording method. The method comprises the steps of performing registration and authentication of an aircraft and an operator; carrying out flight plan declaration and auditing; recording flight data in real time; carrying out change processing on the flight plan; the emergency situation is handled; and sharing and querying airspace use information. Through distributed storage and a consensus mechanism, flight plans, real-time flight data and supervision operation cannot be tampered with an overground chain, and the authenticity, integrity and traceability of data are achieved.

Description

Technical Field

[0001] This invention belongs to the field of low-altitude airspace management technology, specifically relating to a blockchain-based method for recording low-altitude airspace usage. Background Technology

[0002] Current low-altitude airspace management technologies are mainly based on multi-source data fusion and intelligent decision-making system construction, including: (1) Dynamic airspace division: realize dynamic management of airspace grid through AI algorithm, support temporary airspace reservation and layered operation (logistics / emergency rescue / entertainment scenarios); (2) All-domain perception network: integrate radar array, ADS-B broadcast surveillance, 5G communication and Beidou high-precision positioning to build air-ground integrated monitoring capabilities; (3) Intelligent control platform: use digital twin technology to establish a three-dimensional city model space, and combine deep reinforcement learning to realize conflict prediction and autonomous avoidance strategy generation; (4) Communication and navigation system: cover low-altitude airspace through 5G private network, combine pseudo-satellite technology to solve the navigation blind spot problem in hilly and mountainous areas, and deploy edge computing nodes to realize real-time path replanning.

[0003] However, existing low-altitude airspace management technologies have the following shortcomings:

[0004] 1. Low data security and credibility: Most existing technical solutions adopt a centralized architecture, with data stored in a centralized server. In the event of hacker attacks, malicious tampering by internal personnel, or data loss, the authenticity and integrity of the data cannot be guaranteed, affecting incident investigation and accountability.

[0005] 2. Low information sharing and collaboration efficiency: There are barriers to data sharing among different management departments, aircraft operators and regulatory agencies, and information flow is not smooth, resulting in low collaboration efficiency and difficulty in achieving unified management across platforms and regions.

[0006] 3. High difficulty in supervision: Traditional supervision methods are difficult to achieve real-time and accurate monitoring and management of a large number of drones that are scattered and fly at high frequency, which can easily lead to blind spots in supervision.

[0007] 4. Insufficient protection of user privacy: Existing technical solutions may not be able to effectively protect users' flight data and other private information, posing a risk of leakage.

[0008] 5. Poor scalability: Existing centralized systems are ill-equipped to cope with the explosive growth in the number of drones in the future. Summary of the Invention

[0009] To address the shortcomings of the existing technologies, the present invention aims to provide a blockchain-based method for recording low-altitude airspace usage. Through distributed storage and consensus mechanisms, flight plans, real-time flight data, and regulatory operations are immutably recorded on the blockchain, thereby ensuring the authenticity, integrity, and traceability of the data.

[0010] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0011] The present invention provides a blockchain-based method for recording low-altitude airspace usage, comprising the following steps:

[0012] 1) Conduct aircraft and operator registration and certification;

[0013] 2) Conduct flight plan application and review;

[0014] 3) Real-time recording of flight data;

[0015] 4) Modify the flight plan;

[0016] 5) Handling emergency situations;

[0017] 6) To share and query airspace usage information.

[0018] Further, step 1) specifically includes:

[0019] 11) Conduct aircraft operator registration and certification;

[0020] 12) Register the aircraft;

[0021] 13) Perform key generation and management.

[0022] Further, step 11) specifically includes:

[0023] 111) Register operator accounts and complete real-name authentication;

[0024] 112) Upload your identity document and driver's license information;

[0025] 113) Assign a unique identifier to the operator.

[0026] Furthermore, step 12) specifically includes:

[0027] 121) Register aircraft information, including aircraft model, serial number, manufacturer, and hardware security module ID;

[0028] 122) Assign a unique identifier to the aircraft.

[0029] Furthermore, step 13) specifically includes:

[0030] 131) Use a secure random number generator to generate key pairs for data encryption and digital signature; store the operator's private key in the secure element of the client device or in a password-protected keystore, and store the aircraft's private key in the onboard hardware security module (HSM) to prevent physical tampering;

[0031] 132) Establish a key security process and solidify the process in a smart contract; after the key is generated, record the corresponding generated audit log (including timestamp, key ID, operator DID, operation type) and put it on the chain; periodically generate new key pairs and replace old keys, and old keys are marked as to be destroyed; perform secure erasure of the private key to be destroyed, record it in the destruction log and put it on the chain.

[0032] Furthermore, step 2) specifically includes:

[0033] 21) Submit the flight plan;

[0034] 22) Encrypt and sign the flight plan;

[0035] 23) Send the encrypted flight plan, digital signature, and operator / aircraft DID to the blockchain network;

[0036] 24) Smart contracts audit flight plans deployed on the blockchain;

[0037] 25) Process the audit results.

[0038] Furthermore, step 21) specifically includes:

[0039] 211) Submit flight plans through the client. Flight plans include: aircraft identification (DID), operator identification information (DID), takeoff time, landing time, flight route / flight area, maximum / minimum flight altitude, flight purpose, airspace type, contact information, and emergency contact information.

[0040] 212) The flight plan data format conforms to the FPL (Flight Plan) message structure, and all time fields are represented in Coordinated Universal Time (UTC).

[0041] Further, step 22) specifically includes:

[0042] 221) Use a hybrid encryption method to encrypt flight plans: use the AES-256 symmetric encryption algorithm to encrypt flight plan data, and then use the RSA-2048 or ECC asymmetric encryption algorithm to encrypt the AES key;

[0043] 222) Calculate the hash value of the encrypted flight plan using the SHA-256 or SHA-3 algorithm, and then digitally sign the hash value using the operator's private key (using the ECDSA or EdDSA algorithm).

[0044] AES-256 was chosen because of its high encryption speed and security, making it suitable for encrypting large amounts of data. RSA-2048 or ECC were chosen because of their good key management features, making them suitable for protecting symmetric keys.

[0045] Furthermore, step 24) specifically includes:

[0046] 241) Verify digital signature: Call the signature verification function verifySignature(verify signature) to verify the flight plan hash value using the operator's public key to ensure the source is authentic and the data is complete;

[0047] 242) Decrypt the flight plan: Call the plan decryption function decryptPlan(decrypt plan), use the supervisor node's private key to decrypt the AES session key, and then decrypt the flight plan text;

[0048] 243) Rule check: Execute the rule check function ruleCheck(rule check) to search and compare no-fly zones / restricted flight zones, flight altitude and speed, time intervals, route conflicts, weather conditions, aircraft performance and operator qualifications in sequence according to the preset airspace management rules;

[0049] 244) On-chain / off-chain data query: Access geographic information systems, meteorological and capacity databases to obtain the latest boundary and real-time weather information, and return the results to the smart contract;

[0050] 245) Risk Assessment: Call the risk assessment function riskEvaluate(risk assessment) to calculate the risk level RiskLevel based on altitude, speed, region, weather, aircraft type and operator level;

[0051] 246) Generate audit results: Analyze the verification results and risk levels. If all verifications pass and the risk level is less than or equal to the preset threshold, set the status to Pass; otherwise, set the status to Reject and record the Reject Code array RejectCode[].

[0052] 247) Evidence Storage and Event Broadcasting: Store {PlanID, Status, RiskLevel, RejectCode[], and TimeStamp} on the blockchain in the status tree, and trigger the FlightPlanReviewed event to push the review results to the client and the regulatory node.

[0053] Further, step 25) specifically includes:

[0054] 251) Clients and regulatory platforms obtain {plan number, status, risk level, array of rejection codes, and timestamp} by subscribing to approved flight plan events;

[0055] 252) State branch handling, as follows:

[0056] If the status is passed, then the following will be executed:

[0057] 2521) The smart contract stores the plan number in the on-chain valid flight plan table and marks it as effective;

[0058] 2522) Generate a unique flight permit token, containing the plan summary hash and validity period, and return it to the client and the aircraft.

[0059] 2523) Send the spatiotemporal block information to the airspace capacity management contract to update the remaining capacity in real time;

[0060] 2524) The message is pushed synchronously to each regulatory node, airspace service provider, and emergency response department via a message queue;

[0061] If the status is rejected, the following will be executed:

[0062] 2525) The smart contract records an array of rejection codes and stores the corresponding plan number in the on-chain rejection record table;

[0063] 2526) The reason for rejection (the corresponding rule clause or risk exceeding the limit) will be sent back to the client;

[0064] 2527) Allows operators to modify the plan based on the rejection code and resubmit, or choose to withdraw;

[0065] 2528) If rejected three times in a row, the smart contract triggers an abnormal operation alarm event and notifies the regulatory node to initiate manual review;

[0066] 253) All processing logs for both approved and rejected transactions (operator ID, node ID, timestamp, state change hash) are synchronously stored in the blockchain audit channel to ensure immutability;

[0067] 254) The smart contract returns a confirmation that processing is complete, and the client proceeds to the next step (flight preparation or plan re-compilation) based on the flight permit token or rejection information.

[0068] Furthermore, step 3) specifically includes:

[0069] 31) The flight data of the aircraft during flight is collected in real time by airborne equipment. The flight data includes: position information (WGS 84 coordinates, latitude and longitude), altitude information (relative to sea level), speed information, heading, attitude information (pitch angle, roll angle, yaw angle), timestamp, aircraft status (such as battery power, signal strength), ambient temperature, air humidity, atmospheric pressure, wind speed, wind direction, and magnetic field strength information.

[0070] 32) Encrypt and sign flight data;

[0071] 33) Upload the encrypted flight data, digital signature, timestamp, hash value, and aircraft DID to the blockchain network in real time or periodically;

[0072] 34) Verify the smart contract;

[0073] 35) Record the verified flight data on the blockchain and associate it with the flight plan ID.

[0074] Furthermore, step 32) specifically includes:

[0075] 321) The flight data is encrypted using the AES-256 symmetric encryption algorithm to ensure data confidentiality;

[0076] 322) Use the aircraft's private key to digitally sign the encrypted flight data (using ECDSA or EdDSA algorithms) to ensure the integrity of the data and the authenticity of its source;

[0077] 323) The SHA-256 algorithm is used to generate a hash value for the encrypted flight data at the aircraft end; then the {encrypted data packet, hash value, digital signature, timestamp, aircraft DID} is sent to the access gateway node of the blockchain network through the airborne communication link, and stored on the chain by the consensus node.

[0078] Furthermore, step 34) specifically includes:

[0079] 341) Use the aircraft's public key to verify digital signatures to ensure the authenticity and integrity of the data source;

[0080] 342) Use Network Time Protocol or GPS time as the time synchronization source to keep the spacecraft and the blockchain network in sync;

[0081] 343) Recalculate the hash value of the flight data and compare it with the uploaded hash value to ensure that the data has not been tampered with during transmission;

[0082] 344) Compare the real-time location information uploaded by the aircraft with the predetermined route in the flight plan, calculate the deviation distance between the two, and if the deviation distance exceeds the preset threshold, it is determined to be a deviation from the route; and compare the altitude information uploaded by the aircraft with the altitude limit in the flight plan. If it exceeds the limit altitude, it is determined to be over-altitude flight.

[0083] Furthermore, step 4) specifically includes:

[0084] 41) Submit a change request through the client. The change request includes: flight plan ID, change type (modification or cancellation), change content (such as new flight route, new departure time, etc.) and digital signature;

[0085] 42) Review the change request;

[0086] 43) Process the changes.

[0087] Further, step 42) specifically includes:

[0088] 421) Digital signature verification;

[0089] Call the signature verification function to verify the hash value in the change request using the applicant's public key; if the verification fails, immediately return that the signature is invalid and end the process.

[0090] 422) Compliance checks;

[0091] Time window rules: Acceptance is permitted only for changes that are within the maximum allowable lead time from the scheduled departure time, for changes that are within the safe buffer threshold for the planned landing time during flight, or for emergency changes authorized by regulatory agencies; changes exceeding the window limit will be rejected outright.

[0092] Conflict and capacity review: Re-execute route spatiotemporal conflict detection, cross-search of restricted and prohibited flight zones, and airspace capacity calculation to ensure that airspace management rules are still met after the changes;

[0093] Change count limit: Read the change count of the flight plan from the chain; if the change count has reached the maximum number of changes (e.g., 3 times), mark it as exceeded and reject it; otherwise, increment the count and store it on the chain;

[0094] 423) Generate audit conclusion;

[0095] Set the status based on the results of steps 421) and 422). If both steps 421) and 422) are passed, set the status to "Change Passed"; otherwise, set the status to "Change Rejected" and record the array of rejection reason codes.

[0096] Store {Plan Number, Change Number, Status, Rejection Reason Code Array, Timestamp} in the blockchain as a transaction;

[0097] The broadcast of the flight plan change review completion event pushes the review results to the client, regulatory platform and relevant airspace service nodes.

[0098] Further, step 43) specifically includes:

[0099] 431) When the status is "Change Approved", execute the following:

[0100] In the smart contract, call the update plan record method to store the changed flight plan fields into the valid flight plan table on the chain;

[0101] The original flight plan record is marked as cancelled and stored in the historical plan table along with the verification hash;

[0102] Synchronously update the airspace capacity database and replace the spatiotemporal block information occupied by the old plan;

[0103] The broadcast flight plan has been updated, notifying the aircraft, monitoring platform, and relevant airspace service nodes.

[0104] 432) When the status is "Change Rejected", execute the following:

[0105] Call the rejection notification method to send {plan number, array of rejection reason codes, timestamp} to the client;

[0106] Add a rejection log entry to the rejection record table on the chain, which includes the signature verification hash and the audit node identifier;

[0107] When the number of rejections reaches the threshold N, an abnormal change behavior alarm event is triggered and pushed to the regulatory node.

[0108] Furthermore, step 5) specifically includes:

[0109] 51) Report emergency events encountered by the aircraft during flight via onboard equipment or manual triggering. Emergency event information includes: event type, time, location, aircraft status, and digital signature.

[0110] 52) Encrypt emergency information and prioritize its uploading to the blockchain network, specifically including:

[0111] Temporarily add consensus nodes: Pre-designate a set of backup consensus nodes, and in case of emergency, the smart contract will add the backup consensus nodes to the consensus process;

[0112] Lowering consensus requirements: Smart contracts temporarily reduce the proportion of nodes required to reach consensus (e.g., from 2 / 3 to 1 / 2), striking a balance between security and efficiency;

[0113] Using multiple communication channels: Emergency information is uploaded simultaneously through multiple channels including 4G, 5G, and satellite communication, and the smart contract selects the first valid data received;

[0114] 53) Smart contract responses, specifically including:

[0115] 531) Trigger the alarm immediately;

[0116] 532) Push signed emergency alert information to relevant parties, including regulatory agencies, emergency response departments, and aircraft operators;

[0117] 533) Coordinate with other aircraft to avoid the emergency based on its type and location;

[0118] 54) Handling false alarms: If the emergency is confirmed to be a false alarm in the event of an incident, the operator or regulatory authority shall initiate a request to cancel the emergency status through the client; after verifying the legality of the request, the alarm shall be canceled and the relevant aircraft shall be restored to normal status.

[0119] Furthermore, step 6) specifically includes:

[0120] 61) Initiate a query request as follows:

[0121] 611) Identity authentication;

[0122] Applicable users: Regulatory agencies, airspace management authorities, licensed aircraft operators, and permitted public users;

[0123] Users submit digital certificates or account credentials through the client, and the smart contract verifies their authenticity and returns their assigned role identifier.

[0124] 612) Assemble and sign the query message;

[0125] The message structure is {query number, query type, query condition, timestamp, random number};

[0126] Query types include flight plans, real-time flight data, historical flight paths, and airspace capacity statistics;

[0127] The query criteria include flight plan number, aircraft identifier, time interval, geographical range (polygon), and status filtering;

[0128] After generating a digital signature using the user's private key, the client sends it to the blockchain access node via a TLS channel;

[0129] 62) Access control and auditing, as follows:

[0130] 621) Role-based access control;

[0131] Predefined roles: system administrator, supervisor, operator, and the public;

[0132] Each role is associated with a corresponding set of resource accesses and sets of operations;

[0133] 622) Access control list maintenance;

[0134] Smart contracts store triples of <user / role→resource→operation>.

[0135] Supports dynamic adjustments to on-chain proposals and voting;

[0136] 623) Data hierarchy and the principle of least privilege;

[0137] Data classification: publicly visible, restricted visible, and confidential;

[0138] Query results must be filtered and anonymized at the field level to ensure that users can only obtain data that matches their role;

[0139] 624) Authority decision-making and execution;

[0140] Smart contract comparison query messages and access control lists;

[0141] If permissions are insufficient, immediately return "Access denied" and terminate the query;

[0142] 625) Operational audit;

[0143] Generate audit entries {operator, timestamp, operation type, object, result, hash} for user login, query requests, and authorization change operations;

[0144] Audit entries are immediately stored in the blockchain audit log table to ensure immutability and traceability;

[0145] 63) Query execution and result return are as follows:

[0146] 631) Data retrieval;

[0147] The smart contract retrieves the target record by calling the on-chain state database or accessing off-chain storage through an oracle, based on the query type and conditions.

[0148] 632) Result processing;

[0149] Desensitize or crop fields that exceed the authorization level;

[0150] Generate a result set and append a data digest hash and a response timestamp;

[0151] 633) Result Signature and Return;

[0152] The node signs the result set using its own private key;

[0153] The data is returned to the client via the original communication channel, and the client verifies the node signature and data digest before displaying it.

[0154] 634) Confirmation complete;

[0155] The smart contract sends a query completion confirmation message to the querier and marks the query transaction status as completed in the audit log.

[0156] The beneficial effects of this invention are:

[0157] (1) Enhance data security: Utilize the immutability of blockchain to ensure the authenticity and integrity of key information such as flight plans and flight data, and prevent data from being maliciously tampered with or lost; adopt encryption and digital signature technologies to protect the security of data during transmission and storage.

[0158] (2) Improve information transparency and sharing efficiency: Data on the blockchain is open and transparent to authorized users, which promotes information sharing and collaboration; it reduces intermediate links in information transmission and improves the efficiency of information sharing.

[0159] (3) Enhanced regulatory capabilities: Real-time and precise monitoring of low-altitude aircraft, timely detection and handling of violations; provision of traceable flight records to facilitate accident investigation and accountability. Compared with traditional UTM systems, this invention has better interoperability and scalability, enabling cross-platform and cross-regional collaborative management, improving regulatory efficiency and the detection rate of illegal flights.

[0160] (4) Enhance privacy protection: Adopt advanced privacy protection technology to protect user privacy such as flight data while achieving information sharing.

[0161] (5) Reduced management costs: The decentralized management model reduces the dependence on centralized servers and reduces costs in hardware procurement, data center construction, system maintenance, network security protection, etc.; automated processes reduce manual intervention and lower labor costs.

[0162] (6) Improve system reliability and stability: The decentralized architecture avoids the risk of single point of failure and improves system reliability; distributed storage and consensus mechanism ensure data consistency and availability.

[0163] (7) Promote multi-party collaboration: It provides a unified platform for different management departments, aircraft operators, regulatory agencies, etc., and promotes multi-party collaboration. Attached Figure Description

[0164] Figure 1 This is a flowchart illustrating the principle of the method of the present invention. Detailed Implementation

[0165] To facilitate understanding by those skilled in the art, the present invention will be further described below with reference to embodiments and accompanying drawings. The content mentioned in the embodiments is not intended to limit the present invention.

[0166] Reference Figure 1 As shown, the present invention provides a blockchain-based method for recording low-altitude airspace usage, comprising the following steps:

[0167] 1) Conduct aircraft and operator registration and certification; specifically including:

[0168] 11) Conduct aircraft operator registration and certification;

[0169] 12) Register the aircraft;

[0170] 13) Perform key generation and management.

[0171] Specifically, step 11) includes:

[0172] 111) Register operator accounts and complete real-name authentication;

[0173] 112) Upload identification documents (such as ID card, passport) and driver's license information;

[0174] 113) Assign a unique identifier to the operator (such as a blockchain-based DID, a decentralized identifier).

[0175] Specifically, step 12) includes:

[0176] 121) Register aircraft information, including aircraft model, serial number, manufacturer, and hardware security module ID;

[0177] 122) Assign a unique identifier to the aircraft (such as a blockchain-based DID).

[0178] Specifically, step 13) includes:

[0179] 131) Use a secure random number generator to generate key pairs (public and private keys) for data encryption and digital signature; store the operator's private key in a secure element (such as a Secure Element) or a password-protected keystore on the client device, and store the aircraft's private key in the onboard hardware security module (HSM) to prevent physical tampering;

[0180] 132) Establish a key security process and solidify the process in a smart contract; after the key is generated, record the corresponding generated audit log (including timestamp, key ID, operator DID, operation type) and put it on the chain; periodically generate new key pairs and replace old keys, and old keys are marked as to be destroyed; perform secure erasure of the private key to be destroyed, record it in the destruction log and put it on the chain;

[0181] 2) Conduct flight plan application and review; specifically including:

[0182] 21) Submit the flight plan;

[0183] 22) Encrypt and sign the flight plan;

[0184] 23) Send the encrypted flight plan, digital signature, and operator / aircraft DID to the blockchain network;

[0185] 24) Smart contracts audit flight plans deployed on the blockchain;

[0186] 25) Process the audit results.

[0187] Specifically, step 21) includes:

[0188] 211) Submit flight plans via a client (such as a smartphone app or web application). Flight plans include: aircraft identification (DID), operator identification information (DID), takeoff time, landing time, flight route / flight area, maximum / minimum flight altitude, flight purpose, airspace type, contact information, and emergency contact information.

[0189] 212) The flight plan data format conforms to the FPL (Flight Plan) message structure, and all time fields are represented in Coordinated Universal Time (UTC).

[0190] Specifically, step 22) includes:

[0191] 221) Use a hybrid encryption method to encrypt flight plans: use the AES-256 symmetric encryption algorithm to encrypt flight plan data, and then use the RSA-2048 or ECC asymmetric encryption algorithm to encrypt the AES key;

[0192] 222) Calculate the hash value of the encrypted flight plan using the SHA-256 or SHA-3 algorithm, and then digitally sign the hash value using the operator's private key (using the ECDSA or EdDSA algorithm).

[0193] AES-256 was chosen because of its high encryption speed and security, making it suitable for encrypting large amounts of data. RSA-2048 or ECC were chosen because of their good key management features, making them suitable for protecting symmetric keys.

[0194] Specifically, step 24) includes:

[0195] 241) Verify digital signature: Call the signature verification function verifySignature(verify signature) to verify the flight plan hash value using the operator's public key to ensure the source is authentic and the data is complete;

[0196] 242) Decrypt the flight plan: Call the plan decryption function decryptPlan(decrypt plan), use the supervisor node's private key to decrypt the AES session key, and then decrypt the flight plan text;

[0197] 243) Rule check: Execute the rule check function ruleCheck(rule check) to search and compare no-fly zones / restricted flight zones, flight altitude and speed, time intervals, route conflicts, weather conditions, aircraft performance and operator qualifications in sequence according to the preset airspace management rules;

[0198] 244) On-chain / off-chain data query: Access Geographic Information System (GIS), meteorological and capacity databases, obtain the latest boundary and real-time meteorological information, and return the results to the smart contract;

[0199] 245) Risk Assessment: Call the risk assessment function riskEvaluate(risk assessment) to calculate the risk level RiskLevel based on altitude, speed, region, weather, aircraft type and operator level;

[0200] 246) Generate audit results: Analyze the verification results and risk levels. If all verifications pass and the risk level is less than or equal to the preset threshold, set the status to Pass; otherwise, set the status to Reject and record the Reject Code array RejectCode[].

[0201] 247) Evidence Storage and Event Broadcasting: Store {PlanID, Status, RiskLevel, RejectCode[], and TimeStamp} on the blockchain in the status tree, and trigger the FlightPlanReviewed event to push the review results to the client and the regulatory node.

[0202] Specifically, step 25) includes:

[0203] 251) Clients and regulatory platforms obtain {plan number, status, risk level, array of rejection codes, and timestamp} by subscribing to approved flight plan events;

[0204] 252) State branch handling, as follows:

[0205] If the status is passed, then the following will be executed:

[0206] 2521) The smart contract stores the plan number in the on-chain valid flight plan table and marks it as effective;

[0207] 2522) Generate a unique flight permit token (PlanToken) containing a plan summary hash and validity period, and return it to the client and the aircraft.

[0208] 2523) Send the spatiotemporal block information to the airspace capacity management contract to update the remaining capacity in real time;

[0209] 2524) The message is pushed synchronously to each regulatory node, airspace service provider, and emergency response department via a message queue;

[0210] If the status is rejected, the following will be executed:

[0211] 2525) The smart contract records an array of rejection codes and stores the corresponding plan number in the on-chain rejection record table;

[0212] 2526) The reason for rejection (the corresponding rule clause or risk exceeding the limit) will be sent back to the client;

[0213] 2527) Allows operators to modify the plan based on the rejection code and resubmit, or choose to withdraw;

[0214] 2528) If rejected three times in a row, the smart contract triggers an abnormal operation alarm event and notifies the regulatory node to initiate manual review;

[0215] 253) All processing logs for both approved and rejected transactions (operator ID, node ID, timestamp, state change hash) are synchronously stored in the blockchain audit channel to ensure immutability;

[0216] 254) The smart contract returns a confirmation that processing is complete, and the client proceeds to the next step (flight preparation or plan re-compilation) based on the flight permit token or rejection information.

[0217] 3) Real-time recording of flight data; specifically including:

[0218] 31) The flight data of the aircraft during flight is collected in real time through airborne equipment (such as GPS, RTK GPS, inertial navigation system, barometer, communication module, hardware security module, etc.). The flight data includes: position information (WGS 84 coordinates, latitude and longitude), altitude information (relative to sea level), speed information, heading, attitude information (pitch angle, roll angle, yaw angle), timestamp, aircraft status (such as battery power, signal strength), ambient temperature, air humidity, atmospheric pressure, wind speed, wind direction, and magnetic field strength information.

[0219] 32) Encrypt and sign flight data;

[0220] 33) Upload the encrypted flight data, digital signature, timestamp, hash value and aircraft DID to the blockchain network in real time or periodically (critical data such as position, altitude and speed once per second, non-critical data once every 5-10 seconds, or dynamically adjusted according to network conditions and aircraft type);

[0221] 34) Verify the smart contract;

[0222] 35) Record the verified flight data on the blockchain and associate it with the flight plan ID.

[0223] Specifically, step 32) includes:

[0224] 321) The flight data is encrypted using the AES-256 symmetric encryption algorithm to ensure data confidentiality;

[0225] 322) Use the aircraft's private key to digitally sign the encrypted flight data (using ECDSA or EdDSA algorithms) to ensure the integrity of the data and the authenticity of its source;

[0226] 323) The SHA-256 algorithm is used to generate a hash value for the encrypted flight data at the aircraft end; then the {encrypted data packet, hash value, digital signature, timestamp, aircraft DID} is sent to the access gateway node of the blockchain network through the airborne communication link (4G / 5G, dedicated VHF or satellite link), and stored on the chain by the consensus node.

[0227] Specifically, step 34) includes:

[0228] 341) Use the aircraft's public key to verify digital signatures to ensure the authenticity and integrity of the data source;

[0229] 342) Use Network Time Protocol (NTP) or GPS time as the time synchronization source to keep the aircraft and the blockchain network in sync;

[0230] 343) Recalculate the hash value of the flight data and compare it with the uploaded hash value to ensure that the data has not been tampered with during transmission;

[0231] 344) Compare the real-time location information uploaded by the aircraft with the predetermined route in the flight plan, calculate the deviation distance between the two, and if the deviation distance exceeds the preset threshold (e.g., 100 meters), it is determined to be a deviation from the route; and compare the altitude information uploaded by the aircraft with the altitude limit in the flight plan. If it exceeds the limit altitude, it is determined to be an over-altitude flight.

[0232] 4) Modify the flight plan; specifically including:

[0233] 41) Submit a change request through the client. The change request includes: flight plan ID, change type (modification or cancellation), change content (such as new flight route, new departure time, etc.) and digital signature;

[0234] 42) Review the change request;

[0235] 43) Process the changes.

[0236] Specifically, step 42) includes:

[0237] 421) Digital signature verification;

[0238] Call the signature verification function to verify the hash value in the change request using the applicant's (operator or supervisor's) public key; if the verification fails, immediately return that the signature is invalid and end the process.

[0239] 422) Compliance checks;

[0240] Time window rules: Acceptance is permitted only for changes that are within the maximum allowable lead time from the scheduled departure time, for changes that are within the safe buffer threshold for the planned landing time during flight, or for emergency changes authorized by regulatory agencies; changes exceeding the window limit will be rejected outright.

[0241] Conflict and capacity review: Re-execute route spatiotemporal conflict detection, cross-search of restricted and prohibited flight zones, and airspace capacity calculation to ensure that airspace management rules are still met after the changes;

[0242] Change count limit: Read the change count of the flight plan from the chain; if the change count has reached the maximum number of changes (e.g., 3 times), mark it as exceeded and reject it; otherwise, increment the count and store it on the chain;

[0243] 423) Generate audit conclusion;

[0244] Set the status based on the results of steps 421) and 422). If both steps 421) and 422) are passed, set the status to "Change Passed"; otherwise, set the status to "Change Rejected" and record the array of rejection reason codes.

[0245] Store {Plan Number, Change Number, Status, Rejection Reason Code Array, Timestamp} in the blockchain as a transaction;

[0246] The broadcast of the flight plan change review completion event pushes the review results to the client, regulatory platform and relevant airspace service nodes.

[0247] Specifically, step 43) includes:

[0248] 431) When the status is "Change Approved", execute the following:

[0249] In the smart contract, call the update plan record method to store the changed flight plan fields into the valid flight plan table on the chain;

[0250] The original flight plan record is marked as cancelled and stored in the historical plan table along with the verification hash;

[0251] Synchronously update the airspace capacity database and replace the spatiotemporal block information occupied by the old plan;

[0252] The broadcast flight plan has been updated, notifying the aircraft, monitoring platform, and relevant airspace service nodes.

[0253] 432) When the status is "Change Rejected", execute the following:

[0254] Call the rejection notification method to send {plan number, array of rejection reason codes, timestamp} to the client;

[0255] Add a rejection log entry to the rejection record table on the chain, which includes the signature verification hash and the audit node identifier;

[0256] When the number of rejections reaches the threshold N (3 times), an abnormal change behavior alarm event is triggered and pushed to the regulatory node.

[0257] 5) Handling emergency situations; specifically including:

[0258] 51) Report emergency events encountered by the aircraft during flight via onboard equipment or manual triggering. Emergency event information includes: event type, time, location, aircraft status, and digital signature.

[0259] 52) Encrypt emergency information and prioritize its uploading to the blockchain network, specifically including:

[0260] Temporarily add consensus nodes: Pre-designate a set of backup consensus nodes, and in case of emergency, the smart contract will add the backup consensus nodes to the consensus process;

[0261] Lowering consensus requirements: Smart contracts temporarily reduce the proportion of nodes required to reach consensus (e.g., from 2 / 3 to 1 / 2), striking a balance between security and efficiency;

[0262] Using multiple communication channels: Emergency information is uploaded simultaneously through multiple channels including 4G, 5G, and satellite communication, and the smart contract selects the first valid data received;

[0263] 53) Smart contract responses, specifically including:

[0264] 531) Trigger the alarm immediately;

[0265] 532) Push signed emergency event alarm information (including key fields such as event type, risk level, aircraft identification, spatiotemporal coordinates, etc.) to relevant parties, including regulatory agencies, emergency rescue departments and aircraft operators;

[0266] 533) Coordinate with other aircraft to avoid the emergency based on its type and location (e.g., modify the flight plans of other aircraft);

[0267] 54) Handling false alarms: If the emergency is confirmed to be a false alarm in the event of an incident, the operator or regulatory authority shall initiate a request to cancel the emergency status through the client; after verifying the legality of the request, the alarm shall be canceled and the relevant aircraft shall be restored to normal status.

[0268] 6) To share and query airspace usage information; specifically including:

[0269] 61) Initiate a query request as follows:

[0270] 611) Identity authentication;

[0271] Applicable users: Regulatory agencies, airspace management authorities, licensed aircraft operators, and permitted public users;

[0272] Users submit digital certificates or account credentials through the client, and the smart contract verifies their authenticity and returns their assigned role identifier.

[0273] 612) Assemble and sign the query message;

[0274] The message structure is {query number, query type, query condition, timestamp, random number};

[0275] Query types include flight plans, real-time flight data, historical flight paths, and airspace capacity statistics;

[0276] The query criteria include flight plan number, aircraft identifier, time interval, geographical range (polygon), and status filtering;

[0277] After generating a digital signature using the user's private key, the client sends it to the blockchain access node via a TLS channel;

[0278] 62) Access control and auditing, as follows:

[0279] 621) Role-based access control (RBAC);

[0280] Predefined roles: system administrator, supervisor, operator, and the public;

[0281] Each role is associated with a corresponding set of resource accesses and sets of operations;

[0282] 622) Access Control List (ACL) maintenance;

[0283] Smart contracts store triples of <user / role→resource→operation>.

[0284] Supports dynamic adjustments to on-chain proposals and voting;

[0285] 623) Data hierarchy and the principle of least privilege;

[0286] Data classification: publicly visible, restricted visible, and confidential;

[0287] Query results must be filtered and anonymized at the field level to ensure that users can only obtain data that matches their role;

[0288] 624) Authority decision-making and execution;

[0289] Smart contract comparison query messages and access control lists;

[0290] If permissions are insufficient, immediately return "Access denied" and terminate the query;

[0291] 625) Operational audit;

[0292] Generate audit entries {operator, timestamp, operation type, object, result, hash} for user login, query requests, and authorization change operations;

[0293] Audit entries are immediately stored in the blockchain audit log table to ensure immutability and traceability;

[0294] 63) Query execution and result return are as follows:

[0295] 631) Data retrieval;

[0296] The smart contract retrieves the target record by calling the on-chain state database or accessing off-chain storage through an oracle, based on the query type and conditions.

[0297] 632) Result processing;

[0298] Desensitize or crop fields that exceed the authorization level;

[0299] Generate a result set and append a data digest hash and a response timestamp;

[0300] 633) Result Signature and Return;

[0301] The node signs the result set using its own private key;

[0302] The data is returned to the client via the original communication channel, and the client verifies the node signature and data digest before displaying it.

[0303] 634) Confirmation complete;

[0304] The smart contract sends a query completion confirmation message to the querier and marks the query transaction status as completed in the audit log.

[0305] This invention has many specific applications. The above description is only a preferred embodiment of this invention. It should be noted that for those skilled in the art, several improvements can be made without departing from the principle of this invention, and these improvements should also be considered within the scope of protection of this invention.

Claims

1. A blockchain-based method for recording low-altitude airspace usage, characterized in that, The steps are as follows: 1) Register and certify the aircraft and operators; 2) Conduct flight plan application and review; 3) Real-time recording of flight data; 4) Modify the flight plan; 5) Handling emergency situations; 6) To share and query airspace usage information.

2. The blockchain-based low-altitude airspace usage recording method according to claim 1, characterized in that, Step 1) specifically includes: 11) Conduct aircraft operator registration and certification; 12) Register the aircraft; 13) Perform key generation and management.

3. The blockchain-based low-altitude airspace usage recording method according to claim 2, characterized in that, Step 13) specifically includes: 131) Use a secure random number generator to generate key pairs for data encryption and digital signature; store the operator's private key in the secure element of the client device or in a password-protected key store, and store the aircraft's private key in the onboard hardware security module to prevent physical tampering; 132) Establish a key security process and solidify the process in a smart contract; after the key is generated, record the corresponding generated audit log and put it on the chain; periodically generate new key pairs and replace old keys, and old keys are marked as to be destroyed; perform secure erasure of the private keys to be destroyed, record them in the destruction log and put them on the chain.

4. The blockchain-based low-altitude airspace usage recording method according to claim 1, characterized in that, Step 2) specifically includes: 21) Submit a flight plan; 22) Encrypt and sign the flight plan; 23) Send the encrypted flight plan, digital signature, and operator / aircraft DID to the blockchain network; 24) Smart contracts audit flight plans deployed on the blockchain; 25) Process the audit results.

5. The blockchain-based low-altitude airspace usage recording method according to claim 4, characterized in that, Step 24) specifically includes: 241) Verify digital signature: Call the signature verification function verifySignature and use the operator's public key to verify the flight plan hash value to ensure the source is authentic and the data is complete; 242) Decrypt the flight plan: Call the plan decryption function decryptPlan, use the supervisor node's private key to decrypt the AES session key, and then decrypt the flight plan text; 243) Rule check: Execute the rule check function ruleCheck to sequentially search and compare no-fly zones / restricted flight zones, flight altitude and speed, time intervals, route conflicts, weather conditions, aircraft performance, and operator qualifications according to the preset airspace management rules; 244) On-chain / off-chain data query: Access geographic information systems, meteorological and capacity databases to obtain the latest boundary and real-time weather information, and return the results to the smart contract; 245) Risk Assessment: Call the risk assessment function riskEvaluate to calculate the risk level RiskLevel based on altitude, speed, region, weather, aircraft type, and operator level; 246) Generate audit results: Analyze the verification results and risk levels. If all verifications pass and the risk level is less than or equal to the preset threshold, set the status to Pass; otherwise, set the status to Reject and record the Reject Code array RejectCode[]. 247) Evidence Storage and Event Broadcasting: Store {PlanID, Status, RiskLevel, RejectCode[], and TimeStamp} on the blockchain in the status tree, and trigger the FlightPlanReviewed event to push the review results to the client and the regulatory node.

6. The blockchain-based low-altitude airspace usage recording method according to claim 1, characterized in that, Step 3) specifically includes: 31) Real-time flight data of the aircraft during flight is collected through airborne equipment. The flight data includes: position information, altitude information, speed information, heading, attitude information, timestamp, aircraft status, ambient temperature, air humidity, atmospheric pressure, wind speed, wind direction and magnetic field strength information. 32) Encrypt and sign flight data; 33) Upload the encrypted flight data, digital signature, timestamp, hash value, and aircraft DID to the blockchain network in real time or periodically; 34) Verify the smart contract; 35) Record the verified flight data on the blockchain and associate it with the flight plan ID.

7. The blockchain-based low-altitude airspace usage recording method according to claim 6, characterized in that, Step 34) specifically includes: 341) Use the aircraft's public key to verify digital signatures to ensure the authenticity and integrity of the data source; 342) Use Network Time Protocol or GPS time as the time synchronization source to keep the spacecraft and the blockchain network in sync; 343) Recalculate the hash value of the flight data and compare it with the uploaded hash value to ensure that the data has not been tampered with during transmission; 344) Compare the real-time location information uploaded by the aircraft with the predetermined route in the flight plan, calculate the deviation distance between the two, and if the deviation distance exceeds the preset threshold, it is determined to be a deviation from the route; and compare the altitude information uploaded by the aircraft with the altitude limit in the flight plan. If it exceeds the limit altitude, it is determined to be over-altitude flight.

8. The blockchain-based low-altitude airspace usage recording method according to claim 1, characterized in that, Step 4) specifically includes: 41) Submit a change request through the client. The change request includes: Flight Plan ID, Change Type, Change Content, and Digital Signature; 42) Review the change request; 43) Process the changes.

9. The blockchain-based low-altitude airspace usage recording method according to claim 1, characterized in that, Step 5) specifically includes: 51) Report emergency events encountered by the aircraft during flight via onboard equipment or manual triggering. Emergency event information includes: event type, time, location, aircraft status, and digital signature. 52) Encrypt emergency information and prioritize its uploading to the blockchain network, specifically including: Temporarily add consensus nodes: Pre-designate a set of backup consensus nodes, and in case of emergency, the smart contract will add the backup consensus nodes to the consensus process; Lowering consensus requirements: Smart contracts temporarily reduce the proportion of nodes required to reach consensus, balancing security and efficiency; Using multiple communication channels: Emergency information is uploaded simultaneously through multiple channels including 4G, 5G, and satellite communication, and the smart contract selects the first valid data received; 53) Smart contract responses, specifically including: 531) Trigger the alarm immediately; 532) Push signed emergency alert information to relevant parties, including regulatory agencies, emergency response departments, and aircraft operators; 533) Coordinate with other aircraft to avoid the emergency based on its type and location; 54) Handling false alarms: If the emergency is confirmed to be a false alarm in the event of an incident, the operator or regulatory authority shall initiate a request to cancel the emergency status through the client; after verifying the legality of the request, the alarm shall be canceled and the relevant aircraft shall be restored to normal status.

10. The blockchain-based low-altitude airspace usage recording method according to claim 1, characterized in that, Step 6) specifically includes: 61) Initiate a query request as follows: 611) Identity authentication; Applicable users: Regulatory agencies, airspace management authorities, licensed aircraft operators, and permitted public users; Users submit digital certificates or account credentials through the client, and the smart contract verifies their authenticity and returns their assigned role identifier. 612) Assemble and sign the query message; The message structure is {query number, query type, query condition, timestamp, random number}; Query types include flight plans, real-time flight data, historical flight paths, and airspace capacity statistics; Query criteria include flight plan number, aircraft identifier, time range, geographical range, and status filtering; After generating a digital signature using the user's private key, the client sends it to the blockchain access node via a TLS channel; 62) Access control and auditing, as follows: 621) Role-based access control; Predefined roles: system administrator, supervisor, operator, and the public; Each role is associated with a corresponding set of resource accesses and sets of operations; 622) Access control list maintenance; Smart contracts store triples of <user / role→resource→operation>. Supports dynamic adjustments to on-chain proposals and voting; 623) Data hierarchy and the principle of least privilege; Data classification: publicly visible, restricted visible, and confidential; Query results must be filtered and anonymized at the field level to ensure that users can only obtain data that matches their role; 624) Authority decision-making and execution; Smart contract comparison query messages and access control lists; If permissions are insufficient, immediately return "Access denied" and terminate the query; 625) Operational audit; Generate audit entries {operator, timestamp, operation type, object, result, hash} for user login, query requests, and authorization change operations; Audit entries are immediately stored in the blockchain audit log table to ensure immutability and traceability; 63) Query execution and result return are as follows: 631) Data retrieval; The smart contract retrieves the target record by calling the on-chain state database or accessing off-chain storage through an oracle, based on the query type and conditions. 632) Result processing; Desensitize or crop fields that exceed the authorization level; Generate a result set and append a data digest hash and a response timestamp; 633) Result Signature and Return; The node signs the result set using its own private key; The data is returned to the client via the original communication channel, and the client verifies the node signature and data digest before displaying it. 634) Confirmation complete; The smart contract sends a query completion confirmation message to the querier and marks the query transaction status as completed in the audit log.

Images