Consolidated Space Operations ContractNASA/Lockheed Martin-CSOCGround Network and Space Network Interoperability TestbedLindolfo Martinez&Larry MuznyLockheed Martin Space OperationsConsolidated Space Operations ContractPO Box 58980, Mail Code L1CHouston, TX 77258-8980(281) [email protected] IntroductionLockheed Martin-CSOC, a prime contractor for NASA ground systems, has beensupporting in the development of plans for the evolution of NASA’s Ground Network(GN) and Space Network (SN), and where possible, synchronizing those plans with plansfor the evolution of the Deep Space Network (DSN). Both organizations want thosenetworks to have certain key attributes. Among the desired attributes are: 1. A commoninterface for all NASA networks to allow users to reduce development and operationscosts by using common standards-based system interfaces; 2. Network interoperability toallow the sharing of resources among space agencies and other government agencies; and3. Provide a common interface for integrating commercial ground network providers andnetwork users.A multi-center and multi-contractor study team led by Lockheed Martin-CSOCconcluded that the Space Link Extension (SLE) set of Consultative Committee for SpaceData Systems (CCSDS) recommendations has the desired attributes. The teamrecommended that NASA and Lockheed Martin-CSOC set up an interoperability testbedto show how most future NASA missions can use CCSDS SLE and that SLE could meetNASA’s interoperability goals.NASA’s involvement with SLE started with its support for the development of SLE asthe primary interface for future Deep Space Network missions. The current effort,including the buildup of an SLE interoperability testbed, centers on proving that SLE canalso be used for both legacy and future GN and SN science missions. In addition, aPage 1

Consolidated Space Operations Contractproposed testbed effort intends to show that SLE can be applied to ground systemssupporting Human Space Flight missions (International Space Station and Space Shuttle).Inter-agency interoperability plays a major role in the plans for the SLE testbed. NASAhas a program for interoperability with the Air Force Satellite Control Network(AFSCN). As part of this program, the SLE testbed set up connectivity between a groundstation at NASA’s Wallops Flight Facility (WFF), a National Oceanic and AtmosphericAdministration (NOAA) ground station, and an AFSCN control center to allowdownlinks and uplinks using NASA and DoD test satellites. Integrating commercialnetwork providers using SLE services into the testbed remains a future objective.The SLE testbed is a proof of concept showcase for new GN and SN science missionsand for legacy missions assessing the use of SLE. The scope of testing in the SLEinteroperability testbed includes testing CCSDS packet-based SLE Transfer Services onthe GN. Encrypted Bitstream and TDM over SLE Transfer services were tested with theGN, NOAA, and the AFSCN.SLE Management Services Request as defined by the CCSDS Panel 3 OperationsConcept White Paper is being prototyped in the SLE testbed. As part of this activity, weplan to submit automated SLE Service Requests to a Wallops Flight Facility test groundstation from an AFSCN and a Lockheed Martin-CSOC test operations center. One finalproduct of this testing activity is to support the development of CCSDS SLErecommendations by providing inputs and results on our testing and prototyping activitiesto the CCSDS Panel 3 SLE standards committee.1.1 BackgroundThe primary National Aeronautical Space Administration (NASA) ground datacommunications (NASCOM) architecture is based on NASCOM Internet Protocol (IP)transition data format and protocol. The NASCOM IP Transition protocol distributesdata encapsulated in a legacy NASCOM block data structure using an IP infrastructureand the User Datagram Protocol (UDP-Multicast). NASCOM block is a NASA uniquefixed length data format, which is an artifact of the days when data communicationsconsisted of point-to-point communications interfaces.Over the past two decades, many new mission programs have elected to utilize otherreliable data protocols and data structures. The result is that mission operation userfacilities must have unique hardware and/or software implementations for each differentground data service. This is a costly trend for programs needing to utilize NASA’sground data service facilities.NASA and the Lockheed Martin-CSOC formed a multi NASA center work group toinvestigate the phasing out of NASA ground communications based on NASCOM blocksservices on the Ground and Space Network and to propose new data services. TheNASCOM block Phase-Out work group evaluated the key requirements for current andfuture missions, and also evaluated many data protocols and standards currently in use.Page 2

