Transcript ConfigProfilesForCdma

Configuration Profiles for CDMA
Communcation and Tracking
Services
SMWG
Boulder, CO
31 October – 4 November 2011
John Pietras
GST, Inc.
Agenda

Purpose

Background

Approach

Overview of Space Network Configuration Profiles

Walkthrough of CDMA Configuration Profile Class
Diagrams
www.ccsds.org
2
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
3
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 Blue1’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)
•
www.ccsds.org
NASA, ESA, JAXA
4
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 PNrelated 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
•


www.ccsds.org
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
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 link
o
o
•
Mode 2: Return link non-coherent to forward link
o
o
•
Both I and Q channels are PN-coded
Supports 1-way return Doppler and 1-way forward Doppler
Mode 3: Return link coherently related to forward link
o
o

Both I and Q channels are PN-coded
Supports 1-way forward Doppler, 2-way Doppler, and ranging
Only I channel is PN-coded: Q channel carriers non-PN-code data
Supports 1-way return Doppler and 1-way forward Doppler
Data Group 2 (DG2)


No PN code modulation
2 modes
•
•
www.ccsds.org
Coherent: supports 1-way forward Doppler and 2-way Doppler
Noncoherent: supports 1-way return Doppler and 1-way forward Doppler
6
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


Each SN telecommunication service SSC is a flat list containing RF & mod, data link
layer, and transfer service configuration parameters


SN combinations may not apply to all possible uses
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
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



www.ccsds.org
Core carrier profile class/subclasses
SNI carrier profile subclasses
NASA SN carrier profile subclasses
8
Refactored SCCS-SM Managed “Services” Model
www.ccsds.org
9
Strawman Refactored Core Configuration
Profile Classes
SpaceLinkCarrierProfile
1
0..*
carrierProfileId
spaceLinkCarrierAgreementRef
antennaSelection
<<extensionPoint>>
PhysicalChannelProfile
dataRate (symbolRate)
1
0..1
<<extensionPoint>>
ForwardSpaceLinkCarrierProfile
<<extensionPoint>>
ReturnSpaceLinkCarrierProfile
<<extensionPoint>>
DataLinkProfile
receiveFrequency
polarization
dopplerCompensation
transmitFrequency
powerRatio_I_Q
1..*
0..1
0..1
<<extensionPoint>>
ForwardCarrierDependency
0..1
0..*
<<extensionPoint>>
OnlineSleTsProfile
0..*
<<extensionPoint>>
SleDataStore
returnCarrierProfileRef
<<extensionPoint>>
TrackingSignalProfile
rangeTracking
dopplerTracking
1..*
0..1
1
1
0..*
TdDataStore
<<extensionPoint>>
CompleteCstsDataStore
0..1
1
0..*
<<extensionPoint>>
OfflineSleTsProfile
1
0..*
0..*
<<extensionPoint>>
TrackingDataTsProfile
1
<<extensionPoint>>
CompleteCstsProfile
CompleteTdCstsProfile
www.ccsds.org
10
Core Space Link Carrier Profile Class, Subclasses,
& Contained Classes
SpaceLinkCarrierProfile
1
carrierProfileId
spaceLinkCarrierAgreementRef
antennaSelection
0..*
<<extensionPoint>>
PhysicalChannelProfile
dataRate (symbolRate)
1
0..1
<<extensionPoint>>
ReturnSpaceLinkCarrierProfile
<<extensionPoint>>
ForwardSpaceLinkCarrierProfile
<<extensionPoint>>
DataLinkProfile
receiveFrequency
polarization
dopplerCompensation
transmitFrequency
powerRatio_I_Q
1
0..1
ReturnCoherenceModel
<<extensionPoint>>
ForwardCarrierDependency
returnCarrierProfileRef
www.ccsds.org
ReturnOffsetModel
11
SNI & NASA SN Space Link Carrier Profile
Subclasses
SpaceLinkCarrierProfile
carrierProfileId
spaceLinkCarrierAgreementRef
antennaSelection
<<extensionPoint>>
ForwardSpaceLinkCarrierProfile
receiveFrequency
polarization
dopplerCompensation
<<extensionPoint>>
ReturnSpaceLinkCarrierProfile
transmitFrequency
powerRatio_I_Q
ReturnSniDg1SpaceLinkCarrierProfile
ForwardSniSpaceLinkCarrierProfile
ReturnSniDg2SpaceLinkCarrierProfile
dG2Modulation
dG2Type
ReturnNasaSnDg2SpaceLinkCarrierProfile
dG1Configuration
dG1Mode
commandChannelPnModulation
ReturnNasaSnCommonSpaceLinkCarrierProfile
ReturnNasaSnDg1SpaceLinkCarrierProfile
ForwardNasaSnSpaceLinkCarrierProfile
serviceConfiguration
powerMode
www.ccsds.org
serviceConfiguration
maxEirp
minEirp
powerCombining
autotrack
returnChannelTimeDelayDataRequired
12
SNI and NASA SN Physical Channel
Profile Subclasses
<<extensionPoint>>
PhysicalChannelProfile
dataRate (symbolRate)
ForwardNasaSnPhysicalChannelProfile
ReturnSniPhysicalChannelProfile
dataCoding (convolutionalCoding)
dataFormat
maximumDataRate
ReturnNasaSnPhysicalChannelProfile
symbolFormatConversionToBiphase
dataBitJitter
g2Inversion
maxDataRate
ReturnNasaSnPhysical_I_ChannelProfile
www.ccsds.org
ReturnNasaSnPhysical_Q_ChannelProfile
13
Data Link Profile Subclasses
<<extensionPoint>>
DataLinkProfile
<<extensionPoint>>
Ccsds131TmSync&Coding
<<extensionPoint>>
231TcSync&ChannelCoding
<<extensionPoint>>
NasaSnLegacyTmSync&ChannelCoding
convolutionalCoding
tlmRandomization
1
1
Placeholder
for F-AOS
services
needs to
include
LDPC
<<extensionPoint>>
BlockCoding
TurboCoding
fecfPresent
nominalCodeRate
informationBlockLength
1
0..1
ReedSolomonCoding
rFrameLength
syncPatternErrorsDuringSearch
syncPatternErrorsDuringLock
syncMask
frameLength
syncPattern
syncPatternErrorsDuringSearch
syncPatternErrorsDuringLock
syncMask
1
0..1
VirtualChannelProcessing
crcLocation
crcOn_Off
1
0..1
fecfPresent
errorCorrectionCapability
interleaveDepth
virtualFillLength
www.ccsds.org
0..1
FrameSynchronization
NasaSn131Sync&Coding
1
FecfOnly
<<extensionPoint>>
CcsdsFAosSync&Coding
ReedSolomonDecoding
interleaveDepth
rsCodewordLocation
reVirtualFill
14
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

