<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle23
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:635532612;
mso-list-type:hybrid;
mso-list-template-ids:794043098 1895174490 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-number-format:alpha-lower;
mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Times New Roman",serif;
mso-ascii-font-family:Calibri;
mso-hansi-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";
color:#1F497D;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1
{mso-list-id:1763990877;
mso-list-type:hybrid;
mso-list-template-ids:-1344620622 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2
{mso-list-id:2021656103;
mso-list-template-ids:1735278580;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">CSTSWG colleagues ---<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Attached is a partial draft of the White Paper
<i>Shared Space Link Protocol Functional Resources for Forward AOS and Fixed-Length USLP</i>. To quickly recap the background of this white paper, the Functional Resource Reference Model (</span><a href="https://cwe.ccsds.org/css/docs/CSS%20Area/CWE%20Private/Functional%20Resource%20Reference%20Model%20Tech%20Note/FunctionalResourcesRefModel_TechNote-TN-0.15.docx?Web=1">https://cwe.ccsds.org/css/docs/CSS%20Area/CWE%20Private/Functional%20Resource%20Reference%20Model%20Tech%20Note/FunctionalResourcesRefModel_TechNote-TN-0.15.docx?Web=1</a><span style="color:#1F497D">)
currently has placeholders for forward link USLP functions resources (FRs) in addition to already-developed sets of FRs for forward AOS and TC space data link protocols (SDLPs). USLP is intended to provide the functionality of AOS and TC and provide additional
functionality, supporting but fixed-length frames (similar to AOS) and variable-length frames (similar to TC). As an alternative to developing the third, USLP-only set of FRs, Wolfgang and I agreed to explore the possibility of supporting USLP by essentially
expanding the functionality of the existing Forward AOS FR Set to support fixed-length USLP frames, and the existing (forward TC FR Set to support variable-length USLP frames. The two resulting FR Sets could be named something like “Forward Fixed Length Frame
(FLF) SDLP” and “Forward Variable Length Frame (VLF) SDLP”, respectively. The attached draft white paper collects the information for the analysis of the fixed-length side of this study, but it does not (yet) come to any conclusions. I am providing you with
this draft so that we may discuss it at tomorrow’s (Tuesday) CSTSWG telecon. Wolfgang has already supplied some material related to his study on the VLF (TC/USLP) side (see his email at the bottom of this email).
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">I have made similar assumptions and put similar constraints on the FRs that Wolfgang has made, e.g., that the FRs are specific to Earth Space Link Terminals (ESLTs – e.g., ground stations). When I started the
FR Reference Model I had intended that the FRs might be applicable to a broader range of “nodes”, but for practical reasons the scope was narrowed to consideration of ESLTs only. For example, the CCSDS Blue Books that specify the space link functionality that
is represented by the FRs often leave details unspecified that in must be standardized cross-support environments – e.g., the definition of MC and VC multiplexing schemes that are deferred to “project organizations” in the Blue Books. Another example is the
inherent implication that the layers of the SDLPs are collocated with each other. Adjustments to functionality (and therefore the parameters associated with that adjusted functionality) have to be made when an SLE Transfer Service or CSTS is inserted between
two nominally-adjacent protocol layers. Finally, there is functionality inherent in the SDLPs that is theoretically available but not actually driven by any known or anticipated use case. The use of COP on a space-to-Earth link is possible with USLP, but Gian
Paolo has confirmed that that use case was not a driver for USLP – it’s just a side effect. Being able to eliminate it from considerations for ESLTs make the definition of the relevant FRs as they apply to ESLTs more straightforward, Given that (at least so
far) the FR work has been done in the context of CSTS and Service Management, which in turn have been ESLT-centric, it was easiest to make the simplifying assumptions and focus the FR definitions on ESLTs.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#203864;mso-style-textfill-fill-color:#203864;mso-style-textfill-fill-alpha:100.0%">But I am sympathetic to Peter’s concerns (expressed below) and ideally I too would like to make the FRs applicable independent of the
nodes that implement them. Two considerations occur to me at the moment (and I’m sure that more will come with further thought and discussion):<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo4"><![if !supportLists]><span style="color:#10253F;mso-style-textfill-fill-color:#10253F;mso-style-textfill-fill-alpha:100.0%"><span style="mso-list:Ignore">a)<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="color:#203864;mso-style-textfill-fill-color:#203864;mso-style-textfill-fill-alpha:100.0%">We’d have to figure out how to address those aspects of the Blue Books that are left undefined or ambiguous but which we have
been able to define for ESLTs – e.g., a standardized set of VC and MC Multiplexing schemes. For example, do we agree to adopt solutions for all instantiations of the FRs, or do we somehow leave them undefined in the base FR definitions and invent some mechanism
for adding them in known cases (such as ESLTs)? How much – if at all – do these solutions get pushed back into the source Blue Books? This will take some more careful consideration.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo4"><![if !supportLists]><span style="color:#10253F;mso-style-textfill-fill-color:#10253F;mso-style-textfill-fill-alpha:100.0%"><span style="mso-list:Ignore">b)<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="color:#203864;mso-style-textfill-fill-color:#203864;mso-style-textfill-fill-alpha:100.0%">In the context of ESLTs – which by definition are assumed to be multi-mission and therefore expected to support many “parallel”
functionalities concurrently (e.g., AOS, TC, and now USLP) - there is justification for trying to combine similar functionality into as small a group of FR Sets as possible. For example, the current FR Ref Model already combines the return AOS and TM SDLP
functionality in a single FR Set, on the rationalization that AOS and TM are very similar. But whatever similarities there are, there are still always going to be differences that result in different parameters – or different allowed values for the same parameters
– depending on the “mode” of the FR (e.g., AOS or TM on the return link). For a spacecraft that is built to use AOS on the forward and return links, these mode-related parameters are an unnecessary complication – the Mission would much rather use FRs that
are AOS-only and not have to worry about which parameters are no-ops for them. This would argue for *<b>not</b>* combining functionality into aggregate FRs and instead have more FR Sets that are essentially specific to the individual Blue Books. Again this
is a matter for more careful consideration.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#203864;mso-style-textfill-fill-color:#203864;mso-style-textfill-fill-alpha:100.0%"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#203864;mso-style-textfill-fill-color:#203864;mso-style-textfill-fill-alpha:100.0%">I hope that we have time to discuss some of these ideas at tomorrow’s telecon.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#203864;mso-style-textfill-fill-color:#203864;mso-style-textfill-fill-alpha:100.0%"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#203864;mso-style-textfill-fill-color:#203864;mso-style-textfill-fill-alpha:100.0%">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#203864;mso-style-textfill-fill-color:#203864;mso-style-textfill-fill-alpha:100.0%">John<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> CSS-CSTS <css-csts-bounces@mailman.ccsds.org> <b>
On Behalf Of </b>Shames, Peter M (312B) via CSS-CSTS<br>
<b>Sent:</b> Wednesday, July 03, 2019 1:49 PM<br>
<b>To:</b> Holger.Dreihahn@esa.int; css-csts@mailman.ccsds.org; Kazz, Greg J (312B) <greg.j.kazz@jpl.nasa.gov>; Greenberg, Edward (312B) <edward.greenberg@jpl.nasa.gov><br>
<b>Cc:</b> Gian Paolo Calzolari <Gian.Paolo.Calzolari@esa.int>; Burleigh, Scott C (312B) <scott.c.burleigh@jpl.nasa.gov>; Wilmot, Jonathan J. (GSFC-5820) <jonathan.j.wilmot@nasa.gov><br>
<b>Subject:</b> Re: [Css-csts] [EXTERNAL] Fw: Merging of FRs dealing with variable length frames<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Dear CSTS WG (and others),<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Recently I have been involved in looking at the relationships among two of the CCSDS areas, particularly SOIS, and MOIMS, and how they use the services of the other four areas. And this work that you are doing in CSS, to develop a model
of Functional Resources, touches on these areas and also, of course, SLS and SIS. In fact, we have a side discussion starting among SOIS, SIS, and CSS to talk about the relationships among the CSS FR models, the SOIS EDS/DoT component & behavior models, and
the SIS network management models. There seem to be some areas of overlap here, and at any event we will benefit from looking at these from a global, instead of local, perspective.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">It occurs to me that this discussion about Functional Resources (FR), and which aspects and variations of space links they cover, could also benefit from stepping back to gain a broader perspective. There is always a danger in doing this
of "trying to boil the ocean", but in this case I think taking a look at this is warranted.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Here are some assertions that I would like you to consider:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo3">
<![if !supportLists]><span style="mso-list:Ignore">1)<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>CCSDS Space Data Links are made to be used in space-to-ground, ground-to-space, and space-to-space contexts.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo3">
<![if !supportLists]><span style="mso-list:Ignore">2)<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>Some CCSDS space data links are designed to only operate in one of these contexts, others are intended to operate in all three.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo3">
<![if !supportLists]><span style="mso-list:Ignore">3)<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>SLS has defined both fixed length SDL blocks and variable length SDL frames. This notionally includes all three operational contexts.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo3">
<![if !supportLists]><span style="mso-list:Ignore">4)<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>CCSDS coding and synchronization approaches are also intended to operate in all three contexts, with similar specializations.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo3">
<![if !supportLists]><span style="mso-list:Ignore">5)<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>SLS has defined both fixed and variable length coding schemes, and fixed length block and "sliced" alignment and ASM schemes, but there is not yet a complete treatment of all of these.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo3">
<![if !supportLists]><span style="mso-list:Ignore">6)<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>FR, as defined in CSS CSSM, were developed in the context of ground data systems for cross support.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo3">
<![if !supportLists]><span style="mso-list:Ignore">7)<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>FRs define a set of abstract data communication functions that are intended to be combined in known ways, and that may be implemented in multiple different ways and associated with different real components.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo3">
<![if !supportLists]><span style="mso-list:Ignore">8)<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>FR concepts and definitions, with little modification, could equally well be adopted in the context of space communications components, not just on the ground.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo3">
<![if !supportLists]><span style="mso-list:Ignore">9)<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>EDS /DoT provides mechanisms for describing those comm components, their interfaces, and behaviors.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I assume that you will all agree with these assertions, and I fully expect to hear from you if you do not. Assuming that there is agreement, I propose that we ensure that the definitions that we adopt for CSS FRs cover all of these possibilities
and that we not artificially adopt limiting constraints on what these FRs are or where they may be applied. This concern about constraints is especially true for USLP, which has both fixed and variable length frame structures and is explicitly intended for
deployment in all three operational contexts.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Given this approach, and with all due respect, I suggest that you not adopt Wolfgang's stated assumption:<o:p></o:p></p>
<p style="margin-left:.5in">My assumption is that variable length frames will be used on the forward link only and therefore we do not need to investigate which parameters are required for the return link.
<o:p></o:p></p>
<p>Using similar logic, I suggest that you also not adopt this simplifying assumption:<o:p></o:p></p>
<p style="margin-left:.5in">My understanding is that the FR specifications deal only with the Forward Link as emitted by an ESLT, but not with inter-spacecraft communications.<o:p></o:p></p>
<p>If those assumptions I stated earlier are "correct", or if we can agree on some such set of assumptions, how much work would it be to do what is suggested, and to define all of the necessary FR so that these conditions can be met? If we do this I think
that these FR concepts could see much broader use.<o:p></o:p></p>
<p>Thanks for listening.<o:p></o:p></p>
<p>Peter<o:p></o:p></p>
<p><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-left:.5in"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">CSS-CSTS <<a href="mailto:css-csts-bounces@mailman.ccsds.org">css-csts-bounces@mailman.ccsds.org</a>> on behalf of "<a href="mailto:Holger.Dreihahn@esa.int">Holger.Dreihahn@esa.int</a>" <<a href="mailto:Holger.Dreihahn@esa.int">Holger.Dreihahn@esa.int</a>><br>
<b>Date: </b>Wednesday, July 3, 2019 at 5:13 AM<br>
<b>To: </b>CSTS-WG <<a href="mailto:css-csts@mailman.ccsds.org">css-csts@mailman.ccsds.org</a>><br>
<b>Subject: </b>[EXTERNAL] [Css-csts] Fw: Merging of FRs dealing with variable length frames<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Dear CSTS WG,</span>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Please have a look at Wolfgang's email below. Feedback is appreciated!</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Regards,</span> <br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Holger</span> <br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Holger Dreihahn<br>
European Spacecraft Operations Centre | European Space Agency | S-431<br>
+49 6151 90 2233 | </span><a href="http://www.esa.int/esoc"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">http://www.esa.int/esoc</span></a>
<br>
<span style="font-size:7.5pt;font-family:"Arial",sans-serif;color:purple">----- Forwarded by Holger Dreihahn/esoc/ESA on 03/07/2019 14:09 -----</span>
<br>
<br>
<span style="font-size:7.5pt;font-family:"Arial",sans-serif;color:#5F5F5F">From: </span><span style="font-size:7.5pt;font-family:"Arial",sans-serif">"Wolfgang Hell" <<a href="mailto:wo_._he@t-online.de">wo_._he@t-online.de</a>></span>
<br>
<span style="font-size:7.5pt;font-family:"Arial",sans-serif;color:#5F5F5F">To: </span><span style="font-size:7.5pt;font-family:"Arial",sans-serif">"Holger Dreihahn" <<a href="mailto:Holger.Dreihahn@esa.int">Holger.Dreihahn@esa.int</a>></span>
<br>
<span style="font-size:7.5pt;font-family:"Arial",sans-serif;color:#5F5F5F">Cc: </span><span style="font-size:7.5pt;font-family:"Arial",sans-serif">"John Pietras" <<a href="mailto:john.pietras@gst.com">john.pietras@gst.com</a>></span>
<br>
<span style="font-size:7.5pt;font-family:"Arial",sans-serif;color:#5F5F5F">Date: </span><span style="font-size:7.5pt;font-family:"Arial",sans-serif">02/07/2019 14:49</span>
<br>
<span style="font-size:7.5pt;font-family:"Arial",sans-serif;color:#5F5F5F">Subject: </span><span style="font-size:7.5pt;font-family:"Arial",sans-serif">Merging of FRs dealing with variable length frames</span>
<o:p></o:p></p>
<div style="margin-left:.5in">
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="1" width="100%" noshade="" style="color:#A0A0A0" align="center">
</div>
</div>
<p class="MsoNormal" style="margin-left:.5in"><br>
<br>
<br>
<span style="font-size:12.0pt">Hi Holger,</span> <o:p></o:p></p>
<p style="margin-left:.5in">can you please forward this material to the CSTS-WG? I'm copying John directly, because I suspect that he may have some more or less immediate comments while the other WG members presumably will need more time to digest this input
(as for John's input for the fixed length frames). Any early feedback WG members might have will of course be helpful.
<o:p></o:p></p>
<p style="margin-left:.5in">My assumption is that variable length frames will be used on the forward link only and therefore we do not need to investigate which parameters are required for the return link.
<o:p></o:p></p>
<p style="margin-left:.5in">The only Sync and Coding sublayer that may be used in combination with variable length USLP frames are CCSDS 231.0-B-3 and CCSDS 211.0-B-5, where the latter addresses the proximity link. My understanding is that the FR specifications
deal only with the Forward Link as emitted by an ESLT, but not with inter-spacecraft communications. Therefore only CCSDS 231.0-B-3 needs to be taken into account in the FR specification context. That means that the Sync and Coding layer is the same for both
USLP and TC frames and no merging of separate FR types is needed in that respect. For the sake of completeness the attached spreadsheet comparing the USLP and TC cases presents also the managed parameters of the sync and coding sublayer, i.e., of CCSDS 231.0-B-3.If
deemed useful, I can add the VOP-1 managed parameters to the next issue of the spreadsheet. Again, these parameters are common for variable length USLP and for TC frames.
<o:p></o:p></p>
<p style="margin-left:.5in">I have applied the following color coding in the spreadsheet: Those parameters that are identical or reasonably similar so that they can be used both to monitor and, if applicable, control USLP and TC frame handling have a green
background. Those parameters that apply only to one frame type have a blue background. A red background indicates that I see a problem with merging USLP and TC or where I have a problem with the specification of the managed parameters ar generated by the space
link folks. <o:p></o:p></p>
<p style="margin-left:.5in">As the next steps I plan to crosscheck my findings and suggestions against the material generated by John and to suggest an initial mapping of the parameters to FR types. Hopefully we can reach some related conclusions on July 9
such that we have a reasonably stable starting point for reworking some of the FR type specifications.
<o:p></o:p></p>
<p style="margin-left:.5in">Best regards, <o:p></o:p></p>
<p style="margin-left:.5in">Wolfgang <o:p></o:p></p>
<pre style="margin-left:.5in">This message is intended only for the recipient(s) named above. It may contain proprietary information and/or<o:p></o:p></pre>
<pre style="margin-left:.5in">protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received<o:p></o:p></pre>
<pre style="margin-left:.5in">this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect<o:p></o:p></pre>
<pre style="margin-left:.5in">personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (<a href="mailto:dpo@esa.int">dpo@esa.int</a>).<o:p></o:p></pre>
</div>
</body>
</html>