Management of unmanned aerial vehicle identification information

Abstract

In an embodiment of a system and method for managing unmanned aerial vehicle (UAV) identity information, a processor of a networked computing device may generate an anonymous token associated with a digital certificate of the UAV, provide the anonymous token to the UAV for use in operation, receive a request to authenticate the UAV, the request including the anonymous token, determine whether the anonymous token included in the request is associated with the digital certificate, and, in response to a determination that the anonymous token included in the request is associated with the digital certificate, send an indication that the UAV is authenticated in response to the request.

Description

[Technical field]

[0001] Related Applications 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. Non-Provisional Application No. 17 / 482,517, 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. [Background technology]

[0002] Wireless communication networks are widely deployed to provide various types of communication content, such as voice, video, packet data, messaging, broadcasts, etc. 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.

[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, fifth generation (5G) wireless communication technologies (sometimes referred to as new radio (NR)) are envisioned to extend and support diverse usage scenarios and applications for the current mobile network generation. In one aspect, 5G communication technologies can include enhanced mobile broadband that addresses human-centric use cases for accessing multimedia content, services, and data, ultra-reliable-low latency communications (URLLC) with several specifications for latency and reliability, and massive machine-type communications that can enable a very large number of connected devices and the transmission of information that is not affected by a relatively small amount of delay. However, as the demand for mobile broadband access continues to increase, further improvements beyond NR communication technologies may be desired.

[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 cryptographic key that can be cryptographically verified (e.g., using its public key certificate).

[0005] A typical digital certificate provided by a UAV may include identifiers for the UAV and its operator, which may allow the UAV to be tracked and correlated with known operators or entities. Some UAV operators, due to the nature of their identity, role, or mission, may require operator privacy, but must still sign and broadcast authenticatable messages for safety and other operational purposes. Summary of the Invention [Means for solving the problem]

[0006] Various aspects include systems and methods implemented by a processor of a network computing device to manage UAV identity information. Various aspects may include generating an anonymous token associated with a digital certificate of the UAV, providing the anonymous token to the UAV for use in operations, receiving a request to authenticate a UAV message, the request including the anonymous token and a digital signature associated with the UAV message, identifying the digital certificate using the anonymous token included in the request, determining whether the digital signature is verified using the digital certificate, and sending an indication that the UAV message is authenticated in response to the request in response to a determination that the digital signature is verified using the digital certificate.

[0007] In some aspects, the anonymous token may include a cryptographically verifiable indication that the anonymous token is associated with a digital certificate. In some aspects, the anonymous token may include an indication that the UAV is entitled to perform an operation anonymously. In some aspects, the digital certificate may include an indication that the UAV is entitled to perform an operation anonymously. In some aspects, the anonymous token may be associated with a usability time restriction. In some aspects, the anonymous token may be associated with a usability geographic restriction. In some aspects, the anonymous token may include a hash of the digital certificate. In some aspects, the anonymous token may include a hash of the digital certificate concatenated with a secret value.

[0008] In some aspects, generating an anonymous token associated with the digital certificate of the UAV may include generating the anonymous token from one of a hash of the digital certificate, a keyed hash of the digital certificate, or a keyed hash tree of the digital certificate. In some aspects, generating an anonymous token associated with the digital certificate of the UAV may include generating a plurality of anonymous tokens associated with the digital certificate, each of the plurality of anonymous tokens being associated with a usability time limit, and providing the anonymous token to the UAV for use in the operation may include providing the plurality of anonymous tokens to the UAV for use in the operation, the use of each anonymous token being limited by a respective usability time limit. In some aspects, generating a plurality of anonymous tokens associated with the digital certificate may include generating the plurality of anonymous tokens using a keyed hash tree.

[0009] Further aspects include a network computing device having a processing system configured to perform one or more operations of any of the methods summarized above. Further aspects include a processing device for use in a network computing device configured with processor-executable instructions for performing operations of any of the methods summarized above. Further aspects include a non-transitory processor-readable storage medium having stored thereon processor-executable instructions configured to cause a processor of a network computing device to perform operations of any of the methods summarized above. Further aspects include a network computing device having means for performing the functions of any of the methods summarized above.

[0010] The disclosed aspects are now described with reference to the accompanying drawings, in which like designations indicate like elements, which are provided to illustrate but not to limit the disclosed aspects. [Brief description of the drawings]

[0011] [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] FIG. 2 is a schematic diagram illustrating an example of a base station. [Figure 4] FIG. 1 is a schematic diagram of an example of an environment for managing UAVs. [Diagram 5] FIG. 11 is a sequence diagram of an example process for delivering a certificate by a UAV. [Figure 6A] FIG. 1 is a sequence diagram of an example of a UAV initialization process to a network. [Figure 6B] FIG. 11 is a sequence diagram of a first example of a process for distributing a certificate by a base station. [Figure 6C] FIG. 11 is a sequence diagram of a second example of a process for distributing a certificate by a base station. [Figure 6D]FIG. 11 is a sequence diagram of an example of a process for obtaining a certificate by a receiver. [Figure 6E] FIG. 11 is a sequence diagram of an example process for broadcasting a certificate by a base station. [Figure 7A] FIG. 11 is a sequence diagram of an example process for managing UAV identification information. [Figure 7B] FIG. 11 is a sequence diagram of an example process for managing UAV identification information. [Figure 8] FIG. 1 is a process flow diagram illustrating a method that may be implemented by a processor of a networked computing device for managing UAV identification information, according to various embodiments. [Figure 9] FIG. 1 is a process flow diagram illustrating operations that may be performed by a processor of a networked computing device as part of a method for managing UAV identification information, according to various embodiments. [Figure 10] FIG. 1 is a process flow diagram illustrating a method that may be implemented by a processor of a base station for managing UAV identification information, according to various embodiments. [Figure 11] 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 identification information according to various embodiments. [Figure 12] 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 identification information according to various embodiments. [Figure 13] FIG. 1 is a component block diagram of a networked computing device suitable for use with the various embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] The detailed description, set forth below in connection with 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 includes specific details for the purpose of providing a thorough understanding of the various concepts. However, it will be apparent to one skilled in the art that these concepts may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form to avoid obscuring such concepts.

[0013] Several aspects of a telecommunications system are now presented with reference 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.

[0014] 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 shall be construed broadly 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, whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise.

[0015] 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 a computer-readable medium. A computer-readable medium includes a computer storage medium. A storage medium may be any available medium that can be accessed by a computer. By way of example and not limitation, such a computer-readable medium may comprise a random access memory (RAM), a read-only memory (ROM), an electrically erasable programmable ROM (EEPROM), an optical disk storage, a magnetic disk storage, other magnetic storage devices, a combination 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.

[0016] In one implementation, the UAV may split the certificate into segments. The UAV may embed each segment of the certificate into a frame. The frames containing the segments of the split may be transmitted sequentially 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 that will be used to authenticate the broadcast remote identification.

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

[0018] Various embodiments are described in detail with reference to the accompanying drawings. Whenever possible, the same reference numbers are 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 do not limit the scope of the claims.

[0019] Various embodiments include systems and methods implemented by network computing devices and base stations to manage the identity of UAVs. Various embodiments may be used to enable UAVs and base stations to perform operations without transmitting any identifying 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.

[0020] 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 capabilities. Examples of such vehicles include, but are not limited to, aircraft such as a UAV, ground vehicles (e.g., autonomous or semi-autonomous vehicles, cleaning robots, etc.), surface vehicles (i.e., vehicles configured for operation on or underwater), 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 steer and / or navigate the vehicle without remote operating instructions (i.e., autonomously) from a human operator or the like (e.g., via a remote computing device). 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 from a human operator or the like (e.g., via a remote computing device) and autonomously steer and / or navigate the vehicle in accordance with the received information or instructions. In some implementations, a vehicle may be an aircraft (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 lift 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. A vehicle may include various components and / or payloads that may perform various functions. The term "components" when used with respect to a vehicle includes vehicle components and / or vehicle payloads.

[0021] 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 include circuits for digital, analog, mixed signal, and radio frequency functions. A single SOC may also include any number of general purpose or special purpose processors (digital signal processors, modem processors, video processors, etc.), memory blocks (ROM, RAM, flash, etc.), and resources (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.

[0022] The term "system in package" (SIP) may be used herein to refer to a single module or package that contains multiple resources, computing units, cores, or processors on two or more IC chips, substrates, or SOCs. For example, 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 unifying 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 within a single wireless device. The proximity of the SOCs facilitates high-speed communication and sharing of memory and resources.

[0023] As used herein, the terms "network," "system," "wireless network," "cellular network," and "wireless communications network" may interchangeably refer to some or all of a carrier's wireless network 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. In general, any number of wireless networks may be deployed in a given geographic area. Each wireless network may support at least one radio access technology, which may operate at one or more frequencies or frequency ranges. 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 standard, the IS-95 standard, and / or the IS-856 standard), and the like. In another example, a TDMA network may implement GSM Enhanced Data rates for GSM Evolution (EDGE). In another example, an 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 be used interchangeably herein to refer to wireless networks. However, such references are made by way of example only and are not intended to 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, these systems are mentioned merely as examples and future generation systems (e.g., sixth generation (6G) or higher systems) may be substituted in various examples.

[0024] 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 actions, observations of other traffic, and observations of the environment. Require such communications to be digitally signed, allowing authentication of the source of such information. Typical UAV digital certificates are static and may include identifiers of the UAV and its operator, which may allow tracking and / or correlation of the UAV with known operators or entities. As noted above, some UAV operators may desire the ability to operate UAVs anonymously due to the nature of their identity, role, or mission, but still sign and transmit authenticable messages for safety and other operational purposes.

[0025] Various embodiments include a method, and a network computing device and a base station configured to implement the method for managing UAV identification information. In various embodiments, a UAV may be configured with an entitlement or permission to perform an operation without transmitting any 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 or associated with the UAV. As used herein, performing an operation without transmitting such identifying information is referred to as performing an operation "anonymously." In various embodiments, when a UAV is operating anonymously, the UAV may be configured to send a message (e.g., a digitally signed message) without such identifying information (such as a digital signature). Furthermore, a device receiving such a message (e.g., a digitally signed message) from the UAV is not provisioned or provided with information (e.g., a digital signature) that identifies the UAV. Furthermore, an element of a UTM, such as a base station, may configure a message with information about the UAV without identifying information of the UAV, such as a 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 to conduct traffic observations, surveillance operations, etc. As another example, a commercial package delivery operator may obtain permission to operate some UAVs anonymously to avoid observation of covert business operations, to clandestinely deliver packages (such as confidential legal, medical, or business documents, drug prescriptions, medical equipment or devices, medical samples for testing, organs for transplants, etc.), etc.

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

[0027] The UAV may be configured with an anonymous token, and the UAV may associate the anonymous token with a transmission (referred to herein as a "UAV message"). The anonymous token may enable a receiver to request authentication of a transmission and / or a transmitting UAV without receiving identification information 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 anonymous token may include a cryptographically verifiable indication that the anonymous token is associated with the UAV's digital certificate. In some embodiments, the anonymous token may include an indication that the UAV (and / or UAV operator) is entitled to perform operations anonymously.

[0028] 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 anonymous token and a digital signature associated with the UAV message. In some embodiments, the request may include message information (sometimes referred to as "signed data") signed with the digital signature. The network computing device may identify a digital certificate using the anonymous token included in the request. For example, the network computing device may identify a digital certificate associated with the anonymous token. In some embodiments, an association of the digital certificate with one or more anonymous tokens may be stored in a memory or memory device accessible by the network computing device.

[0029] 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 a digital certificate to perform the digital signature verification. In some embodiments, the network computing device may use a 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 is authenticated in response to the request in response to a determination that the digital signature is verified using a digital certificate.

[0030] In some embodiments, the anonymous token may include a cryptographically verifiable indication that the anonymous token is associated with a digital signature. In some embodiments, the anonymous token may include a hash of a digital certificate. In some embodiments, the anonymous token may include a portion of the hash of a digital certificate. In some embodiments, the anonymous 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 anonymous token may be configured to include, without limitation, various encoded information and / or associations to other data.

[0031] In some embodiments, the anonymous token may be associated with a usability time limit. For example, the anonymous token may be associated with an expiration date or another time limit on its usability that limits the usefulness of the anonymous token to a specified time range or duration, otherwise the UAV cannot use the anonymous token to perform operations anonymously. In some embodiments, the anonymous token may include or be associated with an encoding of the usability time limit. In some embodiments, the network computing device may determine the association of the anonymous token and the usability time limit by referring to information stored in a data structure, such as, for example, a database.

[0032] In some embodiments, the anonymous token may be associated with a usability geographic restriction. For example, the anonymous token may be associated with a geofence, coordinates, or another geographic restriction on its usability that limits the utility of the anonymous token to a specified location, area, or physical region, such as may correspond to a jurisdiction, a theater of war, a specified delivery route or travel path, etc., and the UAV cannot otherwise use the anonymous token to perform operations anonymously. In some embodiments, the anonymous token may include or be associated with an encoding of the usability geographic restriction. In some embodiments, the network computing device may determine the association for the anonymous token and the usability geographic restriction, for example, by reference to information stored in a database or other suitable data structure.

[0033] In some embodiments, to enhance the UAV's ability to perform operations anonymously, the network computing device may generate multiple anonymous tokens associated with the UAV's digital certificate, and the multiple anonymous tokens may be configured (e.g., uploaded and stored) in the UAV's memory. In some embodiments, the multiple anonymous tokens may be cryptographically associated with the digital certificate. For example, each anonymous token may be associated with a single certificate or with a unique certificate. In such embodiments, the association of each anonymous token with the digital certificate may be maintained by the network computing device. In some embodiments, the network computing device may generate the multiple anonymous tokens using a hash of the digital certificate. In some embodiments, the network computing device may generate the multiple anonymous tokens using a keyed hash of the digital certificate. In some embodiments, the network computing device may generate the multiple anonymous 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 generate the multiple anonymous tokens. In some embodiments, the UAV may cycle through its multiple anonymous tokens for inclusion in one or more transmissions. In some embodiments, the UAV may randomly select an anonymous token from among the multiple anonymous tokens for use in a transmission. In some embodiments, each of the multiple anonymous tokens may be configured with a usability time limit. In some embodiments, each of the multiple anonymous tokens may be limited to use in a single transmission (i.e., one use). In this manner, the UAV may transmit messages that are both authenticatable and anonymous with respect to the identity of the UAV and / or its operator.

[0034] In various embodiments, a base station, access point, or other device (collectively referred to herein for brevity as a “base station”) that provides a wireless communications link and supports access to a communications network may be configured to perform a method for managing UAV identification information. In some embodiments, the base station may be configured to receive an assertion from the UAV that the UAV is entitled to perform an operation anonymously. In some embodiments, the assertion may include an anonymous token or digital certificate, which may include an indication (e.g., information including the assertion) that the UAV is entitled to perform an operation anonymously. In some embodiments, the assertion may include a message and an anonymous token. In some embodiments, a digital signature is performed on the message and the anonymous token. In some embodiments, the assertion may include an attribute or a data structure pointer to information indicating that the UAV is entitled to perform an operation anonymously. The data structure pointer may be a record locator or other suitable use pointing to the location of information in a data structure, such as a database. In some embodiments, such a database may be managed or accessible by the network computing device. In some embodiments, the anonymous 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 anonymous token to be unambiguously associated with a digital signature associated with the UAV. In some embodiments, the anonymous token may include a cryptographically verifiable indication that the anonymous token is associated with the digital certificate of the UAV.

[0035] In some embodiments, the base station may send a request to authenticate the UAV to the network computing device, the request including an assertion and a digital signature made on the assertion. In some embodiments, the digital signature may include the 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 UAV, configured without the identity of the UAV. In some embodiments, the broadcast may additionally include one or more pseudonymous certificates associated with an anonymous token that other UTM entities may use to authenticate the UAV broadcast without receiving information about the UAV identity.

[0036] The base station may be configured to handle a request from another device asking the base station to authenticate the UAV. Non-limiting examples of another device that may make such a request include another UAV, a ground station, a receiving device such as a smartphone, or a UAV controller device, etc. In some embodiments, the base station may receive a request to authenticate a UAV message, the request including an anonymous token associated with the UAV and a digital signature associated with the UAV that was included in the UAV message. For example, the other device may receive the UAV message from the UAV and retrieve 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) to authenticate the UAV message. In some embodiments, the digital signature may include message data signed with the digital signature.

[0037] Upon receiving such a request, the base station may send a request to the network computing device to authenticate the UAV message, the request including the anonymous 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 in turn pass on the 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.

[0038] Various embodiments may be implemented in various scenarios. For example, a law enforcement UAV may be performing reconnaissance operations in an area where other UAVs are simultaneously operating and may require the exchange of detection and collision avoidance (DAA) messages to avoid near misses or collisions with the other UAVs. In non-anonymous operations, the law enforcement UAV drone may transmit its digital certificate along with the signed DAA message or may make its digital certificate available to the message recipient via the UTM infrastructure (e.g., upon request via the base station) so that the message recipient may 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 anonymous token that may be associated with a public key certificate. Additionally, the law enforcement UAV may send a notification, command, or request to the UTM infrastructure (e.g., base station) not to broadcast the digital certificate associated with the law enforcement UAV. A receiving device needing 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 networked computing device), which may perform operations that provide confirmation or denial of the authentication of the UAV's transmission without revealing the identity of the law enforcement UAV or its operator.

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

[0040] 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 a macrocell (high-power cellular base station) and / or a small cell (low-power cellular base station). The macrocell includes a base station. The small cell includes a femtocell, a picocell, and a microcell. In one implementation, a user equipment (UE) 110 may include 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 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 a certificate, splits the certificate, and / or embeds a certificate segment into a frame. In some implementations, the BS 105 may include a communications component 322 configured to communicate with the UE 110.

[0041] 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, encryption and decryption of radio channels, 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 tracking, RAN information management (RIM), paging, positioning, and delivery of alert messages. The BSs 105 may communicate with each other directly or indirectly (e.g., through the EPC 160 or 5GC 190) via the backhaul link interfaces 134. The backhaul links 132, 134 may be wired or wireless.

[0042] The BSs 105 may wirelessly communicate with the UEs 110. Each of the BSs 105 may provide communication coverage for 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 provide service to closed groups known as closed subscriber groups (CSGs). The communication link 120 between the BSs 105 and the UEs 110 may include uplink (UL) (also referred to as reverse link) transmissions from the UEs 110 to the BSs 105, and / or downlink (DL) (also referred to as forward link) transmissions 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 use a total of Y carriers used for transmission in each direction. x A UE may use spectrum with bandwidth up to Y MHz per carrier (e.g., 5, 10, 15, 20, 100, 400 MHz, etc.) allocated in carrier aggregation of up to 100 MHz (x component carriers). The carriers may or may not be 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).

