Space is a Network.
Constellations is Your Connection.
Transcript:
John Gilroy: The views expressed in this podcast or on www.constellationspodcast.com, 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: Welcome to Constellations the podcast from Kratos. My name is John Gilroy and I’ll be your moderator. Today, we have three guests. We have Lieutenant Colonel Gary Thompson, Spectrum Warfare Division, Space Systems Command, U.S. Space Force; Ben Hilburn, Head of Strategic Initiatives, Azure Spectrum Technologies at Microsoft; and Stuart Daughtridge, Chairman, Digital Intermediate Frequency Interoperability Consortium, or for us mere mortals, just DIFI.
John Gilroy: Our guests are here to discuss needs and challenges associated with interoperability and how industry can support the digital transformation of space, satellite, and related industries. First of all, let me introduce our guests. Lieutenant Colonel Gary Thompson is a space systems architect with the U.S. Space Force. He advises and assists on matters concerning business practices and technologies to advance U.S. government commercial and coalition partner satellite communications capabilities as an integrated enterprise. And that’s the key word: integrated enterprise.
John Gilroy: Mr. Benjamin Hilburn is of strategic initiatives on the Azure spectrum technology team at Microsoft, where he is working on new topics in software radio and wireless on the cloud, including 5G cloud-born RF sensing and virtualized satellite communications. Mr. Stuart Daughtridge is director and chair of DIFI. He has been in the satellite and aerospace industry since 1986. In his current position, he leads Kratos’s satellite ground segment technology research and development efforts.
John Gilroy: Okay, we’re going to start with the Lieutenant Colonel. Lt. Col. Thompson, it seems there’s a growing desire for the U.S. military and commercial satellite ground system to be able to operate together in a coordinated way. So what’s driving this, what’s pushing this need?
Lt. Col. G. Thompson: Well, thank you, sir, for having me on today. As they say, a long time listener, first time caller. So, I appreciate this opportunity and this question, because this need is being driven for many factors, including our operational needs for mission assurance and budgetary efficiencies that can stem 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.
Lt. Col. G. Thompson: Many of the SATCOM services include connection to ground sites, which 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 in nature. 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.
John Gilroy: Lieutenant Colonel Thompson, standards often form the basis for the introduction of new technologies and innovations, and ensure that products, components, and services supplied by different companies will be mutually compatible. So, what role you see open standards filling in making commercial and military ground systems more interoperable?
Lt. Col. G. Thompson: Another great question. The standard of the foundation for discipline systems engineering to go after the hard problems that I mentioned earlier. Standards are a key tenet of MOSA, or Modular Open Systems Architecture, which is a priority here as space systems architect, to enact guardrails to guide our programs to be more interoperable. This also helps to prevent vendor lock when we apply the MOSA principles to the right level of our architecture.
Lt. Col. G. Thompson: We need to be able to bring in the best intellectual property capabilities. And in order to do this, we need to develop standardized interfaces at our portfolio level. The portfolio level architecture is where we map force design architectures 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 and existing product lines towards greater compliance with our interface standards.
John Gilroy: I want to continue this a little bit further here. Lieutenant Colonel Thompson, would simply complying with framework standards, such as VITA 49, guarantee interoperability between a military and commercial satellite ground system? Is that enough?
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 worth 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.
Lt. Col. G. Thompson: What we envision are user networks that can be easily moved between different ground antenna sites operated by different service providers. Our SATCOM capabilities, 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. But 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.
Lt. Col. G. Thompson: 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, providing 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 SATCOM services.
John Gilroy: Hey, Ben, the Lieutenant Colonel just used the phrase “application layer.” So it’s natural and logical for me to toss over to you at Microsoft. So 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 competition innovation?
Ben Hilburn: Yeah, that’s a really interesting question. So there’s a lot of benefits to open standards and interoperability standards. But, for in the context of this question, I think it’s useful to think of two major ones. So one is making technical development easier, right? So to pick an example, PCI express. PCI express is a standard way of moving around data. It exists not only in your big computers, but in cabled connections to phones. Actually look a lot like PCI express connections.
Ben Hilburn: But, in a lot of cases, that’s at the level that’s transparent to the larger system or a customer. For the most part, when you go to build some compute capability, you’re not worried about what version of the PCI express bus is sitting in that thing. But what’s not transparent, and a second major benefit is in driving interoperability at the systems level, right? So there, we start to think of things like where is it useful to disaggregate a system. And by that I mean if you think of, let’s think of a radio, or a satellite radio system for example, where you have some higher-level processing, perhaps application level processing, you’ve got some radio processing, and you have a radio unit, right?
Ben Hilburn: 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. And there’s all kinds of additional benefits that come along with that, right? If in a disaggregated system, you were able to, for example, upgrade the radio without changing the rest of the chain, which allows you to do things like accelerate your acquisition cycle. It allows you to accelerate your development cycle, which you’re building new capabilities. You don’t have to think about the entirety of the system.
Ben Hilburn: So I think the question goes, comes down to, okay, where can we use standards like this to drive innovation and where is the line for where it hinders competition? And so it’s different from 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? And I think 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.
John Gilroy: Gentlemen, thousands of people from all over the world have listened to this podcast. Go to Google and type in “Constellations podcast” to get to our show notes page. Here, you can get transcripts for all 100 plus interviews. Also, you can sign up for free email notifications for future episodes.
John Gilroy: You know, Ben, both you and the Lieutenant Colonel use this word “interoperability.” And that’s kind of the focus of the whole discussion today. So in an ideal world, what are the ideal use cases for interoperability standards? I mean, can you share an example of a successful application of an interoperable standard?
Ben Hilburn: Oh yeah, sure. A great example of a successful use of interoperable standard 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, right? Ethernet has created tremendous opportunity for innovation and technology advancement. And so I think that’s a really strong example. It focused on creating a standard way for moving and understanding data, such 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 having to worry that they’re not going to understand the data when they get it, right?
Ben Hilburn: Taking perhaps a more recent example, Ethernet’s been around for a while, I’d point to the 5G community, ORAN. ORAN is short for open ran, or open radio access networks. And the short story there is, in previous generations of cellular, the cellular operators were buying monolithic systems from the equipment providers, right? So kind of going back to the example in the previous question, you asked me, John, they have to buy the radio and the modem and the processing all from a single vendor. And that was really limiting what the operators could do.
Ben Hilburn: It was limiting acquiring new systems, upgrading systems, right? It introduced additional complexity into the maintenance of systems, and as they were putting together 5G, there was kind of this industry wide, “We’re tired of this. 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 by the processing from a different company that builds the best processing for my specific purpose.” Right? And that industry has really rallied around ORAN and is fundamentally shaping the direction of 5G. And it’s used both commercially and in government. I think it’s another great example of successful application of interoperable standards.
John Gilroy: Hey, Ben, when I was doing show prep for this interview, I came across VITA 49. And at first I thought I was a Vitamin.
Ben Hilburn: Oh yeah.
John Gilroy: No, no. It’s not a vitamin. So maybe people are listening go, “Hey, this a vitamin show?” No, this is not a vitamin show. So what exactly is VITA 49 and what relationship to DIFI here?
Ben Hilburn: Ooh, Okay. So VITA (vi-tah) 49 or VITA (vee-tah) 49. I I’m actually not sure what they prefer. I hear it both ways. I use VITA (vi-tah) though. So VITA 49, it’s often thought of as a standard interface. That’s not really quite accurate though. VITA 49 is more like a framework for building interfaces. It kind of got this 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.
Ben Hilburn: But the problem is that VITA 49 is not a specific interface. VITA 49 is a way of creating interfaces, right? So what ended up happening is every different vendor was indeed creating VITA 49-based interface, but they all looked different, right? And so you’d end up, you’d have 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. And that actually is exactly where DIFI lands.
Ben Hilburn: So DIFI is based on VITA 49, actually, you could think of it as a VITA 49 schema. So it is a specific implementation of a VITA 49 interface, designed to support virtualized satellite communications on the ground, in the ground segment. 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, because VITA 49’s been around for a while, but then create something that is specific and solves interoperability in the ground segment for virtual lives communications in a way that I think is going to be really impactful.
John Gilroy: Speaking of frameworks, I want to put a framework on, in this answer. So VITA 49 has really been around since the early 2000s. And DIFI is really relatively new, isn’t it?
Ben Hilburn: Yeah. That’s right. And Stuart actually probably has a better memory than I do. Stuart, when was the first board meeting for DIFI? Is that two months ago? It’s really recent.
Stuart Daughtridge: It was in August. August 13th.
Ben Hilburn: August. Well, it’s November now, so three months, but yes.
John Gilroy: Well, Ben, that was a great toss. Now I’ve got a couple questions for Stuart here. So Stuart, you are the chairman. So what exactly is the status of the DIFI organization?
Stuart Daughtridge: So the DIFI organization was, as we just discussed, was established and published its 1.0 version of the specification in the end of August timeframe. And since then, the response from the industry has been fantastic. We’ve had steady growth in membership with several new members joining every week. We’ve had excellent support from the U.S. DOD. But more importantly, considering that it’s a standard, what really counts is all we have is a document until it’s adopted. And from an adoption point of view, we’ve had steady downloads of the specification from our website by over 60 different organizations.
Stuart Daughtridge: The 1.0 specification has already been made a requirement in a recent army RFI, so really excited about that. And now we’re starting to up our working groups to start the management of the standard itself and to consider new standards that would help the industry go through a digital transformation. And lastly, in the near future, we’re going to be starting up working groups about how we do certification against the standard. So we hope to be able to provide a free certification capability to the industry for self certification, along with a third party certification program.
John Gilroy: You know, Stuart, when we were talking to Ben, we mentioned this VITA 49. And it’s been around for a while so maybe DIFI will be around for a while. So what are your long term goals for the organization?
Stuart Daughtridge: Yeah, so the reason we formed the organization was really to help enable the digital transformation of the satellite industry. The first step in that digital transformation is really digitizing the IF infrastructure. And 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.
Stuart Daughtridge: So when we looked at creating the standard, the other thing we realized is it wouldn’t be adopted unless it was pretty simple and easy to adopt and pretty much, much non-threatening to the vendor community. And so that’s what we really focused on with our initial DIFI digital IF standard, and we think we’re pretty doing pretty well along that first step. But we also think there’s lots of other areas around the digital architected system where standards could be of value. And we’ll be putting focus on those areas within the organization going forward.
John Gilroy: Stuart, I was at your website and the logo says it all. You don’t have to speak English to understand what’s going on between analog to digital. Talk about making things simple, it’s very simple to understand the goals of your organization. And this digital transformation sure is a term that’s bandied about here in the Washington DC area. Everyone’s going the cloud and making a digital transformation to this and that. People are talking about internet of things, the internet of military things. So speaking of digital transformations, how will this digital transformation impact the satellite industry?
Stuart Daughtridge: That is a great question. And it’s also one that I think’s kind of hard to answer because digital transformation is going to have huge impacts across the entire industry. So it probably best way to answer that is to give a couple of examples. The first example I’ll talk about is one that’s already happened. And that’s basically that it’s enabled ground system as a service for the earth observation market.
Stuart Daughtridge: As little as five to 10 years ago, if you’re putting up an EO satellite, you had to consider building out your own ground infrastructure, which would require significant capital expenditure, as well recurring operations costs. But 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 helps get your data turned into products faster than custom-built ground systems, all for a very nominal pay-as-you-go pricing model. And they’re able to do that because they’re able to amortize the costs of the system across multiple satellite operators. And this is significantly a change. The cost structure required to start a earth observation satellite business. So it’s really had a huge impact on that part of the industry.
Stuart Daughtridge: Another example is with respect to ground system architectures. If you look at the basic architecture of a satellite ground system at the block diagram level, it really hasn’t changed much since the late 1960s. I mean, I joined the industry in the mid-1980s, and I remember when I joined the industry, I was given a book that showed how ground systems were built that were from the mid-1970s. And if I pulled up that book now and I pulled out a block diagram of a satellite ground system from, from that book, it would look basically the same as most satellite ground systems that are being built today.
Stuart Daughtridge: And so at the architectural level, now each of those blocks have advanced massively in the last 40, 50 years, but at the block diagram architecture level, it basically looks identical. So with a digital infrastructure where you digitize once near the antenna, as close to the antenna, as you can, it enables a multitude of new architectures. And as you’re able to use general compute and IP routing to place your L band plumbing and your signal processing, you can disaggregate your architecture and optimize it for the service you’re providing.
Stuart Daughtridge: There’s a lot more I could talk about on that topic but let me go to a third example. And the third example is the impact on remote terminals. Right now, remote terminals are somewhat built around the modems that they integrate with. And 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.
Stuart Daughtridge: So, if you think about what that means, it has dramatic impacts. So if you’re the terminal supplier, it greatly simplifies your offerings since 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. But 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. So you 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 ‘nother dimension of that flexibility.
Stuart Daughtridge: Or if you 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 software, application software into it. Because the application software could have gone from a commercial modem to a highly secure MILSATCOM mode. So digital transformation’s going to have impacts across the entire spectrum of the industry. And I think it’s going to truly transform the industry and open up new applications and opportunities that we’ve not even begun to consider.
John Gilroy: Wait, no, I’m taking notes as you’re speaking. I’m writing down “disaggregation unlocks flexibility.” Boy, that’s the summary of what you had to say. It’s going to be exciting times here in the ground station industry in the next few years. Gentlemen, DIFI is a brand spanking new initiative. You all have done an excellent job showing the benefits of DIFI and shown how standards can improve resiliency and reduce cost.
John Gilroy: I’d like to thank our guests. Lieutenant Colonel, Gary Thompson, Spectrum Warfare Division, Space Systems Command, U.S. Space Force; Ben Hilburn head of Strategic Initiatives, Azure Spectrum Technologies at Microsoft; and Stuart Daughtridge, Chairman, Digital Intermediate Frequency Interoperability Consortium, or DIFI. Thank you, gentlemen.
