[Ns-developers] GSoC Idea - HLA interfaces for ns-3

Tue Feb 28 13:37:54 PST 2012

Hi,

sorry if I didn't answer before, I was quite busy myself.

You're right about the scheduler, we'll need to have an RtiScheduler for sure. I'm not sure we'll need to modify the core tho. In theory it shouldn't be needed at all, since the message passing is just between some models and the federation.

How to achieve this belongs to your ideas, but I'd start by clarifying the models we want to add. Most probably the most flexible architecture would be to have a class responsible for HLA message passing, messages queue management and so on and adopt an internal to ns-3 message-passing structure to forward the relevant messages to the RTI-enabled modules.

The RTI modules (let's say, mobility) could "register" themselves to the interface class so to export the right handlers. This would allow a more flexible architecture without requiring a whole ns-3 core system overhaul. Consider that only the RTI-enabled modules will be interested in the "external" messages, so the core and such shouldn't be affected at all.

You're right about Omnet++, as is we should aim at a similar feature set to be supported, but consider that the architectural solution might be completely different. I'd suggest about this to check what messages are handled by Omnet++, then trash it and find our own solution. Omnet++'s one might be as well "tainted" by Omnet++'s architecture, and ns-3 one is quite different.
As an example: we don't need to cope with ns-3 events already in the scheduler's queue. They was generated by objects in a time ahead of Simulator::Now() and they WILL be received in the future. When they'll be handled (at their proper time), then they will be evaluated.

The RTI itself, at a extremely high abstraction layer, isn't anything more than an orchestration system for time and events. The problem arises when it comes to understand WHAT kind of messages are passed around, but then again, it's a matter of design. Shall ns-3 be a source or just a sink for other federate simulators ? At the start I'd suggest to use ns-3 as a simple sink, so just receiving messages from others. Source is a bit more complex and it would require to know what messages could be relevant for others.
As an example: ns-3 is used as a simulator for a complex network transferring alert messages for tsunami (could be). The message generation is triggered by an external simulator (scenario simulator). The message reception is recorded in an ns-3 application and shall issue a corresponding message-arrival event for another scenario simulator.  The scenario simulator could change link's parameters (link outages) and so on, but at the end the module responsible for sending out a message will be the ns-3 application, and that one will have to be built by the coders willing to simulate that scenario.
Hence, right now let's consider just the sinks.

I'll have a look at the Omnet's implementation as well, to see for relevant inputs.

Cheers,

Tommaso

On 27 Feb 2012, at 08:42, Mudit Gupta wrote:

> Dear Professor Pecorella,
> 
> Thank you for your reply. I apologize for a late reply as I was stuck
> with my mid-term examination. I had gone through the links you
> mentioned and gone through a related publication:
> 
> http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4700136
> 
> I guess (from similar omnet++ implementation, ns3 source code and HLA
> rules) we need to implement something like a ns3::rtischeduler (which
> is a sub class of the base class ns3::scheduler) but apart from the
> functions (Remove, RemoveNext, PeakNext, IsEmpty, GetTypeID and
> Insert) we might have to add a few new functions like :
> 
> 1. ReplyToRTI
> To send a reply to other federate by any ns3 function
> 
> 2. SelectComFunc
> To set the function which receives the message from the other fedrate
> 
> apart from this we need to develop a ns3 Ambassador class in order to
> communicate with the RTI ambassador. Most of the project use
> 
> http://www.porticoproject.org/index.php?title=Main_Page
> 
> I think we can start by aiming just transaction of messages between
> ns3 and federate although the model developed should be scalable to
> meet other requirements.
> 
> I guess the core needs to be modified a bit. I am not sure weather I
> am correct or not. I have been reading the source and documents and
> although the very crude plan suggested, is more or less similar to
> Omnet++ HLA. Am I on the right track?
> 
> Please let me know anything that you think is useful. Your help would
> be invaluable. In the meantime I will try to detail the plan. Thank
> you for reply and time.
> 
> Best Regards,
> 
> Mudit Raj Gupta
> 
> On 2/22/12, Tommaso Pecorella <tpecorella at mac.com> wrote:
>> Hello,
>> 
>> the project details are not yet finalized, as right now it was just an idea.
>> The basis about it is the analogous HLA support offered by Omnetpp. The idea
>> is not to do-it-like-them tho, the idea is to do it somewhat *better*.
>> 
>> The work probably will involve a new scheduler (time is of the essence, and
>> time is shared in this case) and proper APIs for the relevant parts.
>> Considering we're aiming not at federating with similar simulators (e.g.,
>> with Omnetpp) but with higher-level ones (e.g., scenario simulators), the
>> task might be a bit simpler.
>> 
>> I'd suggest to check the solution offered for Omnetpp as a start, purely
>> because it might give a good indication of what are the features of an
>> HLA-compliant simulator have.
>> 
>> Some links are:
>> http://freedownload.is/doc/hla-compliant-network-enabled-distribute-modeling-and--2632737.html
>> http://www.ce.uniroma2.it/~egalli/projects.html
>> 
>> I just did a fast google search, there might be more around.
>> 
>> About the GSOC timeframe, there is no real problem. The ideas are right now
>> there to be discussed and modified so to be reasonably done in the official
>> GSOC period. Most of the bigger projects are just started in a GSOC with a
>> proof of concept as the final deliverable. Then they're finalized
>> afterwards, it can take months to have them really integrated into the main
>> codebase, but that's normal. In the post-GSOC period the students are
>> supposed to be involved in the development and finalization of their
>> contribution, but tmopre people can contribute to it toward the final
>> product.
>> 
>> Anyway, we can discuss about what is reasonable for the GSOC timeline,
>> however I think that the bare minimum would be a scheduler compliant with
>> HLA and a module or two able to be "driven" by an external scenario
>> simulator. Probably the mobility one being the most interesting due to the
>> immediate and "visible" output.
>> Example: HLA scenario simulating a traffic jam (highway: a car crash and the
>> opposite line experiences a traffic jam due to the idiots looking) while the
>> simulator does a Vehicular Network Simulation.
>> 
>> Of course to have a complete HLA compliance we'd need more modules to be
>> integrated, ranging from applications to propagation models, but as you
>> noticed, doing all of them would be too time consuming.
>> The important thing about the solution is that it should be easy to extend
>> for the missing models, so to serve as a guideline for future expansions. So
>> the most important part is actually the solution design rather than the raw
>> coding.
>> 
>> Best regards,
>> 
>> Tommaso
>> 
>> 
>> 
>> 
>> 
>> 
>> On 21 Feb 2012, at 08:01, Mudit Gupta wrote:
>> 
>>> Dear Professor Pecorella,
>>> 
>>> I am Mudit Raj Gupta, a fourth year undergraduate student of M. Sc.(H)
>>> Chemistry and B.E.(H) Electronics and Instrumentation I from BITS - Pilani
>>> (INDIA) (http://www.bits-pilani.ac.in/). I am interested in applying for
>>> the project "High-Level Architecture (HLA) interfaces for ns-3" for GSoC
>>> 2012. I am interested in modeling and simulation of complex distributed
>>> systems and swarm intelligence. I successfully completed GSoC - 2011 for
>>> Center for the Study of Complex Systems (CSCS) - University of Michigan. I
>>> worked on Complex Systems Modelling using an Agent Based Modelling tool -
>>> Repast Symphony. I am also interested in Wireless Sensor Networks and
>>> Networked Embedded System.
>>> 
>>> I have gone through the project description given here:
>>> 
>>> http://www.nsnam.org/wiki/index.php/GSOC2012Projects#High-level_architecture_.28HLA.29_interfaces_for_ns-3
>>> 
>>> and gone through the references including "IEEE 1516-2010 - IEEE Standard
>>> for Modeling and Simulation (M&S) High Level Architecture (HLA) --
>>> Framework and Rules". The project look interesting although I am not
>>> sure weather it could be completed during GSoC. Although these are
>>> only my initial thoughts.
>>> 
>>> It would be greatly appreciated if you and/or community members could
>>> provide any pointers or further information about the project at their
>>> leisure. Thank you for your time.
>>> 
>>> Best Regards,
>>> 
>>> Mudit Raj Gupta
>>> BITS-Pilani Goa Campus
>> 
>> --------------------------------------------------------------
>> 
>> The nice thing about standards is that there are so many to choose from.
>> And if you really don't like all the standards you just have to wait another
>> year until the one arises you are looking for.
>> -- A. Tanenbaum, "Introduction to Computer Networks"
>> 
>> --------------------------------------------------------------
>> 
>> Tommaso Pecorella - Ph.D.
>> 
>> Assistant professor
>> Dpt. Elettronica e Telecomunicazioni
>> Università di Firenze
>> 
>> CNIT - Università di Firenze Unit
>> 
>> via di S. Marta 3
>> 50139, Firenze
>> ITALY
>> 
>> email: tommaso.pecorella at unifi.it
>>       tommaso.pecorella at cnit.it
>> 
>> phone : +39-055-4796412
>> mobile: +39-320-4379803
>> fax   : +39-055-494569
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> --------------------------------------------------------------
>> 
>> Thinking evolution:
>> "To be is to do" - Socrates
>> "To do is to be" - Sartre
>> "Do Be Do Be Do" - Sinatra
>> "Scooby Dooby Do" - Scooby Do
>> "Yaba Daba Doo!" - Fred Flintstone
>> 
>> --------------------------------------------------------------
>> 
>> Tommaso Pecorella - Ph.D.
>> 
>> Assistant professor
>> Dpt. Elettronica e Telecomunicazioni
>> Università di Firenze
>> 
>> CNIT - Università di Firenze Unit
>> 
>> via di S. Marta 3
>> 50139, Firenze
>> ITALY
>> 
>> email: tommaso.pecorella at unifi.it
>>       tommaso.pecorella at cnit.it
>> 
>> phone : +39-055-4796412
>> mobile: +39-320-4379803
>> fax   : +39-055-494569
>> 
>> 
>> 
>> 
>> 

--------------------------------------------------------------

Thinking evolution:
 "To be is to do" - Socrates
 "To do is to be" - Sartre
 "Do Be Do Be Do" - Sinatra
 "Scooby Dooby Do" - Scooby Do
 "Yaba Daba Doo!" - Fred Flintstone 

--------------------------------------------------------------

Tommaso Pecorella - Ph.D.

Assistant professor
Dpt. Elettronica e Telecomunicazioni
Università di Firenze

CNIT - Università di Firenze Unit

via di S. Marta 3
50139, Firenze
ITALY

email: tommaso.pecorella at unifi.it
       tommaso.pecorella at cnit.it

phone : +39-055-4796412
mobile: +39-320-4379803
fax   : +39-055-494569