An Unmanned Aerial Vehicle Control Method, Control Device, Computer-Readable Medium, and Computer Device

Abstract

A drone and its control method are provided. Data associated with the drone to be transmitted during a handover is identified. Based on the identified data, the service provider is notified of the operating state of the drone. An instruction corresponding to the operation of the drone is received from the service provider.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 052,170, filed on July 15, 2020; No. 63 / 052,145, filed on July 15, 2020; No. 63 / 112,543, filed on November 11, 2020; No. 63 / 112,549, filed on November 11, 2020; No. 63 / 115,973, filed on November 19, 2020; and U.S. Patent Application No. 17 / 323,458, filed on May 18, 2021, the entire contents of which are incorporated herein by reference. Technical Field

[0003] The present disclosure generally relates to the field of aircraft technology, and more particularly to a method and apparatus for controlling an unmanned aerial vehicle, a computer - readable medium, and a computer device. Background Art

[0004] Unmanned aerial vehicles (UAVs) have become relatively easy to fly, which in turn has made them popular not only among professional UAV pilots and committed and wealthy hobbyists, but also among the general public. As a result, millions of UAVs are sold each year, compared to a few thousand, if that many, model helicopters about 15 years ago. At the same time, on average, the knowledge, proficiency, and level of engagement of the user community have decreased.

[0005] Currently, there is no mechanism for a UAV system to have the functions of selecting a service provider, handling service switching when switching service providers, detecting flight rule deviations, and / or reporting back to a UAS service provider (USS / UTM). Therefore, there is an urgent need in the art for an effective method of communicating with USS / UTM to improve the safety during UAV operation by specifying how to transmit information and the content of the transmitted information, and identifying key factors violating flight rules. Summary of the Invention

[0006] 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 transmitted during a handover. Notifying a service provider of the operating state of the unmanned aerial vehicle based on the identified data. Receiving an instruction corresponding to the operation of the unmanned aerial vehicle from the service provider.

[0007] According to another aspect, a control device for an unmanned aerial vehicle (UAV) is provided. The control device of the unmanned aerial vehicle may include one or more processors, one or more computer-readable memories, one or more computer-readable tangible storage devices, and program instructions stored on at least one of the one or more storage devices, the program instructions being for execution by at least one of the one or more processors via at least one of the one or more memories, whereby the unmanned aerial vehicle is capable of performing a method. The method may include identifying data associated with the unmanned aerial vehicle to be transmitted during a handover. Notifying a service provider of the operating state of the unmanned aerial vehicle based on the identified data. Receiving instructions corresponding to the operation of the unmanned aerial vehicle from the service provider.

[0008] 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 on 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 perform a method, which may correspondingly include identifying data associated with the unmanned aerial vehicle to be transmitted during a handover. Notifying a service provider of the operating state of the unmanned aerial vehicle based on the identified data. Receiving instructions corresponding to the operation of the unmanned aerial vehicle from the service provider.

[0009] Thus, the UAV and its control method provided by the embodiments of the present application can enable the UAV system to have functions of selecting a service provider, handling service handover when switching service providers, detecting flight rule deviations, and / or reporting back to the UAS service provider (USS / UTM). By specifying how to transmit information and the content of the transmitted information, and identifying key factors violating flight rules, the present application can improve the safety during UAV operation. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] These and other objects, features and advantages will become apparent from the following detailed description of illustrative embodiments to be read in conjunction with the accompanying drawings. The various features of the drawings are not to scale as the illustrations are for clarity purposes to assist those skilled in the art in understanding in conjunction with the detailed description. In the drawings:

[0011] Figure 1 is a schematic diagram of an unmanned flight system;

[0012] Figure 2 is a schematic diagram of an unmanned flight system communicating with a UAS service system;

[0013] Figure 3 is a schematic diagram of a UAV chart;

[0014] Figure 4A is a schematic diagram of a UAS according to one embodiment of the present application;

[0015] Figure 4B is a schematic diagram of a UAS according to another embodiment of the present application;

[0016] Figure 4C is a schematic diagram of a UAS according to yet another embodiment of the present application;

[0017] Figure 5A is a schematic diagram of RESTful position query and JSON reply according to one embodiment of the present application;

[0018] Figure 5B is a schematic diagram of HTTP query and HTML reply according to one embodiment of the present application;

[0019] Figure 6 is a schematic diagram of a UAS according to yet another embodiment of the present application;

[0020] Figure 7 is a schematic diagram of the workflow and reference points of UAE (UAS Application Enabler) and SEAL architecture according to one embodiment of the present application;

[0021] Figure 8 is a schematic diagram of a computer system according to one embodiment of the present application;

[0022] Figure 9 shows the high-level process of SIP session management based on network resource requirements;

[0023] Figure 10 shows the high-level process of the SEAL-NRM server requesting additional bandwidth for a specific SIP session;

[0024] Figure 11 shows the high-level process of using the SEAL group manager for UAV CAA-level IDs;

[0025] Figure 12 shows another high-level process of using the SEAL group manager for UAV CAA-level IDs;

[0026] Figure 13 shows the high-level process of creating a UAV group using the SEAL group manager; and,

[0027] Figure 14 is a flowchart of operations according to one embodiment of the present application, showing the steps performed by a program for controlling an unmanned aerial vehicle (UAV). Detailed implementation manners

[0028] In this document, detailed implementation manners of the claimed structures and methods are disclosed; however, it can be understood that the disclosed implementation manners are only illustrations of the claimed structures and methods that can be implemented in various forms. However, these structures and methods can be implemented in many different forms and should not be construed as limited to the exemplary implementation manners set forth herein. On the contrary, these exemplary implementation manners are provided so that this disclosure will be thorough and complete and will fully convey the 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 implementation manners.

[0029] As mentioned above, UAVs have become rather easy to fly, which in turn has made them popular not only among professional UAV pilots and committed and wealthy enthusiasts, but also among the general public. As a result, millions of UAVs are sold each year now, compared to a few thousand, if that many, model helicopters about 15 years ago. However, there is currently no mechanism for a UAV to select a service provider, handle service switching when switching to a different service provider, detect flight rule deviations, or report back to a UAS service provider (USS / UTM). Therefore, it may be advantageous to specify how information is transmitted and the content of the transmitted information, identify key factors for violating flight rules, and provide technical methods for communicating with the USS / UTM to enhance safety during UAV operation.

[0030] 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 in 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.

[0031] All UAVs, except perhaps the smallest ones, can pose a hazard to manned aircraft, not only through mid-air collisions, but also due to pilot distraction, saturation of Air Traffic Control (ATC) resources, etc. The possible presence of thousands of UAVs flying in combination on some days, and (on average, and when compared to the pilots of manned aircraft) the less skilled, less educated, less informed, and occasionally reckless UAV pilots, have led to millions of dollars being spent on aborted takeoffs, approach failures, diversions, grounding of manned aircraft, property damage from wildfires that cannot be extinguished by manned aircraft resources, etc. It has been reported that mid-air collisions between amateurly flown UAVs and helicopters can endanger lives. For these and other reasons, regulatory bodies, including the International Civil Aviation Organization (ICAO) of the United Nations and the Federal Aviation Administration (FAA) of the United States, have begun to regulate UAVs, including smaller UAVs weighing less than 55 pounds. Heavier UAVs have historically been regulated.

[0032] In the United States, one aspect of such regulations is the requirement to carry a "remote pilot certificate" when pilots conduct essentially all commercial (for-hire) UAV operations. This certificate is not primarily about the mechanical aspects of flying a UAV, but rather about the understanding and compliance with regulations including, for example, airspace, flight restrictions, etc. While commercial remote pilots can become aware of their obligations regarding compliance with the rules and regulations (including airspace) for UAV operations by obtaining the certificate, hobbyists may not be fully aware. UASs have become so inexpensive and easy to operate that the historical means of qualification through model aircraft clubs and similar organizations no longer works reliably. For example, large numbers of UAVs are being operated by individuals who have never been members of such clubs and may never have studied the relevant regulations, away from the airfields maintained by model aircraft clubs, let alone received a briefing on the current layout of the airspace.

[0033] Another aspect of the regulations proposed includes identifying the UAV and its flight to ATC, other UAVs, etc. In the United States, the FAA has issued "Proposed Rules" (https: / / www.federalregister.gov / documents / 2019 / 12 / 31 / 2019-28100 / remote-identification-of-unmanned-aircraft-systems). When substantially all UASs are implemented, the proposed rules will give ATC a certain insight into UAV activities in a timely manner at any given moment. If the reporting mechanism between the UAS and the system interfacing with ATC - called UAV Service Suppliers (USS) - is inactive during UAV flight, the proposed rules also require the UAS to be equipped to notify the pilot. However, contrary to many operations of manned aircraft in controlled airspace - which require the flight crew to make (voice) contact with ATC, transmit transponder codes, etc. - such a requirement is not envisioned in the proposed rules and is not likely to be practical without a significant increase in ATC resources. As it stands, although the FAA may be able to obtain a certain amount of real-time knowledge of active UAV operations through USS, the "Proposed Rules" do not envision influencing the flight of UAVs directly (through technical means) or indirectly (through communication with the pilot) by ATC. Instead, the goal of the proposed rules is to inform ATC of UAV operations relevant to ATC's mission.

[0034] Reference Figure 1 , a Unmanned Aerial System (UAS) can include an Unmanned Aerial Vehicle (UAV) (101) and a controller (102). The controller (102) can use a data link (103) to transmit control commands from the controller (102) to the UAV (101). In its simplest form, the controller can be a VHF, UHF or other wireless technology analog or digital radio device for transmitting, for example, power levels to the engine (104) of the unmanned aerial vehicle or the control interface (not depicted) of a model aircraft. More abstract commands similar to those of a helicopter or an aircraft, such as pitch, yaw and roll, can also be used. Experienced pilots can use these basic controls to operate some UAVs without relying on any advanced onboard processing of the UVA internal control signals. In the form of model helicopters and aircraft, such UAVs have been available for decades.

[0035] Recent advancements in airborne electronics design have allowed certain tasks to be transferred from human operators to the UAV itself. Today, many UAVs include sensors (104) that indicate, for example, the attitude and acceleration of the UAV to the on-board controller circuitry (105). The on-board controller can be a computer system with a scaled-down or non-existent user interface. In addition to control inputs from the controller (102) received via the data link (103), the information obtained by the sensors (104) enables the UAV to remain stable unless a positive control input is received from the controller.

[0036] Even more recently, UAVs can include a receiver (106) for one of the Global Navigation Satellite Systems (GNSS), such as the Global Positioning System (GPS) operated by the United States (a signal (107) from a single satellite (108) is shown here, although at least three and typically four or more line-of-sight satellites are used to triangulate the position of the UAV in space). The GNSS receiver can determine the position of the UAV in space and time with reasonable accuracy. In some UAVs, in many cases, the GNSS can be enhanced by additional sensors (such as ultrasonic or lidar sensors) on the most critical vertical (Z-) axis to enable a soft landing (not depicted). Some UAVs (101) with GNSS capabilities provide users with "fly home" and "automatic landing" features, where the UAV will fly to a location defined as its home position upon a very simple command from the controller (102) (e.g., a single button press) or in the event of a loss of the controller's data link (103) or other meaningful control input timeout. The receiver 106 can also be configured to detect the position via a cellular network such as 3G, 4G, or 5G or via Wi-Fi Internet access.

[0037] As another recent development, some UAVs also include at least one camera (109). In some UAVs, a gimbal-mounted camera can be used to record pictures and videos of sufficient quality to satisfy the use of UAV users - today, typically high-definition television resolution is employed. Some UAVs include additional cameras (110) that generally cover some or all of the axes of movement and use on-board signal processing based on these camera signals to avoid collisions with stationary and moving objects.

[0038] In some UAVs, the camera signal of the "main" camera (109) can be transmitted to a human user in real time (111) and displayed on a display device (112) included in, attached to, or separate from the controller (102). This technically enables the UAV to successfully fly out of the sight of a human pilot using a technique called "first-person view" or FPV.

[0039] Reference Figure 2 , an option for a UAS (including a UAV (201) and a controller (202)) may be operated by a human pilot (203) to notify one or more USSs (204) (only one is depicted) in real time about the location of the UAV (201) according to "proposed rules". Reporting may be done using the Internet (205). For all uses, except for the most exotic uses involving tethered UAVs, this means a wireless Internet connection (206) via a wireless network such as a 5G network (207) to the UAS (UAV (201), controller (202), or both), and the USS (204) also has an Internet connection (208). Such a scenario may be assumed in the proposed rules and is also assumed herein. However, other networks besides the Internet (205) may also be used. For example, it is conceivable that a closed wireless network other than the Internet may be used for communication between the UAS and the USS. This is what is used for some military UAVs today. When "Internet" is mentioned hereafter, it means including such networks.

[0040] Many physical wireless network technologies have been proposed, deployed, and / or are being used, which enable the wireless Internet connection (206) and the wireless network (207) to connect systems such as a UAS controller (202) or a UAV (201) to the Internet (205). For outdoor applications, one option may be to use a mobile network, such as their most recent incarnation known as the fifth generation or "5G" network. Hereafter, it is assumed that such a 5G network is used. However, other physical network technologies may also be employed, including, for example, 3G, 3.5G, 4G, LTE mobile networks, wireless LANs in infrastructure or ad-hoc mode, zig-bee, etc. In the context of the present disclosure, a mobile network carrying the Internet may provide two-way communication, such as two-way communication from the UAS to the USS. However, the quality of service in each direction may be different.

[0041] From Figure 2A key observation that can be made is that the link (206) between the Internet (205) and the UAV (201) or the controller (202) via the 5G network (207) can be bidirectional. When Internet protocols such as IP, TCP, UDP, HTTP, QUIC, etc. are used for communication between the UAS and the USS (as envisaged by the proposed rules), then, by the nature of these protocols, a bidirectional link may be necessary for these protocols to work. In addition, the proposed rules include the following requirement: it is assumed that the human pilot (203) is notified of the loss of communication between the UAS and the USS (204) by the controller (202) or the UAV (201) itself, which may most easily be achieved via the data link between the USS (204) and the UAS - which in turn implies a bidirectional link (206). For these reasons, it is henceforth assumed that the link 206) is bidirectional.

