Dynamic Transmission Control for Wireless Networks

Abstract

To provide a wireless network with dynamic transmission control that includes a multiple of nodes.SOLUTION: In a digital data link (DDL) environment 10, nodes include an arbiter 100 and multiple client nodes 200-500. The arbiter is configured to control an operation of the client nodes by defining communications operation cycles and allocating a bandwidth to each of the client nodes on a cycle by cycle basis in response to requests for bandwidth from the client nodes.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 09 / 11 / 2009, by Grabowsky et al. under the name DYNAMIC TRANSMISSION CONTROL FOR A WIRELESS NETWORK, which is hereby incorporated by reference in its entirety.

Background Art

[0002]

[0001] Small unmanned aircraft systems such as UAVs can achieve their missions using digital data link (DDL) communication. For example, an unmanned aircraft or UAV can transmit 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 UAVs are usually power-constrained, most of the DDL data, the video data from the UAV, is transmitted by the power-constrained UAV.

[0003]

[0002] Furthermore, it is important that many of the DDL signals are real-time. To control a remotely piloted aircraft, the operator receives real-time video, views it, processes it mentally, then physically reacts, i.e., moves the control stick to transmit a control signal to the aircraft, and the aircraft moves according to 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 the case of conventional systems, time is not important for high-quality video, and thus it is usually buffered to utilize time gaps. In the case of UAVs, such buffering is not possible due to the critical nature of the response to the video signal. In the case of packet voice calls or packet video calls, the data is strongly compressed at a low data rate and is not full-motion high-quality real-time data. However, in the case of UAVs, the data needs to be quickly transmitted to the operator when available and does not need to be buffered if it is convenient for the medium or protocol.

[0005]

[0004] Furthermore, in UAVs, the 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 devices to fulfill their missions.

Summary of the Invention

[0007]

[0006] In one possible embodiment, a wireless network is provided that includes a plurality of nodes and has dynamic transmission control. The nodes include a mediation mechanism and a plurality of client nodes. The mediation mechanism defines a communication operation cycle and controls the operation of the client nodes by allocating bandwidth to each client node for each cycle in response to bandwidth requests from the client nodes.

Brief Description of the Drawings

