Managing unmanned aerial vehicle identity

Abstract

In embodiments of systems and methods for managing unmanned aerial vehicle (UAV) identity, a processor of a network computing device can: generate an anonymous token associated with a digital certificate of a UAV; provide the anonymous token to the UAV for use in operations; receive a request to authenticate the UAV, wherein the request includes the anonymous token; determine whether the anonymous token included in the request is associated with the digital certificate; and responsive to determining that the anonymous token included in the request is associated with the digital certificate, send an indication that the UAV is authenticated in response to the request.

Description

[0001] Related applications

[0002] This application claims priority to U.S. Provisional Application No. 63 / 180,502, filed April 27, 2021, entitled “Managing An Unmanned Aerial Vehicle Identity,” and U.S. Non-Provisional Application No. 17 / 482,517, filed September 23, 2021, entitled “Managing An Unmanned Aerial Vehicle Identity,” the entire contents of which are incorporated herein by reference for all purposes. Background Technology

[0003] Wireless communication networks are widely deployed to provide various types of communication content, such as voice, video, packet data, message sending and receiving, and broadcasting. These systems can be multiple access systems capable of supporting communication with multiple users by sharing available system resources (e.g., time, frequency, and power). Examples of such multiple access systems include Code Division Multiple Access (CDMA) systems, Time Division Multiple Access (TDMA) systems, Frequency Division Multiple Access (FDMA) systems, Orthogonal Frequency Division Multiple Access (OFDMA) systems, and Single Carrier Frequency Division Multiple Access (SC-FDMA) systems.

[0004] These multiple access technologies have been adopted in various telecommunications standards to provide a common protocol enabling different wireless devices to communicate at the city, national, regional, and even global levels. For example, fifth-generation (5G) wireless communication technology (which may be referred to as New Radio (NR)) is designed to expand and support a diverse range of use cases and applications relative to current mobile network generations. In one aspect, 5G communication technologies may include: enhanced mobile broadband for human-centric use cases to access multimedia content, services, and data; ultra-reliable low latency communication (URLLC) with certain specifications regarding latency and reliability; and massive machine-type communication, which allows for a very large number of connected devices and the transmission of relatively small amounts of non-latency-sensitive information. However, with the continued growth in demand for mobile broadband access, further improvements to NR and ultra-NR communication technologies may be expected.

[0005] Unmanned Air System Traffic Management (UTM) is under development as a traffic management ecosystem for unmanned aerial vehicle (UAV) operations, separate from but complementary to Air Traffic Management (ATM) systems. In many operational scenarios, communication from UAVs requires digital certificates to enable receiving devices to authenticate information sent from the UAV. For example, onboard applications (such as remote ID and message detection and prevention) may require trusted, authenticated messages signed with cryptographically verifiable private keys (e.g., using their public key certificates).

[0006] A typical digital certificate provided by a UAV may include identifiers of the UAV and its operator, enabling the UAV to be tracked and associated with a known operator or organization. Some UAV operators may require operator privacy depending on the nature of their identity, role, or mission, but for security and other operational purposes, they must still sign and broadcast authenticable messages.

[0007] Overview

[0008] The aspects include systems and methods for managing UAV identities, executed by a processor of a network computing device. These aspects may include: generating an anonymous token associated with a digital certificate of the UAV; providing the anonymous token to the UAV for use in operation; receiving a request to authenticate a UAV message, wherein the request includes the anonymous token and a digital signature associated with the UAV message; using the anonymous token included in the request to identify the digital certificate; determining whether the digital signature has been verified using the digital certificate; and, in response to determining that the digital signature has been verified using the digital certificate, sending an indication that the UAV message has been authenticated in response to the request.

[0009] In some aspects, an anonymity token may include cryptographically verifiable instructions regarding the association of the anonymity token with a digital signature. In some aspects, an anonymity token may include instructions regarding the UAV's right to perform operations anonymously. In some aspects, a digital certificate may include instructions regarding the UAV's right to perform operations anonymously. In some aspects, anonymity tokens may be associated with availability time limits. In some aspects, anonymity tokens may be associated with availability geographical limits. In some aspects, anonymity tokens may include a hash of a digital certificate. In some aspects, anonymity tokens may include a hash of a digital certificate concatenated with a confidential value.

[0010] In some aspects, generating an anonymous token associated with a digital certificate of a UAV may include generating the anonymous token from a hash of the digital certificate, a keyed hash of the digital certificate, or a keyed hash tree of the digital certificate. In some aspects, generating an anonymous token associated with a digital certificate of a UAV may include generating multiple anonymous tokens associated with the digital certificate, wherein each of the multiple anonymous tokens is associated with an availability time limit; and providing the anonymous tokens to the UAV for operational use may include providing the multiple anonymous tokens to the UAV for operational use, wherein the use of each anonymous token is limited by a corresponding availability time limit. In some aspects, generating multiple anonymous tokens associated with a digital certificate may include generating multiple anonymous tokens using a keyed hash tree.

[0011] A further aspect includes a network computing device having a processing system configured to perform one or more operations of any of the methods outlined above. A further aspect includes processing means for use in the network computing device, the processing means being configured with processor-executable instructions for performing operations of any of the methods outlined above. A further aspect includes a non-transient processor-readable storage medium having processor-executable instructions stored thereon, the processor-executable instructions being configured to cause a processor of the network computing device to perform operations of any of the methods outlined above. A further aspect includes a network computing device having means for performing functions of any of the methods outlined above. Brief description of the attached diagram

[0013] The disclosed aspects will now be described in conjunction with the accompanying drawings, which are provided for illustrative purposes and not for limiting the scope of the disclosure, wherein similar reference numerals denote similar elements, and wherein: Figure 1 This is a diagram illustrating an example of a wireless communication system and access network.

[0014] Figure 2 This is a schematic diagram of an example of user equipment (such as a mobile device or UAV).

[0015] Figure 3 This is a schematic diagram of an example base station.

[0016] Figure 4 This is a schematic diagram illustrating an example of an environment used to manage UAVs.

[0017] Figure 5 This is a sequence diagram illustrating an example of the process by which a certificate is distributed by a UAV.

[0018] Figure 6A This is a sequence diagram illustrating an example of the UAV initialization process entering the network.

[0019] Figure 6B This is a sequence diagram of the first example of the process of distributing certificates by a base station.

[0020] Figure 6C This is a sequence diagram of a second example of the process of distributing certificates by a base station.

[0021] Figure 6D This is a sequence diagram illustrating an example of the process by which the recipient obtains a certificate.

[0022] Figure 6E This is a sequence diagram illustrating an example of the process of a base station broadcasting a certificate.

[0023] Figure 7A This is a sequence diagram illustrating an example of the process for managing UAV identities.

[0024] Figure 7B This is a sequence diagram illustrating an example of the process for managing UAV identities.

[0025] Figure 8 This is a flowchart illustrating a method for managing UAV identities that can be executed by a processor of a network computing device according to various embodiments.

[0026] Figure 9 This is a flowchart illustrating the operation of a method for managing UAV identities, which can be executed by a processor of a network computing device according to various embodiments.

[0027] Figure 10 This is a flowchart illustrating a method for managing UAV identities that can be executed by a base station processor according to various embodiments.

[0028] Figure 11 This is a flowchart illustrating the operation of a method for managing UAV identities, which can be executed by the processor of a base station according to various embodiments.

[0029] Figure 12 This is a flowchart illustrating the operation of a method for managing UAV identities, which can be executed by the processor of a base station according to various embodiments.

[0030] Figure 13 This is a component block diagram of a network computing device applicable to various embodiments.

[0031] Detailed description

[0032] The detailed description that follows, taken in conjunction with the accompanying drawings, is intended as a description of various configurations and is not intended to represent only the configurations in which the concepts described herein can be practiced. This detailed description includes specific details to provide a thorough understanding of the various concepts. However, it will be apparent to those skilled in the art that these concepts can be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form to avoid obscuring such concepts.

[0033] Several aspects of a telecommunications system will now be described with reference to various apparatuses and methods. These apparatuses and methods will be described in detail below and explained in the accompanying drawings by various blocks, components, circuits, processes, algorithms, etc. (collectively, “elements”). These elements can be implemented using electronic hardware, computer software, or any combination thereof. Whether such elements are implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system.

[0034] As an example, an element, or any part of an element, or any combination of elements, may be implemented as a "processing system" including one or more processors. Examples of processors include: microprocessors, microcontrollers, graphics processing units (GPUs), central processing units (CPUs), application processors, digital signal processors (DSPs), reduced instruction set computing (RISC) processors, system-on-a-chip (SoCs), baseband processors, field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gated logic, discrete hardware circuits, and other suitable hardware configured to perform the various functionalities described throughout this disclosure. One or more processors in a processing system can execute software. Software should be broadly interpreted as instructions, instruction sets, code, code segments, program code, programs, subroutines, software components, applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description languages, or other terms.

[0035] Accordingly, in one or more example embodiments, the described functionality can be implemented in hardware, software, or any combination thereof. If implemented in software, the functionality can be stored or encoded as one or more instructions or code on a computer-readable medium. Computer-readable media includes computer storage media. Storage media can be any available medium accessible to a computer. By way of example and not limitation, such computer-readable media may include random access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), optical disk storage, magnetic disk storage, other magnetic storage devices, combinations of computer-readable media of the types described above, or any other medium capable of being used to store computer-executable code in the form of instructions or data structures accessible to a computer.

[0036] In one implementation, the UAV can segment a certificate into segments. The UAV can embed each segment of the certificate into a frame. Frames containing the segments can be transmitted sequentially by the UAV. The UAV can transmit a broadcast remote identifier. The recipient of the broadcast remote identifier and / or certificate segments can concatenate these certificate segments into a certificate to be used for authenticating the broadcast remote identifier.

[0037] In some implementations, the broadcast remote identifier can be a mobile identifier (associated with a mobile device or UAV) declared during the broadcast process. In other instances, the broadcast remote identifier can be a certificate associated with or containing a mobile identifier. A mobile identifier can be a serial number, a government-issued identifier, a universally unique identifier, etc.

[0038] Various embodiments will be described in detail with reference to the accompanying drawings. Where possible, the same reference numerals will be used throughout the drawings to refer to the same or similar parts. References to specific examples and implementations are for illustrative purposes and are not intended to limit the scope of the claims.

[0039] Various embodiments include systems and methods performed by network computing devices and base stations to manage the identity of UAVs. These embodiments can be used to enable UAVs and base stations to operate while transmitting information required for security or other purposes, without transmitting certain identifying information that allows the UAV to be tracked or associated with a specific UAV operator.

[0040] While UAVs are referred to in this description for brevity, it will be understood that UAVs can include one of a variety of types of vehicles (including onboard computing devices configured to provide some degree of autonomy or semi-autonomous capability). Examples of such vehicles include, but are not limited to: aircraft, such as UAVs; ground vehicles (e.g., autonomous or semi-autonomous cars, vacuum robots, etc.); water-based vehicles (i.e., vehicles configured to operate on or under water); and / or some combination thereof. In some embodiments, the vehicle may be manned. In other embodiments, the vehicle may be driverless. In embodiments where the vehicle is autonomous, the vehicle may include an onboard computing device configured to operate and / or navigate the vehicle autonomously without remote operating instructions (e.g., from a human operator, via a remote computing device). In embodiments where the vehicle is semi-autonomous, the vehicle may include an onboard computing device configured to receive certain information or instructions (e.g., from a human operator, via a remote computing device) and operate and / or navigate the vehicle autonomously in accordance with the received information or instructions. In some implementations, the vehicle may be an aircraft (unmanned or manned), which may be a rotorcraft or a winged aircraft. For example, a rotorcraft (also known as a multi-rotor aircraft or multi-axis aircraft) may include multiple propulsion units (e.g., rotors / propellers) that provide thrust and / or lift to the vehicle. Specific, non-limiting examples of rotorcraft include triaxial aircraft (three rotors), quadcopters (four rotors), hexacopters (six rotors), and octaxial aircraft (eight rotors). However, a rotorcraft may include any number of rotors. The vehicle may include various components and / or payloads capable of performing a variety of functions. The term "component" in relation to the use of the vehicle includes vehicle components and / or vehicle payloads.

[0041] The term "System-on-a-Chip" (SOC) is used herein to refer to a single integrated circuit (IC) chip containing multiple resources or processors integrated on a single substrate. A single SOC may contain circuitry for digital, analog, mixed-signal, and radio frequency functions. A single SOC may also include any number of general-purpose or special-purpose processors (digital signal processors, modem processors, video processors, etc.), memory blocks (such as ROM, RAM, flash memory, etc.), and resources (such as timers, voltage regulators, oscillators, etc.). Each SOC may also include software for controlling the integrated resources and processors, as well as software for controlling peripheral devices.

