Unmanned Aircraft System Communications

Abstract

An unmanned aerial vehicle and a method for controlling the same are provided. Data related to the unmanned aerial vehicle communicated during handoff is identified. A service supplier is notified of an operational status of the unmanned aerial vehicle based on the identified data. Commands corresponding to operation of the unmanned aerial vehicle are received from the service supplier.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority from U.S. Patent and Trademark Office U.S. Provisional Patent Applications No. 63 / 052,170 (filed July 15, 2020), No. 63 / 052,145 (filed July 15, 2020), No. 63 / 112,543 (filed November 11, 2020), No. 63 / 112,549 (filed November 11, 2020), No. 63 / 115,973 (filed November 19, 2020), and U.S. Patent Application No. 17 / 323,458 (filed May 18, 2021), which are incorporated by reference in their entireties herein.

[0002] The present disclosure relates generally to the field of aviation, and more specifically to unmanned aerial systems. [Background technology]

[0003] Unmanned aerial vehicles (UAVs) have become significantly easier to fly, which has made them popular not only with professional UAV pilots and ambitious, well-heeled hobbyists, but also with the general public. As a result, millions of UAVs are now sold each year, compared to a few thousand (at most) model helicopters about 15 years ago. At the same time, the knowledge, proficiency, and engagement of the user community has, on average, declined. Summary of the Invention

[0004] Embodiments relate to methods, systems, and computer-readable media for controlling an unmanned aerial vehicle (UAV). According to one aspect, a method for controlling an unmanned aerial vehicle (UAV) is provided. The method may include identifying data associated with the unmanned aerial vehicle to be communicated during a handoff. Based on the identified data, a service supplier is notified of an operational status of the unmanned aerial vehicle. An instruction corresponding to an operation of the unmanned aerial vehicle is received from the service supplier.

[0005] According to another aspect, an unmanned aerial vehicle (UAV) is provided. The unmanned aerial vehicle may include one or more processors, one or more computer readable memories, one or more tangible computer readable storage devices, and program instructions stored in at least one of the one or more storage devices and executed by at least one of the one or more processors via at least one of the one or more memories, thereby enabling the unmanned aerial vehicle to perform a method. The method may include identifying data associated with the unmanned aerial vehicle to be communicated during handoff. Based on the identified data, a service supplier is notified of an operational status of the unmanned aerial vehicle. Instructions corresponding to operation of the unmanned aerial vehicle are received from the service supplier.

[0006] According to yet another aspect, a computer readable medium for controlling an unmanned aerial vehicle (UAV) is provided. The computer readable medium may include one or more computer readable storage devices and program instructions stored in at least one of the one or more tangible storage devices, the program instructions being executable by a processor. The program instructions are executable by the processor to responsively perform a method that may include identifying data associated with the unmanned aerial vehicle to be communicated during handoff. Based on the identified data, a service supplier is notified of an operational status of the unmanned aerial vehicle. Instructions corresponding to operation of the unmanned aerial vehicle are received from the service supplier. [Brief description of the drawings]

[0007] These and other objects, features, and advantages will become apparent from the following detailed description of illustrative embodiments, which should be read and understood in connection with the accompanying drawings, in which various features of the drawings are not drawn to scale because the figures, together with the detailed description, are intended to facilitate understanding by those skilled in the art. [Figure 1] 1 is a schematic diagram of an unmanned aerial system. [Diagram 2] FIG. 1 is a schematic diagram of an unmanned aircraft system in communication with a UAS service system. [Diagram 3]FIG. 1 is a schematic diagram of a UAV chart. [Figure 4A] 1 is a schematic diagram of a UAS according to one embodiment. [Figure 4B] 1 is a schematic diagram of a UAS according to one embodiment. [Figure 4C] 1 is a schematic diagram of a UAS according to one embodiment. [Figure 5A] 1 is a schematic diagram of a RESTful location query and JONS response according to one embodiment. [Figure 5B] 2 is a schematic diagram of an HTTP query and an HTML response according to one embodiment. [Figure 6] 1 is a schematic diagram of a UAS according to one embodiment. [Figure 7] A schematic diagram of the workflow and reference points of the UAE (UAS Application Enabler) and SEAL architecture. [Figure 8] FIG. 1 is a schematic diagram of a computer system according to one embodiment. [Figure 9] FIG. 2 illustrates a high level procedure for SIP session management based on network resource requirements. [Figure 10] FIG. 2 illustrates a high level procedure of a SEAL NRM server for requesting additional bandwidth for a particular SIP session. [Figure 11] FIG. 1 illustrates the high level procedure for UAV-CAA Level ID using the SEAL Group Manager. [Figure 12] FIG. 13 illustrates another high level procedure for UAV-CAA Level ID using a SEAL Group Manager. [Figure 13] FIG. 1 illustrates a high level procedure for creating a UAV group using the SEAL Group Manager. [Figure 14] 1 is an operational flow diagram illustrating steps performed by a program for controlling an unmanned aerial vehicle (UAV) according to one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] Detailed embodiments of the claimed structures and methods are disclosed herein. However, it can be understood that the disclosed embodiments are merely examples of the claimed structures and methods, which can be embodied in various forms. However, these structures and methods can be embodied in many different forms and should not be construed as being limited to the exemplary embodiments described herein. Rather, these exemplary embodiments are provided so that this disclosure will be thorough and complete, and will fully convey its scope to those skilled in the art. In the description, details of well-known features and techniques may be omitted to avoid unnecessarily obscuring the presented embodiments.

[0009] As mentioned above, UAVs have become considerably easier to fly, which has made them popular with the general public as well as professional UAV pilots and aspiring, well-heeled hobbyists. As a result, millions of UAVs are now sold each year, compared to a few thousand (at most) model helicopters about 15 years ago. However, there is currently no mechanism for a UAV to select a service supplier, handle service handoffs when switching to another service supplier, detect flight rule deviations, and report them to the UAS service provider (USS / UTM). It would therefore be advantageous to provide a technical method for specifying how and what information to transfer, identifying the main drivers of flight rule violations, and communicating with the USS / UTM to improve safety during UAV operations.

[0010] Aspects are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer-readable media according to various embodiments. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0011] All but perhaps the smallest UAVs can pose a danger to manned aircraft, not only through mid-air collisions, but also through pilot distraction, saturation of air traffic control (ATC) resources, etc. The combination of thousands of UAVs potentially flying simultaneously on a given day, and UAV pilots who are (on average, compared to manned aircraft pilots) less skilled, less educated, less informed, and sometimes reckless, has resulted in millions of dollars being spent on aborted takeoffs, missed approaches, rerouting, grounding manned aircraft, and property damage from wildfires and other events that manned aircraft could not combat. There have been reports of lives lost due to the effects of mid-air collisions between amateur-piloted UAVs and helicopters. For these and other reasons, regulatory agencies, including the United Nations' International Civil Aviation Organization (ICAO) and the United States' Federal Aviation Administration (FAA), have begun regulating UAVs, including small UAVs under 55 pounds (24.95 kg). Heavier UAVs have historically already been subject to regulation.

