Dynamic transmission control for wireless network

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 09 / 11 / 2009 by Grabowsky et al., entitled DYNAMIC TRANSMISSION CONTROL FOR A WIRELESS NETWORK, which is incorporated herein by reference in its entirety. [Background technology]

[0002]

[0001] Small unmanned aircraft 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 DDL, and a small amount of data is transmitted to the UAV. Because unmanned aircraft are typically power-constrained, the majority of the DDL data, including video data from the UAV, is transmitted by the power-constrained UAV.

[0003]

[0002] Furthermore, it is important that many of the DDL signals be real-time. To control a remotely piloted vehicle, an operator receives, sees, and mentally processes real-time video, and then physically reacts, i.e., moves a control stick to send control signals to the vehicle, which then moves according to the control signals. This requires full-motion real-time data in both directions.

[0004]

[0003] Conventional systems, WiMax, and cellular phones are optimized based on the nature of the information in the signal, regardless of power and critical timing constraints. For conventional systems, time is not critical for high-quality video, and therefore buffering is typically used to take advantage of time gaps. For 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 telephony, the data is heavily compressed to a low data rate and is not full-motion, high-quality, real-time data. However, for UAVs, data needs to be sent to the operator quickly when it is ready, and does not need to be buffered if the medium or protocol allows.

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

[0006] What is needed are planned DDL services and capabilities that enable aircraft and ground equipment to accomplish their missions. Summary of the Invention

[0007] In one possible embodiment, a wireless network with dynamic transmission control is provided that includes a plurality of nodes, the nodes including an arbitration mechanism and a plurality of client nodes, the arbitration mechanism controlling operation of the client nodes by defining communication operation cycles and allocating bandwidth to each client node for each cycle in response to bandwidth requests from the client nodes. [Brief explanation of the drawings]

[0008]

[0007] The features and advantages of the present invention will be better understood with reference to the following description, appended claims, and accompanying drawings. [Figure 1] 1 is a block diagram showing an example of a DDL environment. [Figure 2]FIG. 1 illustrates an example network architecture and protocol layers. [Figure 3A] FIG. 10 is a block diagram of the nodes addressed for an exemplary DDL session from each laptop connected to the ground control station. [Figure 3B] FIG. 10 is a block diagram of the nodes addressed for an exemplary DDL session from each laptop connected to the ground control station. [Figure 4A] FIG. 1 is a block diagram illustrating transmission slot allocations for an arbitration cycle over the duration of a mission for one aircraft controlled by one ground control station. [Figure 4B] FIG. 1 is a block diagram illustrating transmission slot allocations for an arbitration cycle over the duration of a mission for one aircraft controlled by one ground control station. [Figure 5A] FIG. 10 is a block diagram illustrating transmission slot allocations for arbitration cycles over the mission lifetime for an exemplary video relay scenario. [Figure 5B] FIG. 10 is a block diagram illustrating transmission slot allocations for arbitration cycles over the mission lifetime for an exemplary video relay scenario. [Figure 6A] FIG. 10 is a block diagram illustrating transmission slot allocations for arbitration cycles over a portion of a mission for an exemplary video relay scenario. [Figure 6B] FIG. 10 is a block diagram illustrating transmission slot allocations for arbitration cycles over a portion of a mission for an exemplary video relay scenario. DETAILED DESCRIPTION OF THE INVENTION

[0009]

[0014] In various embodiments, a wireless network has multiple nodes (transmitters / receivers controlled by an operating system), with one of the nodes acting as an arbiter to control the operation of the other nodes. The arbiter defines operating cycles, each divided into a set of time segments. The arbiter 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 arbiter for each node and for each cycle (hence, dynamic). The nodes can be ground control stations (GCUs), unmanned aerial vehicles such as unmanned aerial vehicles (UAVs), or other devices. In some embodiments, a ground station can act as the arbiter, and the UAVs are the nodes granted varying transmission times. Because small UAVs require very little wireless spectrum, the allocated wireless spectrum can be efficiently shared by multiple nodes (potentially multiple UAVs and ground systems) by adjusting the bandwidth allocated to each node according to the node's instantaneous demand and the operator's needs. This allows the operator to control whether each UAV transmits full video, degraded video or still images, or no images at all, maximizing available bandwidth for the most desired transmission purposes and reducing bandwidth for less desired purposes.