[0042] Aviation traffic control (ATC) agencies, such as the FAA, or government or private agencies or entities responsible by the ATC agency, have not only issued regulations but also various forms of graphical, textual, or oral information on the airspace layout for (manned and unmanned) aircraft operations for decades. Historically, at different times, the relevant information has been provided in the form of printed charts, weekly publications, and textual information, by fax, or read over the phone or in person by flight service specialists. In most countries, including the United States, the relevant information can now be obtained via the Internet, even from various sources. Regarding the disclosed subject matter, the relevant information can be at least the following information:

[0043] Charts: There are many different types of flight charts in different countries and for different purposes (low / high altitude, visual / instrument flight rules, planning, etc.). For the operation of small UAVs, particularly relevant are the "sectional charts" in the United States and the "Low Altitude Authorization and Notification Capability" ("LAANC") information, which is displayed in the form of charts on a web browser. The charts are updated over a relatively long period (e.g.; VFR sectional charts: every six months). For manned aircraft, "valid" charts are required.

[0044] Reference Figure 3, shows an excerpt of a sectional chart centered on Livermore Airport (301) in California. It should be noted that sectional charts are in color and the colors have meaning; however, black and white as used herein is sufficient to illustrate the difficulties that recreational UAV pilots may have in interpreting sectional charts. The dashed circle (about 8 miles in diameter) around the airport (302) represents "Class D" airspace at certain times (when the runway at Livermore Airport is open), which may mean that (manned) aircraft operations are not permitted within this circle up to a certain altitude without prior approval from ATC. Historically, the same rules applied to UAVs, making UAVs illegal in most of the Livermore Township (east / right side of Livermore Airport) and surrounding areas.

[0045] Recognizing that the requirements for manned aircraft operations may be overly restrictive for recreational unmanned aircraft, the FAA has recently allowed recreational unmanned aircraft to fly in certain parts of controlled airspace. Still referring to Figure 3 , shows a screenshot of a "UAV Chart" electronically published by the FAA via the Internet and displayed in a web browser. Again, the colors in these charts are important, but black / white representation is sufficient to show the important aspects of the chart. The 8-mile circle around Livermore Airport is shown again, depicted in blue in the original chart. The area covered by the circle (representing controlled airspace) is covered by rectangular blocks, such as block 305. Each such block is approximately one square mile in size. Each block contains a number representing the maximum allowable altitude at which a UAV is permitted to fly within the block without prior permission. A mechanism (in the form of an application) is in place to allow certain UAV operators to obtain permission to fly above the upper limit by referring to the block identifier.

[0046] Notice to Airmen (NOTAM): These text notifications follow internationally recognized standardized formats and are written in plain English. They can be quickly issued within minutes or hours, which is different from charts with update cycles measured in weeks and months. However, their effective times can vary from a few hours to "indefinitely" or "until further notice". One of the many uses of NOTAMs can be to update certain aspects of charts. For example, a flight chart may include information about navigational obstacles such as tall towers. When a temporary crane is erected above a certain threshold (determined by, among other factors, the proximity of the site to the approach path of an existing airport), it may pose a navigational hazard, and therefore its presence, location, height, and expected duration of presence are provided in the form of a NOTAM. An example of a NOTAM notifying of the presence of a crane near an airport (San Carlos, KSQL) may be as follows:

[0047] KSQL San Carlos

[0048] ! SQL 10 / 003 SQL OBST Crane (ASN 2018 - AWP - 13591 - OE) 372917N1221327W (1.9NMSE SQL) 309 feet (300 feet AGL) Mark and LGTD 1910072355 - 2001312159

[0049] Created: 2019 / 10 / 7 23:55:00

[0050] Source: SQL

[0051] Temporary Flight Restrictions (TFR): A TFR is a form of NOTAM that can inform pilots or aircrews of airspace areas where special ATC clearances may be required to enter. TFRs can be well - publicized in advance (e.g., over areas covering long - planned sporting events), or issued in real - time (e.g., in the case of wildfires). Shown below are examples of TFRs that may be related to fires or similar hazards; the TFRs are only valid for one hour:

[0052] FDC 9 / 1767ZMP MN.. Airspace Hibbing, MN.. Temporary Flight Restriction WIAN Area defined as 2NM radius 472601N0930200W (Hibbing VOR / DME HIB299015.6)

[0053] SFC - 4500 feet Blasting. Temporary flight restrictions are in effect according to 14 CFR Section 91.137(A)(1). Only rescue operations under the direction of Hibbing Taconite Company are authorized in the airspace. Hibbing Taconite Company phone 218 - 262 - 5940 is responsible for on - site emergency response operations.

[0054] Minneapolis / ZMP / ARTCC phone 651 - 463 - 5580 is the FAA CDN facility.

[0055] 2001031630 - 2001031730

[0056] In the United States and many other countries, all of the above information can be obtained in digital format. In the United States, this access can be free. The data format of the above information is standardized, public, and rather compact. All of the above US data related to a given day can just fit into 16GB.

[0057] The FAA has transformed the NAS into Performance Based Navigation (PBN), which mainly uses satellite navigation in the form of the Global Navigation Satellite System (GNSS). GPS (Global Positioning System) is one method of GNSS. It is a system for global navigation and surveying. The GPS system uses geographical lines of latitude and longitude to provide the coordinates of a person's location or a location of interest. Latitude lines are horizontal lines that extend across the globe from east to west. The longest and main line of latitude is called the equator. The equator is represented as 0° latitude. Longitude lines are vertical lines that extend from the North Pole to the South Pole. The main line of longitude is called the prime meridian. The prime meridian is represented as 0° longitude. Most locations on Earth do not lie along latitude lines or longitude lines, but within the shape created by the intersection of horizontal and vertical lines.

[0058] To accurately locate humans on the Earth's surface, latitude lines and longitude lines are further divided and represented in one of three common formats: degrees, minutes, and seconds (DMS). A common way to represent GPS coordinates can be in the format using a pair of latitude (N / S) and longitude (E / W). North (N) / South (S) can be placed at the end of each DMS to indicate whether it is north or south of the equator. East (E) / West (W) can be placed at the end of each DMS to indicate whether it is to the left or right of the prime meridian. The space between each latitude line or longitude line representing 1° is divided into 60 minutes, and each minute is divided into 60 seconds. A specific example might be something like (25°24′10.1″N, 20°15′16.5″E).

[0059] It has been pointed out that it is difficult to interpret airspace using traditional methods designed for manned aircraft and requires a certain amount of training. Although the FAA is increasingly producing simplified charts (such as UAV Chart 303), applications, and other tools designed for non - professionals, even those tools are still difficult to operate and, perhaps more importantly, require UAV pilots to actually consult them before flying his / her UAV. Many recent incidents related to UAVs in controlled airspace clearly show that not all UAV pilots do so.

[0060] In addition, especially for relatively small UAVs, it is difficult for untrained (or even trained) UAV pilots to measure the altitude at which their UAV is flying. For example, how does a UAV pilot know if his / her small UAV is at 90 feet in altitude (which may be legal in some areas indicated by UAV charts) or 110 feet (which may be illegal)? Technical means built into the UAV (201) or the controller (202) can help solve either problem.

