slide1
Download
Skip this Video
Download Presentation
Review Notes concerning Forward Frame Service & Process Data Operation/Procedure

Loading in 2 Seconds...

play fullscreen
1 / 16

Review Notes concerning Forward Frame Service & Process Data Operation/Procedure - PowerPoint PPT Presentation


  • 99 Views
  • Uploaded on

Review Notes concerning Forward Frame Service & Process Data Operation/Procedure. 13.09.2011. 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:

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Review Notes concerning Forward Frame Service & Process Data Operation/Procedure' - louie


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1
Review Notes concerning

Forward Frame Service

& Process Data Operation/Procedure

13.09.2011

introduction
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
our understanding of potential critical items in john s proposal
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 proposal1
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)

issues
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
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?
trade off discussion
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.

a strawman description
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

b transfer buffer tb
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

c data with annotations
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

framework operations and procedures
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

more considerations 1 2
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)
more considerations 1 21
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

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

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

ad