Difference between revisions of "GSOC2012HLA"

From Nsnam
Jump to: navigation, search
(Plan)
Line 6: Line 6:
 
* About me: I'm a fourth year student presently working for my M.Sc (H) in Chemistry and B.E. (H) in Electronics and Instrumentation Engineering at Birla Institute of Technology and Science - Pilani at Goa Campus. My research interest include modelling and simulation of complex systems and use and analysis of evolutionary algorithms for swarms.  
 
* About me: I'm a fourth year student presently working for my M.Sc (H) in Chemistry and B.E. (H) in Electronics and Instrumentation Engineering at Birla Institute of Technology and Science - Pilani at Goa Campus. My research interest include modelling and simulation of complex systems and use and analysis of evolutionary algorithms for swarms.  
  
= Approach =
+
= Related Terms and Software (planned to be used) =
  
 +
== HLA and RTI ==
  
 +
HLA, which is an IEEE standard, facilitates interoperability among simulations and promotes reuse of simulation models. Using HLA, a large-scale distributed simulation can be constructed by linking together a number of distributed simulation components (or federates) into an aggregate simulation (or federation) [2].
 +
 +
Run-time infrastructure (RTI) is a middleware that is required when implementing the High Level Architecture. RTI is the fundamental component of HLA. It provides a set of software services that are necessary to support federates to coordinate their operations and data exchange during a runtime execution. In other sense, it is the implementation of the HLA interface specification but is not itself part of specification
 +
 +
Federates can communicate to RTI through RTI ambassador. Request of a service from/to federate to/from any other federate is done through interactions. There are two basic ways to communicate:
 +
 +
* Interchange messages between federates
 +
* Publication of objects that are shared between federates
 +
 +
== poRTIco [6] ==
 +
 +
poRTIco is an open-source Java implementation of the above mentioned standard and it offers libraries to implement a federate ambassador. It is an interface between the RTI and the simulator. Federates can communicate to RTI through RTI ambassador. Every time the federate schedule wants to advance in the time, it calls the methods timeAdvanceRequest of the RTI ambassador.
 +
 +
== HLA – Repast Symphony [1] ==
 +
 +
HLA-Repast Symphony is modified version of Repast Symphony, a scenario based simulator, with the support of HLA that allows communicating with other sector simulator like ns-3 (if HLA support is added).
 +
 +
= Approach =
  
 
== Testing approach ==
 
== Testing approach ==

Revision as of 10:23, 23 May 2012

HLA interfaces for ns-3

  • Student: Mudit Raj Gupta
  • Mentors: Tommaso Pecorella
  • Abstract: The project deals with writing a HLA compliant scheduler for NS-3 and relevant supporting classes with a HLA API to help NS-3 participate in distributed simulations with other simulators, preferably scenario simulators. HLA is an IEEE standard, facilitates interoperability among simulations and promotes reuse of simulation models. Project also deals with testing of the same by using a portico RTI.The complete proposal can be found here.
  • About me: I'm a fourth year student presently working for my M.Sc (H) in Chemistry and B.E. (H) in Electronics and Instrumentation Engineering at Birla Institute of Technology and Science - Pilani at Goa Campus. My research interest include modelling and simulation of complex systems and use and analysis of evolutionary algorithms for swarms.

Related Terms and Software (planned to be used)

HLA and RTI

HLA, which is an IEEE standard, facilitates interoperability among simulations and promotes reuse of simulation models. Using HLA, a large-scale distributed simulation can be constructed by linking together a number of distributed simulation components (or federates) into an aggregate simulation (or federation) [2].

Run-time infrastructure (RTI) is a middleware that is required when implementing the High Level Architecture. RTI is the fundamental component of HLA. It provides a set of software services that are necessary to support federates to coordinate their operations and data exchange during a runtime execution. In other sense, it is the implementation of the HLA interface specification but is not itself part of specification

Federates can communicate to RTI through RTI ambassador. Request of a service from/to federate to/from any other federate is done through interactions. There are two basic ways to communicate:

  • Interchange messages between federates
  • Publication of objects that are shared between federates

poRTIco [6]

poRTIco is an open-source Java implementation of the above mentioned standard and it offers libraries to implement a federate ambassador. It is an interface between the RTI and the simulator. Federates can communicate to RTI through RTI ambassador. Every time the federate schedule wants to advance in the time, it calls the methods timeAdvanceRequest of the RTI ambassador.

HLA – Repast Symphony [1]

HLA-Repast Symphony is modified version of Repast Symphony, a scenario based simulator, with the support of HLA that allows communicating with other sector simulator like ns-3 (if HLA support is added).

Approach

Testing approach

