Managing Unmanned Aerial Vehicle Identities

Abstract

In an embodiment of a system and method for managing unmanned aerial vehicle (UAV) identity, a processor of a network computing device may generate an anonymity token associated with a digital certificate of the UAV, provide the anonymity token to the UAV for use in operation, receive a request to authenticate the UAV, where the request includes the anonymity token, determine whether the anonymity token included in the request is associated with the digital certificate, and in response to determining that the anonymity token included in the request is associated with the digital certificate, send an indication that the UAV has been authenticated in response to the request.

Description

Claiming priority

[0001] Related Applications

[0001] This application claims the benefit of priority to U.S. Provisional Application No. 63 / 180,502, entitled "Managing An Unmanned Aerial Vehicle Identity," filed on April 27, 2021, and U.S. Nonprovisional Application No. 17 / 482,525, entitled "Managing An Unmanned Aerial Vehicle Identity," filed on September 23, 2021, the entire contents of which are incorporated herein by reference for all purposes. [Technical field]

[0002] The present invention relates to techniques for managing unmanned aerial vehicles (UAVs) identities, for example to enable UAVs to perform operations anonymously. [Background technology]

[0003]

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

[0004]

[0003] These multiple access technologies are being adopted in various telecommunication standards to provide a common protocol that allows different wireless devices to communicate on a city, national, regional, or even global scale. For example, the fifth generation (5G) wireless communication technology (sometimes called New Radio (NR)) is envisioned to extend and support a variety of usage scenarios and applications for the current mobile network generation. In one aspect, the 5G communication technology may include enhanced mobile broadband that addresses human-centric use cases for accessing multimedia content, services, and data, ultra-reliable low-latency communication (URLLC) with several specifications for latency and reliability, and large-scale machine-type communication that may enable a very large number of connected devices and the transmission of a relatively small amount of non-delay sensitive information. However, as the demand for mobile broadband access continues to increase, further improvements beyond NR communication technology may be desired.

[0005]

[0004] Unmanned Aerial System Traffic Management (UTM) is being developed to serve as a traffic management ecosystem for unmanned aerial vehicle (UAV) operations that is separate from, but complementary to, Air Traffic Management (ATM) systems. In many operational scenarios, communications from UAVs require digital certificates to allow receiving devices to authenticate information sent from the UAV. For example, airborne applications such as Remote ID and Detect and Avoid messaging may require trusted, authenticated messages signed by a private encryption key that can be cryptographically verified (e.g., using its public key certificate).

[0006] A typical digital certificate provided by a UAV may include an identifier for the UAV and its operator, which may enable tracking and correlation of the UAV with known operators or entities. Some UAV operators may require operator privacy due to the nature of their identity, role, or mission, but still must sign and broadcast authenticatable messages for security and other operational purposes. Summary of the Invention

[0007]

[0006] Various aspects include a system and method implemented by a processor of a base station for managing UAV identity. Some aspects may include receiving an assertion from a UAV that the UAV is eligible to perform an operation anonymously, sending a request to a network computing device to authenticate the UAV, where 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 is eligible to perform the operation anonymously, determining whether the UAV is eligible to perform the operation anonymously based on the response received from the network computing device, and in response to determining that the UAV is eligible to perform the operation anonymously, broadcasting information about the UAV configured without identity information of the UAV.

[0008]

[0007] In some aspects, the assertion may include an anonymity token or a digital certificate indicating that the UAV is entitled to perform the operation anonymously. In some aspects, the anonymity token may include a cryptographically verifiable indication that the anonymity token is associated with the digital certificate of the UAV. In some aspects, the digital certificate encodes information indicating that the UAV is entitled to perform the operation anonymously. In some aspects, the assertion may include a message and an anonymity token, where a digital signature is performed over the message and the anonymity token. In some aspects, the assertion may include an attribute or a data structure pointer to information indicating that the UAV is entitled to perform the operation anonymously. Some aspects may include receiving a request for the identity of the UAV and, based on determining that the UAV is entitled to perform the operation anonymously, constructing a response message that does not include a digital certificate based identity of the UAV.

[0009] In some aspects, the assertion may include an anonymity token that is a product of a cryptographic process and is explicitly derived from a digital certificate associated with the UAV. In some aspects, in response to determining that the UAV is eligible to perform the operation anonymously, broadcasting information about the UAV configured without identity information of the UAV may include broadcasting one or more pseudonym certificates associated with the anonymity token.

[0010]

[0009] Some aspects may include receiving a request to authenticate the UAV message, where the request may include an anonymity token associated with the UAV and a digital signature associated with the UAV message, sending the request to authenticate the UAV message to a network computing device, where the request may include the anonymity token and the digital signature, receiving a response from the network computing device indicating whether the UAV message was authenticated, and in response to receiving the response from the network computing device indicating that the UAV message was authenticated, sending an indication that the UAV message was authenticated. In some aspects, the structure of the digital signature may include the UAV message data, and the digital signature is generated on the message using a private key of the UAV.

[0011]

[0010] A further aspect includes a base station having a processing system configured to perform one or more operations of any of the methods summarized above. A further aspect includes a processing device for use in a base station, configured with processor-executable instructions for performing operations of any of the methods summarized above. A further aspect includes a non-transitory processor-readable storage medium having stored thereon processor-executable instructions configured to cause a processor of the base station to perform operations of any of the methods summarized above. A further aspect includes a base station having means for performing the functions of any of the methods summarized above.

[0012]

[0011] The disclosed aspects are hereinafter described in conjunction with the accompanying drawings, which are provided to illustrate, but not to limit, the disclosed aspects, and in which like designations refer to like elements. [Brief description of the drawings]

[0013] [Figure 1] FIG. 1 illustrates an example of a wireless communication system and access network. [Diagram 2]1 is a schematic diagram of an example of user equipment, such as a mobile device or UAV. [Diagram 3]

[0014] 1 is a schematic diagram of an example of a base station. [Figure 4]

[0015] 1 is a schematic diagram of an example of an environment for managing UAVs. [Diagram 5]

[0016] FIG. 13 is a sequence diagram of an example process for delivering a certificate by a UAV. [Figure 6A]

[0017] FIG. 1 is a sequence diagram of an example of a UAV initialization process to a network. [Figure 6B]

[0018] FIG. 11 is a sequence diagram of a first example of a process for distributing a certificate by a base station. [Figure 6C]

[0019] FIG. 11 is a sequence diagram of a second example of a process for distributing a certificate by a base station. [Figure 6D]

[0020] FIG. 11 is a sequence diagram of an example of a process for obtaining a certificate by a receiver. [Figure 6E]

[0021] FIG. 13 is a sequence diagram of an example process for broadcasting a certificate by a base station. [Figure 7A]

[0022] FIG. 1 is a sequence diagram of an example process for managing UAV identities. [Figure 7B]

[0023] FIG. 1 is a sequence diagram of an example process for managing UAV identities. [Figure 8]

[0024] A process flow diagram illustrating a method that may be implemented by a processor of a networked computing device for managing UAV identities, according to various embodiments. [Figure 9]

[0025] 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 identities, according to various embodiments. [Figure 10]

[0026] 1 is a process flow diagram illustrating a method that may be implemented by a processor of a base station for managing UAV identities, according to various embodiments. [Figure 11]

[0027] 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 identities, according to various embodiments. [Figure 12]

[0028] 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 identities, according to various embodiments. [Figure 13]

[0029] 1 is a component block diagram of a networked computing device suitable for use with the various embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014]

[0030] The detailed description of the embodiments of the invention described below with reference to the accompanying drawings illustrates various configurations and does not represent the only configurations in which the concepts described herein may be practiced. The detailed description of the embodiments of the invention includes specific details to provide a thorough understanding of the various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form to avoid obscuring such concepts.

[0015]

[0031] Next, several aspects of a telecommunications system are presented with respect to various apparatus and methods that are described in the detailed description that follows 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 on the particular application and design constraints imposed on the overall system.

[0016]

[0032] As an example, an element, or any portion of an element, or any combination of elements, may be implemented as a "processing system" including one or more processors. Examples of processors include microprocessors, microcontrollers, graphics processing units (GPUs), central processing units (CPUs), application processors, digital signal processors (DSPs), reduced instruction set computing (RISC) processors, systems on chips (SoCs), 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 various functions described throughout this disclosure. One or more processors in a processing system may execute software. Software should be broadly construed to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software components, applications, software applications, software packages, routines, subroutines, objects, executable files, threads of execution, procedures, functions, and the like, regardless of whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise.

[0017]

[0033] Thus, in one or more exemplary embodiments, the functions described may be implemented in hardware, software, or any combination thereof. If implemented in software, the functions may be stored on a computer-readable medium or encoded as one or more instructions or codes on the computer-readable medium. Computer-readable media includes computer storage media. A storage medium may be any available medium that can be accessed by a computer. By way of example and not limitation, such computer-readable media may 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 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.

[0018]

[0034] In one implementation, the UAV may partition the certificate into segments. The UAV may embed each segment of the certificate into a frame. The frames containing the partitioned segments may be transmitted consecutively by the UAV. The UAV may transmit a broadcast remote identification. A receiver of the broadcast remote identification and / or certificate segments may append the certificate segments to a certificate to be used to authenticate the broadcast remote identification.

