<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:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Segoe UI Emoji";
panose-1:2 11 5 2 4 2 4 2 2 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
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:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle21
{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:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:40373340;
mso-list-template-ids:-914459602;}
@list l1
{mso-list-id:266498989;
mso-list-type:hybrid;
mso-list-template-ids:1808289672 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@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:-18.0pt;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@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:-18.0pt;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@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:756823178;
mso-list-template-ids:-1687410810;}
@list l2:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3
{mso-list-id:1253395398;
mso-list-type:hybrid;
mso-list-template-ids:1290323628 645326396 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l3:level1
{mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:Calibri;}
@list l3:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l3:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l3:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l3:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l3:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l3:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l3:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l3:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></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-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D;mso-fareast-language:EN-US">Hi Marcin,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D;mso-fareast-language:EN-US">As I would see it, and as I think we had it in the old Blue-1 book, the service instance identifiers and the parameters you feel are missing are part of the service package, not the
SA or CP. Your 3 spacecraft configurations would be 3 configuration profiles. The SP request may identify a specific station or antenna; at any rate, the SP itself will identify the aperture and the service instances, and at least port IDs.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D;mso-fareast-language:EN-US">There was a discussion which I don’t think was ever fully resolved, about service instance identifiers. The original concept had them being dynamically defined for each service package.
But the “stop-gap” SICF approach ended up with people getting used to “permanent” SI IDs and being reluctant to change that. Certainly I think it would be unhelpful to have to reproduce the same config multiple times just to use different SI IDs for different
apertures. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D;mso-fareast-language:EN-US">Basically what you suggest in your second and third bullets looks about right, modulo discussion on permanence of SI IDs.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D;mso-fareast-language:EN-US">I think the FRM parameters identified as just “reporting” mean they cannot be changed during production. Clearly they have to be set somewhere, i.e. “by management”, as part of setting
up the service packages.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D;mso-fareast-language:EN-US">Anthony<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> SMWG <smwg-bounces@mailman.ccsds.org>
<b>On Behalf Of </b>Marcin.Gnat@dlr.de<br>
<b>Sent:</b> 26 January 2021 15:32<br>
<b>To:</b> smwg@mailman.ccsds.org<br>
<b>Subject:</b> [cssm] SACP: configuration of tranfer services<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:solid windowtext 1.0pt;padding:0cm 0cm 0cm 0cm">
<p align="center" style="text-align:center;background:#E4002B"><span lang="EN-US" style="color:white">-
<b>CAUTION: </b>This message was sent from outside of Telespazio Germany. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe. Please report all suspicious emails to "<a href="mailto:support@telespazio.de">support@telespazio.de</a>"
as an attachment. -<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><a name="Gruß"></a><span lang="DE">Dear SMWG,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="DE"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">In course of some implementation work and discussion with my developers, I came to the point where I think we shall have some closer discussion soon (in one of our teleconferences and definitely later during spring meetings).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">The protagonist: configuration (profile) of the transfer service (known currently under nicknames “SLE configuration” or “SICF”).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">The place and time: somewhere in snowy Bavaria during Winter 2020/2021, Corona situation.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">The Synopsis: during implementation of VEEEEEERY remotely similar profiles into DLR’s new scheduling system, my developers asked me how they shall treat the Service Instance Identifiers in the profile. When I looked at
their initial implementation, I noticed, that they did put the complete configuration (service) profile in “one piece”, according to the current list from FRM and to what I told them. It does not correspond to the full flexibility of the actual planned SACP
(this was not the intention). Anyhow, I realized two things: <o:p></o:p></span></p>
<ol style="margin-top:0cm" start="1" type="1">
<li class="MsoNormal" style="mso-list:l1 level1 lfo3"><span lang="EN-US">Not all of SLE parameters were there (GVCID, Port and User identifiers, etc…)
<o:p></o:p></span></li><li class="MsoNormal" style="mso-list:l1 level1 lfo3"><span lang="EN-US">Defined as such now, projects would need to define multiple configuration profiles, being actually the same, differing only with Service Instance Identifier, for each Service Instance.
In our case, for example for TerraSAR mission, we have actual 3 spacecraft configurations for the antenna, but in total 32 service instances for different stations, antennas and cortexes. This maybe does not multiply 1x1, but at least we would need 32 configuration
profiles (I can almost hear the project people coming to get me)! <o:p></o:p></span></li></ol>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Okay, this is to some extent my own fault, as I burdened the implementation of “some kind of configuration profile” to my developers, and maybe did not thought about it in front. But it shows I think also some shortcomings
we have with the concept (maybe it will shape up still).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">To the first point, I quickly noticed, that – even I made a list of parameters based on FRM – actually not all parameters are really exposed. When looking to the export of Holger out of FRM and the schema files, I noticed
than there is number of parameters which are marked only as “reporting” thus in first place not visible to SACP (hence my omission). And so, all Initiator and Responder Id’s as well as PortId’s and the GVCID’s are marked as “reporting” or “read-only” if you
like. How are we going to set them? <b>Shouldn’t they be also configurable, similar like Service Instance ID?</b><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">From this:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><img border="0" width="419" height="242" style="width:4.3645in;height:2.5208in" id="Picture_x0020_1" src="cid:image001.png@01D6F974.59E0DE00"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">To this:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><img border="0" width="411" height="342" style="width:4.2812in;height:3.5625in" id="Picture_x0020_2" src="cid:image002.png@01D6F974.59E0DE00"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Second topic is the actual (operational) separation of the antenna configuration and the transfer services configuration. Currently (at least at DLR) this looks like this:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="DE"><img border="0" width="461" height="361" style="width:4.802in;height:3.7604in" id="Picture_x0020_3" src="cid:image003.png@01D6F974.59E0DE00"></span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">There are few antenna configurations (which may be effectively also identical throughout different antennas) and number of SLE configurations (Service Instances). To be fully honest, the multiplication of the SLE config
is just due to the different Responder ID and Port ID’s, resulting also in separate Service Instance ID, the rest of the config is typically the same (for a specific RCF or FCLTU service).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span lang="EN-US">How do we want to handle that with our current concept of SACP?<o:p></o:p></span></b></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">I know we had some brief discussions on that, and there is some three page (chapter 3.4.2) information on intended use in the TechNote of John. It speaks relatively high level about two options, reusing SICF files (kind
of an extension to the actual SACP config) and also by dynamically setting the abovementioned parameters.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">First option says, that SICF files shall be there, and the Responder and Provider ID’s and Ports shall be fixed in Service Agreement and for specific Site and Mission, and later on only these shall be used. It does not
actually however says anything on how actual SICF is bound to the specific Service Package nor Service Package Request nor Configuration Profile. We have Ports and their ID’s, but how do I know which SICF shall I use? Shall there be also predefined ONE fixed
SICF?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Second option of using the extended/abstract parameters in Service Package may allow for dynamic provision of the so called “scheduledSocket” which would be just the ProviderPort. So far so good, but still I miss the
rest of the SLE/CSTS configuration, especially wrt to what I wrote above.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span lang="EN-US">Here is where the I lost the trace of the hunted game. And maybe we need here some discussion.
</span></b><b><span lang="EN-US" style="font-family:"Segoe UI Emoji",sans-serif">😊</span></b><b><span lang="EN-US"><o:p></o:p></span></b></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">I was thinking – just to came into with some proposal – of the following (better ideas are welcome!):<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;text-indent:-18.0pt;mso-list:l3 level1 lfo6">
<![if !supportLists]><span lang="EN-US"><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US">To not destroy everything else we already somehow managed to set up wrt SMURF, SPDF and SACP…<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;text-indent:-18.0pt;mso-list:l3 level1 lfo6">
<![if !supportLists]><span lang="EN-US"><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US">…We could use extended list (as at the beginning) in the Service profile, with Service Instance ID, PortID’s, GVCID’s etc., having predefined some parameters (i.e. Buffer sizes), whereas leaving all of these
“variable ones” undefined. That way we would have limited number of Configuration Profiles (a set of few generic ones for the spacecraft, universally engageable in every station).<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;text-indent:-18.0pt;mso-list:l3 level1 lfo6">
<![if !supportLists]><span lang="EN-US"><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US">When booking the Service Package (sending the Request) we could “overwrite” the previously mentioned parameters using AbstractParameter Class (for example “InitiatiorID” and “ServiceInstanceID” and “GVCID”).
The same would be true for SPDF – the values there would be shown in AbstractParameter class (and for example additionally station defined PortID would be provided). This would allow to use all of our Books / Formates as they are, and have individual SLE configuration
for each pass/service package.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;text-indent:-18.0pt;mso-list:l3 level1 lfo6">
<![if !supportLists]><span lang="EN-US"><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US">The disadvantage of the above method would be, that there would need to be some kind of automated generation of Service Instance ID and GVCID on user side and the ProviderPort on provider side. Otherwise we
come into danger of crazy users/providers not filling these parameters, or filling them wrongly or even filling them different.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Okay… I’m done for today </span><span lang="EN-US" style="font-family:"Segoe UI Emoji",sans-serif">😉</span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Cheers<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Marcin<o:p></o:p></span></p>
</div>
</div>
</div>
</body>
</html>