Review Notes concerning Forward Frame Service & Process Data Operation/Procedure

1. Review Notes concerning Forward Frame Service & Process Data Operation/Procedure 13.09.2011

2. Introduction • Open Issue from Berlin Meeting: • Should we issue the FW Red2 without Forward Specifications? • CESGrequires assessment of effort to add Forward Specifications • John’s contributions: • Strawman Forward Frame Service Description, Issue July 2011as Use Case for use of FW Forward Specifications • Simplified Process Data operation • Adapted Data Processing Procedure

3. Our Understanding of potential critical items in John’s Proposal • Transmission of multiple Frames within the data parameter of one Process Data operation without further encoding • Adoption of the Orange Book approach • Intention to improve throughput • Annotations on Operation level apply to all enclosed frames (e.g. delay-time) • Sequence number must be increased by the number of frames included in the previous PD operation • Process Data Operation is simplified in order to support synchronous frame processing • Data Processing Procedure extends PD operation and adds sequence control (locked state) • TC Frame Processing Procedure is derived from the Framework Data Processing Procedure • Forward Sync Data Proc. Procedure is a new Procedure specified by the Service, which extends the PD Operation

4. Our Understanding of potential critical items in John’s Proposal (sequence controlled) (simplified) Process Data Operation Data Processing Procedure uses & extends uses & extends inheritance Fwd Synch Data Processing Procedure TC Frame Processing Procedure (new Procedure)

5. Issues • The proposal certainly minimizes the changes required for the FW, but … • Multiple Frames in one data parameter • Extraction of variable size commands is problematic • Why use the same annotation for all frames in one operation (and not e.g. for all frames)? • “Complicated” rules for sequence counting • Specification of new procedures by Services based on FW Operations is allowed, but discouraged by the guidelines

6. Potential Improvements/Alternatives • Frame Packaging • Packing of PD operations into a (Forward) Transfer Buffer in a way similar to the Buffered Data Delivery Procedure • Forward Transfer Buffer (FTB) needs to be confirmed • PD Operations needs to be unconfirmed • FTB would have to be treated as standard Operation • Use of a structured data parameter • SEQUENCE OF data unit • each data unit has a header with annotations as needed • Framework Specifications • Simplified PD Operation as proposed • Simple DP Procedure as base for Forward Synch Data Proc Procedure • Sequence Controlled DP Procedure as base for TC Frame Processing Procedure • Derived from simplified Data Processing Procedure?

7. Trade-off discussion • Options • Packaging of data units in an unstructured data parameter of the PD Operation (Strawman FF CSTS Description from JP) • Packing of PD operations in a (Forward) Transfer Buffer • Packaging of data units in a structured data parameter of the PD Operation with annotations Before attempting to specify detailed data structures and behaviour, suggest to agree on the general approach Top-level trade-off discussion on the following pages.

8. A) Strawman Description • Advantages • Minimum adaptations necessary in the Book • Problems • Extraction of variable length commands • Sequence counter is not on Command level • All attributes consequently apply to enclosed data units (e.g. same delay time for all PDUs) Process Data Op (TC Frame PP) Process Data Op (Sync Data PP) - last-processing-start-time - radiation-completion-report - data sequence counter - data: - delay time - buffer available - data sequence counter - data: TC Frame TC Frame TC Frame TC Frame SL-PDU SL-PDU SL-PDU SL-PDU

9. B) Transfer Buffer (TB) • Advantages • Provides generic approach to bulk data handling (if applied uniformly to return-and forward procedures) • Could be used for other Services / Procedures if necessary / convenient • Attributes on PD level • Confirmation of Buffer confirms all contained PD operations • Identification/Sequence counting on PD Operation level • Problems • Major adaptations necessary to the Book • Uniform approach requires changes also to Return specifications • TB Op must always be used as individual PD operations unconfirmed Transfer Buffer Operation - maximum size - actual size - processing started/radiation notification Process Data Op Process Data Op Process Data Op Process Data Op Process Data Op Process Data Op Process Data Op Process Data Op Process Data Op Process Data Op

10. C) Data with Annotations • Advantages • Minor adaptations necessary in the Book • Sequence counter part of the frame/SL-DU • Other annotations like report requests part of SL-PDU • Problems • Not really a generic solution • Introduces a new Object Type (Data Unit) • Otherwise interaction between user and provider is specified in terms of operations Process Data Op (TC Frame PP) Process Data Op (Sync Data PP) - last-processing-start-time - radiation-completion-report - data sequence counter - data: - delay time - buffer available - data sequence counter - data: TC Frame TC Frame TC Frame TC Frame SL-PDU SL-PDU SL-PDU SL-PDU

11. Framework Operations and Procedures (simplified) Process Data Operation Data Processing Procedure uses inheritance Sequence Controlled DP Procedure Is that possible? Fwd Synch Data Processing Procedure TC Frame Processing Procedure

12. More Considerations (1/2) • If the sequence count is not checked, individual frames may be dropped, do we need a confirmation at all for synchronous servcies? • Make PD an unconfirmed operation • Use the unconfirmed PD in a “simple“ DP procedure • Derive a sequence controlled procedure and extend the PD operation by adding a confirmation. (currently not possible)

13. More Considerations (1/2) • If high data rates are only needed for AOS and not for packet telecommand in the foreseeable future, then we could specify buffering only for AOS • Define an unconfirmed PD operation • Define a simple DP procedure • Derive a buffered DP procedure • Buffering can be done in the same way as for the BDD procedure • No need to make the transfer buffer an explicit operation • No confirmation • Derive a sequence controlled PD procedure • Add confirmation to the operation • No buffering • Impact on throughput accepted Minor: at what level to introduce progress reports

15. First Option Unconfirmed (option 1) (simplified) Process Data Operation Data Processing Procedure uses confirmed with potential throughput impact (option 1b) Sequence Controlled DP Procedure Fwd Synch Data Processing Procedure TC Frame Processing Procedure

16. TRADE-OFF Option 1 (structured data field) + aggregation is available to sequence controlled procedure as well + common parameters need not be repeated for every unit + no need to describe handling of a transfer buffer _ Data units are not an object defined in the current framework and may conflict with operation based specifications _ In the sequence controlled case can only confirm a complete operation Option 1b + could consider using confirmed operations also for the basic operation with possible performance degradation Option 2 (transfer buffer) + standard approach already used and tested for return specs + remains within the currently defined concepts + current data processing procedure can probably be retained to a large extent + can extent specs to insert into the transfer buffer also other operation types _ aggregation not available for the sequence controlled case (but can be added later by extension) _ need to describe handling of the transfer buffer