[0019]

[0035] In one implementation, the broadcast remote identity may be a mobile identity (associated with the mobile device or UAV) declared during the broadcasting process. In other cases, the broadcast remote identity may be a certificate associated with or containing the mobile identity. The mobile identity may be a serial number, a government-issued identifier, a universally unique identity, etc.

[0020]

[0036] Various embodiments will now 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 specific examples and implementations are for illustrative purposes only and are not intended to limit the scope of the claims.

[0021]

[0037] Various embodiments include systems and methods implemented by network computing devices and base stations for managing the identity of UAVs. Various embodiments may be used to enable UAVs and base stations to perform operations without transmitting certain identification information that may allow the UAV to be tracked or correlated with a particular UAV operator, while still transmitting information required for safety and other purposes.

[0022]

[0038] While the description refers to a UAV for brevity, it will be understood that a UAV may include one of various types of vehicles that include an on-board computing device configured to provide some autonomous or semi-autonomous capability. Examples of such vehicles include, but are not limited to, an air vehicle, such as a UAV, a ground vehicle (e.g., an autonomous or semi-autonomous car, a vacuum robot, etc.), a water-based vehicle (i.e., a vehicle configured for operation on or under the surface of water), and / or any combination thereof. In some embodiments, the vehicle may be manned. In other embodiments, the vehicle may be unmanned. In embodiments in which the vehicle is autonomous, the vehicle may include an on-board computing device configured to pilot and / or navigate the vehicle without remote operating instructions, such as from a human operator (e.g., via a remote computing device) (i.e., autonomously). In embodiments in which the vehicle is semi-autonomous, the vehicle may include an on-board computing device configured to receive some information or instructions, such as from a human operator (e.g., via a remote computing device), and autonomously pilot and / or navigate the vehicle according to the received information or instructions. In some implementations, the vehicle may be an air vehicle (unmanned or manned), which may be a rotorcraft or a winged aircraft. For example, a rotorcraft (also called a multirotor or multicopter) may include multiple propulsion units (e.g., rotors / propellers) that provide thrust and / or lifting force to the vehicle. Specific non-limiting examples of rotorcraft include tricopters (three rotors), quadcopters (four rotors), hexacopters (six rotors), and octocopters (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 with respect to a vehicle includes vehicle components and / or vehicle payload.

[0023]

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

[0024]

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

[0025]

[0041] As used herein, the terms "network," "system," "wireless network," "cellular network," and "wireless communications network" may interchangeably refer to some or all of a wireless network of a carrier associated with a wireless device and / or a subscription on a wireless device. The techniques described herein may be used for various wireless communications networks, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), FDMA, Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), and other networks. Generally, 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 on one or more frequencies or ranges of frequencies. For example, a CDMA network may implement Universal Terrestrial Radio Access (UTRA) (including the Wideband Code Division Multiple Access (WCDMA) standard), CDMA2000 (including the IS-2000, IS-95, and / or IS-856 standards), 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, etc. 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 do not exclude wireless networks using other communication standards.For example, although various third-generation (3G), fourth-generation (4G), and fifth-generation (5G) systems are described herein, those systems are mentioned by way of example only and future generation systems (e.g., sixth-generation (6G) or higher systems) may be used instead in various examples.

[0026]

[0042] Generally, communications from a UAV are required to include a digital certificate that allows a receiving device to authenticate the information sent from the UAV. Such communications may include, for example, intended maneuvers and other flight operations, observations of other traffic, and observations of the environment. Requiring such communications to be digitally signed allows for authentication of the source of such information. A typical UAV digital certificate may be static and include an identifier for the UAV and its operator, which may allow tracking of the UAV and / or correlation with known operators or entities. As mentioned above, some UAV operators, depending on the nature of their identity, role, or mission, may desire the ability to operate the UAV anonymously while still signing and sending authenticable messages for safety and other operational purposes.

[0027]

[0043] Various embodiments include a method, and a network computing device and a base station configured to implement the method for managing UAV identity. In various embodiments, a UAV may be configured with entitlements or permissions to perform operations without transmitting certain identifying information of the UAV or its operator, which may enable tracking of the UAV or correlation of the UAV with its operator. One example of such identifying information is a digital certificate of the UAV or a digital certificate associated with the UAV. As used herein, performing operations without transmitting such identifying information is referred to as performing operations "anonymously." In various embodiments, when a UAV is operating anonymously, the UAV may be configured to send messages (e.g., digitally signed messages) without such identifying information (such as a digital signature). Furthermore, devices receiving such messages (e.g., digitally signed messages) from the UAV will not be provisioned or provided with information (e.g., a digital signature) that identifies the UAV. Moreover, elements of a UTM, such as a base station, may configure messages with information about the UAV without identity information of the UAV, such as the digital signature of the UAV. For example, some operators, such as law enforcement or military agencies, may need to operate UAVs anonymously from time to time, such as to conduct traffic observations, surveillance operations, etc. As another example, a commercial package delivery operator may obtain permission to operate some UAVs anonymously, such as to covertly deliver packages (such as confidential legal, medical, or business documents, drug prescriptions, medical equipment or devices, medical samples for testing, organs for transplants, etc.) to protect sensitive business operations from observation.

[0028]

[0044] Various embodiments may include methods, and devices configured to implement those methods, for managing UAV identities to enable UAVs to perform operations anonymously. In various embodiments, a UAV may be associated with or 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 anonymity token associated with the UAV's digital certificate. In some embodiments, the network computing device may provide the anonymity token to the UAV for use in operations. In some embodiments, the network computing device may generate the anonymity token using a hash of the digital certificate. In some embodiments, the network computing device may generate the anonymity token using a keyed hash of the digital certificate. In some embodiments, the network computing device may generate the anonymity token using a keyed hash tree of the digital certificate.

[0029]

[0045] The UAV may be configured with an anonymity token, and the UAV may associate the anonymity token with a transmission (referred to herein as a "UAV message"). The anonymity token may enable a receiver to request a transmission and / or authentication of the transmitting UAV without receiving the identity of the UAV and / or the UAV operator. In some embodiments, the UAV may digitally sign the UAV message using a cryptographic key associated with the UAV. In some embodiments, the anonymity token may include a cryptographically verifiable indication that the anonymity token is associated with the UAV's digital certificate. In some embodiments, the anonymity token may include an indication that the UAV (and / or UAV operator) is entitled to perform operations anonymously.

[0030]

[0046] 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, from another UAV, from a receiving device, such as a ground station, a smartphone, or other suitable device, etc. In some embodiments, the request may include an anonymity token and a digital signature associated with the UAV message. In some embodiments, the request may include message information signed with the digital signature (sometimes referred to as "signed data"). The network computing device may identify a digital certificate using the anonymity token included in the request. For example, the network computing device may identify a digital certificate associated with the anonymity token. In some embodiments, an association between a digital certificate and one or more anonymity tokens may be stored in a memory or memory device accessible by the network computing device.

[0031]

[0047] 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 the 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 that the transmitting UAV may be considered a trusted source. In some embodiments, the network computing device may send an indication that the message was authenticated in response to the request in response to determining that the digital signature is verified using the digital certificate.

[0032]

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

[0033]

[0049] In some embodiments, the anonymity token may be associated with a usability time limitation. For example, the anonymity token may be associated with a validity period or another time limitation on its usability that limits the usefulness of the anonymity token to a specified time range or duration, outside of which the UAV will not be able to use the anonymity token to perform operations anonymously. In some embodiments, the anonymity token may include or be associated with an encoding of the usability time limitation. In some embodiments, the network computing device may determine the association of the anonymity token with a usability time limitation by, for example, referencing information stored in a data structure, such as a database.

[0034]

[0050] In some embodiments, the anonymity token may be associated with a usability geographic limitation. For example, the anonymity token may be associated with a geofence, coordinates, or another geographic limitation on its usability that limits the utility of the anonymity token to a specified location, area, or physical region, such as may correspond to a legal jurisdiction, a theater of operation, a specified delivery route or path of travel, etc., outside of which the UAV will not be able to use the anonymity token to perform operations anonymously. In some embodiments, the anonymity token may include or be associated with an encoding of the usability geographic limitation. In some embodiments, the network computing device may determine the association of the anonymity token and the usability geographic limitation, for example, by referencing information stored in a database or other suitable data structure.

[0035]

[0051] In some embodiments, to improve the UAV's ability to perform operations anonymously, the network computing device may generate multiple anonymity tokens associated with the UAV's digital certificate, and the multiple anonymity tokens may be configured in the UAV's memory (e.g., uploaded and stored in the UAV's memory). In some embodiments, the multiple anonymity tokens may be cryptographically associated with the digital certificate. For example, each anonymity token may be associated with a single certificate or with a unique certificate. In such embodiments, the association between each anonymity token and the digital certificate may be maintained by the network computing device. In some embodiments, the network computing device may generate multiple anonymity tokens using a hash of the digital certificate. In some embodiments, the network computing device may generate multiple anonymity tokens using a keyed hash of the digital certificate. In some embodiments, the network computing device may generate multiple anonymity tokens using a keyed hash tree of the digital certificate. In some embodiments, the network computing device may maintain a private key used by the network computing device in a keyed hashing process to create the multiple anonymity tokens. In some embodiments, the UAV may cycle through its multiple anonymity tokens for inclusion in one or more transmissions. In some embodiments, the UAV may randomly select an anonymity token from among multiple anonymity tokens for use in a transmission. In some embodiments, each of the multiple anonymity tokens may be configured with a usability time limit. In some embodiments, each of the multiple anonymity tokens may be limited to use in a single transmission (i.e., one-time-use). In this manner, the UAV may transmit messages that are authentic and anonymous with respect to the identity of the UAV and / or its operator.

