Patent Description:
Embodiments of the present disclosure relate to design and operation of unmanned aerial systems, and more specifically, monitoring and allocation of unmanned aerial vehicle media sessions and managing network resources.

An unmanned aerial vehicle (UAV) may have an identification (ID) associated with it. Indeed, some UAVs are mandated to have an ID before becoming airborne. For example, in North America, the Federal Aviation Administration (FAA) is making regulations to make sure all UAVs have some sort of identification to be legal to fly, and such identification is called a remote identification (RID) for a drone or UAV.

For various reasons, including manufacturing errors and registration procedure errors, RIDs may be duplicated for two or more unmanned aerial systems (UASes). This can result in a registration failure when these UASes attempt to register with a UAS Service Supplier (USS), which may prevent take-off for a UAV with a duplicate RID. Relevant prior art is disclosed in <CIT>, <CIT> and <CIT>.

According to the invention, a method performed by at least one processor included in an unmanned aerial system (UAS) is provided according to claim <NUM>. The method includes: transmitting, to a UAS Service Supplier (USS) implemented on at least one server, a first registration request to register a first remote identification (RID) corresponding to the UAS with the USS; receiving, from the USS, an indication that the first RID is a duplicate RID that is registered with the USS; determining, based on the first RID, a second RID corresponding to the UAS; and transmitting, to the USS, a second registration request to register the second RID.

According to the invention, a device included in an unmanned aerial system (UAS) is provided according to claim <NUM>. The device includes: at least one memory configured to store program code; and at least one processor configured to read the program code and operate as instructed by the program code. The program code includes: first transmitting code configured to cause the at least one processor to transmit, to a UAS Service Supplier (USS) implemented on at least one server, a first registration request to register a first remote identification (RID) corresponding to the UAS with the USS; first receiving code configured to cause the at least one processor to receive, from the USS, an indication that the first RID is a duplicate RID that is registered with the USS; determining code configured to cause the at least one processor to determine, based on the first RID, a second RID corresponding to the UAS; and second transmitting code configured to cause the at least one processor to transmit, to the USS, a second registration request to register the second RID.

According to the invention, a non-transitory computer-readable medium storing instructions is provided according to claim <NUM>. The instructions are configured to, when executed by at least one processor of a device included in an unmanned aerial system (UAS), cause the at least one processor to: transmit, to a UAS Service Supplier (USS) implemented on at least one server, a first registration request to register a first remote identification (RID) corresponding to the UAS with the USS; receive, from the USS, an indication that the first RID is a duplicate RID that is registered with the USS; determine, based on the first RID, a second RID corresponding to the UAS; and transmit, to the USS, a second registration request to register the second RID.

Referring to <FIG>, an unmanned aerial system (UAS) (<NUM>) can include an unmanned aerial vehicle (UAV) (<NUM>) and a controller (<NUM>). The controller (<NUM>) can use a data link (<NUM>) to communicate control commands from the controller (<NUM>) to the UAV (<NUM>). The controller (<NUM>) may include at least one communication circuit that is configured to provide communication including the data link (<NUM>), via very high frequency (VHF), ultra-high frequency (UHF), or other wireless technology that is analog or digital radio conveying. The controller (<NUM>) via the data link (<NUM>) may control power levels of the engines (<NUM>) of the UAV (<NUM>) or control surfaces of the UAV (<NUM>). More abstract commands like pitch, yaw, and roll, similar to those of helicopters or aircraft, can also be used. An experienced pilot can operate some UAVs with those basic controls, not relying on any advanced onboard processing of control signals inside a UAV. UAVs have been available in many forms, including as helicopters and aircraft.

Advances in onboard electronic designs more recently allow the offload of certain tasks from the human operator to the UAV itself. Many UAVs, today, include sensor(s) (<NUM>) that indicate to an onboard controller (<NUM>) of the UAV (<NUM>) characteristics of the UAV (<NUM>) such as, for example, the attitude and the acceleration of the UAV (<NUM>). The onboard controller (<NUM>) can be a computer system with a scaled-down or non-existent user interface. The information obtained by the sensor(s) (<NUM>), in addition to the control inputs received from the data link (<NUM>) from the controller (<NUM>), may allow the UAV (<NUM>) to remain stable unless positive control input is obtained from the controller (<NUM>).

