Configuration Profiles for CDMA Communcation and Tracking

Services

SMWGBoulder, CO

31 October – 4 November 2011

John PietrasGST, Inc.

www.ccsds.org 2

Agenda

Purpose Background Approach Overview of Space Network Configuration Profiles Walkthrough of CDMA Configuration Profile Class

Diagrams

www.ccsds.org 33

Purpose

To develop a strawman set of configuration profiles suitable for use by the NASA Space Network and other TT&C networks that conform to CCSDS 415.1

www.ccsds.org 4

Background

The proposed Blue-2 refactoring approach provides a framework adding new managed services and extending the managed services already covered by Blue-1

The NASA Space Network (SN) Ground System Sustainment Project (SGSS) is to implement SCCS-SM Blue-1 “to the greatest extent possible”, but the SN uses code division multiple access (CDMA)-based RF and modulation that is not represented by Blue-1’s CCSDS 401-based RF and modulation managed parameters

In September 2011, CCSDS published CCSDS 415.1-B-1, Data Transmission and PN Ranging for 2 GHz CDMA Link Via Data Relay Satellite

Based on SN CDMA RF and modulation scheme Required by Space Network Interoperability Panel (SNIP)

• NASA, ESA, JAXA

www.ccsds.org

Approach

Earlier (pre-2010) approach was to try to add SN RF & Modulation parameters to (refactored) CCSDS 401-based configuration profiles

Mapping turned out to be more complicated that just inserting PN-related parameters and tracking-related parameters

SN configuration profiles (Service Specification Codes in SN terminology) oriented around data group concept that has no equivalent in SCCS-SM-B-1 or CCSDS 401

Other differences are described in following slides

Current approach aligns CDMA configuration profiles with SN data group concept and other SN configuration parameters

CCSDS 415.1-B-1 also uses the SN data group concept and terminology• Formal CCSDS recognition of data group (and related concepts) via CCSDS

415.1 justifies basing SCCS-SM CDMA configuration profiles on SN profiles Adoption of SN orientation for configuration profiles will minimize

translation and transition issues for SN SN structures still need to be generalized for international adoption

5

www.ccsds.org

SN Data Groups (Return Link)

Data Group 1 (DG1) – also used by CCSDS 415.1 PN coded, PN code clock coherently related to transmitted carrier frequency 3 Modes

• Mode 1: Return link coherently related to forward linko Both I and Q channels are PN-codedo Supports 1-way forward Doppler, 2-way Doppler, and ranging

• Mode 2: Return link non-coherent to forward linko Both I and Q channels are PN-codedo Supports 1-way return Doppler and 1-way forward Doppler

• Mode 3: Return link coherently related to forward linko Only I channel is PN-coded: Q channel carriers non-PN-code datao Supports 1-way return Doppler and 1-way forward Doppler

Data Group 2 (DG2) No PN code modulation 2 modes

• Coherent: supports 1-way forward Doppler and 2-way Doppler• Noncoherent: supports 1-way return Doppler and 1-way forward Doppler

6

www.ccsds.org

Overview of Current SN Configuration Profile Information

SN telecommunication services are equivalent to SCCS-SM space link carriers Each SN telecommunication service type is defined by specific TDRS antenna type

and frequency band (S-band) Multiple Access (MA): 300 kbps forward, 3 Mbps return S-band Single Access (SSA): 7 Mbps forward, 6 Mbps return Ku-band Single Access (KuSA): 25 Mbps forward, 300 Mbps return Ka-band Single Access (KaSA): 25 Mbps forward, 300 Mbps return

No subcarriers in standard service configurations Each SN telecommunication service type is constrained to a set of modulation,

coding, etc., options SN combinations may not apply to all possible uses

Each SN telecommunication service SSC is a flat list containing RF & mod, data link layer, and transfer service configuration parameters

No separate “data sets” for I and Q symbol streams: explicit data rate–I channel and data rate–Q channel parameters (for example)

Each SN tracking service is defined by reference to the return (and forward, depending on tracking service type) telecommunication service(s) that support(s) it

www.ccsds.org 8

SCCS-SM Space Network Interoperability (SNI) and NASA SN Space Link Carrier Profiles

Although CCSDS 415.1 is technically focused on DG1 at S-Band, there is a large amount of overlap of parameters across S, Ku, and Ka bands for the SN

Space Network Interoperability (SNI) space link carrier profiles can be generalized

• Each generalized carrier profile contains all of the parameters and all possible values for those parameters

• Individual Complexes (e.g,. NASA SN) can constrain the combinations through Space Link Carrier Agreements within the Service Agreement

DG2 parameters also included in carrier profiles for full support of NASA SN

Three-tiered derivation Core carrier profile class/subclasses SNI carrier profile subclasses NASA SN carrier profile subclasses

www.ccsds.org

Refactored SCCS-SM Managed “Services” Model

9