[0036]

[0052] In various embodiments, a base station, access point, or other device that provides a wireless communication link and supports access to a communication network (collectively referred to herein as a “base station” for brevity) may be configured to perform a method for managing UAV identities. In some embodiments, the base station may be configured to receive an assertion from the UAV that the UAV is entitled to perform operations anonymously. In some embodiments, the assertion may include an anonymity token or digital certificate, which may include an indication (such as information that includes the assertion) that the UAV is entitled to perform operations anonymously. In some embodiments, the assertion may include a message and an anonymity token. In some embodiments, a digital signature is performed on the message and the anonymity token. In some embodiments, the assertion may include an attribute or a data structure pointer to information indicating that the UAV is entitled to perform operations anonymously. The data structure pointer may be a record locator or other suitable information that points to a location of information in a data structure, such as a database. In some embodiments, such a database may be managed by or accessible by the network computing device. In some embodiments, the anonymity token included in the assertion may be the product of a cryptographic process, such as a hash of a digital certificate. The cryptographic process may allow the anonymity token to be unambiguously associated with a digital signature associated with the UAV. In some embodiments, the anonymity token may include a cryptographically verifiable indication that the anonymity token is associated with the digital certificate of the UAV.

[0037]

[0053] In some embodiments, the base station may send a request to the network computing device to authenticate the UAV, where the request includes an 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 is eligible to perform operations anonymously. Based on the response from the network computing device, the base station may determine whether the UAV is eligible to operate anonymously. In response to determining that the UAV is eligible to operate anonymously, the base station may broadcast information about the configured UAV without identity information of the UAV. In some embodiments, the broadcast may further include one or more pseudonym certificates associated with an anonymity token that other UTM entities may use to authenticate the UAV broadcast without receiving information about the UAV identity.

[0038]

[0054] The base station may be configured to handle requests from another device asking the base station to authenticate a UAV. Non-limiting examples of another device that may make such requests include another UAV, a ground station, a receiving device, such as a smartphone, or a UAV controller device, and the like. In some embodiments, the base station may receive a request to authenticate a UAV message, where the request includes an anonymity token associated with the UAV and a digital signature associated with the UAV included in the UAV message. For example, the other device may receive a UAV message from the UAV and extract an assertion in a digital signature or another signed data structure from the UAV message. The other device may include the received assertion and the digital signature in a request (e.g., to the base station) for authentication of the UAV message. In some embodiments, the digital signature may include message data signed with the digital signature.

[0039]

[0055] 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 an anonymity token and a digital signature associated with the UAV message (e.g., a digitally signed UAV message, a digital signature generated using the UAV message, etc.). The base station may receive a response from the network computing device indicating whether the UAV message is authenticated. In some embodiments, the base station may determine whether the UAV message is authenticated based on the response from the network computing device. In some embodiments, the base station may relay or pass on an indication received from the network computing device regarding whether the UAV message is authenticated. In this manner, the base station may send an indication that the UAV message is authenticated. In some embodiments, the structure of the digital signature may include the UAV message data. In some embodiments, the digital signature may be generated on the UAV message using the UAV's private key.

[0040]

[0056] Various embodiments may be implemented in various scenarios. For example, a law enforcement UAV may need to exchange detect-and-avoid (DAA) messages to perform reconnaissance operations and avoid near misses or collisions with other UAVs in an area where other UAVs are operating simultaneously. In non-anonymous operations, the law enforcement UAV drone may either transmit its digital certificate along with a signed DAA message or make its digital certificate available to the message receiver via the UTM infrastructure (e.g., upon request via a base station) so that the message receiver can cryptographically verify and trust messages received from the UAV. When the law enforcement UAV performs operations anonymously, the law enforcement UAV may digitally sign outgoing messages with an anonymity token that may be associated with a public key certificate. Additionally, the law enforcement UAV may send notifications, instructions, or requests to the UTM infrastructure (e.g., a base station) not to broadcast the digital certificate associated with the law enforcement UAV. A receiving device that needs to authenticate a transmission received from a UAV may send a request to a base station or to a remote verification service (e.g., a network computing device), which may perform operations to provide confirmation or denial of the authenticity of the UAV's transmission without revealing the identity of the law enforcement UAV or its operator.

[0041]

[0057] As another example, a commercial package delivery UAV operator may wish to operate its UAV anonymously, e.g., to prevent competitors from analyzing its business operations or to facilitate the transport of confidential or sensitive documents, medicines, medical devices, etc. To accommodate such situations, the UAV operator may be granted an exemption from transmitting certain static or traceable message content or, in some cases, making its certificate available to other entities. Then, when such an operator's UAV performs operations anonymously, the UAV may digitally sign the transmissions associated with an anonymity token that enables authentication of the transmissions and / or the UAV and / or the UAV operator without revealing the identity of the UAV and / or the UAV operator.

[0042]

[0058] FIG. 1 illustrates an example of a wireless communication system and access network 100. The wireless communication system (also referred to as a wireless wide area network (WWAN)) includes at least one BS 105, a UE 110, an evolved packet core (EPC) 160, and a 5G core (5GC) 190. The BS 105 may include macrocells (high-power cellular base stations) and / or small cells (low-power cellular base stations). The macrocells include base stations. The 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 BS 105 or other UEs 110 via a cellular network, a Wi-Fi network, or other wireless and wired networks. The UE 110 may include a certificate component 224 that retrieves the certificate, segments the certificate, and / or embeds the certificate segments into the frame. In some implementations, the BS 105 may include a communications component 322 configured to communicate with the UE 110.

[0043]

[0059] A BS 105 configured for 4G LTE (collectively referred to as Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN)) may interface with the EPC 160 through a backhaul link interface 132 (e.g., an S1, X2, Internet Protocol (IP), or flex interface). A BS 105 configured for 5G NR (collectively referred to as Next Generation RAN (NG-RAN)) may interface with the 5GC 190 through a backhaul link interface 134 (e.g., an S1, X2, Internet Protocol (IP), or flex interface). In addition to other functions, the BSs 105 may perform one or more of the following functions: forwarding of user data, radio channel encryption and decryption, integrity protection, header compression, mobility control functions (e.g., handover, dual connectivity), inter-cell interference coordination, connection setup and release, load balancing, distribution for non-access stratum (NAS) messages, NAS node selection, synchronization, radio access network (RAN) sharing, multimedia broadcast multicast service (MBMS), subscriber and equipment tracing, RAN information management (RIM), paging, positioning, and distribution of alert messages. The BSs 105 may communicate with each other directly or indirectly (e.g., through the EPC 160 or 5GC 190) over the backhaul link interface 134. The backhaul links 132, 134 may be wired or wireless.

[0044]

[0060] The BSs 105 may wirelessly communicate with the UEs 110. Each of the BSs 105 may provide communication coverage in a respective geographic coverage area 130. There may be overlapping geographic coverage areas 130. For example, a 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 including both small cells and macro cells may be known as a heterogeneous network. A heterogeneous network may also include a home evolved Node B (eNB) (HeNB) that may serve a closed group known as a closed subscriber group (CSG). The communication link 120 between the BSs 105 and the UEs 110 may include uplink (UL) transmissions (also referred to as reverse link) from the UEs 110 to the BSs 105 and / or downlink (DL) transmissions (also referred to as forward link) from the BSs 105 to the UEs 110. The communication link 120 may use multiple-input multiple-output (MIMO) antenna techniques, including spatial multiplexing, beamforming, and / or transmit diversity. The communication link may be over one or more carriers. The BS 105 / UE 110 may select the highest total Y carriers used for transmission in each direction. x The UE may use up to Y MHz (e.g., 5, 10, 15, 20, 100, 400 MHz, etc.) bandwidth spectrum per carrier allocated in carrier aggregation of 100 MHz (x component carriers). The carriers may be adjacent or non-adjacent to each other. The carrier allocation may be asymmetric with respect to DL and UL (e.g., more or fewer carriers may be allocated for DL ​​than for 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).

[0045]

[0061] Several UEs 110 may communicate with each other using device-to-device (D2D) communication links 158. The D2D communication links 158 may use DL / UL WWAN spectrum. The D2D communication links 158 may use one or more sidelink channels, such as a physical sidelink broadcast channel (PSBCH), a physical sidelink discovery channel (PSDCH), a physical sidelink shared channel (PSSCH), and a physical sidelink control channel (PSCCH). The D2D communication may be through various wireless D2D communication systems, such as, for example, FlashLinQ, WiMedia, Bluetooth, ZigBee, Wi-Fi based on the IEEE 802.11 standard, LTE, or NR.