Consolidated Space Operations ContractThe work group concluded that CCSDS SLE transfer services has become thepredominant internationally accepted standard for interoperability between ground dataservices and mission user facilities. Based on this investigation, the NASCOM BlockPhase-Out work group agreed to propose a NASA wide data standard based on CCSDSSLE for ground data communications as the first step toward phasing out NASCOMBlocks.1.2 Current ArchitectureThe primary NASA ground data communications used between a typical NASA groundtracking site and the ground data user is the NASCOM IP transition protocol. TheNASCOM IP Protocol effectively tunnels NASA’s legacy NASCOM block data formatsthrough the IP Transition protocol. The NASCOM block data structure is a NASAunique fixed length 4800 bit or 1200 bit data block which is used to carry spacecraft bitstream data asynchronously or ground data messages such as tracking messages, sitestatus messages, etc.The NASCOM block levies no framing structure for the data packed into the data fieldsof the NASCOM block data structure. The ground tracking site performs no processingon the spacecraft data and packs the data into the NASCOM bock asynchronously.NASA’s ground tracking sites for the SN and GN utilize specialized equipment such asNASCOM Block Programmable Telemetry Processors (PTP), Small Converter Devices(SCD), and enhanced Multiplexer / Demultiplexer (MDM) equipment to support theNASCOM IP Transition protocol and the legacy NASCOM block data structure. ThePTP/SCD devices provide conversion between the legacy NASCOM Block protocol andthe NASCOM IP Transition protocol. The use of the NASCOM block PTP/SCD andMDM equipment minimized changes to many legacy user facilities based on NASCOMblock point-to-point communication protocol.The primary ground data service for the NASA SN ground station at the White SandsComplex (WSC) is the NASCOM IP enhanced MDM system. The enhanced MDMsystem is the prime NASA Integrated Service Network (NISN) interface for connectingwith the NASA Johnson Space Center (JSC) Mission Control Center (MCC). The resultis that the NASCOM block data structure is deeply embedded into the NASAcommunication infrastructure and this does not give new low cost missions the capabilityto move to a more robust COTS communications technology.Many new missions using NASA ground facilities have elected to use other reliable dataprotocols based on COTS technology or proprietary data structures. NASA programs arealso investigating various COTS IP protocols for space links and for groundcommunication networks. Other data standards, such as the Standard Formatted DataUnit (SFDU) data structure have been developed and are being used for some NASAmissions. Due to the wide ranges of mission requirements, several variations of SFDUdata formats are in use today. Figure 1 shows several of the major NASA groundcommunications data structures and protocols in use today.Page 3

Consolidated Space Operations ContractIn summary, there are many different proprietary and standard data interfaces betweenthe major ground based systems and user sites in use today. Some new protocols requirethat special equipment be installed at each ground tracking site and at user sites for eachmission specific data communications design. This is a costly trend and does not providefor a common communication interface to network sites.In Use ck- or SFDUServiceNASCOMBlock- or SFDUMissionSpecificIPDUMissionSpecificSFDUNASCOM Block andSFDU AF-1-ACE-LEO-T- IPDU-Landsat 7-EOS GSIPSAFSWDISCDASSLEIP Directto ortLayersRTPISISUDPUDPUDPIPIPIPFigure 1. Major NASA Ground Data Structures and Protocols in Use Today2.0 NASCOM Block Phase-Out Working Group RecommendationsNASA formed a study team to investigate the phasing out of NASA ground-to-groundtelecommunications services based on NASCOM blocks and to propose a new dataservice for all NASA ground facilities and commercial ground facilities. A major goalwas to have a standardized data service that can be used by all NASA ground datafacilities to facilitate interoperability for NASA user facilities and internationalcustomers.Page 4