www.ccsds.org

Strawman Refactored Core Configuration Profile Classes

10

carrierProfileIdspaceLinkCarrierAgreementRefantennaSelection

SpaceLinkCarrierProfile

receiveFrequencypolarizationdopplerCompensation

<<extensionPoint>>ForwardSpaceLinkCarrierProfile

transmitFrequencypowerRatio_I_Q

<<extensionPoint>>ReturnSpaceLinkCarrierProfile

dataRate (symbolRate)

<<extensionPoint>>PhysicalChannelProfile1 0..*

returnCarrierProfileRef

<<extensionPoint>>ForwardCarrierDependency

rangeTrackingdopplerTracking

<<extensionPoint>>TrackingSignalProfile

1

0..1

1

0..1

<<extensionPoint>>DataLinkProfile

<<extensionPoint>>OnlineSleTsProfile

1..*

0..*

<<extensionPoint>>OfflineSleTsProfile

1..*

0..*

<<extensionPoint>>SleDataStore

10..*

0..1

0..1

1

0..1

<<extensionPoint>>CompleteCstsProfile

<<extensionPoint>>TrackingDataTsProfile

0..*

1

TdDataStore

0..1

0..* <<extensionPoint>>CompleteCstsDataStore

10..*

CompleteTdCstsProfile

www.ccsds.org

Core Space Link Carrier Profile Class, Subclasses, & Contained Classes

11

carrierProfileIdspaceLinkCarrierAgreementRefantennaSelection

SpaceLinkCarrierProfile

receiveFrequencypolarizationdopplerCompensation

<<extensionPoint>>ForwardSpaceLinkCarrierProfile

transmitFrequencypowerRatio_I_Q

<<extensionPoint>>ReturnSpaceLinkCarrierProfile

dataRate (symbolRate)

<<extensionPoint>>PhysicalChannelProfile1 0..*

returnCarrierProfileRef

<<extensionPoint>>ForwardCarrierDependency

1

0..1

<<extensionPoint>>DataLinkProfile

1

0..1

ReturnCoherenceModel

ReturnOffsetModel

www.ccsds.org

SNI & NASA SN Space Link Carrier Profile Subclasses

12

commandChannelPnModulation

ForwardSniSpaceLinkCarrierProfile

carrierProfileIdspaceLinkCarrierAgreementRefantennaSelection

SpaceLinkCarrierProfile

serviceConfigurationpowerMode

ForwardNasaSnSpaceLinkCarrierProfile

dG1ConfigurationdG1Mode

ReturnSniDg1SpaceLinkCarrierProfile

dG2ModulationdG2Type

ReturnSniDg2SpaceLinkCarrierProfilereceiveFrequencypolarizationdopplerCompensation

<<extensionPoint>>ForwardSpaceLinkCarrierProfile

transmitFrequencypowerRatio_I_Q

<<extensionPoint>>ReturnSpaceLinkCarrierProfile

ReturnNasaSnDg1SpaceLinkCarrierProfile serviceConfigurationmaxEirpminEirppowerCombiningautotrackreturnChannelTimeDelayDataRequired

ReturnNasaSnCommonSpaceLinkCarrierProfile

ReturnNasaSnDg2SpaceLinkCarrierProfile

www.ccsds.org

SNI and NASA SN Physical Channel Profile Subclasses

13

symbolFormatConversionToBiphasedataBitJitterg2InversionmaxDataRate

ReturnNasaSnPhysicalChannelProfile

maximumDataRate

ForwardNasaSnPhysicalChannelProfile

dataCoding (convolutionalCoding)dataFormat

ReturnSniPhysicalChannelProfile

ReturnNasaSnPhysical_Q_ChannelProfile

dataRate (symbolRate)

<<extensionPoint>>PhysicalChannelProfile

ReturnNasaSnPhysical_I_ChannelProfile

www.ccsds.org

<<extensionPoint>>DataLinkProfile

<<extensionPoint>>NasaSnLegacyTmSync&ChannelCoding

<<extensionPoint>>231TcSync&ChannelCoding

convolutionalCodingtlmRandomization

<<extensionPoint>>Ccsds131TmSync&Coding

fecfPresentnominalCodeRateinformationBlockLength

TurboCoding<<extensionPoint>>BlockCoding

fecfPresenterrorCorrectionCapabilityinterleaveDepthvirtualFillLength

ReedSolomonCoding

1

1

1

0..1

rFrameLength

FecfOnly

<<extensionPoint>>CcsdsFAosSync&Coding

frameLengthsyncPatternsyncPatternErrorsDuringSearchsyncPatternErrorsDuringLocksyncMask

FrameSynchronization

1

0..1

crcLocationcrcOn_Off

VirtualChannelProcessing

1

0..1

interleaveDepthrsCodewordLocationreVirtualFill

ReedSolomonDecoding

1

0..1