[0042] The term "system-in-package" (SIP) may be used herein to refer to a single module or package containing multiple resources, computing units, cores or processors on two or more IC chips, a substrate, or a System-on-a-Chip (SoC). For example, a SIP may include a single substrate on which multiple IC chips or semiconductor dies are stacked in a vertical configuration. Similarly, a SIP may include one or more multi-chip modules (MCMs) on which multiple ICs or semiconductor dies are packaged into a unified substrate. A SIP may also include multiple separate SoCs coupled together and packaged adjacently (e.g., on a single motherboard or in a single wireless device) via high-speed communication circuitry. The proximity of SoCs facilitates high-speed communication and the sharing of memory and resources.

[0043] As used herein, the terms “network,” “system,” “wireless network,” “cellular network,” and “wireless communication network” can be used interchangeably to refer to part or all of an operator’s wireless network associated with a wireless device and / or a subscription on that wireless device. The technologies described herein can be used in a variety of wireless communication networks, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), FDMA, Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), and others. Generally, any number of wireless networks can be deployed in a given geographic area. Each wireless network can support at least one radio access technology, which can operate on one or more frequencies or frequency ranges. For example, a CDMA network can implement Universal Terrestrial Radio Access (UTRA) (including the Wideband Code Division Multiple Access (WCDMA) standard), CDMA2000 (including the IS-2000, IS-95, and / or IS-856 standards), etc. In another example, a TDMA network can implement GSM Enhanced Data Rate (EDGE) for GSM evolution. In another example, OFDMA networks can implement Evolved UTRA (E-UTRA) (including the LTE standard), IEEE 802.11 (WiFi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDM, etc. References to wireless networks using the LTE standard are possible, and therefore the terms "Evolved Universal Terrestrial Radio Access," "E-UTRAN," and "eNodeB" can be used interchangeably herein to refer to wireless networks. However, such references are provided merely as examples and are not intended to exclude wireless networks using other communication standards. For example, while various third-generation (3G), fourth-generation (4G), and fifth-generation (5G) systems are discussed herein, those systems are cited merely as examples and can be replaced by future generations of systems (e.g., sixth-generation (6G) or higher) in various examples.

[0044] Typically, communications from a UAV may require digital certificates that enable receiving devices to authenticate information sent from the UAV. Such communications may include, for example, anticipated maneuvers and other flight operations, observations of other traffic and the environment, and so on. Requiring digital signatures for such communications enables authentication of the source of this information. A typical UAV digital certificate is static and may include the identity of the UAV and its operator, enabling the tracking of the UAV and its association with a known operator or organization. As mentioned above, some UAV operators may desire the ability to operate the UAV anonymously based on the nature of their identity, role, or mission, while still signing and transmitting authenticable messages for security and other operational purposes.

[0045] Various embodiments include methods for managing UAV identities and network computing devices and base stations configured to implement these methods. In various embodiments, a UAV may be configured with the right or permission to perform operations without transmitting certain identifying information about the UAV or its operator, such identifying information enabling tracking of the UAV or associating the UAV with its operator. Examples of such identifying information are a digital certificate of the UAV or a digital certificate associated with it. As used herein, performing operations without transmitting such identifying information is referred to as “anonymously” performing operations. In various embodiments, when a UAV is operating anonymously, the UAV may be configured to send messages that do not have such identifying information (such as a digital signature) (e.g., digitally signed messages). Furthermore, devices receiving such messages (e.g., digitally signed messages) from a UAV will not be provisioned or provided with information identifying the UAV (e.g., a digital signature). Additionally, elements of a UTM (such as a base station) may be configured to send messages containing information about the UAV without the UAV’s identity information (such as a digital signature). For example, certain operators (such as law enforcement or military agencies) may need to operate UAVs anonymously from time to time, such as performing traffic observation, surveillance, etc. As another example, commercial parcel delivery drivers may be granted permission to operate certain UAVs anonymously to protect confidential business operations from observation, and to deliver parcels confidentially (such as confidential legal, medical, or commercial documents; drug prescriptions; medical devices or equipment; medical samples for testing; etc.).

[0046] Various embodiments may include methods for managing UAV identities to enable UAVs to perform operations anonymously, and devices configured to perform these methods. In various embodiments, the UAV may be associated with a digital certificate, or may be issued a digital certificate (e.g., by a certificate authority or another suitable issuer). A network computing device (such as a server) may be configured to generate an anonymous token associated with the UAV's digital certificate. In some embodiments, the network computing device may provide the anonymous token to the UAV for use in operation. In some embodiments, the network computing device may use a hash of the digital certificate to generate the anonymous token. In some embodiments, the network computing device may use a keyed hash of the digital certificate to generate the anonymous token. In some embodiments, the network computing device may use a keyed hash tree of the digital certificate to generate the anonymous token.

[0047] The UAV may be configured with an anonymity token, and the UAV may associate this anonymity token with a transmission (referred to herein as a "UAV message"). The anonymity token enables a recipient to request authentication of the transmission and / or the sending UAV without receiving identification information from the UAV and / or the UAV operator. In some embodiments, the UAV may digitally sign the UAV message using a cryptographic key associated with it. In some embodiments, the anonymity token may include a cryptographically verifiable indication regarding the association of the anonymity token with the UAV's digital certificate. In some embodiments, the anonymity token may include an indication regarding the UAV's (and / or the UAV operator's) right to perform operations anonymously.

[0048] In some embodiments, a network computing device may receive a request for an authenticated UAV message. For example, the network computing device may receive the request from UTM infrastructure (such as a base station or other network access point), another UAV, a receiving device (such as a ground station, smartphone, or other suitable device), etc. In some embodiments, the request may include an anonymity token and a digital signature associated with the UAV message. In some embodiments, the request may include message information that has been digitally signed (sometimes referred to as "signed data"). The network computing device may use the anonymity token included in the request to identify a digital certificate. For example, the network computing device may identify a digital certificate associated with the anonymity token. In some embodiments, the association between a digital certificate and one or more anonymity tokens may be stored in a memory or memory device accessible to the network computing device.

[0049] In some embodiments, the network computing device may determine whether a digital signature has been verified using a digital certificate. In some embodiments, the network computing device may use a digital certificate to perform verification of the digital signature. In some embodiments, the network computing device may use a digital certificate to perform cryptographic verification of the digital signature. In some embodiments, cryptographic verification of the digital signature using a digital certificate may indicate that the UAV message is authentic and / or that the sending UAV can be considered a trusted source. In some embodiments, in response to determining that the digital signature has been verified using a digital certificate, the network computing device may send an indication that the message has been authenticated in response to the request.

[0050] In some embodiments, the anonymity token may include a cryptographically verifiable indication of the association between the anonymity token and a digital signature. In some embodiments, the anonymity token may include a hash of a digital certificate. In some embodiments, the anonymity token may include a portion of the hash of a digital certificate. In some embodiments, the anonymity token may include a hash of a digital certificate concatenated with a confidential value. In some embodiments, a network computing device may use such a hash of a digital certificate (or a hash concatenated with a confidential value) to obtain (e.g., look up) a digital certificate. In various embodiments, the data structure of the anonymity token may be configured to include various encoded information and / or associations with other data, without limitation.

[0051] In some embodiments, anonymity tokens may be associated with availability time constraints. For example, anonymity tokens may be associated with a lifetime or another time constraint on their availability that limits the usefulness of the anonymity token to a specified time range or duration outside which the UAV will not be able to use the anonymity token to perform operations anonymously. In some embodiments, anonymity tokens may include or be associated with an availability time constraint. In some embodiments, a network computing device may determine the association between an anonymity token and an availability time constraint, for example, by referring to information stored in a data structure such as a database.

[0052] In some embodiments, anonymity tokens may be associated with availability geographic restrictions. For example, anonymity tokens may be associated with geofences, coordinates, or another geographic constraint on their availability that limits the usefulness of the anonymity token to a specified location, region, or physical region (such as corresponding to a legal jurisdiction, war zone, or specified delivery route or travel path), outside of which the UAV will not be able to use the anonymity token to perform operations anonymously. In some embodiments, the anonymity token may include or be associated with an availability geographic restriction. In some embodiments, the network computing device may determine the association between the anonymity token and the availability geographic restriction, for example, by referring to information stored in a database or other suitable data structure.

[0053] In some embodiments, to enhance the UAV's ability to perform operations anonymously, a network computing device may generate multiple anonymous tokens associated with a digital certificate of the UAV, and these multiple anonymous tokens may be configured (e.g., uploaded to and stored) in the UAV's memory. In some embodiments, the multiple anonymous tokens may be cryptographically associated with a digital certificate. For example, each anonymous token may be associated with a single certificate or a unique certificate. In such embodiments, the association between each anonymous token and the digital certificate may be maintained by the network computing device. In some embodiments, the network computing device may use a hash of the digital certificate to generate multiple anonymous tokens. In some embodiments, the network computing device may use a keyed hash of the digital certificate to generate multiple anonymous tokens. In some embodiments, the network computing device may use a keyed hash tree of the digital certificate to generate multiple anonymous tokens. In some embodiments, the network computing device may maintain a confidential key used by the network computing device to generate the multiple anonymous tokens during the keyed hashing process. In some embodiments, the UAV may rotate its multiple anonymous tokens for inclusion in one or more transmissions. In some embodiments, the UAV may randomly select an anonymous token from the multiple anonymous tokens for use in a transmission. In some embodiments, each of the multiple anonymous tokens may be configured with an availability time limit. In some embodiments, each of the plurality of anonymity tokens may be limited to use in a single transmission (i.e., one-time use). In this way, the UAV can transmit authentic and anonymous messages about the identity of the UAV and / or its operator.

[0054] In various embodiments, a base station, access point, or other device that provides a wireless communication link and supports access to a communication network (collectively referred to herein as a "base station") may be configured to perform methods for managing UAV identities. In some embodiments, the base station may be configured to receive an assertion from a UAV regarding the UAV's right to perform an operation anonymously. In some embodiments, the assertion may include an anonymous token or digital certificate, and the anonymous token or digital certificate may include indications regarding the UAV's right to perform an operation anonymously (such as information including the assertion). In some embodiments, the assertion may include a message and an anonymous token. In some embodiments, a digital signature is performed on the message and the anonymous token. In some embodiments, the assertion may include a pointer to an attribute or data structure indicating information indicating the UAV's right to perform an operation anonymously. The data structure pointer may be a record locator or other suitable information pointing to the location of information in a data structure, such as a database. In some embodiments, such a database may be managed or accessed by a network computing device. In some embodiments, the anonymous token included in the assertion may be the product of cryptographic processing, such as a hash of a digital certificate. The encryption process may enable the anonymous token to be unambiguously associated with a digital signature associated with the UAV. In some embodiments, the anonymous token may include a cryptographically verifiable indication regarding the association of the anonymous token with the UAV's digital certificate.

[0055] In some embodiments, a base station may send a request to a network computing device for authentication of a UAV, wherein the request includes an assertion and a digital signature performed on the assertion. In some embodiments, the digital signature may include signed data initially sent from the UAV. The base station may receive a response from the network computing device indicating whether the UAV is authorized to perform operations anonymously. Based on the response from the network computing device, the base station may determine whether the UAV is authorized to operate anonymously. In response to determining that the UAV is authorized to operate anonymously, the base station may broadcast information about the UAV without configuring identity information for the UAV. In some embodiments, the broadcast may additionally include one or more pseudonymous certificates associated with an anonymity token, which other UTM entities may use to authenticate the UAV broadcast without receiving information about the UAV's identity.

[0056] A base station can be configured to handle requests from another device that require the base station to authenticate a UAV. Non-limiting examples of other devices that can issue such requests include another UAV, a receiving device (such as a ground station), a smartphone, or a UAV controller device, etc. In some embodiments, the base station may receive a request to authenticate a UAV message, wherein the request includes an anonymity token associated with the UAV and a digital signature associated with the UAV, which are included in the UAV message. For example, another device may receive a UAV message from a UAV and extract the digital signature or an assertion from the UAV message in another signed data structure. The other device may include the received assertion and digital signature in a request (e.g., to the base station) for authentication of the UAV message. In some embodiments, the digital signature may include message data that has already been digitally signed.

[0057] Upon receiving such a request, the base station may send a request to the network computing device for authenticating the UAV message, wherein the request includes an anonymity token and a digital signature associated with the UAV message (e.g., a digitally signed UAV message, a digital signature generated using the UAV message, etc.). The base station may receive a response from the network computing device indicating whether the UAV message has been authenticated. In some embodiments, the base station may determine whether the UAV message has been authenticated based on the response from the network computing device. In some embodiments, the base station may relay or forward the indication received from the network computing device regarding whether the UAV message has been authenticated. In this way, the base station may send an indication that the UAV message has been authenticated. In some embodiments, the structure of the digital signature may include UAV message data. In some embodiments, the private key of the UAV may be used to generate a digital signature on the UAV message.

[0058] Various embodiments can be implemented in a variety of scenarios. For example, a law enforcement UAV may be conducting reconnaissance operations in an area where other UAVs are operating simultaneously, thus requiring the exchange of Detection and Avoidance (DAA) messages to prevent near misses or collisions with these other UAVs. In non-anonymous operations, the law enforcement UAV may transmit its digital certificate along with the signed DAA message, or may make its digital certificate available to the message recipient via a UTM infrastructure (e.g., upon request via a base station) so that the message recipient can cryptographically verify and trust messages received from the UAV. When the law enforcement UAV operates anonymously, it may digitally sign the transmitted message with an anonymous token that can be associated with a public key certificate. Furthermore, the law enforcement UAV may send a notification, command, or request to the UTM infrastructure (e.g., a base station) not to broadcast the digital certificate associated with it. Receiving devices that need to authenticate transmissions received from the UAV may send a request to the base station or a remote verification service (e.g., a network computing device) (which can perform operations to provide confirmation or rejection of UAV transmission authentication) without revealing the identity of the law enforcement UAV or its operator.

[0059] As another example, a commercial parcel delivery UAV operator may wish to operate its UAV anonymously, for example, to prevent competitors from analyzing its business operations or to facilitate the delivery of sensitive or confidential documents, pharmaceuticals, medical devices, etc. To accommodate such scenarios, UAV operators may be granted exemptions from transmitting certain static or traceable message content or otherwise making their certificates available to other entities. Subsequently, when such an operator's UAV performs operations anonymously, the UAV may digitally sign the transmission associated with an anonymous token that enables the authentication of the transmission and / or the UAV and / or the UAV operator, without revealing the identity of the UAV and / or the UAV operator.

[0060] Figure 1This is an illustration of an example of a wireless communication system and access network 100. The wireless communication system (also known as a wireless wide area network (WWAN)) includes at least one BS 105, UE 110, Evolved Packet Core (EPC) 160, and 5G Core (5GC) 190. BS 105 may include macrocells (high-power cellular base stations) and / or small cells (low-power cellular base stations). Macrocells include base stations. Small cells include femtocells, picocells, and microcells. In one implementation, user equipment (UE) 110 may include a communication component 222. The communication component 222 and / or modem 220 of UE 110 may be configured to communicate with BS 105 or other UE 110 via a cellular network, Wi-Fi network, or other wireless and wired networks. UE 110 may include a certificate component 224 that retrieves certificates, segments certificates, and / or embeds certificate segments into frames. In some implementations, BS 105 may include a communication component 322 configured to communicate with UE 110.

[0061] The BS 105 configured for 4G LTE (collectively referred to as the Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN)) can interface with the EPC160 via backhaul link interface 132 (e.g., S1, X2, Internet Protocol (IP), or flex interface). The base station 105 configured for 5G NR (collectively referred to as the Next Generation RAN (NG-RAN)) can interface with the 5GC 190 via backhaul link interface 134 (e.g., S1, X2, Internet Protocol (IP), or flex interface). In addition to other functions, the BS 105 may perform one or more of the following functions: user data delivery, radio channel cryptography and decoding, integrity protection, header compression, mobility control functions (e.g., handover, dual connectivity), inter-cellular interference coordination, connection establishment and release, load balancing, distribution of Non-Access Stratum (NAS) messages, NAS node selection, synchronization, Radio Access Network (RAN) sharing, Multimedia Broadcast Multicast Service (MBMS), subscriber and equipment tracking, RAN Information Management (RIM), paging, location, and delivery of alarm messages. The BS 105s may communicate directly or indirectly with each other on backhaul link interface 134 (e.g., via EPC 160 or 5GC190). Backhaul links 132 and 134 may be wired or wireless.

[0062] BS 105 can wirelessly communicate with UE 110. Each BS 105 can provide communication coverage for a corresponding geographic coverage area 130. Overlapping geographic coverage areas 130 may exist. For example, a small cell 105' may have a coverage area 130' that overlaps with the coverage areas 130 of one or more macro BS 105s. A network that includes small cells and macro cells may be referred to as a heterogeneous network. The heterogeneous network may also include a Home Evolved B Node (eNB) (HeNB) that can provide service to a restricted group referred to as a Closed Subscriber Group (CSG). The communication link 120 between BS 105 and UE 104 may include uplink (UL) (also known as reverse link) transmission from UE 110 to BS 105 and / or downlink (DL) (also known as forward link) transmission from BS 105 to UE 110. The communication link 120 may use multiple-input multiple-output (MIMO) antenna technologies, including spatial multiplexing, beamforming, and / or transmit diversity. These communication links can be transmitted via one or more carriers. The total number of carriers used for transmission in each direction is up to [number missing]. Yx MHz ( x Each carrier allocated in the carrier aggregation (of component carriers) can be used by BS 105 / UE 110 up to [number missing] carriers. Y A spectrum with a bandwidth of MHz (e.g., 5, 10, 15, 20, 100, 400 MHz, etc.). These carriers may or may not be adjacent to each other. Carrier allocation may be asymmetric with respect to DL and UL (e.g., more or fewer carriers may be allocated to DL compared to UL). Component carriers may include primary component carriers and one or more secondary component carriers. The primary component carrier may be referred to as the primary cell (PCell), and the secondary component carriers may be referred to as secondary cells (SCells).

[0063] Some UEs 110 may communicate with each other using device-to-device (D2D) communication link 158. D2D communication link 158 may use DL / UL WWAN spectrum. D2D communication link 158 may use one or more sidelink channels, such as the Physical Sidelink Broadcast Channel (PSBCH), Physical Sidelink Discovery Channel (PSDCH), Physical Sidelink Shared Channel (PSSCH), and Physical Sidelink Control Channel (PSCCH). D2D communication can be achieved through a wide variety of wireless D2D communication systems, such as, for example, FlashLinQ, WiMedia, Bluetooth, ZigBee, Wi-Fi based on the IEEE 802.11 standard, LTE, or NR.

[0064] The wireless communication system may further include a Wi-Fi access point (AP) 150 communicating with a Wi-Fi station (STA) 152 via a communication link 154 in the 5 GHz unlicensed spectrum. When communicating in the unlicensed spectrum, the STA 152 / AP 150 may perform a clear channel assessment (CCA) before communication to determine whether the channel is available.

[0065] Small cell 105' can operate in licensed and / or unlicensed spectrum. When operating in unlicensed spectrum, small cell 105' can employ NR and use the same 5 GHz unlicensed spectrum as that used by Wi-Fi AP 150. Small cell 105' employing NR in unlicensed spectrum can enhance access network coverage and / or increase access network capacity.

[0066] Whether it's a small cell 105' or a large cell (e.g., a macro base station), base station 105 may include an eNB, a gB node (gNB), or other types of base stations. Some base stations (such as gNB 180) may operate in conventional sub-6 GHz spectrum, millimeter wave (mmW) frequencies, and / or near-mmW frequencies to communicate with UE 110. When gNB 180 operates in mmW or near-mmW frequencies, gNB 180 may be referred to as an mmW base station. Extremely high frequency (EHF) is a portion of the radio frequency (RF) in the electromagnetic spectrum. EHF has a range of 30 GHz to 300 GHz and wavelengths between 1 mm and 10 mm. Radio waves in this band may be referred to as millimeter waves. Near-mmW extends down to 3 GHz frequencies with a wavelength of 100 mm. Ultra-high frequency (SHF) bands extend between 3 GHz and 30 GHz, and are also referred to as centimeter waves. Communication using mmW / near-mmW RF bands has extremely high path loss and short range. The mmW base station 180 can utilize beamforming 182 with the UE 110 to compensate for high path loss and short range.

[0067] EPC 160 may include Mobility Management Entity (MME) 162, other MMEs 164, Serving Gateway 166, Multimedia Broadcast Multicast Service (MBMS) Gateway 168, Broadcast Multicast Service Center (BM-SC) 170, and Packet Data Network (PDN) Gateway 172. MME 162 may communicate with Home Subscriber Server (HSS) 174. MME 162 is the control node for handling signaling between UE 110 and EPC 160. Generally, MME 162 provides bearer and connection management. All user Internet Protocol (IP) packets are delivered through Serving Gateway 166, which is itself connected to PDN Gateway 172. PDN Gateway 172 provides UE IP address allocation and other functions. PDN Gateway 172 and BM-SC 170 are connected to IP Service 176. IP Service 176 may include the Internet, intranet, IP Multimedia Subsystem (IMS), Packet Switched (PS) streaming service, and / or other IP services. The BM-SC 170 provides functionality for MBMS user service provisioning and delivery. The BM-SC 170 can serve as an entry point for content provider MBMS transmissions, authorize and initiate MBMS bearer services within a Public Land Mobile Network (PLMN), and schedule MBMS transmissions. The MBMS Gateway 168 can be used to distribute MBMS traffic to BS 105 within a Broadcast-Specific Service Single Frequency Network (MBSFN) area, and can be responsible for session management (start / stop) and collecting eMBMS-related billing information.

[0068] 5GC 190 may include Access and Mobility Management Functions (AMF) 192, other AMFs 193, Session Management Functions (SMF) 194, and User Plane Functions (UPF) 195. AMF 192 may communicate with Unified Data Management (UDM) 196. AMF 192 is the control node that handles signaling between UE 110 and 5GC 190. Generally, AMF 192 provides QoS flow and session management. All user Internet Protocol (IP) packets are transmitted through UPF 195. UPF 195 provides UE IP address allocation and other functions. UPF 195 connects to IP services 197. IP services 197 may include the Internet, intranet, IP Multimedia Subsystem (IMS), PS streaming service, and / or other IP services.

[0069] BS 105 may also be referred to as gNB, B-node, evolved B-node (eNB), access point, base transceiver station, radio base station, access point, access node, radio transceiver, B-node, evolved B-node (eNB), gNB, home B-node, home evolved B-node, relay, transceiver function, basic service set (BSS), extended service set (ESS), transmit / receive point (TRP), or any other suitable term. BS 105 provides UE 110 with an access point to EPC 160 or 5GC 190. Examples of UE 110 include cellular phones, smartphones, Session Initiation Protocol (SIP) phones, laptop devices, personal digital assistants (PDAs), satellite radios, GPS devices, multimedia devices, video devices, digital audio players (e.g., MP3 players), cameras, game consoles, tablet devices, smart devices, wearable devices, vehicles, electricity meters, air pumps, large or small kitchen appliances, healthcare devices, implants, sensors / actuators, displays, or any other similar functional devices. Some UE 110s may be referred to as IoT devices (e.g., parking timers, oil pumps, ovens, vehicles, heart monitors, etc.). UE 110 may also be referred to as a station, mobile station, subscriber station, mobile unit, subscriber unit, wireless unit, remote unit, mobile device, wireless device, wireless communication device, remote device, mobile subscriber station, access terminal, mobile terminal, wireless terminal, remote terminal, handheld device, user agent, mobile client, client, or some other suitable term.

[0070] In some examples, UE 110 may include, be part of, or be identical to a mobile device, UAV, UAS, etc.

[0071] Reference Figure 2 An example implementation of UE 110 may include a modem 220 having a communication component 222. The communication component 222 and / or modem 220 of UE 110 may be configured to communicate with BS 105 via a cellular network, Wi-Fi network, or other wireless and wired networks. The certificate component 224 may retrieve certificates, segment certificates, and / or embed certificate segments into frames.

[0072] In some implementations, UE 110 may include various components, including those communicating via one or more buses 244, such as one or more processors 212, memory 216, and transceiver 202. These components may operate in conjunction with modem 220 and communication components 222 to implement one or more functions related to communication with BS 105 as described herein. Furthermore, the one or more processors 212, modem 220, memory 216, transceiver 202, RF front end 288, and one or more antennas 265 may be configured to support voice and / or data calls (simultaneously or not simultaneously) in one or more radio access technologies. The one or more antennas 265 may include one or more antennas, antenna elements, and / or antenna arrays.

[0073] In one aspect, the one or more processors 212 may include a modem 220 using one or more modem processors. Various functions associated with the communication component 222 and / or the certificate component 224 may be included in the modem 220 and / or the processor 212, and in one aspect, may be performed by a single processor, while in other aspects, different functions may be performed by a combination of two or more different processors. For example, in one aspect, the one or more processors 212 may include any one or any combination of: a modem processor, or a baseband processor, or a digital signal processor, or a transmit processor, or a receiver device processor, or a transceiver processor associated with the transceiver 202. Additionally, the modem 220 may be configured with the processor 212 to support the UE 110. In other aspects, some features of the one or more processors 212 and / or the modem 220 associated with the communication component 222 and / or the certificate component 224 may be performed by the transceiver 202.

[0074] Furthermore, memory 216 may be configured to store data used herein and / or a local version of application 275, or communication component 222, certificate component 224, and / or one or more sub-components of communication component 222 and / or certificate component 224 executed by at least one processor 212. Memory 216 may include any type of computer-readable medium that can be used by a computer or at least one processor 212, such as random access memory (RAM), read-only memory (ROM), tape, magnetic disk, optical disk, volatile memory, non-volatile memory, and any combination thereof. In one aspect, for example, when UE 110 is operating at least one processor 212 to execute communication component 222, certificate component 224, and / or one or more sub-components, memory 216 may be a non-transient computer-readable storage medium storing one or more computer-executable codes defining communication component 222, certificate component 224, and / or one or more sub-components thereof, and / or associated data.

[0075] Transceiver 202 may include at least one receiver 206 and at least one transmitter 208. Receiver 206 may include hardware, firmware, and / or processor-executable software code for receiving data, the code including instructions and stored in memory (e.g., a computer-readable medium). Receiver 206 may be, for example, an RF receiving device. In one aspect, receiver 206 may receive signals transmitted by at least one BS 105. Transmitter 208 may include hardware, firmware, and / or processor-executable software code for transmitting data, the code including instructions and stored in memory (e.g., a computer-readable medium). Suitable examples of transmitter 208 may include, but are not limited to, RF transmitters.

[0076] Furthermore, in one aspect, UE 110 may include an RF front-end 288, which is communicatively operable with one or more antennas 265 and transceiver 202 for receiving and transmitting radio transmissions, such as wireless communications transmitted by at least one BS 105 or wireless transmissions transmitted by UE 110. The RF front-end 288 may be coupled to one or more antennas 265 and may include one or more low-noise amplifiers (LNAs) 290, one or more switches 292, one or more power amplifiers (PAs) 298, and one or more filters 296 for transmitting and receiving RF signals.

[0077] On one hand, the LNA 290 can amplify the received signal to a desired output level. On another hand, each LNA 290 can have specified minimum and maximum gain values. On yet another hand, the RF front end 288 can use one or more switches 292 to select a particular LNA 290 and a specified gain value based on the desired gain value for a particular application.

[0078] Furthermore, for example, one or more PAs 298 may be used by the RF front end 288 to amplify the signal to obtain an RF output at the desired output power level. In one aspect, each PA 298 may have specified minimum and maximum gain values. In another aspect, the RF front end 288 may use one or more switches 292 to select a specific PA 298 and a specified gain value based on the desired gain value for a particular application.

[0079] Furthermore, for example, one or more filters 296 may be used by the RF front end 288 to filter the received signal to obtain the input RF signal. Similarly, in one aspect, for example, a corresponding filter 296 may be used to filter the output from a corresponding PA 298 to produce an output signal for transmission. In one aspect, each filter 296 may be coupled to a specific LNA 290 and / or PA 298. In one aspect, the RF front end 288 may use one or more switches 292 to select the transmit or receive path using a specified filter 296, LNA 290, and / or PA 298 based on the configuration specified by the transceiver 202 and / or processor 212.

[0080] Thus, transceiver 202 can be configured to transmit and receive radio signals via RF front-end 288 through one or more antennas 265. In one aspect, the transceiver can be tuned to operate at a specified frequency so that UE 110 can, for example, communicate with one or more BS 105s or one or more cells associated with one or more BS 105s. In another aspect, for example, modem 220 can configure transceiver 202 to operate at a specified frequency and power level based on the UE configuration of UE 110 and the communication protocol used by modem 220.

[0081] In one aspect, modem 220 may be a multi-band, multi-mode modem capable of processing digital data and communicating with transceiver 202 to enable the use of transceiver 202 for transmitting and receiving digital data. In another aspect, modem 220 may be multi-band and configured to support multiple frequency bands for a specific communication protocol. In another aspect, modem 220 may be multi-mode and configured to support multiple operating networks and communication protocols. In one aspect, modem 220 may control one or more components of UE 110 (e.g., RF front-end 288, transceiver 202) to transmit and / or receive signals from the network based on a specified modem configuration. In one aspect, modem configuration may be based on the modem's mode and the frequency band in use. In another aspect, modem configuration may be based on UE configuration information associated with UE 110, such as that provided by the network.

[0082] Reference Figure 3 An example implementation of BS 105 may include a modem 320 having a communication component 322 configured to transmit data. The communication component 322 and / or modem 320 of BS 105 may be configured to communicate with UE 110 via a cellular network, Wi-Fi network, or other wireless and wired networks.

[0083] In some implementations, BS 105 may include various components, including those communicating via one or more buses 344, such as one or more processors 312, memory 316, and transceiver 302. These components may operate in conjunction with modem 320 and communication components 322 to implement one or more functions related to communication with UE 110 as described herein. Furthermore, the one or more processors 312, modem 320, memory 316, transceiver 302, RF front end 388, and one or more antennas 365 may be configured to support voice and / or data calls (simultaneously or not simultaneously) in one or more radio access technologies.

[0084] In one aspect, the one or more processors 312 may include a modem 320 using one or more modem processors. Various functions associated with the communication component 322 may be included in the modem 320 and / or processor 312, and in one aspect may be executed by a single processor, while in other aspects, different functions may be executed by a combination of two or more different processors. For example, in one aspect, the one or more processors 312 may include any one or any combination of the following: a modem processor, or a baseband processor, or a digital signal processor, or a transmitter processor, or a receiver device processor, or a transceiver processor associated with transceiver 302. Furthermore, the modem 320 may be configured with BS105 and processor 312. In other aspects, some features of the one or more processors 312 and / or modem 320 associated with the communication component 322 may be executed by transceiver 302.

[0085] Furthermore, memory 316 may be configured to store data used herein and / or a local version of application 375, or communication component 322, determination component, and / or one or more sub-components of communication component 322 or determination component executed by at least one processor 312. Memory 316 may include any type of computer-readable medium that can be used by a computer or at least one processor 312, such as random access memory (RAM), read-only memory (ROM), tape, magnetic disk, optical disk, volatile memory, non-volatile memory, and any combination thereof. In one aspect, for example, when BS 105 is operating at least one processor 312 to execute communication component 322, determination component, and / or one or more sub-components, memory 316 may be a non-transient computer-readable storage medium storing one or more computer-executable codes defining communication component 322, determination component, and / or one or more sub-components thereof, and / or associated data.

[0086] Transceiver 302 may include at least one receiver 306 and at least one transmitter 308. At least one receiver 306 may include hardware, firmware, and / or processor-executable software code for receiving data, the code including instructions and stored in memory (e.g., a computer-readable medium). Receiver 306 may be, for example, an RF receiving device. In one aspect, receiver 306 may receive signals transmitted by UE 110. Transmitter 308 may include hardware, firmware, and / or processor-executable software code for transmitting data, the code including instructions and stored in memory (e.g., a computer-readable medium). Suitable examples of transmitter 308 may include, but are not limited to, RF transmitters.

[0087] Furthermore, in one aspect, BS 105 may include an RF front-end 388, which is communicatively operable with one or more antennas 365 and transceiver 302 for receiving and transmitting radio transmissions, such as wireless communications transmitted by other BS 105 or wireless transmissions transmitted by UE 110. The RF front-end 388 may be coupled to one or more antennas 365 and may include one or more low-noise amplifiers (LNAs) 390, one or more switches 392, one or more power amplifiers (PAs) 398, and one or more filters 396 for transmitting and receiving RF signals.

[0088] On one hand, the LNA 390 can amplify the received signal to the desired output level. On another hand, each LNA 390 can have specified minimum and maximum gain values. On yet another hand, the RF front end 388 can use one or more switches 392 to select a particular LNA 390 and a specified gain value based on the desired gain value for a particular application.

[0089] Furthermore, for example, one or more PAs 398 may be used by the RF front end 388 to amplify the signal to obtain an RF output at the desired output power level. In one aspect, each PA 398 may have specified minimum and maximum gain values. In another aspect, the RF front end 388 may use one or more switches 392 to select a specific PA 398 and a specified gain value based on the desired gain value for a particular application.

[0090] Furthermore, for example, one or more filters 396 may be used by the RF front end 388 to filter the received signal to obtain the input RF signal. Similarly, in one aspect, for example, a corresponding filter 396 may be used to filter the output from a corresponding PA 398 to produce an output signal for transmission. In one aspect, each filter 396 may be coupled to a specific LNA 390 and / or PA 398. In one aspect, the RF front end 388 may use one or more switches 392 to select the transmit or receive path using a specified filter 396, LNA 390, and / or PA 398 based on the configuration specified by the transceiver 302 and / or processor 312.

[0091] Thus, transceiver 302 can be configured to transmit and receive wireless signals via RF front-end 388 through one or more antennas 365. In one aspect, the transceiver can be tuned to operate at a specified frequency so that BS 105 can, for example, communicate with UE 110 associated with one or more BS 105s or one or more cells. In another aspect, for example, modem 320 can configure transceiver 302 to operate at a specified frequency and power level based on the base station configuration of BS 105 and the communication protocol used by modem 320.

[0092] In one aspect, modem 320 may be a multi-band, multi-mode modem capable of processing digital data and communicating with transceiver 302 to enable the use of transceiver 302 for transmitting and receiving digital data. In another aspect, modem 320 may be multi-band and configured to support multiple frequency bands for a specific communication protocol. In another aspect, modem 320 may be multi-mode and configured to support multiple operating networks and communication protocols. In one aspect, modem 320 may control one or more components of BS 105 (e.g., RF front-end 388, transceiver 302) to enable the transmission and / or reception of signals from the network based on a specified modem configuration. In one aspect, modem configuration may be based on the modem's mode and the frequency band in use. In another aspect, modem configuration may be based on the base station configuration associated with BS 105.

[0093] Go to Figure 4In one implementation, an example of an environment 400 for managing a UAV may include a mobile device 402. The mobile device 402 may include, be part of, or be identical to a UE 110. The mobile device 402 may be a UAV, an unmanned aerial system (UAS), a drone, or other device that can be controlled by a remote operator. The mobile device 402 may be operated by an operator 404 (e.g., a human operator, a machine operator, or an AI operator). The environment 400 may include a first receiver 410a, a second receiver 410b, and a third receiver 410c. The first receiver 410a may be a third-party authorized entity (TPAE, such as a police detector, a civilian / government detector, a regulatory agency, etc.). The second receiver 410b and the third receiver 410c may be mobile devices, such as UAVs. Other types of receivers are possible. The mobile device 402 may communicate with the first receiver 410a via a wireless communication link 412 (such as Bluetooth, Wi-Fi, a cellular device-to-device link, or other wireless communication links). Mobile device 402 may communicate with second receiver 410b via D2D communication link 158 (such as Bluetooth, Wi-Fi, cellular device-to-device link, or other wireless communication link). Mobile device 402 may communicate with third receiver 410c via communication link 154 (such as Bluetooth, Wi-Fi, cellular device-to-device link, or other wireless communication link). Other communication links may be used for communication.

[0094] In some implementations, environment 400 may include a first BS 105a having a first coverage area 130a and a second BS 105b having a second coverage area 130b. Environment 400 may include a core network 430, such as Figure 1 The environment 400 may include either EPC 160 or 5GC 190. The environment 400 may include a UAV service provider (USS) 420. USS 420 may optionally include a UAV flight management system (UFMS) 422. In some optional implementations, UFMS 422 may be implemented in the core network 430. In other optional implementations, UFMS 422 may be implemented in a separate server from USS 422. USS 420 and / or UFMS 422 may communicate with the first receiver 410 via communication link 414 (e.g., WiFi, long-range radio, cellular link, fiber optic, etc.) or the core network 430. USS 420 and / or UFMS 422 may communicate with the core network 430 via communication interface 416 (e.g., 5GC 190 network open function, EPC 160 service capability open function, 3GPP Rx interface, etc.).

[0095] In one implementation of this disclosure, the mobile device 402 may include a remote identifier (ID). The remote ID may include one or more pieces of information such as UAVID (e.g., serial number, registration number, or UAV traffic management unique ID), UAV type, timestamp, timestamp accuracy, operating status, operating description, longitude, latitude, geodetic altitude, takeoff altitude, position pressure altitude, vertical accuracy, horizontal accuracy, speed (north / south), speed (east / west), vertical speed, operating direction longitude, and operating direction latitude. The remote ID may be dynamically updated during operation of the mobile device 402. The mobile device 402 may obtain some or all of the information in the remote ID (e.g., UAV ID) from USS 420 and / or UFMS 422 via a cellular network (e.g., first BS 105a, second BS 105b, etc.).

[0096] In some implementations, the remote ID may include a Network Remote ID (NRID) and a Broadcast Remote ID (BRID). The NRID and / or BRID may include some or all of the information for the remote ID. In one example, the BRID may include the UAV ID and location information.

[0097] In one implementation, the cryptographic hash / digest of BRID is equivalent to UAV ID or index of UAV ID.

[0098] In one aspect of this disclosure, mobile device 402 may broadcast a BRID to one or more of a first receiver 410a, a second receiver 410b, and / or a third receiver 410c. To enable the first receiver 410a, the second receiver 410b, and / or the third receiver 410c to authenticate the BRID, mobile device 402 may transmit (e.g., unicast, multicast, or broadcast) a certificate. This certificate may be a certificate of mobile device 402, a certificate from a certificate authority that assigned the certificate to mobile device 402, or a trust chain file indicating one or more tiers of the certificate (each tier up to a root certificate or other designated authority). Mobile device 402 may segment the certificate into... n Each part, and can be n The certificate is transmitted in this frame. n For example, a Mobile Device 402 certificate can be divided into 20 parts. n= 20). Mobile device 402 may embed these 20 certificate partitions / segments into 20 frames and sequentially transmit these 20 frames to one or more of the first receiver 410a, the second receiver 410b, and / or the third receiver 410c. For example, frame 1 may include part 1 of the certificate, frame 2 may include part 2 of the certificate, and so on. Once a receiver (e.g., the first receiver, the second receiver, and / or the third receiver) receives all the frames (e.g., 20 frames), the receiver (e.g., ...) may concatenate these parts of the certificate (e.g., the 20 parts of these 20 frames) to generate or form a certificate (e.g., the certificate of mobile device 402).

[0099] In some scenarios, using certificates to authenticate BRIDs can allow the recipient 410a-410c to simultaneously verify the authenticity of the mobile device 402.

[0100] In some respects, mobile device 402 may indicate to receiver 410a-c the number of certificate portions (or frames). For example, mobile device 402 may divide the certificate into 50 portions and embed these 50 portions into 50 frames. Mobile device 402 may indicate in the first frame (which contains the first portion of the certificate) that the certificate to be transmitted has 50 portions. In response, receiver 410a-c may assemble the certificate after receiving these 50 portions in the 50 frames.

[0101] On the other hand, mobile device 402 may indicate to receivers 410a-c the last frame carrying the final portion of the certificate. For example, mobile device 402 may divide the certificate into 15 parts and embed these 15 parts into 15 frames. Mobile device 402 may indicate in the 15th frame that it is the last frame carrying the certificate. In response, receivers 410a-c may assemble the certificate after receiving the 15th frame (which has the 15th part or the final part).

[0102] In some respects, frames that carry the certificate portion can be labeled as certificate frames.

[0103] In some respects, the number of frames used to transmit the certificate portion (i.e., segments) can be dynamically determined based on factors such as weather conditions, traffic, regulatory requirements, and the technology used for transmission.

[0104] In some implementations, after the receiver 410a-c concatenates the certificate from its various parts, the receiver 410a-c can use the certificate to authenticate BRID and / or other messages transmitted by the mobile device 402.

[0105] In some respects, mobile device 402 may transmit frames carrying a certificate at specific periodic intervals. Examples of periodicity may include 50 milliseconds (ms), 100 ms, 500 ms, 1 second (s), 5 s, 10 s, 100 s, or other durations. Periodicity may be determined by various methods described below.

[0106] In one aspect of this disclosure, mobile device 402 may receive a security profile (e.g., an IEEE 1609.2 security profile). Mobile device 402 may receive the security profile during installation, programming, setup, initialization, or registration of mobile device 402. The security profile may indicate the periodicity of frames used to transmit the portion carrying the certificate.

[0107] In another aspect of this disclosure, the mobile device 402 may receive periodic values ​​when connected to the first BS 105a, the second BS 105b, the UFMS 422, and / or the USS 420. For example, when the USS 420 and / or the UFMS 422 provides a UAV ID to the mobile device 402, the USS 420 and / or the UFMS 422 may transmit the periodicity to the mobile device 402. In other examples, the periodicity may be embedded in the UAV ID when the USS 420 and / or the UFMS 422 provides the UAV ID to the mobile device 402.

[0108] In another aspect, the first BS 105a serving mobile device 402 may transmit the periodicity to mobile device 402 via a Radio Resource Configuration (RRC) message or a System Information Broadcast (SIB) message. The transmitted periodicity may be one of the following values ​​(e.g., 1 s, 2 s, 5 s, 10 s, 20 s, 50 s, 100 s, etc.) or a predefined index (e.g., 0 – never, 1 – 5 s, 2 – 10 s, 3 – 20, etc.).

[0109] In some aspects of this disclosure, the first BS 105a serving the mobile device 402 may dynamically update the periodicity of the mobile device 402 via RRC messages. The first BS 105a may send an RRC message to the mobile device 402 to change the periodicity of the frames used to transmit the portion carrying the certificate (e.g., from 10 s to 15 s).

[0110] In one implementation, this periodicity may vary depending on the flight schedule of mobile device 402, the geographic area along the flight schedule, local / regional / national policies, traffic density, terrain interference, or other factors related to the operation of mobile device 402.

[0111] In some implementations, this periodicity can be adaptively based on detected environmental factors, such as RF interference from other UAV traffic, weather-related attenuation, excessive certificate requests, etc. In other implementations, this periodicity can be based on received signal strength indication (RSSI), radio frequency, one or more network or link quality of service (QoS) parameters, or other factors associated with the quality of the communication channel.

[0112] In one aspect of this disclosure, recipients 410a-c may obtain certificates from sources other than mobile device 402. In a first example, USS 420 and / or UFMS 422 may provide certificates to core network 430. Core network 430 may determine the geographic location of mobile device 402 based on location information (e.g., longitude, latitude, altitude, etc.) in a remote ID, BRID, or NRID. Core network 430 may determine one or more coverage areas and corresponding base stations associated with the geographic location, such as a first BS 105a and a first coverage area 130a. Core network 430 may provide a certificate to the first BS 105a after determining that mobile device 402 is within the first coverage area 430a. Mobile device 402 may broadcast a BRID. After mobile device 402 broadcasts a BRID, second recipient 410b may receive the BRID from mobile device 402. Second recipient 410b may obtain information from the BRID, such as the UAVID of mobile device 402. The second receiver 410b may send a certificate request, including the UAV ID, to the first BS 105a (the serving base station of the second receiver 410b). In response, the first BS 105a may send a certificate response to the second receiver 410b, including the certificate (previously received from the core network 430). The second receiver 410b may use this certificate to authenticate the BRID from the mobile device 402.

[0113] In the second example, mobile device 402 may broadcast a BRID. After mobile device 402 broadcasts the BRID, second receiver 410b may receive the BRID from mobile device 402. Second receiver 410b may obtain information from the BRID, such as the UAV ID of mobile device 402. Second receiver 410b may send a certificate request, including the UAV ID, to first BS 105a (the serving base station of second receiver 410b). In response, first BS 105a may (e.g., via core network 430) send a certificate retrieval message (including the UAV ID of mobile device 402) to USS 420 and / or UFMS 422 to request a certificate. USS 420 and / or UFMS 422 may send the certificate associated with the UAV ID of mobile device 402 to first BS 105a in a certificate delivery message. After receiving the certificate delivery message, first BS 105a may send a certificate response, including the certificate, to second receiver 410b in response to the certificate request from second receiver 410b. The second recipient 410b can use the certificate to authenticate the BRID from the mobile device 402.

[0114] In the third example, mobile device 402 may broadcast a BRID. After mobile device 402 broadcasts the BRID, second receiver 410b may receive the BRID from mobile device 402. Second receiver 410b may obtain information from the BRID, such as the UAV ID of mobile device 402. Second receiver 410b may send a certificate request including the UAV ID to USS 420 and / or UFMS 422 by identifying USS 420 and / or UFMS 422 using the UAV ID (e.g., the UAV ID may be in the format of a fully qualified domain name (FQDN) and receiver 410b uses Domain Name Service (DNS) to retrieve the address of USS and / or UFMS). In response to receiving the certificate request, USS 420 and / or UFMS 422 may (e.g., via core network 430 and / or first BS 105a) send a certificate response including the certificate associated with the UAV ID to second receiver 410b. The second recipient 410b can use the certificate to authenticate the BRID from the mobile device 402.

[0115] In the fourth example, USS 420 and / or UFMS 422 may provide a certificate to core network 430. Core network 430 may determine the geographic location of mobile device 402 based on location information (e.g., longitude, latitude, altitude, etc.) in the remote ID, BRID, and / or NRID. Core network 430 may determine one or more coverage areas and corresponding base stations associated with the geographic location, such as first BS 105a and first coverage area 130a. Core network 430 may provide a certificate to first BS 105a after determining that mobile device 402 is within first coverage area 430a. Upon receiving the certificate, first BS 105a may broadcast the certificate within first coverage area 130a. Second receiver 410b may receive the broadcast certificate. Mobile device 402 may broadcast a BRID. After mobile device 402 broadcasts a BRID, second receiver 410b may receive the BRID from mobile device 402. Second receiver 410b may use the certificate to authenticate the BRID from mobile device 402. The first BS 105a and the second BS 105b may use a cellular broadcast system to broadcast the received certificate using an instruction for the BRID certificate, a Commercial Mobile Alert System (CMAS) to broadcast the received certificate using an instruction for the BRID certificate, or a multimedia broadcast / multicast system to broadcast the received certificate using a shared or dedicated channel for the BRID certificate that all receivers are subscribed to for receiving the BRID certificate.

[0116] In the fifth example, the first BS 105a may receive certificates from the mobile device 402, the core network 430, the UFMS 422, and / or the USS 420. The first BS 105a may also receive the flight / travel plan of the mobile device 402 from the core network 430, the UFMS 422, and / or the USS 420. Based on this flight plan, the first BS 105a may determine the geographic area that the mobile device 402 will enter. The first BS 105a may identify the coverage area associated with the geographic area that the mobile device 402 will enter, such as the second coverage area 130b of the second BS 105b. In response, the first BS 105a may identify the second BS 105b as associated with the second coverage area 130b and transmit the certificate to the second BS 105b (for broadcast to the respective receivers in the second coverage area 130b) before the mobile device 402 enters the second coverage area 130b.

[0117] In some aspects of this disclosure, recipients 410a-410c may use a certificate to authenticate any message transmitted by mobile device 402. Once authenticated, recipients 410a-410c are able to verify the authenticity and / or integrity of the arbitrary message from mobile device 402. In another example, mobile device 402 may use any message as a BRID.

[0118] Turn Figure 5 In some implementations, examples of sequence diagram 500 may include UAV 502, first receiver 504, second receiver 506, radio access network (RAN) 508, core network 430, UFMS 422, and USS 420. First receiver 504 and / or second receiver 506 may be a UAV, mobile device, UE, TPAE, base station, controller, or other device. In operation 520, UAV 502 may be configured by obtaining a UAV ID and performing credential bootstrapping (e.g., a security certificate). In communication 522, UAV 502 may transmit an RRC connection request to RAN 508. In communication 524, RAN 508 may transmit an RRC connection response with parameters for establishing a wireless communication link between RAN 508 and UAV 502 to UAV 502. In communication 526, UAV 502 may transmit an RRC connection completion message to RAN 508. In communication 528, RAN 508 may optionally transmit an RRC connection reconfiguration message to UAV 502. As an example, this reconfiguration may change the connection and / or operating parameters of UAV 502, such as the periodicity of certificate transmission. In communication 530, in response to completing the reconfiguration, UAV 502 may optionally transmit an RRC connection reconfiguration complete message to RAN 508.

[0119] In some implementations, during communication 532, UAV 502 can broadcast a BRID, which is received by the first receiver 504. UAV 502 can segment the certificate into... n The UAV 502 can be divided into segments (e.g., 25 segments). n Each segment is embedded into n In each frame. In an optional implementation, the UAV 502 can be marked this n A frame to indicate this n Each frame carries a segment of the certificate. In communication 534-1, UAV 502 can transmit the first frame of the first segment carrying the certificate. In communication 534-2, UAV 502 can transmit the second frame of the second segment carrying the certificate, and so on. In communication 534-n, UAV 502 can transmit the first frame of the last segment carrying the certificate. n Frame. The UAV 502 can periodically transmit this frame, carrying the certificate for each segment. nEach frame in the frame. For example, the periodicity may be signaled by USS 420 and / or UFMS 422 during the boot process at step 520. Alternatively, the periodicity may be signaled by RAN 508 using an RRC configuration / reconfiguration message at step 524 or 528. The periodicity may also be internally stored (e.g., in memory, hard-decoded, etc.) in UAV 502 prior to step 520.

[0120] In an optional implementation, the first frame may include a segmentation indicator, whose indicator certificate includes n The segmentation indicator can indicate to the receiving device (such as the first receiving device 504) that there are segments. n Each frame (and the certificate) n (Each segment) needs to be transmitted by UAV 502.

[0121] In another optional implementation, the first n The frame may include a termination indicator, which indicates the termination date. n The frame is carrying the last segment of the UAV 502 certificate.

[0122] In an optional implementation, UAV 502 can assign a sequence number corresponding to the order of the certificate segments to n A frame. The first segment carrying the certificate can be assigned "1". The second segment carrying the certificate can be assigned "2", and so on.

[0123] In one aspect of this disclosure, UAV 502 can segment a certificate into segment groups. UAV 502 can sequentially embed each segment group (with or without an equal number of segments) into corresponding frames for transmission. For example, UAV 520 can segment a certificate into 50 segments. UAV 520 can group these 50 segments into 5 segment groups, each group containing 10 segments (e.g., group 1 – segments #1-10, group 2 – segments #11-20, and so on). UAV 520 can embed the first segment group into a first frame, the second segment group into a second frame, and so on. UAV 520 can sequentially transmit these five frames carrying the five segment groups. In some implementations, the groups may have the same number of segments or different numbers of segments.

[0124] In operation 536, the first receiver 504 can verify the BRID by authenticating the BRID using a cascaded certificate (as described above).

[0125] In the alternative implementation, each segment of the certificate can be associated with an identifier. For example, UAV 520 can divide the certificate into 30 segments. UAV 520 can use "1" to mark the first segment, "2" to mark the second segment, ..., and "30" to mark the thirtieth segment. If the first receiver 504 fails to receive some of these segments (e.g., the seventeenth segment marked with the identifier "17"), the first receiver 504 can use that identifier to send a request to UAV 520 for retransmission of the seventeenth segment.

[0126] In operation 538, UAV 502 may wait until the broadcast timer expires. The broadcast timer indicates the interval during which UAV 502 waits between broadcasting two BRIDs. The broadcast timer may last for 1 s, 5 s, 10 s, 50 s, or other suitable intervals (e.g., depending on the operation of UAV 502, the remaining battery power in UAV 502, the operating environment, regulations, etc.).

[0127] In some implementations, during communication 542, UAV 502 can broadcast the BRID, which is received by the second receiver 506. UAV 502 can segment the certificate into... m The UAV 502 can be divided into segments (e.g., 15 segments). m Each segment is embedded into m In each frame. In an optional implementation, the UAV 502 can be marked this m A frame to indicate this m Each frame carries a segment of the certificate. In communication 544-1, UAV 502 can transmit the first frame of the first segment carrying the certificate. In communication 544-2, UAV 502 can transmit the second frame of the second segment carrying the certificate, and so on. In communication 544-m, UAV 502 can transmit the first frame of the last segment carrying the certificate. m Frame. In operation 546, the second receiver 506 can verify the BRID by authenticating the BRID using a cascaded certificate (as described above).

[0128] In some instances, the number of segments into which the certificate is divided by the UAV 502 may depend on the communication link technology, the operation of the UAV 502, the remaining battery power in the UAV 502, the operating environment, regulations, etc.

[0129] Turn Figure 6A-E, In one implementation, an example of sequence diagram 600 may include UAV 602, first receiver 604, second receiver 606, first BS 105a, second BS 105b, core network 430, UFMS 422, and USS 420. First receiver 604 and / or second receiver 606 may be a UAV, mobile device, UE, TPAE, base station, controller, or other device. In communication 620, UAV 602 can be configured by obtaining a UAV ID and performing credential bootstrapping (e.g., a security certificate). In communication 622, UAV 602 may be registered to and / or connected to a mobile network including first BS 105a and second BS 105b. In communication 624, UAV 602 may register with USS 420 and / or UFMS 422.

[0130] Reference Figure 6A and 6B In some implementations, in communication 630, USS 420 may transmit a location subscription to core network 430 to obtain the updated location of UAV 602. In communication 632, core network 430 may transmit a location report including the last known location of UAV 602 (based on the received remote ID, NRID, or BRID). In an optional implementation, USS 420 may subscribe to UFMS 422 to obtain location information from UFMS 422. In another instance, USS 420 may obtain location information from the Location Service (LCS) of communication network 100. In communication 634, USS 420 and / or UFMS 422 may transmit the certificate associated with UAV 602 (which includes the UAV ID) to core network 430. In operation 636, based on location information received from USS 420 and UFMS 422, core network 430 can determine the geographic location of UAV 602 based on location information (e.g., longitude, latitude, altitude, etc.) in the location report. Core network 430 can determine one or more coverage areas and corresponding base stations associated with the geographic location, such as first BS 105a and first coverage area 130a. In communication 638, core network 430 can provide certificates to first BS 105a and / or second BS 105b after determining that UAV 602 is within the first coverage area 130a.

[0131] In some implementations, during communication 640, UAV 602 may broadcast a BRID. After UAV 602 broadcasts the BRID, a first receiver 604 may receive the BRID from UAV 602. The first receiver 604 may obtain information from the BRID, such as the UAVID of UAV 602. During communication 642, the first receiver 604 may transmit a certificate request including the UAV ID to the first BS 105a (the serving base station of the first receiver 604). In response, the first BS 105a may identify the certificate associated with the UAV ID. During communication 644, the first BS 105a may transmit a certificate response to the first receiver 604 including the certificate (previously received from core network 430 at 638). During operation 646, the first receiver 604 may use the certificate to authenticate the BRID from UAV 602.

[0132] Turn Figure 6A and 6C In some implementations, during communication 650, UAV 602 may broadcast a BRID. After UAV 602 broadcasts the BRID, a second receiver 606 may receive the BRID from UAV 602. The second receiver 606 may obtain information from the BRID, such as the UAV ID of UAV 602. During communication 652, the second receiver 606 may transmit a certificate request, including the UAV ID, to the second BS 105b (e.g., the serving base station of the second receiver 606). In response, during communication 654, the second BS 105b may (e.g., via core network 430) transmit a certificate retrieval message (including the UAV ID of UAV 602) to UFMS 422 to request a certificate. Alternatively, BS 105b may transmit a certificate retrieval message to USS 420 via UFMS to request a certificate. In communication 656, USS 420 and / or UFMS 422 may transmit the certificate associated with the UAV ID of UAV 602 to the second BS 105b in a certificate delivery message. In communication 658, after receiving the certificate delivery message, the second BS 105b may transmit a certificate response including the certificate to the second receiver 606 in response to a certificate request to the second receiver 606. In operation 660, the second receiver 606 may use the certificate to authenticate the BRID from UAV 602.

[0133] Turn Figure 6A and 6DIn some implementations, during communication 662, UAV 602 may broadcast a BRID. After UAV 602 broadcasts the BRID, a second receiver 606 may receive the BRID from UAV 602. The second receiver 606 may obtain information from the BRID, such as the UAV ID of UAV 602. During communication 664, the second receiver 606 may (e.g., via the first BS 105a, the second BS 105b, and / or the core network 430) transmit a certificate request including the UAV ID to USS 420 and / or UFMS 422. During communication 666, in response to receiving the certificate request, USS 420 and / or UFMS 422 may (e.g., via the core network 430, the first BS 105a, and / or the second BS 105b) transmit a certificate response including a certificate associated with the UAV ID to the second receiver 606. In operation 668, the second receiver 606 can use a certificate to authenticate the BRID from UAV 602.

[0134] Reference Figure 6A and 6E In one implementation, at 630, the core network 430 may transmit a location subscription to the USS 420 and / or UFMS 422 to obtain the updated location of UAV 602. In communication 632, the USS 420 and / or UFMS 422 may transmit a location report including the last known location of UAV 602 (based on the received remote ID, NRID, or BRID). In communication 634, the USS 420 and / or UFMS 422 may transmit a certificate associated with UAV 602 (which includes the UAV ID) to the core network 430. In operation 636, the core network 430 may determine the geographic location of UAV 602 based on location information (e.g., longitude, latitude, altitude, etc.) in the remote ID, BRID, and / or NRID. The core network 430 may determine one or more coverage areas and corresponding base stations associated with the geographic location, such as a first BS 105a and a first coverage area 130a. In communication 638, core network 430 may provide a certificate to first BS 105a via a certificate delivery message after determining that UAV 602 is within the first coverage area 130a. In communication 670, UAV 602 may broadcast a BRID. After UAV 602 broadcasts the BRID, the first receiver may receive the BRID from UAV 602. In communication 672, first BS 105a may broadcast a certificate (received from core network 430 at 638) within the first coverage area 130a. First receiver 604 may receive the broadcast certificate. In operation 674, first receiver 604 may use the certificate to authenticate the BRID from UAV 602.

[0135] Figure 7AThis is a sequence diagram illustrating an example of a process 700 for managing UAV identities according to some embodiments. (See also...) Figure 1-7A The process 700 may include a UAV 602, a first receiver 604, a second receiver 606, a first BS 105a, a second BS 105b, a core network 430, a UFMS 422, a USS 420, and a network computing device (NCD) 701. In some implementations, the NCD 701 may be implemented in the core network 430.

[0136] In operation 702, NCD 701 can generate an anonymous token associated with the UAV's digital certificate. In communication 704, NCD 701 can provide the anonymous token to the UAV for use in operation. In some embodiments, NCD 701 can generate multiple anonymous tokens associated with a digital certificate, wherein each of the multiple anonymous tokens is configured with an availability time limit.

[0137] In communication 706, UAV 602 can transmit a UAV message, which is received by a first receiver 604. The UAV message may include an anonymity token and a digital signature associated with the UAV message. The first receiver 604 can send a request for authentication of the UAV, which includes the anonymity token. In some embodiments, the first receiver 604 can send a request 708 to a first BS 105a, and the first BS can send a request to NCD 701 in communication 710.

[0138] In operation 712, NCD 701 may use the anonymous token included in the request to identify the digital certificate associated with UAV 602. In some embodiments, the anonymous token may include a pointer or other information that enables NCD 701 to identify the digital certificate associated with UAV 602.

[0139] In operation 714, NCD 701 can determine whether the digital signature has been verified using a digital certificate. In some embodiments, NCD 701 can use a digital certificate to perform cryptographic verification of the digital signature.

[0140] Based on this determination, NCD 701 may send a response to the first BS 105a in communication 716, and the first BS 105a may send a response to the first receiver 604 in communication 718. In some embodiments, the responses in communication 716 and communication 718 may indicate that the UAV message has been authenticated in response to the determination that the digital signature has been verified using a digital certificate.

[0141] Figure 7B This is a sequence diagram illustrating an example of a process 750 for managing UAV identities according to some embodiments. (See also...) Figure 1-7BThe process 750 may include UAV 602, first receiver 604, second receiver 606, first BS 105a, second BS 105b, core network 430, UFMS 422, USS 420 and NCD 701.

[0142] In communication 752, the first BS 105a may receive an assertion from UAV 602 regarding the UAV's right to perform operations anonymously. In some embodiments, the assertion may include the UAV's anonymity token. In some embodiments, the assertion may include the UAV's digital certificate. The first BS 105a may send a request for authentication of the UAV to NCD 701 in communication 754, wherein the request includes the assertion of the UAV.

[0143] In operation 756, NCD 701 may determine, based on this assertion, whether the UAV is entitled to perform operations anonymously. In some embodiments, NCD 701 may determine whether UAV 602 is associated with a right to anonymous operations. In some embodiments, information indicating such rights may be stored in a data structure and / or a memory device accessible by NCD 701.

[0144] The first BS 105a may receive a response from the NCD 701 in communication 758, the response indicating whether the UAV is authorized to perform operations anonymously. In some embodiments, the first BS 105a may determine whether the UAV is authorized to perform operations anonymously based on the response 758.

[0145] In operation 760, in response to determining that the UAV has been authenticated, the first BS 105a may broadcast information about the UAV whose identity information is not configured, in response to determining that the UAV is authorized to perform operations anonymously. The first BS 105a may send the broadcast in communications 762a, 762b, which may be received by the first receiver 604 and / or the second receiver 606.

[0146] In communication 764, UAV 602 may broadcast a UAV message including the assertion and a digital signature associated with the UAV, which may be received by the first receiver 604. The first receiver 604 may send a request to the first BS 105a to authenticate UAV 602 in communication 766. The request in communication 766 may include the assertion and the digital signature associated with the UAV message from UAV 602.

[0147] The first BS 105a may send a request for an authenticated UAV message to NCD 701 in communication 768. The request in communication 768 may include the assertion and the digital signature of UAV 602. In operation 770, NCD 701 may determine whether UAV 602 is authorized to operate anonymously (e.g., as described above regarding process 700). Figure 7A (As described in operations 712 and 714).

[0148] The first BS 105a may receive a response from the NCD 701 in communication 772, the response indicating whether the UAV message is authenticated. In some embodiments, the first BS 105a may determine whether the UAV message is authenticated based on the response in communication 772.

[0149] In response to determining that the UAV message has been authenticated, the first BS 105a may send an indication in communication 774 to the requesting device (e.g., the first receiver 604) regarding the authentication of the UAV message.

[0150] Figure 8 This is a flowchart illustrating a method 800 for managing UAV identities, executable by a processor of a network computing device according to some embodiments. (Refer to...) Figure 1-8 The operation of method 800 can be executed by the processor of the network processing device.

[0151] In block 802, the processor may generate an anonymous token associated with a digital certificate of the UAV. In some embodiments, the anonymous token may include a cryptographically verifiable indication regarding the association of the anonymous token with the digital certificate of the UAV. In some embodiments, the anonymous token may include or indicate an indication regarding the UAV (and / or the UAV operator)'s right to perform operations anonymously. In some embodiments, each anonymous token may include (or may be) a hash of the digital certificate. In some embodiments, each anonymous token may include a hash of the digital certificate concatenated with a confidential value, which may be stored by or accessible to the network computing device. The means for performing the operations of block 802 may include processor 1301 ( Figure 13 ).

[0152] In some embodiments, the anonymity token may be configured with an availability time limit. For example, the anonymity token may be configured with a lifetime or another time constraint on its availability, which limits the usefulness of the anonymity token to a specified time range or duration outside of which the UAV will not be able to use the anonymity token to perform operations anonymously. In other words, if the UAV uses the token for transmission before or after the time constraint on the anonymity token, the UAV will not be certified by the base station or NCD 701.

[0153] In some embodiments, the anonymity token may be configured with geographic availability restrictions. For example, the anonymity token may be configured with a geofence, coordinates, or another geographic constraint on its availability that limits the usefulness of the anonymity token to a specified location, region, or physical region (such as corresponding to a legal jurisdiction, war zone, or specified delivery route or travel path), outside of which the UAV will not be able to use the anonymity token to perform operations anonymously.

[0154] In block 804, the processor may provide an anonymous token to the UAV for use in operation. In some embodiments, providing an anonymous token to the UAV enables the UAV to perform operations anonymously using the anonymous token. For example, the UAV may associate the anonymous token with a transmission. In some embodiments, the UAV may digitally sign the transmission using a private key associated with the anonymous token. In some embodiments, the anonymous token may be a cryptographic hash of a public key certificate associated with it. In some embodiments, the associated public key certificate may contain a pseudonym to mask the identity of the UAV or its operator. The means for performing the operations of block 802 may include processor 1301, network access ports 1304, and antennas 1307. Figure 13 ).

[0155] In box 806, the processor may receive a request for an authenticated UAV message. This request may include an anonymous token and a digital signature associated with the UAV message. For example, the network computing device may receive this request from UTM infrastructure (such as a base station or other network access point), another UAV, a receiving device (such as a ground station, smartphone, or other wireless device), etc. Means for performing the operations of box 806 may include processor 1301, network access ports 1304, and antennas 1307. Figure 13 ).