[0012] In the United States, one aspect of such regulations requires pilots to carry a "remote pilot certificate" when conducting virtually all commercial (for hire) UAV operations. This certificate does not primarily address the mechanical aspects of flying a UAV, but rather, understanding and complying with regulations, including, for example, airspace, flight restrictions, etc. Commercial remote pilots may be aware of their obligations regarding compliance with rules and regulations regarding the operation of UAVs, including, among other things, airspace, while hobbyists may not be fully aware. UAS have become so cheap and easy to operate that the historical method of developing capabilities through model aircraft clubs and similar organizations no longer works reliably. For example, a significant number of UAVs are operated away from airfields maintained by model aircraft clubs by individuals who are not members of such clubs and who are likely never to have had regulatory considerations, let alone a briefing on the current airspace layout.

[0013] Another aspect proposed for regulation includes identification of UAVs and their flight to ATC, identification of other UAVs, etc. In the United States, "proposed rules" have been published by the FAA (https: / / www.federalregister.gov / documents / 2019 / 12 / 31 / 2019-28100 / remote-identification-of-unmanned-aircraft-systems). The proposed rules, when implemented by substantially all UAS, would provide ATC with certain insight into UAV activity at any given time. The rules would further require UASs to be equipped to inform the pilot if the reporting mechanism between the UAS and the system that interfaces with ATC (known as the UAV Service Supplier (USS)) is inactive while the UAV is airborne. However, contrary to many operations of manned aircraft in controlled airspace, where flight crews need to be in (audio) contact with ATC, squawk transponder codes, etc., the proposed rules do not envisage such a requirement and may be impractical without significantly increasing ATC resources. Thus far, the FAA via the USS may be able to obtain a certain amount of real-time insight into active UAV operations, but the Proposed Rule does not anticipate ATC affecting the flights of UAVs directly (through technical means) or indirectly (through communications with the pilot). Instead, the Proposed Rule is directed at informing ATC about UAV operations related to ATC's missions.

[0014] Referring to FIG. 1, an unmanned aerial vehicle (UAS) may include an unmanned aerial vehicle (UAV) (101) and a controller (102). The controller (102) may communicate control commands from the controller (102) to the UAV (101) using a data link (103). In its simplest form, the controller may be an analog or digital radio transmission of VHF, UHF, or other radio technology, such as a power level to the engine (104) of a drone or to the control surfaces of a model airplane (not shown). More abstract commands such as pitch, yaw, roll, etc. may also be used, as well as helicopter or airplane commands. An experienced pilot may operate some UAVs with these basic controls without relying on advanced on-board processing of control signals in the UAV. In the form of model helicopters and airplanes, such UAVs have been available for decades.

[0015] Advances in on-board electronics design have recently made it possible to offload certain tasks from a human operator to the UAV itself. Many UAVs today contain sensors (104) that indicate the UAV's attitude, acceleration, etc. to an on-board controller circuit (105). The on-board controller can be a computer system with a reduced or non-existent user interface. The information obtained by the sensors (104), in addition to the control inputs received over a data link (103) from the controller (102), allows the UAV to remain stable unless positive control inputs are received from the controller.

