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:
|
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