[0156] In box 808, the processor may use the anonymous token included in the request to identify the digital certificate. For example, the association between the digital certificate and one or more anonymous tokens may be stored in a memory or memory device accessible by a network computing device. The means for performing the operations of box 802 may include processor 1301. Figure 13 ).

[0157] In block 810, the processor may determine whether the digital signature has been verified using a digital certificate. In some embodiments, the processor may use the digital certificate to perform cryptographic verification of the digital signature. In some embodiments, the processor may use the public key associated with the digital certificate to authenticate the digital signature (and / or authenticate the digitally signed UAV message). The means for performing the operations of block 810 may include processor 1301. Figure 13 ).

[0158] In block 812, in response to determining that the digital signature has been verified using a digital certificate, the processor may send an indication that the UAV message has been authenticated in response to the request. For example, the processor may send this indication to the requesting device. Means for performing the operation of block 812 may include processor 1301, network access ports 1304, and antennas 1307. Figure 13 ).

[0159] Figure 9 This is a flowchart illustrating operation 900 as part of a method 800 for managing UAV identities, executable by a processor of a network computing device according to various embodiments. (Refer to...) Figure 1-9 The operation of method 900 can be executed by the processor of the network processing device. As mentioned above, the UAV can be configured with multiple limited-use anonymity tokens to enhance anonymity or further reduce the traceability of the UAV.