[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 accompanying drawings.

Figure 1

Figure 2

Figure 3A

Figure 3B

Figure 4A

Figure 4B

Figure 5A

Figure 5B

Figure 6A

Figure 6B

Best Mode for Carrying Out the Invention

[0009]

[0014] In various embodiments, a wireless network has a plurality of nodes (transmitters / receivers controlled by an operating system), and one of the nodes functions as a mediation mechanism to control the operation of the other nodes. The mediation mechanism defines an operating cycle that is divided into a set of time segments for each. The mediation mechanism also assigns a transmission start time (time segment) and a per-cycle transmission duration (number of time segments) to each node in the network. The transmission start time and duration can be changed (and thus are dynamic) by the mediation mechanism for each node and for each cycle. The nodes can be a ground control unit GCU, a drone such as an unmanned aerial vehicle or UAV, or others. In some embodiments, the ground station can operate as the mediation mechanism, and the UAV is a node to which a varying transmission time is assigned. Since small UAVs require very little radio spectrum, by adjusting the instantaneous demands by the nodes and the bandwidth assigned to each node as needed by the operator, the assigned radio spectrum can be efficiently shared among multiple nodes (potentially multiple UAVs and ground systems). This enables the operator 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 the bandwidth for less desired purposes.

[0010]

[0015] FIG. 1 is a block diagram showing 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, and these unmanned aerial vehicles each include DDL nodes 100 and 300. The DDL environment 10 may further include manned ground stations GCU1 and GCU2, and these ground stations each include DDL nodes 200 and 400. Handheld controllers 205 and 405 respectively connected to GCU1 and GCU2 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 DDL nodes 200 and 400 respectively via Ethernet connections 215 and 415. Further, one or more optional remote viewing terminals (plural) RVT including DDL node 500 may be included. In FIG. 1, the remote viewing terminal (plural) and / or the ground station may optionally include a push-to-talk or PTT voice communication function (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 related architecture shown in FIG. 1 are for illustration purposes and may be various types of multiple devices, components, or items, or other devices or items discussed above. Further, some of the devices, components, or items may be combined or omitted as desired. For example, the ground station GCU1 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] The DDL system may include various functional and design constraints depending on the embodiment. In various embodiments, the DDL system should provide some or all of the following functions. DDL nodes should be able to address each other. A laptop (or hand controller) should be able to address its local DDL nodes. These are the nodes in the ground station to which the laptop is connected. A laptop (or hand controller) should be able to address all DDL nodes (not just local DDLs). A laptop should be able to address other laptops (connected to other DDL nodes). The DDL LAN should support routers that connect local DDL nodes and wide area networks and provide a connection between these two. Furthermore, in various embodiments, the DDL system design can follow 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. The laptop is optional. Local DDL nodes 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 the operator having to pre-configure DDL nodes. Advanced scenarios require only minimal operator setup. Non-standard laptop software should not be required. Ordinary operating system software is sufficient to connect a laptop to the DDL network. Specialized software is required to control an aircraft. The introduction of DDL nodes or the attachment of external devices should not cause service interruptions.

[0013] Exemplary DDL Scenarios

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

[0014]

[0019] As shown in Table 1, there are multiple scenarios envisioned for operating the DDL network. Some scenarios include the entire mission, while others consist of parts of the mission. There can also be missions that are components of many missions. The following list in Table 1 is a collection of scenarios that reveal 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 considered a vertical stack from the bottom physical layer to the standard network layer. These layers are as follows. Network layer The top layer transmits Ethernet packets between external devices connected to the DDL nodes. The packets have MAC addresses used by the external devices to communicate with each other. Normal Internet traffic enters the DDL network through one edge DDL node, exits from all other edge DDL nodes, and provides channels for those external devices to communicate with each other. In 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) that identifies the DDL node, also called the SUID (Session User Identifier), and a DDL port that identifies a specific input / output port of that DDL node. Physical layer The bottom layer controls the timing of transmission and the preparation of data for modulation into RF energy that is radiated by the transmitter and intercepted and processed by multiple receivers.

[0016] Arbitration mechanism

[0021] Referring to FIG. 1, each DDL network session 15 is coordinated by one of the DDL nodes 100, 200, 300, 400, or 500 that operates in the role of an "arbitration mechanism". This arbitration node is typically mounted on an aircraft UAV1 or UAV2 to benefit from an advantageous position in the air. In various other network environments (not shown), such as a fully ground-based network environment, the arbitration mechanism 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. Or, if desired, the arbitration mechanism may be a node in a secure location. In FIG. 1, the DDL node 100 in UAV1 is shown in the role of the arbitration mechanism. The main role of the arbitration mechanism is to schedule the time slots during which each node is permitted to transmit between them. Sharing the communication channel by 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 required by any of the nodes 200, 300, 400, and 500, the arbitration mechanism gives the bandwidth to another one of the nodes 200, 300, 400, or 500. The arbitration mechanism changes the bandwidth allocation successively. Thereby, the arbitration mechanism 100 can allocate a large bandwidth to one node and a small bandwidth to another node based on the respective needs of the nodes 100, 200, 300, 400, and 500. Therefore, the arbitration mechanism 100 controls all communications in the network session 15.

[0018]

[0023] Furthermore, all communications are between the DDL nodes 200, 300, 400, or 500 and the arbitration mechanism 100. Generally, the arbitration mechanism 100 is an aircraft, but any of the nodes 200, 300, 400, or 500 can be the arbitration mechanism. The arbitration mechanism 100 may be on the ground, but is generally arranged 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 other nodes 200, 400, or 500 via the arbitration mechanism 100 in the aircraft UAV1. In this embodiment, in addition to being the arbitration mechanism, the DDL node 100 may also have its own session video, aircraft control data, or other data to be transmitted. Therefore, the DDL node 100 is also involved in the bandwidth allocation in the arbitration mechanism 100.

[0019]

