Dynamic transmission control for wireless networks

Abstract

To provide a wireless network that optimizes data transmission in consideration of power constraints and critical timing constraints, in Small Unmanned Vehicle Systems, such as UAVs.SOLUTION: In a digital data link (DDL) environment having dynamic transmission control and including a plurality of nodes 100-500, one of the nodes functions as an arbiter to control operation of the other nodes. The arbiter also assigns to each node in a network a transmission start time (a time segment) and transmission duration for each cycle (number of time segments). The transmission start time and the duration can be changed for each node and for each cycle dynamically by the arbiter. The nodes can be ground control stations GCUs, unmanned vehicles, such as unmanned aerial vehicles or UAVs, or the like.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 61 / 241,854, filed on September 11, 2009, by Grabowsky et al., entitled DYNAMIC TRANSMISSION CONTROL FOR A WIRELESS NETWORK, the entire disclosure of which is incorporated herein by reference.

Background Art

[0002]

[0001] Small unmanned aerial vehicle systems such as UAVs can accomplish their missions using digital data link (DDL) communications. For example, an unmanned aerial vehicle or UAV transmits a large amount of data (video) to a ground controller via the DDL, and a small amount of data is transmitted to the UAV. Since unmanned aerial vehicles are typically power-constrained, most of the DDL data, namely the video data from the UAV, is transmitted by the power-constrained UAV.

[0003]

[0002] Furthermore, it is important that many DDL signals are real-time. To control a remotely operated aircraft, an operator receives real-time video, views and processes it through thinking, then physically reacts, that is, moves a control stick to transmit a control signal to the aircraft, and the aircraft moves in accordance with the control signal. This requires full-motion real-time data in both directions.

[0004]

[0003] Conventional systems, WiMAX, and mobile phones are optimized based on the nature of the information in the signal, regardless of power constraints and critical timing constraints. In conventional systems, time is not critical for high-quality video, and therefore it is usually buffered to take advantage of time gaps. In UAVs, such buffering is not possible due to the critical nature of the response to the video signal. In the case of packet voice or packet video calls, the data is heavily compressed by the low data rate and is not full-motion, high-quality, real-time data. However, in the case of UAVs, the data needs to be transmitted quickly to the operator when it is ready and does not need to be buffered if it is convenient for the medium or protocol.

[0005]

[0004] Furthermore, in UAVs, DDL must satisfy several operating scenarios that are not present in conventional systems.

[0006]

[0005] What is needed is a planned DDL service and function that enables the aircraft and ground equipment to perform their missions. [Overview of the project]

[0007]

[0006] In one possible embodiment, a wireless network is provided which includes a plurality of nodes and has dynamic transmission control. The nodes include an arbitration mechanism and a plurality of client nodes. The arbitration mechanism controls the operation of the client nodes by defining communication operation cycles and allocating bandwidth to each client node in each cycle in response to bandwidth requests from the client nodes. [Brief explanation of the drawing]

[0008]

[0007] The features and advantages of the present invention will be better understood by referring to the following description, the appended claims, and the appended drawings. [Figure 1] This block shows an example of a DDL environment. [Figure 2]This diagram illustrates the network architecture and protocol layer. [Figure 3A] This is a block diagram of the nodes addressed for exemplary DDL sessions from each laptop connected to the ground control station. [Figure 3B] This is a block diagram of the nodes addressed for exemplary DDL sessions from each laptop connected to the ground control station. [Figure 4A] This block diagram shows the transmission slot allocation for arbitration cycles over the mission duration for a single aircraft controlled by a single ground control station. [Figure 4B] This block diagram shows the transmission slot allocation for arbitration cycles over the mission duration for a single aircraft controlled by a single ground control station. [Figure 5A] This block diagram shows the transmission slot allocation for the arbitration cycle over the mission lifetime for an exemplary video relay scenario. [Figure 5B] This block diagram shows the transmission slot allocation for the arbitration cycle over the mission lifetime for an exemplary video relay scenario. [Figure 6A] Block diagram showing the transmission slot allocation for the arbitration cycle across a portion of a mission for an exemplary video relay scenario. [Figure 6B] Block diagram showing the transmission slot allocation for the arbitration cycle across a portion of a mission for an exemplary video relay scenario. [Modes for carrying out the invention]

