<font size=2 face="sans-serif">Hi Marcin,</font>
<br><font size=2 face="sans-serif">I remember having implemented SLE SICF
generation for our scheduling system (2008?) and I think we have put some
thinking in how to do that. As Colin correctly remarks, the feature of
pass specific SICFs is not used - simply too many files.</font>
<br>
<br><font size=2 face="sans-serif">However, the trick at the time was to
distribute the information for SLE SICF creation to the two relevant places:
The mission agreement with the (SLE) service requirements and the ground
station model with the ground station capabilities (amongothers the SLE
services supported formulated as templates). The two are used for determine
'does the station have the required capabilities' and then to combine the
information as shown below to the configuration (slide 45 of attachment):</font>
<br>
<br>
<br><img src=cid:_2_7A0F9A207A0F92A0002A9367C1258679 width=1381 height=339 style="border:0px solid;"><font size=2 face="sans-serif"> </font>
<br>
<br>
<br><font size=2 face="sans-serif">Some background: Our scheduling is service
based, so in addition to the SLE services we define the underlying production
services as operational services (TM, TC, DDOR, Ranging, etc.), which are
required (mission agreement) and matched with station capabilities (station
model). Those production services are in fact subject to configuration
profiles, which can be refined by missions per pass or requested service.</font>
<br><font size=2 face="sans-serif">In orinciple the complete configuration
profiles could be defined by FRM parameters.</font>
<br>
<br><font size=2 face="sans-serif">I know it's not exactly what you discuss,
but maybe of some interest.</font>
<br>
<br><font size=2 face="sans-serif">Best regards,</font>
<br><font size=2 face="sans-serif">Holger</font>
<br>
<br>
<br>
<br><font size=2 face="sans-serif">Holger Dreihahn<br>
European Spacecraft Operations Centre | European Space Agency | H-293<br>
+49 6151 90 2233 | </font><a href=http://www.esa.int/esoc><font size=2 face="sans-serif">http://www.esa.int/esoc</font></a>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Colin.Haddow@esa.int</font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"Anthony Crowson"
<anthony.crowson@telespazio.de></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">"SMWG" <smwg-bounces@mailman.ccsds.org>,
"smwg@mailman.ccsds.org" <smwg@mailman.ccsds.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">10/02/2021 18:46</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [cssm] SACP:
configuration of tranfer services</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">"SMWG"
<smwg-bounces@mailman.ccsds.org></font>
<br>
<hr noshade>
<br>
<br>
<br><font size=2>Hi Marcin, Anthony,</font><font size=3> </font><font size=2><br>
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.</font><font size=3> <br>
</font><font size=2><br>
Cheers for now,</font><font size=3> <br>
</font><font size=2><br>
Colin</font><font size=3> </font><font size=2><br>
<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>
---------------------------------------------------------------------------------------------------------</font><font size=3><br>
<br>
<br>
<br>
</font><font size=1 color=#5f5f5f><br>
From: </font><font size=1>"Anthony Crowson"
<anthony.crowson@telespazio.de></font><font size=3> </font><font size=1 color=#5f5f5f><br>
To: </font><font size=1>"Marcin.Gnat@dlr.de"
<Marcin.Gnat@dlr.de>, "smwg@mailman.ccsds.org" <smwg@mailman.ccsds.org></font><font size=3>
</font><font size=1 color=#5f5f5f><br>
Date: </font><font size=1>10/02/2021 18:23</font><font size=3>
</font><font size=1 color=#5f5f5f><br>
Subject: </font><font size=1>Re: [cssm] SACP:
configuration of tranfer services</font><font size=3> </font><font size=1 color=#5f5f5f><br>
Sent by: </font><font size=1>"SMWG"
<smwg-bounces@mailman.ccsds.org></font><font size=3> <br>
</font>
<hr noshade><font size=3><br>
</font>
<br><font size=2 color=#004080>Hi Marcin,</font>
<br><font size=2 color=#004080> </font>
<br><font size=2 color=#004080>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. </font>
<br><font size=2 color=#004080>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. </font>
<br><font size=2 color=#004080>Basically what you suggest in your second
and third bullets looks about right, modulo discussion on permanence of
SI IDs.</font>
<br><font size=2 color=#004080> </font>
<br><font size=2 color=#004080>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.</font>
<br><font size=2 color=#004080> </font>
<br><font size=2 color=#004080>Anthony</font>
<br><font size=2 color=#004080> </font>
<br><font size=2><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</font>
<br><font size=2> </font>
<div align=center><font size=3 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 "</font><a href=mailto:support@telespazio.de><font size=3 color=blue><u>support@telespazio.de</u></font></a><font size=3 color=white>"
as an attachment. -</font></div>
<br><a name="Gruß"></a><font size=2>Dear SMWG,</font>
<br><font size=2> </font>
<br><font size=2>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).</font>
<br><font size=2> </font>
<br><font size=2>The protagonist: configuration (profile) of the transfer
service (known currently under nicknames “SLE configuration” or “SICF”).</font>
<br><font size=2> </font>
<br><font size=2>The place and time: somewhere in snowy Bavaria during
Winter 2020/2021, Corona situation.</font>
<br><font size=2> </font>
<br><font size=2>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: </font>
<p><font size=2><br>
1. </font><font size=2>Not all of SLE parameters
were there (GVCID, Port and User identifiers, etc…) </font><font size=2><br>
2. </font><font size=2>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)! </font>
<br><font size=2> </font>
<br><font size=2>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).</font>
<br><font size=2> </font>
<br><font size=2>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></font>
<br><font size=2> </font>
<br><font size=2>From this:</font>
<br><img src=cid:_4_7988833079887F90002A9369C1258679 width=419 height=242 style="border:0px solid;">
<br><font size=2> </font>
<br><font size=2>To this:</font>
<br><img src=cid:_4_7988914879888DA8002A9369C1258679 width=411 height=342 style="border:0px solid;">
<br><font size=2> </font>
<br><font size=2>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:</font>
<br><img src=cid:_4_7988A01879889C78002A9369C1258679 width=461 height=361 style="border:0px solid;">
<br><font size=2> </font>
<br><font size=2>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).</font>
<br><font size=2> </font>
<br><font size=2><b>How do we want to handle that with our current concept
of SACP?</b></font>
<br><font size=2> </font>
<br><font size=2>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. </font>
<br><font size=2> </font>
<br><font size=2>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?</font>
<br><font size=2> </font>
<br><font size=2>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.</font>
<br><font size=2> </font>
<br><font size=2><b>Here is where the I lost the trace of the hunted game.
And maybe we need here some discussion. ?</b></font>
<br><font size=2> </font>
<br><font size=2>I was thinking – just to came into with some proposal
– of the following (better ideas are welcome!):</font>
<br><font size=2> </font>
<br><font size=2>- To not destroy everything
else we already somehow managed to set up wrt SMURF, SPDF and SACP…</font>
<br><font size=2>- …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).</font>
<br><font size=2>- 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.</font>
<br><font size=2>- 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.</font>
<br><font size=2> </font>
<br><font size=2>Okay… I’m done for today ?</font>
<br><font size=2> </font>
<br><font size=2>Cheers</font>
<br><font size=2>Marcin</font><tt><font size=2>_______________________________________________<br>
SMWG mailing list<br>
SMWG@mailman.ccsds.org</font></tt><font size=3 color=blue><u><br>
</u></font><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg"><tt><font size=2 color=blue><u>https://mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg</u></font></tt></a>
<p><tt><font size=3>This message is intended only for the recipient(s)
named above. It may contain proprietary information and/or<br>
protected content. Any unauthorised disclosure, use, retention or dissemination
is prohibited. If you have received<br>
this e-mail in error, please notify the sender immediately. ESA applies
appropriate organisational measures to protect<br>
personal data, in case of data privacy queries, please contact the ESA
Data Protection Officer (dpo@esa.int).<br>
</font></tt><tt><font size=2>_______________________________________________<br>
SMWG mailing list<br>
SMWG@mailman.ccsds.org<br>
</font></tt><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg"><tt><font size=2>https://mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg</font></tt></a><tt><font size=2><br>
</font></tt>
<p>
<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>