[0016] More recently, UAVs may include a receiver (106) to one of the Global Navigation Satellite Systems (GNSS), such as the Global Positioning System (GPS) operated by the United States (shown here as a signal (107) from a single satellite (108), but at least three, and typically four or more, line-of-sight satellites are used to triangulate the UAV's position in space). The GNSS receiver can determine the UAV's position in space and time with considerable accuracy. In some UAVs, the GNSS may be augmented with additional sensors, such as ultrasonic or lidar sensors, often on the most important vertical (Z-) axis, to enable soft landings (not shown). Some UAVs (101) that include GNSS capabilities offer users "fly home" and "auto-land" features, where the UAV (drone) flies to a location defined as the home position on a very simple command (such as a single button press) from the controller (102), or if the data link (103) from the controller is lost or other timeout of meaningful control input occurs. The receiver 106 can be configured to detect location via cellular networks such as 3G, 4G, or 5G, or even via Wi-Fi (wireless fidelity) Internet access.

[0017] As another recent development, some UAVs also include at least one camera (109). Some UAVs use a gimbal-mounted camera to record photos and videos of sufficient quality for the drone user, often now at high definition television resolution. Some UAVs include other cameras (110), often covering some or all of the axes of motion. On-board signal processing based on these camera signals is used for collision avoidance with both fixed and moving objects.

[0018] In some UAVs, the camera signal of the "main" camera (109) may be communicated (111) in real time to a human user and displayed on a display device (112) contained in, attached to, or separate from the controller (102). This allows the UAV to be effectively removed from the view of the human pilot, using a technique technically known as "first-person view," or FPV.

[0019] Referring to FIG. 2, one option is for the UAS (including UAV (201) and controller (202)) to be potentially operated by a human pilot (203) and to inform one or more USSs (204) (only one shown) about the location of the UAV (201) in real time in accordance with the Proposed Rule. The reports can be made using the Internet (205). In all but the most exotic use cases involving tethered UAVs, this means a wireless Internet connection (206) to the UAS (UAV (201), controller (202), or both) via a wireless network, such as a 5G network (207), and a connection to the USS (204) that also includes an Internet connection (208). Such scenarios were envisioned in the Proposed Rule and are envisioned here as well. However, networks other than the Internet (205) can also be used. For example, a closed wireless network that is not the Internet can be used to communicate between the UAS and the USS. This is what is currently used for certain military UAVs. Hereafter, when reference is made to the "Internet", such networks are intended to be included.

[0020] Many physical wireless network technologies have been proposed, deployed, and / or used that allow wireless Internet connections (206) and wireless networks (205) to connect systems such as the UAS controller (202) or UAV (201) to the Internet (205). For outdoor applications, one option is the use of mobile networks, the latest known incarnation being the fifth generation, or "5G" networks. Hereinafter, the use of such 5G networks is assumed. However, other physical network technologies may be used as well, such as 3G, 3.5G, 4G, LTE mobile networks, infrastructure or ad-hoc mode wireless LANs, zig-bee, etc. In the context of this disclosure, mobile networks that extend the Internet may provide bidirectional communication, such as from the UAS to the USS. However, the quality of service in each direction may differ.

[0021] One important insight from FIG. 2 is that the link (206) between the Internet (205) and the UAV (201) or controller (202) via the 5G network (205) can be bidirectional. If Internet protocols such as IP, TCP, UDP, HTTP, QUIC, and the like are used for communication between the UAS and the USS (as envisioned in the proposed rule), a bidirectional link may be a necessity for those protocols to function, due to the nature of such protocols. Additionally, the proposed rule includes a requirement that the human pilot (203) be notified, perhaps from the controller (202) or the UAV itself (201), if communication between the UAS and the USS (204) is lost, which perhaps can be most easily accomplished via a data link between the USS (204) and the UAS, which would imply a bidirectional link (206). For these reasons, it is assumed hereafter that the link (206) is bidirectional.

[0022] Air traffic control (ATC) authorities such as the FAA, or government or civil authorities, or bodies tasked with ATC authorities, have had for decades various forms of not only regulations but also graphic, written, or verbal information regarding the layout of the airspace in which aircraft (manned and unmanned) operate. Historically available at various times in the form of printed charts, weekly publications, and text information read by fax or over the telephone or by flight service specialists, the relevant information is available in most countries, including the United States, from various sources, but also via the Internet. With respect to the disclosed subject matter, at least the following information may be relevant:

[0023] Charts: Many different types of aeronautical charts are available in different countries and for different purposes (low / high altitude, visual / instrument flight procedures, planning, etc.). Of particular relevance to small UAV operations are the US "Sectional Charts" and the "Low Altitude Authorization and Notification Capability" (LAANC) information displayed in chart format in a web browser. Charts are updated on a relatively long-term cycle (e.g. VFR sectional charts: every 6 months). For manned aircraft, the "active" charts must be used.

[0024] Referring to Figure 3, this figure shows an excerpt of a sectional chart centered on Livermore Airport in California (301). Note that the sectional chart is colored and the colors have meaning. However, the black and white representation used herein is sufficient to show the difficulties a recreational UAV pilot may have in interpreting the sectional chart. The dashed cycle (approximately 8 miles in diameter) (302) around the airport indicates "Class D" airspace at certain times (when the direction of Livermore Airport is open), which may mean that no (manned) aircraft operations are permitted inside this circle and up to certain altitudes without prior approval by ATC. Historically, the same rules applied to UAVs, resulting in UAVs being illegal in most parts of Livermore Township (east / right of Livermore Airport) and surrounding areas.

[0025] Recognizing that the requirements for manned aircraft operations are perhaps overly restrictive for recreational drones, the FAA has recently permitted recreational drones to be flown in certain portions of controlled airspace. With continued reference to Figure 3, a screenshot of a "UAV Chart" issued electronically by the FAA over the Internet and displayed in a web browser is shown. Again, the colors in these charts are significant, but the black / white representation is sufficient to indicate the key aspects of the chart. An 8 mile circle around Livermore Airport is again shown, with the original circle in blue. The area covered by the circle (representing controlled airspace) is then covered by rectangular blocks such as block 305. Each such block is approximately one square mile in size. Each block contains a numerical value indicating the maximum allowable altitude at which a UAV may fly within the block without prior authorization. A mechanism (in the form of an app) has been introduced to allow certain UAV operators to obtain authorization to fly higher than that limit by referencing the block identifier.

[0026] Notices to Aircraft Carriers (NOTAMs): Following an internationally accepted standardized format and written in plain English, these textual notices can be issued quickly, within minutes or hours, unlike charts, whose update cycles are measured in weeks and months, but their validity period can vary from a few hours to "indefinitely" or "until further notice". One of the many purposes of a NOTAM can be to update certain aspects of a chart. For example, an aeronautical chart can contain information about navigational obstacles such as tall towers. If temporary cranes are erected that are higher than a certain threshold (determined, among other things, by the proximity of the site to the approach paths of existing airports), they may constitute a navigation hazard, and therefore their presence, position, height, and expected duration are made available in the form of a NOTAM. An example of a NOTAM indicating the presence of a crane near an airport (San Carlos, KSQL) looks like this: KSQL SAN CARLOS !SQL 10 / 003 SQL OBST CRANE (ASN 2018-AWP-13591-OE) 372917N1221327W (1.9NM SE SQL) 309FT (300FT AGL) FLAGGED AND LGTD 1910072355-2001312159 CREATED: 07 Oct 2019 23:55:00 SOURCE: SQL

[0027] Temporary Flight Restrictions (TFR): A TFR is a form of NOTAM that can inform pilots or crew of airspace when special ATC permission may be required to enter. TFRs can be announced in advance (e.g., to cover an area over a long-planned sporting event) or issued in real time (e.g., in the case of a wildfire). Below are examples of TFRs that may be related to a fire or similar disaster. TFRs are only valid for one hour. FDC 9 / 1767 ZMP MN..AIRSPACE HIBBING, MN..TEMPORARY FLIGHT RESTRICTIONS WI AN AREA DEFINED AS 2 NM RADIUS OF 472601N0930200W (HIBBING VOR / DME HIB299015.6) SFC-4500FT BLASTINGPURSUANT TO 14 CFR SECTION 91.137(A)(1) TEMPORARY FLIGHT RESTRICTIONS ARE IN EFFECT. ONLY RELIEF ACFT OPS UNDER DIRECTION OF HIBBING TACONITE ARE AUTH IN THE AIRSPACE. HIBBING TACONITE TELEPHONE 218-262-5940 IS IN CHARGE OF ON SCENE EMERG RESPONSE ACT. MINNEAPOLIS / ZMP / ARTCC TELEPHONE 651-463-5580 IS THE FAA CDN FACILITY. 2001031630-2001031730

[0028] In the United States and many other countries, all of the above information is available in digital format. In the United States, such access is free of charge. The data format of the above information is standardized, publicly available, and very compact. All the aforementioned U.S. data relating to a particular day could fit into 16 GB.

[0029] The FAA is transitioning the NAS to Performance-Based Navigation (PBN), which primarily uses satellite navigation in the form of the Global Positioning Satellite System (GNSS). GPS (Global Positioning System) is one of the methods of GNSS. It is a system used for navigation and surveying around the world. The GPS system provides coordinates of a person's location or a place of interest using geographic lines of latitude and longitude. Parallels are horizontal lines that run from east to west across the Earth. The longest and principal line of latitude is called the equator. The equator is represented by 0° latitude. Meridians are vertical lines that run from the North Pole to the South Pole. The principal line of longitude is called the prime meridian. The prime meridian is represented by 0° longitude. Most locations on Earth are not along lines of latitude or longitude, but within a shape created from the intersection of horizontal and vertical lines.

[0030] To pinpoint a person on the Earth's surface, the lines of latitude and longitude are further divided and expressed in one of three common formats: degrees, minutes, and seconds (DMS). A common way to represent a GPS coordinator may be to use the format of a pair of latitude (N / S) and longitude (E / W). N (North) / S (South) can be placed at the end of each DMS to represent whether it is north or south of the equator. E (East) / W (West) can be placed at the end of each DMS to represent whether it is to the left of the prime meridian or to the right of the prime meridian. The space between each line of latitude or longitude representing 1° is divided into 60 minutes, and each minute is divided into 60 seconds. A specific example would be (25°24'10.1"N, 20°15'16.5"E).

[0031] It has already been noted that interpreting airspace using traditional means designed for manned aircraft is difficult and requires some training. The FAA has made available increasingly simplified charts (such as UAV Chart 303), apps, and other tools designed for non-experts, but even those tools are difficult to operate and, perhaps more importantly, require UAV pilots to actually consult them before flying their UAVs. A number of recent incidents involving UAVs in controlled airspace clearly demonstrate that not all UAV pilots do this.

[0032] Furthermore, especially for relatively small UAVs, it can be difficult for an untrained (or even trained) UAV pilot to gauge the altitude at which his UAV is flying. For example, how does a UAV pilot know that his small UAV is at an altitude of 90 feet (which may be legal in a particular area indicated on the UAV chart) or 110 feet (which may be illegal)? Technological measures built into the UAV (201) or controller (202) can help solve either problem.