[0043] 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.

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

[0045] 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. A small cell 105' utilizing NR in the unlicensed frequency spectrum may provide enhanced coverage to and / or increase the capacity of an access network.

[0046] 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 communicate with the UE 110 and operate in the conventional sub-6 GHz spectrum, at millimeter wave (mmW) frequencies, and / or at sub-mmW frequencies. When the gNB 180 operates at mmW or sub-mmW frequencies, it may be referred to as an 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 this band may be referred to as millimeter waves. Sub-mmW can extend down to frequencies of 3 GHz with a wavelength of 100 millimeters. The very high frequency (SHF) band extends between 3 GHz and 30 GHz and is also referred to as centimeter waves. Communications using mmW / sub-mmW radio frequency bands have significant path loss and short distances. The mmW base station 180 may utilize beamforming 182 with the UE 110 to compensate for the path loss and short distances.

[0047] 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 handles 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 UE IP address allocation 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 initiate MBMS bearer services in the 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.

[0048] The 5GC 190 may include an Access and Mobility Management Function (AMF) 192, other AMFs 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. In general, 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.

[0049] 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 base station 105 provides an access point to the EPC 160 or 5GC 190 for the UE 110. Examples of the UE 110 include a mobile 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 cooking appliance, a health management 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.

[0050] 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.

