[Moims-sc] Re: Would SM&C have a few hours to discuss network management?

Nestor.Peccia at esa.int Nestor.Peccia at esa.int
Tue Oct 14 13:20:50 UTC 2014


Meh ran
What happens if you have a DTN node at a Ground Station?
And it is a Ground Station from other Agency in an ABA configuration?
If the DTN NM info is encapsulated in a TM packet, I do not see any issue
But if you have a node at the Ground Station there are issues with CSS
That we need to address
My suggestion, as CESG Chair,
Is "discuss the issues"
Not " do not do it"
And Meteron is an enabler but does not represent all cases
And by no way the most complex configurations
Ciao
Nestor

Sent from my iPhone

> On 14.10.2014, at 09:17, Mehran Sarkarati <Mehran.Sarkarati at esa.int> wrote:
> 
> Hi Nestor,
> 
> How does this relate to the question asked by Scott? If I understand correctly, he is asking if they can use the SM&C application layer M&C services (Parameter and Aggregation Service) for retrieving TM items, which are related to DTN-management (e.g. the status of each node, the ping time to the next node, ...)
> 
> I guess at communication layer, for each scenario (deep space or not) an appropriate DTN protocol and convergence layer will be selected but if you want to transfer DTN management telemetry items, it means you are using DTN in the first place, right? As far as the MO services are concerned, what you need to do is to define a communication protocol binding for MAL to whatever DTN protocol you use (e.g. BP or another).
> 
> The METERON case is the proof of concept of how such binding works. For a different deployment a different binding (or encoding) may be needed but the concept is the same.
> 
> So, I think the answer is: Yes you can use the MO Parameter or Aggregation service for doing what you want to do and yes you can bind it to whatever DTN protocol suitable for your deployment, similar to what we have done for METERON.
> 
> But I may be missing something here.
> 
> Kind regards
> Mehran
> Nestor Peccia---14/10/2014 13:32:46---From: Nestor Peccia/esoc/ESA To: Mehran Sarkarati/esoc/ESA at esa,
> 
> 
> From:	Nestor Peccia/esoc/ESA
> To:	Mehran Sarkarati/esoc/ESA at esa, 
> Cc:	Mario Merri/esoc/ESA at esa, "moims-sc-bounces at mailman.ccsds.org" <moims-sc-bounces at mailman.ccsds.org>, "Barkley,	Erik J (317H)" <erik.j.barkley at jpl.nasa.gov>, "Scott,	Keith L." <kscott at mitre.org>, "moims-sc at mailman.ccsds.org" <moims-sc at mailman.ccsds.org>
> Date:	14/10/2014 13:32
> Subject:	Re: [Moims-sc] Re: Would SM&C have a few hours to discuss network	management?
> 
> 
> 
> We must analyze potential issues with SIS and CSS
> Meteron configuration is not similar to a deep space or L2 cross support scenario
> 
> Sent from my iPhone
> 
> On 14.10.2014, at 06:37, Mehran.Sarkarati at esa.int wrote:
> Hi Scott, Mario, 
> 
> If I may add one more detail, which may be of interest to Scott: 
> 
> In the context of the METERON project, ESA has already implemented, deployed and operationally validated some of the MO M&C services to publish a various set of TM parameters (which were not Spacecraft related but for instance related to the health status of a laptop and even the status of a button on particular software running on that laptop on the ISS) using DTN BP at communication layer (we used ION 2.3 and are currently updating to ION 3.2). 
> 
> We have also implemented a so called BPPing Agent, which was deployed on each DTN node and periodically pinged other nodes. The results of the BPPings were then published to all intersted listeners (our M&C system instances) using again the related MO M&C Parameter service. 
> 
> In practice, the mentioned M&C service were used to publish and receive the TM parameters encoded in binary over BP over Channel Protocol (the convergence layer below BP) from ISS to the ground. The exact same implementation of these services (same code at run-time) had published a second endpoint to provide the same functionality via a different protocol (XML encoding over HTTP) on the ground. 
> 
> So basically two set of different consumers have used the same services to retrieve the TM, using the communication protocol of their choice. If you are interested, I can prepare a presentation for the discussion session. I have added Sebastian in cc, who is our DTN expert, in case of DTN specific questions. 
> 
> Kind Regards 
> Mehran 
> 
> 
> 
> From: Mario.Merri at esa.int 
> To: "Scott, Keith L." <kscott at mitre.org>, 
> Cc: "Barkley, Erik J \(317H\)" <erik.j.barkley at jpl.nasa.gov>, moims-sc at mailman.ccsds.org 
> Date: 14/10/2014 11:21 
> Subject: [Moims-sc] Re: Would SM&C have a few hours to discuss network management? 
> Sent by: moims-sc-bounces at mailman.ccsds.org 
> 
> 
> 
> Hi Keith, 
> 
> I have earmarked a 2h joint meeting with SIS-DTN in the agenda of SM&C WG starting at 13:30 of Thu 13Nov. Is that OK? 
> 
> Without pre-emptying the discussion, the MO SM&C Services provide a coherent set of services to monitor and control *any* remote (controllable) object, not necessarily only as spacecraft. The operations of these services are defined in an abstract manner (via the MAL). For a specific deployment, and here I am touching on your question on "how those parameters are encoded and transported, the abstract services need to be mapped to a concrete encoding/transport. This is achieved by a dedicated blue book at the level of MAL. 
> 
> The bottom line is that 
> - one can use the MO M&C services to monitor and control any remote object 
> - one can select the most appropriate encoding/transport for its deployment of these services. 
> 
> I hope the above helps. How do you want to play the joint meeting? For instance, would you like to send us in advance a set of questions that you would like to be addressed? 
> 
> Thanks 
> 
> __Mario 
> 
> 
> 
> From: "Scott, Keith L." <kscott at mitre.org> 
> To: "Mario.Merri at esa.int" <Mario.Merri at esa.int>, "Barkley, Erik J (317H)" <erik.j.barkley at jpl.nasa.gov>, 
> Cc: "roger.thompson at scisys.co.uk" <roger.thompson at scisys.co.uk> 
> Date: 13/10/2014 20:09 
> Subject: Would SM&C have a few hours to discuss network management? 
> 
> 
> 
> The SIS-DTN working group is about to start doing some work in the network management for the BP layers of the stack. Would it be possible for us to get a few hours together with SM&C to talk about the interaction between the monitor and control services and what we (think we) need for DTN network management? I’m thinking just an hour or two for the two WGs to exchange their views of what’s going on would be really helpful to us. 
> 
> >From my interpretation of the 522.1-R-3 book, the MO SM&C Services provides a framework for (general-purpose) monitor and control, which is tailored towards spacecraft. *IF* I understand correctly, a way for e.g. Bundle Protocol network management could ‘plug in’ to SM&C with a set of ‘drivers’ for the spacecraft to monitor / control the various BP parameters of interest according to the various SM&C services. [Is that a completely broken characterization?] There’s then a question of how those parameters are encoded and transported. 
> 
> Sometime Thursday (PM?) of the CCSDS meetings would be best for the SIS-DTN WG, but we’re meeting Thursday and Friday and if that wouldn’t work, I’ll find some other time. 
> 
> I know that Erik and the CSS groups are interested in talking with you as well, and that would be a good time for them. 
> 
> 
> --keith 
> 
> 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.
> _______________________________________________
> Moims-sc mailing list
> Moims-sc at mailman.ccsds.org
> http://mailman.ccsds.org/mailman/listinfo/moims-sc
> 
> 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.
> 
> _______________________________________________
> Moims-sc mailing list
> Moims-sc at mailman.ccsds.org
> http://mailman.ccsds.org/mailman/listinfo/moims-sc

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-sc/attachments/20141014/ce6d9feb/attachment.html>


More information about the MOIMS-SC mailing list