[0033] Referring to FIG. 4A, in one embodiment, the UAV (401) may be equipped with an embedded computer system (402), except for most user interface components. The embedded system may advantageously be part of or integrated into the UAV's on-board flight control circuitry (for space and weight reasons). The system (402) may have a mechanism for acquiring its position in three-dimensional space. A GPS antenna (403) is depicted here, which may be one example of such a mechanism, together with a GPS receiver. Other mechanisms are a combination of GPS and a (potentially more accurate) barometric altitude sensor, triangulation mechanisms to determine lateral position from ground navigation tools (VOR, cell phone towers, etc.), etc. The UAV (401) may also include a storage mechanism (404) accessible by the user of the UAV. A micro SD card (404) is shown here as an example. However, the storage may be other replaceable semiconductor storage, the UAV's on-board NV-RAM accessible via a network plug from a computer or a wireless LAN, etc.

[0034] The storage device (404) may be of sufficient size to store information regarding the airspace in which the UAV may operate. Such information may include digital representations of charts, NOTAMs, TFRs, etc. The digital information may be interpreted by the embedded computer system and correlated with the drone's position in three dimensions (including lateral position and altitude). As a result of the correlation process, the UAV may be "legal to fly" or "not legal to fly" in the airspace it currently occupies. Optionally, other results are possible, such as "legal to fly but approaching the edge of legal airspace" or "legal to fly but will become illegal within 10 seconds if course is not changed."

[0035] In the same or another embodiment, the digital information in memory (404) may be loaded by a human user (405) via a personal computer, tablet, or similar device (406), or by an automated process from a source such as an airspace authority or designated service provider, for example via the Internet.

[0036] To minimize storage requirements, the digital information may be limited such that the information only pertains to a particular area, for example, the digital information may only include chart data for a 100 mile radius around the proposed flight site, which may have been preselected by the user (405) when downloading the chart data into memory (404).

[0037] In the same or another embodiment, the results of the correlation process may be communicated to the UAV pilot (407). One possible option is to use a data link (410) between the UAV and the controller to communicate a signal encoding the results of the correlation and to notify the pilot (407) by a tactile, visual, text, or audible alert via the controller or the UAV. For example, the pilot may be notified by a visual signal such as a vibration (409) of the controller, a warning light (not shown), an audible warning sound played through a speaker (not shown), or a message on a screen (408) (not shown) that may be attached to the controller. Presumably, the data link (410) is available, as may be required under the proposed FAA regulations anyway. However, if for some reason such a data link is not available, the UAV may instead or additionally include an on-board mechanism that can notify the pilot of the results of the correlation process. For example, the UAV may include a speaker or a warning light visible from the ground. As another example, the UAV may "bob" (a rapidly oscillating vertical movement).

[0038] The UAV may be configured to take one or more actions based on determining a potential violation or if the operator ignores a warning of a potential violation. For example, the UAV may land immediately, return to the operator, hover at its current location, or move to a location where there is no potential violation.

[0039] 4B, an alternative implementation can shift the computational burden from the UAV itself to the controller (409), which can then access the memory (404) and perform the aforementioned correlation based on position information transmitted by the UAV (401) over the data link (510).

[0040] 4C, in one embodiment, the UAV may be further equipped with a (wireless) network interface (420), e.g., a 5G network interface, which allows the UAV to access or point to a USS (423), or similar server operated by a relevant authority for the airspace, via a wireless network (421) (e.g., a 5G network) and the Internet (422). At power up, pre-flight, or during flight, the UAV (401) may query the USS (423) for one or more of the following: - charts, if the on-board charts in the storage (404) for the relevant area are not up to date (aeronautical charts have an expiration date); charts related to the geographical position obtained from GPS (403) or other georeferenced data, this chart including a reasonable radius around the current position of the UAV, which allows to calculate a reasonable radius depending on the endurance (maximum flight time) of the UAV, its maximum speed and safety factors to accommodate wind and other environmental factors; -NOTAMs related to similar areas; - TFRs related to similar areas; -Other information relevant to the flight, e.g. weather / wind data.

[0041] Information received using the above mechanisms may be integrated with on-board information in storage (404) and used as described below.

[0042] The details of the protocol used for communication between the UAV (401) and the USS (or other server) depend on the services provided by the USS (423). Historically, by way of example, NOTAMs and / or TFRs have been available in files covering the geographic area (several US states in size) of an air traffic control center. The UAV can request the file corresponding to the state in which it is operating (identified by its GPS position and on-board charts), download the relevant textual NOTAM file (tens or perhaps hundreds of kilobytes in size) using a protocol such as ftp or http, parse the file for relevant information, and integrate the found information with the on-board chart information in storage (404). Such a process may occur at least once before the flight, but may also occur several times during the flight, for example at one- or five-minute intervals. This is practical due to the relatively small file sizes, but is inefficient compared to other access mechanisms described below.

[0043] More recently, airspace authorities, including the FAA, have implemented modern query interfaces that allow for automated downloads of information related to specific locations at a much finer granularity than states. These interfaces can be based on RESTful operations. REST, also known as Representational State Transfer, is a methodology that allows clients to query a server, identified by a base Unified Resource Indicator (URI), via standard HTTP methods including, for example, GET, POST, PUT, PATCH, and DELETE, and in a prescribed format. One such prescribed standardized format is known as Java Object Notation, or JSON.

[0044] 5A, there is shown a RESTful query (501) to an FAA-designed USS server relating to a UVA chart, and the server's JSON-encoded response (502). In this case, the response indicates information such as the "Climb Limit" (503) in feet (504) (the maximum allowable altitude for a UAV), the chart's effective date (505) and last edit date (506) (from which an expiration date can be derived), and the location (506) and shape (507) of the spatial region to which the climb limit (503) applies.

[0045] Queries for TFRs / NOTAMs, or other real-time updates, could have a similar format. Such a query mechanism may be more suitable for UAVs compared to downloading and parsing a full file, since the size of both the query message and the response are relatively small, and the computational requirements for processing such messages are relatively low compared to parsing a text file several kilobytes in size. There would also arguably be no privacy concerns, since the UAV would have to inform the USS about its location anyway, according to the proposed rule.

[0046] After obtaining updates to the chart information stored in storage (404) according to any of the mechanisms described above or other suitable mechanisms, in the same or another embodiment, the results of the correlation process can be communicated to the UAV pilot (409).

[0047] The UAV may need to obtain permission from the USS / UTM prior to takeoff using any means of network communication such as wireless technologies like 3G / 4G / 5G. Permission obtained may include, but is not limited to, standby, permission to take off with follow-up instructions, or no permission to take off during a specified time frame. Once airborne, the UAV may only connect to a single USS / UTM for traffic advisory purposes for traffic monitoring, weather updates, and status updates.

[0048] During the UAV's en route to follow a predefined flight path, it may be necessary to switch to another USS / UTM as the service converges from the first one. The instructions can be obtained during takeoff clearance or updated after floating. This switch is called a handoff when the UAV changes its flight service to another service supplier or traffic controller. During the handoff phase, some data may need to be updated to the new USS / UTM service supplier. Similarly, new instruction data may be actively transmitted to the UAV. The following data transfers may include current position, altitude, speed, destination, power settings, and on-board equipment list such as barometer and payload.