[0160] In block 902, the processor may generate multiple anonymous tokens associated with a digital certificate, wherein each of the multiple anonymous tokens is configured with an availability time limit. For example, each of the multiple anonymous tokens may be useful for a specified time period or duration, including one-time use. In some embodiments, generating multiple anonymous tokens associated with a digital certificate may include generating multiple anonymous tokens using a keyed hash tree. The means for performing the operations of block 902 may include processor 1301 (…). Figure 13 ).

[0161] In block 904, the processor may provide anonymity tokens to the UAV for use in operation, including providing multiple anonymity tokens to the UAV for use in operation, wherein the use of each anonymity token is subject to a corresponding availability time limit. The means for performing the operations of block 904 may include processor 1301, network access ports 1304, and antennas 1307. Figure 13 ).

[0162] The processor can execute method 800 as described. Figure 8 The operation of box 806.

[0163] Figure 10 This is a flowchart illustrating a method 1000 for managing UAV identities according to various embodiments. (Refer to...) Figure 1-10 Method 1000 can be executed by the processor of the base station.

[0164] In block 1002, the processor may receive an assertion from the UAV regarding the UAV's right to perform operations anonymously. In some embodiments, the assertion may include the UAV's digital certificate. In some embodiments, the assertion may include an anonymity token. In some embodiments, the anonymity token may include or be associated with a data structure (such as a digital certificate attribute, pointer, or location identifier) ​​that enables (e.g., by a network computing device) to identify or locate information indicating the UAV's right to perform operations anonymously. In some embodiments, the digital certificate may include information indicating the UAV's right to perform operations anonymously. In some embodiments, the anonymity token may include a cryptographically verifiable indication regarding the association of the anonymity token with the UAV's digital certificate, such as a hash or portion of the hash of the digital certificate. Apparatus for performing the operations of block 1002 may include a processor 312, a modem 320, a transceiver 302, and an RF front-end 388. Figure 3 ).

