CN117203998A

CN117203998A - Managing unmanned aerial vehicle identity

Info

Publication number: CN117203998A
Application number: CN202280030012.1A
Authority: CN
Inventors: D·F·范杜伦
Original assignee: Qualcomm Inc
Current assignee: Qualcomm Inc
Priority date: 2021-04-27
Filing date: 2022-02-24
Publication date: 2023-12-08

Abstract

In embodiments of a system and method for managing Unmanned Aerial Vehicle (UAV) identity, a processor of a network computing device may: 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 the UAV, wherein the request includes the anonymous token; determining whether an anonymous token included in the request is associated with the digital certificate; and in response to determining that the anonymous token included in the request is associated with the digital certificate, sending an indication that the UAV is authenticated in response to the request.

Description

Managing unmanned aerial vehicle identity

RELATED APPLICATIONS

The present application claims priority from U.S. provisional application No.63/180,502 entitled "Managing An Unmanned Aerial Vehicle Identity (managing unmanned aerial vehicle identity)" filed on month 27 of 2021 and U.S. non-provisional application No.17/482,525 entitled "Managing An Unmanned Aerial Vehicle Identity (managing unmanned aerial vehicle identity)" filed on month 23 of 2021, the entire contents of which are hereby incorporated by reference herein for all purposes.

Background

Wireless communication networks are widely deployed to provide various types of communication content such as voice, video, packet data, messaging, broadcast, and so on. These systems may be multiple-access systems capable of supporting communication with multiple users by sharing the 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.

These multiple access techniques have been adopted in various telecommunications standards to provide a common protocol that enables different wireless devices to communicate at the urban, national, regional, and even global levels. For example, fifth generation (5G) wireless communication technologies, which may be referred to as New Radios (NRs), are designed to expand and support diverse usage scenarios and applications relative to current mobile network generations. In an aspect, the 5G communication technique may include: enhanced mobile broadband for accessing multimedia content, services and data for people-centric use cases; ultra Reliable Low Latency Communications (URLLC) with certain specifications regarding latency and reliability; and large-scale machine type communications, which may allow for a very large number of connected devices and transmission of relatively small amounts of non-delay sensitive information. However, as the demand for mobile broadband access continues to grow, further improvements to NR communication technology and supernr technology may be desired.

Unmanned air system traffic management (UTM) is under development to function as a traffic management ecosystem for Unmanned Aerial Vehicle (UAV) operation that is separate from but complementary to the Air Traffic Management (ATM) system. In many operating scenarios, communications from the UAV require digital certificates to enable the recipient device to authenticate the information sent from the UAV. For example, on-board applications (such as remote IDs and detecting and avoiding messaging) may require trusted, authenticated messages signed by an encrypted private key that can be cryptographically verified (e.g., using its public key certificate).

Typical digital certificates provided by a UAV may include an identifier of the UAV and its operator, which may enable the UAV to be tracked and correlated with known operators or organizations. Some UAV operators may require operator privacy by the nature of their identity, role, or task, but authenticatable messages must still be signed and broadcast for security and other operational purposes.

SUMMARY

Various aspects include systems and methods for managing UAV identity performed by a processor of a base station. Some aspects may include: receiving an assertion from the UAV that the UAV has authority to perform operations anonymously; transmitting a request to authenticate the UAV to a network computing device, wherein the request may include the assertion and a digital signature performed on the assertion; receiving a response from the network computing device indicating whether the UAV has the right to perform an operation anonymously; determining, based on the response received from the network computing device, whether the UAV has the right to perform an operation anonymously; and in response to determining that the UAV is entitled to perform an operation anonymously, broadcasting information about the UAV that does not configure identity information of the UAV.

In some aspects, the asserting may include: an anonymous token or digital certificate indicating that the UAV has the right to perform an operation anonymously. In some aspects, the anonymous token may include a cryptographically verifiable indication that the anonymous token is associated with a digital certificate of the UAV. In some aspects, the digital certificate encodes information indicating that the UAV has authority to perform operations anonymously. In some aspects, the assertion may include a message and an anonymous token, and wherein the digital signature is performed on the message and the anonymous token. In some aspects, the assertion may include an attribute or data structure pointer to information indicating that the UAV has authority to perform the operation anonymously. Some aspects may include: receiving a request for an identity of a 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 entitled to anonymously perform the operation.

In some aspects, the assertion comprises an anonymous token that is a product of the cryptographic process and that is unambiguously derived from a digital certificate associated with the UAV. In some aspects, broadcasting information about the UAV that does not configure identity information of the UAV in response to determining that the UAV has the authority to perform operations anonymously may include: one or more pseudonymous certificates associated with the anonymous token are broadcast.

Some aspects may include: receiving a request to authenticate a UAV message, wherein the request may include an anonymous token associated with the UAV and a digital signature associated with the UAV message; transmitting a request to authenticate the UAV message to a network computing device, wherein the request may include the anonymous token and the digital signature; receiving a response from the network computing device indicating whether the UAV message is authenticated; and send an indication that the UAV message is authenticated in response to receiving a response from the network computing device indicating that the UAV message is authenticated. In some aspects, the structure of the digital signature may include UAV message data, and the digital signature is generated on the message using a private key of the UAV.

Further aspects may include a base station having a processing system configured to perform one or more operations of any of the methods outlined above. A further aspect includes processing devices for use in a base station configured with processor-executable instructions for performing the operations of any of the methods outlined above. Further aspects include a non-transitory processor-readable storage medium having stored thereon processor-executable instructions configured to cause a processor of a base station to perform operations of any of the methods outlined above. A further aspect includes a base station having means for performing the functions of any of the methods outlined above.

Brief Description of Drawings

The disclosed aspects will hereinafter be described in conjunction with the appended drawings, provided to illustrate and not to limit the disclosed aspects, wherein like designations denote like elements, and in which:

fig. 1 is a diagram illustrating an example of a wireless communication system and an access network.

Fig. 2 is a schematic diagram of an example of a user equipment, such as a mobile device or UAV.

Fig. 3 is a schematic diagram of an example of a base station.

FIG. 4 is a schematic diagram of an example of an environment for managing a UAV.

Fig. 5 is a sequence diagram of an example of a process for distributing credentials by a UAV.

Fig. 6A is a sequence diagram of an example of a UAV initialization process into the network.

Fig. 6B is a sequence diagram of a first example of a process of distributing certificates by a base station.

Fig. 6C is a sequence diagram of a second example of a process of distributing certificates by a base station.

Fig. 6D is a sequence diagram of an example of a process of obtaining a certificate by a recipient.

Fig. 6E is a sequence diagram of an example of a process of broadcasting a certificate by a base station.

Fig. 7A is a sequence diagram of an example of a process of managing UAV identity.

Fig. 7B is a sequence diagram of an example of a process of managing UAV identity.

Fig. 8 is a process flow diagram illustrating a method for managing UAV identity that may be performed by a processor of a network computing device, in accordance with various embodiments.

Fig. 9 is a process flow diagram illustrating operations that may be performed by a processor of a network computing device as part of a method for managing UAV identity, in accordance with various embodiments.

Fig. 10 is a process flow diagram illustrating a method for managing UAV identity that may be performed by a processor of a base station, in accordance with various embodiments.

Fig. 11 is a process flow diagram illustrating operations that may be performed by a processor of a base station as part of a method for managing UAV identity, in accordance with various embodiments.

Fig. 12 is a process flow diagram illustrating operations that may be performed by a processor of a base station as part of a method for managing UAV identity, in accordance with various embodiments.

FIG. 13 is a component block diagram of a network computing device suitable for use with the various embodiments.

Detailed Description

The detailed description set forth below in connection with the appended drawings is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of the various concepts. It will be apparent, however, to one skilled in the art that these concepts may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form in order to avoid obscuring such concepts.

Several aspects of the telecommunications system will now be presented with reference to various apparatus and methods. These apparatus and methods will be described in the following detailed description and illustrated in the accompanying drawings by various blocks, components, circuits, processes, algorithms, etc. (collectively referred to as "elements"). These elements may be implemented using electronic hardware, computer software, or any combination thereof. Whether such elements are implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system.

As an example, an element, or any portion of an element, or any combination of elements, may be implemented as a "processing system" that includes 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 (SoC), baseband processors, field Programmable Gate Arrays (FPGAs), programmable Logic Devices (PLDs), state machines, gate logic, discrete hardware circuits, and other suitable hardware configured to perform the various functionalities described throughout this disclosure. One or more processors in the processing system may execute the software. Software should be construed broadly to mean instructions, instruction sets, code segments, program code, programs, subroutines, software components, applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, etc., whether described in software, firmware, middleware, microcode, hardware description language, or other terminology.

Accordingly, in one or more example embodiments, the described functionality may be implemented in hardware, software, or any combination thereof. If implemented in software, the functions may be stored on or encoded on a computer-readable medium as one or more instructions or code. Computer readable media includes computer storage media. A storage media may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise 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 the above-described types of computer-readable media, or any other medium that can be used to store computer-executable code in the form of instructions or data structures that can be accessed by a computer.

In an implementation, the UAV may segment the credentials into segments. The UAV may embed each segment of the credential into a frame. Frames containing the segmented segments may be sequentially transmitted by the UAV. The UAV may transmit a broadcast remote identification. The recipient of the broadcast remote identification and/or the certificate fragments may attach the certificate fragments to certificates to be used for authenticating the broadcast remote identification.

In some implementations, the broadcast remote identity may be a mobile identity (associated with the mobile device or UAV) declared during the broadcast process. In other examples, the broadcast remote identification may be a certificate associated with or containing the mobile identification. The mobile identification may be a serial number, a government issued identifier, a universally unique identification, or the like.

Various embodiments will be described in detail with reference to the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts. References made to particular examples and implementations are for illustrative purposes, and are not intended to limit the scope of the claims.

Various embodiments include systems and methods performed by a network computing device and a base station to manage the identity of a UAV. Various embodiments may be used to enable UAVs and base stations to perform operations while conveying information required for security or other purposes without conveying certain identifying information that may enable UAVs to be tracked or related to a particular UAV operator.

While the present description refers to a UAV for brevity, it will be appreciated that the UAV may comprise one of various types of vehicles (including an onboard computing device configured to provide some autonomous or semi-autonomous capability). Examples of such vehicles include, but are not limited to: an aircraft, such as a UAV; ground vehicles (e.g., autonomous or semi-autonomous automobiles, vacuum robots, etc.); water-based vehicles (i.e., vehicles configured for operation on the water or underwater); and/or some combination thereof. In some embodiments, the vehicle may be manned. In other embodiments, the vehicle may be unmanned. In embodiments where the vehicle is autonomous, the vehicle may include an on-board computing device configured to maneuver and/or navigate the vehicle without (i.e., autonomously) remote operation instructions, such as from a human operator (e.g., via a remote computing device). In embodiments where the vehicle is semi-autonomous, the vehicle may include an on-board computing device configured to receive certain information or instructions (such as from a human operator (e.g., via a remote computing device)) and autonomously maneuver and/or navigate the vehicle in accordance with the received information or instructions. In some implementations, the vehicle may be an aircraft (unmanned or manned), which may be a rotary or winged aircraft. For example, a rotorcraft (also known as a multi-rotor or multi-axis aircraft) may include a plurality of propulsion units (e.g., rotor/propellers) that provide thrust and/or lift to the vehicle. Specific non-limiting examples of rotorcraft include triaxial (three rotors), tetraxial (four rotors), hexaxial (six rotors), and octaxial (eight rotors). However, a rotorcraft may include any number of rotors. The vehicle may include various components and/or payloads that may perform various functions. The term "component" when used in reference to a vehicle includes a vehicle component and/or a vehicle payload.

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 integrated resources and processors, and for controlling peripheral devices.