Consolidated Space Operations ContractThe NASCOM Block Phase-Out work group defined a set of requirements based oncurrent and future missions and identified a new NASA wide standard data service toreplace data services based on NASCOM block data structures and protocols. TheNASCOM Block Phase-Out work group investigated the known major standards and datastructures in use today and found that CCSDS SLE was the only protocol in use that is aninternationality accepted standard with the potential to meet the interoperabilityrequirement.The NASCOM Block Phase-Out work group found the benefits of SLE included thefollowing: SLE can be a common ground data service standard for future SN and GN sciencemissions.SLE can provide cross-support (interoperability) among NASA sites and withinternational agencies.SLE builds upon the wide spread adoption of many CCSDS recommendations inuse by missions already using CCSDS standards for their space links.SLE places no additional requirements on spacecrafts that are already usingCCSDS space link protocols.SLE offers cost savings potential through the use of common equipment at allground stations and a standard user interface.The NASCOM Block Phase-Out work group also found some shortcomings with CCSDSSLE. Among them: As designed, SLE is not intended to support the NASA legacy data protocolscommunications data structures and protocols in use to day.SLE is still in the early stages of maturity.Several challenges have to be overcome for implementing CCSDS SLE at theexisting NASA GN and SN tracking sites.Security considerations related to SLE need to be further developed to operateover the NASA networks.The NASCOM Block Phase-Out work group concluded that the CCSDS SLE Servicesbeing implemented for the INTEGRAL mission could meet the requirements identifiedfor most future Goddard Space Flight Center (GSFC) SN and GN science missions. Thework group also concluded that most of the shortcomings will be resolved with furtherSLE testing and proposed enhancements.The general consensus of the NASCOMBlock Phase-Out work group was to proceed with CCSDS SLE services for ground datacommunications requirements for future GSFC SN and GN Science Missions.2.1 CCSDS SLE Service Reference ModelFigure 2 shows a high level view of the CCSDS SLE service reference model as definedin the CCSDS cross-support reference model1 and the SLE service specifications. ThePage 5

Consolidated Space Operations Contractservice model includes data transfer services and management services. Transfer servicesprovide a standard means to transfer spacecraft forward and return data between theground tracking station (provider site) and a Mission Control Center (user site). SLEmanagement supports the means to allocate and configure resources under managementauthorities within the SLE complexes (SLE service provider sites). The cross-supportmodel describes the management interactions within the SLE Complexes and the SLEutilization management on behalf of the Mission Control Center within the domain of theSLE architecture model.The CCSDS Cross Support Reference Model Part 1 Space Link Extension Services1describes eight return data services and ten forward data services. To date, the CCSDSSLE Panel has defined and released draft service specifications for following five of theeighteen data services defined in the Cross Support Reference Model: Return All Frames (RAF) data service2. Provides data service to transfer allreturn link frames to the user center.Return Channel Frames (RCF) data service3. Provides data service to transferpre-agreed selected virtual channels to the user center.Forward Command Link Transmission Unit (CLTU) data service 4. Providesforward command service from the user control center to the provider site.Forward Space Packet (FSP) Service5. Provides service for user control center tosend forward telecommand packets to the provider site.Telecommand Frame Service6 . Provides service for user control center to sendforward telecommand frames to the provider site.Of these, only the RAF, RCF, and CLTU services are being implement by JPL for itsDSN sites these same services were selected by the NASCOM Block Phase-Out workgroup for the initial proposed NASA wide data service standard. Other services definedin the SLE Cross Support model include services for CCSDS Advance Orbital Systems(AOS) and bit stream space links, but additional interest is required before thesespecifications are fully developed by the CCSDS SLE panel.Figure 2 shows the RAF, RCF, and CLTU data services within the SLE transfer servicesProvider and User functions. The provider service resides at the SLE provider facility(tracking station), and the SLE user service resides at mission control facility. Thesetransfer services operate at the application level at each site and establish acommunications relationship between the user and the provider transfer service to set upthe ground communications link via a Wide Area Network (WAN).As shown in figures 2 and 3, the return link data production process receives return linktelemetry from the RF production function at the provider site. The provider return linkdata production function includes frame synchronization, de-randomization, errordetection and correction, virtual channel sorting per CCSDS packet processing standards.The data production routes framed data with ground receipt time stamp and data qualityinformation to the SLE RAF and RCF return provision service. The return link dataPage 6