[0051] 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 over a cellular network, a Wi-Fi network, or other wireless and wired networks. The certificate component 224 may retrieve the certificate, split the certificate, and / or embed the certificate segments into a frame.

[0052] In some implementations, the UE 110 may include various components, including components such as one or more processors 212, memory 216, and transceivers 202 in communication over one or more buses 244, which may operate in conjunction with a modem 220 and communication components 222 to facilitate one or more of the functions described herein related to communication 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 (concurrently or non-concurrently) over one or more radio access technologies. The one or more antennas 265 may include one or more antennas, antenna elements, and / or antenna arrays.

[0053] 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 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 212 may include any one of a modem processor, or a baseband processor, or a digital signal processor, or a transmit processor, or a receive device processor, or a transceiver processor associated with the transceiver 202, or any combination thereof. In addition, 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.

[0054] The memory 216 may also be configured to store local versions of data and / or applications 275 as used herein, or the communications component 222, the certificate component 224, and / or one or more subcomponents of the communications component 222 and / or the certificate component 224 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 communications component 222, the certificate component 224, and / or one or more of the subcomponents, and / or data associated therewith, when the UE 110 operates the at least one processor 212 to execute the communications component 222, the certificate component 224, and / or one or more of its subcomponents.

[0055] 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 to receive 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 to transmit 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.

