NetAgility: Transport Bonding and Automated Failover
CW2 Quintero checks a MMT terminal, one of the transports used to test NetAgility

NetAgility: Transport Bonding and Automated Failover


Commercial off the Shelf (COTS) flyaway kits give US Army units the capability to deploy systems that extend network access to users quickly. A multitude of transport options provides flexibility for determining which package fits each unique situation. The problem: As transport options increase, there lacks a simple way to aggregate bandwidth or autonomously switch between different transport options. COTS Flyaway Communications Kit with multiple transport options would benefit from automated transport failover and bonding in order to maximize bandwidth and minimize the need for on-site signal support personnel. Software Defined Networking (SDN) virtual machines at the tactical edge and SDN Aggregator in the cloud enable bonding and automated transport failover regardless of transport medium and aids in the creation of easy to operate communications packages for units at every level.

Background

Our command has 45 commercial off-the-shelf (COTS) Network Extension communications Kits (NEK). Of these, 14 are medium packages capable of running multiple network enclaves and supporting a mobile command post of approximately 45 personnel. These medium kits use a variety of transport options, from 4G/LTE and Low Earth Orbit (LEO) satellite terminals to Geo Stationary Orbit (GEO) satellite terminals. These transport options enable us to stay online in any environment but require manual intervention when switching between them and offer no native transport bonding. We try to design these communication packages so that a Soldier from any occupational background can operate them. Having an automatic transport failover mechanism at the command post would decrease the amount of downtime and troubleshooting by Soldiers whose primary job function is not networking related.

Solution

Viasat’s Internal Research and Development (IRAD) funded NetAgility software enables an improved user connectivity experience in both stationary and dynamic environments. At the core of Viasat’s solution is the ability to aggregate traffic across many different communication paths. In the case of concurrent communication paths, this provides the user with improved bandwidth performance, by aggregating the connections together to provide a higher capacity logical connection to the user. The NetAgility solution will also automatically measure the performance and throughput of each link and will adjust the traffic. From the user’s perspective, this allows for seamless connectivity, despite network traffic using one or more communication paths. The bonding router component will take these connections and transmit portions of the client application flow across all available links. The aggregation server will combine the results back together and provide them to the intended destination. In the case that not all transports are aggregated or bonded, the software will automatically failover or switch between designated links creating an automatic primary, alternative, contingency, and emergency (PACE) plan. The NetAgility Router was developed specifically for these types of tactical networks. The design is based on architectural concepts derived from substantial commercial investment in SDN/SD-WAN technology, yet can scale from embedded systems to cloud compute. It can be deployed bare-metal, virtualized (ESXi, KVM, OpenStack, AWS, etc.) and Viasat is working towards a containerized approach.

Testing

Our initial testing utilized a 3-port PACSTAR server running Viasat NetAgility vSDR for transport bonding and failover. A 10-port PACSTAR switch enabled up to six transport options. Transports used included 4G/LTE hotspots, a Starlink LEO satellite terminal, a High Capacity Multi Mission Terminal (MMT) GEO satellite terminal and a Wideband Global SATCOM (WGS) connected Hawkeye III GEO satellite terminal. The 4G/LTE Hotspot, Starlink and MMT are commercial services out of the box. As such, they did not require any additional configuration to connect to the Amazon Web Services (AWS) hosted aggregator. The WGS terminals required a Gateway Access Request (GAR) change to provide commercial internet access. Visibility on the status of connected transports could be viewed in the NetAgility GUI via a management client connected to one of the two LAN port as well as the connection status to the AWS hosted Aggregator. Initial connection/set-up time to the aggregator averaged around 4 minutes for each transport option and failover time once connected ranged between 10 and 30 seconds. Convergence to a better connection was instantaneous once the NetAgility software saw that a stable and more advantaged communication path was available. 

No alt text provided for this image

Transport setup tested

I.            4G/LTE (Cradlepoint) (Hotspot)

II.           Starlink (LEO satellite terminal)

III.          Multi Mission Terminal (MMT) (GEO High Capacity KA satellite terminal)

IV.         Hawkeye III Lite (WGS GEO satellite terminal W/ Commercial Access)

No alt text provided for this image

Baseband setup tested

1.           PACSTAR 451 server module (running NetAgility)

2.           PACSTAR 441 router module (Unclassified)

3.           PACSTAR 441 router module (Classified)

4.           PACSTAR 441 router module (Mission Partner)

5.           NetAgility Management Client

No alt text provided for this image

Other considerations

·        Echelon requirement recommendations:

o  Brigade or higher recommend a 5-port server module (Allow 4 transport options)

o  Battalion or lower recommend a 3-port server module (Allow 2 transport options)

·        GEO bonding was not functional during the validation period. Viasat engineers are working on ways to bond these connections

·        The NetAgility GUI is basic and still needs some work but will allow you to see the status of the individual tunnel interfaces that are bonding the transports. Having information regarding the health of each transport and a graphical interpretation of the bonding tunnels would be a benefit in future builds

Conclusion

               The increasing reliance on COTS communication equipment and the security and performance they can provide today means having a growing arsenal of transport options. Having the ability to automate communication path failover and incorporate bonding of these transports, to maximize limited bandwidth, would significantly enhance user experience, reduce down time when transport systems fail and ultimately enhance mission command capabilities for units at every level.

 

Ronnie Eriksson

CTO, USARNORTH (5th Army)

2y

Sean Robbins I deleted your question about the bonding by accident. That screenshot was using two LTE connections:

  • No alternative text description for this image
Like
Reply
Sean Robbins

Network Engineer | Virtualization Enthusiast | TS/SCI | Retired CW3 US ARMY

2y

Great job on this. But with papers like these i have to play devils advocate otherwise im not doing the signal corps justice. My biggest issues here are the bills for the LTE and Starlink usage. Coupled with the antenna size, terminal G/T and EIRP for the GEO/ WGS birds. Why not use a band less affected by rainfade (it being not available is a valid reaponse as i know the EMS is crowded)? If these have small aperture antenna how do you propse to support a full BDE? Also, who foots the bill for data usage on commercial usage?

Like
Reply
Russell Glenn

Cyber Solutions Engineer at Viasat, Inc.

2y

Chief Ronnie Eriksson, great write up and excited to support the mission and enhancing network resilience on top of fielded platforms like PacStar's 400 series! More to follow! #TacticalSDN, #NetAgility, driving to #AnyPlatformAnyNetworkAnyWhere

Rich Baisley .. look familiar? Like Minds! PACSTAR & MBK's

Like
Reply

To view or add a comment, sign in

Insights from the community

Others also viewed

Explore topics