[0009]

[0014] In various embodiments, a wireless network has multiple nodes (transmitters / receivers controlled by an operating system), one of which acts as an arbitrator to control the operation of the other nodes. The arbitrator defines an operation cycle, each divided into a set of time segments. The arbitrator also assigns each node in the network a transmission start time (time segment) and a transmission duration per cycle (number of time segments). The transmission start time and duration can be changed by the arbitrator for each node and per cycle (and are therefore dynamic). Nodes may be ground control stations (GCUs), unmanned aerial vehicles (UAVs), or other entities. In some embodiments, a ground station can act as the arbitrator, and a UAV is a node to which the variable transmission time is assigned. Since small UAVs require only a small amount of radio spectrum, the allocated radio spectrum can be efficiently shared by multiple nodes (potentially multiple UAVs and ground systems) by adjusting the bandwidth allocated to each node as needed, in accordance with the instantaneous demands of the nodes and the needs of the operator. This allows operators to control whether each UAV transmits full video, degraded video or still images, or no images at all, maximizing the bandwidth available for the most desired transmission purposes and reducing bandwidth for less desired purposes.

[0010]

[0015] Figure 1 is a block diagram illustrating an exemplary DDL environment 10. In one DDL session 15 in frequency band x, the DDL environment 10 includes unmanned aerial vehicles (UAVs) 1 and 2, such as aircraft, each containing DDL nodes 100 and 300, respectively. The DDL environment 10 may further include manned ground stations GCU1 and GCU2, each containing DDL nodes 200 and 400, respectively. Handheld controllers 205 and 405, connected to GCU1 and GCU2 respectively, are used by operators (not shown) to generate control signals for UAV1 or UAV2. Optionally, the DDL environment 100 may further include external devices 210 and 410, such as laptops, physically connected to DDL nodes 200 and 400 via Ethernet connections 215 and 415, respectively. Furthermore, it may include one or more optional remote viewing terminals (RVTs) containing a DDL node 500. In Figure 1, the remote viewing terminal(s) and / or ground station may optionally include push-to-talk or PTT voice communication functionality (not shown). In addition to DDL session 15, other DDL sessions 25 operating in other operating frequency bands may also exist in the DDL environment 10.

[0011]

[0016] The DDL environment 10 and associated architecture shown in Figure 1 are illustrative and may consist of multiple devices, components, or items of various types discussed above, or other devices or items. Furthermore, some of the devices, components, or items may be combined or omitted as desired. For example, the ground station GCU 1 and the handheld controller 205 may be combined into a single device. Also, for example, the external device 210 may be omitted or may be a device other than a laptop computer device.

[0012]

[0017] Depending on the embodiment, the DDL system may include various functional and design constraints. In various embodiments, the DDL system should provide some or all of the following functions: DDL nodes should be able to address each other. The laptop (or hand controller) should be addressable to those local DDL nodes. These are nodes within the ground station to which the laptop is connected. The laptop (or hand controller) should be able to address all DDL nodes (not just the local DDL). A laptop should be able to address other laptops (connected to other DDL nodes). A DDL LAN should support local DDL nodes and routers connected to a wide area network that provide connectivity between the two. Furthermore, in various embodiments, the DDL system design may adhere to some or all of the following constraints: The hand controller is optional. Local DDL nodes should be able to connect to the DDL network without a hand controller. A laptop is optional. A local DDL node should be able to connect to the DDL network without a laptop. Operator setup should not be required. Basic DDL scenarios can be satisfied without requiring the operator to pre-configure the DDL nodes. Advanced scenarios require minimal operator setup. Non-standard laptop software should not be required. Standard operating system software is sufficient to connect a laptop to the DDL network. Specialized software is required to control the aircraft. The introduction of DDL nodes or the installation of external devices should not cause service interruptions.

[0013] Exemplary DDL scenario