[0049] At any time, a UAV may operate outside the limits assigned by the USS / UTM due to known or unknown reasons such as weather that causes the UAV to deviate from its flight course, on-board GPS failure causing loss of directional control, data link communication failure, inability to transmit and receive instruction messages from the USS, miscalculating flight time due to an incorrect indicated airspeed, entering dangerous or prohibited flight zones such as TFRs due to incorrect airspace interpretation, flying the UAV into an unsafe area due to an incorrect altitude indicator, or moving the UAV out of range due to excessive power usage. Being able to identify discrepancies between erroneous UAV flight data and USS instructions may be mandatory for safe operation. Table 1 shows the possible data formats. [Table 1]

[0050] As mentioned above, the FAA implements RESTfulp operations to retrieve NOTAM / TFR data. The returned data is in a standardized format known as Java Object Notation or JSON. If the UAV is able to follow the instructions received from the USS / UTM, an ACK message may be sent back to acknowledge. Either way, if the UAV is unable to follow the instructions from the USS, a feedback message may be sent back to report the misalignment.

[0051] A recent ASTM publication on remote ID of unmanned aerial vehicles also uses JSON and XML as the data transfer format. It is important to follow major regulatory and standardization committees for data transfer formats. An ACK message may be sent using JSON format as follows: A feedback message regarding a mismatch may be sent using JSON format as follows: Supplemental data may be added to provide additional information to the USS / UTM:

[0052] Figure 5B shows a TFR / NOTAM query (511) using an HTTP GET method to a USS (423) near Disneyland Park in California, and the HTTP-based NOTAM response with text transformation (513). In this case, the response shows information such as the NOTAM's latitude and longitude (514), radius (515), altitude (516), and effective date (517), which are important areas that indicate where and when UAV flight is restricted.