[0046]

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

[0047]

[0063] The small cell 105' may operate in licensed and / or unlicensed frequency spectrums. When operating in an unlicensed frequency spectrum, the small cell 105' may employ NR and use the same 5 GHz unlicensed frequency spectrum used by the Wi-Fi AP 150. The small cell 105' employing NR in the unlicensed frequency spectrum may boost coverage to and / or increase capacity of the access network.

[0048]

[0064] The BS 105 may include an eNB, gNodeB (gNB), or other type of base station, whether a small cell 105′ or a large cell (e.g., a macro base station). Some base stations, such as the gNB 180, may operate in the conventional sub-6 GHz spectrum, in millimeter wave (mmW) frequencies, and / or near-mmW frequencies in communication with the 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 radio frequency (RF) in the electromagnetic spectrum. EHF has a range of 30 GHz to 300 GHz and a wavelength between 1 millimeter and 10 millimeters. Radio waves in that band may be referred to as millimeter waves. Near-mmW may extend down to frequencies of 3 GHz with a wavelength of 100 millimeters. The very high frequency (SHF) band, also called centimeter wave, extends between 3 GHz and 30 GHz. Communications using the 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 the path loss and short range.

[0049]

[0065] The 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. The MME 162 may be in communication with a Home Subscriber Server (HSS) 174. The MME 162 is a control node that handles signaling between the UE 110 and the EPC 160. In general, the MME 162 provides bearer and connection management. All user Internet Protocol (IP) packets are forwarded through the Serving Gateway 166, which is itself connected to the PDN Gateway 172. The PDN Gateway 172 provides IP address allocation for the UE as well as other functions. The PDN Gateway 172 and the BM-SC 170 are connected to an IP Service 176. The IP services 176 may include Internet, intranet, 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 act as an entry point for content provider MBMS transmissions, may be used to authorize and start MBMS bearer services in a Public Land Mobile Network (PLMN), and may be used to schedule MBMS transmissions. The MBMS Gateway 168 may be used to deliver MBMS traffic to BSs 105 that belong to a Multicast Broadcast Single Frequency Network (MBSFN) area that broadcasts a particular service, and may be responsible for session management (start / stop) and collecting eMBMS-related charging information.

[0050]

[0066] The 5GC 190 may include an Access and Mobility Management Function (AMF) 192, another AMF 193, a Session Management Function (SMF) 194, and a User Plane Function (UPF) 195. The AMF 192 may be in communication with an Unified Data Management (UDM) 196. The AMF 192 is a control node that handles signaling between the UE 110 and the 5GC 190. Generally, the AMF 192 provides QoS flow and session management. All user Internet Protocol (IP) packets are forwarded through the UPF 195. The UPF 195 provides IP address allocation for the UE as well as other functions. The UPF 195 is connected to IP services 197. The IP services 197 may include the Internet, intranet, IP multimedia subsystem (IMS), PS streaming services, and / or other IP services.

[0051]

[0067] The BS 105 may also be referred to as a gNB, Node B, evolved Node B (eNB), access point, base transceiver station, radio base station, access point, access node, radio transceiver, Node B, eNode B (eNB), gNB, Home Node B, Home eNode B, relay, transceiver function, basic service set (BSS), enhanced service set (ESS), transmit reception point (TRP), or some other suitable terminology. The BS 105 provides an access point to the EPC 160 or 5GC 190 for the UEs 110. Examples of the UEs 110 include a cellular phone, a smartphone, 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 electric meter, a gas pump, a large or small kitchen appliance, a healthcare device, an implant, a sensor / actuator, a display, or any other similarly functional device. Some of the UEs 110 may be referred to as IoT devices (e.g., a parking meter, a gas pump, a toaster, a vehicle, a heart monitor, etc.) The UEs 110 may also be referred to as a station, a mobile station, a subscriber station, a mobile unit, a subscriber unit, a wireless unit, a remote unit, a mobile device, a wireless device, a wireless communication device, a remote device, a mobile subscriber station, an access terminal, a mobile terminal, a wireless terminal, a remote terminal, a handset, a user agent, a mobile client, a client, or some other suitable terminology.

[0052]

[0068] In some examples, the UE 110 may include, be part of, or be the same as a mobile device, a UAV, a UAS, or the like.

[0053]

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

[0054]

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

[0055]

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

[0056]

[0072] The memory 216 may also be configured to store data used herein and / or local versions of the application 275 or the communication component 222, the certificate component 224, and / or one or more subcomponents of the communication component 222 and / or the certificate component 224 being executed by the at least one processor 212. The 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 one aspect, for example, the memory 216 may be a non-transitory computer-readable storage medium that stores one or more computer-executable codes defining the communication component 222, the certificate component 224, and / or one or more of its subcomponents, and / or data associated therewith, when the UE 110 operates the at least one processor 212 to execute the communication component 222, the certificate component 224, and / or one or more of the subcomponents.

[0057]

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

[0058]

[0074] Moreover, in an aspect, the UE 110 may include an RF front end 288 that may be operative in communication with the one or more antennas 265 and the transceiver 202 to receive and transmit radio transmissions, e.g., wireless communications transmitted by at least one BS 105 or wireless transmissions transmitted by the UE 110. The RF front end 288 may be coupled to the 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 to transmit and receive RF signals.

[0059]

[0075] In one aspect, the LNAs 290 may amplify the received signal at a desired power level. In one aspect, each LNA 290 may have a specified minimum and maximum gain value. In one 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 the desired gain value for a particular application.

[0060]

[0076] Additionally, one or more PAs 298 may be used by the RF front end 288, for example, to amplify a signal for RF output at a desired output power level. In an aspect, each PA 298 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 PA 298 and a specified gain value based on the desired gain value for a particular application.

[0061]

[0077] Also, for example, one or more filters 296 may be used by the RF front end 288 to filter a received signal to obtain an input RF signal. Similarly, in an aspect, for example, each filter 296 may be used to filter an output from a respective PA 298 to produce an output signal for transmission. In an aspect, each filter 296 may be coupled to 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 that uses a specified filter 296, LNA 290, and / or PA 298 based on a configuration specified by the transceiver 202 and / or processor 212.

[0062]

[0078] Thus, the transceiver 202 may be configured to transmit and receive wireless signals through one or more antennas 265 via the RF front end 288. In an aspect, the transceiver may be tuned to operate at a designated frequency such that the UE 110 may communicate with, for example, one or more BSs 105, or one or more cells associated with the one or more BSs 105. In an aspect, for example, the modem 220 may configure the transceiver 202 to operate at a designated frequency and power level based on the UE configuration of the UE 110 and a communication protocol used by the modem 220.

[0063]

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

[0064]

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

[0065]

[0081] In some implementations, the BS 105 may include various components, including one or more processors 312 and components such as memory 316 and transceiver 302 in communication over one or more buses 344, which may operate in conjunction with a modem 320 and communications components 322 to facilitate one or more of the functions described herein related to communicating with the UE 110. Additionally, 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 (concurrently or non-concurrently) over one or more radio access technologies.

[0066]

[0082] In one aspect, the one or more processors 312 may include a modem 320 using one or more modem processors. Various functions related to the communication component 322 may be included in the modem 320 and / or the processor 312, and in one aspect may be performed by a single processor, while in other aspects different ones of the functions may be performed by a combination of two or more different processors. For example, in one aspect, the one or more processors 312 may include any one or any combination of a modem processor associated with the transceiver 302, or a baseband processor, or a digital signal processor, or a transmit processor, or a receive device processor, or a transceiver processor. Furthermore, the modem 320 may constitute the BS 105 and the processor 312. In other aspects, some of the features of the one or more processors 312 and / or the modem 320 associated with the communication component 322 may be implemented by the transceiver 302.

[0067]

[0083] The memory 316 may also be configured to store data used herein, and / or the application 375 or the communication component 322, a local version of the determination component, and / or one or more subcomponents of the communication component 322 or the determination component being executed by the at least one processor 312. The memory 316 may include any type of computer readable medium usable by the computer or at least one processor 312, such as random access memory (RAM), read only memory (ROM), tape, magnetic disk, optical disk, volatile memory, non-volatile memory, and any combination thereof. In one aspect, for example, the memory 316 may be a non-transitory computer readable storage medium that stores one or more computer executable codes defining the communication component 322, the determination component, and / or one or more of its subcomponents, and / or data associated therewith, when the BS 105 operates the at least one processor 312 to execute the communication component 322, the determination component, and / or one or more of the subcomponents.

[0068]

[0084] 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, firmware, and / or software code executable by a processor for receiving data, where the code comprises instructions and is stored in a memory (e.g., a computer-readable medium). The receiver 306 may be, for example, an RF receiving device. In one aspect, the receiver 306 may receive a signal transmitted by the UE 110. The transmitter 308 may include hardware, firmware, and / or software code executable by a processor for transmitting data, where the code comprises instructions and is stored in a memory (e.g., a computer-readable medium). A suitable example of the transmitter 308 may include, but is not limited to, an RF transmitter.

[0069]