The term "system in package" (SIP) may be used herein to refer to a single module or package that contains multiple resources, computing units, cores or processors on two or more IC chips, substrates, or SOCs. For example, SIP may include a single substrate on which multiple IC chips or semiconductor dies are stacked in a vertical configuration. Similarly, SIP may include one or more multi-chip modules (MCMs) on which multiple ICs or semiconductor die are packaged into a unified substrate. SIP may also include multiple independent SOCs coupled together via high-speed communication circuitry and packaged together in close proximity, such as on a single motherboard or in a single wireless device. The proximity of the SOC facilitates high-speed communication and sharing of memory and resources.

As used herein, the terms "network," "system," "wireless network," "cellular network," and "wireless communication network" may interchangeably refer to a portion or all of a wireless network of an operator associated with a wireless device and/or subscription on a wireless device. The techniques described herein may be used for various 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. In general, any number of wireless networks may be deployed in a given geographic area. Each wireless network may support at least one radio access technology that may operate over one or more frequencies or frequency ranges. For example, a CDMA network may implement Universal Terrestrial Radio Access (UTRA) (including Wideband Code Division Multiple Access (WCDMA) standards), CDMA2000 (including IS-2000, IS-95, and/or IS-856 standards), and the like. In another example, the TDMA network may implement GSM enhanced data rates for GSM evolution (EDGE). In another example, the OFDMA network may implement evolved UTRA (E-UTRA) (including the LTE standard), institute of Electrical and Electronics Engineers (IEEE) 802.11 (WiFi), IEEE 802.16 (WiMAX), IEEE 802.20, flash-OFDM, and so on. Reference may be made to wireless networks using the LTE standard, and thus the terms "evolved universal terrestrial radio access", "E-UTRAN" and "eNodeB" may also be used interchangeably herein to refer to wireless networks. However, such references are provided by way of example only 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 future generations of systems (e.g., sixth generation (6G) or higher generation systems) may be substituted in various examples.

Typically, communications from the UAV may be required to include digital certificates that enable the recipient device to authenticate information sent from the UAV. Such communications may include, for example, anticipated maneuver and other flight operations, observations of other traffic and environments, and so forth. Requiring digital signatures for such communications enables authentication of the source of such information. Typical UAV digital certificates are static and may include the identity of the UAV and its operator, which may enable tracking of the UAV and correlation with known operators or organizations. As mentioned above, some UAV operators may desire the ability to operate the UAV anonymously, by the nature of their identity, role, or task, while still signing and transmitting authenticatable messages for security and other operational purposes.

Various embodiments include methods of managing UAV identities, and network computing devices and base stations configured to implement these methods. In various embodiments, a UAV may be configured with rights or permissions to perform operations without transmitting certain identifying information of the UAV or its operator, which may enable tracking or correlating the UAV with its operator. Examples of such identification information are digital certificates of or associated with UAVs. As used herein, performing an operation without transmitting such identification information is referred to as "anonymously" performing the operation. In various embodiments, when the UAV is operating anonymously, the UAV may be configured to send messages (e.g., digitally signed messages) without such identifying information (such as digital signatures). Furthermore, devices that receive such messages (e.g., digitally signed messages) from the UAV will not be provisioned or provide information (e.g., digital signatures) that identifies the UAV. Furthermore, elements of the UTM (such as the base station) may configure messages with information about the UAV without the identity information of the UAV (such as the digital signature of the UAV). For example, certain operators (such as law enforcement or military authorities) may need to operate UAVs anonymously from time to time, such as to perform traffic observation, monitoring operations, and the like. As another example, a commercial package deliverer may obtain permission to anonymously operate some UAV to protect confidential business operations from observation, confidential delivery of packages (such as confidential legal, medical, or business documents, pharmaceutical prescriptions, medical instruments or devices, medical specimens for testing, organs for transplantation, etc.), and the like.

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 a digital certificate of a UAV. 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 digital certificates to generate the anonymous token.

The UAV may be configured with an anonymous token, and the UAV may associate the anonymous token with the transmission (referred to herein as a "UAV message"). The anonymous token may enable the recipient to request authentication of the transmitting and/or transmitting party UAV without receiving identification information of the UAV and/or UAV operator. In some embodiments, the UAV may digitally sign the UAV message using an encryption key associated with the UAV. In some embodiments, the anonymous token may include a cryptographically verifiable indication that the anonymous token is associated with a digital certificate of the UAV. In some embodiments, the anonymized token may include an indication that the UAV (and/or UAV operator) has authority to anonymously perform the operation.

In some embodiments, the network computing device may receive a request to authenticate the UAV message. For example, the network computing device may receive the request from a UTM infrastructure (such as a base station or other network access point), another UAV, a recipient device (such as a ground station, smart phone, or other suitable device), and so forth. In some embodiments, the request may include an anonymous token and a digital signature associated with the UAV message. In some embodiments, the request may include message information (sometimes referred to as "signed data") that has been signed with a digital signature. The network computing device may identify the digital certificate using the anonymous token included in the request. For example, the network computing device may identify a digital certificate associated with the anonymous token. In some embodiments, the association between the digital certificate and the one or more anonymous tokens may be stored in a memory or memory device accessible by the network computing device.

In some embodiments, the network computing device may determine whether the digital signature is verified using a digital certificate. In some embodiments, the network computing device may use the digital certificate to perform verification of the digital signature. In some embodiments, the network computing device may use the digital certificate to cryptographically verify the digital signature. In some embodiments, cryptographic verification of the digital signature using the digital certificate may indicate that the UAV message is authentic and/or the sender UAV may be considered a trusted source. In some embodiments, in response to determining that the digital signature verifies using the digital certificate, the network computing device may send an indication that the message was authenticated in response to the request.

In some embodiments, the anonymous token may include a cryptographically verifiable indication that the anonymous token is associated with a digital signature. In some embodiments, the anonymous token may comprise a hash of the digital certificate. In some embodiments, the anonymous token may comprise a portion of a hash of the digital certificate. In some embodiments, the anonymous token may comprise a hash of a digital certificate concatenated with the secret value. In some embodiments, the network computing device may use such a hash of the digital certificate (or a hash concatenated with the secret value) to obtain (e.g., find) the digital certificate. In various embodiments, the data structure of the anonymous token may be configured to include various encoded information and/or associations with other data, without limitation.

In some embodiments, the anonymous token may be associated with an availability time limit. For example, the anonymous token may be associated with a survival time or another time constraint on its availability that limits the usefulness of the anonymous token to a specified time range or duration beyond which the UAV would not be able to use the anonymous token to anonymously perform operations. In some embodiments, the anonymous token may include or be associated with an encoding of the availability time limit. In some embodiments, the network computing device may determine the association of the anonymous token with the availability time limit, for example, by referencing information stored in a data structure (such as a database).

In some embodiments, the anonymous token may be associated with a geographic restriction of availability. For example, the anonymous token may be associated with a geofence, coordinates, or another geographic constraint on its availability that limits the usefulness of the anonymous token to a designated location, area, or physical zone (such as may correspond to a legal jurisdiction, a war zone, or a designated delivery route or travel path, etc.), beyond which the UAV would not be able to use the anonymous token to anonymously perform operations. In some embodiments, the anonymous token may include or be associated with a code of a geographic limitation of availability. In some embodiments, the network computing device may determine the association of the anonymous token with the availability geographic limit, for example, by referencing information stored in a database or other suitable data structure.

In some embodiments, to enhance the ability of the UAV to anonymously perform operations, the network computing device may generate a plurality of anonymous tokens associated with digital certificates of the UAV, and the plurality of anonymous tokens may be configured in (e.g., uploaded to and stored in) a memory of the UAV. In some embodiments, 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 a plurality of anonymous tokens. In some embodiments, the network computing device may generate a plurality of anonymous tokens using a keyed hash of the digital certificate. In some embodiments, the network computing device may generate a plurality of anonymous tokens using a keyed hash tree of the digital certificate. In some embodiments, a network computing device may maintain secret keys that are used by the network computing device in a keyed hashing process to generate a plurality of anonymous tokens. 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 among a plurality of anonymous tokens for use in the transmission. In some embodiments, each of the plurality of anonymous tokens may be configured with an availability time limit. In some embodiments, each of the plurality of anonymous tokens may be limited to use in a single transmission (i.e., one-time use). In this way, the UAV may transmit an authenticatable and anonymous message regarding the identity of the UAV and/or its operator.

In various embodiments, a base station, access point, or other device providing a wireless communication link and supporting access to a communication network (collectively referred to herein as a "base station" for brevity) may be configured to perform a method for managing UAV identity. In some embodiments, the base station may be configured to receive an assertion from the UAV that the UAV has authority to perform operations anonymously. In some embodiments, the assertion may include an anonymous token or digital certificate, and the anonymous token or digital certificate may include an indication that the UAV is entitled to perform the operation anonymously (such as information including the assertion). In some embodiments, the assertion may include a message and an anonymous token. In some embodiments, digital signing is performed on the message and the anonymous token. In some embodiments, the assertion may include an attribute or data structure pointer that points to information that indicates that the UAV has the right to perform the operation anonymously. The data structure pointer may be a record locator or other suitable information that points to the location of information in a data structure, such as a database. In some embodiments, such databases may be managed or accessed by a network computing device. In some embodiments, the anonymous token included in the assertion may be a 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 that the anonymous token is associated with a digital certificate of the UAV.

In some embodiments, the base station may send a request to the network computing device to authenticate the UAV, where the request includes the assertion and a digital signature performed on the assertion. In some embodiments, the digital signature may include signed data originally sent from the UAV. The base station may receive a response from the network computing device indicating whether the UAV has the right to perform the operation anonymously. Based on the response from the network computing device, the base station may determine whether the UAV has authority to operate anonymously. In response to determining that the UAV is entitled to anonymous operation, the base station may broadcast information about the UAV that does not configure identity information of the UAV. In some embodiments, the broadcast may additionally include one or more pseudonym certificates associated with the anonymous token that may be used by other UTM entities to authenticate the UAV broadcast without receiving information about the UAV identity.

