Configuration Profiles for CDMA Communcation and Tracking Services SMWG Boulder, CO 31 October – 4 November 2011 John Pietras GST, Inc.
Feb 23, 2016
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