[0018] The list of exemplary scenarios in Table 1 below represents various missions and portions of missions that a DDL may perform in various UAV embodiments. Other embodiments and scenarios are also possible. A scenario that is part of a mission may be performed as part of a plurality of other missions. For example, a GCS handoff scenario may be performed during a mission represented by a conventional scenario, in which case both scenarios impose requirements on DDL design.

[0014]

[0019] As shown in Table 1, there are multiple scenarios envisioned for operating a DDL network. Some scenarios include an entire mission, while others consist of a portion of a mission. There may also be missions that are components of many missions. The following list in Table 1 is a collection of scenarios that clarify features applicable to DDL network design. [Table 1]

[0015] Network Protocol Layer

[0020] The network architecture consists of several protocol layers as shown in Figure 2. As illustrated in Figure 2, the DDL network can be regarded as a vertical stack from the bottommost physical layer up to the standard network layer. These layers are as follows. Network Layer The topmost layer transmits Ethernet packets between external devices connected to DDL nodes. The packets have MAC addresses that are used by external devices to communicate with each other. Ordinary Internet traffic enters the DDL network through one edge DDL node, exits from all other edge DDL nodes, and provides a channel for those external devices to communicate with each other. At the network layer, external devices communicate with other external devices. Link Layer: This middle layer transmits DDL packets between DDL nodes. These packets have a DDL address consisting of a DDL RUID (Random Unit Identifier), also called a SUID (Session User Identifier), which identifies the DDL node, and a DDL port, which identifies a specific input / output port of that DDL node. The physical layer, the lowest layer, controls the timing of transmission and the preparation of data for modulation into RF energy radiated by the transmitter and intercepted and processed by multiple receivers.

[0016] Mediation mechanism

[0021] Referring to Figure 1, each DDL network session 15 is coordinated by one of the DDL nodes 100, 200, 300, 400, or 500, which act as the "arbitrator." This arbitrator node is typically mounted on an aircraft UAV1 or UAV2 to benefit from its advantageous position in the air. In various other network environments (not shown), such as a purely ground-based network environment, the arbitrator may be a node that is in an advantageous position relative to other nodes, a node that can communicate with other nodes, or a node that is particularly effective when communicating with other nodes. Alternatively, if desired, the arbitrator may be a node in a secure location. In Figure 1, DDL node 100 on UAV1 is shown in the role of the arbitrator. The primary role of the arbitrator is to schedule the time slots that each node is allowed to transmit between. Sharing communication channels through time scheduling is known as "Time Division Multiple Access" (TDMA).

[0017]

[0022] The arbitration mechanism 100 controls the bandwidth for each of the client nodes 200, 300, 400, and 500. The arbitration mechanism 100 sets the bandwidth for each node 200, 300, 400, and 500. If the bandwidth allocated by the arbitration mechanism 100 is not needed by any of the nodes 200, 300, 400, and 500, the arbitration mechanism allocates the bandwidth to another node of node 200, 300, 400, or 500. The arbitration mechanism changes the bandwidth allocation sequentially. This allows the arbitration mechanism 100 to allocate a large bandwidth to one node and a small bandwidth to another node based on the respective needs of nodes 100, 200, 300, 400, and 500. Thus, the arbitration mechanism 100 controls all communication in the network session 15.

[0018]

[0023] Furthermore, all communications are between DDL nodes 200, 300, 400, or 500 and the arbitration mechanism 100. Generally, the arbitration mechanism 100 is an aircraft, but any of nodes 200, 300, 400, or 500 can be the arbitration mechanism. The arbitration mechanism 100 may be on the ground, but is generally located on an aircraft because the aircraft has the best line of sight for transmitting radio signals. As shown in Figure 1, node 300 in another aircraft UAV 2 can relay to other nodes 200, 400, or 500 via the arbitration mechanism 100 in aircraft UAV 1. In this embodiment, in addition to being the arbitration mechanism, DDL node 100 may also have its own session video, aircraft control data, or other data to transmit. Thus, DDL node 100 is also involved in the allocation of bandwidth in the arbitration mechanism 100.

[0019]