The base station may be configured to handle a request from another device that the base station authenticate the UAV. Non-limiting examples of another device that may issue such a request include another UAV, a recipient device (such as a ground station), a smart phone, or a UAV controller device, among others. In some embodiments, the base station may receive a request to authenticate the UAV message, where the request includes an anonymous token associated with the UAV and a digital signature associated with the UAV, which are included in the UAV message. For example, other devices may receive a UAV message from a UAV and extract a digital signature or assertion in another signed data structure from the UAV message. Other devices may include the received assertion and digital signature in a request (e.g., to a base station) for authentication of the UAV message. In some embodiments, the digital signature may include message data that has been signed with the digital signature.

Upon receiving such a request, the base station may send a request to the network computing device to authenticate the UAV message, where the request includes the anonymous token and a digital signature associated with the UAV message (e.g., digitally signed UAV message, 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 is authenticated. In some embodiments, the base station may determine whether the UAV message is authenticated based on a response from the network computing device. In some embodiments, the base station may relay or relay an indication received from the network computing device as to whether the UAV message is authenticated. In this way, the base station may send an indication that the UAV message is authenticated. In some embodiments, the structure of the digital signature may include UAV message data. In some embodiments, a digital signature may be generated on the UAV message using a private key of the UAV.

Various embodiments may be implemented in a variety of scenarios. For example, law enforcement UAVs may perform scout operations in areas where other UAVs are concurrently operating, requiring the exchange of detection and avoidance (DAA) messages to avoid an unsuccessful event or collision with these other UAVs. In non-anonymous operation, the law enforcement UAV drone may transmit its digital certificate along with the signed DAA message, or may make its digital certificate available to the message recipient via the UTM infrastructure (e.g., upon request via the base station) so that the message recipient can cryptographically verify and trust the message received from the UAV. When the law enforcement UAV anonymously performs operations, the law enforcement UAV may digitally sign the transmitted message with an anonymous token that may be associated with a public key certificate. Further, the law enforcement UAV may send a notification, command, or request to a UTM infrastructure (e.g., a base station) that digital certificates associated with the law enforcement UAV are not broadcast. A recipient device that needs to authenticate transmissions received from the UAV may send a request to a base station or remote verification service (e.g., a network computing device) that may perform operations to provide confirmation or denial of authentication of the UAV's transmissions while not revealing the identity of the law enforcement UAV or its operator.

As another example, a business package delivery UAV operator may desire to operate his UAV anonymously, for example, to prevent competitors from analyzing his business operations, or facilitating the shipment of sensitive or confidential documents, drugs, medical devices, and the like. To accommodate such scenarios, UAV operators may be granted an exemption to transmit certain static or trackable message content or otherwise make their credentials available to other entities. Subsequently, when such an operator's UAV anonymously performs an operation, the UAV may digitally sign transmissions associated with anonymous tokens that enable authentication of the transmissions and/or the UAV and/or UAV operator without revealing the identity of the UAV and/or UAV operator.

Fig. 1 is a diagram illustrating an example of a wireless communication system and an access network 100. A wireless communication system, also known as a Wireless Wide Area Network (WWAN), includes at least one BS105, a UE 110, an Evolved Packet Core (EPC) 160, and a 5G core (5 GC) 190.BS105 may include macro cells (high power cell base stations) and/or small cells (low power cell base stations). The macrocell includes a base station. Small cells include femtocells, picocells, and microcells. In one implementation, a User Equipment (UE) 110 may include a communication component 222. The communication component 222 and/or modem 220 of the UE 110 may be configured to communicate with the BS105 or other UE 110 via a cellular network, wi-Fi network, or other wireless and wireline networks. UE 110 may include a credential component 224 that retrieves credentials, segments the credentials, and/or embeds credential fragments into frames. In some implementations, BS105 may include a communication component 322 configured to communicate with UE 110.

A BS105 configured for 4G LTE, collectively referred to as an evolved Universal Mobile Telecommunications System (UMTS) terrestrial radio access network (E-UTRAN), may interface with EPC 160 through a backhaul link interface 132 (e.g., S1, X2, internet Protocol (IP), or flex interface). A base station 105 configured for 5G NR, collectively referred to as a next generation RAN (NG-RAN), may interface with the 5gc 190 through a backhaul link interface 134 (e.g., S1, X2, internet Protocol (IP), or flex interface). BS105 may perform, among other functions, one or more of the following functions: user data delivery, radio channel ciphering and ciphering, integrity protection, header compression, mobility control functions (e.g., handover, dual connectivity), inter-cell interference coordination, connection setup and release, load balancing, distribution of non-access stratum (NAS) messages, NAS node selection, synchronization, radio Access Network (RAN) sharing, multimedia Broadcast Multicast Services (MBMS), subscriber and equipment tracking, RAN Information Management (RIM), paging, positioning, and delivery of alert messages. BS105 may communicate with each other directly or indirectly (e.g., through EPC 160 or 5gc 190) over backhaul link interface 134. The backhaul links 132, 134 may be wired or wireless.

BS105 may communicate wirelessly with UE 110. Each BS105 may provide communication coverage for a respective geographic coverage area 130. There may be overlapping geographic coverage areas 130. For example, the small cell 105 'may have a coverage area 130' that overlaps with the coverage area 130 of one or more macro BSs 105. A network comprising small cells and macro cells may be referred to as a heterogeneous network. The heterogeneous network may also include a home evolved node B (eNB) (HeNB) that may provide services to a restricted group known as a Closed Subscriber Group (CSG). The communication link 120 between the BS105 and the UE 104 may include Uplink (UL) (also known as reverse link) transmissions from the UE 110 to the BS105 and/or Downlink (DL) (also known as forward link) transmissions from the BS105 to the UE 110. Communication link 120 may use multiple-input multiple-output (MIMO) antenna techniques including spatial multiplexing, beamforming, and/or transmit diversity. These communication links may be through one or more carriers. For each carrier allocated in carrier aggregation up to yxmhz (x component carriers) in total for transmission in each direction, BS105/UE 110 may use a spectrum up to Y MHz (e.g., 5, 10, 15, 20, 100, 400MHz, etc.) bandwidth. These carriers may or may not be contiguous with each other. The allocation of carriers may be asymmetric with respect to DL and UL (e.g., more or fewer carriers may be allocated to DL than UL). The component carriers may include a primary component carrier and one or more secondary component carriers. The primary component carrier may be referred to as a primary cell (PCell) and the secondary component carrier may be referred to as a secondary cell (SCell).

Some UEs 110 may communicate with each other using a device-to-device (D2D) communication link 158. The D2D communication link 158 may use the DL/UL WWAN spectrum. The D2D communication link 158 may use one or more side link channels such as a physical side link broadcast channel (PSBCH), a physical side link discovery channel (PSDCH), a physical side link shared channel (PSSCH), and a physical side link control channel (PSCCH). D2D communication may be through a 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.

The wireless communication system may further include a Wi-Fi Access Point (AP) 150 in communication with a Wi-Fi Station (STA) 152 via a communication link 154 in a 5GHz unlicensed spectrum. When communicating in the unlicensed spectrum, the STA 152/AP 150 may perform a Clear Channel Assessment (CCA) prior to communication to determine whether the channel is available.

The small cell 105' may operate in licensed and/or unlicensed spectrum. When operating in unlicensed spectrum, the small cell 105' may employ NR and use the same 5GHz unlicensed spectrum as that used by the Wi-Fi AP 150. Small cells 105' employing NR in unlicensed spectrum may push up access network coverage and/or increase access network capacity.

Whether small cell 105' or a large cell (e.g., macro base station), base station 105 may include an eNB, g B node (gNB), or other type of base station. Some base stations, such as gNB 180, may operate in the legacy sub-6 GHz spectrum, millimeter wave (mmW) frequencies, and/or near mmW frequencies to communicate with UE 110. When the gNB 180 operates in mmW or near mmW frequencies, the gNB 180 may be referred to as a mmW base station. Extremely High Frequency (EHF) is a part of the Radio Frequency (RF) in the electromagnetic spectrum. EHF has a wavelength in the range of 30GHz to 300GHz and between 1 mm and 10 mm. The radio waves in this band may be referred to as millimeter waves. The near mmW can be extended down to a 3GHz frequency with a wavelength of 100 mm. The ultra-high frequency (SHF) band extends between 3GHz and 30GHz, which is also known as a centimeter wave. Communications using mmW/near mmW radio frequency bands have extremely high path loss and short range. The mmW base station 180 may utilize beamforming 182 with the UE 110 to compensate for high path loss and short range.

EPC 160 may include a Mobility Management Entity (MME) 162, other MMEs 164, a serving gateway 166, a Multimedia Broadcast Multicast Service (MBMS) gateway 168, a broadcast multicast service center (BM-SC) 170, and a Packet Data Network (PDN) gateway 172.MME 162 may be in communication with a Home Subscriber Server (HSS) 174. MME 162 is a control node that handles signaling between UE 110 and EPC 160. Generally, MME 162 provides bearer and connection management. All user Internet Protocol (IP) packets are communicated through the serving gateway 166, which serving gateway 166 itself is connected to the PDN gateway 172. The PDN gateway 172 provides UE IP address allocation as well as other functions. The PDN gateway 172 and BM-SC 170 are connected to an IP service 176.IP services 176 may include the internet, intranets, IP Multimedia Subsystem (IMS), packet Switched (PS) streaming services, and/or other IP services. The BM-SC 170 may provide functionality for MBMS user service provisioning and delivery. The BM-SC 170 may be used as an entry point for content provider MBMS transmissions, may be used to authorize and initiate MBMS bearer services within a Public Land Mobile Network (PLMN), and may be used to schedule MBMS transmissions. The MBMS gateway 168 may be used to distribute MBMS traffic to BSs 105 belonging to a Multicast Broadcast Single Frequency Network (MBSFN) area broadcasting a particular service and may be responsible for session management (start/stop) and for collecting eMBMS-related charging information.

The 5gc 190 may include access and mobility management functions (AMFs) 192, other AMFs 193, session Management Functions (SMFs) 194, and User Plane Functions (UPFs) 195. The AMF 192 may be in communication with a Unified Data Management (UDM) 196. AMF 192 is a control node that handles signaling between UE 110 and 5gc 190. In general, AMF 192 provides QoS flows and session management. All user Internet Protocol (IP) packets are delivered through UPF 195. The UPF 195 provides UE IP address assignment as well as other functions. The UPF 195 is connected to an IP service 197. The IP services 197 may include the internet, intranets, IP Multimedia Subsystem (IMS), PS streaming services, and/or other IP services.

BS105 may also be referred to as a gNB, a node B, an evolved node B (eNB), an access point, a base transceiver station, a radio base station, an access point, an access node, a radio transceiver, a node B, an evolved node B (eNB), a gNB, a home node B, a home evolved node B, a relay, a transceiver function, a basic service set (BSs), an Extended Service Set (ESS), a transmission-reception point (TRP), or some other suitable terminology. BS105 provides UE 110 with an access point to EPC 160 or 5gc 190. Examples of UE 110 include a cellular telephone, a smart phone, a Session Initiation Protocol (SIP) phone, a laptop, a Personal Digital Assistant (PDA), a satellite radio, a global positioning system, a multimedia device, a video device, a digital audio player (e.g., MP3 player), a camera, a game console, a tablet, a smart device, a wearable device, a vehicle, an electricity meter, an air pump, a large or small kitchen appliance, a healthcare device, an implant, a sensor/actuator, a display, or any other similar functional device. Some UEs 110 may be referred to as IoT devices (e.g., parking meters, 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 communication device, remote device, mobile subscriber station, access terminal, mobile terminal, wireless terminal, remote terminal, handset, user agent, mobile client, or some other suitable terminology.

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

Referring to fig. 2, one example of an implementation of ue 110 may include a modem 220 with a communication component 222. The communication component 222 and/or modem 220 of UE 110 may be configured to communicate with BS105 via a cellular network, wi-Fi network, or other wireless and wireline networks. Certificate component 224 may retrieve the certificate, split the certificate, and/or embed the certificate fragments into the frame.

In some implementations, UE 110 may include various components including components that communicate via one or more buses 244, such as one or more processors 212, memory 216, and transceiver 202, which may operate in conjunction with modem 220 and communication component 222 to implement one or more of the functions described herein in connection with BS105 communications. In addition, 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 (simultaneous or non-simultaneous) 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.

In an aspect, the one or more processors 212 may include a modem 220 that uses one or more modem processors. Various functions related to the communication component 222 and/or the credential component 224 can be included in the modem 220 and/or the processor 212 and, in one aspect, can be performed by a single processor, while in other aspects, different ones of these functions can be performed by a combination of two or more different processors. For example, in an aspect, the one or more processors 212 may include any one or any combination of the following: 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 transceiver 202. Additionally, modem 220 may configure UE 110 with processor 212. In other aspects, some features of the one or more processors 212 and/or modems 220 associated with the communication component 222 and/or the credential component 224 may be performed by the transceiver 202.

Moreover, the memory 216 may be configured to store local versions of data and/or applications 275 used herein, or the communication component 222, the credential component 224, and/or one or more sub-components of the communication component 222 and/or the credential component 224 are executed by the at least one processor 212. Memory 216 may include any type of computer-readable medium usable by the computer or the 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 an aspect, for example, memory 216 may be a non-transitory computer-readable storage medium storing one or more computer-executable code defining and/or data associated with communication component 222, credential component 224, and/or one or more subcomponents thereof, when UE 110 is operating at least one processor 212 to execute communication component 222, credential component 224, and/or one or more subcomponents thereof.

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

Also, in an aspect, UE 110 may include an RF front end 288 operable in communication with one or more antennas 265 and transceiver 202 for receiving and transmitting radio transmissions, such as wireless communications transmitted by at least one BS105 or wireless transmissions transmitted by UE 110. The RF front end 288 may be coupled with 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.

In an aspect, the LNA 290 may amplify the received signal to a desired output level. In an aspect, each LNA 290 may have a specified minimum and maximum gain value. In an aspect, the RF front-end 288 may use one or more switches 292 to select a particular LNA 290 and a specified gain value based on a desired gain value for a particular application.

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

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

As such, transceiver 202 may be configured to transmit and receive wireless signals through one or more antennas 265 via RF front end 288. In an aspect, the transceiver may be tuned to operate at a specified frequency such that UE 110 may communicate with one or more BSs 105 or one or more cells associated with one or more BSs 105, for example. In an aspect, for example, modem 220 may 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.

In an aspect, modem 220 may be a multi-band-multi-mode modem that may process digital data and communicate with transceiver 202 to enable the use of transceiver 202 to transmit and receive digital data. In an aspect, modem 220 may be multi-band and configured to support multiple frequency bands for a particular communication protocol. In an aspect, modem 220 may be multi-mode and configured to support multiple operating networks and communication protocols. In an aspect, modem 220 may control one or more components of UE 110 (e.g., RF front end 288, transceiver 202) to enable transmission and/or reception of signals from the network based on a specified modem configuration. In an aspect, the modem configuration may be based on the mode of the modem and the frequency band in use. In another aspect, the modem configuration may be based on UE configuration information associated with UE 110 as provided by the network.

Referring to fig. 3, one example of an implementation of the bs105 may include a modem 320 having a communication component 322 configured to transmit data. The communication component 322 of the BS105 and/or the modem 320 may be configured to communicate with the UE 110 via a cellular network, wi-Fi network, or other wireless and wireline networks.

In some implementations, BS105 may include various components including components that communicate via one or more buses 344, such as one or more processors 312, memory 316, and transceiver 302, which may operate in conjunction with modem 320 and communication component 322 to implement one or more of the functions described herein in connection with UE 110 communications. In addition, 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 (simultaneous or non-simultaneous) in one or more radio access technologies.

In an aspect, the one or more processors 312 may include a modem 320 using one or more modem processors. Various functions associated with communication component 322 may be included in modem 320 and/or processor 312 and may be performed by a single processor in one aspect, while in other aspects different ones of the functions may be performed by a combination of two or more different processors. For example, in an 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 transmit processor, or a receiver device processor, or a transceiver processor associated with transceiver 302. In addition, modem 320 may configure BS105 and processor 312. In other aspects, some features of one or more processors 312 and/or modems 320 associated with communication component 322 may be performed by transceiver 302.

Moreover, the memory 316 can be configured to store local versions of data and/or applications 375 used herein, or the communication component 322, the determination component, and/or one or more sub-components of the communication component 322 or the determination component, are executed by the at least one processor 312. Memory 316 may include any type of computer-readable medium usable by computer or at least 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 an aspect, for example, memory 316 may be a non-transitory computer-readable storage medium storing one or more computer-executable code defining and/or data associated with communication component 222, determination component, and/or one or more subcomponents thereof, while BS105 is operating at least one processor 312 to execute communication component 322, determination component, and/or one or more subcomponents thereof.

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

Also, in an aspect, BS105 may include an RF front end 388 that may be communicatively operable with one or more antennas 365 and transceivers 302 for receiving and transmitting radio transmissions, such as wireless communications transmitted by other BSs 105 or wireless transmissions transmitted by UEs 110. The RF front-end 388 may be coupled with 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.

In an aspect, the LNA 390 may amplify the received signal to a desired output level. In an aspect, each LNA 390 may have a specified minimum and maximum gain value. In an aspect, the RF front-end 388 may select a particular LNA 390 and a specified gain value based on a desired gain value for a particular application using one or more switches 392.

Further, for example, one or more PAs 398 may be used by the RF front-end 388 to amplify signals to obtain RF output at a desired output power level. In an aspect, each PA 398 may have specified minimum and maximum gain values. In an aspect, the RF front end 388 may select a particular PA 398 and a specified gain value based on a desired gain value for a particular application using one or more switches 392.

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

As such, transceiver 302 may be configured to transmit and receive wireless signals through one or more antennas 365 via RF front end 388. In an aspect, the transceiver may be tuned to operate at a specified frequency such that the BS105 may communicate with, for example, the UE 110 or one or more cells associated with one or more BSs 105. In an aspect, for example, modem 320 may configure transceiver 302 to operate at a specified frequency and power level based on the base station configuration of BS105 and the communication protocol used by modem 320.

In an aspect, modem 320 may be a multi-band-multi-mode modem that may process digital data and communicate with transceiver 302 to enable the use of transceiver 302 to transmit and receive digital data. In an aspect, modem 320 may be multi-band and configured to support multiple frequency bands for a particular communication protocol. In an aspect, modem 320 may be multi-mode and configured to support multiple operating networks and communication protocols. In an aspect, modem 320 may control one or more components of BS105 (e.g., RF front end 388, transceiver 302) to enable transmission and/or reception of signals from a network based on a specified modem configuration. In an aspect, the modem configuration may be based on the mode of the modem and the frequency band in use. In another aspect, the modem configuration may be based on a base station configuration associated with BS 105.

Turning to fig. 4, in an implementation, an example of an environment 400 for managing a UAV may include a mobile device 402. Mobile device 402 may include UE 110, be part of UE 110, or be the same as UE 110. The mobile device 402 may be a UAV, an Unmanned Aerial System (UAS), an unmanned aerial vehicle, or other apparatus that may 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 artificial intelligence operator). The environment 400 may include a first recipient 410a, a second recipient 410b, and a third recipient 410c. The first recipient 410a may be a third party authorized entity (TPAE, such as police detector, civilian/government detector, regulatory agency, etc.). The second recipient 410b and the third recipient 410c may be mobile devices, such as UAVs. Other types of recipients are possible. The mobile device 402 may communicate with the first recipient 410a via a wireless communication link 412, such as bluetooth, wi-Fi, cellular device-to-device link, or other wireless communication link. The mobile device 402 may communicate with the second recipient 410b via a D2D communication link 158, such as a bluetooth, wi-Fi, cellular device-to-device link, or other wireless communication link. The mobile device 402 may communicate with the third recipient 410c via a communication link 154, such as a bluetooth, wi-Fi, cellular device-to-device link, or other wireless communication link. Other communication links may be used for communication.

In some implementations, the environment 400 may include a first BS105a having a first coverage area 130a and a second BS105b having a second coverage area 130 b. The environment 400 may include a core network 430, such as the EPC 160 or 5gc 190 in fig. 1. 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 core network 430. In other optional implementations, UFMS 422 may be implemented in a stand-alone server separate from USS 422. USS 420 and/or UFMS 422 may communicate with first recipient 410 via a communication link 414 (e.g., wiFi, long range radio, cellular link, optical fiber, etc.) or core network 430. USS 420 and/or UFMS 422 may communicate with core network 430 via communication interface 416 (e.g., 5gc 190 network open function, EPC 160 service capability open function, 3GPP Rx interface, etc.).

In an implementation of the present disclosure, mobile device 402 may include a remote Identification (ID). The remote ID may include one or more information such as UAV ID (e.g., serial number, registration number, or UAV traffic management unique ID, etc.), UAV type, timestamp accuracy, operational status, operational description, longitude, latitude, geodetic altitude, takeoff altitude, location pressure altitude, vertical accuracy, horizontal accuracy, speed (north/south), speed (east/west), vertical speed, operator longitude, operator latitude, etc. 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 (e.g., UAV ID) from USS 420 and/or UFMS 422 via a cellular network (e.g., first BS105a, second BS105b, etc.).

In some implementations, the remote IDs 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 of the remote ID. In one example, the BRID may include a UAV ID and location information.

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

In one aspect of the disclosure, the mobile device 402 may broadcast the BRID to one or more of the first recipient 410a, the second recipient 410b, and/or the third recipient 410 c. To enable the first, second, and/or third recipients 410a, 410b, 410c to authenticate the BRID, the mobile device 402 may transmit (e.g., unicast, multicast, or broadcast) a certificate. The certificate may be a certificate of the mobile device 402, a certificate from a certificate authority assigned the certificate of the mobile device 402, or a chain of trust file indicating one or more tiers of certificates (each tier up to a root certificate or other specified authority). The mobile device 402 may split the certificate into n portions and may transmit the n portions of the certificate in n frames. For example, the mobile device 402 may split the certificate into 20 parts (n=20). The mobile device 402 may embed the 20 certificate partitions/segments into 20 frames and sequentially transmit the 20 frames to one or more of the first receiver 410a, the second receiver 410b, and/or the third receiver 410 c. For example, frame 1 may include part 1 of the certificate, frame 2 may include part 2 of the certificate, and so on. Once all frames (e.g., 20 frames) are received by a recipient (e.g., first recipient, second recipient, and/or third recipient), the recipient (e.g., …) can concatenate the portions of the certificate (e.g., 20 portions of the 20 frames) to generate or form a certificate (e.g., of the mobile device 402).

In some scenarios, authenticating the BRID using a certificate may allow the recipient 410a-410c to verify the authenticity of the mobile device 402 at the same time.

In some aspects, the mobile device 402 may indicate the number of portions (or frames) of the certificate to the recipients 410 a-c. For example, the mobile device 402 may split the certificate into 50 parts and embed the 50 parts into 50 frames. The mobile device 402 may indicate that there are 50 portions of the certificate to be transmitted in a first frame (which contains a first portion of the certificate). In response, the recipient 410a-c may assemble the certificate after receiving the 50 portions in 50 frames.

In another aspect, the mobile device 402 may indicate to the recipients 410a-c the last frame carrying the last portion of the certificate. For example, the mobile device 402 may split the certificate into 15 parts and embed the 15 parts into 15 frames. The mobile device 402 may indicate in frame 15 that it is the last frame of the portion carrying the certificate. In response, the recipient 410a-c may assemble the certificate after receiving the 15 th frame (which has the 15 th or last portion).

In some aspects, the frame of the portion carrying the certificate may be marked as a certificate frame.

In certain aspects, the number of frames used to transmit the portion (i.e., segment) of the certificate may be dynamically determined based on factors such as weather conditions, traffic, regulatory requirements, techniques for transmission, and the like.

In some implementations, after the recipient 410a-c concatenates the certificate from portions of the certificate, the recipient 410a-c may use the certificate to authenticate the BRID and/or other message transmitted by the mobile device 402.

In certain aspects, the mobile device 402 may transmit frames carrying portions of the credentials at a particular periodicity. Examples of periodicity may include 50 milliseconds (ms), 100ms, 500ms, 1 second(s), 5s, 10s, 100s, or other durations. Periodicity may be determined by various methods as described below.

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

In another aspect of the present disclosure, the mobile device 402 may receive the periodicity value when connected to the first BS105a, the second BS105 b, the UFMS 422, and/or the USS 420. For example, USS 420 and/or UFMS 422 may communicate this periodicity to mobile device 402 when USS 420 and/or UFMS 422 provide a UAV ID to mobile device 402. In other examples, the periodicity may be embedded in the UAV ID when USS 420 and/or UFMS 422 provide the UAV ID to mobile device 402.

In a different aspect, the first BS105a serving the mobile device 402 may transmit the periodicity to the mobile device 402 via a Radio Resource Configuration (RRC) message or a System Information Broadcast (SIB) message. The periodicity transmitted may be one of a value (e.g., 1s, 2s, 5s, 10s, 20s, 50s, 100s, etc.), or a predefined index (e.g., 0-never, 1-5s, 2-10s, 3-20, etc.).

In some aspects of the present disclosure, the first BS105a serving the mobile device 402 may dynamically update the periodicity of the mobile device 402 via RRC messages. The first BS105a may transmit 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 10s to 15 s).

