1

12 March 2008

JPL/DSN/CSSXP Overview JPL/DSN/CSSXP Overview and Findingsand Findings

Crystal City, USA12 March 2008

Erik Barkley (JPL)

2

12 March 2008

CSSXP/DSN Test Configurations

Message exchanges/validation in reference to service agreements geared for interface verification

Message exchanges/validation in reference to internal development service agreement

SLE SM Exchange wrt to service agreements aimed at supporting shadow tracking

SLE SM --> DSN MappingsCoordination of "Verification Baseline" (via 820-013 0168)

Support Products

"Verification Baseline" (via normal coordination) and CCSDS "Test" SLE Transfer Services (via Prototype coordination)

DSN SLE SM Prototype Test Configurations

Overview

Internal Test Configuration

CSSXP (JPL CM Prototype)

Operates in "Loop back mode" (interface to SPS "short-circuited")

UM Test Driver GUI

External SM I/F Test Configuration

ESA/JAXA/UM Prototypes CSSXP

Operates in "Loop back mode"

External Shadow Tracking Test Configuration

ESA/JAXA/UM Prototypes

Utilizes SPS portal for coordination of "verification" baseline of services

Utilizes CCSDS SLE SM interface for coordination of "test" services

SLE Transfer Services

CSSXP

Responds to CCSDS SLE SM requests

Performs transformations from CCSDS SLE SM into SPS inputs and internal work order configurations

SPS

Generates support products for operationally committed DSN services

Generates support products for test DSN services as orchestrated by CSSXP

DSN/AMMOS Subsystems

SLE Transfer Services

3

12 March 2008

CSSXP Data Mapping Summary

• OEM: -- Used in determining how to point the antenna in accordance with SELENE's apparent motion over the DSN tracking station

• OEM + CP -- Used in controlling calculations for Doppler compensated frequency prediction to enable DSN receivers to maintain carrier lock on the SELENE signal

• SP + CP -- Used to produce a sequence of events used for detailed instructions for DSN internal equipment

• SP -- Used to generate a schedule request for scheduling the activity;• In accordance with what is scheduled via the current established DSN

process as CSSXP is not operational

• SP can also be used for producing SICF information however• Used the default information • SLE configuration information is not going from CSSXP to the internal

operational SLE server- JPL Internal management of SLE a little too adapted for use in non-service managed

environment- BIND Test done with CSSXP override SICF generated in accordance with default

information

4

12 March 2008

JPL FindingsLogged By Finding # Title Description ImplicationsTung Large info enity transport Oem file needed compression for e-mail Tung Rigid SICF IDs Unable to use dynamic SLE Instance Config

TungNeed guidance on what elements should be encrypted Do we need to start "normify" this?

TungOEM Text type should be base64 encrypted.

Should a recommendation to base64 of the OEM Text Type be part of the book?

TungOEM file's start and end time should be referencing mission coverage?

TungShould receiver number be indicated somewhere in the SLE SM?

Tung

symbolRate in the schema does not specify as milli-symbol per second. It should be.

TungOEM should be allowed to reference a Planetary file.

TungOEM must be submitted to cover 24 hours after the track

TungOEM Text Type submitted in DOS format problem

The OEM they submitted to us is in DOS format and so SPS failed to convert it to SPK

Tung 3-W link with other provider

Sil AMMOS SLE Service Integration

AMMOS SLE Service integration.  Clearly, original test 1 was meant to test the request for two return service instances.  This would necessitate the creation of an override SICF file that AMMOS would need to support the activities.  Not clear what AMMOS does if telemetry from the stations continues to flow after service instance completes.  I assume they

SilSubsystem Software Configuration Tables

Information on creating all necessary subystem configuration tables currently used by the DSN.  Presumably this would happen during Service Agreement negotiation.

5

12 March 2008

Most Significant Finding

• Management of SLE Instance Configuration• SLE Recommendations allow for dynamic management• Practice appears to be hardcoding/fixing information as

much as possible• Ramifications for CS SM specification

- Appears that dynamic service package Id being mapped to SLE Instance Id information is not realistic with current implementation

- Should CS SM recommendation be modified or should this be considered as transition issue at the implementations that will be worked?

• 3-Way communication used in inter-agency setting• CS SM draft recommendation does not address this• Does service package need to indicate three-way

reference? What would it look like at a service level?• Implies exchange of uplink ramps in near-realtime if this

truly to be a committed inter-agency capability- This implies near-real-time exchange of data- Seems like an expensive proposition vs. assuming a tune-out-tune-back in

model when transitioning a S/C between agency networks