[cssm] [EXTERNAL] Re: Use of SICF in service management

Wed Feb 24 09:03:52 UTC 2021

Dear all,

just a quick one, before I have a meeting.

First of all, I knew it will be getting worse, but this is the reason we need the discussion.

Secondly, there are actually two topics, which we here mix up:

  1.  Are the Service Instances on Service level or Service Package level, and how many there can be per service
  2.  Are there one or multiple service instances (SICF) per container (here the text file).

As of point 2, I know this format of ESA / DSN with multiple SI's in a file. We for example are using individual files (I think our software uses some solution of the very early SLE times, and when ESA changed eventually to the multiple-SI's-per file, we stayed with individual ones). Anyway, we know our method is "oldfashioned", thus I have no problem with ESA/DSN file. As said, this would be anyway bilaterally agreed (and we could use i.e. some container like zip file). But this is only DLR, ESA, DSN... What about the rest of the world? Do we know which SICF are most popularly used? What is accepted by Cortex SLE provider for example?

All in all, I do not see an issue here, as said, this may be bilaterally agreed. And for the sake of our exercise, I'd say, go ahead, add the wrapper for SICF at the level of Service Package.

If you are interested to solve just an issue of SICF file wrapper, stop reading here, and read the rest of the mail some day later.

As for the point 1 (this topic is file format independent, and we can maybe keep it just in mind for the moment), there is definitely more than one service instance per service package. So there may be 0 or more Service Instances per service. And I write "or more" and no "just 1", because think please about two following scenarios:

  *   S-Band telemetry reception service (S-Band carrier) - defined as one service in Configuration Profile....
     *   At the end of the service, multiple virtual channels need to be provided. Theoretically one can provide multiple VC's in one Service Instance. But...
        *   ... the software must allow that (for whatever stupid reasons, our software does not, and we may not be the only ones - so we need to have separate service instances for multiple VC's)
        *   ... both provider and user of the SI need to be the same
     *   At the end of the service, multiple virtual channels (or even the same virtual channel) need to be provided to two (or more) different receivers (users). This is a typical scenario for shadow/parallel reception (two control centers hanging on the same service of the antenna at the same time).
        *   One could argue, that if there is different user for a service instance, it would need to be actually separate service agreement. But this would imply also separate service package, conflict resolution or some other method of binding service packages from different users to each other, so that they are not conflicting, and so on....

Actually, the solution with dynamically assigned SLE config and usage of our AbstractParameter things we already have, and how the SACP is planned, would allow for all above without any problems (at least technically).

Regards
Marcin

From: SMWG <smwg-bounces at mailman.ccsds.org> On Behalf Of Colin.Haddow at esa.int
Sent: Dienstag, 23. Februar 2021 20:18
To: Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov>
Cc: smwg at mailman.ccsds.org
Subject: Re: [cssm] [EXTERNAL] Re: Use of SICF in service management

Hi Erik, Hugh, Wes,
                                         just looked at Hugh's example again, I think it actually contains 2 service instances, one for R-AF and the other for F-CLTU. That to me suggests it (potentially) contains all the services required during a pass, i.e. it could be referenced at service package level.

Cheers for now,

Colin

---------------------------------------------------------------------------------------------------------
Dr. Colin R. Haddow,
HSO-GI, European Space Agency,
European Space Operations Centre,
Robert-Bosch-Str 5,
64293 Darmstadt,
Germany.

Phone; +49 6151 90 2896
Fax;      +49 6151 90 3010
E-Mail;  colin.haddow at esa.int<mailto:colin.haddow at esa.int>
---------------------------------------------------------------------------------------------------------

From:        "Barkley, Erik J (US 3970)" <erik.j.barkley at jpl.nasa.gov<mailto:erik.j.barkley at jpl.nasa.gov>>
To:        "Hugh Kelliher" <hugh.kelliher at spaceconnexions.com<mailto:hugh.kelliher at spaceconnexions.com>>, "Colin.Haddow at esa.int<mailto:Colin.Haddow at esa.int>" <Colin.Haddow at esa.int<mailto:Colin.Haddow at esa.int>>, "smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>" <smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>>
Date:        23/02/2021 20:08
Subject:        RE: [EXTERNAL] Re: [cssm] Use of SICF in service management
________________________________

Colin,

I think Hugh is correct.  If you have RAF and RCF and FCLTU for a given tracking pass that means 3 SICFs for that tracking pass.  Presumably if we had MD-CSTS there would the be (some other) form of configuration file needed not to mention TD-CSTS.  To diverge a bit, I think this tends to confirm we really want, ultimately, the SPDF + SCAP to be the mechanism for conveying this kind of information.

-Erik

From: SMWG <smwg-bounces at mailman.ccsds.org<mailto:smwg-bounces at mailman.ccsds.org>> On Behalf Of Hugh Kelliher
Sent: Tuesday, February 23, 2021 10:36
To: Colin.Haddow at esa.int<mailto:Colin.Haddow at esa.int>; smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>
Subject: [EXTERNAL] Re: [cssm] Use of SICF in service management

Hi Colin,

I believe there is one SICF per service type per pass. An example I have for RAF and F-CLTU is:

[SERVICE INSTANCE]

SERVICE_TYPE = R-AF

ID = [{3 2 229}QNTQ-Tabatha:CPX01-Doce-(2)][{3 2 236}1][{4 2 37}1][{4 2 41}1][{3 2 181}1][{3 2 183}1] PEER_ID = West Freugh GS

PORT_ID = 172.26.16.9:5008

START_YEAR = 2002

START_MONTH = 2

START_DAY = 19

START_HOUR = 12

START_MIN = 51

STOP_YEAR = 2002

STOP_MONTH = 2

STOP_DAY = 19

STOP_HOUR = 12

STOP_MIN = 54

TIME_OUT = 10

DELIVERY_MODE = TimelyOnline

LATENCY_LIMIT = 1

TRANSFER_BUFFER_SIZE = 1

ALLOWED_FRAME_QUALITY = AllFrames

INITIAL_PRODUCTION_STATUS = configured

INITIAL_FRAME_SYNC_LOCK = Unknown

INITIAL_CARRIER_DEMOD_LOCK = Unknown

INITIAL_SUBCARRIER_DEMOD_LOCK = Unknown

INITIAL_SYMBOL_SYNC_LOCK = Unknown

SERVICE INSTANCE]