Consolidated Space Operations Contractproduction function also includes data capture and playback for line outage recording andplaybacks via the SLE RAF and RCF transfer services.Space linkSLE Provider Site(Ground Tracking Station)RFProductionUser Site(Mission Control Center)ProvisionSLE Tran sferServicesDataProductionWAN§ RAF§ RCF§ CLTUSLE ComplexManagementUserSLE Tran sferServices§ RAF§ RCF§ CLTUMission ControlCenterApplicationsUtilizationManagement Domain of CCSDS SLE Architecture Model SLE Transfer Services SLE ManagementFigure 2. CCSDS SLE Reference ModelThe forward link data production receives the CLTUs from the SLE forward CLTUprovision service, and applies the forward service physical link operations procedure(PLOP) to build the command stream to the Radio Frequency (RF) forward productionfor transmission to the space-link. The PLOP defines the carrier modulation sequencesincluding Idle fill between commandsLeading pattern for each commandTrailing pattern for each commandMinimum spacing between commandsThe forward data production also performs required buffering and interface required atthe tracking site for RF production.2.2 Legacy Mission SupportSLE transfer services are defined for missions using CCSDS conformant PacketTelemetry standards for the return space link, and for missions using CCSDStelecommand standards for the forward space link. However, many legacy missions werebuilt before the CCSDS space-link were defined and implemented. Many legacy missionuse time division multiplex (TDM) telemetry, unframed telemetry, and CCSDS AOSspace links which are not currently supported by an SLE transfer service. The NASCOMPage 7

Consolidated Space Operations ContractBlock Phase-Out work group determined that CCSDS SLE services could potentially beconfigured to support legacy missions with some minor requirement extensions.SLE transfer services for CCSDS Advanced Orbiting Systems (AOS) are defined in theCCSDS SLE Service Model but have not been developed. The NASCOM Block PhaseOut work group concluded that missions that utilize return links with CCSDS AOStelemetry recommendations (such as Space Station) can utilize SLE transfer service sincethey have production processes that are compatible with the SLE RAF and RCF transferservices. Additionally, the work group concluded SLE RAF transfer service couldsupport TDM synchronous telemetry and encrypted stream by providing a dataproduction capability to block TDM frames or block unframed data units into SLEprotocol data units (PDUs) format at the provider site. The mission control center usersite could use standard SLE RAF transfer service to receive the TDM frames withoutneed for frame synchronization function. For unframed encrypted data, the missioncontrol center user site would be required to have a re-serialize function, and telemetryprocessing function.Missions utilizing CCSDS AOS forward service for the space link require a continuoussynchronous bit stream uplink, a service that is not supported by CCSDS SLE CLTUservice. However, CCSDS SLE CLTU data service does not levy any requirements onthe CLTU data structure. The SLE CLTU data service and the provider site forwardservice production only sends the CLTU data structure to the spacecraft as it wasformatted by the SLE user along with the start and stop patterns and fill bits defined bythe telecommand PLOP configuration parameters. To support synchronous bit streamservice, the mission user could block the bit stream into SLE CLTU data structure. Theprovider CLTU transfer service can be configured to route the CLTU back-to-back torecreate the serial stream by utilizing a special PLOP configuration setting.The NASCOM Block Phase-Out work group concluded that the CCSDS SLE CLTUcould potentially support legacy forward bit steams services including CCSDS AOSforward service with minor requirement extensions. While not an ideal architecture, itcould provide a common hardware and software platform transition option while thereare legacy missions which continue to use these legacy space links.2.3 SLE MaturityWhile SLE data transfer services are being implemented by many space agencies, it is farfrom just a turnkey implementation. Final (Blue Book) SLE transfer servicesspecifications have been developed but several space agencies are already discussingfuture changes. The transfer service is expected to continue to evolve for the next fewyears. SLE management standards were released for review and are being revised byCCSDS SLE panel to simplify future implementations.The NASCOM Block Phase-Out work group also identified other requirements not yetfully explored by current CCSDS SLE implementations and requirements. These includethe following areas:Page 8