[0085] Moreover, in an aspect, the BS 105 may include an RF front end 388 that may be operative in communication with the one or more antennas 365 and the transceiver 302 to receive and transmit radio transmissions, e.g., wireless communications transmitted by other BSs 105 or wireless transmissions transmitted by the UE 110. The RF front end 388 may be coupled to the 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 to transmit and receive RF signals.

[0070]

[0086] In one aspect, the LNAs 390 may amplify the received signal at a desired power level. In one aspect, each LNA 390 may have a specified minimum and maximum gain value. In one aspect, the RF front end 388 may use one or more switches 392 to select a particular LNA 390 and a specified gain value based on the desired gain value for a particular application.

[0071]

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

[0072]

[0088] Also, for example, one or more filters 396 may be used by the RF front end 388 to filter a received signal to obtain an input RF signal. Similarly, in an aspect, for example, each filter 396 may be used to filter an output from a respective PA 398 to produce an output signal for transmission. In an aspect, each filter 396 may be coupled to 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 that uses a specified filter 396, LNA 390, and / or PA 398 based on a configuration specified by the transceiver 302 and / or processor 312.

[0073]

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

[0074]

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

[0075]

[0091] Referring to FIG. 4, in one implementation, an example of an environment 400 for managing UAVs may include a mobile device 402. The mobile device 402 may include, be part of, or be the same as the UE 110. The mobile device 402 may be a UAV, an unmanned aerial system (UAS), a drone, or other device controllable 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 receiver 410a, a second receiver 410b, and a third receiver 410c. The first receiver 410a may be a third-party authorized entity (such as a police detector, a civilian / government detector, a regulatory agency, etc., a TPAE). The second receiver 410b and the third receiver 410c may be mobile devices, such as UAVs. Other types of receivers are possible. The mobile device 402 may communicate with the first receiver 410a via a wireless communication link 412, such as Bluetooth, Wi-Fi, a cellular device-to-device link, or other wireless communication link. The mobile device 402 may communicate with the second receiver 410b via a D2D communication link 158, such as Bluetooth, Wi-Fi, a cellular device-to-device link, or other wireless communication link. The mobile device 402 may communicate with the third receiver 410c via a communication link 154, such as Bluetooth, Wi-Fi, a cellular device-to-device link, or other wireless communication link. Other communication links may be used for communication.

[0076]

[0092] In some implementations, the environment 400 may include a first BS 105a having a first coverage area 130a and a second BS 105b having a second coverage area 130b. 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 supplier (USS) 420. The USS 420 may optionally include a UAV flight management system (UFMS) 422. In some optional implementations, the UFMS 422 may be implemented in the core network 430. In other optional implementations, the UFMS 422 may be implemented in a standalone server separate from the USS 422. The USS 420 and / or UFMS 422 may communicate with the first receiver 410a via a communication link 414 (e.g., WiFi, long range wireless, cellular link, fiber optics, etc.) or via a core network 430. The USS 420 and / or UFMS 422 may communicate with the core network 430 via a communication interface 416 (e.g., 5GC190 network publishing function, EPC160 service capability publishing function, 3GPP® Rx interface, etc.).

[0077]

[0093] In one implementation of the present disclosure, the 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, timestamp precision, operation status, operation description, latitude, longitude, geodetic altitude, height above takeoff, barometric altitude of position, vertical accuracy, horizontal accuracy, speed (North / South), speed (East / West), vertical speed, operator latitude, operator longitude, 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 in the remote ID (e.g., UAV ID) from the USS 420 and / or UFMS 422 via a cellular network (e.g., the first BS 105a, the second BS 105b, etc.).

[0078]

[0094] In some implementations, the remote ID may include a network remote ID (NRID) and a broadcast remote ID (BRID). The NRID and / or the 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.

[0079]

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

[0080]

[0096] In one aspect of the disclosure, the mobile device 402 may broadcast the BRID to one or more of the first receiver 410a, the second receiver 410b, and / or the third receiver 410c. To enable the first receiver 410a, the second receiver 410b, and / or the third receiver 410c to authenticate the BRID, the mobile device 402 may transmit (e.g., unicast, multicast, or broadcast) a certificate. The certificate may be the mobile device's 402 certificate, a certificate from a certificate authority that assigned the mobile device's 402 certificate, or a chain of trust file indicating one or more hierarchies of certificates, each up to a root certificate or other designated authority. The mobile device 402 may partition the certificate into n parts and transmit the n parts of the certificate in n frames. For example, the mobile device 402 may partition the certificate into 20 parts (n=20). The mobile device 402 may embed the 20 certificate segments / segments into 20 frames and transmit the 20 frames consecutively to one or more of the first receiver 410a, the second receiver 410b, and / or the third receiver 410c. For example, frame 1 may include certificate portion 1, frame 2 may include certificate portion 2, etc. Once a receiver (e.g., the first receiver, the second receiver, and / or the third receiver) receives all of the frames (e.g., the 20 frames), the receiver (e.g., ...) may concatenate the certificate portions (e.g., the 20 portions of the 20 frames) to generate or form a certificate (e.g., a certificate for the mobile device 402).

[0081]

[0097] In some circumstances, using a certificate to authenticate the BRID may allow the receivers 410a-410c to simultaneously verify the authenticity of the mobile device 402.

[0082]

[0098] In some aspects, the mobile device 402 may indicate the number of parts (or frames) for the certificate to the receivers 410a-410c. For example, the mobile device 402 may partition the certificate into 50 parts and embed the 50 parts into 50 frames. The mobile device 402 may indicate in the first frame (containing the first part of the certificate) that there are 50 parts of the certificate to be transmitted. In response, the receivers 410a-410c may assemble the certificate after receiving the 50 parts in the 50 frames.

[0083]

[0099] In another aspect, the mobile device 402 may indicate to the receivers 410a-410c the last frame carrying the last portion of the certificate. For example, the mobile device 402 may partition the certificate into 15 portions and embed the 15 portions into 15 frames. The mobile device 402 may indicate in the 15th frame that it is the last frame carrying portions of the certificate. In response, the receivers 410a-410c may assemble the certificate after receiving the 15th frame (having the 15th or last portion).

[0084]

[0100] In some aspects, a frame carrying a portion of a certificate may be marked as a certificate frame.

[0085]

[0101] In some aspects, the number of frames used to transmit portions (i.e., segments) of the certificate may be dynamically determined based on factors such as weather conditions, traffic, regulatory requirements, the technology used for transmission, etc.

[0086]

[0102] In some implementations, after the receivers 410a-410c concatenate the certificate from the certificate portions, the receivers 410a-410c may use the certificate to authenticate the BRID and / or other messages sent by the mobile device 402.

[0087]

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

[0088]

[0104] In one aspect of the disclosure, the mobile device 402 may receive a security profile (e.g., an IEEE 1609.2 security profile). The mobile device 402 may receive the security profile during installation, programming, setup, initialization, or registration of the mobile device 402. The security profile may indicate a periodicity for transmitting frames carrying portions of the certificate.

[0089]

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

[0090]

[0106] In a different aspect, the first BS 105a 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 transmitted periodicity may be one of a value (e.g., 1s, 2s, 5s, 10s, 20s, 50s, 100s, etc.) or a set of predefined indices (e.g., 0-none, 1-5s, 2-10s, 3-20, etc.).

[0091]

[0107] In some aspects of the disclosure, the first BS 105a serving the mobile device 402 may dynamically update the periodicity of the mobile device 402 via an RRC message. The first BS 105a may send an RRC message to the mobile device 402 to change the periodicity for transmitting frames carrying portions of a certificate, for example, from 10s to 15s.

[0092]

[0108] In one implementation, the periodicity may be a function of the flight plan of the mobile device 402, the geographic area along the light plan, local / regional / national policies, traffic density, topographical interference, or other factors related to the operation of the mobile device 402.

[0093]

[0109] 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 demand for certificates, etc. In some implementations, the periodicity may be determined 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 related to the quality of the communication channel.

[0094]

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

[0095]

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

[0096]

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

[0097]

[0113] In a fourth example, the USS 420 and / or the UFMS 422 may provide a certificate to the core network 430. The core network 430 may determine a geographic location of the mobile device 402 based on location information (e.g., latitude, longitude, altitude, etc.) in the remote ID, BRID, and / or NRID. The core network 430 may determine one or more coverage areas and corresponding base stations associated with the geographic location, such as the first BS 105a and the first coverage area 130a. The core network 430 may provide the certificate to the first BS 105a after determining that the mobile device 402 is within the first coverage area 130a. Upon receiving the certificate, the first BS 105a may broadcast the certificate 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 receiver 410b may receive the BRID from the mobile device 402. The second receiver 410b may use the certificate to authenticate the BRID from the mobile device 402. The first BS 105a and the second BS 105b may broadcast the received certificate using a cellular broadcast system with indication of the BRID certificate, a commercial mobile alert system (CMAS) with indication of the BRID certificate, or using a multimedia broadcast / multicast system using a common or dedicated channel for the BRID certificate, where all receivers subscribe to receive the BRID certificate.

[0098]