[0053] Referring to FIG. 6, an alternative embodiment may shift some of the computational burden from the UAV (601) to the controller (602). In this case, the controller (602) may access a memory (604) containing the (potentially updated) chart data and may perform the correlation described above based on location information (obtained by the on-board GPS (605) transmitted by the UAV (601) via a data link (610). The chart data may be updated to the USS (608) via its wireless network interface (605), a wireless network (606), such as a 5G interface, 5G network, or the Internet (607), using any suitable mechanism, including those described above. The results of the correlation (i.e., whether the flight is legal or illegal) may be made available locally at the controller (602) and communicated by the controller (602) to the human UAV pilot (609), for example, via a visual signal (light, not shown), a message on the controller's screen (611), a vibration alert, or other suitable mechanism. Since the controller (601) controls the UAV (601), the signal may also be visible by the UAV (601) itself, for example by an optical signal attached to the UAV (601) or by a UAV "Bob". Doing so has the advantage that the UAV pilot (609) can focus on the UAV (601) itself, rather than on the user interface of the controller (602).

[0054] Perhaps the UAV performs pre-flight checks, in particular chart data queries from national airspace charts, which may be saved to the UAV's on-board storage system. Referring again to Figure 4, the initially obtained chart information may be stored in storage (404) according to any of the mechanisms described above or any other suitable mechanism, and in the same or another embodiment, the results of the correlation process may be communicated to the UAV pilot (409).

[0055] The communication link between the UAV and the USS, be it a GPS antenna (403) or a wireless network interface (405), such as a 5G network interface, may use one or some combination of the following communication mechanisms: - stateful or stateless: stateful communication allows less data to be carried in future data exchanges. In a stateless approach, each interaction may contain the entire data payload; - Connection-oriented or connectionless: The choice of connection style may depend on the capabilities of the UAV system.

[0056] The frequency of querying for updated chart data while flying the UAV may depend on the configuration of the UAV's onboard system for power saving or storage (404) limitations. However, near real-time updates may be recommended since charts such as TFRs / NOTAMs may be issued without prior notice. As with ADS-B, 30 second updates may be sufficient.

[0057] The UAV pilot may not be particularly interested in the details obtained. Instead, the UAV pilot may be more interested in an indication of when the flight of the UAV is or has become illegal. The UAV may then perform one or more maneuvers, such as staying stationary, holding heading, deviating from the original flight path, returning immediately to base, crashing immediately, or other appropriate instructions from the USS or ATC.

[0058] Now referring to FIG. 7, in the current 3GPP 5G wireless architecture, the service enabler architecture layer for verticals (SEAL) provides procedures, information flows, and APIs to support vertical applications on the 3GPP system and ensures efficient use and deployment of vertical applications on the 3GPP system. SEAL services include group management, configuration management, location management, identity management, key management, and network resource management. The UAS application enablement (UAE) layer provides UAE functionality to UAE application specific layers. The UAE layer may include a UAE client (701) and a UAE server (703). The UAE client and the UAE server communicate with each other over the 3GPP network using the U1-AE (702) reference point.

[0059] Immediately underlying SEAL services utilized by the upper UAE layer may include location management, group management, configuration management, identity management, key management, and network resource management.

[0060] The SEAL Client (704) communicates with the SEAL Server (707) through the 3GPP network via the SEAL-UU (705) reference point. The SEAL-UU (705) supports both unicast and multicast delivery modes. The SEAL Client (701) provides the Service Enablement Layer support function to the UAE Client (701) via the SEAL-C reference point (710). The UAE Server (703) communicates with the SEAL Server (707) via the SEAL-S (708) reference point. The SEAL Server (706) can communicate with the underlying 3GPP Core Network system using the respective 3GPP Interfaces (706) specified by the 3GPP Network system.

[0061] The reference point (706) may include functions such as, but are not limited to, a network resource management server communicating with a PCRF (3GPP Policy and Charging Rules Function) or a network resource management server communicating with a PCF (3GPP 5G Policy Control Function) to control unicast and multicast resources from the underlying 3GPP network system.

[0062] The unmanned aircraft system communication techniques described throughout may be implemented in both the controller and the UAV as computer software using computer readable instructions and physically stored on one or more computer readable media. For example, Figure 8 illustrates a computer system 800 suitable for implementing certain embodiments of the disclosed subject matter.

[0063] The computer software may be coded using any suitable machine code or computer language that may be subject to assembly, compilation, linking, or similar mechanisms to create code containing instructions, which may be executed in microcode, either directly or through interpretation, such as by execution by a computer central processing unit (CPU), graphics processing unit (GPU), etc.

[0064] The instructions may be executed on various types of computers or components thereof including, for example, personal computers, tablet computers, servers, smart phones, gaming devices, Internet of Things devices, etc.

[0065] 8 are exemplary in nature and are not intended to suggest any limitation on the scope of use or functionality of the computer software implementing the embodiments of the present disclosure, nor should the arrangement of components be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary embodiment of computer system 800.

[0066] The computer system 800 may include certain human interface input devices that may respond to input by one or more human users through, for example, tactile input (keystrokes, swipes, data glove movements, etc.), audio input (voice, clapping, etc.), visual input (gestures, etc.), and olfactory input (not shown). The human interface devices may also be used to capture certain media that are not necessarily directly associated with conscious human input, such as audio (voice, music, ambient sounds, etc.), images (scanned images, photographed images obtained from a still camera, etc.), and video (two-dimensional video, three-dimensional video including stereoscopic video, etc.).

[0067] The input human interface devices may include one or more of a keyboard 801, a mouse 802, a trackpad 803, a touch screen 810, a data glove 804, a joystick 805, a microphone 806, a scanner 807, a camera 808 (only one depicted).

[0068] The computer system 800 may also include certain human interface output devices. Such human interface output devices may stimulate one or more of the human user's senses, for example, through haptic output, sound, light, and smell / taste. Such human interface output devices may include haptic output devices (e.g., haptic feedback via a touch screen 810, data gloves 804, or joystick 805, although there may also be haptic feedback devices that do not function as input devices), audio output devices (speakers 809, headphones (not shown), etc.), visual output devices (such as screens 810, including CRT screens, LCD screens, plasma screens, OLED screens, each with or without touch screen input capability and with or without haptic feedback capability, some of which may provide two-dimensional visual output or three or more dimensional output via means of stereographic output, virtual reality glasses (not shown), holographic displays, smoke tanks (not shown), etc.), and printers (not shown).

[0069] The computer system 800 may also include human accessible storage devices and their associated media such as optical media including CD / DVD ROM / RW 820 or similar media 821 including CDs / DVDs, thumb drives 822, removable hard drives or solid state drives 823, legacy magnetic media such as tapes and floppy disks (not shown), specialized ROM / ASIC / PLD based devices such as security dongles (not shown), and the like.

[0070] Those skilled in the art should also understand that the term "computer-readable medium" as used in connection with the presently disclosed subject matter does not include transmission media, carrier waves, or other transitory signals.

[0071] The computer system 800 may also include interfaces to one or more communication networks. The networks may be, for example, wireless, wired, optical. The networks may further be local, wide area, metropolitan, vehicular and industrial, real-time, delay tolerant, etc. Examples of networks include local area networks such as Ethernet, cellular networks including WLAN, GSM, 3G, 4G, 5G, LTE, etc., TV wired or wireless wide digital networks including cable TV, satellite TV, terrestrial broadcast TV, vehicular and industrial including CANBus, etc. Certain networks typically require an external network interface adapter connected to a specific general-purpose data port or peripheral bus (849) (e.g., a USB port on the computer system 800, etc., while others are typically integrated into the core of the computer system 800 by connecting to a system bus as described below (e.g., an Ethernet interface to a PC computer system or a cellular network interface to a smartphone computer system)). Using any of these networks, the computer system 800 may communicate with other entities. Such communications may be unidirectional, receive only (e.g., broadcast TV), unidirectional transmit only (e.g., from the CANBus to a particular CANBus device), or bidirectional (e.g., to other computer systems using local or wide digital networks). Specific protocols and protocol stacks may be used with each of these networks and network interfaces, as described above.

[0072] The aforementioned human interface devices, human accessible storage devices, and network interfaces may be connected to core 840 of computer system 800 .

[0073] The core 840 may include one or more central processing units (CPUs) 841, graphics processing units (GPUs) 842, specialized programmable processing units in the form of field programmable gate arrays (FPGAs) 843, hardware accelerators 844 for specific tasks, etc. These devices may be connected via a system bus 848, along with read only memory (ROM) 845, random access memory 846, internal mass storage 847 such as an internal non-user accessible hard drive, SSD, etc. In some computer systems, the system bus 848 may be accessible in the form of one or more physical plugs to allow expansion with additional CPUs, GPUs, etc. Peripheral devices may be connected directly to the core's system bus 848 or via a peripheral bus 849. Peripheral bus architectures include PCI, USB, etc.

[0074] The CPU 841, GPU 842, FPGA 843, and accelerator 844 may combine to execute certain instructions that may constitute the aforementioned computer code. That computer code may be stored in ROM 845 or RAM 846. Persistent data may be stored, for example, in internal mass storage 847, while transitory data may also be stored in RAM 846. Fast storage and retrieval to any memory device may be enabled using cache memory, which may be closely associated with one or more of the CPU 841, GPU 842, mass storage 847, ROM 845, RAM 846, etc.

[0075] The computer-readable media can have computer code thereon for performing various computer-implemented operations. The media and computer code can be those specially designed and constructed for the purposes of the present disclosure, or they can be of the kind well known and available to those skilled in the computer software arts.

[0076] By way of example and not by way of limitation, the architecture 800, and in particular a computer system having the core 840, may provide functionality as a result of a processor (including a CPU, GPU, FPGA, accelerator, etc.) executing software embodied in one or more tangible computer-readable media. Such computer-readable media may be user-accessible mass storage devices as introduced above, as well as media associated with specific storage devices of the core 840 that are non-transitory in nature, such as the core internal mass storage device 847 or the ROM 845. Software implementing various embodiments of the present disclosure may be stored in such devices and executed by the core 840. The computer-readable media may include one or more memory devices or chips according to specific needs. The software may cause the core 840, and in particular the processor therein (including a CPU, GPU, FPGA, etc.) to perform certain processes or certain parts of certain processes described herein, including defining data structures stored in the RAM 846 and modifying such data structures according to processes defined by the software. Additionally or alternatively, a computer system may provide functionality as a result of logic hardwired or otherwise embodied in circuitry (e.g., accelerator 844) that may operate in place of or together with software to perform certain processes or portions of certain processes described herein. References to software may include logic, and vice versa, as appropriate. References to computer-readable media may include circuitry (such as an integrated circuit (IC)) that stores software for execution, circuitry that embodies logic for execution, or both, as appropriate. The present disclosure encompasses any suitable combination of hardware and software.

[0077] Now referring to FIG. 9, the UAV grouping functionality is managed by the SEAL Group Manager (GM) SIP Core (905), which enables group management operations for higher application layers.

[0078] The SEAL Network Resource Manager (NRM) (904) on the SEAL NRM Server (903) enables support for unicast and multicast network resource management for upper application layers.

[0079] As mentioned above, a camera (1) may be equipped on a UAV (901). Such media-related devices may be referred to as a UAV payload. Support for a media session between the UAV and other parties using network resources may be established. When such a session exists, the UAV payload may generate, transfer, or interact with data traffic with other parties. Events may be live video streaming, file transfer, remote media control, etc.

[0080] In most real-time media communications, a combination of SIP and SDP is used to initialize sessions and negotiate media parameters. Both protocols data are carried in the control plane before the actual media traffic passes through the network. SDP is primarily carried as a SIP payload that contains all media codec related parameters. The purpose of SDP is to convey information about the media streams and provide enough information to be able to join and participate in media sessions in a unicast scenario.

[0081] The Session Initiation Protocol (SIP) is a signaling protocol used to initiate, maintain, and terminate real-time sessions over Internet Protocol (IP) networks and mobile networks, such as 4G LTE or 5G networks.

[0082] The Session Description Protocol (SDP) is a protocol for describing media session parameters. It is also used to negotiate media capabilities between media session participants. It is typically used in SIP payloads. One of the important pieces of information carried in SDP is the potential bandwidth usage of a particular media stream. In UAV media-related payload use cases, knowledge of the bandwidth that the payload is going to use is important for resource allocation in the network.

[0083] In a 3GPP network, the SIP Core may be deployed to communicate with the 3GPP Core Network to initiate a PCC (Policy Control and Charging) function to request more network resources.

[0084] In most real-time media communications, a combination of SIP and SDP is used for session initialization and media parameter negotiation. Both protocol data are carried in the control plane before the actual media traffic passes through the network. SDP is mainly carried as a SIP payload that contains all media codec related parameters. The purpose of SDP is to convey information about the media streams and provide enough information to be able to join and participate in a media session in a unicast scenario.

[0085] One of the key pieces of information carried in the SDP is the potential bandwidth usage of a particular media stream. In UAV media-related payload use cases, knowledge of the bandwidth that the payload is expected to use is important for resource allocation in the 3GPP network.

[0086] The solution proposed here provides the ability to monitor UAV media sessions and improve session manageability based on information from the SDP.

[0087] The SEAL Network Resource Manager (NRM) (904) enables support for unicast and multicast network resource management for upper application layers.

[0088] The 3GPP SEAL layer supports SIP for session establishment. This solution addresses how to monitor and manage UAV media sessions using SEAL addresses with the following prerequisites: the UAV has established a SIP session between the UAV media payload and an external party such as a UAV-C or USS / UTM using the 3GPP core network; and SDP as a SIP payload for media description.

[0089] Once a SIP session is established and SDP is exchanged, the UAE server can be informed about how much bandwidth is required for this session.

[0090] The UAE server (902) can request network bandwidth resources (906) based on the SDP description of the SIP session by examining the bandwidth requirements.

[0091] If the SEAL NRM server (903) cannot accommodate the requested bandwidth resources (907), the SEAL NRM server (903) may choose to terminate the SIP session (908), otherwise (b) bandwidth may be allocated (909) and unicast traffic may commence (910).

[0092] Now referring to Figure 10, the UAE Server (1002) can request network resources (1006) for the UAV (1001). In this case, the SEAL NRM Server (1003) can evaluate the request (1007) and send a session bandwidth request (1008) to the SIP Core (1004). A PCC is initiated to the 3GPP CN network (1005) for more resources (1009).

[0093] The SIP core can send a recourse request status (1010) back to the SEAL NRM server. If the requested resources cannot be allocated, the UAE server can decide to measure the SIP session (1011), otherwise (b) unicast traffic is initiated (1012).

[0094] Now referring to FIG. 11, the UAV may be replaced and controlled by an existing UAC controller (UAV-C). Such replacement may be scheduled or unscheduled. Such UAV replacement events may cause network and service interruptions. The UAS may also connect to the USS / UTM using means of 3GPP network, WIFI, Internet, or other network approaches. Either way connected, the USS / UTM may only use one identifier to communicate with the UAS. When replacing the UAV, the ID associated with the UAS may also change to a new ID. The USS may lose control of the UAS due to the ID change. The UAV ID or RID is a critical component for a UAS to be considered safe to operate. In some cases, replacing the UAV with a UAS may change the UAV ID and cause network and service interruptions.

[0095] At the 3GPP UAE layer, the UAV ID can be used to request network resources via the SEAL. A 3GPP connected UAV can obtain a 3GPP UE ID upon successful connection. A 3GPP connected UAV must also register with the USS / UTM according to certain regulations using a pre-assigned or dynamically assigned CAA-level UAV ID as described above. In any case, after replacing a UAV, a new registration between the UAS and the 3GPP network or from the UAV to the USS / UTM may be required, which may affect how the SEAL provides certain services to the UAS. Registration of the UAV ID may occur when the UAV is replaced with a new CAA-level ID. In some cases, the following procedure may require re-establishing the connection between the USS and the UAV if the new UAV has a pre-assigned CAA-level ID.

[0096] After the UAV exchange in the UAS, the UAE Server (1102) recognizes that there is a UAV exchange using a pre-assigned CAA-level UAV ID. The UAE Server (1102) sends a registration request to the USS / UTM (1107) via the 3GPP network. The USS / UTM (1104) can send back a registration confirmation (1108).

[0097] The UAE server (1103) can start using the CAA level ID as a generic UAE layer user ID for requesting SEAL services.

[0098] However, depending on the establishment of a group ID using a previous pair of UAV and UAV-C, a group ID may be created with a new UAV. The producer of group creation for one pair of UAV and UAV-C is described below. First, both UAV-C (1101) and UAV (1103) may have successfully connected to the UAE server using a new UAV ID (1105).

[0099] The UAE server (1102) recognizes a unique pair of UAV and UAV-C (1106).

[0100] The UAE server sends a group creation request to the SEAL GM server (1104)us on the g GM-S reference link (1107).

[0101] The SEAL GM server may create one group ID for one pair of UAV and UAV-C (1108). In some cases, it may create subgroups for each UAV and UAV-C (1109).

[0102] The UAE server can use the returned group ID for QoS management. When subgroups of UAV and UAV-C are created, the UAE server can use the subgroup ID to manage the QoS of UAV and UAV-C individually (1110).

[0103] In some other cases, the new UAV may not have a pre-assigned CAA-level ID, and the USS / UTM can then dynamically assign a CAA-level UAV ID to the new UAV during the registration process (1111-1113).

[0104] 12, the UAE Server (1203) recognizes the UAV exchange without a pre-assigned CAA-level UAV ID. The UAE Server (1203) sends a registration request to the USS / UTM (1204) using the 3GPP network including the 3GPP UE ID (1205).

[0105] Now, in this case, the USS / UTM will return a registration confirmation that includes the new CAA-level ID assigned to this new UAV.

[0106] As before, a Group ID may be created if there was an existing Group ID for a previous pair of UAV (1202) and UAV-C (1201).

[0107] After the UAV exchange in the UAS, the UAE (1202) server recognizes that there is a UAV exchange using a pre-assigned CAA-level UAV ID. The UAE server (1202) sends a registration request to the USS / UTM (1207) via the 3GPP network. The USS / UTM (1204) may return a registration confirmation (1208).

[0108] The UAE server (1203) can start using the CAA level ID as a generic UAE layer user ID for requesting SEAL services.

[0109] However, depending on the establishment of a group ID using a previous pair of UAV and UAV-C, a group ID may be created with the new UAV. The producer of group creation for one pair of UAV and UAV-C is described below. First, both UAV-C (1201) and UAV (1203) may successfully connect to the UAE server using a new UAV ID (1205).

[0110] The UAE server (1202) recognizes a unique pair of UAV and UAV-C (1260).

[0111] The SEAL GM server may create one group ID for one pair of UAV and UAV-C (1208). In some cases, it may create subgroups for each UAV and UAV-C (1209).

[0112] The UAE server can use the returned group ID for QoS management. When subgroups of UAV and UAV-C are created, the UAE server can use the subgroup ID to manage the QoS of UAV and UAV-C individually (1210).

[0113] In some other cases, the new UAV may not have a pre-assigned CAA-level ID, and the USS / UTM can then dynamically assign a CAA-level UAV ID to the new UAV during the registration process (1211-1213).

[0114] 13, we will now describe the producer of group creation for one pair of UAV and UAV-C. First, both UAV-C (1301) and UAV (1303) may successfully connect to the UAE server using new UAV IDs (1305).

[0115] The UAE server (1302) recognizes a unique pair of UAV and UAV-C (1306).

[0116] The UAE server sends the group creation request to the SEAL GM server (1304)us on the g GM-S reference link (1307).

[0117] The SEAL GM server may create one group ID for one pair of UAV and UAV-C (1308). In some cases, it may create subgroups for each UAV and UAV-C (1309).

[0118] The UAE server can use the returned group ID for QoS management. When subgroups of UAV and UAV-C are created, the UAE server can use the subgroup ID to manage the QoS of UAV and UAV-C individually (1310).

[0119] Referring now to FIG. 14, an operational flow chart illustrating steps of a method 1400 for controlling an unmanned aerial vehicle (UAV) is shown.

[0120] At 1402, the method 1400 includes identifying data associated with the UAV to be communicated during handoff.

[0121] At 1404, the method 1400 includes notifying a service supplier of an operational status of the UAV based on the identified data.

[0122] At 1406, the method 1400 includes receiving instructions from a service supplier corresponding to an operation of the UAV.

[0123] It can be appreciated that Figure 14 is only intended to provide an illustration of one embodiment and is not intended to be a limitation on how different embodiments may be implemented Many modifications to the depicted environments can be made based on design and implementation requirements.

[0124] Some embodiments may relate to systems, methods, and / or computer-readable media at any possible level of technical detail integration. The computer-readable media may include a non-transitory computer-readable storage medium (or media) having computer-readable program instructions thereon for causing a processor to perform operations.

[0125] A computer-readable storage medium may be a tangible device capable of holding and storing instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random access memories (RAMs), read-only memories (ROMs), erasable programmable read-only memories (EPROMs or flash memories), static random access memories (SRAMs), portable compact disk read-only memories (CD-ROMs), digital versatile disks (DVDs), memory sticks, floppy disks, mechanically encoded devices such as punch cards or raised structures with instructions recorded in grooves, and any suitable combination of the foregoing. As used herein, a computer-readable storage medium should not be construed as a transitory signal itself, such as an electric signal transmitted over a wire, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electric signal transmitted over a wire.

[0126] The computer readable program instructions described herein can be downloaded from a computer readable storage medium to each computing / processing device or to an external computer or storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can be composed of copper transmission cables, optical transmission fiber, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface of each computing / processing device receives the computer readable program instructions from the network and transfers the computer readable program instructions to a computer readable storage medium within the respective computing / processing device for storage.

[0127] The computer readable program code / instructions for performing the operations may be source or object code written in any combination of assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state setting data, configuration data of an integrated circuit, or one or more programming languages ​​(such as object oriented programming languages ​​such as Smalltalk, C++, and procedural programming languages ​​such as the "C" programming language or similar programming languages). The computer readable program instructions may be executed completely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer, partially on a remote computer, or completely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN). Alternatively, the connection may be made to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can execute computer readable program instructions to perform aspects or operations by utilizing state information of the computer readable program instructions to personalize the electronic circuitry.