[0010]

[0015] FIG. 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 (UAV1 and UAV2), such as aircraft, each including a DDL node 100 and a DDL node 300. The DDL environment 10 may further include manned ground stations (GCU1 and GCU2), each including a DDL node 200 and a DDL node 400. Handheld controllers 205 and 405 connected to GCU1 and GCU2, respectively, are used by an operator (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 the DDL nodes 200 and 400, respectively, via Ethernet connections 215 and 415. Additionally, one or more optional remote viewing terminal(s) RVT may be included, including a DDL node 500. 1, the remote viewing terminal(s) and / or ground station may optionally include push-to-talk or PTT voice communication capabilities (not illustrated). In addition to DDL session 15, other DDL sessions 25 operating in other operating frequency bands may also exist in DDL environment 10.

[0011]

[0016] The DDL environment 10 and associated architecture shown in FIG. 1 is for illustrative purposes only and may be a plurality of devices, components, or items of the 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, ground station GCU1 and handheld controller 205 may be combined into a single device. Also, for example, external device 210 may be omitted or may be a device other than a laptop computer device.

[0012]

[0017] A DDL system may include various functional and design constraints depending on the embodiment. In various embodiments, a DDL system should provide some or all of the following functionality: DDL nodes should be able to address each other. Laptops (or hand controllers) should be able to address their local DDL node, which is the node in the ground station to which the laptop connects. The laptop (or hand controller) should be able to address all DDL nodes (not just the local DDL). Laptops should be able to address other laptops (which are connected to other DDL nodes). The DDL LAN should support a router connected to the local DDL node and to the wide area network to provide connectivity between the two. Additionally, in various embodiments, the DDL system design may adhere to some or all of the following constraints: The hand controller is optional: a local DDL node should be able to connect to the DDL network without a hand controller. The laptop is optional: the local DDL node should be able to connect to the DDL network without a laptop. No operator setup should be required. Basic DDL scenarios can be satisfied without requiring an operator to pre-configure DDL nodes. Advanced scenarios require minimal operator setup. No non-standard laptop software should be required. Normal operating system software is sufficient to connect the laptop to the DDL network. Specialized software is required to control the aircraft. The introduction of a DDL node or the attachment of an external device should not cause a disruption of service.

[0013] Example DDL Scenarios

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

[0014]

[0019] There are multiple scenarios foreseen for operating a DDL network, as shown in Table 1. Some scenarios involve an entire mission, while others consist of parts of a mission. Some missions may be components of many other missions. The following list in Table 1 is a collection of scenarios that highlight characteristics 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, a DDL network can be viewed as a vertical stack from the bottom physical layer to the standard network layer. These layers are: Network Layer The top layer transports 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. Regular internet traffic enters the DDL network through one edge DDL node and exits through all other edge DDL nodes, providing 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 transports DDL packets between DDL nodes. These packets contain a DDL address consisting of a DDL RUID (Random Unit Identifier), also known as a SUID (Session User Identifier), which identifies the DDL node, and a DDL port, which identifies a specific input / output port on that DDL node. Physical Layer The lowest layer controls the timing of transmission and preparation of data for modulation onto RF energy that is emitted by a transmitter and intercepted and processed by multiple receivers.

[0016] Mediation mechanism

[0021] Referring to FIG. 1, each DDL network session 15 is coordinated by one of DDL nodes 100, 200, 300, 400, or 500, acting in the role of an "arbiter." This arbitration 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 entirely ground-based network environments, the arbitration may be a node that is advantageously positioned relative to other nodes, capable of communicating with other nodes, or particularly effective when communicating with other nodes. Alternatively, if desired, the arbitration may be located in a node in a secure location. In FIG. 1, DDL node 100 on UAV1 is shown in the role of arbitrator. The arbitrator's primary role is to schedule the time slots during which each node is allowed to transmit. Sharing a communication channel 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 one of the nodes 200, 300, 400, or 500, the arbitration mechanism gives the bandwidth to another of the nodes 200, 300, 400, or 500. The arbitration mechanism cycles through the bandwidth allocations. This allows the arbitration mechanism 100 to allocate more bandwidth to one node and less bandwidth to another node based on the needs of each of the nodes 100, 200, 300, 400, and 500. Thus, the arbitration mechanism 100 controls all communications in the network session 15.

[0018]

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

[0019]

[0024] Traditional TDMA applications use a predetermined cycle. In various embodiments of the present application, the arbiter 100 can set up a regular cycle for transmission but vary the bandwidth allocated to each node 200, 300, 400, or 500 based on the bandwidth needs of the session 15. The arbiter 100 is not fixed to a predetermined cycle. The bandwidth for each node 200, 300, 400, or 500 can vary from burst to burst. The decision on how to allocate bandwidth is made by the arbiter. If there is low-bandwidth data, such as only voice data, the arbiter can set up a more structured network similar to TDMA. If data requirements change, the arbiter 100 can change the bandwidth allocation. For example, the arbiter 100 may need high bandwidth to send an entire new frame of new video to ground station GCU1, and then only need to send low-bandwidth incremental video to ground station GCU1. As 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 the 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 ground control station GCU 1. Figure 3A shows a block diagram illustrating the random unit identifiers (RUIDs) and specific input / output channels or ports of DDL nodes 100, 200, 300, 400, and 500. For communications 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 designated by DDL port numbers: 01 for DDL control, 11 for Ethernet, 21 for serial communications, 31 for LVDS or low-voltage differential signaling, and 02 for arbitration.

[0021]

[0026] In communication, the ground control station DDL node to which the laptop is connected maps known DDL nodes to IP port number ranges so that software on the laptop can address the DDL nodes using conventional IP address and port number pairs. Figure 3B shows a block diagram illustrating an example of mapping of known network nodes 100, 200, 300, 400, and 500 in a network session 16 by a 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 and port number pairs. A conventional IP address (xxx.xxx.xxx.xxx) and base port address are generated by 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, namely 5000, 50100, 5200, 5300, and 50400, assigned by GCL1 DDL node 200 to serve laptop1 210 for session 16. DDL node 200 communicates with the other DDL nodes 100, 300, 400, and 500 using the RUID addresses and port numbers shown in Figure 3A.

[0022]

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

[0023]

[0028] 3B, DDL node 500 is a passive listener and is therefore not addressable by laptop 1 210 and therefore does not appear in 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 convey text or other messages.

[0024]

[0029] 3B, each DDL node with a laptop attached generates its own DDL network table (not shown) for that laptop. Thus, a different DDL network table (not shown) is generated by GCU2 DDL node 400 for laptop 410.

[0025] Messages and Packets

[0030] DDL messages carry commands between DDL nodes. A bandwidth allocation strategy governs how DDL nodes share the RF channel to communicate with other DDL nodes and supports connections to and between external devices. Communications between DDL nodes are carried in a small set 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 an external device is carried in one of these messages.

[0026]

[0031] Referring to FIG. 1 , in various embodiments, each node 200, 300, 400, and 500 requests the amount of bandwidth it needs from the arbiter 100. As shown in Table 2 below, nodes 200, 300, 400, and 500 also request a desired amount of bandwidth or desired BW they need, and a minimum amount of bandwidth or required BW. Additionally, in various embodiments, because data may have a specific size associated with it, nodes 200, 300, 400, and 500 can request a service interval and the longest time to wait before sending more data using a slot start time and duration, and a preferred allocation size or allocated BW. Based on these requests, the arbiter 100 controls the bandwidth for each of nodes 200, 300, 400, and 500. [Table 2]

[0027]

[0032] The message in Table 2 is sent as a DDL packet which also contains the fields listed below in Table 3. The DDL message contains the fields shown in Table 3 to assist the receiver. [Table 3]

[0028] Example Scenarios and Messages One aircraft and one GCS (Figures 4A and 4B)

[0033] 4A and 4B are block diagrams illustrating arbitration cycle transmit slot allocations over the mission lifetime for one aircraft controlled by one GCU. In this example communication for a simple mission scenario 600, an operator powers up one UAV and one GCU, performs pre-flight preparations for the aircraft, takes off and flies the aircraft to an area of ​​interest, observes the area, and returns to the takeoff location to land.

[0029]

[0034] In this scenario 600, the aircraft listens to determine if there are any ongoing sessions in block 610, and if it hears that there are not, it assumes the role of arbiter for this channel in its receiving geographic region and starts its own session. The arbitration session is ready to accept any UAVs and GCUs that may check in at any time. The arbiter allocates the maximum bandwidth to block 624 for the UAV downlink video stream in frame 620 (frame number 1). This is because initially, only other demand on the channel is relatively low; flight commands are uplinked from GCU1 to the aircraft, and a contention slot 625 is allocated by the arbiter, allowing the new node to check in and request bandwidth.

[0030]

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

[0031]

[0036] Request 636 by 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 need the entire slot 657, so the arbiter ends frame 650 in 650e and begins the next frame 660 (frame M+3), where command 658 is given slot 667. The arbiter offers contention slot 665 for the new requester.

[0032]

[0037] Any RVT tuned to this channel and with the correct encryption key for this session will be able to view the video transmitted by UAV1.

[0033] Video relay: two aircraft and one GCS (Figures 5A and 5B)

[0038] 5A and 5B are block diagrams illustrating the transmission slot allocation of arbitration cycles over the mission duration for an exemplary video relay scenario 700. In this example, an operator uses one UAV1 as a “relay” to communicate with a second, remote “sensor” UAV2. The sensor UAV2 cannot communicate directly with GCU1 because it is beyond the radio range of GCU1 or not within line of sight of GCU1. The operator first powers up GCU1 and relay UAV1 and flies relay UAV1 to a relay station from which it can communicate with both GCU1 and sensor UAV2 when it arrives at the planned operating area. The operator then powers up sensor UAV2 and flies it to the operating area and operates it. Upon completion of the mission, sensor UAV2 is recovered first, followed by relay UAV1. Extending the duration of a relay mission can be achieved by taking over from relay UAV1 when it is nearing battery depletion, as illustrated in the relay takeover scenarios of FIGS. 6A and 6B below.

[0034]

[0039] When first powered on, relay UAV2 does not listen to any existing sessions in progress and initiates its own session by assuming the role of arbiter for this channel within its receiving geographic region. The arbiter 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 is controlling UAV1, which is transmitting high-bandwidth video in slot 714. The arbiter initially allocates maximum bandwidth to video slot 714 for its own downlink video stream from UAV1, since the only other requests on the channel are an uplink flight command 716 from GCU1 to UAV1 and a contention slot 725 allocated by the arbiter for a new node to check in and request bandwidth, as shown in frame 720 (frame M+1). This allocation continues while relay UAV1 is being flown to its relay station.

[0035]

[0040] While relay UAV1 is in flight, the operator can power on sensor UAV2, prepare it for flight, launch it, and fly it to its operating area. Upon powering 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, in frame 720 (frame M+1), the arbitrator prompts a new request in slot 725: UAV2 requests moderate-bandwidth video 726, which exceeds its capacity. Having previously granted maximum bandwidth to relay UAV1 video in 724, the arbitrator must now adjust its bandwidth allocation to meet sensor UAV2's request. The arbitrator adjusts the bandwidth allocation based on the bandwidth policy in effect at the time, typically reducing the allocation of the current stream to grant an allocation to sensor UAV2. The allocation for the sensor UAV2 video stream is set in recognition of the need for relay UAV1 to receive and transmit the sensor UAV1 stream.

[0036]

[0041] In frame 730 (frame M+2), GCU1 takes control of 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 commands UAV1 to reduce to the lowest bandwidth 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, so 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 a pilot command 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 arbiter controls the session, so the arbiter grants bandwidth to GCU1 in frame 710. The arbiter prompts a new request in frame 720. In frame 730, the arbiter grants bandwidth to GCU1. In frame 740, the arbiter grants available bandwidth to UAV2. In frame 750, the arbiter grants bandwidth to GCU1. The arbiter grants moderate bandwidth to UAV2 in frames 760 and 770. Then, in frame 780, the arbiter grants bandwidth to GCU1. Thereafter, the arbiter again grants moderate bandwidth to UAV2 in frame 790.

[0038]

[0043] Any RVT tuned to this channel and with the correct encryption key for this session can view the video transmitted by the relay aircraft.

[0039] Relay takeover: two aircraft and two GCS (Figures 6A and 6B)

[0044] 6A and 6B are block diagrams illustrating transmission slot allocation for a portion of a mission arbitration cycle for an exemplary video relay scenario 800. In this example, transmission slot allocation for a portion of a mission arbitration cycle occurs when a new aircraft UAV2 relieves relay aircraft UAV1. An operator is using one aircraft as a "relay" to communicate with other aircraft or GCUs, and the relay aircraft reaches the end of its flight time. The operator powers on relief UAV2 and flies it to the relay station, where it downloads session information from relay UAV1 and assumes the role of arbitrator.

[0040]

[0045] In frame 810 (frame M), the arbitrator grants bandwidth to GCU1 in slot 816, and GCU1 transfers data from its external client to GCU2 for that external client in 816. In frame 820 (frame M+1), the arbitrator grants 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 arbitrator prompts a new request, so UAV2 wakes up and detects an ongoing session; UAV2 waits for contention slot 835 and then requests bandwidth to transmit its telemetry in slot 836. In frame 840 (frame M+3), the arbitrator grants bandwidth to UAV2, and UAV2 transmits its telemetry in slot 846.

[0041]

[0046] Prior to frame 850 (frame N), UAV2 takes off and flies to the station. In frame 850 (frame N), the arbiter grants bandwidth to GCU1, which commands UAV2 to assume the role of arbiter at 856. In frame 860 (frame N+1), the arbiter at UAV1 grants bandwidth to UAV2, which requests the arbiter at UAV1 to relinquish the role of session arbiter at 866. In frame 870 (frame N+2), the arbiter at UAV1 transmits its arbitration table at slot 876, allowing UAV2 to assume the role of arbiter without forcing clients to check in again, so that no allocated slots are granted by the arbiter at UAV1. In frame 880 (frame N+3), UAV2 assumes the role of arbiter and grants bandwidth to GCU2, which forwards data from the external client to GCU1 for that external client at 896. In frame 890 (frame N+4), the arbitration mechanism in UAV2 grants bandwidth to GCU1, which forwards data from the external client to GCU2 for that external client at 896.

[0042]

[0047] It is worth noting that any reference to "one embodiment" or "an embodiment" means that particular features, structures, or characteristics described in connection with this embodiment may also be included in the embodiment, if desired. The appearances of the phrase "in one embodiment" in various places in this specification do not necessarily all refer to the same embodiment.

[0043]

[0048] The illustrations and examples provided herein are for illustrative purposes and are not intended to limit the scope of the appended claims. The present disclosure should be considered as an exemplification 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 make modifications to the invention for their particular applications.

[0045]

[0050] The discussion contained in this patent is intended to serve as a basic description. It should be noted that the specific discussion may not explicitly describe all possible embodiments, and alternatives are implied. Furthermore, this discussion may not fully describe the general nature of the invention, nor may it explicitly indicate how representative or equivalent each feature or element may actually be. Furthermore, these elements are implicitly included in the disclosure. When 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 the description. Furthermore, these modifications are within the scope of the invention.

[0046]

[0051] Furthermore, each of the various elements of the invention and claims may also be achieved in various ways. The present disclosure should be understood to encompass each such variation, whether it be a variation of any device embodiment, a method embodiment, or even simply a variation of any element of those embodiments. In particular, as the present disclosure relates to elements of the invention, it should be understood that the terms for each element may be expressed by equivalent device terms, even if only the function or result is the same. Such equivalent, broader, or even more general terms should be considered encompassed in the description of each element or operation. Such terms may be substituted where desired to make explicit the implicitly broad scope to which the present invention is entitled. It should be understood that all operations can be expressed as a means for performing that operation or an element that causes that operation. Similarly, each physical element disclosed should be understood to encompass a disclosure of the operation that the physical element facilitates. Such variations and alternative terms should be understood to be expressly included in the present description.

[0047]

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

Claims

1. A method for communicating over a wireless network having a plurality of unmanned aerial vehicle nodes, comprising: selecting a drone to act as an arbitration mechanism to control communications of at least one non-arbitration node among a plurality of nodes on the wireless network, the selecting step including: receiving a request for a desired bandwidth from the at least one non-arbitration node at the arbitration mechanism; dynamically adjusting the bandwidth allocated to the at least one non-arbitration node based on the request; and using the drone arbitration mechanism to define an operating cycle for each cycle and assign a transmission start time and duration for each cycle to the at least one non-arbitration node; When the battery of the drone arbitration mechanism is low, launching a relief drone to take over the role of the drone arbitration mechanism; transferring the role of the arbitration mechanism to the relief unmanned aerial vehicle to provide a new arbitration mechanism.

2. The method described in claim 1, wherein the step of selecting an unmanned aerial vehicle node to assume the role of an arbitration mechanism for controlling the communication includes the step of selecting a UAV.

3. The method described in claim 2, wherein the step of launching the relief unmanned aerial vehicle includes the step of launching a UAV.

4. The method described in claim 3, wherein at least one of the two non-arbitration nodes is a UAV.

5. The method of claim 1, wherein at least one of the two non-arbitration nodes is a UAV.

6. At least one of the two non-arbitration nodes is a UAV; selecting an unmanned aerial vehicle node to assume a role as an arbiter to control the communications includes selecting a UAV; the step of launching the relief unmanned aerial vehicle includes launching a UAV; at least one of the two non-arbiter nodes is a UAV; The method of claim 1 further comprising controlling the UAV non-arbitration node and the other of the two non-arbitration nodes.

7. An unmanned aerial vehicle, a transmitter / receiver controlled by an operating system such that the unmanned aerial vehicle can act as an arbitrator in a DDL session; the arbitration mechanism is configured to control operation of the client nodes by defining an operating cycle for communication and allocating bandwidth to each of the plurality of client nodes for each operating cycle in response to bandwidth requests from the plurality of client nodes; The unmanned aerial vehicle is further characterized in that the arbitration mechanism is configured to respond to bandwidth requests from the multiple client nodes, allocate bandwidth based on the needs of each of the requests during an operating cycle, transfer control as a session arbitration mechanism to another node, and send an arbitration table to the other node before transferring control as a session arbitration mechanism.

8. An unmanned aerial vehicle as described in claim 7, characterized in that the arbitration mechanism is configured to change the operating cycle based on the bandwidth requirements.

9. Each operating cycle is divided into a set of time segments; 8. The unmanned aerial vehicle of claim 7, wherein the allocating of bandwidth includes assigning 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. An unmanned aerial vehicle as described in claim 7, wherein the multiple client nodes include multiple unmanned aerial vehicles.

11. An unmanned aerial vehicle as described in claim 7, wherein the multiple client nodes include a ground station.

12. An unmanned aerial vehicle as described in claim 11, wherein the plurality of client nodes further include a drone.

13. The unmanned aerial vehicle described in claim 7, wherein the arbitration mechanism is configured so that the bandwidth allocation includes the steps of assigning transmission start times and transmission durations to the multiple client nodes, and changing the transmission start times and transmission durations for the multiple client nodes in response to requests from the multiple client nodes.

14. The unmanned aerial vehicle described in claim 7, wherein the arbitration mechanism is configured such that the bandwidth allocation includes a step of controlling video quality transmission by each of the plurality of client nodes.

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

Images