www.ccsds.org
Details of WDISC profiles are TBD
15
Transfer Service Subclasses
<<extensionPoint>>
DataLinkProfile
0..*
0..*
0..*
0..*
<<extensionPoint>>
OnlineSleTsProfile
<<extensionPoint>>
SleDataStore
0..*
0..*
<<extensionPoint>>
NasaSnWdiscProfile
1
0..*
SleFcltuTsProfile
OnlineRafSleTsProfile
OnlineRcfSleTsProfile
OnlineRocfSleTsProfile
www.ccsds.org
<<extensionPoint>>
OfflineSleTsProfile
OfflineRafSleTsProfile
NasaSnWdiscCltuProfile
NasaSnWdiscReturnFrameProfile
OfflineRcfSleTsProfile
OfflineRocfSleTsProfile
16
Tracking Services

Two components of tracking services


Tracking signal
Tracking data transfer service

Each tracking signal instance is associated with a return carrier (oneway 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)
•
•


www.ccsds.org
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
Tracking Service Signal & Transfer Services
<<extensionPoint>>
ForwardSpaceLinkCarrierProfile
<<extensionPoint>>
ReturnSpaceLinkCarrierProfile
receiveFrequency
polarization
dopplerCompensation
transmitFrequency
powerRatio_I_Q
1
0..1
0..1
0..1
0..1
<<extensionPoint>>
TrackingSignal
TdDataStore
0..*
rangeTracking
dopplerTracking
1
0..*
<<extensionPoint>>
TrackingDataTsProfile
0..*
1
NasaSnTrackingSignal
timeTransferRequired
timeTransferNumberOfSamples
sampleRate
www.ccsds.org
<<extensionPoint>>
CompleteCstsDataStore
<<extensionPoint>>
CompleteCstsProfile
association via
station package
NasaSnTdTsProfile
CompleteTdCstsProfile
18
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




Coherence model for CDMA has fixed defined ratios


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”
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?
•
•

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


Declare the parameters to be abstract, requiring substitution?
Declare parameters to be of abstract type?
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
www.ccsds.org
19