syncPatternErrorsDuringSearchsyncPatternErrorsDuringLocksyncMask

NasaSn131Sync&Coding

Data Link Profile Subclasses

14

needs to include LDPC

Placeholder for F-AOS services

www.ccsds.org

Transfer Services

In SCCS-SM B-1, an attempt was made to accommodate future return CSTS services with “complete” and “timely” modes by merging them with SLE “online” and “offline” modes into new “SLS” and “retrieval” instances, respectively

However, the mapping in B-1 is not completely correct – it does not adequately address the dual online and offline nature of a complete-mode CSTS

The CSTSWG is re-evaluating the underlying protocols related to CSTS complete and real-time mode

It is premature to attempt to fix the SM configuration profiles for return CSTS complete services until that re-evaluation is complete

B-1 does not include any “attachment points” for non-spacecraft-data-bearing transfer services (such as tracking data and monitored data)

In the following strawman diagrams, the B-1 “SLS” and “retrieval” qualifiers are replaced with their CSTS and SLE terms

I.e., online and offline for SLE, complete and timely for CSTS

Further analysis is required to see if these various classes of transfer services can be grouped

SN extension classes for W[hite Sands Complex] [TCP/IP] D[ata] I[nterface] S[ervice] C[apability] (WDISC) are for illustrative purposes

Details of WDISC profiles are TBD

15

www.ccsds.org

Transfer Service Subclasses

16

<<extensionPoint>>DataLinkProfile

<<extensionPoint>>OnlineSleTsProfile

0..*

0..*

<<extensionPoint>>OfflineSleTsProfile

0..*

0..*

<<extensionPoint>>SleDataStore

10..*

SleFcltuTsProfile

OnlineRafSleTsProfile

OnlineRcfSleTsProfile

OnlineRocfSleTsProfile

OfflineRafSleTsProfile

OfflineRcfSleTsProfile

OfflineRocfSleTsProfile

0..*

0..*

<<extensionPoint>>NasaSnWdiscProfile

NasaSnWdiscCltuProfile

NasaSnWdiscReturnFrame-Profile

www.ccsds.org

Tracking Services

Two components of tracking services Tracking signal Tracking data transfer service

Each tracking signal instance is associated with a return carrier (one-way Doppler) and a forward carrier (two-way Doppler, ranging)

Each tracking data transfer service instance can deliver tracking data associated with multiple tracking signals

What is the appropriate level to associate tracking data transfer services with tracking signals?

NASA SN aggregates all tracking data for a single Event (i.e., all services provided through a single TDRS)

• Relating tracking services to stations (TDRSs or ground stations) supports storage of tracking data for subsequent retrieval

• In general, grouping services by stations has practical advantages TD-CSTS is capable of aggregating tracking data from an arbitrary set of

resources For the purposes of this presentation, we assume the existence of a station

package component of a Service Package

17

www.ccsds.org

receiveFrequencypolarizationdopplerCompensation

<<extensionPoint>>ForwardSpaceLinkCarrierProfile

transmitFrequencypowerRatio_I_Q

<<extensionPoint>>ReturnSpaceLinkCarrierProfile

rangeTrackingdopplerTracking

<<extensionPoint>>TrackingSignal

1

0..1

<<extensionPoint>>CompleteCstsProfile

<<extensionPoint>>TrackingDataTsProfile0..*

1

TdDataStore0..1

0..*

<<extensionPoint>>CompleteCstsDataStore

0..1

0..1

10..*

timeTransferRequiredtimeTransferNumberOfSamplessampleRate

NasaSnTrackingSignal

NasaSnTdTsProfile CompleteTdCstsProfile

Tracking Service Signal & Transfer Services

18

association via station package

www.ccsds.org 19

Some Questions and Observations

Is the SN telecommunication service terminology better than the SCCS-SM space link carrier? SN has a fixed forward sweep pattern

Should the core forward space link carrier contain forward link sweep components, or should they be included only when needed?

Is forward link sweep more of a Service Agreement-level entity? Forward link sweep could be made “standard but optional”

Coherence model for CDMA has fixed defined ratios Similar questions as for forward sweep pattern

Do we need extensible parameters (akin to CSTS FW)? Ability to add new values to already-existing parameters If so, how do we do it in XML?

• Declare the parameters to be abstract, requiring substitution?• Declare parameters to be of abstract type?

How do we show “stereotypical” relationships? E.g., that space link carriers can have physical channels, or that return space link carriers can have

coherency/offset relationships with forward channels These diagrams use containment in the higher-level diagrams. That implies that all derived (concrete)

classes will have placeholders for them, even if they aren’t used

Should parent classes contain only the parameters that all child classes must have, or should they contain parameters that “most” children will use, even if some do not

Include the ones that most will use, but make the non-mandatory-for-all ones optional

Having the Service Agreement explicitly contain all possible parameters – even the fixed one – will make for huge Agreements as extensions are added