In one implementation, the periodicity may be a function of the flight plan of the mobile device 402, geographic areas along the flight plan, local/regional/national policies, traffic density, terrain disturbances, or other factors related to the operation of the mobile device 402.

In some implementations, the periodicity may be adaptively based on detected environmental factors, such as RF interference from other UAV traffic, weather-related attenuation, excessive requests for credentials, and so forth. In some implementations, the periodicity may be based on a Received Signal Strength Indication (RSSI), a radio frequency, one or more network or link quality of service (QoS) parameters, or other factors associated with the quality of the communication channel.

In an aspect of the disclosure, the recipients 410a-c may obtain credentials from sources other than the mobile device 402. In a first example, USS 420 and/or UFMS 422 may provide credentials 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, or NRID. The core network 430 may determine one or more coverage areas associated with the geographic location and corresponding base stations, such as the first BS105a and the first coverage area 130a. The core network 430 may provide the credentials to the first BS105a after determining that the mobile device 402 is within the first coverage area 430 a. The mobile device 402 may broadcast the BRID. After the mobile device 402 broadcasts the BRID, the second recipient 410b may receive the BRID from the mobile device 402. The second recipient 410b may obtain information from the BRID, such as the UAV ID of the mobile device 402. The second receiver 410b may transmit a credential request including the UAV ID to the first BS105a (the serving base station of the second receiver 410 b). In response, the first BS105a may transmit a certificate response including the certificate (received earlier from the core network 430) to the second receiver 410 b. The second recipient 410b may use the certificate to authenticate the BRID from the mobile device 402.

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

