Digital Transformation: Interoperability, Open Standards and Next Level Flexibility
The views expressed in this article do not officially represent the views of the U.S. Military or the United States government. The appearance of U.S. Department of Defense, DoD visual information, does not imply, or constitute, DoD endorsement.
John Gilroy — Host, Constellation
Welcome to Constellations the podcast from Kratos. We’ll be discussing the challenges associated with interoperability and how industry can support the digital transformation of space and satellite with our three guests.
The first question is for Lt. Col. Thompson, the space systems architect with the U.S. Space Force (USSF) where he is working to advance U.S. government, commercial and coalition partner MILSATCOM capabilities as an integrated enterprise. There seems to be a growing desire for the U.S. military and commercial satellite ground systems to be able to operate together in a coordinated way. What’s driving this?
Lt. Col. G. Thompson
The need is being driven for many factors, including our operational needs for mission assurance and budgetary efficiencies for more effective use of available ground assets. Ground is a critical component to the end-to-end communications that U.S. forces and our allies rely on to perform their missions each day.
Many of the SATCOM services include connection to ground sites that act as gateways to move data across terrestrial links to destinations worldwide. Unfortunately, how we plan this end-to-end connect is often closed and inflexible.
Breaking this paradigm is important to ensure the next level of flexibility, which is the ability to transition between military and commercial space and ground systems independently and at the speed of need. This is a hard problem due to the way that many of these connections are currently developed, procured, planned and operated.
Standards often form the basis for ensuring that new technologies and innovations work together and that products from different companies will be mutually compatible. So, what role do you see open standards playing to make commercial and military ground systems more interoperable?
Lt. Col. G. Thompson
Standards are a key tenet of MOSA, or Modular Open Systems Architecture, which is a priority here to enact as guardrails to guide our programs to be more interoperable. This also helps to prevent vendor lock when applied to the right level of our architecture.
From left to right: Stuart Daughtridge, Lt. Col. Gary
Thompson and Ben Hilburn.
We need to develop standardized interfaces at our portfolio level, architecture that maps to lower level program or implementation architectures to meet our desired mission capability. These standards need to be open, and consensus-based, to truly reach MOSA ideals.
Our space systems architect engineering office has been participating in several consortia and groups to mature our approach for enterprise portfolio management. We are working with industry to incorporate best practices while minimizing the amount of changes needed in existing product lines, and facilitating the evolution of new product lines towards greater compliance with our interface standards.
Going a bit further, would simply complying with framework standards such as VITA 49 (VITA-49 is a generic packet-based protocol to convey digitized signal data and metadata pertaining to different reference points within a radio receiver) guarantee interoperability between a military and commercial satellite ground system?
Lt. Col. G. Thompson
VITA 49 plays an essential part in standardizing the underlying plumbing for interoperability at the IF transport layer. But interoperability at the data and application layers must also be built in. For this reason, at Space Systems Command, we’re working on flexible networking, cross mission, and interoperability standards to build on VITA 49 in DIFI, in order to enable interoperability between military and commercial ground networks.
We envision user networks that can be easily moved between different ground antenna sites operated by different service providers. Our MILSATCOM capabilities include a significant number of heritage systems, so applying middleware overlays can help us move towards data fusion sooner rather than waiting for a complete recapitalization of our terminals, space systems and ground segments. This approach allows us to harvest interoperability sooner and higher levels of mission assurance now. However, these are predicated on having defined in standards and interfaces. This also requires a retooling on how we plan and monitor these systems in providing their end-to-end connectivity.
Over the past couple years, we’ve done several demonstrations and have advanced standards for flexible terminals and SATCOM networking. In each demonstration, we were able to show a significant increase in our ability to detect where and why the end-to-end link broke and quickly restore to an alternate path. This knowledge, and having each appliance in the end-to- end connection become a sensor to provide critical data on the status of the mission traffic, is an important step to providing the user at the edge with the information they need to keep their link active.
This can’t work if we treat each end-to-end connection as a single connection to move our data. Having standards, which enable us to quickly reroute our data over the full inventory of government and commercial, space and ground service providers, is a revolutionary advancement in our delivery of MILSATCOM services.
I heard the phrase “application layer,” so, I’m tossing this over to Ben from Microsoft Azure where he is working on software radio and wireless in the cloud, including 5G and virtualized satellite communications. Ben, should open standards be applied to all elements of a satellite ground system, or are there certain areas where mandating standards could actually hinder competitive innovation?
Yes, an interesting question. There are many benefits to open standards and interoperability standards. But in the context of this question, it’s useful to think of two major ones. One is making technical development easier, and what’s transparent to the larger system or a customer. A second major benefit is in driving interoperability at the systems level.
We start to think of things such as where is it useful to disaggregate a system. In a satellite radio system, for example, where you have some higher-level application level processing, or radio processing, is there value in that entire chain being from a single vendor, monolithic, and completely one thing that’s inseparable? Or is there more value in disaggregating it such that you’re able to pick the pieces from the vendors that are providing the best products along the way. There’s all kinds of additional benefits that come with those questions.
In a disaggregated system, if you were able to upgrade the radio without changing the rest of the chain, for example, that allows you to do things such as accelerate your acquisition cycle and to accelerate your development cycle and build new capabilities. You don’t have to think about the entirety of the system.
The question comes to where can we use standards such as this to drive innovation — where is the line where it hinders competition? That question is different system to system. But I really think it comes down to what is transparent to a system integrator or an operator, and where does it drive value for them to benefit from these interoperable disaggregated systems. That’s kind of the dividing line that defines where you’re hindering competition if you go further, because you do want to allow vendors to be able to build their differentiated IP within a block and monetize that.
In an ideal world, what are the use cases for interoperability standards?
A great example is Ethernet, perhaps one of the most widely used, interoperable standards. Ethernet doesn’t care what’s on either end of a link. It doesn’t even care if it’s wired or wireless. Ethernet has created tremendous opportunity for innovation and technology advancement. It focused on creating a standard way for moving and understanding data, so that people building products or components that sit on either end of an Ethernet link could differentiate on what you do with that data and not to worry about understanding the data when they get it. Ethernet’s been around for a while, so a more recent example is the 5G community, ORAN, which is short for open radio access networks. In previous generations of cellular, the cellular operators were buying monolithic systems from the equipment providers... going back to the example in the previous question, about having to buy the radio and the modem and the processing all from a single vendor, that was really limiting what the operators could do. It was limiting acquiring new systems and upgrading systems. It added complexity to the maintenance of systems. When 5G was being built, the industry said, “This doesn’t make sense anymore.
We need an interoperable standard so that we can just buy a unit from the company that builds the best radio for my specific purpose and buy the processing from a different company that builds the best processing for my specific purpose.”
That industry has NOW rallied around ORAN and is fundamentally shaping the direction of 5G. ORAN IS used both commercially and in government, so it’s another great example of A successful application of interoperable standards.
What exactly is VITA 49 and the relationship to DIFI ?
VITA 49 is often thought of as a standard interface. That’s not really accurate. VITA 49 is more like a framework for building interfaces. It got a bad rep because lots of different vendors would produce equipment that they claimed was compliant with VITA 49 and none of them would work together, which kind of breaks the promises of interoperable standards.
VITA 49 isn’t a specific interface, but a way of creating interfaces. You’d have vendors creating VITA 49-based interfaces, but they all looked different, so you’d end up with a customer that would buy some piece of processing that ingested VITA 49 and some piece of hardware that produced VITA 49 and they couldn’t work together.
That’s exactly where DIFI lands. DIFI is based on VITA 49, but you could think of it as a VITA 49 schema, a specific implementation of a VITA 49 interface designed to support virtualized satellite communications in the ground segment. VITA 49’s been around for a while and so it allows us to benefit and leverage a really broad ecosystem of VITA 49-based technology and IP and vendors that already exist to solve interoperability for virtualized communications in a way that is going to be really impactful.
If VITA 49 has been around since the early 2000s, and DIFI is relatively new, then I have some questions for Stuart, the chairman of DIFI. Stuart, what is the status of the DIFI organization?
The DIFI organization published its 1.0 version of the specification at the close of August last year and, since then, the response from the industry has been fantastic. We’ve had steady growth with new members joining every week as well as excellent support from the U.S. DoD. What really counts for a standard is going from a document to adoption. We’ve had steady downloads of the specification from our website by more than 60 different organizations. The 1.0 specification has already been made a requirement in a recent U.S. Army RFI, which is exciting. And now our working groups are starting the management of the standard itself and to consider new standards that would help the industry go through a digital transformation. In the near future, we hope to be able to provide a free certification capability to the industry for self- certification, along with a third-party certification program.
What are the long-term goals for the DIFI organization?
We formed the organization to help enable the digital transformation of the satellite industry. The first step in that digital transformation is digitizing the IF infrastructure. We realized that wasn’t going to happen without a digital IF standard.
Analog frequencies, IF frequencies, provided a natural interoperability that’s lost once you go digital because there’s lots of different ways to stuff bits into a packet. When we looked to create the standard, we realized it wouldn’t be adopted unless it was simple and easy to adopt and pretty much non- threatening to the vendor community.
That’s what we focused on with our initial DIFI digital IF standard for that first step. We also think there’s lots of other areas around the digital architected system where standards could be of value — we’ll be focusing on those areas as we progress forward.
With everything going to the cloud and digital transformation, how will this impact the satellite industry?
Great question. Digital transformation is going to have huge impacts across the entire industry. I’ll answer that with a couple of examples. The first has already happened,and that’s basically enabled ‘ground system as a service’ for the Earth Observation (EO) market.
As little as five to ten years ago, if you put up an EO satellite, you had to consider building out your own ground infrastructure and that would require significant capital expenditure, as well recurring operations costs. However, now, with the availability of software modems and cloud compute capabilities, it’s enabled an entire ‘ground system as a service’ industry that can provide better coverage, excellent performance and even help get your data turned into products faster than custom-built ground systems, all for a very nominal pay-as-you-go pricing model.
They can do that because they’re able to amortize the costs of the system across multiple satellite operators. This is a significant change to the cost structure required to start an earth observation satellite business. This has had a huge impact on that part of the industry.
Another example is with respect to ground system architectures. If you looked at a block diagram of how satellite ground systems were built from the mid- 1970s and how they are constructed today, they would look basically the same — it hasn’t changed much. With a digital infrastructure, once you digitize as close to the antenna as you can, it enables a multitude of new architectures. You’re now able to use general compute and IP routing to replace your L-band plumbing and your signal processing so you can disaggregate your architecture and optimize it for the service you’re providing.
A third example is the impact on remote terminals. Currently, remote terminals are somewhat built around the modems that they integrate with — that’s because modems come from different suppliers and they don’t come in a standard size, shape or with standard interface points.
But in the future, terminals will not come with modems. What they’ll come with is generic compute packages and the modem will be a software application that can be loaded into the generic compute along with other applications.
Think about what that means. If you’re the terminal supplier, it greatly simplifies your offerings as you won’t need a different model antenna for each modem.
If you’re the terminal buyer, it greatly expands your supply chain because now any terminal can be compatible with any modem. Maybe most important of all is to think about the terminal user. They can now load up any modem they need and connect the terminal to any satellite or any network that’s available with that same terminal.
Consider the flexibility that creates, and then consider what if the terminal could be a flat panel antenna that could support multiple beams. That just adds a whole other dimension of flexibility.
Or think about a MILSATCOM application where you could use the same terminal one day to support a COMSATCOM application, and then the next day use it for a highly secure MILSATCOM application just by loading different application software into it to go from a commercial mode to a highly secure MILSATCOM mode. Digital transformation’s going to have impacts across the entire spectrum of the industry and open up new applications and opportunities that we’ve not even begun to consider.
It certainly sounds as though disaggregation unlocks flexibility. These are going to be exciting times in the next few years.
Listen to this and more than 100 other podcast interviews on Constellations.
See the full list of interviews and subscribe to the Constellation podcasts at: