1 / 19

Configuration Profiles for CDMA Communcation and Tracking Services

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.

lidia
Download Presentation

Configuration Profiles for CDMA Communcation and Tracking Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 TT&C 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-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

  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 rate–I channeland 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

  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 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

  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 association via station package

  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

More Related