[0061] ReferenceFigure 4A In an embodiment, in addition to most user interface components, the UAV (401) can be equipped with an embedded computer system (402). The embedded system can advantageously (for reasons of space and weight) be part of or integrated into the on-board flight control circuitry of the UAV. The system (402) can have a mechanism for obtaining its position in three-dimensional space. Illustrated here is a GPS antenna (403), which together with a GPS receiver can be an example of such a mechanism. Other mechanisms can be a combination of GPS with (possibly more precise) barometric altitude sensors, a triangulation mechanism for determining lateral position from ground-based navigation aids (VOR, mobile phone towers, etc.), and so on. The UAV (401) can also include a storage mechanism (404) accessible to the user of the UAV. As an example, a micro SD card (404) is depicted here. However, the memory can also be other volatile semiconductor memories, on-board NV-RAM in the UAV accessible from a computer via a network plug or a wireless LAN, and so on.

[0062] The memory (404) can be of sufficient size and can store information about the airspace in which the UAV can operate. Such information can include digital representations of charts, NOTAMs, TFRs, etc. The digital information can be interpreted by the embedded computer system and can be related to the position of the unmanned aerial vehicle in three dimensions (including lateral position and altitude). The result of the correlation process can be that the UAV is "legally flying" or "not legally flying" in the airspace it currently occupies. Optionally, other results are possible, such as "legally flying but close to the legal airspace boundary", "legally flying but will be illegal in 10 seconds if the heading does not change", etc.

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

[0064] To minimize storage requirements, the digital information can be restricted such that it is only related to certain areas. For example, the digital information can only contain chart data within a 100-mile radius around the expected flight locations that the user (405) can pre-select when downloading chart data to the memory (404).

[0065] In the same or another implementation, the results of the relevant process can be transmitted to the UAV pilot (407). One possible option could be to use the data link (410) between the UAV and the controller to transmit a signal encoded with the relevant results, and to notify the pilot (407) via the controller or the UAV with a tactile, visual, text, or auditory warning. For example, the pilot can be notified by vibration of the controller (409), a visual signal such as a warning light (not depicted), an auditory warning sound played through a speaker (not depicted), or a message that can be attached to the screen (408) of the controller. It is presumed that the data link (410) is available because it may be required under the proposed FAA rules anyway. However, if for any reason such a data link is not available, the UAV can alternatively or additionally include an onboard mechanism that allows the UAV to notify the pilot of the results of the relevant process. For example, the UAV can include a speaker or a ground-visible warning light. As another example, the UAV can "wiggle" (a rapidly oscillating vertical motion).

[0066] The UAV can be configured to take one or more actions based on determining a potential violation or whether the operator has ignored a potential violation warning. For example, the UAV can land immediately, return to the operator, hover in its current position, or go to a location where there is no potential violation.

[0067] Reference Figure 4B , alternative implementations can shift the computational burden from the UAV itself to the controller (409). In this case, the controller (409) can access the memory (404) and perform the above-related content based on the location information sent by the UAV (401) via the data link (410).

[0068] Reference Figure 4C , in an implementation, the UAV can also be equipped with a (wireless) network interface (420), such as a 5G network interface, which allows the UAV to access the USS (423) or a similar server or its designation operated by the relevant agency in the airspace via a wireless network (421) (such as a 5G network) and the Internet (422). During startup, before flight, or during flight, the UAV (401) can query the USS (423) for one or more of the following:

[0069] - Charts, in case the on-board charts for the relevant area in the memory (404) are not current (flight charts with an expiration date); charts related to the geographical location obtained from the GPS (403) or other georeferenced data, including a reasonable radius around the current position of the UAV, where the reasonable radius can be calculated by the endurance of the UAV (maximum flight time), its maximum speed, and a safety factor to account for wind and other environmental factors;

[0070] - NOTAMs related to similar areas;

[0071] - TFRs related to similar areas;

[0072] - Other flight-related information, such as weather / wind data.

[0073] The information received using the above mechanisms can be integrated with the on-board information in the memory (404) and used as described later.

[0074] The details of the protocol for communication between the UAV (401) and the USS (or other server) depend on the services provided by the USS (423). Historically, as an example, NOTAMs and / or TFRs were available in files covering geographical areas (the size of several US states) of air traffic control centers. The UAV can request the file corresponding to its operating status (identified by the GPS position and on-board charts), download the relevant text NOTAM file (which can be tens or possibly 100 Kbyte in size) using a protocol such as ftp or http, parse the file to obtain the relevant information, and integrate the information found with the on-board chart information in the memory (404). Such a process can occur at least once before the flight, but can also occur multiple times during the flight, for example, at intervals of 1 minute or 5 minutes. This is practical due to the relatively small file size, although it is less efficient compared to other access mechanisms described below.

[0075] Recently, airspace management agencies, including the FAA, have implemented modern query interfaces that allow for the automatic download of information related to specific locations at a finer granularity than the state level. These interfaces can be based on RESTful operations. REST, also known as Representational State Transfer, is a technology where a client can query a server identified by a basic Uniform Resource Identifier (URI) using standard HTTP methods (including, for example, GET, POST, PUT, PATCH, or DELETE) and in a defined format. One such defined standardized format is called Java Object Notation or JSON.

[0076] Reference Figure 5A depicts a RESTful query (501) of the USS server related to the UVA chart designed by the FAA and the JSON-encoded response (502) of the server. In this case, the response indicates information such as the "ceiling" (503) in feet (504) (the maximum allowable altitude of the UAV), the effective date (505) of the chart, and the last edit date (505) (from which the expiration date can be derived), as well as the location (506) and shape (507) of the spatial area to which the ceiling (503) applies.

[0077] Queries for TFR, NOTAM, or other real-time update information can have a similar format. Since both the query message and the reply are relatively small in size and the computational requirements for processing such messages are relatively low compared to parsing text files of many Kbytes, such a query mechanism can be more suitable for UAVs compared to full file downloads and parsing. Arguably, there are also no privacy issues, as according to the proposed rules, UAVs need to notify the USS of their location anyway.

[0078] After obtaining an update to the chart information stored in the memory (404) according to any of the above mechanisms or any other suitable mechanism, in the same or another embodiment, the result of the relevant process can be transmitted to the UAV pilot (409).

[0079] The UAV may need to obtain authorization from the USS / UTM using any network communication means - such as wireless technologies like 3G / 4G / 5G - before takeoff. The authorization obtained can include, but is not limited to, standby, allowing takeoff with subsequent instructions, or not allowing takeoff within a specified time range. Once it is in flight, the UAV may only connect to a single USS / UTM for traffic advisories to monitor traffic, weather updates, and status updates.

[0080] When the UAV travels along a predetermined flight path, it may be necessary to switch to a different USS / UTM due to service convergence from the initial USS / UTM. This instruction can be obtained during takeoff permission or updated after flight. When the UAV changes its flight service to a different service provider or traffic controller, this switch is called a handoff. During the handoff phase, it may be necessary to update some data to the new USS / UTM service provider. Similarly, new instruction data can be actively sent to the UAV. Subsequent data transmissions can include the current location, altitude, speed, destination, power settings, and a list of onboard devices such as barometers and payloads.