[0128] These computer readable program instructions can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing device to produce a machine, whereby the instructions, executed via the processor of the computer or other programmable data processing device, create means for performing the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams. These computer readable program instructions can be stored on a computer readable storage medium that can direct a computer, programmable data processing device, and / or other apparatus to function in a particular manner, whereby the computer readable storage medium having instructions stored therein includes an article of manufacture containing instructions that implement aspects of the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams.

[0129] The computer readable program instructions may be loaded into a computer, other programmable data processing device, or other apparatus to cause the computer, other programmable apparatus, or other apparatus to execute a series of operational steps to generate a computer-implemented process, whereby the instructions executing on the computer, other programmable apparatus, or other apparatus perform the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams.

[0130] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, which includes one or more executable instructions for implementing a specified logical function. The methods, computer systems, and computer-readable media may include additional, fewer, different, or differently arranged blocks than those shown in the figures. In some alternative implementations, the functions shown in the blocks may differ from the order shown in the figures. For example, two blocks shown in succession may in fact be executed simultaneously or substantially simultaneously. Alternatively, the blocks may be executed in reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a special purpose hardware-based system that performs the specified functions or operations, or executes a combination of dedicated hardware and computer instructions.

[0131] It will be apparent that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specific control hardware or software code used to implement these systems and / or methods is not intended to limit the implementation. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It will be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

