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

Mudit Gupta mudit.raaj.gupta at gmail.com
Thu Mar 29 11:19:13 PDT 2012


Dear Professor Pecorella,

I am almost done with my project proposal for HLA interfaces for ns-3. I
wanted to ask should I add omnet++ references for similar implementation in
my project proposal? I will upload the proposal on the website in a day or
two.

I had a discussion with you and/on the mailing list about the idea before
the GSoC application period started. I had sticked to the same for my
proposal :

Make a scheduler, write relevant API.
Use NS-3 as a sink because of the time constrains of GSoC, maybe add source
functionality afterwards
Write a RTI ambassador and which will handle cross-federate communication
and queuing
Modules like "mobility" can register to receive messages from the federate
and correspondingly respond
Write tests, documentation, API details and demo codes, and test with
poRTIco

Do you want me to add anything else? I have obviously elaborated on the
above mentioned points in the proposal.

I would like to sincerely apologize for the delay in submission, but I was
caught up with my exams and thesis interviews. I hope that I can
still receive valuable comments from you and the community about my
proposal and improve the same.

Hope to hear from you soon. Thank you for your time.

Best Regards,

Mudit Raj Gupta

On Sat, Mar 17, 2012 at 3:19 PM, Mudit Gupta <mudit.raaj.gupta at gmail.com>wrote:

> Dear Professor Pecorella,
>
> I would like to congratulate ns-3 for it's selection for GSoC - 2012 as a
> mentoring organization. I will be preparing the proposal keeping in mind
> the conversation we had related to the project. I have some question about
> the project proposal :
>
> 1. Should I mail a basic draft of the proposal to the mailing list for
> review ? ( I am aware that we have to submit the final proposal on the GSoC
> -2012 site)
>
> 2. Is there any specific requirement related to the project that I should
> mention in the proposal?
>
> 3. Is there an application template for ns - 3 or should I follow the GSoC
> guide?
>
> Hope to hear from you soon.
>
> Best Regards,
>
> Mudit Raj Gupta
>
>
> On Fri, Mar 9, 2012 at 12:38 PM, Mudit Gupta <mudit.raaj.gupta at gmail.com>wrote:
>
>>
>> Dear Professor Pecorella,
>> I think I will go with the Ambassador having an inner message queue, as
>> you suggested. Since now even I am convienced that this might be the better
>> option.
>>
>> I will get in touch again if I face any other such issue. As of now
>> ambassador will be the event-dispatcher, while I work on the rest of the
>> design. Thank you for your reply.
>>
>> Best Regards,
>>
>> Mudit Raj Gupta
>>
>>
>>
>>>    On 08/mar/2012, at 11:33, Mudit Gupta wrote:
>>>
>>>  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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>   --------------------------------------------------------------
>>>
>>> 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