<span style=" font-size:10pt;font-family:sans-serif">Hi Marcin, Anthony,</span>
<br><span style=" font-size:10pt;font-family:sans-serif">
ESOC has effectivly moved to
permanent SICfs. The NIS (Neywork Interface System - Handles MCS - Groundstation
SLE links) was designed to be able to use dynamic as well as permanent
SICFs and the missions screamed about the prospect of having to use dynamic
ones, much preferring to use permanent ones.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Cheers for now,</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Colin</span>
<br><span style=" font-size:10pt;font-family:sans-serif"><br>
<br>
---------------------------------------------------------------------------------------------------------<br>
Dr. Colin R. Haddow,<br>
HSO-GI, European Space Agency,<br>
European Space Operations Centre,<br>
Robert-Bosch-Str 5,<br>
64293 Darmstadt,<br>
Germany.<br>
<br>
Phone; +49 6151 90 2896<br>
Fax; +49 6151 90 3010<br>
E-Mail; colin.haddow@esa.int<br>
---------------------------------------------------------------------------------------------------------<br>
</span>
<br>
<br>
<br>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">From:
</span><span style=" font-size:9pt;font-family:sans-serif">"Anthony
Crowson" <anthony.crowson@telespazio.de></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">To:
</span><span style=" font-size:9pt;font-family:sans-serif">"Marcin.Gnat@dlr.de"
<Marcin.Gnat@dlr.de>, "smwg@mailman.ccsds.org" <smwg@mailman.ccsds.org></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Date:
</span><span style=" font-size:9pt;font-family:sans-serif">10/02/2021
18:23</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Subject:
</span><span style=" font-size:9pt;font-family:sans-serif">Re:
[cssm] SACP: configuration of tranfer services</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Sent
by: </span><span style=" font-size:9pt;font-family:sans-serif">"SMWG"
<smwg-bounces@mailman.ccsds.org></span>
<br>
<hr noshade>
<br>
<br>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">Hi
Marcin,</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">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. </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">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.
</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">Basically
what you suggest in your second and third bullets looks about right, modulo
discussion on permanence of SI IDs.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">Anthony</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"><b>From:</b>
SMWG <smwg-bounces@mailman.ccsds.org> <b>On Behalf Of </b>Marcin.Gnat@dlr.de<b><br>
Sent:</b> 26 January 2021 15:32<b><br>
To:</b> smwg@mailman.ccsds.org<b><br>
Subject:</b> [cssm] SACP: configuration of tranfer services</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<div align=center><span style=" font-size:12pt;color:white;font-family:Times New Roman">-
<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 "</span><a href=mailto:support@telespazio.de><span style=" font-size:12pt;color:blue;font-family:Times New Roman"><u>support@telespazio.de</u></span></a><span style=" font-size:12pt;color:white;font-family:Times New Roman">"
as an attachment. -</span></div>
<p style="margin-top:0px;margin-Bottom:0px"><a name="Gruß"></a><span style=" font-size:11pt;font-family:Calibri">Dear
SMWG,</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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).</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">The
protagonist: configuration (profile) of the transfer service (known currently
under nicknames “SLE configuration” or “SICF”).</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">The
place and time: somewhere in snowy Bavaria during Winter 2020/2021, Corona
situation.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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: </span></p>
<br><span style=" font-size:10pt;font-family:sans-serif">1.
</span><span style=" font-size:11pt;font-family:Calibri">Not
all of SLE parameters were there (GVCID, Port and User identifiers, etc…)
</span>
<br><span style=" font-size:10pt;font-family:sans-serif">2.
</span><span style=" font-size:11pt;font-family:Calibri">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)! </span>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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).</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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></span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">From
this:</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><img src=cid:_4_09943EBC09943AAC00600EC7C1258678 style="border:0px solid;"></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">To
this:</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><img src=cid:_4_09944A30099447C400600EC7C1258678 style="border:0px solid;"></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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:</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><img src=cid:_4_099454880994521C00600EC7C1258678 style="border:0px solid;"></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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).</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"><b>How
do we want to handle that with our current concept of SACP?</b></span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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. </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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?</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"><b>Here
is where the I lost the trace of the hunted game. And maybe we need here
some discussion. </b></span><span style=" font-size:11pt;font-family:Segoe UI Emoji"><b>?</b></span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">I
was thinking – just to came into with some proposal – of the following
(better ideas are welcome!):</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">-
To not destroy everything else we already
somehow managed to set up wrt SMURF, SPDF and SACP…</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">-
…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).</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">-
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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">-
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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Okay…
I’m done for today </span><span style=" font-size:11pt;font-family:Segoe UI Emoji">?</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Cheers</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Marcin</span><tt><span style=" font-size:10pt">_______________________________________________<br>
SMWG mailing list<br>
SMWG@mailman.ccsds.org<br>
</span></tt><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg"><tt><span style=" font-size:10pt">https://mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg</span></tt></a><tt><span style=" font-size:10pt"><br>
</span></tt></p>
<p style="margin-top:0px;margin-Bottom:0px"></p>
<p style="margin-top:0px;margin-Bottom:0px"></p><PRE>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@esa.int).
</PRE>