In a third example, mobile device 402 may broadcast a BRID. After the mobile device 402 broadcasts the BRID, the second recipient 410b may receive the BRID from the mobile device 402. The second recipient 410b may obtain information from the BRID, such as the UAV ID of the mobile device 402. The second recipient 410b may communicate a credential request including the UAV ID to USS 420 and/or UFMS 422 by identifying USS 420 and/or UFMS 422 using a UAV ID (e.g., the UAV ID may be in the format of a Fully Qualified Domain Name (FQDN) and the recipient 410b retrieves the address of the USS and/or UFMS using Domain Name Service (DNS)). In response to receiving the credential request, USS 420 and/or UFMS 422 may transmit a credential response (e.g., via core network 430 and/or first BS105 a) to second recipient 410b that includes a credential associated with the UAV ID. The second recipient 410b may use the certificate to authenticate the BRID from the mobile device 402.

In a fourth example, USS 420 and/or UFMS 422 may provide credentials 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. The core network 430 may determine one or more coverage areas associated with the geographic location and corresponding base stations, such as the first BS105a and the first coverage area 130a. The core network 430 may provide the credentials to the first BS105a after determining that the mobile device 402 is within the first coverage area 430 a. Upon receiving the credential, the first BS105a may broadcast the credential in the first coverage area 130a. The second receiver 410b may receive the broadcasted certificate. The mobile device 402 may broadcast the BRID. After the mobile device 402 broadcasts the BRID, the second recipient 410b may receive the BRID from the mobile device 402. The second recipient 410b may use the certificate to authenticate the BRID from the mobile device 402. The first BS105a and the second BS105b may broadcast the received certificate with an indication of the BRID certificate using a cellular broadcast system, broadcast the received certificate with an indication of the BRID certificate using a Commercial Mobile Alert System (CMAS), or broadcast the received certificate with a common or dedicated channel for BRID certificates that all recipients subscribe to receive the BRID certificate using a multimedia broadcast/multicast system.

In a fifth example, the first BS105a may receive credentials from the mobile device 402, the core network 430, the UFMS 422, and/or the USS 420. The first BS105a may receive a flight/travel plan for the mobile device 402 from the core network 430, UFMS 422, and/or USS 420. Based on the flight plan, the first BS105 may determine the geographic area into which the mobile device 402 will enter. The first BS105a may identify a coverage area associated with a geographic area into which the mobile device 402 will enter, such as the second coverage area 130b of the second BS105 b. In response, the first BS105a may identify that the second BS105b is associated with the second coverage area 130b and transmit credentials to the second BS105b (for broadcast to recipients in the second coverage area 130 b) before the mobile device 402 enters the second coverage area 130b.

In some aspects of the disclosure, the recipients 410a-410c may use certificates to authenticate any messages transmitted by the mobile device 402. Once authenticated, the recipients 410a-410c can verify the authenticity and/or integrity of the arbitrary message of the mobile device 402. In another example, the mobile device 402 can use any message as the BRID.

Turning to fig. 5, in some implementations, examples of sequence diagram 500 may include UAV 502, first recipient 504, second recipient 506, radio Access Network (RAN) 508, core network 430, UFMS 422, and USS 420. The first receiver 504 and/or the 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., security credentials). In communication 522, UAV 502 may communicate an RRC connection request to RAN 508. In communication 524, RAN 508 may transmit an RRC connection response to UAV 502 with parameters for establishing a wireless communication link between RAN 508 and UAV 502. In communication 526, UAV 502 may transmit an RRC connection complete message to RAN 508. In communication 528, RAN 508 may optionally transmit an RRC connection reconfiguration message to UAV 502. As an example, the reconfiguration may change connection and/or operating parameters of UAV 502, such as periodicity to transmit portions of credentials. In communication 530, UAV 502 may optionally transmit an RRC connection reconfiguration complete message to RAN 508 in response to completing the reconfiguration.

In some implementations, in communication 532, UAV 502 may broadcast a BRID that is received by first recipient 504. UAV 502 may segment the credential into n segments (e.g., 25 segments). UAV 502 may embed the n segments into n frames. In an optional implementation, UAV 502 may tag the n frames to indicate that the n frames carry segments of credentials. In communication 534-1, UAV 502 may transmit a first frame carrying a first segment of the credential. In communication 534-2, UAV 502 may transmit a second frame carrying a second segment of the credential, and so on. In communications 534-n, UAV 502 may transmit the nth frame of the last segment carrying the credential. UAV 502 may transmit each of the n frames carrying segments of credentials on a predetermined periodicity. For example, the periodicity may be signaled by USS 420 and/or UFMS 422 during the boot process at step 520. Alternatively, the periodicity is signaled by the RAN 508 at steps 524 or 528 using RRC configuration/reconfiguration messages. The periodicity may also be stored internally (e.g., in memory, hard coded, etc.) in UAV 502 prior to step 520.

In an optional implementation, the first frame may include a segment indicator indicating that the certificate includes n segments. The segment indicator may indicate to a recipient device (such as the first recipient 504) that there are n frames (and n segments of credentials) to be transmitted by the UAV 502.

In another optional implementation, the nth frame may include a termination indicator that indicates that the nth frame is carrying the last segment of the credentials of UAV 502.

In one optional implementation, UAV 502 may assign sequence numbers corresponding to the order of segments of the credential to n frames. The frame of the first segment carrying the certificate may be assigned a "1". The frame of the second segment carrying the certificate may be assigned a "2", and so on.

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

In operation 536, the first recipient 504 may verify the BRID by authenticating the BRID using the concatenated certificate (as described above).

In alternative implementations, each segment of the certificate may be associated with an identifier. For example, UAV 520 may segment the credentials into 30 segments. UAV 520 may label the first segment with a "1", the second segment with a "2", … …, and the thirty-th segment with a "30". If the first receiver 504 fails to receive some of these segments (e.g., the seventeenth segment labeled with the identifier "17"), the first receiver 504 may use the identifier to send a request to the UAV 520 to retransmit the seventeenth segment.

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

