In many ways, battlefield networks architecturally resemble a typical LAN/WAN, but the broader battlefield is far from a typical environment. The big difference is that platforms are on the move, so they must connect using RF technologies rather than wire or fiber. And that’s where things get tricky.
In many ways, battlefield networks architecturally resemble a typical LAN/WAN office or enterprise environment (Figure 1). There are end-point nodes—typically a vehicle, UAV, airplane, or even a dismounted soldier—which are rolled up into clusters (subnets) and inter-connected via battlefield routers. Communication is managed via IPv4/IPv6 for data, voice, and video, and the networks use flow control and typical terrestrial routing protocols just like the world’s Internet.
But the broader battlefield is not your typical enterprise, office, or home environment. Each platform (say, a Stryker vehicle) can have multiple computers that each represent an end node, and each platform may require its own router and have a LAN aboard (Figure 2). But the most striking difference is that battlefield assets will likely not connect via copper or fiber cable because the platforms are on the move. So how can they connect? Using RF technologies such as radios for local and beyond-line-of-sight (BLOS), or SATCOM for longer-range connectivity to distant entities such as CONUS (continental United States). UAVs or airborne assets hovering over the battlefield (or more likely, crisscrossing the sky at pseudo-random intervals) act as relay stations, not unlike mobile cell phone towers.
Challenges of the Battlefield Network
With interconnectivity provided by RF links, the challenges for battlefield networks are many. First, different service branches use different RF links for voice and data, and those links often don’t interoperate. Tactical data links such as CDL, Link-16, EPLRS, or TADIL-J are typically service-specific.
But aside from this not-so-easy to surmount obstacle, we’re talking about radio links for data. These aren’t 1GbE copper or 10/40GbE fiber cables. They are RF waves that on a good day might support 10Mbits/s data rates.
Even if these links were all interoperable, Radio A that is far away from Radio Z may not be able to broadcast or receive that far (due to power and obstacle limitations). That means a form of mesh networking is needed. That is, Radio A talks to Radio B, which relays data to Radio C… or whatever the most optimum jump-between path is. As well, radios may come and go as battlefield assets move. Interference, obstacles, too-long distances, and other physical and environmental conditions make radio data nets incredibly challenging. This ad hoc collection of radios that rely on each other is what Cisco calls a mobile ad hoc network, or MANET.
To create a LAN/WAN architecture like we’re used to seeing in the enterprise requires battlefield routers that can keep track of the location of other routers (including those on moving platforms like Strykers) and the destination nodes with which they’re trying to connect. And this occurs with nodes and inter-connecting links that are ever-changing as assets move around the battlefield and as radio capabilities change.
Cisco Mobile Ready Net Protocols in a Wide Array of Router Form Factors
Cisco has come up with a way to deal with this “radio-aware routing” problem by creating its Mobile Ready Net set of protocols that all of these assets utilize (Figure 3). Cisco’s Router Radio Control Protocol (R2CP) coupled with the open standard RFC 5578 “PPP over Ethernet (PPPoE)” provide ways to quantify the network, its characteristics, quality of service (QoS), and other essential metrics of an ever-changing ad hoc MANET.
Knowing the condition, location, available bandwidth, and other characteristics of each node and interconnecting router allows all assets to dynamically choose the best way to move packets around this dynamic battlefield network. As well, each networking hop—radio, router, end node, whatever—has to keep track of enough of the MANET picture to efficiently move the data around in such a way that the notional LAN/WAN architecture is preserved (Figure 4).
At GMS, we build battlefield routers in a variety of form factors, from blade servers based upon 3U VPX and 6U VME, to small form factor micro-servers using Intel Xeon D server processors, all the way up to Xeon E5 heavyweight servers in conduction- and air-cooled chassis over -40°C to +85°C (Figure 5). To implement battlefield networks, we use Cisco software routers and run them on co-processors or virtual machines in our hardware. Examples of Cisco routers that implement battlefield MANETs are the Embedded Services Router (ESR) 5921, and the software enterprise router Cisco 1000V.
In all cases, our hardware has ample processing, networking/switching, and storage to keep up with the ad hoc, mesh-style, rapidly evolving mobile battlefield network.