[0024] In conventional TDMA applications, a predetermined cycle is used. In various embodiments of the present application, the arbitration mechanism 100 can set up a regular 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 for 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. When the data requirements change, the arbitration mechanism 100 can change the bandwidth allocation. For example, the arbitration mechanism 100 may need a high bandwidth to send the entire new full frame of a new video to the ground station GCU1, and then may only need to send a low-bandwidth incremental video to the ground station GCU1. 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 in 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 laptop 1 connected to ground control unit GCU1. Figure 3A shows a block diagram showing the random unit identifiers (RUIDs) of DDL nodes 100, 200, 300, 400, and 500 and specific input / output channels or ports. In the communication between DDL nodes 100, 200, 300, 400, and 500, the random unit identifier (RUID) (sometimes called the session user identifier (SUID)) and specific input / output channels are specified by the DDL port number, and 01 is specified for DDL control, 11 for Ethernet, 21 for serial communication, 31 for LVDS i.e. low voltage differential signal, and 02 for the arbitration mechanism.

[0021]

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

[0022]

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

[0023]

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

[0024]

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

[0025] Messages and Packets

[0030] DDL messages carry commands between DDL nodes. The bandwidth allocation strategy manages how RF channels are shared by DDL nodes to communicate with other DDL nodes and supports connections to external devices and connections between external devices. Communication between DDL nodes is carried in a small set of packets having 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 FIG. 1, in various embodiments, each of the nodes 200, 300, 400, and 500 requests the arbitration mechanism 100 for the amount of bandwidth it needs. As shown in Table 2 below, the nodes 200, 300, 400, and 500 also request the desired amount of bandwidth or desired BW that they need, and the minimum amount of bandwidth or required BW that they need. Further, in various embodiments, since the data may have a unique size associated with it, the nodes 200, 300, 400, and 500 request the service interval and the longest time to wait before sending more data using the start time and duration of the slot, and can request a preferred allocation size or allocation BW. Based on these requests, the arbitration mechanism 100 controls the bandwidth for each of the nodes 200, 300, 400, and 500. [Table 2]

[0027]

[0032] The messages in Table 2 are sent as DDL packets that also include the fields described 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 (FIGS. 4A and 4B)

[0033] FIGS. 4A and 4B are block diagrams showing the transmission slot allocation of the arbitration cycle over the mission duration for one aircraft controlled by one GCU. In this exemplary communication in the simple mission scenario 600, the operator powers on one UAV and one GCU, prepares the aircraft for flight, takes off the aircraft and flies it to the area of interest, observes the area, and returns and lands at the departure location.

[0029]

[0034] In this scenario 600, the aircraft listens to determine if there is an ongoing session in block 610. If it hears that there is no ongoing session, it undertakes the role of the mediation mechanism for this channel in the geographical area of this reception and starts its own session. The mediation session is always ready to accept any UAV and GCU that may check in. The mediation mechanism, in frame 620 (frame number 1), allocates the maximum bandwidth to block 624 for the UAV downlink video stream. This is initially because the other demands on the channel are relatively low, the flight commands are uplinked from GCU1 to the aircraft, contention slot 625 is allocated by the mediation mechanism, and new nodes check in and request bandwidth.

[0030]

[0035] GCU1 listens to the mediation mechanism and, in frame 630 (frame M), participates in the session to obtain a bandwidth allocation. In frame 630 (frame M), GCU1 issues a request 636 in contention slot 635, controls the UAV in frame 640 (frame M + 1), and continues this control during the mission duration.

[0031]

[0036] The request 636 by GCU1 is given slot 646 in frame 640 (frame M + 1), and GCU1 issues a command 647 in contention slot 645. The command 647 is given slot 657 in frame 650 (frame M + 2). GCU1 issues a command 648 in contention slot 655. GCU1 transmits the command data 657 but does not require the entire slot 657. Therefore, the mediation mechanism ends frame 650 at 650e, starts the next frame 660 (frame M + 3), where the command 658 is given slot 667. The mediation mechanism provides a contention slot 665 for new claimants.

[0032]

[0037] An RVT with the correct encryption key for this session, matching this channel, can view the video transmitted from UAV1.

[0033] Video Relay: Two Aircraft and One GCS (Figs. 5A and 5B)