In some implementations, in communication 542, UAV 502 may broadcast a BRID that is received by second recipient 506. UAV 502 may segment the credential into m segments (e.g., 15 segments). UAV 502 may embed the m segments into m frames. In an optional implementation, UAV 502 may tag the m frames to indicate that the m frames carry credential segments. In communication 544-1, UAV 502 may transmit a first frame carrying a first segment of credentials. In communication 544-2, UAV 502 may transmit a second frame carrying a second segment of the credential, and so on. In communication 544-m, UAV 502 may transmit an mth frame carrying the last segment of the credential. In operation 546, the second recipient 506 may verify the BRID by authenticating the BRID using the concatenated certificate (as described above).

In some examples, the number of segments into which UAV 502 segments a credential may be partitioned into may depend on the communication link technology, operation of UAV 502, battery power remaining in UAV 502, operating environment, regulations, and the like.

Turning to fig. 6A-E, in one implementation, an example of sequence diagram 600 may include UAV 602, first recipient 604, second recipient 606, first BS105a, second BS105b, core network 430, UFMS 422, and USS 420. The first recipient 604 and/or the second recipient 606 may be a UAV, mobile device, UE, TPAE, base station, controller, or other device. In communication 620, UAV 602 may be configured by obtaining a UAV ID and performing credential bootstrapping (e.g., security credentials). In communication 622, UAV 602 may be registered with and/or connected to a mobile network including first BS105a and second BS105 b. In communication 624, UAV 602 may register with USS 420 and/or UFMS 422.

Referring to fig. 6A and 6B, in some implementations USS 420 may communicate a location subscription to core network 430 to obtain an updated location of UAV 602 in communication 630. In communication 632, core network 430 may transmit a location report that includes 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 example, USS 420 may obtain location information from a location service (LCS) of communication network 100. In communication 634, USS 420 and/or UFMS 422 may communicate credentials (including a UAV ID) associated with UAV 602 to core network 430. In operation 636, based on the location information received from USS 420, UFMS 422, core network 430 may determine the geographic location of UAV 602 based on the location information (e.g., longitude, latitude, altitude, etc.) in the location report. The core network 430 may determine one or more coverage areas associated with the geographic location and corresponding base stations, such as the first BS105a and the first coverage area 130a. In communication 638, core network 430 may provide credentials to first BS105a and/or second BS105b after determining that UAV 602 is within first coverage area 130a.

In some implementations, in communication 640, UAV 602 may broadcast a BRID. After UAV 602 broadcasts the BRID, first recipient 604 may receive the BRID from UAV 602. The first recipient 604 may obtain information from the BRID, such as a UAV ID of the UAV 602. In communication 642, the first recipient 604 may transmit a credential request including the UAV ID to the first BS105a (the serving base station of the first recipient 604). In response, the first BS105a may identify a credential associated with the UAV ID. In communication 644, the first BS105a may transmit a certificate response to the first recipient 604 that includes the certificate (received earlier at 638 from the core network 430). In operation 646, the first recipient 604 may authenticate the BRID from the UAV 602 using the certificate.

Turning to fig. 6A and 6C, in some implementations, UAV 602 may broadcast a BRID in communication 650. After UAV 602 broadcasts the BRID, second recipient 606 may receive the BRID from UAV 606. The second recipient 606 may obtain information from the BRID, such as the UAV ID of UAV 602. In communication 652, the second recipient 606 may transmit a credential request including the UAV ID to the second BS105b (e.g., a serving base station of the second recipient 606). In response, in communication 654, second BS105b may transmit a credential retrieval message (including the UAV ID of UAV 602) to UFMS 422 (e.g., via core network 430) to request a credential. Alternatively, BS105b 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 a credential associated with the UAV ID of UAV 602 to second BS105b in a credential delivery message. In communication 658, after receiving the credential delivery message, the second BS105b can transmit a credential response including the credential to the second recipient 606 in response to the credential request to the second recipient 606. In operation 660, the second recipient 606 may authenticate the BRID from the UAV 602 using the certificate.

Turning to fig. 6A and 6D, in some implementations, UAV 602 may broadcast a BRID in communication 662. After UAV 602 broadcasts the BRID, second recipient 606 may receive the BRID from UAV 606. The second recipient 606 may obtain information from the BRID, such as the UAV ID of UAV 602. In communication 664, the second recipient 606 may transmit a credential request including the UAV ID to USS 420 and/or UFMS 422 (e.g., via first BS105a, second BS105b, and/or core network 430). In communication 666, USS 420 and/or UFMS 422 may transmit a credential response (e.g., via core network 430, first BS105a, and/or second BS105 b) to second recipient 606 that includes a credential associated with the UAV ID in response to receiving the credential request. In operation 668, the second recipient 606 may authenticate the BRID from the UAV 602 using the certificate.

Referring to fig. 6A and 6E, in one implementation, core network 430 may communicate a location subscription to USS 420 and/or UFMS 422 to obtain an updated location of UAV 602 at 630. In communication 632, USS 420 and/or UFMS 422 may transmit a location report that includes the last known location of UAV 602 (based on the received remote ID, NRID, or BRID). In communication 634, USS 420 and/or UFMS 422 may communicate credentials (including a UAV ID) associated with UAV 602 to core network 430. In operation 636, 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 associated with the geographic location and corresponding base stations, such as the first BS105a and the first coverage area 130a. In communication 638, core network 430 may provide credentials to first BS105a via a credential delivery message after determining that UAV 602 is within first coverage area 130a. In communication 670, UAV 602 may broadcast a BRID. After UAV 602 broadcasts the BRID, the first recipient may receive the BRID from UAV 602. In communication 672, the first BS105a may broadcast the certificate (received from the core network 430 at 638) in the first coverage area 130a. The first recipient 604 may receive the broadcasted certificate. In operation 674, the first recipient 604 may authenticate the BRID from the UAV 602 using the credentials.

Fig. 7A is a sequence diagram of an example of a process 700 of managing UAV identity, according to some embodiments. Referring to fig. 1-7A, process 700 may include UAV 602, first recipient 604, second recipient 606, first BS105a, second BS105b, core network 430, UFMS 422, USS 420, and Network Computing Device (NCD) 701. In some implementations, the NCD 701 may be implemented in the core network 430.

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

In communication 706, UAV 602 may transmit a UAV message that is received by first recipient 604. The UAV message may include an anonymous token and a digital signature associated with the UAV message. The first recipient 604 may send a request to authenticate the UAV, the request including an anonymous token. In some embodiments, the first recipient 604 may send a request 708 to the first BS105a, and the first BS may send the request in a communication 710 to the NCD 701.

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

In operation 714, the NCD 701 may determine if the digital signature is verified using a digital certificate. In some embodiments, the NCD 701 may cryptographically verify the digital signature using a digital certificate.

Based on this determination, NCD 701 may send a response to first BS105a in communication 716 and first BS105a may send a response to first recipient 604 in communication 718. In some embodiments, the response in communication 716 and the response in communication 718 may indicate that the UAV message is authenticated in response to determining that the digital signature was verified using a digital certificate.

Fig. 7B is a sequence diagram of an example of a process 750 of managing UAV identity, according to some embodiments. Referring to fig. 1-7B, process 750 may include UAV 602, first recipient 604, second recipient 606, first BS105a, second BS105B, core network 430, UFMS 422, USS 420, and NCD 701.

In communication 752, first BS105a may receive an assertion from UAV 602 that the UAV has authority to perform operations anonymously. In some embodiments, the assertion may include an anonymous token of the UAV. In some embodiments, the assertion may include a digital certificate of the UAV. The first BS105a may send a request to the NCD 701 in communication 754 to authenticate the UAV, wherein the request includes an assertion of the UAV.

In operation 756, the NCD 701 may determine, based on the assertion, whether the UAV has authority to perform operations anonymously. In some embodiments, NCD 701 may determine whether UAV 602 is associated with the right to operate anonymously. In some embodiments, information indicative of such rights may be stored in a data structure and/or a memory device accessible by NCD 701.

The first BS105a may receive a response from the NCD 701 in the communication 758 indicating whether the UAV has the right to perform the operation anonymously. In some embodiments, the first BS105a may determine whether the UAV has authority to perform operations anonymously based on the response 758.

In operation 760, in response to determining that the UAV is authenticated, the first BS105a may broadcast information about the UAV that does not configure identity information of the UAV in response to determining that the UAV has the authority to perform the operation anonymously. The first BS105a may transmit a broadcast in communications 762a, 762b that may be received by the first receiver 604 and/or the second receiver 606.

In communication 764, UAV 602 may broadcast a UAV message in communication 764 that includes the assertion and a digital signature associated with the UAV, which may be received by first recipient 604. The first recipient 604 may send a request to authenticate the UAV 602 to the first BS105a in communication 766. The request in communication 766 may include the assertion and a digital signature associated with the UAV message from UAV 602.

The first BS105a may send a request to the NCD 701 in communication 768 to authenticate the UAV message. The request in communication 768 may include the assertion and a digital signature of UAV 602. In operation 770, NCD 701 may determine whether UAV 602 has authority to operate anonymously (e.g., as described above with respect to operations 712 and 714 of process 700 (fig. 7A)).

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

In response to determining that the UAV message is authenticated, the first BS105a may send an indication in communication 774 to the requester device (e.g., the first receiver 604) that the UAV message is authenticated.

Fig. 8 is a process flow diagram illustrating a method 800 for managing UAV identity that may be performed by a processor of a network computing device, according to some embodiments. Referring to fig. 1-8, the operations of method 800 may be performed by a processor of a network processing device.

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 that the anonymous token is associated with a digital certificate of the UAV. In some embodiments, the anonymous token may include or point to an indication that the UAV (and/or UAV operator) has authority 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 a digital certificate concatenated with a secret value, which may be stored by or accessible to the network computing device. The means for performing the operations of block 802 may include the processor 1301 (fig. 13).

In some embodiments, the anonymous token may be configured with an availability time limit. For example, the anonymous token may be configured with a survival time or another time constraint on its availability that limits the usefulness of the anonymous token to a specified time range or duration beyond which the UAV would not be able to use the anonymous token to anonymously perform operations. In other words, if the UAV uses an anonymous token to transmit before or after a time constraint on the token, the UAV will not be authenticated by the base station or NCD 701.

In some embodiments, the anonymous token may be configured with availability geographic restrictions. For example, an anonymous token may be configured with a geofence, coordinates, or another geographic constraint on its availability that limits the usefulness of the anonymous token to a designated location, area, or physical zone (such as may correspond to a legal jurisdiction, a war zone, or a designated delivery route or travel path, etc.), beyond which the UAV would not be able to use the anonymous token to anonymously perform an operation.

In block 804, the processor may provide the anonymous token to the UAV for use in operation. In some embodiments, providing the anonymous token to the UAV may enable the UAV to perform the operation anonymously using the anonymous token. For example, the UAV may associate an anonymous token with the 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 therewith. In some embodiments, the associated public key certificate may include a pseudonym to disguise the identity of the UAV or its operator. Means for performing the operations of block 802 may include the processor 1301, the network access port(s) 1304, and the antenna(s) 1307 (fig. 13).

