COMMAND MEETS COMMUNICATION

Interaction between the 
SWARM Command and Control System and the Communications Device

The specific syntax of the interface is NOT yet attempted. Neither are the bus interactions. Both of these will be designed later, and will serve as (or follow) a model for all the device communications of the Command and Control system 

 

 
Proposed Interface
Events
PacketHeaderReceived
Among the data are the sender, the packet type, the content length, and timestamps from the sender and the comm unit's receiver.
PacketContentReceived
Content of Packet has been completely received and (when necessary and possible) been reconstructed.
Packets that contain no content (such as an ACK) do not generate this call.
CollisionDetect
Due to interference thew reception of this packet could not be completed.
PacketLost
The packet could not be received without errors
PacketSent
An enqueued Packet (queued with packetTransmit) has been sent by the Comm System.		 
Methods
PacketTransmit
This the the method by which an assembled packet is presented to the comm system to be transmitted. Queueing will need to be performed as the system waits for Media Access. Currently MAC-related cuing and timing are being performed on the Network side of the Interface, but once our protocol is established, this should migrate to the Comm Side.
CarrierDetect
An access method for the read-only CarrierDetect bit (see below)		 
Properties
CarrierDetect
This is a boolean property that indicates that the radio is receiving a signal. It is true during normal reception, interference and successful jamming.
This might be implemented as a read-only property or as an access method (see above).		 
 
 

QUESTIONS & ANSWERS ABOUT COMM. SYSTEM CAPABILITIES:  

  1. What is the Signal to Noise threshold required to receive a new packet?
    We are working out issues of interference.  We assign each plane (for now) the same arbitrary transmitter power and use the inverse square law to sum up the signals at any given point. OK?Xxxzxzxzxzxzxz
    No solid Signal / Noise ratio is defined. 
    However it is pointed out that the transmitter power is NOT (as we assumed) a fixed value. We need to upgrade the simulation for a system where the transmitting node always minimizes its power level to avoid RF clutter in the battlefield. This will have a large affect on the networking. If well designed, the affect can be positive..   
  2. Is there a way to estimate error rates?
    We want to model uncorrectable errors in our system. Presumably these are a function of the signal/noise ratio. Is there a way to easily estimate this-- or is it more realistic just to have a cutoff point?
    No specifics.
  3. During an incoming packet, can a new, stronger signal 'usurp' the reception?
    Will a new signal be able to abort the reception of an earlier but weaker packet, and itself be immediately treated as the Incoming Packet?     If so, what is the signal strength ratio where this occurs?
    Current system does not provide for this.
  4. What is the minimum length of time before the identity of a packet is known?
    Presumably this id will be very close to the beginning of the packet header, but we do not know what the effects of error correction are. Must the whole packet be read and error corrected before any data are available? (In this case, the "id" we are concerned with is actually the id of the originating node.     )
    Entire packet must be read before any information is returned (in current design)
  5. What 'QoS' metrics might be available in the actual system?
    We want to compare routing alternatives for reliability and efficiency. Some measure of signal quality would be very useful. Can the Comm. System attach some figure(s) of merit to each packet it receives before passing it to the C&C unit? If so, what data? Bit errors (corrected, of course)?  Absolute Signal Strength? Signal/Noise? 
    Bit error count only.