[0114] In a fifth example, the first BS 105a may receive a certificate from the mobile device 402, the core network 430, the UFMS 422, and / or the USS 420. The first BS 105a may receive a flight / traffic plan for the mobile device 402 from the core network 430, the UFMS 422, and / or the USS 420. Based on the flight plan, the first BS 105a may determine a geographic area into which the mobile device 402 will be. The first BS 105a may identify a coverage area, such as the second coverage area 130b of the second BS 105b, associated with the geographic area into which the mobile device 402 will be. In response, the first BS 105a may identify that the second BS 105b is associated with the second coverage area 130b and may send a certificate to the second BS 105b (for broadcast to receivers in the second coverage area 130b) before the mobile device 402 enters the second coverage area 130b.

[0099]

[0115] In some aspects of the disclosure, the receivers 410a-410c may use the certificate to authenticate any message sent by the mobile device 402. Once authenticated, the receivers 410a-410c may verify the authenticity and / or integrity of any message of the mobile device 402. In another example, the mobile device 402 may use any message as a BRID.

[0100]

[0116] Referring to FIG. 5, in some implementations, an example of a sequence diagram 500 may include a UAV 502, a first receiver 504, a second receiver 506, a radio access network (RAN) 508, a core network 430, a UFMS 422, and a USS 420. The first receiver 504 and / or the second receiver 506 may be a UAV, a mobile device, a UE, a TPAE, a base station, a controller, or other devices. In operation 520, the UAV 502 may be configured by obtaining a UAV ID and perform certificate bootstrapping (e.g., security certificates). In communication 522, the UAV 502 may send an RRC connection request to the RAN 508. In communication 524, the RAN 508 may send an RRC connection response to the UAV 502 with parameters for establishing a wireless communication link between the RAN 508 and the UAV 502. At communication 526, the UAV 502 may transmit an RRC connection complete message to the RAN 508. At communication 528, the RAN 508 may optionally transmit an RRC connection reconfiguration message to the UAV 502. The reconfiguration may change connection and / or operational parameters of the UAV 502, such as, as one example, the periodicity for transmitting portions of the certificate. At communication 530, the UAV 502 may optionally transmit an RRC connection reconfiguration complete message to the RAN 508 in response to completing the reconfiguration.

[0101]

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

[0102]

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

[0103]

[0119] In another optional implementation, the nth frame may include an end indicator indicating that the nth frame is carrying the last segment of the certificate by the UAV 502.

[0104]

[0120] In one optional implementation, the UAV 502 may assign sequential numbers to the n frames that correspond to the order of the segments of the certificate. The frame carrying the first segment of the certificate may be assigned "1." The frame carrying the second segment of the certificate may be assigned "2," and so on.

[0105]

[0121] In one aspect of the disclosure, the UAV 502 may partition the certificate into segment groups. The UAV 502 may consecutively embed each of the segment groups (equal or unequal in number) into a corresponding frame for transmission. For example, the UAV 520 may partition the certificate into 50 segments. The UAV 520 may group the 50 segments of the certificate into ten 5 segment groups (e.g., group 1-segments #1-10, group 2-segments #11-20, etc.). The UAV 520 may embed a first segment group into a first frame, a second segment group into a second frame, etc. The UAV 520 may consecutively transmit 5 frames carrying the 5 segment groups. In some implementations, the groups may have the same or different number of segments.

[0106]

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

[0107]

[0123] In alternative implementations, each segment of the certificate may be associated with an identifier. For example, the UAV 520 may partition the certificate into 30 segments. The UAV 520 may mark the first segment with a "1", the second segment with a "2", ... the 30th segment with a "30". If the first receiver 504 is unable to receive some of the segments (e.g., the 17th segment marked with an identifier "17"), the first receiver 504 may send a request to the UAV 520 to retransmit the 17th segment using the identifier.

[0108]

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

[0109]

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

[0110]

[0126] In some instances, the number of segments into which the UAV 502 divides the certificate may depend on the communication link technology, the operation of the UAV 502, battery power remaining in the UAV 502, the operating environment, regulations, and the like.

[0111]

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

[0112]

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

[0113]

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

[0114]

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

[0115]

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

[0116]

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

[0117]

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

[0118]

[0134] In operation 702, the NCD 701 may generate an anonymity token associated with a digital certificate of the UAV. In communication 704, the NCD 701 may provide the anonymity token to the UAV for use in the operation. In some embodiments, the NCD 701 may generate multiple anonymity tokens associated with the digital certificate, where each of the multiple anonymity tokens is configured with a usability time limit.

[0119]

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

[0120]

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

[0121]

[0137] In operation 714, the NCD 701 may determine whether the digital signature is verified using the digital certificate. In some embodiments, the NCD 701 may cryptographically verify the digital signature using the digital certificate.

[0122]

[0138] Based on the determination, the NCD 701 may send a response to the first BS 105a in communication 716, and the first BS 105a may send a response to the first receiver 604 in communication 718. In some embodiments, in response to determining that the digital signature is verified (as true) using the digital certificate, the response in communication 716 and the response in communication 718 may indicate that the UAV message is authenticated.

[0123]

[0139] 7B is a sequence diagram of an example of a process 750 for managing UAV identities according to some embodiments. Referring to FIG. 1-7B, the process 750 may include a UAV 602, a first receiver 604, a second receiver 606, a first BS 105a, a second BS 105b, a core network 430, a UFMS 422, a USS 420, and an NCD 701.

[0124]

[0140] In communication 752, the first BS 105a may receive an assertion from the UAV 602 that the UAV is entitled to perform operations anonymously. In some embodiments, the assertion may include an anonymity token for the UAV. In some embodiments, the assertion may include a digital certificate for the UAV. The first BS 105a may send a request to authenticate the UAV to the NCD 701 in communication 754, where the request includes the assertion for the UAV.

[0125]

[0141] At operation 756, the NCD 701 may determine, based on the assertion, whether the UAV 602 is entitled to perform the operation anonymously. In some embodiments, the NCD 701 may determine whether the UAV 602 is associated with an entitlement to operate anonymously. In some embodiments, information indicative of such entitlement may be stored in a data structure accessible by the NCD 701 and / or in a memory device.

[0126]

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

[0127]

[0143] In operation 760, in response to determining that the UAV is authenticated, the first BS 105a may broadcast information about the UAV configured without the identity information of the UAV in response to determining that the UAV is eligible to perform the operation anonymously. The first BS 105a may send a broadcast in communication 762a, 762b, which may be received by the first receiver 604 and / or the second receiver 606.

[0128]

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

[0129]

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

[0130]

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

[0131]

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

[0132]

[0100] Figure 8 is a process flow diagram illustrating a method 800 that may be implemented by a processor of a network computing device for managing UAV identities, according to some embodiments. With reference to Figures 1-8, the operations of method 800 may be implemented by a processor of a network computing device.

[0133]

[0148] In block 802, the processor may generate an anonymity token associated with the digital certificate of the UAV. In some embodiments, the anonymity token may include a cryptographically verifiable indication that the anonymity token is associated with the digital certificate of the UAV. In some embodiments, the anonymity token may include or point to an indication that the UAV (and / or UAV operator) is entitled to perform operations anonymously. In some embodiments, each anonymity token may include (or may be) a hash of the digital certificate. In some embodiments, each anonymity token may include a hash of the digital certificate concatenated with a secret value, which may be stored by or accessible to the network computing device. A means for performing the operations of block 802 may include a processor 1301 (FIG. 13).

[0134]

[0149] In some embodiments, the anonymity token may be configured with a usability time limit. For example, the anonymity token may be configured with a validity period or another time limit on its usability that limits the usefulness of the anonymity token to a specified time range or duration, outside of which the UAV will not be able to use the anonymity token to perform operations anonymously. In other words, if the UAV transmits using the anonymity token before or after the token's time limit, the UAV will not be authenticated by the base station or NCD 701.

[0135]

[0150] In some embodiments, the anonymity token may be configured with a usability geographical restriction. For example, the anonymity token may be configured with a geofence, coordinates, or another geographical restriction on its usability that limits the utility of the anonymity token to a specified location, area, or physical region, such as may correspond to a legal jurisdiction, a theater of operation, a specified delivery route or path of travel, etc., outside of which the UAV will not be able to use the anonymity token to perform operations anonymously.

[0136]

[0151] In block 804, the processor may provide an anonymity token to the UAV for use in the operation. In some embodiments, providing the anonymity token to the UAV may enable the UAV to use the anonymity token to perform the operation anonymously. For example, the UAV may associate the anonymity token with a transmission. In some embodiments, the UAV may digitally sign the transmission using a private key associated with the anonymity token. In some embodiments, the anonymity token may be a cryptographic hash of a public key certificate with which it is associated. In some embodiments, the associated public key certificate may include a pseudonym to disguise the identity of the UAV or its operator. A means for performing the operations of block 802 may include a processor 1301, a network access port(s) 1304, and an antenna(s) 1307 (FIG. 13).

[0137]

[0152] In block 806, the processor may receive a request to authenticate the UAV message. The request may include an anonymity 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, from another UAV, from a receiving device, such as a ground station, a smartphone, or other wireless device. Means for performing the operations of block 806 may include a processor 1301, a network access port(s) 1304, and an antenna(s) 1307 (FIG. 13).

[0138]

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

[0139]

[0154] In block 810, the processor may determine whether the digital signature is verified (as true) using the digital certificate. In some embodiments, the processor may use the digital certificate to cryptographically verify the digital signature. In some embodiments, the processor may use a public key associated with the digital certificate to authenticate the digital signature (and / or to authenticate the digitally signed UAV message). A means for performing the operations of block 810 may include a processor 1301 (FIG. 13).

[0140]

[0155] In block 812, the processor may, in response to determining that the digital signature is verified (as true) using the digital certificate, send an indication that the UAV message is authenticated responsive to (i.e., in response to) the request. For example, the processor may send the indication to the requesting device. Means for performing the operations of block 812 may include a processor 1301, a network access port(s) 1304, and an antenna(s) 1307 (FIG. 13).

[0141]

[0156] 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 identities, according to various embodiments. With reference to FIGS. 1-9, operations 900 may be performed by a processor of a network computing device. As discussed above, a UAV may be configured with multiple limited-use anonymity tokens to improve anonymity or to further reduce traceability of the UAV.

[0142]

[0157] In block 902, the processor may generate a plurality of anonymity tokens associated with a digital certificate, where each of the plurality of anonymity tokens is configured with a usability time limit. For example, each of the plurality of anonymity tokens may be usable for a specified period or duration, including one-time-only use. In some embodiments, generating the plurality of anonymity tokens associated with a digital certificate may include generating the plurality of anonymity tokens using a keyed hash tree. A means for performing the operations of block 902 may include a processor 1301 (FIG. 13).

[0143]

[0158] In block 904, the processor may provide an anonymity token to the UAV for use in the operation, including providing a plurality of anonymity tokens to the UAV for use in the operation, where the use of each anonymity token is limited by a respective usability time limit. Means for performing the operations of block 904 may include a processor 1301, a network access port(s) 1304, and an antenna(s) 1307 (FIG. 13).

[0144]

[0159] The processor may perform the operations of block 806 (FIG. 8) of method 800 as described.

[0145]

[0160] 10 is a process flow diagram illustrating a method 1000 for managing UAV identities according to various embodiments. Referring to FIGS. 1-10, the method 1000 may be implemented by a processor of a base station.

[0146]

[0161] In block 1002, the processor may receive an assertion from the UAV that the UAV is entitled to perform the operation anonymously. In some embodiments, the assertion may include a digital certificate of the UAV. In some embodiments, the assertion may include an anonymity token. In some embodiments, the anonymity token may include or be associated with a data structure, such as a digital certificate attribute, a pointer, or a location identifier, that may enable identification or location (e.g., by a network computing device) of information indicating that the UAV is entitled to perform the operation anonymously. In some embodiments, the digital certificate may include information indicating the entitlement of the UAV to perform the operation anonymously. In some embodiments, the anonymity token may include a cryptographically verifiable indication that the anonymity token is associated with the 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).