In block 806, the processor may receive a request to authenticate the UAV message. The request may include an anonymous token and a digital signature associated with the UAV message. For example, the network computing device may receive the request from a UTM infrastructure (such as a base station or other network access point), another UAV, a recipient device (such as a ground station, smart phone, or other wireless device), and so on. Means for performing the operations of block 806 may include the processor 1301, the network access port(s) 1304, and the antenna(s) 1307 (fig. 13).

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

In block 810, the processor may determine whether the digital signature is verified using a digital certificate. In some embodiments, the processor may cryptographically verify the digital signature using a digital certificate. In some embodiments, the processor may authenticate the digital signature (and/or authenticate the digitally signed UAV message) using a public key associated with the digital certificate. The means for performing the operations of block 810 may include the processor 1301 (fig. 13).

In block 812, in response to determining that the digital signature verifies using the digital certificate, the processor may send an indication that the UAV message was authenticated in response to the request. For example, the processor may send the indication to the requestor device. Means for performing the operations of block 812 may include the processor 1301, the network access port(s) 1304, and the antenna(s) 1307 (fig. 13).

Fig. 9 is a process flow diagram illustrating operations 900 that may be performed by a processor of a network computing device as part of a method 800 for managing UAV identity, in accordance with various embodiments. Referring to fig. 1-9, the operations of method 900 may be performed by a processor of a network processing device. As mentioned above, the UAV may be configured with a plurality of limited use anonymous tokens to enhance anonymity or further reduce traceability of the UAV.

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

In block 904, the processor may provide the anonymous token to the UAV for use in operation including: the UAV is provided with a plurality of anonymous tokens for use in operation, wherein use of each anonymous token is limited by a respective availability time limit. Means for performing the operations of block 904 may include the processor 1301, the network access port(s) 1304, and the antenna(s) 1307 (fig. 13).

The processor may perform the operations of block 806 of method 800 (fig. 8) as described.

Fig. 10 is a process flow diagram illustrating a method 1000 for managing UAV identity in accordance with various embodiments. Referring to fig. 1-10, method 1000 may be performed by a processor of a base station.

In block 1002, a processor may receive an assertion from a UAV that the UAV has authority to perform an operation anonymously. In some embodiments, the assertion may include a digital certificate of the UAV. In some embodiments, the assertion may include an anonymous token. In some embodiments, the anonymous token may include or be associated with a data structure (such as a digital certificate attribute, pointer, or location identifier) that may enable identification or locating (e.g., by a network computing device) of information indicating that the UAV is entitled to perform operations anonymously. In some embodiments, the digital certificate may include information indicating the right for the UAV to anonymously perform the operation. In some embodiments, the anonymous token may include a cryptographically verifiable indication that the anonymous token is associated with a digital certificate of the UAV, such as a hash or a portion of a hash of the digital certificate. Means for performing the operations of block 1002 may include the processor 312, the modem 320, the transceiver 302, and the RF front end 388 (fig. 3).

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

In block 1006, the processor may receive a response from the network computing device indicating whether the UAV has the right to perform the operation anonymously. Means for performing the operations of block 1006 may include the processor 312, the modem 320, the transceiver 302, and the RF front end 388 (fig. 3).

In block 1008, the processor may determine whether the UAV has authority to perform operations anonymously based on the response received from the network computing device. The means for performing the operations of block 1008 may include the processor 312 (fig. 3).

In block 1010, the processor may broadcast information about the UAV that does not configure the identity information of the UAV in response to determining that the UAV has the authority to perform the operation anonymously. Means for performing the operations of block 1010 may include the processor 312, the modem 320, the transceiver 302, and the RF front end 388 (fig. 3).

Fig. 11 is a process flow diagram illustrating operations 1100 that may be performed by a processor of a base station as part of a method 1000 for managing UAV identity, in accordance with various embodiments. Referring to fig. 1-11, operation 1100 may be performed by a processor of a base station.

After performing the operations of block 1010 of method 1000 (fig. 10) as described, the processor may receive a request for an identity of the UAV in block 1102. Means for performing the operations of block 1102 may include the processor 312, the modem 320, the transceiver 302, and the RF front end 388 (fig. 3).

In block 1104, the processor may configure a response message that does not indicate an identity of the UAV based on determining that the UAV is entitled to anonymously perform operations. In some embodiments, the processor may configure the response message to not include information indicative of an identity of the UAV. In some embodiments, the processor may configure the response message to include a pseudonym or another identifier of the UAV that does not indicate the identity of the UAV. In some embodiments, the pseudonym may also be an anonymous token. The means for performing the operations of block 1104 may include the processor 312 (fig. 3).

Fig. 12 is a process flow diagram illustrating operations 1200 that may be performed as part of a method 1000 for managing UAV identity, in accordance with various embodiments. Referring to fig. 1-12, operation 1200 may be performed by a processor of a base station.

After performing the operations of block 1010 of method 1000 (fig. 10) as described, the processor may receive a request to authenticate a UAV message in block 1202, where 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 that has been signed with a digital signature of the UAV. Means for performing the operations of block 1202 may include the processor 312, the modem 320, the transceiver 302, and the RF front end 388 (fig. 3).

In block 1204, the processor may send a request to the network computing device to authenticate the UAV message, wherein the request includes the assertion and the digital signature. Means for performing the operations of block 1204 may include the processor 312, the modem 320, the transceiver 302, and the RF front end 388 (fig. 3).

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

In block 1208, the processor may send an indication that the UAV message is authenticated in response to receiving a response from the network computing device indicating that the UAV message is authenticated. Means for performing the operations of block 1208 may include the processor 312, the modem 320, the transceiver 302, and the RF front end 388 (fig. 3).

Fig. 13 is a block diagram of components of a network computing device 1300 suitable for use with the various embodiments. Such a network computing device (e.g., NCD 701) may include at least the components illustrated in fig. 13. With reference to fig. 1-13, a network computing device 1300 may generally include a processor 1301 coupled to volatile memory 1302 and mass nonvolatile memory, such as disk drive 1308. Network computing device 1300 may also include a peripheral memory access device 1306, such as a floppy disk drive, compact Disk (CD), or Digital Video Disk (DVD) drive, coupled to processor 1301. The network computing device 1300 may also include a network access port 1304 (or interface) coupled to the processor 1301 for establishing a data connection with 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 one or more antennas 1307 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 (Firewire), thunderbolt (Thunderbolt), and the like.

The processor of network computing device 1300 may be any programmable microprocessor, microcomputer or multiple processor chip or chips that can be configured by software instructions (applications) to perform a variety of functions, including the functions that are implemented by some described below. In some wireless devices, multiple processors may be provided, such as one processor within the SOC (e.g., 204) dedicated to wireless communication functions and one processor within the SOC (e.g., 202) dedicated to running other applications. The software applications may be stored in the memory 1302 and then accessed and loaded into the processor. The processor may include internal memory sufficient to store the application software instructions.

Examples of implementations are described in the following paragraphs. While some of the following implementation examples are described in terms of example methods, further example implementations may include: an example method as discussed in the following paragraphs implemented by a network computing device or base station comprising a processor configured with processor-executable instructions to perform operations of the following implementing the example method; an example method discussed in the following paragraphs implemented by a network computing device or base station comprising means for performing the functions of the following implementing example methods; the example methods discussed in the following paragraphs are implemented as a non-transitory processor-readable storage medium having stored thereon processor-executable instructions configured to cause a processor of a network computing device or base station to perform operations of the example methods.

Example 1. A method performed by a processor of a network computing device for managing Unmanned Aerial Vehicle (UAV) identity, 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 to authenticate a UAV message, wherein the request includes the anonymous token and a digital signature associated with the UAV message; identifying the digital certificate using an anonymous token included in the request; determining whether the digital signature is verified using the digital certificate; and in response to determining that the digital signature is verified using the digital certificate, sending an indication that the UAV message was authenticated in response to the request.

Example 2 the method of example 1, wherein the anonymous token includes a cryptographically verifiable indication that the anonymous token is associated with the digital certificate.

Example 3 the method of example 1 or 2, wherein the anonymized token comprises an indication that the UAV is entitled to anonymously perform the operation.

Example 4 the method of any of examples 1-3, wherein the digital certificate includes an indication that the UAV is entitled to anonymously perform operations.

Example 5 the method of any of examples 1-4, wherein the anonymous token is associated with an availability time limit.

Example 6 the method of any of examples 1-5, wherein the anonymous token is associated with an availability geographic limit.

Example 7 the method of any of examples 1-6, wherein the anonymous token comprises a hash of the digital certificate.

Example 8 the method of any of examples 1-7, wherein the anonymous token comprises a hash of the digital certificate concatenated with a secret value.

Example 9 the method of 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.

Example 10 the method of any of examples 1-9, wherein generating the anonymous token associated with the digital certificate of the UAV comprises generating a plurality of anonymous tokens associated with the digital certificate, wherein each anonymous token 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: the plurality of anonymous tokens are provided to the UAV for use in operation, wherein the use of each anonymous token is limited by a respective availability time limit.

Example 11 the method of example 10, wherein generating the plurality of anonymous tokens associated with the digital certificate comprises generating the plurality of anonymous tokens using a keyed hash tree.

Example 12. A method performed by a processor of a base station for managing Unmanned Aerial Vehicle (UAV) identity, comprising: receiving an assertion from the UAV that the UAV has authority to perform operations anonymously; transmitting a request to authenticate the UAV to a network computing device, wherein the request includes the assertion and a digital signature performed on the assertion; receiving a response from the network computing device indicating whether the UAV has the right to perform an operation anonymously; determining, based on the response received from the network computing device, whether the UAV has the right to perform an operation anonymously; and in response to determining that the UAV is entitled to perform an operation anonymously, broadcasting information about the UAV that does not configure identity information of the UAV.

Example 13 the method of example 12, wherein the assertion comprises an anonymous token or digital certificate indicating that the UAV has authority to perform operations anonymously.

Example 14 the method of example 13, wherein the anonymous token includes a cryptographically verifiable indication that the anonymous token is associated with the digital certificate of the UAV.

Example 15 the method of example 14, wherein the digital certificate encodes information indicating that the UAV has authority to perform operations anonymously.

Example 16 the method of any of examples 12-15, wherein the assertion comprises a message and an anonymous token, and wherein the digital signature is performed on the message and the anonymous token.

Example 17 the method of any of examples 12-16, wherein the asserting includes pointing to an attribute or data structure pointer that indicates that the UAV has authority to perform operations anonymously.

Example 18 the method of any one of examples 12-17, further comprising: receiving a request for an 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 entitled to anonymously perform the operation.

Example 19 the method of any of examples 12-18, wherein the assertion comprises an anonymous token that is a product of a cryptographic process and that is unambiguously derived from a digital certificate associated with the UAV.

Example 20 the method of any of examples 12-19, wherein broadcasting information about the UAV that does not configure identity information of the UAV includes broadcasting one or more pseudonym certificates associated with the anonymous token.

