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

Tommaso Pecorella tpecorella at mac.com
Fri Mar 30 07:15:29 PDT 2012


Hi,

I can't see why you shouldn't include the relevant references ! We're not in a war against Omnet++, so why not :)

ABout your proposal, I'll wait for it then! And no, I don't think you should really add more topics, the ones we discussed are already quite challenging.

Cheers,

T.



On 29/mar/2012, at 20:19, Mudit Gupta wrote:

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

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

$25: for you a pizza and some beers with friends, for someone 
     might change their lives. Think about it.

Kiva.org - Loans That Change Lives

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

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