[0024] Conventional TDMA applications use a predetermined cycle. In various embodiments of this application, the arbitration mechanism 100 can set up a periodic cycle for transmission, but can change the bandwidth allocated to each node 200, 300, 400, or 500 based on the bandwidth needs of session 15. The arbitration mechanism 100 is not fixed to a predetermined cycle. The bandwidth for each node 200, 300, 400, or 500 may change with each burst. The decision on how to allocate the bandwidth is made by the arbitration mechanism. If there is low-bandwidth data, such as only voice data, the arbitration mechanism can set up a more structured network similar to TDMA. If data requirements change, the arbitration mechanism 100 can change the bandwidth allocation. For example, the arbitration mechanism 100 may need high bandwidth to send a new full frame of new video to the ground station GCU1, or it may only need to send low-bandwidth incremental video to the ground station GCU1 afterwards. When the amount of data changes, the arbitration mechanism 100 can change the allocation to each node 200, 300, 400, and 500. The arbitration mechanism 100 can accommodate the data transmission needs within session 15.

[0020] Node addressing

[0025] Figures 3A and 3B show block diagrams of node addressing for an exemplary DDL session 16 from the perspective of a laptop 1 connected to the ground control station GCU 1. Figure 3A shows a block diagram indicating the random unit identifiers (RUIDs) and specific input / output channels or ports for DDL nodes 100, 200, 300, 400, and 500. For communication between DDL nodes 100, 200, 300, 400, and 500, the random unit identifiers (RUIDs) (sometimes called session user identifiers (SUIDs)) and specific input / output channels are specified by DDL port numbers, with 01 for DDL control, 11 for Ethernet, 21 for serial communication, 31 for LVDS (low-voltage differential signaling), and 02 for arbitration.

[0021]

[0026] In the communication, the ground control station DDR node to which the laptop is connected maps known DDL nodes to an IP port number range, allowing software on the laptop to address the DDL nodes using conventional IP address-port number pairs. Figure 3B shows a block diagram illustrating an example of the mapping of known network nodes 100, 200, 300, 400, and 500 in network session 16 by the ground control station DDL node 200. Laptop 1 210 is connected to an IP port number range for use by laptop 1 210. This allows software on laptop 1 210 to address the DDL nodes using conventional IP address-port number pairs. Conventional IP addresses (xxx.xxx.xxx.xxx) and base port addresses are generated by the GCL1 DDL node 200 for provision to laptop 1 210. DDL Network Table 202 shows an example of conventional IP addresses (xxx.xxx.xxx.xxx) with base port addresses, i.e., 5000, 50100, 5200, 5300, and 50400, that are assigned by GCL1 DDL node 200 to provide for laptop 1 210 for session 16. DDL node 200 communicates with the other DDL nodes 100, 300, 400, and 500 using the RUID address and port number shown in Figure 3A.

[0022]

[0027] Referring to Figure 3A, in this example, the arbitration mechanism 101 and the UAV1 system 102 have separate RUID addresses, 0 and 47034, respectively. Therefore, the arbitration mechanism 101 and the UAV system 102 are assigned separate base ports 50000 and 50100.

[0023]

[0028] Note that in the example in Figure 3B, the DDL node 500 is a passive listener and therefore not addressable by laptop 1 210, and thus does not appear in the DDL network table 201. In other embodiments, RTV 500 may be addressable. Similarly, laptop 2 410 is not addressable in this example, but may be addressable in other embodiments. For example, in some embodiments, RTV 500 or laptop 2 410 may be addressable to transmit text or other messages.

[0024]

[0029] Referring to Figure 3B, each DDL node to which a laptop is attached generates its own DDL network table (not shown) for that laptop. Therefore, a different DDL network table (not shown) is generated by the GCU2 DDL node 400 for laptop 410.

[0025] Messages and packets

[0030] DDL messages carry commands between DDL nodes. The bandwidth allocation strategy manages how DDL nodes share RF channels to communicate with other DDL nodes, supporting connections to and between external devices. Communication between DDL nodes is carried in small sets of packets with specific header information and message content. DDL nodes communicate with each other via the messages listed in Table 2. Note that data from external devices is carried in one of these messages.

[0026]

