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

Mudit Gupta mudit.raaj.gupta at gmail.com
Thu Mar 8 02:34:09 PST 2012


 Dear Professor Pecorella,

I apologize for a late reply. I have been reading literature and planning
on the lines of your mail.


>  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.
>

This should be more or less like a RTI ambassador it will communicate with
the scheduler and will have the information about which module the external
fedrate wants to communicate with. I think (not sure) the queue management
is the job of the scheduler. This RTI ambassador should be a layer between
the other fedrate's RTI and the RTI scheduler.


>  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
>

I think you are absolutely right and in one of the HLA implementation of
Omnet++, I saw a similar architecture in which cSimplemodule extends a
class HLA if it want's communication with the external fedrate and nothing
else has to be modified. So any module can extend or as you said "register"
to use the feature of an interface class to send the messages.


>  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.
>

I have been going through the omnet++ and ns-3 architecture and finding
different ways of implementation. It hope to figure out a good way by the
time I have to prepare my proposal.


>  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.
>

I think this would be better. I was thinking more on the lines like the
external fedrate is a scenario based simulator like Repast S or Netlogo (I
don't know about it's HLA compliance) in which the event is guided by some
multi-agent algorithm (like ant colony, random walk etc.) and as the
scenario changes - like agent move to new positionor new attachments are
made, subsequently ns-3 simulation should change the power and the time of
message being trasmitted to various agents.

I will be going through the documentation and literature and will come up
with a proposal soon. As of now I will try to refine my plan. Please let me
know if you think anything is worth adding. You advice and guidance had
been invaluable. Thank you for your time.

Best Regards,

Mudit


>    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
>
>
>
>
>



More information about the Ns-developers mailing list