[0081] At any time, due to known or unknown reasons such as weather causing the UAV to fly off course, or onboard GPS failure resulting in loss of direction control, the UAV may operate outside the limits specified by the USS / UTM. Data link communication failures prevent the transmission and reception of command messages from the USS, incorrect indicated airspeed leads to miscalculation of flight time, misinterpreted airspace leads to entry into dangerous or prohibited flight areas such as TFRs, incorrect altitude indicators cause the UAV to fly into unsafe areas, or excessive power usage causes the UAV to go out of range. For safe operation, it is possible to enforce the identification of incorrect UAV flight data and mismatches with USS commands. Table 1 lists the possible data formats.

[0082]

[0083]

[0084] Table 1

[0085] As mentioned above, the FAA has implemented RESTful operations for retrieving NOTAM / TFR data. The data returned is in a standardized format called JavaScript Object Notation or JSON. If the UAV is able to follow the commands received from the USS / UTM, an ACK message can be sent back for confirmation. In any case, if the UAV cannot follow the commands from the USS, a feedback message can be sent back to report any deviations.

[0086] Recently, the ASTM (American Society for Testing and Materials) publication on Unmanned Aircraft Remote ID also uses JSON and XML as data transfer formats. It is important to follow the main regulations and standardization committees for data transfer formats. An ACK message can be sent in the JSON format as follows. A feedback message for any deviations can be sent in the JSON format as follows. Supplementary data can be added to the USS / UTM for other information.

[0087] Figure 5B Shows a TFR / NOTAM query (511) for USS (423) near Disneyland in California using the HTTP GET method, and an HTTP-based NOTAM response (513) with text translation. In this case, the response indicates information such as NOTAM latitude and longitude (514), radius (515), altitude (516), and expiration date (517). This information is a key area indication of where and when the UAV is restricted from flying.

[0088] Reference Figure 6, alternative implementations can shift some of the computational burden from the UAV (601) to the controller (602). In this case, the controller (602) can access a memory (604) with (possibly updated) chart data and can perform the above-related content based on the location information sent by the UAV (601) via the data link (610) (such as obtained by the on-board GPS (605)). Any suitable mechanism (including the above mechanism) can be used to update the chart data to the USS (608) via its wireless network interface (605), such as a 5G interface, a wireless network 606 such as a 5G network, or the Internet (607). The relevant results (i.e., legal flight or illegal flight) can be locally available at the controller (602) and can be communicated to the human UAV pilot (609) by the controller (602) through, for example, visual signals (light, not depicted), messages on the controller screen (611), vibration alerts, or other suitable mechanisms. When the controller (602) controls the UAV (601), the signal can also be visible through the UAV (601) itself, such as through an optical signal connected to the UAV (601) or through the UAV "wobbling". This can have the advantage that the UAV pilot (609) can focus on the UAV (601) itself rather than the user interface of the controller (602).

[0089] Presumably, the UAV may have performed a pre-flight check, especially querying the chart data of the national airspace chart and storing it in the UAV on-board storage system. Referring again to Figure 4A , Figure 4B and Figure 4C , according to any of the above mechanisms or any other suitable mechanism, the initially obtained chart information can be stored in the memory (404), and in the same or another embodiment, the results of the relevant process can be communicated to the UAV pilot (409).

[0090] For the communication links, GPS antennas (403) or wireless network interfaces (405) such as 5G network interfaces between the UAV and the USS described above, one or some combination of the following communication mechanisms can be used:

[0091] - Stateful or stateless. Through stateful communication, future data exchanges may carry less data. Through a stateless approach, each conversation can contain the entire data payload.

[0092] - Connection-oriented or connectionless. The choice of connection type can depend on the UAV system capabilities.

[0093] Due to power savings or storage (404) limitations, the frequency of querying for updated chart data during UAV flight can depend on the configuration of the UAV's onboard system. However, since charts such as TFR / NOTAM can be issued without prior notice, near real-time updates can be recommended. Similar to ADS-B, updates of 30 seconds may be sufficient.

[0094] UAV pilots may not be particularly interested in the details obtained. Instead, UAV pilots may be most interested in an indication of whether the UAV's flight is or has become illegal. Thereafter, the UAV can perform one or more operations such as remaining stationary, maintaining orientation, deviating from the original flight path, immediately returning to base, immediately crashing, or any other applicable instruction from the USS or ATC.

[0095] Now referring to Figure 7 , in the current 3GPP 5G radio architecture, the (Vertical Service Enablement Architecture layer) can provide procedures, information flows, and APIs to support vertical applications on the 3GPP system to ensure the effective use and deployment of vertical applications on the 3GPP system. The SEAL service includes group management, configuration management, location management, identity management, key management, and network resource management. The UAS Application Enabler (UAE) layer provides UAE capabilities to the UAS application-specific layer. The UAE layer can include a UAE client (701) and a UAE server (703). The UAE client and the UAE server communicate with each other via the 3GPP network using the U1-AE (702) reference point.

[0096] The lower SEAL services used by the upper UAE layer can include location management, group management, configuration management, identity management, key management, and network resource management.

[0097] The SEAL client (704) communicates with the SEAL server (707) via the 3GPP network at the SEAL-UU (705) reference point. The SEAL-UU (705) supports unicast transfer mode and multicast transfer mode. The SEAL client (701) provides service enablement layer support functions 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 (707) can communicate with the underlying 3GPP core network system using the corresponding 3GPP interface (706) specified by the 3GPP network system.

[0098] The reference point (706) may include, but is not limited to, functions such as 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, etc.

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

[0100] The computer software may be encoded using any suitable machine code or computer language, and the machine code or computer language may be subject to mechanisms such as assembly, compilation, linking, etc. to create code including instructions that can be directly executed by a computer central processing unit (CPU), a graphics processing unit (GPU), etc., or executed through interpretation, microcode execution, etc.

[0101] The instructions may be executed on various types of computers or their components, including, for example, personal computers, tablet computers, servers, smartphones, gaming devices, Internet of Things devices, etc.

[0102] Figure 8 The components shown for the computer system 800 are exemplary in nature and are not intended to impose any limitation on the use or functional scope of the computer software implementing the embodiments of the present disclosure. The configuration of the components should also not be construed as having any dependence on or requirement for any one component or combination of components shown in the exemplary embodiments of the computer system 800.

[0103] The computer system 800 may include certain human-machine interface input devices. Such human-machine interface input devices may respond to inputs made by one or more human users through, for example, tactile inputs (such as keystrokes, swipes, data glove movements), audio inputs (such as voice, applause), visual inputs (such as gestures), olfactory inputs (not depicted). The human-machine interface device may also be used to capture certain media not necessarily directly related to conscious input by humans, such as audio (such as voice, music, ambient sound), images (such as scanned images, photographic images obtained from a still image camera), video (such as two-dimensional video, three-dimensional video including stereoscopic video).

[0104] The input human-machine interface device may include one or more of the following (only one of which is depicted): keyboard 801, mouse 802, touchpad 803, touch screen 810, data glove, joystick 805, microphone 806, scanner 807, camera 808.

