[Css-csts] RE: No MC-OCF service on AOS links?
John Pietras
john.pietras at gst.com
Wed Mar 6 10:33:42 EST 2013
Wolfgang,
Thank you for your reply. I too favor keeping the MC option available for AOS links, but I wanted to raise the question. I also agree that it would be nice if the AOS SDLP book offer MC-OCF as an explicit service but that it is not strictly necessary in order to justify the SLE ROCF delivery of those fields.
Regarding the possible need for a note - I don't have an opinion on whether such a note is necessary, but I will point out that section 1.6.1.6 (c) currently states the book makes use of the terms Virtual Channel or Master Channel OCF from the AOS SDLP. That should probably be amended to delete "or Master Channel" since MC-OCF is not to be found in the AOS SDLP book.
Best regards,
John
Ps - Martin's explanation of the undefined value for requestedGVCID makes sense and there is no need to modify the book.
-----Original Message-----
From: Wolfgang.Hell at esa.int [mailto:Wolfgang.Hell at esa.int]
Sent: Wednesday, March 06, 2013 7:38 AM
To: John Pietras
Cc: CCSDS_CSTSWG (css-csts at mailman.ccsds.org); css-csts-bounces at mailman.ccsds.org; Greenberg, Edward (313B); Kazz, Greg J (313B)
Subject: Re: [Css-csts] RE: No MC-OCF service on AOS links?
John,
Your observation that ROCF permits the selection of the MC as source of the OCFs regardless of the TFVN is correct. Given that AOS does not specify an MC_OCF service, one could argue that ROCF should be more restrictive because the service being 'extended' does not exist on the space link side. Looking at the VC_OCF service specified in AOS, we see that optionally an OCF_SDU Loss Flag may be supported which is based on checking the VC Frame Counter being in sequence. Given that in AOS (opposite to Packet TM) there is no MC frame counter, this mechanism for setting the OCF_SDU Loss Flag would not work.
However, comparing the VC and MC Frame services as specified in AOS, we see that also for the MC case a frame loss can optionally be flagged, where however the flag is not derived from a frame counter, but rather relies on the underlying coding sublayer flagging the loss of a frame, This mechanism could also be used in an AOS MC_OCF service. In other words, the absence of the MC Frame Counter is not a good reason for not having an MC_AOS service.
It is certainly correct that AOS is intended for missions with high frame rates and that there is no need to sample the CLCW (if that is what the OCF
carries) at such high rates. On the other hand, this operational scenario applies when the mission is in its routine phase. During LEOP the frame rate generally is much lower and that is when COP-1 is most helpful. Missions will not be willing to implement both AOS (for routine) and TM (for LEOP and/or safe mode). Therefore I would favour (also for a higher degree of similarity with TM) the addition of an MC_OCF service to AOS.
At least for now I would therefore leave ROCF as is. If deemed necessary, one could add a note stating that for the time being an MC_OCF service over AOS frames is not covered by a CCSDS Recommendation.
Best regards,
Wolfgang
|------------>
| From: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|John Pietras <john.pietras at gst.com> |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|"CCSDS_CSTSWG (css-csts at mailman.ccsds.org)" <css-csts at mailman.ccsds.org> |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|"Greenberg, Edward \(313B\)" <edward.greenberg at jpl.nasa.gov>, "Kazz, Greg J \(313B\)" <greg.j.kazz at jpl.nasa.gov> |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|05/03/2013 17:54 |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|[Css-csts] RE: No MC-OCF service on AOS links? |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Sent by: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|css-csts-bounces at mailman.ccsds.org |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
CSTSWG colleagues ---
I noticed yesterday that there is a disparity between the AOS and TM Space Data Link Protocols regarding MC-OCFs – specifically, TM has an MC-OCF service and AOS doesn’t. I asked Greg Kazz (chairman of the SLS Space Link Protocols WG) whether this difference in behavior was intentional and if so why, and got a response from Ed Greenberg (below).
The SLE ROCF service allows MC selection of OCFs regardless of whether the protocol is AOS or TM.
NOTE - The Cross Support Reference Model defined separate VC-OCF and
MC-OCF services which were subsequently combined in the SLE ROCF
service, but the Reference Model didn’t exclude MC-OCFs for AOS links
either.
Is there a legitimate use case for having CLCW-bearing OCFs reporting on a TC VC appear in every frame of a Master Channel (instead of just a single VC)?
If so, should we propose to the Space Link Protocols WG that the AOS SDLP be changed to include an MCOCF “service” comparable to the one in the TM SDLP stack?
If there’s not a legitimate use case, should the SLE ROCF book be modified to restrict MC-OCF delivery to TM return links?
Best regards,
John
From: Greenberg, Edward (313B) [mailto:edward.greenberg at jpl.nasa.gov]
Sent: Monday, March 04, 2013 5:48 PM
To: Kazz, Greg J (313B); John Pietras
Subject: Re: No MC-OCF service on AOS links?
I haven't talked to Tim Ray yet about using ROCF service but I don't think that we had envisioned MC OCF for AOS because of the nature of the channel it was to be use on. It was for : 1)very high speed links, 2) many VCs to service multiple independent users
3) the push was to get away from reliable frame service to reliable file service and for high rate links COP-1 was not the best way to achieve reliable transfer. The VC-OCF service was to support a single uplink control channel in support of a TC uplink.
_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts
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.
More information about the Css-csts
mailing list