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

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

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

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

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

Potential Improvements/Alternatives Frame Packaging 1. 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 2. 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?

Trade-off discussion Options A. Packaging of data units in an unstructured data parameter of the PD Operation (Strawman FF CSTS Description from JP) B. Packing of PD operations in a (Forward) Transfer Buffer C. 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.

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) - delay time - buffer available - data sequence counter - data: - delay time - buffer available - data sequence counter - data: Process Data Op (TC Frame PP) - last-processing-start-time - radiation-completion-report - data sequence counter - data: - last-processing-start-time - radiation-completion-report - data sequence counter - data: Process Data Op (Sync Data PP) TC Frame SL-PDU

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 - maximum size - actual size - processing started/radiation notification - maximum size - actual size - processing started/radiation notification Transfer Buffer Operation Process Data Op

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 - delay time - buffer available - data sequence counter - data: - delay time - buffer available - data sequence counter - data: Process Data Op (TC Frame PP) - last-processing-start-time - radiation-completion-report - data sequence counter - data: - last-processing-start-time - radiation-completion-report - data sequence counter - data: Process Data Op (Sync Data PP) TC Frame SL-PDU

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

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

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

14

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

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