[0056] 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.

[0057] 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 its specified gain value based on the desired gain value of a particular application.

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

[0059] 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 generate an output signal for transmission. In an aspect, each filter 296 may be coupled with a particular LNA 290 and / or PA 298. In an aspect, the RF front end 288 may use one or more switches 292 to select a transmit or receive path that uses a specified filter 296, LNA 290, and / or PA 298 based on a configuration as specified by the transceiver 202 and / or processor 212.

[0060] 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 specified 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 specified frequency and power level based on the UE configuration of the UE 110 and a communication protocol used by the modem 220.

[0061] 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.

[0062] 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.

[0063] In some implementations, the BS 105 may include various components, including components such as one or more processors 312, memory 316, and transceivers 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 communications 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.

[0064] 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 within 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 of a modem processor, or a baseband processor, or a digital signal processor, or a transmit processor, or a receive device processor, or a transceiver processor associated with the transceiver 302, or any combination thereof. 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.

[0065] The memory 316 may also be configured to store local versions of data and / or applications 375 as used herein, or the communication component 322, the determination component, and / or one or more subcomponents of the communication component 322 or the determination component 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, and / or data associated with, one or more of the communication component 322, the determination component, and / or one or more of its subcomponents 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 its subcomponents.

[0066] 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 to receive 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 to transmit 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.

