[Css-csts] Re: effects of Repetitions on SLE F-CLTU and FSP services?

[Gian.Paolo.Calzolari at esa.int]

Dear All,
        SLE F-CLTU currently receives a CLTU (i.e. one - or more - encoded 
frames) and as such it operates at the output of the Synchronization and 
Channel Coding Sublayer (compare with Figure 2-2: Internal Organization of 
the Sublayer at the Sending End of CCSDS 231.0-B-2).
Conversely the ChannelAccess.request primitive - that provides one or two 
parameters as follows: ChannelAccess.request (Frames, Repetitions) - 
operates at the input of the Synchronization and Channel Coding Sublayer.
As "At the sending end, the Synchronization and Channel Coding Sublayer 
accepts Transfer Frames from the Data Link Protocol Sublayer (see figure 
2-1), performs functions selected for the mission, and delivers CLTUs to 
the Physical Layer." it looks reasonable to me to assume that SLE F-CLTU 
is implementing the functions of the Physical layer and therefore that the 
multiple copies of a CLTU shall be generated by the F-CLTU service user. 
This would limit any effect on F-CLTU to e.g. a NOTE to remark the assumed 
behavior/responsibility.

I do concur that FSP is affected.
About rational, CCSDS 231.0-B-2 section A4.2.2 describes 
ChannelAccess.request primitive and states 
NOTES
1 Support for the Repetitions parameter is optional.
2 The use of the Repetitions parameter with values greater than 1 should 
be restricted to links with long light time delays.
3 For a link with long light time delay, the use of the Repetitions 
parameter with a value greater than 1 can improve the probability that a 
sequence of frames is successfully received during a limited transmission 
session. Further improvement of the probability can be obtained by 
restricting the Frames parameter to consist of a single TC Transfer Frame: 
in fact, in a CLTU with multiple frames, the loss of a frame causes the 
loss of all subsequent frames in the same CLTU and, in addition, the 
probability of loss increases with the length of the CLTU.

Other hints can be found in CCSDS 232.0-B-2 as e.g. section 2.4.2 stating
The TC Space Data Link Protocol requests the systematic retransmissions in 
accordance with parameters set by management. For each Virtual Channel, 
management sets the value to be used for the Repetitions parameter when 
requesting the transfer of frames carrying service data units on the 
Type-A Service. For each Virtual Channel, management sets a similar 
parameter for frames carrying COP control commands. For a Physical 
Channel, management sets an upper limit for the value of the Repetitions 
parameter specified in [3]. 
When requesting the transfer of frames carrying service data units on the 
Type-B Service, the TC Space Data Link Protocol always sets the value of 
the Repetitions parameter to one.

[At least] Section 5 MANAGED PARAMETERS of CCSDS 232.0-B-2 should also be 
considered. Specifically 
Table 5-1: Managed Parameters for a Physical Channel
Table 5-3: Managed Parameters for a Virtual Channel

Note that Tom Gannett has also updated versions of the following Green 
Books (to undergo CESG approval soon) with relevant material.
        CCSDS 130.2-G   Space Data Link Protocols?Summary of Concept and 
Rationale . Green Book
        CCSDS 230.1-G TC Synchronization and Channel Coding?Summary of 
Concept and Rationale . Green Book. 

Assuming there is no special harry we may plan a joint chat (with SLP and 
C&S reps) in Cleveland if we are able to find a slot in the compressed 3.5 
days schedule.

I hope this helps.

Best regards

Gian Paolo

PS note that I added Greg in cc as SLS-SLP Chair.



From:
"John Pietras" <john.pietras at gst.com>
To:
<css-csts at mailman.ccsds.org>, <smwg at mailman.ccsds.org>
Cc:
<Gian.Paolo.Calzolari at esa.int>, <Massimo.Bertinelli at esa.int>
Date:
30/05/2012 17:17
Subject:
effects of Repetitions on SLE F-CLTU and FSP services?



CSTSWG and SMWG colleagues ---
Version 2 of the TC Synchronization and Channel Coding Recommended 
Standard (CCSDS 231.0-B-2, September 2010) ?specifies an option for 
repeated transmissions of Transfer
Frames?. According to the normative Annex A of that Blue Book, the 
repetition is specified as part of the ChanneAccess.request primitive, 
which has two parameters, Frames and Repetitions. The Frames parameter 
contains the transfer frames that are to be contained within a single 
CLTU, and the Repetitions parameter specifies how many times that CLTU is 
to be transmitted. The existence of this Repetition parameter is not 
reflected in the SLE F-CLTU or FSP transfer service specifications, nor is 
it currently reflected in the version 1 SCCS-SM Blue Book. This is a 
concern to both the CSTSWG and SMWG: if it should have an effect on 
F-CLTU, FSP (and the future Forward Frames service)then those books need 
to be updated accordingly, and their management aspects will have to be 
addressed in the ongoing Service Management work.
 
Repetition may or may not affect the F-CLTU service, depending on where 
the repeated CLTUs are generated. If they are generated by the F-CLTU 
service user, then there is no effect: the repeated CLTUs arrive in 
separate CLTU-TRANSFER-DATA invocations and are treated by the F-CLTU 
service provider the same way as non-repeated CLTUS would be treated. This 
of course multiplies the traffic on the underlying communication service, 
but that may not be an issue if that underlying service would be otherwise 
idle. On the other hand, internalizing the repetition of the CLTUs as part 
of F-CLTU service production would raise issues regarding the 
interpretation of earliest and latest radiation times and possibly the 
delay-time  parameter.
 
In the case of the FSP service, however, the generation of frames from 
packets and CLTUs from frames is performed as part of FSP service 
production, which technically internally includes the ChannelAccess 
interface. Should each packet be accompanied by its own repetition 
parameter in the FSP-TRANSFER-DATA invocation (allowing the decision to 
repeat to vary on a packet-by-packet basis), or should it a be a managed 
parameter of the Service Package? What would be the effect on earliest and 
latest radiation times and the inter-CLTU delay times?
 
Alternatively, the repetition of frames (and subsequently CLTUs) could be 
synthesized by having the FSP service user generate and send  multiple 
copies of the same packet in successive FSP-TRANSFER-DATA invocations. 
This would also put the bounds on radiation time in complete control of 
the user via the earliest and latest production times and delay-time 
parameters of each successive FSP-TRANSFER-DATA invocation. However, if 
this is the approach that is taken, one has to wonder about the 
circumstances under which the Space Link Coding and Synchronization 
Working Group envisioned that a single frame would be repeated. Presumably 
they had  a use case that justified repetition at the coding layer 
interface (as opposed to, for example, repetition at the packet level). Is 
that use case undermined by the repeated packet approach?
 
Finally, note that essentially the same issues will affect the TC mode of 
the future Forward Frames service, namely; should the FF service take in 
one frame and repeat it as part of the service production, or should the 
repetition be performed be the user?
 
Best regards,
John 
 


This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20120604/dc6d3daa/attachment-0001.htm