[Sls-slp] AOS 5-year review: typo and VCF Service issues

Gian.Paolo.Calzolari at esa.int Gian.Paolo.Calzolari at esa.int
Mon Nov 2 19:29:19 UTC 2020


John, 
        please note that SLP have many improvements pending on SDLP books.
You can find them at  https://tinyurl.com/yd2xgoyb

For VCF-MCF see the attached files.

Regards

Gian Paolo




From:   Gian Paolo Calzolari/esoc/ESA
To:     "John Pietras" <john.pietras at gst.com>
Cc:     "SLS-SLP Mailing List" <sls-slp at mailman.ccsds.org>
Date:   28-10-20 11:02
Subject:        Re: [Sls-slp] AOS 5-year review: typo and VCF Service 
issues


John,
        my wording yesterday evening was just a late nigh effort :o)
In such sense that verbose splitting had the main task of identifying the 
issue.

I do share your main concern  "to eliminate any misinterpretation that 
there could be only one VCF or MCF service instance per space link"
Considering the original formulation
“The Virtual Channel Frame Service transfers the independently created AOS 
Transfer Frames through a space link, possibly together with AOS Transfer 
Frames identified by other GVCID values created by the service provider 
itself.” 
a relatively simple improvement could be the following:
“The Virtual Channel Frame Service transfers the independently created AOS 
Transfer Frames through a space link. The existence of a Virtual Channel 
Frame Service on a given Virtual Channel does not prevent existence of 
other services of the same type or different type on other channels 
identified by other GVCID values."

Similarly the sentence in 2.2.3.7 "The  Master  Channel  Frame  Service 
transfers  the  independently  created  AOS  Transfer  Frames  through the 
 space  link,  together  with  AOS  Transfer  Frames  created  by  the 
service  provider  itself. " could change to
"The  Master  Channel  Frame  Service  transfers  the  independently 
created  AOS  Transfer  Frames  through  the  space  link. The existence 
of a Virtual Channel Frame Service on a given Master Channel does not 
prevent existence of other services of the same type or different type on 
other channels identified by other MCID values. "

I used the formulation "does not prevent" for a sort of alignment to the 
MCF/VCF remarks in section 2.2.4 RESTRICTIONS ON SERVICES, i.e.: 
        b) If the Master Channel Frame Service exists on a Master Channel, 
other services shall not exist simultaneously on that Master Channel. 
        c) If the Virtual Channel Frame Service exists on a Virtual 
Channel, other services shall not exist simultaneously on that Virtual 
Channel.
but of course also an active form may be used, e.g.:
"Together with a Virtual Channel Frame Service on a given Virtual Channel, 
other services of the same type or different type can exist on other 
channels identified by other GVCID values."

Finally, as non-native English speaker, I am always open to linguistic 
improvement.

Could one of the two proposed shorter texts satisfy the real needs for 
improvement?

Best regards

Gian Paolo





From:   "John Pietras" <john.pietras at gst.com>
To:     "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>, 
"Kazz, Greg J(US 312B)" <greg.j.kazz at jpl.nasa.gov>
Cc:     "Kazz, Greg J\(US 312B\) via SLS-SLP" <sls-slp at mailman.ccsds.org>
Date:   28-10-20 00:06
Subject:        Re: [Sls-slp] AOS 5-year review: typo and VCF Service 
issues
Sent by:        "SLS-SLP" <sls-slp-bounces at mailman.ccsds.org>



Gian Paolo,
I was trying to make minimal changes to the existing (new) text, but I 
agree with you that trying to squeeze multiple thoughts into a single 
sentence is problematic. 
 
My main concern was to eliminate any misinterpretation that there could be 
only one VCF or MCF service instance per space link – I’m particularly 
sensitive to this point, having just completed the Forward Frame CSTS 
book, the main point of which is to allow multiple external (with respect 
to the ground station) sources of VC frames to share the same space link, 
where each FF-CSTS instance has its own dedicated VC and therefore maps 
into a separate instance of the VCF service.
 