SERVICE_TYPE = F-CLTU

ID = [{3 2 229}QNTQ-Tabatha:CPX01-Doce-(2)][{3 2 236}1][{4 2 14}1][{4 2 18}1][{3 2 97}1][{3 2 72}1] PEER_ID = West Freugh GS

PORT_ID = 172.26.16.9:5008

START_YEAR = 2002

START_MONTH = 2

START_DAY = 19

START_HOUR = 12

START_MIN = 52

STOP_YEAR = 2002

STOP_MONTH = 2

STOP_DAY = 19

STOP_HOUR = 12

STOP_MIN = 55

TIME_OUT = 10

MAX_SLDU_LENGTH = 144

MOD_FREQUENCY = 8

MAX_BUFFER_SIZE = 1024

DATA_RATE = 1000.0

MOD_INDEX = 1.1

INIT_PROD_STATUS = configured

BITLOCK_REQ = true

RF_AVAIL_REQ = 1

PLOP = plop2

INIT_UPLINK_STATUS = false

Cheers,

Hugh

From: SMWG [mailto:smwg-bounces at mailman.ccsds.org] On Behalf Of Colin.Haddow at esa.int<mailto:Colin.Haddow at esa.int>
Sent: 23 February 2021 18:03
To: smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>
Subject: [cssm] Use of SICF in service managemnt

Dear all,
                 just working thro' what using the SICF means for the SMURF and SPDF, if my memory serves me correctly there should be one and only one SICF used during a pass. This being the case it would imply that per service package there would be at most one SICF referenced. Also I think that the SICF would be needed for Offline Services.

Are these valid assumptions ?

Cheers for now,

Colin

---------------------------------------------------------------------------------------------------------
Dr. Colin R. Haddow,
HSO-GI, European Space Agency,
European Space Operations Centre,
Robert-Bosch-Str 5,
64293 Darmstadt,
Germany.

Phone; +49 6151 90 2896
Fax;      +49 6151 90 3010
E-Mail;  colin.haddow at esa.int<mailto:colin.haddow at esa.int>
---------------------------------------------------------------------------------------------------------

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<mailto:dpo at esa.int>).

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<mailto:dpo at esa.int>).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20210224/85fb6fd9/attachment-0001.htm>