[0067] Additionally, in an aspect, the BS 105 may include an RF front end 388 that may be in operative communication with one or more antennas 365 and a transceiver 302 for receiving and transmitting 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 for transmitting and receiving RF signals.

[0068] 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 its specified gain value based on the desired gain value for a particular application.

[0069] Further, for example, one or more PAs 398 may be used by the RF front end 388 to amplify the RF output signal 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 its specified gain value based on the desired gain value for a particular application.

[0070] 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 generate an output signal for transmission. In an aspect, each filter 396 may be coupled with a particular LNA 390 and / or PA 398. In an aspect, the RF front end 388 may use one or more switches 392 to select a transmit or receive path that uses a specified filter 396, LNA 390, and / or PA 398 based on a configuration as specified by the transceiver 302 and / or processor 312.

[0071] 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 an 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 an 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 base station 105 and the communication protocol used by the modem 320.

[0072] 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.

[0073] 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 (TPAE, police detector, civil / government detector, regulatory agency, etc.). The second receiver 410b and the third receiver 410c may be mobile devices, such as UAVs. Other types of receivers are contemplated. 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.

[0074] 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 of FIG. 1. The environment 400 may include a UAV service provider (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 within the core network 430. In other optional implementations, the UFMS 422 may be implemented in a separate and independent server 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., a network publishing function of the 5GC 190, a service capabilities publishing function of the EPC 160, a 3GPP® Rx interface, etc.).

[0075] 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, pressure 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 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).

[0076] 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.

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

[0078] 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 trust chain file indicating one or more hierarchies of certificates, each up to a root certificate or other designated authority. The mobile device 402 may split the certificate into n parts and may transmit the n parts of the certificate in n frames. For example, the mobile device 402 may split the certificate into 20 parts (n=20). The mobile device 402 may embed the 20 certificate partitions / segments into 20 frames and transmit the 20 frames sequentially 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, and so on. 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).

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

[0080] In some aspects, the mobile device 402 may indicate to the receivers 410a-c the number of parts (or frames) for the certificate. For example, the mobile device 402 may split the certificate into 50 parts and embed the 50 parts into 50 frames. The mobile device 402 may indicate 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-c may assemble the certificate after receiving the 50 parts in the 50 frames.

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

[0082] In some aspects, a frame carrying a portion of a certificate may be labeled a certificate frame.

[0083] 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 volume, regulatory requirements, the technology used for transmission, etc.

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

[0085] In some aspects, the mobile device 402 may transmit frames carrying portions of the certificate at regular periodicities. Example periodicities 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 in various ways, which are described below.

[0086] 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.

[0087] In another aspect of the disclosure, the mobile device 402 may receive the 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.

[0088] In different aspects, 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 a value (e.g., 1s, 2s, 5s, 10s, 20s, 50s, 100s, etc.) or one of a set of predefined indices (e.g., 0 to never, 1 to 5s, 2 to 10s, 3 to 20s, etc.).

[0089] 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 of transmitting frames carrying portions of the certificate, for example, from 10 s to 15 s.

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

[0091] In some implementations, the period may be adaptively based on detected environmental factors, such as RF interference from other UAV traffic, weather-related attenuation, excessive requests for certificates, etc. In some implementations, the period 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.

[0092] In one aspect of the disclosure, the receivers 410a-c may obtain the 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.

[0093] 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, such as the UAV ID of the mobile device 402, from the BRID. 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 search 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 the 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.

[0094] 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 look up 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 to the second receiver 410b (e.g., via the core network 430 and / or the first BS 105a) that includes the certificate associated with the UAV ID. The second receiver 410b may use the certificate to authenticate the BRID from the mobile device 402.

[0095] In a fourth 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 the location information (e.g., latitude, longitude, altitude, etc.) in the remote ID, the BRID, and / or the 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 an indication of the BRID certificate, a commercial mobile alarm system (CMAS) with an 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.

[0096] 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 / movement 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 in which the mobile device 402 will be. The first BS 105a may identify a coverage area associated with the geographic area in which the mobile device 402 will be, such as the second coverage area 130b of the second BS 105b. In response, the first BS 105a may identify that the second BS 105b is associated with the second coverage area 130b and 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.

[0097] 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.

[0098] Referring to FIG. 5, in some implementations, an example 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 credential bootstrapping (e.g., security certification). 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 possibly 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, by way of example, the periodicity at which portions of the certificate are transmitted. At communication 530, the UAV 502 may transmit an RRC connection reconfiguration complete message to the RAN 508, possibly responsive to completion of the reconfiguration.

[0099] In some implementations, in communication 532, the UAV 502 may broadcast a BRID, which is received by the first receiver 504. The UAV 502 may divide 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 label 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 during the bootstrapping process in step 520. Alternatively, the periodicity may be 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.

[0100] 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.