[0147]

[0162] In block 1004, the processor may send a request to the network computing device to authenticate the UAV. In such an embodiment, the request may include an 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).

[0148]

[0163] In block 1006, the processor may receive a response from the network computing device indicating whether the UAV is eligible to perform the operation anonymously. The means for performing the operation of block 1006 may include the processor 312, the modem 320, the transceiver 302, and the RF front end 388 (FIG. 3).

[0149]

[0164] In block 1008, the processor may determine whether the UAV is eligible to perform the operation anonymously based on the response received from the network computing device. The means for performing the operation of block 1008 may include the processor 312 (FIG. 3).

[0150]

[0165] In block 1010, the processor may broadcast information about the UAV without identity information of the UAV in response to determining that the UAV is eligible to perform the operation anonymously. Means for performing the operation of block 1010 may include the processor 312, the modem 320, the transceiver 302, and the RF front end 388 (FIG. 3).

[0151]

[0166] 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 identities, according to various embodiments. Referring to FIGS. 1-11, operations 1100 may be performed by a processor of a base station.

[0152]

[0167] Following performance of the operations of block 1010 (FIG. 10) of the described method 1000, the processor may receive a request for the 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).

[0153]

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

[0154]

[0169] 12 is a process flow diagram illustrating operations 1200 that may be performed as part of a method 1000 for managing UAV identities, according to various embodiments. With reference to FIGS. 1-12, operations 1200 may be performed by a processor of a base station.

[0155]

[0170] Following performance of the operations of block 1010 (FIG. 10) of the described method 1000, the processor may receive a request to authenticate the UAV message in block 1202, where the request includes an assertion and a digital signature associated with the UAV message. In some embodiments, the digital signature structure may include message data signed with the 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).

[0156]

[0171] In block 1204, the processor may send a request to the network computing device to authenticate the UAV message, where 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).

[0157]

[0172] 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).

[0158]

[0173] 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).

[0159]

[0174] FIG. 13 is a component block diagram of a network computing device 1300 suitable for use with various embodiments. Such a network computing device (e.g., NCD 701) may include at least the components shown in FIG. 13. With reference to FIGS. 1-13, the network computing device 1300 may typically include a processor 1301 coupled to a volatile memory 1302 and a large capacity non-volatile memory such as a disk drive 1308. The 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 the 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 sending and receiving electromagnetic radiation that may be connected to a wireless communication link. The network computing device 1300 may include additional access ports, such as USB, Firewire, Thunderbolt, etc., for coupling to peripherals, external memory, or other devices.

[0160]

[0175] The processor of the network computing device 1300 may be any programmable microprocessor, microcomputer, or one or more multiple processor chips that may be configured by software instructions (applications) to perform various functions, including those of some implementations described below. In some wireless devices, multiple processors may be provided, such as one processor in a SOC (e.g., 204) dedicated to wireless communication functions, one processor in a SOC (e.g., 202) dedicated to running other applications, etc. Software applications may be stored in memory 1302 before they are accessed and loaded into the processor. The processor may include sufficient internal memory to store application software instructions.

[0161]

[0176] Example implementations are described in the following paragraphs. Although some of the following implementation examples are described with respect to example methods, further example implementations may include the example methods described in the following paragraphs implemented by a network computing device or base station including a processor configured with processor-executable instructions for performing operations of the methods of the following implementation examples, the example methods described in the following paragraphs implemented by a network computing device or base station including means for performing the functions of the example methods, and the example methods described in the following paragraphs implemented as a non-transitory processor-readable storage medium having stored thereon processor-executable instructions configured to cause a processor of the network computing device or base station to perform operations of the example methods.

[0162]

[0177] Example 1. A method implemented by a processor of a network computing device for managing unmanned aerial vehicle (UAV) identities, the method including: generating an anonymity token associated with a digital certificate of the UAV; providing the anonymity token to the UAV for use in operation; receiving a request to authenticate a UAV message, wherein the request identifies a digital certificate using the anonymity token included in the request, the anonymity token including an anonymity token and a digital signature associated with the UAV message; determining whether the digital signature verifies as true using the digital certificate; and in response to determining that the digital signature verifies as true using the digital certificate, sending an indication that the UAV message has been authenticated in response to the request.

[0163]

[0178] Example 2. The method of example 1, wherein the anonymity token includes a cryptographically verifiable indication that the anonymity token is associated with a digital certificate.

[0164]

[0179] Example 3. The method of any of Examples 1 or 2, wherein the anonymity token includes an indication that the UAV is entitled to perform the operation anonymously.

[0165]

[0180] Example 4. The method of any of Examples 1-3, wherein the digital certificate includes an indication that the UAV is entitled to perform the operation anonymously.

[0166]

[0181] Example 5. The method of any of Examples 1-4, wherein the anonymity token is associated with a usability time limit.

[0167]

[0182] Example 6. The method of any of Examples 1-5, wherein an anonymity token is associated with a usability geographic restriction.

[0168]

[0183] Example 7. The method of any of Examples 1-6, wherein the anonymity token comprises a hash of a digital certificate.

[0169]

[0184] Example 8. The method of any of Examples 1-7, wherein the anonymity token comprises a hash of a digital certificate concatenated with a secret value.

[0170]

[0185] Example 9. The method of any of Examples 1-8, wherein generating an anonymity token associated with the digital certificate of the UAV includes generating the anonymity 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.

[0171]

[0186] Example 10. The method of any of Examples 1-9, wherein generating an anonymity token associated with a digital certificate for the UAV includes generating a plurality of anonymity tokens associated with the digital certificate, where each of the plurality of anonymity tokens is associated with a usability time limit, and providing an anonymity token to the UAV for use in operation includes providing a plurality of anonymity tokens to the UAV for use in operation, where use of each anonymity token is limited by a respective usability time limit.

[0172]

[0187] Example 11. The method of example 10, wherein generating a plurality of anonymity tokens associated with a digital certificate includes generating the plurality of anonymity tokens using a keyed hash tree.

[0173]

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

[0174]

[0189] Example 13. The method of example 12, wherein the assertion includes an anonymity token or digital certificate indicating that the UAV is entitled to perform the operation anonymously.

[0175]

[0190] Example 14. The method of example 13, wherein the anonymity token includes a cryptographically verifiable indication that the anonymity token is associated with a digital certificate of the UAV.

[0176]

[0191] Example 15. The method of example 14, wherein the digital certificate encodes information indicating that the UAV is entitled to perform the operation anonymously.

[0177]