[0038] Figs. 5A and 5B are block diagrams showing the transmission slot allocation of 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" to communicate with a second remote "sensor" UAV2. The sensor UAV2 cannot communicate directly with the GCU1 because it is outside the radio range of the GCU1 or not within the line of sight of the GCU1. The operator first powers on the GCU1 and the relay UAV1 and flies the relay UAV1 to a relay station where it can communicate with both the GCU1 and the sensor UAV2 when it arrives at the planned operating area. The operator then powers on the sensor UAV2, flies it to its operating area, and operates it. When the mission is complete, first the sensor UAV2 is recovered, followed by the relay UAV1. Extension of the relay mission duration can be achieved by taking over from the relay UAV1 when the battery is running low, which is described in Figs. 6A and 6B in the following relay handover scenario.

[0034]

[0039] When initially powered on, Relay UAV2 starts its own session without listening for existing sessions in progress and by assuming the role of the mediation mechanism for this channel within the geographical area of this reception. The mediation session is ready to accept additional UAVs and additional GCU that can check in at any time. As shown in frame 710 (frame M), GCU1 is controlling UAV1, and UAV1 is transmitting high-bandwidth video in slot 714. The other requests on the channel are the uplink flight command 716 from GCU1 to UAV1, and the contention slot 725 allocated by the mediation mechanism for a new node to check in and request bandwidth, as shown in frame 720 (frame M+1). So, the mediation mechanism first allocates the maximum bandwidth to video slot 714 of the downlink video stream from its own UAV1. 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, take off, and fly it to its operating area. When powered on, Sensor UAV2 listens for the existing session being 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 mediation mechanism prompts for new requests in slot 725, and UAV2 requests moderate-bandwidth video 726, which exceeds the capacity. Since the mediation mechanism has previously given the maximum bandwidth to the Relay UAV1 video at 724, it now has to adjust the bandwidth allocation to satisfy the request of Sensor UAV2. The mediation mechanism adjusts the bandwidth allocation based on the effective bandwidth policy at that time, usually reducing the allocation of the current stream to give an allocation to Sensor UAV2. The allocation for the Sensor UAV2 video stream is set recognizing the need for Relay UAV1 to receive and transmit the Sensor UAV1 stream.

[0036]

[0041] In frame 730 (frame M+2), GCU1 controls UAV2 and sends a pilot command 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 arbitration mechanism controls the session, so the arbitration mechanism gives bandwidth to GCU1 in frame 710. The arbitration mechanism prompts for new requests in frame 720. The arbitration mechanism gives bandwidth to GCU1 in frame 730. The arbitration mechanism gives available bandwidth to UAV2 in frame 740. The arbitration mechanism gives bandwidth to GCU1 in frame 750. The arbitration mechanism gives moderate bandwidth to UAV2 in frames 760 and 770. Then, the arbitration mechanism gives bandwidth to GCU1 in frame 780. After that, the arbitration mechanism gives moderate bandwidth to UAV2 again in frame 790.

[0038]

[0043] To match this channel, an RVT with the correct encryption key for this session can view the video transmitted from the relay aircraft.

[0039] Relay handover: Two aircraft and two GCS (FIGS. 6A and 6B)

[0044] FIGS. 6A and 6B are block diagrams showing transmission slot allocations for a mediation cycle over part of a mission for an exemplary video relay scenario 800. In this example, when the new aircraft UAV2 relieves the relay aircraft UAV1, transmission slot allocations for a mediation cycle over part of the mission are performed. The operator uses one aircraft as a “relay” to communicate with other aircraft or the GCU, and that relay aircraft reaches the limit of its flight duration. The operator powers on the relief UAV2, flies the relief UAV2 to the relay station, where the relief UAV2 downloads session information from the relay UAV1 and assumes the role of the mediation mechanism.

[0040]

[0045] In frame 810 (frame M), the mediation mechanism gives bandwidth to GCU1 at slot 816, and GCU1 transfers data at 816 from its external client to GCU2 for that external client. In frame 820 (frame M + 1), the mediation mechanism gives bandwidth to GCU2 at slot 826. GCU2 transfers data 826 from its external client to GCU1 for that external client. In frame 830 (frame M + 2), the mediation mechanism prompts a new request, and thus, UAV2 wakes up and detects the ongoing session. UAV2 waits for contention slot 835 and then requests bandwidth to transmit its telemetry at slot 836. In frame 840 (frame M + 3), the mediation mechanism gives bandwidth to UAV2, and UAV2 transmits its telemetry at slot 846.

