Enable breadcrumbs token at /includes/pageheader.html.twig

Sponsored: Verifying Resilience Over Networks

Communications is an integral part of any Army, Navy, Air or Space Force.

“No Comms, No Bombs” is the mantra of Military Signals Divisions (Brigades or Corps), and they’re right: Communications is an integral part of any Army, Navy, Air or Space Force.

Luckily the reverse: Comms => Bombs, is not true and comms go far further in the modern military than providing time and location information for bombing. No Comms also means no search and rescue, no logistics support, no tactical awareness, ...

Examples of communications go:

  • from the seemingly mundane, but hugely morale boosting, communications systems that allow deployed troops to communicate with their families back home
  • through, vital “housekeeping” systems:
    where are my assets?,
    what state of availability or repair are they in?
    ...all viewed from national, command, formation or unit perspectives.
  • to leading edge tactical systems

Much of this is delivered by network circuits with limited bandwidth, very high latency (satcoms in particular), and sometimes significant data loss.

The point is, that unlike commercial networks, it’s not as simple as finding a better network circuit by going to another provider or getting an upgrade from your existing provider. In the military, you’re stuck with the circuits you have. 

These networks have been referred to in two ways:

  1. Disadvantaged - limited by their very nature
  2. Degraded - normally OK, but not working well at this time,
    possibly due to overload
    Or environment, e.g. terrain, weather
    Or enemy interference.

Applications must work in these environment “as best they can.”

So, the requirement is for networks/devices to employ techniques like:

  • Properly prioritizing important traffic over lesser types in limited bandwidth conditions
  • Changing networks or bearers dynamically, based on availability and performance
  • Understanding an application’s needs, e.g. to have lower latency and route it accordingly.

And applications must be architected to cope with either always poor (disadvantaged) or sometimes poor (degraded) network conditions by:

  • Scaling down transmission rates as networks get worse, and vitally doing the opposite when network get better
  • Being able to auto restart transfers of large objects like mapping and asset databases without going back to the start, and thereby not waste more precious resources
  • By design, hold such data in a modular fashion, not monolithically so that small updates are possible
  • Dynamically change to lower quality & lower bit rate codecs for coice and video when required
  • Implementing reliable communications protocols, more suitable for poor networks than TCP-based ones
  • Implement caching so that the network is not used when a local cached copy will suffice.

And that’s just the start.

The problem becomes: “How will you verify your applications’ resilience in these disadvantaged or degraded environments before deployment?”

You clearly don’t want to be arriving at a field trial or an official certification process having not fully tested your application in the right network, with suitably disadvantaged or degraded conditions—that would be “failing to prepare” and you know what they say about that!  Furthermore, the cost of failing at “trials” is significant both monetarily and reputationally.

So how are you going to do that?

One proven and cost-effective approach is to use Software Defined Test Networks (STDNs), which can act like a wide range of real-world environments including large scale (multiple hundreds of connections), point-to-point, meshed, tactical or strategic networks. Using this type of technology, you can create different scenarios to dynamically change the network experience in order to test how well applications, devices and services cope with variations in network quality and availability, so that you can be confident they will perform when it matters.

STDNs also offer the advantage that their use cuts down on the number of expensive live trials that need to be conducted during the development life cycle, thereby saving money.

To learn more and receive a copy of our Defense Technical Briefing go to https://itrinegy.com/solution-by-industry/military/ 


 Frank Puranik is a senior technical specialist with iTrinegy.