[0132] No element, act, or instruction used herein should be construed as critical or essential unless expressly described as such. Also, as used herein, the article "a" or "an" is intended to include one or more items and may be used interchangeably with "one or more." Additionally, as used herein, the term "set" is intended to include one or more items (e.g., related items, unrelated items, combinations of related and unrelated items, etc.) and may be used interchangeably with "one or more." When only one item is intended, the term "a" or similar language is used. Also, as used herein, terms such as "has, have, having" are intended to be open-ended terms. Additionally, the phrase "based on" is intended to mean "based at least in part on," unless otherwise specified.

[0133] The description of various aspects and embodiments is presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. Even if combinations of features are recited in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of possible embodiments. Indeed, many of these features can be combined in ways not specifically recited in the claims and / or disclosed in the specification. Although each dependent claim listed below may directly depend on only one claim, the disclosure of possible embodiments includes each dependent claim in combination with all other claims within the scope of the claims. Many modifications and variations will be apparent to those skilled in the art without departing from the scope of the described embodiments. The terms used in this specification have been selected to best explain the principles of the embodiments, practical applications or technical improvements to the technology found in the market, or to enable those skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for controlling an unmanned aerial vehicle (UAV), the method comprising: a processor on board the UAV identifying data associated with the UAV to be communicated during handoff; The processor notifying a service supplier of an operational status of the UAV based on the identified data; a UAS Application Enablement (UAE) server notifying the service supplier regarding an update of an identification (ID) corresponding to the UAV, the update of the ID including an instruction to replace the UAV with the second UAV that is a group pair between the second UAV and a UAV controller (UAV-C); the UAE server receiving a new ID from the service supplier; The method includes: a SEAL Group Manager (GM) server maintaining and updating group management information associated with the UAV in the group pair by exchanging an identifier of the second UAV with an identifier of the UAV, the updated group management information indicating that the UAV and the UAV-C are the group pair; and a processor controlling movement operations of the UAV based on instructions sent to the UAV from the service supplier according to the updated group management information. method.

2. The identified data includes: A current location associated with the UAV; A current altitude associated with the UAV; A current speed associated with the UAV; A list of equipment associated with the UAV; and A power setting associated with the UAV.

3. the processor identifying one or more problematic operating parameters based on the identified data; The method of claim 1 , further comprising the step of: the processor notifying the service supplier of a command violation corresponding to the problematic operating parameter.

4. The step of the processor notifying the service supplier of the instruction violation includes: the processor comparing data collected on board the UAV with information received from the service supplier; The method of claim 3 , further comprising the step of: the processor notifying the service supplier of an operational inconsistency based on the compared data.

5. The information received from the service supplier includes: Advanced Report, Speed ​​report, GPS location report, Output report, and An airspace report.

6. said UAE server interpreting bandwidth parameters; the UAE server managing session establishment and termination; the UAE server requesting network resources; The method of claim 1 , further comprising the step of the UAE server enabling session control within network bandwidth constraints.

7. An unmanned aerial vehicle (UAV), comprising: one or more non-transitory computer readable storage media configured to store computer program code; one or more computer processors configured to access the computer program code and to operate as instructed by the computer program code; The computer program code, when executed by the one or more computer processors, causes the one or more computer processors to:

7. Carrying out the method according to any one of claims 1 to 6, Unmanned aerial vehicle (UAV).

8. 1. A computer program for controlling an unmanned aerial vehicle (UAV), the computer program, when executed by one or more computer processors, causing the computer processors to:

7. Carrying out the method according to any one of claims 1 to 6, Computer program.

Images