[0165] In block 1004, the processor may send a request for an authenticated UAV to the network computing device. In such embodiments, the request may include an assertion and a digital signature associated with the UAV. Means for performing the operations of block 1004 may include a processor 312, a modem 320, a transceiver 302, and an RF front-end 388. Figure 3 ).

[0166] In block 1006, the processor may receive a response from the network computing device indicating whether the UAV is authorized to perform operations anonymously. Means for performing the operations of block 1006 may include processor 312, modem 320, transceiver 302, and RF front end 388. Figure 3 ).

[0167] In block 1008, the processor may determine whether the UAV is authorized to perform operations anonymously based on a response received from the network computing device. The means for performing the operations in block 1008 may include processor 312. Figure 3 ).

[0168] In block 1010, the processor may broadcast information about the UAV, for which no identity information is configured, in response to determining that the UAV is authorized to perform operations anonymously. Apparatus for performing the operations of block 1010 may include processor 312, modem 320, transceiver 302, and RF front-end 388. Figure 3 ).

[0169] Figure 11 This is a flowchart illustrating operations 1100 of a method 1000 for managing UAV identities, which can be executed by a base station processor according to various embodiments. (Refer to...) Figure 1-11 Operation 1100 can be executed by the base station's processor.

[0170] In performing method 1000 as described ( Figure 10 Following the operation of box 1010, the processor can receive a request for the identity of the UAV in box 1102. The means for performing the operation of box 1102 may include processor 312, modem 320, transceiver 302, and RF front end 388. Figure 3 ).