[0041]

[0046] Before frame 850 (frame N), UAV2 takes off and flies to the station. In frame 850 (frame N), the mediation mechanism gives bandwidth to GCU1, and GCU1 commands UAV2 to accept the mediation mechanism at 856. In frame 860 (frame N+1), the mediation mechanism in UAV1 gives bandwidth to UAV2, and UAV2 requests the mediation mechanism in UAV1 to relinquish the role of the session mediation mechanism at 866. In frame 870 (frame N+2), the mediation mechanism in UAV1 sends its mediation table at slot 876 so that UAV2 can accept the role of the mediation mechanism without being forced to check in again with the client, so there is no grant of an assigned slot by the mediation mechanism in UAV1. In frame 880 (frame N+3), UAV2 accepts the role of the mediation mechanism, gives bandwidth to GCU2, and GCU2 transfers data from that external client to GCU1 for that external client at 896. In frame 890 (frame N+4), the mediation mechanism in UAV2 gives bandwidth to GCU1, and GCU1 transfers data from that 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 the particular features, configurations, or characteristics described in connection with that embodiment may be included in an embodiment if desired. The appearance of the phrase "in one embodiment" 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 patent claims. This disclosure should be regarded as an exemplification of the principles of the present invention and is not intended to limit the spirit and scope of the claims of the present invention and / or the illustrated embodiments.

[0044]

[0049] Those skilled in the art will make modifications to the present invention for specific applications of the present invention.

[0045]

[0050] The discussions contained in this patent are intended to serve as a basic explanation. It should be noted that specific discussions may not be able to explicitly describe all possible embodiments, and alternative forms are implied. Furthermore, this discussion may not be able to fully explain the general nature of the present invention, nor can it explicitly show how representative or equivalent each feature or element may actually be. Furthermore, these elements are implicitly included in this disclosure. When the present invention is described in terms of device-oriented terminology, each element of the device implicitly performs a function. It should also be understood that various changes may be made without departing from the essence of the present invention. Such changes are also implicitly included in this description. Furthermore, these changes are included within the scope of the present invention.

[0046]

[0051] Furthermore, each of the various elements of the present invention and the claims can also be achieved in various ways. It should be understood that this disclosure encompasses any such variations, whether it is a variation of any device embodiment, a method embodiment, or even simply a variation of any element of these embodiments. In particular, since this disclosure relates to the elements of the present invention, it should be understood that the terms of each element may be represented by equivalent device terms even if only the function or result is the same. Such equivalent, broader, and even more general terms shall be considered to be included in the description of each element or operation. Such terms may be replaced if it is desired to explicitly define an implicitly broader scope of application to which the present invention is entitled. It should be understood that all operations can be represented as the means for performing that operation or the element that causes that operation to occur. Similarly, it should be understood that each physical element disclosed includes the disclosure of the operation facilitated by that physical element. It should be understood that such changes and alternative terms are explicitly included in this description.

[0047]

[0052] Although the present invention has been described in connection with several embodiments, those skilled in the art will now surely come up with 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 disclosed embodiments except as required by the appended claims.

Claims

1. In unmanned aerial vehicles, 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 client nodes for each operating cycle in response to bandwidth requests from the 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 and allocate bandwidth based on the needs of each of the requests during an operating cycle to maximize available bandwidth for most necessary transmission purposes and reduce bandwidth for less necessary transmission purposes.

2. 2. The unmanned aerial vehicle of claim 1, wherein the arbitration mechanism is configured to vary the operating cycle based on the bandwidth demand.

3. 2. The unmanned aerial vehicle of claim 1, wherein the arbitration mechanism is configured to transfer control as a session arbitration mechanism to another node.

4. 4. The unmanned aerial vehicle of claim 3, wherein the arbitration mechanism is configured to transmit an arbitration table to the other node before transferring control as the session arbitration mechanism.