Even more recently, UAVs can include a receiver (<NUM>) configured to receive communication from one of the Global Navigation Satellite Systems (GNSS), such as the Global Positioning System (GPS) operated by the United States. <FIG> illustrates a single satellite (<NUM>) that provides a signal (<NUM>) as such communication, to represent a GNSS. However, the receiver (<NUM>) of the UAV (<NUM>) may receive communication from a GNSS that includes three or more, and typically four or more, line-of-sight satellites to triangulate the position of the UAV (<NUM>) in space. The receiver (<NUM>), which may be a GNSS receiver, may determine with fair accuracy the position of the UAV (<NUM>) in space and time. In some UAVs, a GNSS can be augmented by additional sensors (such as an ultrasonic or LIDAR sensor) of the UAV (<NUM>) on the vertical (Z-) axis to enable soft landings (not depicted). The UAV (<NUM>), according to some embodiments, may be configured to perform features such as "fly home" and "auto-land" based on GNSS capabilities, where the UAV (<NUM>) flies to a location that was defined as its home location. Such features may be performed by the UAV (<NUM>) based upon a simple command from the controller (<NUM>) (like: the push of a single button) or in case of a loss of the data link (<NUM>) from the controller (<NUM>) or other timeout of meaningful control input.

As another recent development, the UAV (<NUM>) may also include one or more cameras (<NUM>). In some cases, the UAV (<NUM>) may include a gimbal-mounted camera as one of the cameras (<NUM>) and can be used to record pictures and video of a quality sufficient for the UAV's users-today, often in High Definition TV resolution. In some cases, the UAV (<NUM>) may include other cameras (<NUM>), often covering some or all axes of movement, and the UAV (<NUM>) may be configured to perform onboard signal processing based on signals from the cameras (<NUM>) for collision avoidance with both fixed and moving objects.

In some cases, the UAV (<NUM>) may include a "main" camera as one of the cameras (<NUM>) and its camera signal can be communicated by a communication interface (e.g. communication circuit) of the UAV (<NUM>) via a data link (<NUM>) in real-time towards the human user, and displayed on a display device (<NUM>) included in, attached to, or separate from the controller (<NUM>). The data link (<NUM>) may be the same as or different from the data link (<NUM>). Accordingly, UAVs may be successfully flown out of line-of-sight of a human pilot, using a technique known as "First Person View" (FPV).

Referring to <FIG>, a UAS (<NUM>) may include a UAV (<NUM>) and a controller (<NUM>). The UAV (<NUM>) and the controller (<NUM>) may be the same or similar to the UAV (<NUM>) and the controller (<NUM>) illustrated in <FIG>, respectively. According to an embodiment, the UAS (<NUM>), potentially operated by a UAS operator (<NUM>) such as a human pilot, may be configured to inform one or more UAS Service Suppliers (USSs) (<NUM>) about the position of the UAV (<NUM>) in real-time. In embodiments, the USS may be implemented on or using, for example, a server. The reporting can be conducted using the Internet (<NUM>). For all but the most exotic use cases involving tethered UAVs, this may imply that one or both of the UAV (<NUM>) and the controller (<NUM>) of the UAS (<NUM>) may configured to have a connection (<NUM>) over a wireless network such as a network (<NUM>) (e.g. a cellular network) to the Internet (<NUM>), and the USS (<NUM>) also may have a connection (<NUM>) to the Internet (<NUM>). Such a scenario may be assumed herein, but embodiments of the present disclosure are not limited thereto. Networks other than the Internet (<NUM>) may also be used. For example, conceivably, a closed wireless network that is not the Internet could be used to communicate between the UAS (<NUM>) and the USS (<NUM>). Closed wireless networks may be used for certain military UAVs. When referring to the "Internet" henceforth, such networks are meant to be included.

