The ASTi radio environment does not implement any specific bandwidth overload handling techniques since these very techniques could introduce undesirable side effects in normal operation. The core problem is that audio data is a true realtime problem, and any additional processing (or in this case a side process of load monitoring) can only take away from the main processing task of translating audio data into analog audio. Currently, ASTi systems are operating in complex environments that typically experience loads of hundreds of radio channels and many simultaneous transmission streams both in receive and transmit states to/from individual nodes.

Latency is of crucial concern with audio since beyond a certain value (which is somewhat subjective) any delay introduced into the signal path becomes noticeable and distracting up to a point where normal communication is almost impossible due to excessive bi-direction delays (any delay of the order of 120mS upwards is regarded as noticeable from a human physcoacoustic perspective). Therefore any additional process looking at bandwidth loading and applying some kind of post-processing process to reduce bandwidth of the transmitted audio data stream can only but introduce overhead.

(Note that the algorithm used, would have to by necessity attempt to reduce the bandwidth of the signal data portion of the transmitted signal in response to an identified bandwidth load condition seen on the network. This would require additional data being transmitted with the signal to allow receivers of this data to know what algorithm to apply to extract the data, which would have the opposite effect of adding additional load to the system).

The core problem of an overloaded network is that data packets can be dropped, arrive out of order or get corrupted. Unfortunately retransmission of such data does not fix the problem since the data is required in realtime. Unless of course we introduce extended data buffering, which has the undesired effect of adding unnecessary latency...

Underneath all of this discussion is the unwritten assumption that we have a perfect environment that is supporting the infrastructure used to transfer the data around. This of course is not the case. The RTI software that HLA requires is certainly not oriented toward realtime-streaming data, and as such we do have an artificial limit of approximately 16 audio streams through the RTI for any particular node. This is far reduced from the DIS limit of around 64 active streams that our systems in DIS mode can handle. (Please note I am referring to active audio streams that are being transmitted or received - there may of course be many more audio data streams on the network that are being 'ignored' since they do not match in frequency, or mode, or are out of range, etc). ASTi does have an approach to avoid the RTI bottleneck - this being known as backchanneling data. We can define certain data types to not use the RTI and simply pass them directly onto the network in a similar fashion to DIS. This has the disadvantage of the data being non-HLA but does have the advantage in that the number of audio streams then jumps up to that of a pure DIS system. The most logical application of this technique is to define the signal audio data to use backchannel networking, whilst maintaining the transmitter and receiver data as HLA. Since the signal data is the high consumer of RTI capability (due to numerous and near continuous stream of packets with audio data) it makes most sense to avoid the RTI. It is also worth noting that very few (if any) other systems have any interest in subscribing to the audio data, other than other radios, which assuming they are also supplied by ASTi will therefore be compatible.