[0031] Referring to Figure 1, in various embodiments, each node 200, 300, 400, and 500 requests the arbitration mechanism 100 for the amount of bandwidth it needs. As shown in Table 2 below, nodes 200, 300, 400, and 500 also request the desired amount of bandwidth or BW they need, and the minimum amount of bandwidth or required BW they need. Furthermore, in various embodiments, since the data may have its own inherent size, nodes 200, 300, 400, and 500 may request the service interval, the longest time to wait before sending more data using the slot start time and duration, and a preferred allocation size or allocated BW. Based on these requests, the arbitration mechanism 100 controls the bandwidth for each of nodes 200, 300, 400, and 500. [Table 2]

[0027]

[0032] The messages in Table 2 are sent as DDL packets, which also include the fields listed in Table 3 below. The DDL messages include the fields shown in Table 3 to assist the receiver. [Table 3]

[0028] Exemplary scenarios and messages One aircraft and one GCS (Figures 4A and 4B)

[0033] Figures 4A and 4B are block diagrams showing the transmission slot allocation for an arbitration cycle over the mission lifespan for a single aircraft controlled by a single GCU. In this exemplary communication in a simple mission scenario 600, the operator powers on a single UAV and a single GCU, prepares the aircraft for pre-flight, takes off and flies the aircraft to an area of ​​interest, observes the area, and returns and lands at the takeoff point.

[0029]

[0034] In this scenario 600, the aircraft listens to determine if there is an ongoing session in block 610, and if it hears that there is no ongoing session, it initiates its own session in the geographical region of this reception, taking on the role of arbitration mechanism for this channel. The arbitration session is ready to accept any UAVs and GCUs that may check in at any time. In frame 620 (frame number 1), the arbitration mechanism allocates the maximum bandwidth to block 624 for the UAV downlink video stream. This is because, initially, only other demands on the channel are relatively low, a flight command is uplinked from GCU1 to the aircraft, contention slot 625 is allocated by the arbitration mechanism, and a new node checks in and requests bandwidth.

[0030]

[0035] GCU1 listens to the arbitration mechanism and, in frame 630 (frame M), joins the session and obtains bandwidth allocation. In frame 630 (frame M), GCU1 issues request 636 in contention slot 635, takes control of the UAV in frame 640 (frame M+1), and continues this control for the duration of the mission.

[0031]

[0036] Request 636 from GCU1 is given slot 646 in frame 640 (frame M+1), and GCU1 issues command 647 in contention slot 645. Command 647 is given slot 657 in frame 650 (frame M+2). GCU1 issues command 648 in contention slot 655. GCU1 sends command data 657, but does not require the entire slot 657, and therefore the arbitration mechanism terminates frame 650 in 650e and starts the next frame 660 (frame M+3), where command 658 is given slot 667. The arbitration mechanism provides contention slot 665 for a new requester.

[0032]

[0037] A RVT that is tuned to this channel and has the correct encryption key for this session can view the video transmitted from UAV1.

[0033] Video broadcast: 2 aircraft and 1 GCS (Figures 5A and 5B)

[0038] Figures 5A and 5B are block diagrams showing the transmission slot allocation for the arbitration cycle over the mission duration for an exemplary video relay scenario 700. In this example, the operator uses one UAV1 as a “relay unit” to communicate with a second remote “sensor” UAV2. Sensor UAV2 cannot communicate directly with GCU1 because it is either beyond GCU1’s radio range or not within line of sight of GCU1. The operator first powers on GCU1 and relay UAV1 and flies relay UAV1 to a relay station from which it can communicate with both GCU1 and sensor UAV2 once it arrives in the planned operating area. The operator then powers on sensor UAV2 and flies it to its operating area and puts it into operation. Once the mission is complete, sensor UAV2 is recovered first, followed by relay UAV1. Extending the duration of the relay mission can be achieved by taking over from relay UAV1 when its battery is running low, as illustrated in the relay handover scenarios shown in Figures 6A and 6B below.

[0034]