[0105] The computer system 800 may also include certain human-machine interface output devices. Such human-machine interface output devices may stimulate one or more human users' senses through, for example, haptic output, sound, light, and smell / taste. Such human-machine interface output devices may include haptic output devices (such as haptic feedback through the touch screen 810, data glove 804, or joystick 805, but may also be haptic feedback devices that are not used as input devices), audio output devices (such as speakers 809, headphones (not depicted)), visual output devices (such as screens 810 including CRT screens, LCD screens, plasma screens, OLED screens, each with or without touch screen input capabilities, each with or without haptic feedback capabilities - some of which are capable of outputting two-dimensional visual output or outputting more than three dimensions through means such as stereoscopic output; virtual reality glasses (not depicted), holographic displays, and smoke boxes (not depicted)), and printers (not depicted).

[0106] The computer system 800 may also include human-accessible storage devices and their associated media, such as optical media including media 821 such as CD / DVD ROM / RW 820 with CD / DVD, thumb drives 822, removable hard disk drives, or solid state drives 823, traditional magnetic media such as tapes and floppy disks (not depicted), devices based on dedicated ROM / ASIC / PLD such as security dongles (not depicted), etc.

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

[0108] The computer system 800 may also include an interface to one or more communication networks. The network can be, for example, wireless, wired, or optical. The network can also be a local area network, wide area network, metropolitan area network, vehicle network, and industrial network, real-time network, delay-tolerant network, etc. Examples of networks include local area networks such as Ethernet, wireless LAN, cellular networks including GSM, 3G, 4G, 5G, LTE, etc., TV wired or wireless wide area digital networks including cable TV, satellite TV, and terrestrial broadcast TV, vehicle networks and industrial networks including CANBus, etc. Certain networks typically require an external network interface adapter connected to certain general-purpose data ports or peripheral buses (849) (such as the USB port of the computer system 800); other networks are typically integrated into the core of the computer system 800 by connecting to the following system buses (for example, an Ethernet interface into a PC computer system or a cellular network interface into a smart phone computer system). The computer system 800 can use any of these networks to communicate with other entities. Such communication can be unidirectional receive-only (such as broadcast TV), unidirectional transmit-only (such as CANbus to certain CANbus devices), or bidirectional, such as to other computer systems using local or wide area digital networks. Certain protocols and protocol stacks can be used on each of these networks and network interfaces as described above.

[0109] The above-mentioned human-machine interface devices, human-accessible storage devices, and network interfaces can be attached to the core 840 of the computer system 800.

[0110] The core 840 can include one or more central processing units (CPUs) 841, a graphics processing unit (GPU) 842, a dedicated programmable processing unit in the form of a field-programmable logic gate area (FPGA) 843, a hardware accelerator 844 for certain tasks, etc. These devices, together with a read-only memory (ROM) 845, a random access memory 846, and an internal mass storage 847 such as an internal non-user-accessible hard disk drive, SSD, etc., can be connected through a system bus 848. In some computer systems, the system bus 848 can be accessed in the form of one or more physical plugs to enable expansion through additional CPUs, GPUs, etc. Peripheral devices can be directly connected to the system bus 848 of the core or through a peripheral bus 849. The structure of the peripheral bus includes PCI, USB, etc.

[0111] The CPU 841, GPU 842, FPGA 843, and accelerator 844 can execute certain instructions, and the combination of these instructions can constitute the above-mentioned computer code. This computer code can be stored in the ROM 845 or the RAM 846. Transitional data can also be stored in the RAM 846, while permanent data can be stored in, for example, the internal mass storage 847. Fast storage and retrieval for any storage device in the storage device can be achieved by using a cache memory, which can be closely associated with one or more CPUs 841, GPUs 842, mass storage devices 847, ROM 845, RAM 846, etc.

[0112] Computer code can be present on a computer-readable medium for performing various computer-implemented operations. The medium and the computer code can be media and computer code that are specially designed and constructed for the purposes of the present disclosure, or they can be of the types that are well-known and available to those skilled in the art of computer software.

[0113] By way of example and not limitation, a computer system with architecture 800, particularly the core 840, can provide functions as a result of a processor (including CPU, GPU, FPGA, accelerator, etc.) executing software contained in one or more tangible computer-readable media. Such computer-readable media can be media associated with the user-accessible mass storage as described above, and certain memories of the core 840 having a non-transitory nature, such as the core internal mass storage 847 or the ROM 845. The software implementing various embodiments of the present disclosure can be stored in such devices and executed by the core 840. Depending on specific needs, the computer-readable media can include one or more memory devices or chips. The software can cause the core 840, particularly the processors therein (including CPU, GPU, FPGA, etc.), to execute specific processes or specific parts of specific processes described herein, including defining data structures stored in the RAM 846 and modifying such data structures according to software-defined processes. Additionally or alternatively, the computer system can provide functions as a result of being logically hardwired or otherwise embodied in a circuit (e.g., accelerator 844), which can operate in place of or in conjunction with the software to execute specific processes or specific parts of specific processes described herein. Where appropriate, references to software can include logic, and vice versa. Where appropriate, references to computer-readable media can include circuits (such as integrated circuits (ICs)) storing software for execution, circuits embodying logic for execution, or both. The present disclosure encompasses any suitable combination of hardware and software.

[0114] Now refer to Figure 9 , the UAV grouping function is managed by the SEAL group manager (GM) SIP core (905), enabling group management operations for the upper-layer application layer.

[0115] The SEAL Network Resource Manager (NRM)

[0116] (904) enables support for unicast network resource management and multicast network resource management for the upper-layer application layer.

[0117] As described above, a camera can be equipped on the UAV (901). Such media-related devices can also be referred to as UAV payloads. Support for media sessions between the UAV and other parties using network resources can be established. If such a session exists, the UAV payload can generate, transmit, or communicate with data traffic with other parties. Events such as real-time video streaming, file transfer, remote media control, etc.

[0118] In most real-time media communications, a combination of SIP and SDP is used for session initialization and media parameter negotiation. Before the actual media traffic passes through the network, the two protocol data are carried in the control plane. SDP is mainly carried as a SIP payload including all media codec-related parameters. The purpose of SDP is to convey information about the media stream and provide sufficient information to enable joining and participating in the media session in a unicast scenario.

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

[0120] The Session Description Protocol (SDP) is a protocol used to describe media session parameters. It is also used to negotiate media capabilities between media session participants. It is usually used as a SIP payload. One of the important information carried in SDP is the potential bandwidth usage of a specific media stream. For the usage of UAV media-related payloads, knowing the bandwidth that the payload wants to use is important for resource allocation in the network.

[0121] In a 3GPP network, the SIP core can appropriately communicate with the 3GPP core network to initiate the PCC (policy control and charge) function to request more network resources.

[0122] In most real-time media communications, the combination of SIP and SDP is used for session initialization and media parameter negotiation. Before the actual media traffic passes through the network, the two protocol data are carried in the control plane. SDP is mainly carried as an SIP payload including all media codec-related parameters. The purpose of SDP is to convey information about media streams and provide sufficient information to enable joining and participating in media sessions in unicast scenarios.

[0123] One of the important information carried in SDP is the potential bandwidth usage of a specific media stream. For the usage of UAV media-related payloads, knowing the bandwidth that the payload wants to use is important for resource allocation in 3GPP networks.

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

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

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

[0127] Once the SIP session is established and SDP is exchanged, the UAE server can be notified of how much bandwidth it needs for the session.

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

[0129] In the case where the SEAL NRM server (903) may not be able to accommodate the requested bandwidth resources (907), the SEAL NRM server (903) can choose to terminate the SIP session (908), otherwise, (b) the bandwidth can be allocated (909) and unicast traffic can start (910).