I think that your wording is an improvement on my proposal. In any case, I 
would be happy with any wording that makes clear that there can possibly 
be:
- one or more instances of the VCF service (each with its own GVCID); 
- one or more instances of MCF Service (each with its own MCID, where 
multiple MCs on the same space link are valid);
- one or more VCs (each with its own GVCID) generated by the service 
provider itself; and/or
- one or more MCs (each with its own MCID) generated by the service 
provider itself 
 
[NOTE – I believe that MCs that are populated by frames received through 
instances of the VC Frame service should be considered to be MCs created 
by the provider system, since those frames come into the MC through the 
service provider’s VC Mux function]
 
Best regards,
John
 
From: SLS-SLP [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of 
Gian.Paolo.Calzolari at esa.int
Sent: Tuesday, October 27, 2020 6:31 PM
To: Kazz, Greg J(US 312B) <greg.j.kazz at jpl.nasa.gov>
Cc: Kazz, Greg J (US 312B) via SLS-SLP <sls-slp at mailman.ccsds.org>
Subject: [Sls-slp] AOS 5-year review: typo and VCF Service issues
 
Dear All, 
        the typo remark as presented in John's e-mail looks correct (but I 
did not check the documents). 

For the other remark I am getting more doubts. 
The current sentence is not looking correct to me, but I am not sure the 
proposed correction is the best one. 

As specified in 2.2.4 RESTRICTIONS ON SERVICES bullet c: If the Virtual 
Channel Frame Service exists on a Virtual Channel, other services shall 
not exist simultaneously on that Virtual Channel. 
Let's consider the original sentence:  “The Virtual Channel Frame Service 
transfers the independently created AOS Transfer Frames through a space 
link, possibly together with AOS Transfer Frames identified by other GVCID 
values created by the service provider itself.” 
If we split it, I read something like this 
 “The Virtual Channel Frame Service transfers the independently created 
AOS Transfer Frames through a space link.
 The Virtual Channel Frame Service transfers possibly also AOS Transfer 
Frames identified by other GVCID values created by the service provider 
itself.” 

In other words it looks as the other frames are also transferred by the 
VCF Service while they are transferred by other services (or service 
instances) on other VCs/MCs. 
The same issue rises also with the rewording proposed by John. 

A possible improvement could then be something like this: 
“Each Virtual Channel Frame Service instance transfers the independently 
created AOS Transfer Frames through a space link.
Those AOS Transfer Frames are possibly multiplexed on the space link 
together with other AOS Transfer Frames identified by different GVCID/MCID 
values. 
These other AOS Transfer Frames can have been created by other VCF/MCF 
Service instances and/or by the service provider itself.”


I understand this is likely not to be the best formulation, but may be a 
good starting point for a less ambiguous formulation. 

I also guess that a similar improvement should apply to 2.2.3.7 for the 
sentence "The Master Channel Frame Service transfers the independently 
created AOS Transfer Frames through the space link, together with AOS 
Transfer Frames created by the service provider itself." noting that <If 
the Master Channel Frame Service exists on a Master Channel, other 
services shall not exist simultaneously on that Master Channel.>. 

Best regards 

Gian Paolo 



From:        "Kazz, Greg J\(US 312B\) via SLS-SLP" <
sls-slp at mailman.ccsds.org> 
To:        "Kazz, Greg J (US 312B) via SLS-SLP" <sls-slp at mailman.ccsds.org
> 
Date:        27-10-20 22:53 
Subject:        [Sls-slp] FW: [EXTERNAL] RE: Updated TM & AOS 5-year 
review files from SLP WG meeting Oct 27 
Sent by:        "SLS-SLP" <sls-slp-bounces at mailman.ccsds.org> 

 
Dear SLP WG members,
 
John Pietras has what I believe are some good points below.
Please let me know your opinion of his proposed changes below
 
Thanks!
Greg
Chair SLP WG
 
From: John Pietras <john.pietras at gst.com>
Date: Tuesday, October 27, 2020 at 2:23 PM
To: "Kazz, Greg J (US 312B)" <greg.j.kazz at jpl.nasa.gov>
Subject: [EXTERNAL] RE: Updated TM & AOS 5-year review files from SLP WG 
meeting Oct 27
 