[0039] Upon initial power-up, Relay UAV2 does not hear any existing sessions in progress and initiates its own session by assuming the role of arbitration mechanism for this channel within the geographical area of ​​this reception. The arbitration session is ready to accept additional UAVs and additional GCUs that can check in at any time. As shown in frame 710 (frame M), GCU1 controls UAV1, and UAV1 is transmitting high-bandwidth video in slot 714. Since the only other requests on the channel are the uplink flight command 716 from GCU1 to UAV1, and the opportunity for contention slot 725, which is allocated by the arbitration mechanism for new nodes to check in and request bandwidth, as shown in frame 720 (frame M+1), the arbitration mechanism first allocates maximum bandwidth to video slot 714 from its own UAV1 to the downlink video stream. This allocation remains in effect while Relay UAV1 is being flown to its relay station.

[0035]

[0040] When Relay UAV1 is in flight, the operator can power on Sensor UAV2, prepare it for flight, have it take off, and fly it to its operating area. Upon power-up, Sensor UAV2 listens to the existing session conducted by Relay UAV1 and checks in with a high-bandwidth request 726 to support its video stream. In this example, at frame 720 (frame M+1), the arbitration mechanism prompts for a new request in slot 725, and UAV2 requests a moderate-bandwidth video 726, but it exceeds the capacity. Since the arbitration mechanism previously gave maximum bandwidth to Relay UAV1 video at 724, it must now adjust the bandwidth allocation to meet Sensor UAV2's request. The arbitration mechanism adjusts the bandwidth allocation based on the bandwidth policy in effect at that time, usually by reducing the allocation for the current stream to give the allocation to Sensor UAV2. The allocation for the Sensor UAV2 video stream is set when Relay UAV1 recognizes the need to receive the Sensor UAV1 stream and transmit it.

[0036]

[0041] In frame 730 (frame M+2), GCU1 controls UAV2 and sends pilot commands in slot 737. In frame 740 (frame M+3), UAV2 transmits telemetry and very low bandwidth video in slots 748 and 749, respectively. In frame 750 (M+4), GCU1 instructs UAV1 to reduce bandwidth to the minimum in slot 757. In frame 760 (frame M+5), UAV2 transmits telemetry and moderate bandwidth video in slots 768 and 769, respectively. In frame 770 (frame M+6), UAV2 transmits telemetry 778 and video 779, but does not require the entire slot 775, and therefore frame 770 (frame M+6) ends at 770e. The arbitration mechanism starts the next frame 780 (frame M+7) early. In frame 780 (frame M+7), GCU1 sends pilot commands to UAV2 in slot 787. In frame 790 (frame M+8), UAV2 transmits telemetry and moderate bandwidth video in slots 798 and 799, respectively.

[0037]

[0042] The arbitration mechanism controls the session and therefore allocates bandwidth to GCU1 in frame 710. The arbitration mechanism prompts for a new request in frame 720. In frame 730, the arbitration mechanism allocates bandwidth to GCU1. In frame 740, the arbitration mechanism allocates available bandwidth to UAV2. In frame 750, the arbitration mechanism allocates bandwidth to GCU1. The arbitration mechanism allocates a reasonable amount of bandwidth to UAV2 in frames 760 and 770. Then, in frame 780, the arbitration mechanism allocates bandwidth to GCU1. After that, the arbitration mechanism again allocates a reasonable amount of bandwidth to UAV2 in frame 790.

[0038]

[0043] By tuning into this channel and possessing the correct encryption key for this session, RVTs can view the video transmitted from the relay aircraft.

[0039] Relay handover: Two aircraft and two GCSs (Figures 6A and 6B)

[0044] Figures 6A and 6B are block diagrams showing the transmit slot allocation for an arbitration cycle across a portion of a mission for an exemplary video relay scenario 800. In this example, the transmit slot allocation for an arbitration cycle across a portion of a mission is performed when a new aircraft UAV2 relieves relay aircraft UAV1. The operator is using one aircraft as a “relay” to communicate with another aircraft or GCU, and that relay aircraft has reached the limit of its flight time. The operator powers on the relief UAV2 and flies the relief UAV2 to the relay station, where the relief UAV2 downloads session information from relay UAV1 and takes over the role of the arbitration mechanism.