Many physical wireless network technologies may be deployed in uses that enable connections (<NUM>) (e.g. wireless connections) and networks (<NUM>) (e.g. wireless networks) to connect systems such as the controller (<NUM>) or the UAV (<NUM>) of the UAS (<NUM>) to the Internet (<NUM>). For outdoor applications, mobile networks may be used such as, for example, <NUM>th Generation or "<NUM>" networks. Henceforth, the use of such a <NUM> network may be assumed but embodiments of the present disclosure are not limited thereto. Other physical network technologies can equally be employed, including for example, <NUM>, <NUM>, <NUM>, LTE mobile networks, wireless LAN in infrastructure or ad hoc mode, zig-bee, and so on. In embodiments of the present disclosure, a mobile network carrying the Internet can offer bi-directional communication, such as, for example, between the UAS (<NUM>) and the USS (<NUM>). The Quality of Service in each direction may differ however. According to embodiments of the present disclosure, the UAV (<NUM>), the controller (<NUM>), and/or the USS (<NUM>) may include communication interfaces (including for example, a transmitter and/or a receiver) and at least one processor with memory that implements one or more of the physical wireless network technologies, so as to be configured to communicate via one or more of the network types of the present disclosure.

With reference to <FIG>, the connections (<NUM>) between the Internet (<NUM>) through a network (<NUM>) (e.g. a cellular network) to the UAV (<NUM>) and/or the controller (<NUM>) can be bi-directional. When using Internet protocols such as Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), Quick UDP Internet Connections (QUIC), and similar, for the communication between the UAS (<NUM>) and the USS (<NUM>), then by the nature of such protocols, a bi-directional link may be required for those protocols to work.

As discussed above, a UAV, for example UAV (<NUM>) or UAV (<NUM>), may have an identification (ID) associated with it. Indeed, some UAVs are mandated to have an ID before becoming airborne. For example, in North America, the Federal Aviation Administration (FAA) is making regulations to make sure all UAVs have some sort of identification to be legal to fly, and such identification is called a remote identification (RID) for a drone or UAV.

A few RID types have been identified by the Civil Aviation Authority (CAA) and all RID must be registered to a USS, for example USS (<NUM>). The USS maintains all direct communications with a UAS and forwards appropriate information to UTM. UTM may have other sources of information on UAS and may query the USS for more information on a UAS, for example UAS <NUM>.

The following are examples of RID types:.

In embodiments, whatever RID type has been assigned to a UAS (<NUM>), the RID must be registered to a USS (<NUM>). In order for the UAS (<NUM>) to register with the USS, the UAS (<NUM>) must present a unique RID to the USS (<NUM>).