[0130] Now refer 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). PCC is initiated to the 3GPP CN network (1005) to obtain more resources (1009).

[0131] The SIP core can send the resource request status (1010) back to the SEAL NRM server. If the requested resources cannot be allocated, the UAE server can decide to terminate the SIP session (1011), otherwise start (b) unicast traffic (1012).

[0132] Now refer to Figure 11 , the UAV can be replaced and controlled by an existing UAC controller (UAV-C). This replacement may or may not be arranged. Such a UAV replacement event may cause network and service interruptions. The UAS can also connect to the USS / UTM using 3GPP networks, WIFI, the Internet, or other networking methods. Regardless of how the connection occurs, the USS / UTM can communicate with the UAS using only one identifier. When the UAV is replaced, the ID associated with the UAS can also change to a new ID. The USS may lose its control ability over the UAS due to the ID change. The UAV identification or RID is an important part of the UAS being considered operationally safe. In some cases, the UAV replacement in the UAS may cause a change in the UAV ID, which may lead to network and service interruptions.

[0133] In the 3GPP UAE layer, the UAVID can be used to request network resources through SEAL. When the connection is successful, the 3GPP-connected UAV can obtain a 3GPP UE ID. In addition, the 3GPP-connected UAV must register with the USS / UTM according to certain regulations and have a pre-allocated or dynamically allocated CAA-level UAV id as described above. In either case, after the UAV is replaced, a new registration between the UAS and the 3GPP network or between the UAV and the USS / UTM may be required, which may affect how SEAL provides specific services to the UAS. When the UAV has been replaced with a new CAA-level ID, UAV ID registration can be performed. In some cases, when the new UAV has a pre-allocated CAA-level ID, the following procedures may be required to re-establish the connection between the USS and the UAV.

[0134] After a UAV replacement in the UAS, the UAE server (1103) identifies that there has been a UAV replacement using a pre-allocated CAA-class UAV ID. The UAE server (1103) sends a registration request (1107) to the USS / UTM (1104) via the 3GPP network. The USS / UTM (1104) may send back a registration confirmation (1108).

[0135] The UAE server (1103) may start to request the SEAL service using the CAA-class ID as the common UAE layer user ID.

[0136] However, depending on using the previously paired UAV and UAV-C to establish a group ID, a new UAV may be used to create a group ID. The producer of the group creation for a pair of UAV and UAV-C is described. First, both the UAV-C (1101) and the UAV (1102) can successfully connect to the UAE server (1103) with the new UAV ID.

[0137] The UAE server (1103) identifies a unique pair of UAV and UAV-C.

[0138] The UAE server sends a group creation request to the SEAL GM server (1105) using the GM-S reference link.

[0139] The SEAL GM server may create a group ID for a pair of UAV and UAV-C. In some cases, subgroups may also be created for the UAV and UAV-C respectively.

[0140] The UAE server may use the returned group ID for QoS management. In the case of creating subgroups for the UAV and UAV-C, the UAE server may use the subgroup IDs to manage the QoS of the UAV and UAV-C respectively.

[0141] In some other cases, when the new UAV does not have a pre-allocated CAA-class ID. Then the USS / UTM may dynamically assign a CAA-class UAV ID to the new UAV during the registration process.

[0142] Now refer to Figure 12 , the UAE server (1203) identifies a UAV replacement without a pre-allocated CAA-class UAV ID. The UAE server (1203) sends a registration request (1207) to the USS / UTM (1204) via the 3GPP network using the 3GPP UE ID.

[0143] Now, in this case, the USS / UTM will return a registration confirmation with the new CAA-class ID assigned to this new UAV.

[0144] Similar to the previous case, if there is an existing group ID for the previous pair of UAV (1202) and UAV-C (1201), a group ID can be created.

[0145] After a UAV replacement in the UAS, the UAE server (1203) recognizes that there is a UAV replacement with a pre-allocated CAA-level UAV ID. The UAE server (1203) sends a registration request (1207) to the USS / UTM via the 3GPP network. The USS / UTM (1204) can send back a registration confirmation (1208).

[0146] The UAE server (1203) can start using the CAA-level ID as a general UAE layer user ID to request the SEAL service.

[0147] However, depending on creating a group ID using the previously paired UAV and UAV-C, a new UAV can be used to create a group ID. Explain the originator of the group creation for a pair of UAV and UAV-C. First, both the UAV-C (1201) and the UAV (1202) can successfully connect to the UAE server (1203) via the new UAV ID.

[0148] The UAE server (1203) recognizes a unique pair of UAV and UAV-C (1206).

[0149] The SEAL GM server can create a group ID for a pair of UAV and UAV-C. In some cases, subgroups can also be created for the UAV and UAV-C respectively.

[0150] The UAE server can use the returned group ID for QoS management. In the case of creating subgroups for the UAV and UAV-C, the UAE server can use the subgroup IDs to manage the QoS of the UAV and UAV-C respectively.

[0151] In some other cases, when the new UAV does not have a pre-allocated CAA-level ID. Then the USS / UTM can dynamically assign a CAA-level UAV ID to the new UAV during the registration process.

[0152] Now refer to Figure 13 , explain the originator of the group creation for a pair of UAV and UAV-C. First, both the UAV-C (1301) and the UAV (1303) can successfully connect to the UAE server (1305) via the new UAV ID.

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

[0154] The UAE server sends a group creation request (1307) to the SEAL GM server (1304) using the GM-S reference link.

[0155] The SEAL GM server can create a group ID (1308) for a pair of UAV and UAV-C. In some cases, subgroups can also be created for the UAV and UAV-C respectively (1309).

[0156] The UAE server can use the returned group ID for QoS management. In the case of creating subgroups for the UAV and UAV-C, the UAE server can use the subgroup IDs to manage the QoS of the UAV and UAV-C respectively (1310).

[0157] Now referring Figure 14 to

[0158] At 1402, method 1400 includes identifying data associated with the UAV to be transferred during a handover.

[0159] At 1404, method 1400 includes notifying a service provider of the operating state of the UAV based on the identified data.

[0160] At 1406, method 1400 includes receiving instructions corresponding to the operation of the UAV from the service provider.

[0161] It can be understood that Figure 14 only an illustration of one implementation is provided and does not imply any limitation on how different implementations can be achieved. Many modifications can be made to the depicted environment based on design and implementation requirements.

[0162] Some implementations can relate to systems, methods, and / or computer-readable media at any possible level of integration of technical details. The computer-readable media can include computer-readable non-transitory storage media (or media), which have computer-readable program instructions thereon for causing a processor to perform operations.

[0163] A computer-readable storage medium can be a tangible device that is capable of retaining and storing instructions for use by an instruction execution device. A computer-readable storage medium can be, for example, but is 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 the following: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanical encoding device such as a punched card or raised structures in grooves recorded with instructions thereon, and any suitable combination of the foregoing. As used herein, a computer-readable storage medium should not be construed to be a transient signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., an optical pulse passing through an optical fiber cable), or an electrical signal transmitted through a wire.

[0164] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device, or downloaded to an external computer or external storage device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network). The network can include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the corresponding computing / processing device.