Consolidated Space Operations Contract SLE has not been tested to support mission with high data rate space links.Efficient routing of high rate data to multiple user sites in real time as data isbeing received by the ground tracking stations (such as multicast protocols).Some missions require that the same mission data be routed to multiple user sites in realtime. The current implementation of SLE requires multiple instances of CCSDS SLERAF or RCF transfer services (one for each user) to service multiple centers with thesame spacecraft data concurrently.CCSDS SLE COTS products are expected to be available in the near future. Severalcompanies offer SLE products and services, but only under a development contract or asa special order. ESA and JPL SLE APIs have been developed and are available, buteach is tailored to the current ESA and JPL unique implementation. Additional softwareintegration for specific site architectures is required.In summary, the NASCOM Block Phase-Out working group concluded that the SLEtransfer service provides a good initial deployment. The group also decided to make SLEmanagement optional for initial SLE implementations at NASA GN and SN sites untilafter the CCSDS SLE managements requirements become more mature.2.4 Proposed NASA Recommended Standard and ModelAll ground sites used by NASA missions need to support CCSDS SLE forinteroperability. JPL is currently integrating CCSDS SLE RAF, RCF, and CLTUtransport services into its DSN Sites, but major challenges still remain for installation ofSLE in the NASA SN and GN. This includes adding SLE capability to commercialground tracking sites supporting NASA space missions.The NASA SN is composed of two primary ground sites for supporting spacecraftcommunications via multiple NASA Tracking Data Relay Satellites (TDRS). The SNcan support several spacecrafts simultaneously using the TDRSS satellites. The NASAGN consists of several NASA sites and commercial sites for communicating directly withthe spacecrafts. All NASA ground tracking sites currently have RF production, datahandling, data routing, site scheduling systems, and site configuration and managementsystems in place and these are well ingrained into NASA data service operationsconcepts. NASA ground data systems were developed separately and many are uniquelydesigned. Incorporating all objectives of the SLE model and specifications is expected tobe costly. But the use of common SLE equipment at all the ground facilities offers a costsavings opportunity. Also, SLE implementation costs could be offset if implemented aspart of the planned equipment obsolesce replacement for existing NASA equipment asdescribed in this paper.Implementing SLE Management will require major change in the way site scheduling andmanagement are done today. Scheduling and management for the NASA SN and GNsites are different and very integrated into the existing ground site configuration andPage 9

Consolidated Space Operations Contractmanagement systems. Initial SLE installations will not implement SLE Management andwill utilize existing site scheduling and management operations concepts and systemsuntil the SLE management becomes more mature.Existing ground tracking sites are required to continue to support existing legacymissions with space links which utilize Time Division Multiplexed (TDM) telemetry,unframed telemetry formats, and CCSDS AOS forward data services. Legacy missionscould be supported by existing equipment for a transitional period or implemented withSLE capability extensions.Figure 3 illustrates a more detailed view of the SLE Model being proposed for the initialimplementation for SN and GN sites. The initial delivery shows use of the existing sitescheduling, resource configuration system, and RF systems. It adds CCSDS dataproduction and SLE RAF, RCF, and CLTU transfer services at the ground tracking sitesas described in a previous section of this paper. The initial SLE implementation willutilize the SLE APIs developed by ESA and JPL for the INTEGRAL mission and whichutilized standard TCP/IP protocol. As SLE management requirements mature and siteequipment is replaced, the full SLE model can be deployed.Scheduling and UtilizationFunctionsProvider ServicesExistingSchedulingSystemConf & Control Agent Production Configuration Service Provision Configurationsand InitializationReturn Link RFProductionRFProductionCommon Return LinkData Production**** **Frame/CADU SyncDe-randomizationReed Solomon/ECFVC Frame SeparatorData AnnotationØ Earth Receipt TimeØ Data Quality Status Data Storage (for Completeand Offline Delivery)Forward LinkData ProductionForward Link RFProduction Physical Layer OperationProcedure (PLOP) Direct InterfaceØ Uplink Bit RateØ Buffering**SLE RAFTransfer ServiceProvision(SW Instance)User FacilitySLE RAFTransfer ServiceUse(SW Instance)TCP/IPstatusUser**SLE RCFTransfer ServiceProvision(SW Instance)SLE RCFTransfer ServiceUse(SW Instance)TCP/IPApplicationsstatusUplink CLCWstatusSLE CLTUTransfer ServiceProvision(SW Instance)TCP/IPSLE CLTUTransfer ServiceUse(SW Instance)productionstatus** RF production status optionalColor Notation:SLE EnvironmentSLE Data Transfer ServiceFigure 3. Proposed NASA SLE Service Model – Initial PhasePage 10

