1. 1 W.Hell (ESA) November 2014 SLE Pink Books SLE Pink Books Summary of the Updates November 2014

2. 2 W.Hell (ESA) November 2014 responder-port-identifier Specification changed such that the SLE responder application MUST disregard the value of this parameter State table conventions The state tables apply now the same convention as the CSTS Framework, i.e., each ‘IF’ clause must be terminated by the ‘ENDIF’ keyword and the ‘ELSE’ branch is optional For the CSTS documents we apparently need to derive a ‘Convention’ section regarding state tables; this will be derived from the SLE books All SLE Services

3. 3 W.Hell (ESA) November 2014 UNBIND reason ‘end’ Although this value is hardly used, it was agreed not to remove it Text has been added explaining better what ‘release of resources’ will typically imply All SLE Services

4. 4 W.Hell (ESA) November 2014 Service instance provision period Whenever we refer to the period during which a service instance is accessible by the service user, we use the term ‘service instance provision period’. Undefined terms such as ‘start time of a service instance’ have been removed Do we enforce an ‘all-parameters-gettable’ policy? The decision taken by the CSTS WG was: yes, we do, apart from the following exceptions: service-instance-provision-period service-version-number All SLE Services

5. 5 W.Hell (ESA) November 2014 Not initialized gettable parameters There are a few parameters in the SLE services which at the moment they might be queried by means of the GET-PARAMETER operation have not yet been initialized (set to a specific value) For all such parameters the SLE Books now unambiguously specify the value to be returned in response to a GET invocation ASN.1 Updates Wherever possible, ASN.1 changes have been made such, that we have backwards compatibility with the present version of the SLE services All SLE Services

6. 6 W.Hell (ESA) November 2014 All Return Services State Tables Given that the CSTS WG decided to retain the possibility of a provider initiated BIND, the problems affecting this case identified in an email from John Pietras dated 30 Jan 2012 have all been corrected. Warning on potential data loss The discussion of the conditions under which in online complete delivery mode the actual data delivery might not be complete has been rephrased and should be much clearer now. This affects mostly 3.1.9.2.12 and the associated note

7. 7 W.Hell (ESA) November 2014 All Return Services Association release/abort and reset of parameters No parameters need to be reset in case the association is released or aborted. The reset of parameters has been removed from the list of actions to be performed in case of a user initiated PEER-ABORT Production status and provider behavior A new annex (similar to those in the forward services books) has been added that specifies the production status transitions and the effect of the production status on the provider behavior This new annex should remove any related ambiguities.

8. 8 W.Hell (ESA) November 2014 All Return Services Earth Receive Time (ERT) resolution The ERT resolution is NOT controlled by a managed parameter and as such the selection of the format will be driven by the provider capability This implies that a service user must be able to handle either format A note pointing this out has been added after 3.1.7.2.

9. 9 W.Hell (ESA) November 2014 RAF Service LDPC From the RAF perspective, LDPC is in essence like RS: The information is transmitted unchanged (systematic code) and the parity symbols are appended The decoder provides the information if the outcome of the decoding process resulted in a valid codeword and therefore in a ‘good’ frame If a frame is good, there is no point in transferring the parity bits and they shall be stripped off If the frame is found to be erred, the parity bits shall be retained so that the user e.g. by applying some context knowledge can attempt the decoding in an offline process For bandwidth reasons, only the sign bit of the soft symbols will be provided The RAF Book has been modified accordingly

10. 10 W.Hell (ESA) November 2014 RAF Service permitted-frame-quality managed parameter The handling of this managed parameter has now been harmonized with similar parameters, e.g. the permitted- GVCID-set parameter in RCF. Among others it is now gettable The RAF SLE API will need to be modified as so far it disregards the setting of this parameter, i.e. invalid RAF- START invocations are sent to the RAF provider

11. 11 W.Hell (ESA) November 2014 All Forward Services Return Timeout Event Since the forward service providers do not invoke any confirmed operations, a return timeout event cannot happen on the provider side. Consequently this event has been removed from the state tables

12. 12 W.Hell (ESA) November 2014 F-CLTU Service Production status, uplink status and PLOP CMMs Thanks to John, the fairly complex interdependencies of these parameters are now captured in state tables that have been inserted into the F-CLTU Book In an attempt to contain the complexity (in particular for the PLOP-1 case), recovery from a loss of bit lock requires re-sweeping of the (unmodulated) carrier (in the light of realistic operational scenarios such shortcut appears to be acceptable) Although in CCSDS 231.0 PLOP-1 has been kind of deprecated, we still cover it in the F-CLTU Book updates With respect to earlier drafts the layout of this annex now requirements are correctly shown as numbered clauses rather than being hidden in Notes

13. 13 W.Hell (ESA) November 2014 F-CLTU Service Deferred notification This optional feature of the F-CLTU service is now fully covered in that the state table of the service provider has been extended accordingly

14. 14 W.Hell (ESA) November 2014 FSP Service Single TC frame per CLTU Updates made to unambiguously specify that FSP requires that each CLTU embeds a single TC frame only This is also strongly recommended for the optional repeated transmission of TC frames FSP over a VC not using segment headers Such configuration has been permissible in FSP from the beginning Text has been added as concerns the conditions that must be met as to make such configuration permissible Deferred notification Although this has been the mandatory way of handling production status changes, the behavior prescribed in the text was not captured in the state table. The FSP state table has now been modified in a similar way as the F-CLTU state table

15. 15 W.Hell (ESA) November 2014 FSP Service Repeated TC frame transmission The FSP service production specification in annex B has been modified to support on links with long light time delay the repeated transmission of TC frames as per CCSDS 231.0-B-2 This feature is exclusively controlled by managed parameters, where one applies to AD frames and the other to BC frames on the given VC. No feature permitting the ‘on the fly’ modification of the repetition by the FSP service users is provided A third parameter specifies the upper bound for the repetition as per CCSDS 231.0-B-2, but is disregarded by FSP FSP-THROW-EVENT As to have the possibility to protect the FSP service production against conflicting configuration changes initiated by different users, FSP has a new managed parameter that permits disabling of the FSP-THROW-EVENT operation on a per service instance basis

16. 16 W.Hell (ESA) November 2014 FSP Service No Recovery from Loss of Telemetry during Station Handover The information accessible to the FSP user for resuming commanding in a controlled manner (no packets duplicated, no packets lost) turned out to be insufficient in the event that telemetry gets lost before commanding via an outgoing station is lost and telemetry delivery only resumes over the incoming station For overcoming this problem, a parameter has been added to the ‘packet radiated’ notification that reports to the user the sequence number of the TC frame in which the packet reported on traveled to the spacecraft With this information and by means of performing a GET operation at the incoming station to obtain the next expected TC frame sequence number (extracted from the CLCW) the exact status of the commanding can be determined by the FSP user.