[0040]

[0045] In frame 810 (frame M), the arbitration mechanism allocates bandwidth to GCU1 in slot 816, and GCU1 transfers data in 816 from its external client to GCU2 for that external client. In frame 820 (frame M+1), the arbitration mechanism allocates bandwidth to GCU2 in slot 826. GCU2 transfers data 826 from its external client to GCU1 for that external client. In frame 830 (frame M+2), the arbitration mechanism prompts for a new request, and therefore UAV2 starts up and detects an ongoing session, UAV2 waits for contention slot 835, and then requests bandwidth in slot 836 to send its telemetry. In frame 840 (frame M+3), the arbitration mechanism allocates bandwidth to UAV2, and UAV2 sends its telemetry in slot 846.

[0041]

[0046] Before frame 850 (frame N), UAV2 takes off and flies to the station. In frame 850 (frame N), the arbitration mechanism grants bandwidth to GCU1, and GCU1 instructs UAV2 to assume the arbitration role at 856. In frame 860 (frame N+1), the arbitration mechanism in UAV1 grants bandwidth to UAV2, and UAV2 requests the arbitration mechanism in UAV1 to relinquish its role as session arbitration mechanism at 866. In frame 870 (frame N+2), the arbitration mechanism in UAV1 transmits its arbitration table at slot 876, allowing UAV2 to assume the arbitration role without forcing the client to check in again, so there is no allocation slot by the arbitration mechanism in UAV1. In frame 880 (frame N+3), UAV2 assumes the arbitration role and grants bandwidth to GCU2, and GCU2 transfers data from its external client to GCU1 at 896 for that external client. In frame 890 (frame N+4), the arbitration mechanism in UAV2 allocates bandwidth to GCU1, and in 896, GCU1 transfers data from its external client to GCU2 for that external client.

[0042]

[0047] It is worth noting that any reference to “one embodiment” or “an embodiment” means that certain features, configurations, or characteristics described in relation to this embodiment may be included in the embodiment, if desired. The phrase “in one embodiment” appearing in various places in this specification does not necessarily refer to the same embodiment.

[0043]

[0048] The examples and illustrations provided herein are for illustrative purposes only and are not intended to limit the scope of the appended claims. This disclosure should be considered illustrative of the principles of the invention and is not intended to limit the spirit and scope of the claims of the invention and / or the illustrated embodiments.

[0044]

[0049] Those skilled in the art will modify the present invention for specific applications.

[0045]

[0050] The arguments contained herein are intended to serve as a basic explanation. It should be noted that certain arguments do not explicitly describe all possible embodiments, and alternative forms are implied. Furthermore, these arguments do not fully describe the general nature of the invention, nor can they explicitly show how representative or equivalent each feature or element may actually be. Moreover, these elements are implicitly included in this disclosure. Where the invention is described in device-oriented terminology, each element of the device implicitly performs a function. It should also be understood that various modifications may be made without departing from the essence of the invention. Such modifications are implicitly included in this description. Furthermore, these modifications fall within the scope of the invention.

[0046]

[0051] Furthermore, each of the various elements of the present invention and its claims can also be achieved in various ways. This disclosure should be understood to encompass such variations, whether they are variations of any apparatus embodiment, method embodiments, or simply variations of any element of these embodiments. In particular, since this disclosure relates to elements of the present invention, it should be understood that the terminology of each element may be expressed by equivalent apparatus terminology, even if only the function or result is the same. Such equivalent, broader, and more general terms shall be considered to be encompassed within the description of each element or operation. Such terms may be replaced if it is desired to express the implicitly broad scope for which the invention has rights. All operations can be expressed as means for performing the operation or elements that produce the operation. Similarly, each disclosed physical element should be understood to encompass the disclosure of the operation facilitated by that physical element. Such modifications and alternative terminology should be understood to be expressly included in this description.

[0047]

[0052] While the present invention has been described in relation to several embodiments, those skilled in the art will surely be able to conceive of modifications. The exemplary embodiments herein are not intended to be limiting, and various configurations and combinations of features are possible. Accordingly, the present invention is not limited to the embodiments disclosed, except as required by the appended claims.