[0171] In block 1104, the processor may configure a response message that does not indicate the identity of the UAV based on determining that the UAV is authorized to perform the operation anonymously. In some embodiments, the processor may configure a response message that does not include information indicating the identity of the UAV. In some embodiments, the processor may configure a response message that includes a pseudonym or another identifier of the UAV that does not indicate its identity. In some embodiments, the pseudonym may also be an anonymity token. The means for performing the operation of block 1104 may include processor 312 ( Figure 3 ).

[0172] Figure 12 This is a process flowchart illustrating operations 1200 that can be performed as part of a method 1000 for managing UAV identities according to various embodiments. (Refer to...) Figure 1-12 Operation 1200 can be executed by the base station's processor.

[0173] In performing method 1000 as described ( Figure 10 Following the operation of block 1010, the processor may receive a request for an authenticated UAV message in block 1202, wherein the request includes the assertion and a digital signature associated with the UAV message. In some embodiments, the digital signature structure may include message data already signed with the digital signature of the UAV. Apparatus for performing the operation of block 1202 may include processor 312, modem 320, transceiver 302, and RF front-end 388. Figure 3 ).

[0174] In block 1204, the processor may send a request for an authenticated UAV message to the network computing device, wherein the request includes the assertion and the digital signature. Apparatus for performing the operations of block 1204 may include processor 312, modem 320, transceiver 302, and RF front end 388. Figure 3 ).

