<font size=2 face="Arial">Nestor,</font>
<br>
<br><font size=2 face="Arial">sorry for the delay in the answer. Below
my comments:</font>
<br>
<br><font size=2 face="Arial"><b>Monitor and Control Recommendations: Spacecraft
vs TTC Network </b></font>
<br><font size=2 face="Arial">Here I believe there is an overlap which
is currently unresolved.</font>
<br>
<br><font size=2 face="Arial">My (simple) thinking is that SLE (or CSTS
as they call it now) relates in the transfer of TM and TC between GS and
CC pretty much at protocol level (i.e. w/o any understanding of the TM
and TC data that is being transferred). Therefore these are transfer services
(as they are in fact called).</font>
<br>
<br><font size=2 face="Arial">As soon as you go higher in the stack and
transfer meaningful data object, you get into the MO Service domain. In
this context the MD-CSTS overlaps with the MO M&C Services. I also
believe that the terminations of the Transfer Services and MD-CSTS are
different: at least in the ESA case, the Transfer Services will terminate
on one hand in the TMTCS and on the other side in the NIS. For the MD-CSTS
ESA will have to develop a TM parameter provider at the ground station
side while on the CC side the parameters will be monitored by the MCS.
This is the same interface that would be required for MO M&C Services
(which will eventually be the same used to M&C the S/C). Also, this
shows that the interfaces for Transfer Services and MD-CSTS are completely
different and there is little justification to keep them with the Transfer
Services. The same holds true for TD-CSTS.</font>
<br>
<br><font size=2 face="Arial">Clearly, CCSDS could have specific service
definitions for MD and TD, but this will be largely inelegant and not a
well engineered solution.</font>
<br>
<br><font size=2 face="Arial"><b>File transfer</b></font>
<br><font size=2 face="Arial">The SM&C will only provide 1) a service
to manage the transfer of files (that will use whatever underlined FT mechanism,
e.g. CFDP, FTP, SFTP) and 2) operations in relevant services to make use
of files (for instance, the SW Management MO Service will include an operation
"load SW patch from file".)</font>
<br>
<br><font size=2 face="Arial">I believe there is no overlap here.</font>
<br>
<br><font size=2 face="Arial"><b>Archictures vs reference models</b></font>
<br><font size=2 face="Arial">CSSA documents should include the MO Services
in their architecture. Possibly no overlap, but these docs could be the
tools to identify/resolve overlaps and provide a unified architecture to
CCSDS space systems. This is not the case now.</font>
<br>
<br><font size=2 face="Arial"><b>TLM, CMD, RNG services</b></font>
<br><font size=2 face="Arial">For TLM and CMD, any MO service that needs
to communicate with the S/C will put the MAL messages in CCSDS TM/TC packets
and these will travel to/from the S/C as defined by the missions, i.e.
via SLE if so decided. Therefore, there will not be any specific MAL->SLE
binding.</font>
<br>
<br><font size=2 face="Arial">I believe there is no overlap here. </font>
<br>
<br><font size=2 face="Arial">For Ranging, we go back into the application
level services (so potential overlapping), but I have not investigated
in depth the matter.</font>
<br>
<br><font size=2 face="Arial">Regards,</font>
<br>
<br><font size=2 face="Arial">__Mario</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Nestor.Peccia@esa.int</font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">moims-sc@mailman.ccsds.org,
</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">29/08/2014 10:49</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">[Moims-sc] CESG
overlaps</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">moims-sc-bounces@mailman.ccsds.org</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=2 face="sans-serif">Dear all,</font><font size=3> </font><font size=2 face="sans-serif"><br>
The CESG has worked out (and minimised) the number of potential overlaps
(see attached file) across Areas and WGs.</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
Next CESG webex is on 2nd Sept 2014 from 5 till 7 pm.and the main Agenda
point is the overlap discussion.</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
I would appreciate if the SMC WG can send me any comments you might have
on them</font><font size=3> <br>
<br>
<br>
</font><font size=2 face="sans-serif"><br>
ciao</font><font size=3> </font><font size=2 face="sans-serif"><br>
nestor</font><font size=3> </font>
<br><tt><font size=3>This message and any attachments are intended for
the use of the addressee or addressees only.<br>
The unauthorised disclosure, use, dissemination or copying (either in whole
or in part) of its<br>
content is not permitted.<br>
If you received this message in error, please notify the sender and delete
it from your system.<br>
Emails can be altered and their integrity cannot be guaranteed by the sender.<br>
<br>
Please consider the environment before printing this email.<br>
[attachment "d1-OverlapIdentifications-29-Aug-2014.xlsx" deleted
by Mario Merri/esoc/ESA] </font></tt><tt><font size=2>_______________________________________________<br>
Moims-sc mailing list<br>
Moims-sc@mailman.ccsds.org<br>
</font></tt><a href="http://mailman.ccsds.org/mailman/listinfo/moims-sc"><tt><font size=2>http://mailman.ccsds.org/mailman/listinfo/moims-sc</font></tt></a><tt><font size=2><br>
</font></tt>
<br><PRE>This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.
Please consider the environment before printing this email.
</PRE>