5. 2. The unmanned aerial vehicle according to claim 1, Each operating cycle is divided into a set of time segments; an unmanned aerial vehicle, wherein the bandwidth allocation includes the steps of: 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.

6. 10. The unmanned aerial vehicle of claim 1, wherein the plurality of client nodes comprises a plurality of unmanned aerial vehicles.

7. 10. The unmanned aerial vehicle of claim 1, wherein the plurality of client nodes includes a ground station.

8. 8. The unmanned aerial vehicle of claim 7, wherein the plurality of client nodes further comprises an unmanned aerial vehicle.

9. 2. The unmanned aerial vehicle of claim 1, wherein the arbitration mechanism is configured such that the bandwidth allocation includes the steps of assigning transmission start times and transmission durations to the plurality of client nodes, and modifying the transmission start times and the transmission durations for the plurality of client nodes in response to requests from the plurality of client nodes.

10. 2. The unmanned aerial vehicle of claim 1, wherein the arbitration mechanism is configured such that the bandwidth allocation includes controlling video quality transmissions by each of the plurality of client nodes.

11. 11. The unmanned aerial vehicle of claim 10, 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 bandwidth.

12. In unmanned aerial vehicles, a transmitter / receiver controlled by an operating system; the unmanned aerial vehicle is configured to monitor existing DDL sessions and assume the role of an arbitration mechanism if no DDL sessions are in progress; the unmanned aerial vehicle as the arbitration mechanism is configured to control operation of the plurality of 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 as the arbitration mechanism is further configured to respond to bandwidth requests from the multiple client nodes and allocate bandwidth based on the needs of each of the requests during an operating cycle to maximize available bandwidth for the most necessary transmission purposes and reduce bandwidth for less necessary transmission purposes.

13. 13. The unmanned aerial vehicle of claim 12, wherein the unmanned aerial vehicle as the arbitration mechanism is configured to initiate a DDL session in a channel if a DDL session is not detected in the channel.

14. 13. The unmanned aerial vehicle of claim 12, wherein the unmanned aerial vehicle as the arbitration mechanism is configured to control operation of a ground control station.

15. 13. The unmanned aerial vehicle of claim 12, wherein the unmanned aerial vehicle as the arbitration mechanism is further configured to receive aircraft control commands for the unmanned aerial vehicle from one of the plurality of client nodes and perform operations in accordance with the aircraft control commands from one of the plurality of client nodes.

16. 13. The unmanned aerial vehicle of claim 12, wherein the unmanned aerial vehicle as the arbitration mechanism is further configured to relay data between at least two of the plurality of client nodes.

17. 13. The unmanned aerial vehicle of claim 12, wherein the arbitration mechanism is configured to allocate bandwidth based on data priority during an operational cycle.

18. 13. The unmanned aerial vehicle of claim 12, wherein the unmanned aerial vehicle as the arbitration mechanism is configured to transfer its role as the arbitration mechanism.

19. In unmanned aerial vehicles, a transmitter / receiver controlled by an operating system; the unmanned aerial vehicle is configured to assume the role of an arbitrator in a DDL session and to control operation of the plurality of client nodes by defining operational cycles for communication and allocating bandwidth to each of the plurality of client nodes for each operational cycle in response to bandwidth requests from the plurality of client nodes; the unmanned aerial vehicle as the arbitration mechanism is configured to respond to the bandwidth requests from the plurality of client nodes and allocate bandwidth based on the needs of each of the requests during an operating cycle to maximize available bandwidth for a most necessary transmission purpose and reduce bandwidth for a less necessary transmission purpose; The unmanned aerial vehicle is further configured to transfer the role of the arbitration mechanism to another node when the unmanned aerial vehicle serves as the arbitration mechanism and receives a request from another node to transfer the role of the arbitration mechanism.

20. 20. The unmanned aerial vehicle of claim 19, The unmanned aerial vehicle as the arbitration mechanism is configured to receive an initial request for a desired bandwidth allocation from a non-arbitration node, allocate bandwidth in response to the initial request from the non-arbitration node, and enable the requesting non-arbitration node to participate in a DDL session.

Images