[0175] In block 1206, the processor may receive a response from the network computing device indicating whether the UAV message has been authenticated. Means for performing the operations of block 1206 may include processor 312, modem 320, transceiver 302, and RF front end 388. Figure 3 ).

[0176] In block 1208, the processor may send an indication that the UAV message has been authenticated in response to receiving an indication from the network computing device that the UAV message has been authenticated. Apparatus for performing the operations of block 1208 may include processor 312, modem 320, transceiver 302, and RF front end 388. Figure 3 ).

[0177] Figure 13 This is a component block diagram of a network computing device 1300 applicable to various embodiments. Such a network computing device (e.g., NCD 701) may include at least Figure 13 The components explained in the text. See reference. Figure 1-13 The network computing device 1300 typically includes a processor 1301 coupled to volatile memory 1302 and mass non-volatile memory (such as a disk drive 1308). The network computing device 1300 may also include peripheral memory access devices 1306 coupled to the processor 1301, such as floppy disk drives, compact disc (CD) or digital video disc (DVD) drives. The network computing device 1300 may also include a network access port 1304 (or interface) coupled to the processor 1301 for establishing data connections to a network (such as the Internet or a local area network coupled to other system computers and servers). The network computing device 1300 may include one or more antennas 1307 for transmitting and receiving electromagnetic radiation, which may be connected to a wireless communication link. The network computing device 1300 may include additional access ports for coupling to peripheral devices, external memory, or other devices, such as USB, FireWire, Thunderbolt, etc.

[0178] The processor of the network computing device 1300 can be any programmable microprocessor, microcomputer, or one or more multiprocessor chips that can be configured via software instructions (applications) to perform various functions, including some of the functions implemented below. In some wireless devices, multiple processors may be provided, such as one processor within a System-on-a-Chip (SOC) (e.g., 204) dedicated to wireless communication functions and another processor within a SOC (e.g., 202) dedicated to running other applications. Software applications may be stored in memory 1302 and then accessed and loaded into the processor. The processor may include internal memory sufficient to store application software instructions.

[0179] The following paragraphs describe various implementation examples. While some of the following implementation examples are described as example methods, further example implementations may include: example methods discussed in the following paragraphs implemented by a network computing device or base station, the network computing device or base station including a processor configured with processor-executable instructions to perform the operations of the methods of the following implementation examples; example methods discussed in the following paragraphs implemented by a network computing device or base station, the network computing device or base station including means for performing the functions of the methods of the following implementation examples; and example methods discussed in the following paragraphs implemented as a non-transient processor-readable storage medium having processor-executable instructions stored thereon, these processor-executable instructions being configured to cause a processor of the network computing device or base station to perform the operations of these example methods.

[0180] Example 1. A method for managing the identity of an unmanned aerial vehicle (UAV), executed by a processor of a network computing device, comprising: generating an anonymous token associated with a digital certificate of the UAV; providing the anonymous token to the UAV for use in operation; receiving a request for authenticating a UAV message, wherein the request includes the anonymous token and a digital signature associated with the UAV message; using the anonymous token included in the request to identify the digital certificate; determining whether the digital signature has been verified using the digital certificate; and in response to determining that the digital signature has been verified using the digital certificate, sending an indication that the UAV message has been authenticated in response to the request.

[0181] Example 2. The method of Example 1, wherein the anonymous token includes a cryptographically verifiable indication of the association between the anonymous token and the digital certificate.

[0182] Example 3. A method similar to Example 1 or 2, wherein the anonymous token includes an instruction regarding the UAV's right to perform operations anonymously.

[0183] Example 4. A method as in any of Examples 1-3, wherein the digital certificate includes instructions regarding the UAV's right to perform operations anonymously.

[0184] Example 5. A method like any of Examples 1-4, where the anonymous token is associated with an availability time limit.

[0185] Example 6. A method as in any of Examples 1-5, where the anonymous token is associated with availability geographic restrictions.

[0186] Example 7. A method as in any of Examples 1-6, wherein the anonymous token includes a hash of the digital certificate.

[0187] Example 8. A method as in any of Examples 1-7, wherein the anonymous token includes a hash of the digital certificate concatenated with the confidential value.

[0188] Example 9. A method as in any of Examples 1-8, wherein generating the anonymous token associated with the digital certificate of the UAV comprises generating the anonymous token from one of: a hash of the digital certificate, a keyed hash of the digital certificate, or a keyed hash tree of the digital certificate.

[0189] Example 10. A method as in any of Examples 1-9, wherein generating the anonymous token associated with a digital certificate of the UAV includes generating a plurality of anonymous tokens associated with the digital certificate, wherein each of the plurality of anonymous tokens is associated with an availability time limit; and providing the anonymous token to the UAV for use in operation includes: providing the plurality of anonymous tokens to the UAV for use in operation, wherein the use of each anonymous token is subject to a corresponding availability time limit.

[0190] Example 11. The method of Example 10, wherein generating multiple anonymous tokens associated with the digital certificate includes using a keyed hash tree to generate multiple anonymous tokens.

[0191] Example 12. A method for managing the identity of an unmanned aerial vehicle (UAV), executed by a processor of a base station, comprising: receiving from the UAV an assertion that the UAV is authorized to perform operations anonymously; sending a request to a network computing device to authenticate the UAV, wherein the request includes the assertion and a digital signature performed on the assertion; receiving from the network computing device a response indicating whether the UAV is authorized to perform operations anonymously; determining whether the UAV is authorized to perform operations anonymously based on the response received from the network computing device; and in response to determining that the UAV is authorized to perform operations anonymously, broadcasting information about the UAV for which no identity information is configured.

[0192] Example 13. The method as in Example 12, wherein the assertion includes an anonymous token or digital certificate indicating that the UAV is authorized to perform operations anonymously.

[0193] Example 14. A method as in either Example 12 or 13, wherein the assertion comprises a message and an anonymous token, and wherein the digital signature is performed on the message and the anonymous token.

[0194] Example 15. A method like any of Examples 12-14, wherein the assertion includes a pointer to an attribute or data structure indicating that the UAV has the right to perform operations anonymously.

