MESSAGE CLASSES

Problem

Planes have different communications tasks with requirements. Unless these can be readily distinguished, they will waste resources: cluttering the system with unecessary message forwarding and acknowledgement and increasing the latency of themselves and the system as a whole.

 

Solution 

A communication system that establishes Message Classes. 

The Internet Analog
An example of such a mechanism is the Internet Protocol. IP supplies both UDP and TCP. UDP is a very low overhead, unregulated packet transmission protocol. It is also a lossy system.  TCP is not loss tolerant, but it burdens the system with a bigger packet header (from 8 bytes to 20), an adaptive transmission throttle. More importantly, it loads the network with much more traffic: every packet stream begins with a three-way handshake to establish a connection. On top of this, every packet of TCP requires a return ACK packet. There are also considerable system costs at each end of a TCP connection - buffers, tables, state,  etc - that limit the connections. 

Matching Applications to Protocols
On the Internet, applications use the appropriate mechanism. Applications that do not tolerate dropped (or missequenced) packets use TCP (email, http, ftp). UDP is favored by high-volume, loss-tolerant multimedia apps, such as streaming video or IP telephony. It is also used by many absolutely critical internet applications. For example DNS (the system that converts "//bigfun.net" into "65.188.246.217") uses UDP because it creates lots of packet traffic. Its requests and responses are single short packets and the TCP overhead would add at least three more packets to each DNS request.  The DNS information is critical however, and if a response is not received the requester will retransmit. By contrast, the Internet's ROuting Protocol uses UDP because RIP messages are not critical. They are sent periodically and overwrite the previous state - until they too are overwritten. A missed RIP update usually makes no difference and never introduces irrecoverable error.

SWARM Application Requirements
Just as these protocols were developed to serve different application needs, our best introduction of Message Classes begins with considering the various needs of our system.

Formation Position Broadcast
All the members of a formation must broadcast their position frequently. This avoids collision and permits negotiated group flight control. Each UAV is sending these messages periodically, and in a well populated formation, there are many such streams vying for channel access.

A formation, in our sense, is a group of UAVs performing coordinated flight. As we will see, it is very useful to constrain the diameter of a formation to the radius of a single reliable radio transmission. This might, for example, restrict a formation to no more than twenty miles wide. Coordinated groups can exceed this size - but they will not be classified as single formations and they will not be able to use specialized mechanisms for high-resolution positioning. Of course a group spread out over such distance will not have very high requirements for such positioning: collision avoidance is not a big problem and super-tight formations (eg:  flying phased arrays) cannot be that large, because their functionality (ie: wave front reconstruction)  requires high volume, low latency communications. 

Group Control 
The behavior of the group is directed by cooperative command and control decisions. Some of these may be preprogrammed by the Mission Planner. But most are dynamically modified variations of the program. Really, the goal is that essentially all control decisions are dynamically emerge from whatever autonomy these vehicles achieve. Dynamic decision-making demands that the resulting control decisions are reliably propagated to the members of the affected group. 
These group  control decisions demand less bandwidth than the formation position packets: although they are longer packets, they are far less frequent.  However unlike the formation position updates, these packets are important. Receipt of the packet must be guaranteed, and backed up with consequential recovery mechanisms.. 

A group, is a collection of UAVs with a common agenda. In the simplest case all the craft in a mission are part of the Mission Group, and this is the only group. All the members of a group can be in a formation - or some may be members of a formation while others serve relay functions. A group can have more than one formation.
More significantly: a group can contain multiple groups - and that groups can overlap. An individual UAV would generally subscribe to more than one group. 

For example a single craft might belong to these concentric groups:

  • Mission Group: all the planes launched on the mission group.
  • Surveillance Group: the operational planes in forward position.
  • Gravitometer Group: those planes carrying this sensor.

Peer-to-Peer Messaging 
We do not forsee support for individual point-to-point communication. The nature of our Command and Control is based on functional coordination of fluid agents - not specific plane-to-plane traffic. However, if two specific plane must exchange information, this is easily set up by creating a group of two.

Group-to-Group Coordination 
This is supported by a group of control hubs. When an individual UAV assumes the hub position for a group it assumes membership in this network. The hub concentrates data from the members of the group. It participates in high level decision making representing all its members and  disseminated decisions back to these members.

Back-to-Base Messaging 
The HQ/Base is a member of this high order group of hubs. In addition any group can open a direct channel with the base by creating group of two between hub and base.

Relay Members
Groups will include members who are not functional participants in originating, receiving or processing the content of the messages. These relay members provide the critical role of packet forwarding. In the message routing and network integrity mechanisms we have outlined, these relay members behave no differently than other members. However they belong to the group because of their geographic position (they may be dedicated to message relay - or it may be a background task). They resign from the group when topology and geometry make them obsolete. 

 

MESSAGE CLASSES
Our protocol design is very much a work in progress. Our goal is to provide efficient specialized message classes to serve these demands. Meanwhile, we want to keep the number of classes to a workable minimum. (Two or three different classes seems ideal.) Our current design contemplates these:

Formation Message 
These ephemeral messages are

 

Group Message 
These messages are critical and unrestricted in range. This class of message will be

 

Upstream Message
We may discover a need for a communication class dedicated to getting messages back to the base. The value of this class of message diminishes as the UAVs become increasingly autonomous. 
This class of message will be