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

Mudit Gupta mudit.raaj.gupta at gmail.com
Sat Mar 17 02:49:34 PDT 2012


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