[0195] Example 16. A method as in any of Examples 12-15, further comprising receiving a request for the identity of the UAV; and configuring a response message that does not include the digital certificate-based identity of the UAV based on determining that the UAV is authorized to perform operations anonymously.

[0196] Example 17. The method of Example 13, wherein the anonymous token includes a cryptographically verifiable indication of the association between the anonymous token and the digital certificate of the UAV.

[0197] Example 18. The method of Example 17, wherein the digital certificate encodes information indicating that the UAV is authorized to perform operations anonymously.

[0198] Example 19. A method as in any of Examples 12-18, wherein the assertion includes an anonymous token, which is the product of cryptographic processing and is unambiguously derived from a digital certificate associated with the UAV.

[0199] Example 20. A method as in any of Examples 12-19, wherein broadcasting information about the UAV for which no identity information is configured includes broadcasting one or more pseudonymous certificates associated with the anonymous token.

[0200] Example 21. A method as described in any of Examples 12-20, further comprising: receiving a request for authenticating a UAV message, wherein the request includes an anonymous token associated with the UAV and a digital signature associated with the UAV message; sending a request for authenticating the UAV message to a network computing device, wherein the request includes the anonymous token and the digital signature; receiving from the network computing device a response indicating whether the UAV message has been authenticated; and sending an indication that the UAV message has been authenticated in response to receiving the response from the network computing device indicating that the UAV message has been authenticated.

[0201] Example 22. The method of Example 21, wherein the structure of the digital signature includes the UAV message data, and wherein the digital signature has been generated on the UAV message using the private key of the UAV.

[0202] As used herein, the terms “component,” “module,” “system,” and similar terms are intended to include computer-related entities such as, but not limited to, hardware, firmware, combinations of hardware and software, software, or software in execution configured to perform a particular operation or function. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, or a computer. By extension, both an application running on a wireless device and the wireless device itself can be referred to as a component. One or more components may reside within a process or a thread of execution, and components may be localized on a single processor or core or distributed across two or more processors or cores. Furthermore, these components may execute from various non-transitory computer-readable media on which various instructions or data structures are stored. Components may communicate via local and / or remote processes, function or procedure calls, electronic signals, data packets, memory read / write, and other known network, computer, processor, or process-related communication methods.

[0203] Several different cellular and mobile communication services and standards are available and envisioned for the future, all of which are feasible and benefit from various implementations. These services and standards include, for example, the 3rd Generation Partnership Project (3GPP), Long Term Evolution (LTE) systems, 3rd Generation Wireless (3G), 4th Generation Wireless (4G), 5th Generation Wireless (5G) and subsequent 3GPP technologies, Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), 3GSM, Universal Packet Radio Service (GPRS), Code Division Multiple Access (CDMA) systems (e.g., cdmaOne, CDMA1020TM), Enhanced Data Rate GSM Evolution (EDGE), Advanced Mobile Phone Systems (AMPS), Digital AMPS (IS-136 / TDMA), Evolved Data Optimization (EV-DO), Digital Enhanced Cordless Telecommunications (DECT), Global Interoperability for Microwave Access (WiMAX), Wireless Local Area Networks (WLAN), Wi-Fi Protected Access I and II (WPA, WPA2), and Integrated Digital Enhanced Network (iDEN). Each of these technologies relates to the transmission and reception of, for example, voice, data, signaling, and / or content messages. It should be understood that any references to terms and / or technical details relating to individual telecommunications standards or technologies are for illustrative purposes only and are not intended to limit the scope of the claims to a particular communication system or technology, unless specifically stated in the language of the claims.

[0204] The various embodiments illustrated and described are provided merely as examples illustrating the various features of the claims. However, the features shown and described with respect to any given embodiment are not necessarily limited to the associated embodiment and may be used in conjunction with or combined with other illustrated and described embodiments. Furthermore, the claims are not intended to be limited to any single example embodiment. For example, one or more of methods and operations 800, 900, 1000, and 1100 may replace or combine one or more of methods and operations 800, 900, 1000, and 1100.

[0205] The foregoing method descriptions and process flow diagrams are provided as illustrative examples only and are not intended to require or imply that the operations of the various embodiments must be performed in the given order. As those skilled in the art will appreciate, the order of operations in the foregoing embodiments can be performed in any order. Terms such as “afterward,” “following,” and “next” are not intended to limit the order of operations; these terms are used to guide the reader through the description of the method. Furthermore, any reference to a singular claim element (e.g., references using the articles “a,” “some,” or “the”) should not be construed as limiting that element to the singular.

[0206] The various illustrative logic blocks, modules, components, circuits, and algorithmic operations described in conjunction with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability between hardware and software, the various illustrative components, blocks, modules, circuits, and operations are described above in a generalized manner in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in different ways for each specific application, but such implementation decisions should not be construed as causing a departure from the scope of the claims.

[0207] The hardware used to implement the various illustrative logics, logic blocks, modules, and circuits described in conjunction with the embodiments disclosed herein may be implemented or executed using a general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof. The general-purpose processor may be a microprocessor, but in alternatives, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of receiver intelligent objects, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors cooperating with a DSP core, or any other such configuration. Alternatively, some operations or methods may be performed by a circuit system dedicated to a given function.

[0208] In one or more embodiments, the described functionality may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, such functionality may be stored as one or more instructions or code on a non-transient computer-readable storage medium or a non-transient processor-readable storage medium. The operation of the methods or algorithms disclosed herein may be implemented in a processor-executable software module or processor-executable instructions, which may reside on a non-transient computer-readable or processor-readable storage medium. A non-transient computer-readable or processor-readable storage medium may be any storage medium accessible to a computer or processor. By way of example and not limitation, such a non-transient computer-readable or processor-readable storage medium may include RAM, ROM, EEPROM, flash memory, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage smart objects, or any other medium that can be used to store desired program code in the form of instructions or data structures and is accessible to a computer. As used herein, disk and disc include compact discs (CDs), laser discs, optical discs, digital multi-purpose discs (DVDs), floppy disks, and Blu-ray discs. Disks typically reproduce data magnetically, while discs reproduce data optically using lasers. Combinations of these media are also included within the scope of non-transient computer-readable and processor-readable media. Furthermore, the operation of a method or algorithm may reside as a piece of code and / or instruction, or any combination or set of code and / or instructions, on a non-transient processor-readable and / or computer-readable storage medium that can be incorporated into a computer program product.

[0209] The prior description of the disclosed embodiments is intended to enable any person skilled in the art to make or use these claims. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein can be applied to other embodiments without departing from the scope of the claims. Thus, this disclosure is not intended to be limited to the embodiments shown herein, but should be accorded the broadest scope consistent with the appended claims and the principles and novel features disclosed herein.

Claims

1. A method for managing the identity of an unmanned aerial vehicle (UAV), executed by a processor of a network computing device, comprising: Generate anonymous tokens associated with the UAV's digital certificate; The anonymous token is provided to the UAV for use in operation; Receive a request for an authenticated UAV message, wherein the request includes the anonymity token and a digital signature associated with the UAV message; Use the anonymous token included in the request to identify the digital certificate; Determine whether the digital signature has been verified using the digital certificate; as well as In response to determining that the digital signature has been verified using the digital certificate, an indication is sent regarding the UAV message indicating that it has been authenticated in response to the request.

2. The method of claim 1, wherein the anonymity token includes a cryptographically verifiable indication of the association between the anonymity token and the digital certificate.

3. The method of claim 1, wherein the anonymity token includes an indication that the UAV is authorized to perform operations anonymously.

4. The method of claim 1, wherein the digital certificate includes an instruction regarding the UAV's right to perform operations anonymously.

5. The method of claim 1, wherein the anonymous token is associated with an availability time limit.

6. The method of claim 1, wherein the anonymous token is associated with availability geographic restrictions.

7. The method of claim 1, wherein the anonymity token comprises one of the following: a hash of the digital certificate, or a hash of the digital certificate concatenated with a confidential value.

8. The method of claim 1, wherein generating the anonymous token associated with the digital certificate of the UAV comprises generating the anonymous token from one of: a hash of the digital certificate, a keyed hash of the digital certificate, or a keyed hash tree of the digital certificate.

9. The method of claim 1, wherein: Generating the anonymous token associated with the digital certificate of the UAV includes generating a plurality of anonymous tokens associated with the digital certificate, wherein each of the plurality of anonymous tokens is associated with an availability time limit; as well as Providing the anonymous tokens to the UAV for use in operation includes: providing the plurality of anonymous tokens to the UAV for use in operation, wherein the use of each anonymous token is subject to a corresponding availability time limit.

10. The method of claim 9, wherein generating a plurality of anonymous tokens associated with the digital certificate comprises using a keyed hash tree to generate the plurality of anonymous tokens.

11. A network computing device, comprising: Processor, the processor being configured with processor-executable instructions to: Generate anonymous tokens associated with the digital certificates of unmanned aerial vehicles (UAVs); The anonymous token is provided to the UAV for use in operation; Receive a request for an authenticated UAV message, wherein the request includes the anonymity token and a digital signature associated with the UAV message; Use the anonymous token included in the request to identify the digital certificate; Determine whether the digital signature has been verified using the digital certificate; as well as In response to determining that the digital signature has been verified using the digital certificate, an indication is sent regarding the UAV message indicating that it has been authenticated in response to the request.

12. The network computing device of claim 11, wherein the processor is further configured with processor-executable instructions such that the anonymous token includes a cryptographically verifiable indication regarding the association of the anonymous token with the digital certificate.

13. The network computing device of claim 11, wherein the processor is further configured with processor-executable instructions such that the anonymous token includes an indication that the UAV is authorized to perform operations anonymously.

14. The network computing device of claim 11, wherein the processor is further configured with processor-executable instructions such that the digital certificate includes instructions regarding the UAV's right to perform operations anonymously.

15. The network computing device of claim 11, wherein the processor is further configured with processor-executable instructions to associate the anonymous token with an availability time limit.

16. The network computing device of claim 11, wherein the processor is further configured with processor-executable instructions to associate the anonymous token with availability geographic restrictions.

17. The network computing device of claim 11, wherein the processor is further configured with processor-executable instructions such that the anonymous token includes one of: a hash of the digital certificate, or a hash of the digital certificate concatenated with a confidential value.

18. The network computing device of claim 11, wherein the processor is further configured with processor-executable instructions to generate the anonymous token from one of: a hash of the digital certificate, a keyed hash of the digital certificate, or a keyed hash tree of the digital certificate.

19. The network computing device of claim 11, wherein the processor is further configured with processor-executable instructions to: Generate a plurality of anonymous tokens associated with the digital certificate, wherein each of the plurality of anonymous tokens is associated with an availability time limit; and The plurality of anonymous tokens are provided to the UAV for use in operation, wherein the use of each anonymous token is subject to a corresponding availability time limit.

20. The network computing device of claim 19, wherein the processor is further configured with processor-executable instructions to generate a plurality of anonymous tokens using a keyed hash tree.

21. A network computing device, comprising: A device for generating anonymous tokens associated with digital certificates for unmanned aerial vehicles (UAVs); A means for providing the anonymous token to the UAV for use in operation; A means for receiving a request for an authenticated UAV message, wherein the request includes the anonymous token and a digital signature associated with the UAV message; A means for identifying the digital certificate using the anonymous token included in the request; A means for determining whether the digital signature has been verified using the digital certificate; as well as A means for sending an indication that the UAV message has been authenticated in response to a determination that the digital signature has been verified using the digital certificate.

22. The network computing device of claim 21, wherein the anonymity token includes a cryptographically verifiable indication of the association between the anonymity token and the digital certificate.

23. The network computing device of claim 21, wherein the anonymity token includes an indication that the UAV is authorized to perform operations anonymously.

24. The network computing device of claim 21, wherein the digital certificate includes an instruction regarding the UAV's right to perform operations anonymously.

25. The network computing device of claim 21, wherein the anonymous token is associated with an availability time limit.

26. The network computing device of claim 21, wherein the anonymous token is associated with availability geographic restrictions.

27. The network computing device of claim 21, wherein the anonymity token comprises one of the following: a hash of the digital certificate, or a hash of the digital certificate concatenated with a confidential value.

28. The network computing device of claim 21, wherein the means for generating the anonymous token associated with the digital certificate of the UAV includes means for generating the anonymous token from one of: a hash of the digital certificate, a keyed hash of the digital certificate, or a keyed hash tree of the digital certificate.

29. The network computing device of claim 21, wherein: The apparatus for generating the anonymous token associated with a digital certificate of a UAV includes means for generating a plurality of anonymous tokens associated with the digital certificate, wherein each of the plurality of anonymous tokens is associated with an availability time limit; and The means for providing the anonymous tokens to the UAV for use in operation includes: means for providing the plurality of anonymous tokens to the UAV for use in operation, wherein the use of each anonymous token is subject to a corresponding availability time limit.

30. The network computing device of claim 29, wherein the means for generating a plurality of anonymous tokens associated with the digital certificate includes means for generating the plurality of anonymous tokens using a keyed hash tree.

Images