Example 21 the method of any one of examples 12-20, further comprising: receiving a request to authenticate a UAV message, wherein the request includes an anonymous token associated with the UAV and a digital signature associated with the UAV message; transmitting a request to authenticate the UAV message to a network computing device, wherein the request includes the anonymous token and the digital signature; receiving a response from the network computing device indicating whether the UAV message is authenticated; and send an indication that the UAV message is authenticated in response to receiving a response from the network computing device indicating that the UAV message is authenticated.

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 a private key of the UAV.

As used in this disclosure, the terms "component," "module," "system," and the like are intended to include a computer-related entity, such as but not limited to hardware, firmware, a combination of hardware and software, or software in execution, configured to perform a particular operation or function. For example, a component may be, but is not limited to being, a process running on a processor, an object, an executable, a thread of execution, a program, or a computer. By way of illustration, both an application running on a wireless device and the wireless device can be referred to as a component. One or more components may reside within a process or thread of execution and a component may be localized on one processor or core or distributed between two or more processors or cores. In addition, these components can execute from various non-transitory computer readable media having various instructions or data structures stored thereon. The components may communicate by way of local and/or remote processes, function or procedure calls, electronic signals, data packets, memory read/write, and other known networks, computers, processors, or process-related communication methodologies.

Several different cellular and mobile communication services and standards are available and contemplated in the future, all of which may be implemented and benefit from the various embodiments. Such services and standards include, for example, third generation partnership project (3 GPP), long Term Evolution (LTE) systems, third generation wireless mobile communication technology (3G), fourth generation wireless mobile communication technology (4G), fifth generation wireless mobile communication technology (5G), next generation 3GPP technologies, global System for Mobile communications (GSM), universal Mobile Telecommunications System (UMTS), 3GSM, general Packet Radio Service (GPRS), code Division Multiple Access (CDMA) systems (e.g., cdmaOne, CDMA1020 TM), enhanced data rates for GSM evolution (EDGE), advanced mobile telephone systems (AMPS), digital AMPS (IS-136/TDMA), evolution data optimized (EV-DO), digital Enhanced Cordless Telecommunications (DECT), worldwide Interoperability for Microwave Access (WiMAX), wireless Local Area Networks (WLAN), wi-Fi protected accesses I and II (WPA, WPA 2), and Integrated Digital Enhanced Networks (iDEN). Each of these techniques involves the transmission and reception of, for example, voice, data, signaling, and/or content messages. It should be understood that any reference to terminology and/or technical details related to individual telecommunication standards or technologies is for illustrative purposes only and is not intended to limit the scope of the claims to a particular communication system or technology unless specifically stated in the claim language.

The various embodiments illustrated and described are provided merely as examples illustrating the various features of the claims. However, the features illustrated and described for any given embodiment are not necessarily limited to the associated embodiment and may be used or combined with other embodiments illustrated and described. Furthermore, the claims are not intended to be limited to any one example embodiment. For example, one or more of the methods and operations 800, 900, 1000, and 1100 may be substituted for or combined with one or more of the methods and operations 800, 900, 1000, and 1100.

The foregoing method descriptions and the process flow diagrams are provided merely as illustrative examples and are not intended to require or imply that the operations of the various embodiments must be performed in the order presented. As will be appreciated by those skilled in the art, the order of operations in the foregoing embodiments may be performed in any order. Words such as "thereafter," "then," "next," and the like are not intended to limit the order of operations; these terms are used to guide the reader through the description of the method. Further, any reference to claim elements in the singular (e.g., using the articles "a," "an," or "the") is not to be construed as limiting the element to the singular.

The various illustrative logical blocks, modules, components, circuits, and algorithm operations described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and operations have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the claims.

The hardware used to implement the various illustrative logic, logic blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of receiver intelligence objects, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Alternatively, some operations or methods may be performed by circuitry dedicated to a given function.

In one or more embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, these functions may be stored as one or more instructions or code on a non-transitory computer-readable storage medium or a non-transitory processor-readable storage medium. The operations of the methods or algorithms disclosed herein may be implemented in a processor-executable software module or processor-executable instructions that may reside on a non-transitory computer-readable or processor-readable storage medium. The non-transitory computer-readable or processor-readable storage medium may be any storage medium that can be accessed by a computer or processor. By way of example, and not limitation, such non-transitory computer-readable or processor-readable storage media can comprise 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 that can be accessed by a computer. Disk (disk) and disc (disk) as used herein include Compact Disc (CD), laser disc, optical disc, digital Versatile Disc (DVD), floppy disk and blu-ray disc where disks (disk) often reproduce data magnetically, while discs (disk) reproduce data optically with lasers. Combinations of the above are also included within the scope of non-transitory computer-readable and processor-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a non-transitory processor-readable storage medium and/or computer-readable storage medium, which may be incorporated into a computer program product.

The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present claims. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the scope of the claims. Thus, the present disclosure is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the following claims and the principles and novel features disclosed herein.

Claims

1. A method performed by a processor of a base station for managing Unmanned Aerial Vehicle (UAV) identity, comprising:

receiving an assertion from a UAV that the UAV has authority to perform an operation 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 a response from the network computing device indicating whether the UAV has the right to perform an operation anonymously;

determining, based on the response received from the network computing device, whether the UAV has authority to perform an operation anonymously; and

in response to determining that the UAV is entitled to perform an operation anonymously, information about the UAV is broadcast for which identity information of the UAV is not configured.

2. The method of claim 1, wherein the assertion comprises an anonymous token or digital certificate indicating that the UAV has authority to perform operations anonymously.

3. The method of claim 2, wherein the anonymous token comprises a cryptographically verifiable indication that the anonymous token is associated with a digital certificate of the UAV.

4. The method of claim 3, wherein the digital certificate encodes information indicating that the UAV has authority to perform operations anonymously.

5. The method of claim 1, wherein the asserting comprises one of:

a message and an anonymous token, wherein the digital signature is performed on the message and the anonymous token;

or an attribute or data structure pointer to information indicating that the UAV has authority to perform operations anonymously.

6. The method of claim 1, further comprising:

receiving a request for an identity of the UAV; and

a response message that does not include a digital certificate-based identity of the UAV is configured based on determining that the UAV has authority to perform operations anonymously.

7. The method of claim 1, wherein the assertion comprises an anonymous token that is a product of cryptographic processing and that is unambiguously derived from a digital certificate associated with the UAV.

8. The method of claim 1, wherein broadcasting information about the UAV that does not configure identity information of the UAV in response to determining that the UAV is entitled to perform operations anonymously comprises: one or more pseudonymous certificates associated with the anonymous token are broadcast.

9. The method of claim 1, further comprising:

receiving a request to authenticate a UAV message, wherein the request includes an anonymous token associated with the UAV and a digital signature associated with the UAV message;

transmitting a request to authenticate the UAV message to a network computing device, wherein the request includes the anonymous token and the digital signature;

receiving a response from the network computing device indicating whether the UAV message is authenticated; and

an indication that the UAV message is authenticated is sent in response to receiving a response from the network computing device indicating that the UAV message is authenticated.

10. The method of claim 9, wherein the structure of the digital signature includes UAV message data, and wherein the digital signature has been generated on the UAV message using a private key of the UAV.

11. A base station, comprising:

a processor configured with processor-executable instructions to:

Receiving an assertion from an Unmanned Aerial Vehicle (UAV) that the UAV has authority to perform an operation anonymously;

12. The base station of claim 11, wherein the processor is further configured with processor-executable instructions such that the assertion comprises an anonymous token or digital certificate indicating that the UAV has authority to perform operations anonymously.

13. The base station of claim 12, wherein the processor is further configured with processor-executable instructions such that the anonymous token includes a cryptographically verifiable indication that the anonymous token is associated with a digital certificate of the UAV.

14. The base station of claim 13, wherein the processor is further configured with processor-executable instructions to cause the digital certificate to encode information indicating that the UAV is entitled to perform operations anonymously.

15. The base station of claim 11, wherein the processor is further configured with processor-executable instructions such that the asserting comprises one of:

a message and an anonymous token, wherein the digital signature is performed on the message and the anonymous token; or alternatively

An attribute or data structure pointer to information indicating that the UAV has authority to perform operations anonymously.

16. The base station of claim 11, wherein the processor is further configured with processor-executable instructions to:

receiving a request for an identity of the UAV; and

17. The base station of claim 11, wherein the processor is further configured with processor-executable instructions such that the assertion comprises an anonymous token that is a product of a cryptographic process and is unambiguously derived from a digital certificate associated with the UAV.

18. The base station of claim 11, wherein the processor is further configured with processor-executable instructions to broadcast one or more pseudonym certificates associated with the anonymous token.

19. The base station of claim 11, wherein the processor is further configured with processor-executable instructions to:

20. The base station of claim 19, wherein the processor is further configured with processor-executable instructions such that the structure of the digital signature includes UAV message data, and wherein the digital signature has been generated on the UAV message using a private key of the UAV.

21. A base station, comprising:

means for receiving, from an Unmanned Aerial Vehicle (UAV), an assertion that the UAV has authority to perform an operation anonymously;

means for 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;

Means for receiving a response from the network computing device indicating whether the UAV has the right to perform an operation anonymously;

means for determining whether the UAV has authority to perform an operation anonymously based on the response received from the network computing device; and

in response to determining that the UAV is entitled to perform an operation anonymously, broadcasting information about the UAV that does not configure identity information of the UAV.

22. The base station of claim 21, wherein the assertion comprises an anonymous token or digital certificate indicating that the UAV has authority to perform operations anonymously.

23. The base station of claim 22, wherein the anonymous token comprises a cryptographically verifiable indication that the anonymous token is associated with a digital certificate of the UAV.

24. The base station of claim 23, wherein the digital certificate encodes information indicating that the UAV has authority to perform operations anonymously.

25. The base station of claim 21, wherein the assertion comprises one of:

26. The base station of claim 21, further comprising:

means for receiving a request for an identity of the UAV; and

means for configuring a response message that does not include a digital certificate-based identity of the UAV based on determining that the UAV is entitled to perform an operation anonymously.

27. The base station of claim 21, wherein the assertion comprises an anonymous token that is a product of cryptographic processing and that is unambiguously derived from a digital certificate associated with the UAV.

28. The base station of claim 21, wherein means for broadcasting information about the UAV that does not configure identity information of the UAV in response to determining that the UAV is entitled to perform operations anonymously comprises: means for broadcasting one or more pseudonymous certificates associated with the anonymous token.

29. The base station of claim 21, further comprising:

means for receiving a request to authenticate a UAV message, wherein the request includes an anonymous token associated with the UAV and a digital signature associated with the UAV message;

means for sending a request to authenticate the UAV message to a network computing device, wherein the request includes the anonymous token and the digital signature;

Means for receiving a response from the network computing device indicating whether the UAV message is authenticated; and

means for sending an indication that the UAV message is authenticated in response to receiving a response from the network computing device indicating that the UAV message is authenticated.

30. The base station of claim 29, wherein the structure of the digital signature comprises UAV message data, and wherein the digital signature has been generated on the UAV message using a private key of the UAV.