[0101] In another optional implementation, the nth frame may include an end indicator indicating that the nth frame carries the last segment of the attestation by UAV502.

[0102] In an optional implementation, the UAV 502 may assign sequence numbers to the n frames corresponding 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.

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

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

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

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

[0107] In some implementations, in communication 542, the UAV 502 may broadcast the BRID, which is received by the second receiver 506. The UAV 502 may split 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 label the m frames to indicate that they 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 the 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).

[0108] 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 on the UAV 502, the operating environment, regulations, and the like.

[0109] 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 credential bootstrapping (e.g., security certification). 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.

[0110] 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 latest 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.

[0111] 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.

[0112] 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, such as the UAV ID of the UAV 602, from the BRID. In communication 652, the second receiver 606 may transmit 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 transmit a certificate search 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 transmit a certificate search message to the USS 420 via the UFMS to request a certificate. In communication 656, the USS 420 and / or UFMS 422 may send the certificate associated with the UAV ID of the UAV 602 in a certificate delivery message to the second BS 105b. In communication 658, the second BS 105b may, after receiving the certificate delivery message, send a certificate response including the certificate to the second receiver 606 in response to the certificate request to the second receiver 606. In operation 660, the second receiver 606 may use the certificate to authenticate the BRID from the UAV 602.

[0113] 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, such as the UAV ID of the UAV 602, from the BRID. 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 UFMS 422 may send a certificate response (e.g., via the core network 430, the first BS 105a, and / or the second BS 105b) to the second receiver 606 including the 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.

[0114] 6A and 6E, in one implementation, at 630, the core network 430 may send a location subscription to the USS 420 and / or UFMS 422 to obtain an updated location of the UAV 602. At communication 632, the USS 420 and / or UFMS 422 may send a location report including the latest known location of the UAV 602 (based on the received remote ID, NRID, or BRID). At communication 634, the USS 420 and / or 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, 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 the 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 a certificate in the first coverage area 130a (received from the core network 430 in 638). 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.

[0115] 7A is a sequence diagram of an example of a process 700 for managing UAV identification information, 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 within the core network 430.

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

[0117] 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 that includes the anonymity token. In some embodiments, the first receiver 604 may send a request 708 to the first BS 105a, which may send the request in communication 710 to the NCD 701.

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

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

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

[0121] 7B is a sequence diagram of an example of a process 750 for managing UAV identification information 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.

[0122] In communication 752, the first BS 105a may receive an assertion from the UAV 602 that the UAV is entitled to perform the operation anonymously. In some embodiments, the assertion may include an anonymous 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, the request including the assertion for the UAV.

[0123] In operation 756, the NCD 701 may determine whether the UAV 602 is entitled to perform the operation anonymously based on the assertion. 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 and / or in a memory device accessible by the NCD 701.

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

[0125] In operation 760, in response to determining that the UAV is authenticated, the first BS 105a may broadcast information about the UAV, configured without identification 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 a communication 762a, 762b that may be received by the first receiver 604 and / or the second receiver 606.

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

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

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

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

[0130] 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 identification information, according to various embodiments. With reference to FIGS. 1-8, the operations of method 800 may be implemented by a processor of a network computing device.

[0131] In block 802, the processor may generate an anonymous token that is associated with the digital certificate of the UAV. In some embodiments, the anonymous token may include a cryptographically verifiable indication that the anonymous token is associated with the digital certificate of the UAV. In some embodiments, the anonymous token may include or point to an indication that the UAV (and / or UAV operator) is entitled to perform an operation anonymously. In some embodiments, each anonymous token may include (or may be) a hash of the digital certificate. In some embodiments, each anonymous token may include a hash of the digital certificate concatenated with a 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).

[0132] In some embodiments, the anonymous token may be configured with a usability time limit. For example, the anonymous token may be configured with an expiration date or another time limit on its usability that limits the usefulness of the anonymous token to a specified time range or duration, otherwise the UAV cannot use the anonymous token to perform operations anonymously. In other words, if the UAV transmits using the anonymous token before or after the time limit of the anonymous token, the UAV will not be authenticated by the base station or NCD 701.

[0133] In some embodiments, the anonymous token may be configured with usability geographical restrictions. For example, the anonymous token may be configured with a geofence, coordinates, or another geographical restriction on its usability, limiting the utility of the anonymous token to a specified location, area, or physical region, such as may correspond to a jurisdiction, a theater of war, a designated delivery or travel route, etc., where the UAV cannot otherwise use the anonymous token to perform operations anonymously.

[0134] In block 804, the processor may provide the anonymous token to the UAV for use in the operation. In some embodiments, providing the anonymous token to the UAV may enable the UAV to use the anonymous token to perform the operation anonymously. For example, the UAV may associate the anonymous token with a transmission. In some embodiments, the UAV may digitally sign the transmission using a private key associated with the anonymous token. In some embodiments, the anonymous token may be a cryptographic hash of a public key certificate with which it is associated. In some embodiments, the associated public key certificate may include a pseudonym to hide 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 1304, and an antenna 1307 (FIG. 13).

[0135] In block 806, the processor may receive a request to authenticate the UAV message. The request may include an anonymous token and a digital signature associated with the UAV message. For example, the network computing device may receive the request from a UTM infrastructure, such as a base station or other network access point, from another UAV, from a receiving device, such as a ground station, a smartphone, or other wireless device. A means for performing the operations of block 806 may include a processor 1301, a network access port 1304, and an antenna 1307 (FIG. 13).

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

[0137] In block 810, the processor may determine whether the digital signature is verified using a 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).

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

