1 Nov. 9, 2015 CSTS Forward Frame Service Work Plan T. Pham Nov. 9, 2015

2 Agenda General approach High-level schedule (draft) Technical discussion Key changes since 2011 draft Relationship to FCLTU specification Frame type among service instances It’s my first formal assignment on CCSDS, especially on the development of a specification. Will definitely need, and appreciate, much of your help and guidance!!!

3 Nov. 9, 2015 Approach Build up essential knowledge on the overall framework CSTS SFW (921x1r2) Also CSTS Guidelines and Functional Resources Familiarize with similar relevant documents Forward CLTU (912x1b3) and Enhanced forward CLTU (912x11o1) CSTS-MD (922x1r1_4) and CSTS-TD (922.2-w0.11) Leverage on John’s earlier 2011 writeup CSTS Forward Frame Service Strawman Specification Plan of actions Focus on the first few general sections - Make necessary changes to sync up any changes in general operation concept since Serve as 1 st installment of updates Learn more on the detailed information re: procedures for later sections - Make necessary changes to sync up with the latest SFW and examples of MD and TD specifications - Serve as second and third installment of updates CSTS Framing & Multiplex Service User A Coding & Sync A1, A2,… (AOS) C1, C2,… (TC) B1, B2,… Service User B Service User C RF Mod Spacecraft

4 Nov. 9, 2015 Work Products Develop the specifications for the CSTS Forward Frames Service Near-term: Red Book Longer term: Blue Book, after validation via prototype effort Interface with prototyping team for validation of specifications Facilitate information flow into prototype development Extract lessons learned and changes needed to the specifications

5 Nov. 9, 2015 FY15, Q4FY16, Q1FY16, Q2FY16, Q3FY16, Q4FY17, Q1FY17, Q2FY17, Q3FY17, Q4FY18, Q1FY18, Q2FY18, Q3FY18, Q4FY19, Q1FY19, Q2FY19, Q3 Research; Formulate work plan Work on 1st draft Internal team review, 1st draft Revise & Work on 2nd draft Internal team review 2nd draft Revise & Work on 3rd draft External review Redbook Formalize Redbook Prototype effort Develop Blue Book Review BlueBook Formalize BlueBook **Draft** Work Plan Planning estimates are based on comparative analysis with previous CCSDS work, e.g. Delta-DOR Dependencies: Obtained support from collaborators on technical inputs and writing John Pietras, Wolfgang Hell, Holger Dreihahn - Commitment? Committed implementation prototype to validate the information prior to formalizing the blue book ESA/NASA - Commitment? Red Book ready Blue Book ready Q. Realistic schedule?

6 Nov. 9, 2015 TOC of 2011 FF Strawman Spec Q. Key areas require change? - Mismatches over time - Applying SFW to achieve various use cases envisioned

7 Nov. 9, 2015 Clarification on FCLTU CSTS-FF covers the functionality of FCLTU? Current FCLTU specifications to be retired post missions transition out of using it? BCH encoding typically done by mission users. Allow for bypass option? Impact with mixed use? Figure 1 Figure 2

8 Nov. 9, 2015 Clarification on frame type Current draft: Constraint on all F-Frame services instances associated with the same physical channel carry the same type of SL-PDU (TC frame, AOS frame, or AOS CADU) In Fig. 1, are all SL-PDUs into the MUX of - Same type (e.g., all instances in AOS)? - Mixture across multiple service instances (one service instance in AOS, another in TC)? - Mixture within one service instance (single service instance supports AOS/TC/CADU? Figure 1 Figure 2

9 Nov. 9, 2015 Clarification on frame type Current draft: Constraint on all F-Frame services instances associated with the same physical channel carry the same type of SL-PDU (TC frame, AOS frame, or AOS CADU) In Fig. 1, are all SL-PDUs into the MUX of - Same type (e.g., all instances in AOS)? - Mixture across multiple service instances (one service instance in AOS, another in TC)? - Mixture within one service instance (single service instance supports AOS/TC/CADU? If same type of SL-PDU is required, - Over constraint on users’ operations? - Implication to realize the scheme in Fig. 2? Figure 1 Figure 2

10 Nov. 9, 2015 Clarification on frame type Current draft: Constraint on all F-Frame services instances associated with the same physical channel carry the same type of SL-PDU (TC frame, AOS frame, or AOS CADU) In Fig. 1, are all SL-PDUs into the MUX of - Same type (e.g., all instances in AOS)? - Mixture across multiple service instances (one service instance in AOS, another in TC)? - Mixture within one service instance (single service instance supports AOS/TC/CADU? If same type of SL-PDU is required, - Over constraint on users’ operations? - Implication to realize the scheme in Fig. 2? If multi type of SL-PDU allowed, upper and lower path in Fig. 1 would be simultaneously active - Effect on idle frame generation in the async and sync paths (e.g., difficulty with definition of service instance duration)? - Additional service configuration parameters needed for defining multi-type SL-PDU? Figure 1 Figure 2