Claims

1. A method for communicating on a wireless network having multiple drone nodes, A step of selecting an unmanned aerial device (UAR) node to assume the role of an arbitration mechanism in order to control the communication of at least one non-arbitrated node among a plurality of UAR nodes on the wireless network, the selection step of: receiving a request for desired bandwidth from the at least one non-arbitrated node in the arbitration mechanism; dynamically adjusting the bandwidth allocated to the at least one non-arbitrated node based on the request; and using the selected UAR node, which is the UAR arbitration mechanism, to define an operating cycle for each cycle and to assign a transmission start time and duration for each cycle to the at least one non-arbitrated node, When the battery of the aforementioned drone mediation mechanism runs low, a relief drone is launched to take over the role of the drone mediation mechanism. A method characterized by including the step of transferring the role of the mediation mechanism to the relief drone in order to provide a new mediation mechanism.

2. The method according to claim 1, wherein the step of selecting an unmanned aerial node to assume the role of an arbitration mechanism for controlling the aforementioned communications includes the step of selecting a UAV.

3. The method according to claim 2, wherein the step of launching the relief drone includes the step of launching a UAV.

4. The method according to claim 3, wherein the unmanned aircraft arbitration mechanism controls the communication of two or more non-arbitration nodes on the wireless network, and at least one of the two or more non-arbitration nodes is a UAV.

5. The method according to claim 1, wherein the unmanned aircraft arbitration mechanism controls the communication of two or more non-arbitration nodes on the wireless network, and at least one of the two or more non-arbitration nodes is a UAV.

6. The step of selecting an unmanned aerial node to assume the role of an arbitration mechanism in order to control the communications includes the step of selecting a UAV, The step of launching the relief drone includes the step of launching the UAV, The method according to claim 5, further comprising the step of controlling the non-arbitration node of the UAV and other non-arbitration nodes.

7. In unmanned aerial vehicles, The aforementioned unmanned aerial vehicle is equipped with a transmitter / receiver controlled by an operating system so that it can function as an arbitration mechanism in a DDL session. The arbitration mechanism is configured to control the operation of the client nodes by defining communication operation cycles and allocating bandwidth to each of the multiple client nodes for each operation cycle in response to bandwidth requests from the multiple client nodes. An unmanned aerial vehicle characterized in that the arbitration mechanism is further configured to respond to bandwidth requests from the plurality of client nodes, allocate bandwidth in an operating cycle based on the needs of each request, transfer control as a session arbitration mechanism to another node, and transmit an arbitration table to the other node before transferring control as a session arbitration mechanism.

8. The unmanned aerial vehicle according to claim 7, characterized in that the arbitration mechanism is configured to change the operation cycle based on the bandwidth requirement.

9. Each operation cycle is divided into a set of time segments, The unmanned aerial vehicle according to claim 7, wherein the bandwidth allocation includes the steps of allocating a transmission start time and a transmission duration for each of the plurality of client nodes requesting bandwidth, and modifying the transmission start time and the transmission duration for each of the plurality of client nodes requesting bandwidth in response to the bandwidth requests from the plurality of client nodes.

10. The unmanned aircraft according to claim 7, wherein the plurality of client nodes include a plurality of unmanned aircraft.

11. The unmanned aerial vehicle according to claim 7, wherein the plurality of client nodes include a ground station.

12. The unmanned aerial vehicle according to claim 11, further comprising the plurality of client nodes.

13. The arbitration mechanism is configured such that the bandwidth allocation includes the steps of allocating a transmission start time and a transmission duration to the plurality of client nodes, and changing the transmission start time and the transmission duration for the plurality of client nodes in response to requests from the plurality of client nodes, as described in claim 7.

14. The arbitration mechanism is configured such that the allocation of bandwidth includes the step of controlling video quality transmission by each of the plurality of client nodes, according to claim 7.

15. The arbitration mechanism is configured such that the bandwidth allocation includes the step of allocating bandwidth for at least one of the following: a) full video, b) video of degraded quality, c) still images, or d) no video images for client nodes requesting bandwidth, as described in claim 14.

Images