[0139] 9 is a process flow diagram illustrating operations 900 that may be performed by a processor of a networked computing device as part of a method 800 for managing UAV identity information, according to various embodiments. With reference to FIGS. 1-9, operations 900 may be performed by a processor of a networked computing device. As discussed above, a UAV may be configured with multiple limited-use anonymous tokens to increase anonymity or to further reduce the trackability of the UAV.

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

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

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

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

[0144] 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 anonymous token of the UAV. In some embodiments, the anonymous 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 aspects, the digital certificate may include information indicating that the UAV is entitled to perform the operation anonymously. In some embodiments, the anonymous token may include a cryptographically verifiable indication that the anonymous 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).

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

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

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

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

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

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

[0151] At block 1104, the processor may configure a response message that does not indicate an identity of the UAV based on a determination 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 an 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 anonymous token. A means for performing the operations of block 1104 may include a processor 312 (FIG. 3).

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

[0153] 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, the request including an assertion and a digital signature associated with the UAV message. In some embodiments, the digital signature structure may include the 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).

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

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

[0156] In block 1208, the processor may send an indication that the UAV message is authenticated in response to receiving a response from the networked 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).

[0157] 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, which 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.

[0158] The processor of the network computing device 1300 may be any programmable microprocessor, microcomputer, or one or more multi-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 and one processor in a SOC (e.g., 202) dedicated to running other applications. Software applications may be stored in memory 1302 before being accessed and loaded into the processor. The processor may include sufficient internal memory to store application software instructions.

[0159] 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 comprising a processor configured with processor-executable instructions to perform operations of the following implementation example methods, 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.

[0160] Example 1. A method implemented by a processor of a network computing device for managing unmanned aerial vehicle (UAV) identity information, the method including: generating an anonymous token associated with a digital certificate of the UAV, providing the anonymous token to the UAV for use in operation, receiving a request to authenticate a UAV message, the request including the anonymous token and a digital signature associated with the UAV message, identifying the digital certificate using the anonymous token included in the request, determining whether the digital signature is verified using the digital certificate, and responsive to a determination that the digital signature is verified using the digital certificate, sending an indication that the UAV message is authenticated in response to the request.

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

[0162] 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.

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

[0164] Example 5. The method of any of Examples 1 to 4, wherein the anonymous token is associated with a usability time limit.

[0165] Example 6. The method of any of Examples 1 to 5, wherein the anonymous token is associated with a usability geographic restriction.

[0166] Example 7. The method of any of Examples 1 to 6, wherein the anonymous token comprises a hash of a digital certificate.

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

[0168] Example 9. The method of any of Examples 1 to 8, wherein generating the anonymous token associated with the digital certificate of the UAV includes generating the anonymous token from one of a hash of the digital certificate, a keyed hash of the digital certificate, or a keyed hash tree of the digital certificate.

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

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

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

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

[0173] Example 14. The method of any of Examples 12 or 13, wherein the assertion includes a message and an anonymous token, and a digital signature is performed on the message and the anonymous token.

[0174] Example 15. The method of any of Examples 12 to 14, wherein the assertion includes an attribute or a data structure pointer to information indicating that the UAV is entitled to perform the operation anonymously.

[0175] Example 16. The method of any of Examples 12 to 15, further comprising: receiving a request for identification information of the UAV; and configuring a response message that does not include identification information based on a digital certificate of the UAV based on a determination that the UAV is eligible to perform the operation anonymously.

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

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

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

[0179] Example 20. The method of any of Examples 12 to 19, wherein broadcasting information about a UAV configured without identity information of the UAV includes broadcasting one or more pseudonymous certificates associated with an anonymous token.

[0180] Example 21. The method of any one of Examples 12 to 20, further comprising: receiving a request to authenticate the UAV message, the request including an anonymous 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, the request including the anonymous token and the digital signature; receiving a response from the network computing device indicating whether the UAV message is authenticated; and sending an indication that the UAV message is authenticated in response to receiving a response from the network computing device indicating that the UAV message is authenticated.

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

[0182] As used in this application, terms such as "component," "module," and "system" 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 to one processor or core or distributed among two or more processors or cores. In addition, these components may execute from various non-transitory computer-readable media on which various instructions or data structures are stored. Components may communicate by way of local or remote processes, function or procedure calls, electronic signals, data packets, memory reads / writes, and other known network, computer, processor, or process related communication methods.