Dear Greg and all,
I’ve taken a quick look at the updates TM and AOS books and I found a typo 
and a statement that I think is misleading.
 
First the typo – As modified, the first sentence of the second paragraph 
under 2.2.3.6 of the AOS book now reads “For a given service instance, 
only one user, identified with the GVCID of the Virtual Channel, and each 
VCF Service instance on a physical channel must utilize a unique GVCID 
value.” The phrase “can use this service on a Virtual Channel” has been 
erroneously deleted. 
The sentence should read “For a given service instance, only one user, 
identified with the GVCID of the Virtual Channel, can use this service on 
a Virtual Channel, and each VCF Service instance on a physical channel 
must utilize a unique GVCID value.”
 
What I believe to be a misleading statement appears in two forms in both 
the AOS and TM books. The first sentence of the third paragraph under 
2.2.3.6 of the AOS book now reads “The Virtual Channel Frame Service 
transfers the independently created AOS Transfer Frames through a space 
link, possibly together with AOS Transfer Frames identified by other GVCID 
values created by the service provider itself.” 
My interpretation of this sentence is that there can be only one instance 
of the VCF Service per space link, with the implication that all other VCs 
on the space link are generated “by the service provider itself”. 
I believe that a more accurate, less ambiguous statement is 
“Each Virtual Channel Frame Service instance transfers the independently 
created AOS Transfer Frames through a space link, possibly together with 
AOS Transfer Frames identified by other GVCID values created by users of 
other VCF Service instances, users of Master Channel Frame service 
instances (see 2.2.3.7), and/or by the service provider itself.”
 
If my suggestion is accepted, the same change should be applied to 2.2.3.6 
of the TM book. 
 
The analogous situation applies to the MCF Service. The equivalent 
modification would be to change first sentence of the third paragraph 
under 2.2.3.7 of the AOS book (and 2.2.9 of the TM book) to read “Each 
Master Channel Frame Service instance transfers the independently created 
AOS Transfer Frames through the space link, possibly together with AOS 
Transfer Frames identified by other MCID values created by users of other 
MCF Service instances or by the service provider itself.“
 
Best regards,
John 
 
 
From: SLS-SLP [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of 
Kazz, Greg J (US 312B) via SLS-SLP
Sent: Tuesday, October 27, 2020 12:43 PM
To: Kazz, Greg J (US 312B) via SLS-SLP <sls-slp at mailman.ccsds.org>
Subject: [Sls-slp] Updated TM & AOS 5-year review files from SLP WG 
meeting Oct 27
 
Dear SLP WG,
 
Attached please find two files as a result of the 5-year review:
 
1.        Updated 132.0-B TM SDLP book modified during our SLP WG meeting 
today on Oct 27.
2.        Updated 732.0-B AOS SDLP book modified during our SLP WG meeting 
today on Oct 27.
 
When I have a chance, I will load both of them to the SLP WG CWE directory 
under the Fall 2020 meeting.
 
Best regards,
 
Greg Kazz
Principal Engineer
Technical Group Supervisor,
PSSE/EEISE/PPSE (312B)
Jet Propulsion Laboratory
4800 Oak Grove Dr., M/S 301-490
Pasadena, CA 91109
1+(818)393 6529(voice)
1+(818)393 6871(fax)
email: greg.j.kazz at jpl.nasa.gov 
 _______________________________________________
SLS-SLP mailing list
SLS-SLP at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-slp
This message is intended only for the recipient(s) named above. It may 
contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or 
dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies 
appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA 
Data Protection Officer (dpo at esa.int).
_______________________________________________
SLS-SLP mailing list
SLS-SLP at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-slp





This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20201102/4f7960a6/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 732.0-B(AOS).CorrigendumVCF-MCF.v1.0.pdf
Type: application/octet-stream
Size: 86288 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20201102/4f7960a6/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 232.0-B(TC).CorrigendumVCF-MCF.v1.0.pdf
Type: application/octet-stream
Size: 85335 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20201102/4f7960a6/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 132.0-B-CorrigendumVCF-MCF.v1.0.pdf
Type: application/octet-stream
Size: 87405 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20201102/4f7960a6/attachment-0005.obj>


More information about the SLS-SLP mailing list