[0165] The computer-readable program code / instructions for performing the operations can be assembly instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuits, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages such as Smalltalk, C++, etc. and procedural programming languages such as the "C" programming language or similar programming languages. The computer-readable program instructions can be executed entirely on the user's computer, partly on the user's computer, executed as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on a remote computer or server. In the case of being executed entirely on a remote computer or server, the remote computer can be connected to the user's computer through any type of network including a local area network (LAN) or a wide area network (WAN), or can make a connection to an external computer (e.g., using an Internet service provider through the Internet). In some embodiments, an electronic circuit system including, for example, a programmable logic circuit system, a field-programmable gate array (FPGA), or a programmable logic array (PLA) can execute the computer-readable program instructions by utilizing the state information of the computer-readable program instructions to personalize the electronic circuit system to perform various aspects or operations.

[0166] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine, such that the instructions executed via the processor of the computer or other programmable data processing device create a means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium, which can direct a computer, a programmable data processing device, or other device to act in a particular manner, such that the computer-readable storage medium in which the instructions are stored includes an article of manufacture that includes instructions for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0167] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other devices to produce a computer-implemented process such that the instructions executed on the computer, other programmable apparatus, or other devices implement the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0168] 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 flowchart or block diagram may represent a module, segment, or portion of instructions that includes one or more executable instructions for implementing a particular logical function. The methods, computer systems, and computer-readable media may include additional blocks, fewer blocks, different blocks, or differently arranged blocks compared to those depicted in the figures. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may in fact be executed concurrently or substantially concurrently, or the blocks may sometimes be executed in the reverse order depending on the functionality involved. It should also be noted that each block in the block diagram and / or flowchart illustration, and combinations of blocks in the block diagram and / or flowchart illustration, can be implemented by a dedicated system based on hardware that performs a particular function or action or a combination of dedicated hardware and computer instructions.

[0169] 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 does not limit these implementations. Thus, the operations and behavior of the systems and / or methods are described herein without reference to specific software code, and it should be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

[0170] Unless explicitly described otherwise, the elements, acts, or instructions used herein should not be construed as critical or essential. Also, as used herein, the articles "a" and "an" are 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." The term "one" or similar language is used when intending to refer to only a single item. Also, as used herein, the terms "having," "has," "containing," etc. are intended to be open-ended terms. Additionally, unless otherwise explicitly stated, the phrase "based on" is intended to mean "at least partially based on."

[0171] The description of various aspects and embodiments has been presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. Although combinations of features are recited in the claims and / or disclosed in the specification, such combinations are not intended to limit the disclosure of possible implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and / or not disclosed in the specification. Although each dependent claim listed below may directly depend on only one claim, the disclosure of possible implementations includes each dependent claim combined with every other claim in the claim group. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope of the described embodiments. The terms used herein have been chosen to best explain the principles of the embodiments, practical application, or technical improvement over the prior art found in the marketplace, or to enable other ordinary skilled artisans in the art to understand the embodiments disclosed herein.

Claims

1. A control method for an unmanned aerial vehicle (UAV), characterized in that, Comprising: Identifying data associated with the unmanned aerial vehicle (UAV) to be transmitted during a handover, where the handover includes the unmanned aerial vehicle (UAV) changing a flight service from an initial service provider to a different service provider; Notifying a different service provider of the operating state of the unmanned aerial vehicle (UAV) based on the identified data, where the identified data includes one or more of the following: The current position associated with the unmanned aerial vehicle (UAV); The current altitude associated with the unmanned aerial vehicle (UAV); The current speed associated with the unmanned aerial vehicle (UAV); A list of devices associated with the unmanned aerial vehicle (UAV); And The power settings associated with the unmanned aerial vehicle (UAV); and Receiving instructions corresponding to the operation of the unmanned aerial vehicle (UAV) from the different service provider.

2. The control method according to claim 1, further comprising: Identifying one or more problematic operating parameters based on the identified data; Notifying the service provider of an instruction violation corresponding to the problematic operating parameter.

3. The control method according to claim 2, wherein, Notifying the service provider of an instruction violation includes: Comparing data collected on the unmanned aerial vehicle (UAV) with information received from the service provider; and Notifying the service provider of an operation deviation based on the comparison data.

4. The control method according to claim 3, wherein, The information received from the service provider includes one or more of the following: An altitude report; A speed report; A GPS position report; A power report; and An airspace report.

5. The control method according to any one of claims 1 to 4, wherein, Communicating with the service provider includes: Interpreting bandwidth parameters; Managing session establishment and termination; Requesting network resources; and Enabling session control within network bandwidth limits.

6. The control method according to any one of claims 1 to 4, further comprising: Notifying the service provider of an identification update corresponding to the unmanned aerial vehicle (UAV); Receiving a new identification from the service provider; And Maintaining and updating group management associated with the unmanned aerial vehicle (UAV).

7. A control device for an unmanned aerial vehicle (UAV), characterized in that, Comprising: An identification module for identifying data associated with the unmanned aerial vehicle (UAV) to be transmitted during a handover, where the handover includes the unmanned aerial vehicle (UAV) changing a flight service from an initial service provider to a different service provider; A notification module for notifying a different service provider of the operating state of the unmanned aerial vehicle (UAV) based on the identified data, where the identified data includes one or more of the following: The current position associated with the unmanned aerial vehicle (UAV); The current altitude associated with the unmanned aerial vehicle (UAV); The current speed associated with the unmanned aerial vehicle (UAV); A list of devices associated with the unmanned aerial vehicle (UAV); and The power settings associated with the unmanned aerial vehicle (UAV); and A receiving module, configured to receive instructions corresponding to operations of the unmanned aerial vehicle (UAV) from the different service providers.

8. The control device according to claim 7, further comprising: A second identification module, configured to identify one or more problematic operation parameters based on the identified data; A second notification module, configured to notify the service provider of an instruction violation corresponding to the problematic operation parameter.

9. The control device according to claim 8, wherein, The second notification module includes: A comparison module, configured to compare data collected on the unmanned aerial vehicle (UAV) with information received from the service provider; and A notification module, configured to notify the service provider of an operation deviation based on the comparison data.

10. The control device according to claim 9, wherein, The information received from the service provider includes one or more of the following: Altitude report; Speed report; GPS position report; Power report; and Airspace report.

11. The control device according to any one of claims 7 to 10, wherein, Communicating with the service provider includes: An interpretation module, configured to interpret bandwidth parameters; A management module, configured to manage session establishment and termination; A request module, configured to request network resources; and An enabling module, configured to enable session control within network bandwidth constraints.

12. The control device according to any one of claims 7 to 10, further comprising: A notification module, configured to notify the service provider of an identification update corresponding to the unmanned aerial vehicle (UAV); A receiving module, configured to receive a new identification from the service provider; And A maintenance and update module, configured to maintain and update group management associated with the unmanned aerial vehicle (UAV), respectively.

13. A non-transitory computer-readable medium storing a computer program for controlling an unmanned aerial vehicle (UAV), characterized in that, The computer program is configured to cause one or more computer processors to execute the control method according to any one of claims 1 to 4.

14. A computer device, comprising a processor and a memory storing computer-readable instructions, wherein: The computer-readable instructions, when executed by the processor, cause the computer device to execute the control method according to any one of claims 1 to 4.

Images