[0183] A number of different cellular and mobile communication services and standards are 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) and newer 3GPP® technologies, Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), 3GSM, General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA) systems, and the like. Examples of technologies include the following: (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 & 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. It should be understood that any reference to terminology and / or technical details relating to a particular telecommunications standard or technology is for illustrative purposes only and does not limit the scope of the claims to a particular communication system or technology unless specifically recited in the claim language.

[0184] 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 with 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 substituted for or combined with one or more operations of the methods and operations 800, 900, 1000, and 1100.

[0185] The above method descriptions and process flow diagrams are provided as illustrative examples only and do not 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-described embodiments may be performed in any order. Terms such as "then," "then," and "next" do not limit the order of operations, but rather these terms are used to guide the reader through the method descriptions. Additionally, any reference to a claim element in the singular, for example using the articles "a," "an," or "the," should not be construed as limiting the element to the singular.

[0186] The various exemplary logic blocks, modules, components, circuits, and algorithmic operations described in connection with 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.

[0187] 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 specific to a given function.

[0188] In one or more embodiments, the described functions 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 or processor-readable storage medium. The operations of the methods or algorithms disclosed herein may be embodied in a processor-executable software module or processor-executable instructions that may reside on a non-transitory computer-readable or processor-readable storage medium. A non-transitory computer-readable or processor-readable storage medium may be any storage medium that may be accessed by a computer or processor. By way of example and not limitation, such a non-transitory computer-readable or processor-readable storage medium may include RAM, ROM, EEPROM, FLASH memory, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage smart objects, or any other medium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a computer. As used herein, disk and disc 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 using lasers. Combinations of the above are also included within the scope of non-transitory computer-readable media and non-transitory processor-readable media. Additionally, operations of a method or algorithm may exist 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.

[0189] The foregoing 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. [Explanation of symbols]

[0190] 100 Access Network 105 BS 110 User Equipment (UE) 120 Communication Links 130 Coverage Area 132 Backhaul Link Interface 134 Backhaul Link Interface 150 Wi-Fi access points (AP) 152 Wi-Fi stations (STA) 154 Communication Links 158 Device-to-Device (D2D) Communication Links 160 Evolved Packet Core (EPC) 162 Mobility Management Entity (MME) 164 Other MMEs 166 Serving Gateway 168 Multimedia Broadcast Multicast Service (MBMS) Gateway 170 Broadcast Multicast Service Center (BM-SC) 172 Packet Data Network (PDN) Gateway 174 Home Subscriber Server (HSS) 176 IP Services 180g Node B (gNB) 182 Beamforming 190 5G Core (5GC) 192 Access and Mobility Management Function (AMF) 193 Other AMF 194 Session Management Facility (SMF) 195 User Plane Function (UPF) 196 Unified Data Management (UDM) 197 IP Services 202 Transceiver 206 Receiver 208 Transmitter 212 processors 216 Memory 220 Modem 222 Communication Components 224 Certificate Components 244 Bus 265 Antenna 288 RF Front End 290 Low Noise Amplifier (LNA) 292 Switch 296 Filters 298 Power Amplifier (PA) 302 Transceiver 306 Receiver 308 Transmitter 312 processor 316 Memory 320 Modem 322 Communication Components 344 Bus 365 Antenna 375 Applications 388 RF Front End 390 Low Noise Amplifier (LNA) 392 Switch 396 Filters 398 Power Amplifier (PA) 400 Environment 402 Mobile Devices 404 Operator 410 Receiver 412 Wireless Communication Links 414 Communication Links 416 Communication Interface 420 UAV Service Provider (USS) 422 UAV Flight Management System (UFMS) 430 Core Network

Claims

1. 1. A method implemented by a processor of a networked computing device for managing unmanned aerial vehicle (UAV) identification information, comprising: generating an anonymous token associated with a digital certificate of the UAV, the anonymous token including an indication that the UAV is entitled to perform operations anonymously; providing the anonymous token to enable use of the UAV in anonymous operation; receiving a request to authenticate a UAV message, the request including the anonymous token and a digital signature associated with the UAV message; identifying the digital certificate using the anonymous token included in the request; determining whether the digital signature is verified using the digital certificate; responsive to determining that the digital signature is verified using the digital certificate, sending an indication that the UAV message is authenticated in response to the request. A method comprising:

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

3. The method of claim 1 , wherein the digital certificate includes an indication that the UAV is entitled to perform operations anonymously.

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

5. generating the anonymous token associated with a digital certificate for the UAV comprises generating a plurality of anonymous tokens associated with the digital certificate; each of the plurality of anonymous tokens is associated with a usability time limit; providing the anonymous token to the UAV for use in the operation includes providing the anonymous tokens to the UAV for use in the operation; The method of claim 1 , wherein use of each of the anonymous tokens is limited by a respective usability time limit.

6. 6. The method of claim 5, wherein generating the plurality of anonymous tokens associated with the digital certificate comprises generating the plurality of anonymous tokens using a keyed hash tree.

7. 1. A network computing device, comprising: means for generating an anonymous token associated with a digital certificate of an unmanned aerial vehicle (UAV), the anonymous token including an indication that the UAV is entitled to perform operations anonymously; means for providing the anonymous token to enable use of the UAV in anonymous operation; means for receiving a request to authenticate a UAV message, the request including the anonymous token and a digital signature associated with the UAV message; means for identifying the digital certificate using the anonymous token included in the request; means for determining whether the digital signature is verified using the digital certificate; means for, in response to determining that the digital signature is verified using the digital certificate, sending an indication that the UAV message is authenticated in response to the request; 1. A network computing device comprising:

8. The network computing device of claim 7 , wherein the anonymous token includes a cryptographically verifiable indication that the anonymous token is associated with the digital certificate.

9. The network computing device of claim 7 , wherein the digital certificate includes an indication that the UAV is entitled to perform operations anonymously.

10. The method of claim 1 or the network computing device of claim 7, wherein the anonymous token is associated with a usability time limit.

11. The method of claim 1 or the network computing device of claim 7, wherein the anonymous token is associated with a usability geographical restriction.

12. The method of claim 1 or the network computing device of claim 7, wherein the anonymous token comprises one of a hash of the digital certificate or a hash of the digital certificate concatenated with a secret value.

13. 8. The network computing device of claim 7, wherein the means for generating the anonymous token associated with the digital certificate of the UAV comprises means for generating the anonymous token from one of a hash of the digital certificate, a keyed hash of the digital certificate, or a keyed hash tree of the digital certificate.

14. the means for generating the anonymous token associated with a digital certificate of the UAV includes means for generating a plurality of anonymous tokens associated with the digital certificate; each of the plurality of anonymous tokens is associated with a usability time limit; the means for providing the anonymous token to the UAV for use in the operation includes means for providing the anonymous tokens to the UAV for use in the operation; The network computing device of claim 7 , wherein use of each of the anonymous tokens is limited by a respective usability time limit.

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

Images