[0192] Example 16. The method of any of Examples 12-15, wherein the assertion includes a message and an anonymity token, and wherein a digital signature is performed on the message and the anonymity token.

[0178]

[0193] Example 17. The method of any of Examples 12-16, wherein the assertion includes an attribute or a data structure pointer to information indicating that the UAV is entitled to perform the action anonymously.

[0179]

[0194] Example 18. The method of any of Examples 12-17, further comprising receiving a request for the identity of the UAV and, based on determining that the UAV is eligible to perform the operation anonymously, configuring a response message that does not include the digital certificate-based identity of the UAV.

[0180]

[0195] Example 19. The method of any of Examples 12-18, wherein the assertion includes an anonymity token that is the product of a cryptographic process and is derived in the clear from a digital certificate associated with the UAV.

[0181]

[0196] Example 20. The method of any of Examples 12-19, wherein broadcasting information about the UAV configured without identity information for the UAV includes broadcasting one or more pseudonym certificates associated with an anonymity token.

[0182]

[0197] Example 21. The method of any of Examples 12-20, further comprising receiving a request to authenticate the UAV message, where the request includes an anonymity token associated with the UAV and a digital signature associated with the UAV message, sending the request to a network computing device to authenticate the UAV message, where the request includes an anonymity token and a digital signature, receiving a response from the network computing device indicating whether the UAV message has been authenticated, where the request includes the anonymity token and the digital signature, and sending an indication that the UAV message has been authenticated in response to receiving the response from the network computing device indicating that the UAV message has been authenticated.

[0183]

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

[0184]

[0199] Terms such as "component," "module," and "system" as used in this application are intended to include computer-related entities, such as, but not limited to, hardware, firmware, a combination of hardware and software, software, or software in execution, configured to perform certain operations or functions. For example, a component may be, but is not limited to, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, or a computer. As an example, both an application running on a wireless device and the wireless device may 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 among two or more processors or cores. Furthermore, these components may execute from various non-transitory computer-readable media having various instructions or data structures stored thereon. Components may communicate via local or remote process, function or procedure calls, electronic signals, data packets, memory read / writes, and other known network, computer, processor, or process related communication methods.

[0185]

[0200] A number of different cellular and mobile communication services and standards may become available or are contemplated in the future, all of which may implement and benefit from the various embodiments. Such services and standards include, for example, 3rd Generation Partnership Project (3GPP), Long Term Evolution (LTE) systems, third generation wireless mobile communication technologies (3G), fourth generation wireless mobile communication technologies (4G), fifth generation wireless mobile communication technologies (5G) as well as later generation 3GPP technologies, Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), 3GSM, General Packet Radio Service (GPRS), and Code Division Multiple Access (CDMA) systems (e.g., cdmaOne, CDMA1020®), Enhanced Data Rates for GSM Evolution (EDGE), Advanced Mobile Phone System (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 Access I and II (WPA, WPA2), and Integrated Digital Enhanced Network (iDEN). Each of these technologies involves, for example, the transmission and reception of voice, data, signaling, and / or content messages. Any reference to terminology and / or technical details relating to a particular telecommunications standard or technology is for illustrative purposes only and is not intended to limit the scope of the claims to a particular communication system or technology unless expressly stated in the claim language.

[0186]

[0201] The various embodiments shown and described are provided merely as examples to illustrate various features of the claims. However, features shown and described with respect to any given embodiment are not necessarily limited to the associated embodiment and may be used or combined with other embodiments shown and described. Furthermore, the claims are not intended to be limited by any one exemplary embodiment. For example, one or more of the methods and operations 800, 900, 1000, and 1100 may be replaced by or combined with one or more operations of the methods and operations 800, 900, 1000, and 1100.

[0187]

[0202] The above method descriptions and process flow diagrams are provided only 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 one of ordinary skill in the art, the order of operations in the above embodiments may be performed in any order. Words such as "then," "then," and "next" do not limit the order of operations, but rather these words are used to guide the reader through the method descriptions. Additionally, references to claim elements in the singular using, for example, the articles "a," "an," or "the" should not be construed as limiting the element to the singular.

[0188]

[0203] The various exemplary logic blocks, modules, components, circuits, and algorithmic operations described with respect to the embodiments disclosed herein may be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability of hardware and software, the various exemplary 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 on the particular application and design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in various ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the claims.

[0189]

[0204] The hardware used to implement the various example logic, logic blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed using general purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs) or other programmable logic devices, 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 alternatively, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of receiver smart objects, e.g., a combination of a DSP and a microprocessor, multiple 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 that is specific to a given function.

[0190]

[0205] In one or more embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or codes 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 storage medium or a non-transitory processor-readable storage medium. A non-transitory computer-readable storage medium or a non-transitory 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 a non-transitory computer-readable storage medium or a non-transitory processor-readable storage medium may include RAM, ROM, EEPROM, FLASH memory, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage smart objects, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Disk and disc as used herein include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc, where disks typically reproduce data magnetically and discs reproduce data optically with a laser. Combinations of the above are also included within the scope of non-transitory computer-readable media and non-transitory processor-readable media. Furthermore, operations of a method or algorithm may reside as one or any combination or set of code and / or instructions on a non-transitory processor-readable storage medium and / or a non-transitory computer-readable storage medium, which may be incorporated into a computer program product.

[0191]

[0206] The preceding description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the claims. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general 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. 1. A method for managing unmanned aerial vehicle (UAV) identities, the method comprising: receiving an assertion from the UAV that the UAV is entitled 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 is eligible to perform an operation anonymously; determining whether the UAV is eligible to perform an operation anonymously based on the response received from the networked computing device; In response to determining that the UAV is eligible to perform an operation anonymously, broadcasting information about the UAV configured without identity information of the UAV; Equipped with receiving a request for an identity of the UAV; Based on determining that the UAV is eligible to perform the operation anonymously, constructing a response message that does not include a digital certificate-based identity of the UAV; The method further comprises:

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

3. The method of claim 2 , wherein the anonymity token includes a cryptographically verifiable indication that the anonymity 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 is entitled to perform operations anonymously.

5. The assertion is: a message and an anonymity token, where the digital signature is performed on the message and the anonymity token, or an attribute or data structure pointer to information indicating that the UAV is eligible to perform operations anonymously; The method of claim 1 , comprising one of:

6. The method of claim 1 , wherein the assertion comprises an anonymity token that is the product of a cryptographic process and is derived explicitly from a digital certificate associated with the UAV.

7. 2. The method of claim 1, wherein in response to determining that the UAV is eligible to perform operations anonymously, broadcasting information about the UAV configured without identity information of the UAV comprises broadcasting one or more pseudonym certificates associated with the anonymity token.

8. receiving a request to authenticate a UAV message, wherein the request includes an anonymity token associated with the UAV and a digital signature associated with the UAV message; sending a request to a network computing device to authenticate the UAV message, wherein the request includes the anonymity token and the digital signature; receiving a response from the network computing device indicating whether the UAV message was authenticated; in response to receiving a response from the network computing device indicating that the UAV message is authenticated, sending an indication that the UAV message is authenticated; The method of claim 1 further comprising:

9. The digital signature structure comprises UAV message data; The digital signature is generated on the UAV message using a private key of the UAV. The method according to claim 8.

10. means for receiving an assertion from an unmanned aerial vehicle (UAV) that the UAV is entitled 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 is eligible to perform an operation anonymously; means for determining whether the UAV is eligible to perform an operation anonymously based on the response received from the networked computing device; means for broadcasting information about the UAV configured without identity information of the UAV in response to determining that the UAV is eligible to perform an operation anonymously; Equipped with means for receiving a request for an identity of the UAV; 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 eligible to perform an operation anonymously; The base station further comprises:

11. The assertion includes an anonymity token or digital certificate indicating that the UAV is entitled to perform operations anonymously; the anonymity token includes a cryptographically verifiable indication that the anonymity token is associated with a digital certificate of the UAV; The base station of claim 10 , wherein the digital certificate encodes information indicating that the UAV is entitled to perform operations anonymously.

12. The assertion is a message and an anonymity token, where the digital signature is performed on the message and the anonymity token, or an attribute or data structure pointer to information indicating that the UAV is eligible to perform operations anonymously; The base station of claim 10, comprising one of:

13. The base station of claim 10 , wherein the assertion comprises an anonymity token that is the product of a cryptographic process and is derived explicitly from a digital certificate associated with the UAV.

14. The base station of claim 10, wherein in response to determining that the UAV is eligible to perform operations anonymously, means for broadcasting information about the UAV configured without identity information of the UAV comprises means for broadcasting one or more pseudonym certificates associated with the anonymity token.

15. means for receiving a request to authenticate a UAV message, wherein the request includes an anonymity token associated with the UAV and a digital signature associated with the UAV message; means for sending a request to a network computing device to authenticate the UAV message, wherein the request includes the anonymity token and the digital signature; means for receiving a response from the network computing device indicating whether the UAV message was authenticated; means for sending an indication that the UAV message has been authenticated in response to receiving a response from the network computing device indicating that the UAV message has been authenticated; Further equipped with The digital signature structure comprises UAV message data; The base station of claim 10 , wherein the digital signature is generated on the UAV message using a private key of the UAV.

Images