Two of the RID types described above, ANSI/CTA-<NUM>-A Serial Number and CAA-level Assigned Registration Number, may be statically assigned, for example to the UAS (<NUM>, or to the UAV (<NUM>), and may be used by the UAS (<NUM>) for registration.

As discussed above, for various reasons, including manufacturing errors and registration procedure errors, RIDs of these RID types can be duplicated for two or more UASes (<NUM>). This can result in a registration failure when these UASes (<NUM>) attempts to register with a USS (<NUM>), which prevents take-off for the UAV (<NUM>) being controlled. Since these registration types are statically assigned, there is no way for the UAS to recover from this condition.

<FIG> shows an example process <NUM> for registering a UAS, for example UAS (<NUM>), using an ANSI/CTA-<NUM>-A serial number. In process <NUM>, a UAS (<NUM>) may determine the ANSI/CTA-<NUM>-A serial number it will use as a RID at block <NUM>. For example, the UAS may determine an ANSI/CTA-<NUM>-A serial number that is hard coded into hardware of UAV (<NUM>). At block <NUM>, UAS (<NUM>) attempts to register this RID with a USS (<NUM>).

If this registration succeeds at block <NUM>, the UAS (<NUM>) may continue to prepare for flight of UAV (<NUM>) at block <NUM>.

If this registration fails because the RID is a duplicate at block <NUM>, the UAS (<NUM>) may use the current RID as input to compute a <NUM>-bit Overlay Routable Cryptographic Hash Identifiers (ORCHID) hash, and then use this hashed valued to construct a HHIT at block <NUM>. Then, UAS (<NUM>) may attempt to register with the USS (<NUM>) using this HHIT as the RID at block <NUM>.

<FIG> shows an example process <NUM> for registering a UAS, for example UAS (<NUM>), using CAA-level assigned registration number. In process <NUM>, a UAS (<NUM>) may determine the CAA-level assigned registration number it will use as a RID at block <NUM>, and may attempt to register this RID with a USS (<NUM>) at block <NUM>.

If this registration succeeds at block <NUM>, the UAS (<NUM>) may continue to prepare for flight at block <NUM>.

If this registration fails because the RID is a duplicate at block <NUM>, the UAS (<NUM>) may use the current RID as input to compute a <NUM>-bit ORCHID hash, and then use this hashed valued to construct a HHIT at block <NUM>. Then, UAS (<NUM>) may attempt to register with the USS (<NUM>) using this HHIT as the RID at block <NUM>.

In embodiments, a HHIT RID may be used because HHIT RIDs use a <NUM>-bit hash size, so have a <NUM>% probability of collision given a population of <NUM> million HHIT RIDs.

Accordingly, embodiments may provide a method of allowing a UAS to recover from registration failures due to duplicate Registration IDs of the ANSI/CTA-<NUM>-A Serial Number type by attempting registration with a Registration Number created by hashing the duplicate Registration Number using the IETF HHIT algorithm, with the ANSI/CTA-<NUM>-A Serial Number used as input.

Further, embodiments may provide a method of allowing a UAS to recover from registration failures due to duplicate Registration IDs of the CAA-level Assigned Registration Number type by attempting registration with a Registration Number created by hashing the duplicate Registration Number using the IETF HHIT algorithm, with the CAA-level Assigned Registration Number used as input.

In embodiments, and as for example described above, the ANSI/CTA-<NUM>-A Serial Number, CAA-level Assigned Registration Number, and Universally Unique IDentifier (UUID) may be serial numbers or registration numbers which may be assigned to or associated with any one of UAS (<NUM>), UAV (<NUM>), controller (<NUM>), UAS (<NUM>), UAV (<NUM>), controller (<NUM>), or any associated hardware or software, and may be assigned or associated by any one of a manufacturer, a local or international CAA, or any other serial number or registration number authority as desired.

<FIG> are flowcharts illustrating example processes 500A-500C for managing a UAS, for example during a UAS registration process. <FIG> may be described with the aid of <FIG>. In embodiments, one or more blocks of processes 500A-500C may be combined in any order.

As shown in <FIG>, process 500A may include transmitting, to a USS implemented on at least one server, a first registration request to register a first RID corresponding to the UAS with the USS (block <NUM>). In embodiments, the UAS may correspond to UAS (<NUM>) and/or UAS (<NUM>), and the USS may correspond to USS (<NUM>). In embodiments, the first registration request may correspond to blocks <NUM>-<NUM> or blocks <NUM>-<NUM> discussed above, and the first RID may correspond to or include the ANSI/CTA-<NUM>-A serial number, the CAA-level assigned registration number or any other identifier discussed above.

As further shown in <FIG>, process 500A may include receiving, from the USS, an indication that the first RID is a duplicate RID that is registered with the USS (block <NUM>).

As further shown in <FIG>, process 500A may include determining, based on the first RID, a second RID corresponding to the UAS (block <NUM>).

As further shown in <FIG>, process 500A may include transmitting, to the USS, a second registration request to register the second RID (block <NUM>). In embodiments, the second registration request may correspond to blocks <NUM>-<NUM> or blocks <NUM>-<NUM> discussed above, and the second RID may correspond to or include the ANSI/CTA-<NUM>-A serial number, the CAA-level assigned registration number or any other identifier discussed above.

In embodiments, the first RID may include an ANSI/CTA-<NUM>-A serial number.

In embodiments, the ANSI-CTA-<NUM>-A serial number may be coded into hardware of UAV associated with the UAS. In embodiments, the UAV may correspond to UAV (<NUM>) and/or UAV (<NUM>).

In embodiments, the first RID may include a Civil Aviation Authority (CAA) assigned registration number.

In embodiments, process 500B illustrated in <FIG> may be combined with process 500A. For example, blocks of process 500B may be performed after block <NUM> of process 500A.

As shown in <FIG>, process 500B may include receiving, from the USS, an indication that the UAS is registered with the USS based on the second RID (block <NUM>).

As further shown in <FIG>, process 500B may include preparing an unmanned aerial vehicle (UAV) associated with the UAS for flight based on the second RID (block <NUM>).

In embodiments, process 500C illustrated in <FIG> may be combined with process 500A. For example, blocks of process 500C may be performed in combination with block <NUM> of process 500A. In embodiments, blocks of process 500C may be sub-blocks of block <NUM> of process 500A.

As shown in <FIG>, process 500C may include obtaining a hashed value based on the first RID (block <NUM>).

As further shown in <FIG>, process 500A may include computing the second RID based on the hashed value (block <NUM>).

In embodiments, the hashed value may be a <NUM>-bit hashed value.

In embodiments, the hashed value may be an Overlay Routable Cryptographic Hash Identifiers (ORCHID) hashed value.

In embodiments, the second RID may include an Internet Engineering Task Force (IETF) Hierarchical Host Identity Tag (HHIT) constructed based on the hashed value.

It may be appreciated that <FIG> provide only illustrations of implementations, and do not imply any limitations with regard to how different embodiments may be implemented. Many modifications to the depicted environments may be made based on design and implementation requirements.

Although <FIG> show example blocks of processes 500A-500C, in some implementations, processes 500A-500C may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in <FIG>. For example, any one or more of the blocks included in processes 500A-500C may be performed in place of, or in combination with, any other one or more blocks included in processes 500A-500C, in any order. Additionally, or alternatively, two or more of the blocks of processes 500A-500C may be performed in parallel.

Further, the proposed methods may be implemented by processing circuitry (e.g., one or more processors or one or more integrated circuits). In one example, the one or more processors execute a program that is stored in a non-transitory computer-readable medium to perform one or more of the proposed methods.

Systems of the present disclosure may comprise at least one processor and memory storing computer code. The computer code, when executed by the at least one processor, may be configured to cause the at least one processor to perform the functions of the embodiments of the present disclosure. For example, the UASs, UAVs, and USSs of the present disclosure may each include a respective at least one processor and memory storing computer code configured to cause the UASs, UAVs, and USSs to perform their respective functions.

The techniques for Unmanned Aerial System Communication described above can be implemented in, for example, controller and UAV, as computer software using computer-readable instructions and physically stored in one or more computer-readable media. For example, <FIG> shows a computer system <NUM> suitable for implementing certain embodiments of the disclosed subject matter.

With reference to <FIG>, a computer system (<NUM>) suitable for implementing certain embodiments of the disclosed subject matter is illustrated.

The computer software can be coded using any suitable machine code or computer language, that may be subject to assembly, compilation, linking, or like mechanisms to create code including instructions that can be executed directly, or through interpretation, micro-code execution, and the like, by computer central processing units (CPUs), Graphics Processing Units (GPUs), and the like.

Input human interface devices may include one or more of (only one of each depicted): keyboard (<NUM>), mouse (<NUM>), trackpad (<NUM>), touch-screen (<NUM>), joystick (<NUM>), microphone (<NUM>), scanner (<NUM>), and camera (<NUM>).

Such human interface output devices may include tactile output devices (for example tactile feedback by the touch-screen (<NUM>), data-glove, or joystick (<NUM>), but there can also be tactile feedback devices that do not serve as input devices. For example, such devices may be audio output devices (such as: speakers (<NUM>), headphones (not depicted)), visual output devices (such as screens <NUM> to include CRT screens, LCD screens, plasma screens, OLED screens, each with or without touch-screen input capability, each with or without tactile feedback capability-some of which may be capable to output two dimensional visual output or more than three dimensional output through means such as stereographic output; virtual-reality glasses (not depicted), holographic displays and smoke tanks (not depicted)), and printers (not depicted).

Computer system (<NUM>) can also include interface to one or more communication networks. Networks can for example be wireless, wireline, optical. Networks can further be local, wide-area, metropolitan, vehicular and industrial, real-time, delay-tolerant, and so on. Examples of networks include local area networks such as Ethernet, wireless LANs, cellular networks to include GSM, <NUM>, <NUM>, <NUM>, LTE and the like, TV wireline or wireless wide area digital networks to include cable TV, satellite TV, and terrestrial broadcast TV, vehicular and industrial to include CANBus, and so forth. Certain networks commonly require external network interface adapters that attached to certain general purpose data ports or peripheral buses (<NUM>) (such as, for example USB ports of the computer system (<NUM>); others are commonly integrated into the core of the computer system (<NUM>) by attachment to a system bus as described below (for example Ethernet interface into a PC computer system or cellular network interface into a smartphone computer system). Using any of these networks, computer system (<NUM>) can communicate with other entities. Such communication can be uni-directional, receive only (for example, broadcast TV), uni-directional send-only (for example CANbus to certain CANbus devices), or bi-directional, for example to other computer systems using local or wide area digital networks. Such communication can include communication to a cloud computing environment (<NUM>). Certain protocols and protocol stacks can be used on each of those networks and network interfaces as described above.

Aforementioned human interface devices, human-accessible storage devices, and network interfaces (<NUM>) can be attached to a core (<NUM>) of the computer system (<NUM>).

The core (<NUM>) can include one or more Central Processing Units (CPU) (<NUM>), Graphics Processing Units (GPU) (<NUM>), specialized programmable processing units in the form of Field Programmable Gate Areas (FPGA) (<NUM>), hardware accelerators (<NUM>) for certain tasks, and so forth. These devices, along with Read-only memory (ROM) (<NUM>), Random-access memory (RAM) (<NUM>), internal mass storage such as internal non-user accessible hard drives, SSDs, and the like, may be connected through a system bus (<NUM>). A graphics adapter (<NUM>) may be included in the core (<NUM>).

Transitional data can be also be stored in RAM (<NUM>), whereas permanent data can be stored for example, in the mass storage (<NUM>) that is internal.

As an example and not by way of limitation, the computer system (<NUM>) having architecture , and specifically the core (<NUM>) can provide functionality as a result of processor(s) (including CPUs, GPUs, FPGA, accelerators, and the like) executing software embodied in one or more tangible, computer-readable media. Such computer-readable media can be media associated with user-accessible mass storage as introduced above, as well as certain storage of the core (<NUM>) that are of non-transitory nature, such as core-internal mass storage (<NUM>) or ROM (<NUM>). The software implementing various embodiments of the present disclosure can be stored in such devices and executed by core (<NUM>). A computer-readable medium can include one or more memory devices or chips, according to particular needs. The software can cause the core (<NUM>) and specifically the processors therein (including CPU, GPU, FPGA, and the like) to execute particular processes or particular parts of particular processes described herein, including defining data structures stored in RAM (<NUM>) and modifying such data structures according to the processes defined by the software. In addition or as an alternative, the computer system can provide functionality as a result of logic hardwired or otherwise embodied in a circuit (for example: accelerator (<NUM>)), which can operate in place of or together with software to execute particular processes or particular parts of particular processes described herein. Reference to software can encompass logic, and vice versa, where appropriate. Reference to a computer-readable media can encompass a circuit (such as an integrated circuit (IC)) storing software for execution, a circuit embodying logic for execution, or both, where appropriate. The present disclosure encompasses any suitable combination of hardware and software.

Claim 1:
A method performed by at least one processor included in an unmanned aerial system, UAS, the method comprising:
transmitting (<NUM>), to a UAS Service Supplier, USS, UOO implemented on at least one server, a first registration request to register a first remote identification, RID, corresponding to the UAS with the USS;
and characterized by further comprising:
receiving (<NUM>), from the USS, an indication that the first RID is a duplicate RID that is registered with the USS;
determining (<NUM>), based on the first RID, a second RID corresponding to the UAS; and transmitting (<NUM>), to the USS, a second registration request to register the second RID.