Consolidated Space Operations Contract3.0 Lockheed Martin-CSOC SLE TestbedThis section describes the current status of the Lockheed Martin-CSOC SLE testbed, itsarchitecture and how it interfaces to NASA and AFSCN facilities. Project status and thefindings to date will also be described.SLE has been identified by NASA as a key area of interest, and the agency has beenexploring SLE definition and implementation for several years. Although new GSFC lowearth orbit and medium earth orbit missions have not committed to SLE, and SLE is notcurrently supported by GN or SN operational tracking stations, NASA and contractorpersonnel are testing and investigating the use of SLE on SN and GN ground trackingsites.Lockheed Martin decided to put to use CSOC’s expertise in ground station operationsand technical standards implementation and proposed that NASA fund an SLEinteroperability testbed to further define and explore the recommendations made by theNASCOM Phase-Out work group for the SN and GN. The SLE testbed project issponsored by John Rush of NASA HQ, and promotes NASA’s use of the SLE protocolwithin the GN and SN and it helps define the architecture for future interoperablecommunications and cross support with other national and international agencies andorganizations.Lockheed Martin-CSOC has assumed a major leadership role in the investigation of SLEon the SN and GN and ensures that GN and SN SLE activities are technically compatiblewith the implementation of SLE on the DSN. Lockheed Martin-CSOC has also taken onthe role of SLE clearinghouse for information relating to SLE on the GN and SN and hassupported GSFC and JSC investigations of SLE. Lockheed Martin-CSOC has alsoprovided the leadership and support for the development of SLE interoperabilitydemonstrations.The primary goal of the SLE testbed is to demonstrate the use of SLE for GN and SNscience missions and for potential cross-support between NASA and the Air ForceSatellite Control Network (AFSCN). Additional high-level goals include: Demonstrate, test, and promote CCSDS SLE as proposed by the NASCOM BlockPhase-Out work group.Gain experience in the CCSDS SLE APIs developed by Jet Propulsion Laboratory(JPL) and the European Space Agency (ESA) for the INTErnational Gamma RayAstrophysics Laboratory (INTEGRAL) mission.Conduct interagency interoperability testing using CCSDS SLE.Evaluate Commercial Off The Shelf (COTS) CCSDS SLE products from AvtecSystems.Investigate SLE service management.Monitor on-going SLE service management working group activities.Page 11

Consolidated Space Operations ContractTo meet these goals, Lockheed Martin-CSOC has installed SLE provider systems at twooperating ground station antennas, installed an SLE user system at Lockheed MartinCSOC facilities in Houston, and coordinated satellite testing with both NASA and DoDspace vehicles.An SLE “user” refers to the entity that is receiving telemetry from and/or issuingcommands to the spacecraft, typically the mission operations center. The SLE “provider”refers to the antenna ground station. The provider tasks are broken into provision andproduction. Provision is the actual SLE interface that exchanges data with the SLE uservia the communications network. Production refers to the other tasks performed by theground station equipment, such as bit synchronization, error correction, time-stamping,etc. The SLE testbed houses two instances of two different SLE user/provider systems.The first user/provider system is based on a collection of SLE user tools and a COTSTelemetry/Command processor (See Figure 4). The SLE user tools were developed byJet Propulsion Laboratory (JPL) and Lockheed Martin-CSOC. They are based on the JPLSLE API set. The SLE user tools provide the forward and return service userapplications. The COTS processor provides the SLE Forward Command LinkTransmission Unit (CLTU) service. The Return All Frames (RAF) and Return ChannelFrames (RCF) services were initially provided by in-house software based on the JPLSLE API set, but following a software upgrade in January 2003 the COTS processorprovides all three services. End-to-End tests using telemetry and command generatorswere conducted in a laboratory environment to demonstrate the functionality of the SLEimplementations.The second user/provider system is a prototype developed by Global Science andTechnology, Inc. under AFSCN sponsorship. Since DoD space vehicles do not useCCSDS protocols, this system performs additional production processing to break theencrypted bit stream interface into arbitrary data blocks to be passed to the SLE providerservice. This supplemental production processing also packages additional timinginformation with the data to meet the stringent time correlation requirements for the datadelivery to the end-user equipment. This system successfully proved the feasibility ofdelivering the AFSCN data stream over a packet switched network while meeting timestamping and delivery requirements.One instance of each of the above SLE provider systems has been installed at adevelopment and test ground station at the NASAWallops Flight Facility (WFF). Thesecond instan

the NASCOM IP Transition protocol. The use of the NASCOM block PTP/SCD and MDM equipment minimized changes to many legacy user facilities based on NASCOM block point-to-point communication protocol. The primary ground data service for the NASA SN ground station at the White Sands Complex (WSC) is