I plan to incorporate a TestSuite with a few Unit Tests, System Integration Tests and Validation Tests. The details are as follows:

  • Validation Test 1 (V1): Compare Random Walk
  • System Integration Test 1 (S1): Message Passing between ns3Federate Ambassador and rtiScheduler.
  • System Integration Test 2(S2): Message Passing between RTI and ns3FederateAmbassador
  • Unit Test 1 (U1): Checking standard scheduler functionalities
  • Unit Test 2 (U2): Check whether rtischeduler is decoding the message properly and adding is to event queue.
  • Unit Test 3 (U3): Checking whether the scheduler is generating a Time advance request sending to the ports in MessagePack format
  • Unit Test 4 (U4): Check whether ns3FederateAmbassdor is decoding/encoding the message properly and sending it to ports/RTI.
  • API (API1) test is to be done with the final HLA RTI API.

Deliverables

  • 1.0 rtiScheduler
    • 1.1 The class will be the sub class of the base class ns3::Scheduler and all virtual functions defined would be written like – Insert, PeakNext, IsEmpty, Remove, Remove. Activating a thread responsible to manage the MessagePack packet messages received from the ns3FederateAmbassador and uses them appropriately.
    • 1.2 Setting up a message server and using appropriate sockets to get messages from ns3FederateAmbassador
    • 1.3 Handling/decoding messages received and adding it in proper format to the event queue for the simulator to process using ns3::Simulator::Schedule
    • 1.4 Generating and Sending Time advance Request and taking proper action on the request being granted from the RTI.
  • 2.0 ns3FederateAmbassador
    • 2.1 Define socket communication with rtischeduler and conversion of message to MessagePack packet format
    • 2.2 Define Semantics for other federates to send message to ns-3
    • 2.3 Define ambassador for ns3 according to poRTIco definition and adding various functions ton interface with poRTIco to receive messages and send request and various other functions
    • 2.4 Integrate all the above classes and write a test code to run the ns3FederateAmbassador.
  • 3.0 HLA API
    • 3.1 Writing the Informer function and update HLA class
    • 3.2 Writing HLA API for the designed system
  • 4.0 Complex Network Simulation
    • 4.1 Writing a demo Repast symphony model which is HLA compliant*
    • 4.2 Writing a ns3 model which is HLA compliant* and using both simultaneously
  • 0.0 If time permits/future plans (post GSoC)
    • 0.1 Adding the possibility of object publication and sharing in the existing code and integrating it.
    • 0.2 Addition of a functionality in which ns-3 will also be used as a source.
    • 0.3 Making more refined and complex model in which ns-3 will be a federate.

Plan

  • Week 1 May.21 -- May.27: Deliverables 1.1 and 1.2
  • Week 2 May.28 -- Jun.03: Deliverables 1.3 and 1.4
  • Week 3 Jun.4 -- Jun.10: Testing and Documenting 1.0
  • Week 4 Jun.11 -- Jun.17: Deliverables 2.1 and 2.2
  • Week 5 Jun.18 -- Jun.24: Deliverables 2.3 and 2.4
  • Week 6 Jun.25 -- Jul.01: Testing and Documenting 2.0
  • Week 7 Jul.02 -- Jul.08: Buffer 1 (Prepare for Mid-Term Evaluation)
  • Week 8 Jul.09 -- Jul.15: Deliverables 3.1 and 3.2
  • Week 9 Jul.16 -- Jul.22: Testing and Documenting 3.0
  • Week 10 Jul.23 -- Jul.29: Deliverable 4.1
  • Week 11 Jul.30 -- Aug.5: Deliverable 4.2
  • Week 12 Aug.06 -- Aug.12: Buffer 2 (Prepare for Final Evaluation)
  • Week 13 Aug.13 -- Aug.19: Buffer

References

  • [1] http://www.cs.bham.ac.uk/research/projects/hlarepast/
  • [2] Distributed Repast Agent Based Simulation with HLA - R. Minson and G. K. Theodoropoulos, CONCURRENCY AND COMPUTATION: PRACTICE AND EXPERIENCE
  • [3] Large Scale Agent Based Simulation on the Grid - Dan Chena , Georgios K. Theodoropoulos, Stephen J. Turner, Wentong Cai, Robert Minson, Future Generation Computer Systems, 24 (2008), 658-51
  • [4] MobileOnRealEnvironment-GIS: a federated mobile network simulator of mobile nodes on real geographic data- Emiliano Casalicchio, Emanuele Galli and Vittorio Ottaviani Dipartimento di Informatica, Sistemi e Produzione (DISP), 2009 13th IEEE/ACM International Symposium on Distributed Simulation and Real Time Applications
  • [5] HLA-OMNET++: an HLA compliant network simulator Emanuele Galli, Gaetano Cavarretta and Salvatore Tucci, 12th 2008 IEEE/ACM International Symposium on Distributed Simulation and Real-Time Applications
  • [6] http://porticoproject.org/index.php?title=Main_Page
  • [7] http://msgpack.org/