Home >> October 2014 Edition >> New SATCOM Design Feature Sets For Next Generation Products
New SATCOM Design Feature Sets For Next Generation Products
By Karl Fuchs, Senior Contributor

 

When at tradeshows or other industry events, we are often asked, “What are you working on these days?” Of course, the question actually is, “What will the next generation of satellite router look like and what feature sets will it have?” 

In the past, the answer could detail one or two remotes with fairly broad feature sets. Today, however, as satellite communications has entered new markets with diverse needs that span the spectrum from airborne to consumer, a broader portfolio of satellite routers is required. 

One fairly ubiquitous requirement across all market segments of next-generation remotes is to reduce size, weight and power (SWaP). Nowhere is SWaP more important than the man-portable market. The importance of reducing the physical size of the terminal is self-explanatory, but the more important element is the need to reduce power draw. 

From a systems perspective, the number of batteries required to accomplish a mission truly determines the soldier’s load. Even in the fixed terminal market, size and weight are important. New developments are under way to integrate the digital side of a satellite router directly with a block upconverter (BUC) through an I and Q interface. These remote routers can be mounted to the antenna and run by power over Ethernet. This configuration greatly simplifies the RF chain and eliminates the need for inter facility link (IFL) cable runs and electrical power on the roof. 

The new High Throughput Satellite (HTS) architecture with the promise of global coverage is driving the demand for mission flexibility. End-users need to be able to use government satellite assets when necessary and appropriate, and yet have the flexibility to leverage commercial HTS when needed. 

In addition to HTS, the DoD uses a number of waveforms in various programs. True interoperability would mean standardizing on a single platform, adopting an industry standard waveform or leveraging a software-defined radio (SDR). Of course, each approach has pluses and minuses. 

Standardizing on a single, potentially proprietary platform often provides the best technical solution but leaves the end-user vulnerable to all the inherent risks of a single vendor solution. The adoption of a standardized waveform can be effective and allows for vendor interoperability in the case of simple topologies such as single channel per carrier (SCPC). However, such falls far short when more spectrally efficient, and therefore more complex, topologies, such as time division multiple access (TDMA), are employed. In TDMA systems, waveform interoperability is not the limiting factor. It is simple enough to describe both an outbound and inbound carrier in which multiple vendors’ equipment could lock and pass data. The efficiency of a TDMA system is derived from the system being able to take advantage of the statistical nature of bursty IP data and integrate a network-wide remote burst plan. 

These TDMA time plans are tightly coupled to a system’s quality of service (QoS) and de-queuing mechanisms. The ability to deliver an over-subscribed and therefore spectrally efficient network—which provides tight traffic characteristics such as jitter to allow for real-time, voice and video data—cannot simply be defined in a waveform document. 

The real efficiencies of TDMA systems lie in the intellectual property of the individual suppliers. The software-defined radio (SDR) option can be a compelling one. The promise of an SDR is that no matter the mission requirements—e.g., SCPC, TDMA, supervisory control and data acquisition (SCADA) and so on—the software image on a single device is displayed to meet the need. 

The complexity of the design of an SDR comes in when we try to push the limits of a hardware design. The conventional wisdom is that it is hard enough to make complex software work on purpose-designed hardware, let alone support a wide range of software. The other perhaps more intractable problem is that of intellectual property rights. Given there are a number of proprietary satellite solutions deployed in the DoD, vendors may not be open to allowing their waveforms instantiated on a competitor’s SDR.

Applications in the DoD and commercial markets have designers of next-generation remotes building in separate processors. These processors can be PC104 form factor or the like and provide a wide range of possibilities.

For example, a processor could run routing code to off load layer 3 processing requirements. Other applications include providing a moving map with effective isotropically radiated power (EIRP) contour overlays for airborne situational awareness.

Looking at more distant horizons, much attention is being paid to non-geosynchronous satellite constellations. 

Recent announcements by Google and others have satellite terminal vendors grappling to understand the true impact of these Low Earth Orbiting (LEO) satellites and their inherent power and bandwidth advantages. Clearly, these developments could open satellite to new markets, but the question then becomes, “How far can satellite go in a market dominated by terrestrial wireless?” 

It’s too early to see how the LEO market plays out. However, if the LEO market proves to be valuable for satellite, vendors will be designing product with SWaP in mind. Additionally, a broader portfolio of next generation satellite routers will be available to support the breadth of new SATCOM developments.

About the author
Karl Fuchs is vice president of technology for iDirect Government Technologies (iGT). He joined iGT in 2004 as the director of sales engineering, just as the satellite-based IP communications company was expanding its very small aperture satellite (VSAT) market presence into the federal government and international Internet Protocol (IP) networking world. He now works as the vice president of technology.

With more than 20 years of experience in technology and the federal government, Fuchs leads iGT’s team of federal systems engineers and serves as chief architect for new product integration.

Prior to joining iGT, Fuchs was director of systems engineering at Nortel Networks, where he oversaw the Verizon account team of systems engineers, leading the design of IP, frame relay, asynchronous transfer mode (ATM) and dense wavelength division multiplexing (DWDM) networks. Before joining Nortel, he designed IP and ATM networks for Sprint and the federal government. Fuchs holds a Bachelor of Science degree in electrical engineering from George Mason University, Fairfax, Virginia, and an MBA from Averett University, Danville, Virginia.