If you have not read our post about Low-SWaP, be sure to check it out for some great information about why Size, Weight and Power are critically important to consider with deployable communications.
When most people think about low SWaP, they tend to focus solely on the size of the box itself, without thinking about everything that comes with it. In this post, we will take a more holistic approach to Low SWaP and address things such as batteries, generators, peripherals, transportation, and support personnel.
Looks can be deceiving, and the size of any given device is only a small part of the big picture. In a forward-operating environment, each function performed by a device has a logistical trail that follows. Today, it is commonplace to utilize virtualization to bundle multiple capabilities on a single device — adding complexity. Let’s take a closer look at the bigger picture:
A forward-deployed communications network typically relies on locally-generated power. This could be a combination of generators, batteries, or solar. It is critical to plan for maximum draw (kilowatts) and minimum runtime – i.e. how many batteries, what size generator, and how much fuel will be required. In many cases, a locally-generated power source is shared with others, and communicators may not have control over the power source, so consider how will you handle brownouts, surges, or hard power-off situations. Is a UPS required? Ensure that equipment can operate repeatedly and reliably on the planned power source.
Consider the environmental requirements. Can a device operate under full load in the desert sun, or will it require air conditioning? If a device requires significant power, then it is also generating significant amounts of heat. How will it be cooled? If you plan on air conditioning, you will need power for air conditioners. Can the hardware sustain operations through a sandstorm, pouring rain, and freezing temperatures or does it need to be in a shelter with heat? Can the device sustain a drop out of the back of a vehicle? Does it need to be mounted in a rugged transit case?
Consider the devices will you need to provide for the end users; i.e. Radios, Phones, Encryptors, Notebooks/tablets, Batteries & Chargers. How will these devices be powered, and how will they attach to the network? Wired Ethernet, phone wire, fiber, wireless? If you plan to connect to an upstream network via Satellite, LMR, Microwave, etc, what equipment is needed for those connections? Make sure you have access for administration of key components – i.e. laptop, monitor/keyboard, serial connection, etc. Consider bringing spares for critical components. Consider how you will work with coalition partners and other agencies in the field – will you need to bring extra gateways and converters, or is your solution natively flexible? Interoperability is key.
Deployed networks continue to grow in complexity, and communicators often have responsibilities outside the realm of communications. This leaves little time for training, creating a knowledge gap often addressed by third-party field support. Civilian contractors deploy alongside military personnel, and manufacturer’s reps deploy alongside first responders and public safety personnel to situations in the field. This is costly and can place civilian personnel at risk in the field. When identifying components of your forward-deployed communications network, seek solutions that are easy to use and intuitive. These will empower communicators to quickly establish communications in the field without on-site assistance from third parties.
To bring all this together, let’s consider how to move everything. Equipment, Peripherals, Spares, Shelters, Power, Air Conditioning, Vehicles, Personnel, Lodging, Food and Fuel. Consider how often to restock food and other supplies. How much fuel is needed, and how often? Can you get fuel delivered regularly and on time, or do you need a surplus reserve? U.S. Army Logistics estimates that in Operation Iraqi Freedom, fuel convoys pictured below constituted 70% of vehicular traffic on attack-prone main routes.
Generic Server vs SLICE 2100
Let’s look at a use case involving two call controllers. On the left is a small form factor server running a software-based IP call controller; on the right is a REDCOM SLICE® 2100. The SLICE 2100 is equipped with T1s, analog lines, radio interface, VoIP and conference capability. While both platforms share some common features, they clearly serve very different purposes.
At first glance, it would appear that the small server is the more efficient solution. After all, it’s a lot more compact than the SLICE 2100. In an IP-only environment, this is likely true.
However, as we discussed, the concept of Low SWaP needs to take into account everything around the main box. A forward-deployed communications environment is rarely IP-only. There is typically a mix of LMR, TDM, analog and VoIP – particularly in coalition and inter-agency deployments. The REDCOM SLICE 2100 natively supports these on a single platform and can be managed by a single communicator. If you want to be able to connect with these various network types on the small server, you will need to add a REDCOM SLICE/HDX or third-party gateways. The more third-party gateway devices are added, the less value there is with having a smaller initial box – and even more importantly, the increased complexity may require additional field support and delay setup time.
At the end of the day, the size of ‘the box’ is only as important as the trail that follows it. An ideal deployable solution will not only be low SWaP, but it will also minimize dependence on third-party field support, maximize interoperability, and enable the communicator to rapidly establish service with minimal training. When looking at all the pieces of the puzzle, we can have a better understanding of the true cost and scale of a proposed deployable solution.