Configuration Profiles for CDMA Communcation and Tracking Services

1
Configuration Profiles for CDMA Communcation and
Tracking Services

• SMWG
• Boulder, CO
• 31 October 4 November 2011
• John Pietras
• GST, Inc.

2
Agenda

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

3
Purpose

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

3
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-1s 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

5
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

6
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
• Both I and Q channels are PN-coded
• Supports 1-way forward Doppler, 2-way Doppler,
  and ranging
• Mode 2 Return link non-coherent to forward link
• 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
• 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
• Coherent supports 1-way forward Doppler and
  2-way Doppler
• Noncoherent supports 1-way return Doppler and
  1-way forward Doppler

7
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 rateI channel and data
  rateQ 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

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

9
Refactored SCCS-SM Managed Services Model
10
Strawman Refactored Core Configuration Profile
Classes
11
Core Space Link Carrier Profile Class,
Subclasses, Contained Classes
12
SNI NASA SN Space Link Carrier Profile
Subclasses
13
SNI and NASA SN Physical Channel Profile
Subclasses
14
Data Link Profile Subclasses
Placeholder for F-AOS services
needs to include LDPC
15
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 White Sands Complex
  TCP/IP Data Interface Service
  Capability (WDISC) are for illustrative
  purposes
• Details of WDISC profiles are TBD

16
Transfer Service Subclasses
17
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

18
Tracking Service Signal Transfer Services
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 arent 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