GSOC2012HLA

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.

Approach

Design

In order to make ns-3 IEEE 1516 a new HLA compliant scheduler for ns-3 (rtiScheduler), has to be designed along with ns3FederateAmbassador.

• 1. Ns3Federate
• 2. Ns3FederateAmbassador
• 3. LinkToRti

There is a possibility of a two way communication between ns-3 and the other federates, but in the approach mentioned ns-3 is only used as a sink and not a source. This is so because in previous discussions with the mentor a conclusion was drawn that if ns-3 would also be used as a source, it will complicate things. The only-sink methodology can be extended to source and sink after GSoC, but adding it in the GSoC timeframe would be a bit over ambitious. Although, it will definitely be a part of post-GSoC plans.

rtiScheduler

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. Further, some extra functions will also be there. I plan to adopt a strategy in which a server – client paradigm is implemented between rtischeduler and ns3FederateAmbassador. It would be implemented by using sockets. A message server would be set up and appropriate sockets would be used get messages from ns3FederateAmbassador.

I plan to use a standard serialisation/deserialsation opensource library for cross language communication between JAVA (ns3FederateAmbassador) and C++ (rtiScheduler) - TheMessagePack[7].

rtiScheduler will have multiple threads. A thread will be responsible to manage the Message Pack packet messages received from the ns3FederateAmbassador. The message will be decoded and added to the events queue using ns3::Simulator::Schedule(). The message will be send to Informer function for all messages from the RTI. Another task would be to generate and send TimeAdvanceRequest and take proper action on the request being granted from the RTI. This would be because even the events queue is empty the simulation might not have finished; this is so because of the distributed nature of the simulation.

Ns3FederateAmbassador

It receives messages from RTI, the message is translated in MessagePack packet format and sent to the rtiScheduler by an open socket. It will have definitions of semantics which other simulators have to follow in order to federate with ns-3. It will have definition and implementation of the interface between poRTIco and ns-3. I will also be responsible for forwarding the requests to RTI.

Informer Function and updateHLA

The only parameters to Informer will be the nodes ID and the message for informer. The ns-3 modules those wish to subscribe for these updates can and read the node IDs and message from the public classs variable and accordingly change their own state. Although, I haven’t decided on how will the modules be notified for the update. There can be two option – polling (quite unfeasible) or direct notification. In the second one the module will be notified about the update.

Testing approach

• Validation Test 1 (V1): Communication with other Federates (dummy)

Worked on creating a dummy federate which modifies the attributes of the object published by ns3. Both federates use the same RTI - poRTIco. It can be used for testing weather ns3Federate is receiving call backs from RTI or not and further for testing if the whole hla module is communicating with RTI or not.

• System Integration Test 1 (S1): Message Passing between ns3Federate Ambassador and ns3 link-to-rti

This tests checks weather the sockets are working fine between the JAVA code and the C++ code. It basically reads the values from ns3Federate to link-to-rti and logs the messages received.

• System Integration Test 2(S2): Message Passing between RTI and ns3FederateAmbassador

This tests records the events and logs them in order of occurrence. Thus verifying connection between ns3Federate and RTI.

• Unit Test 1 (U1): Checking ns3Federate (Java Sockets)

• Unit Test 2 (U2): Checking link-to-rti (C++ sockets)

• Unit Test 3 (U3):

• Unit Test 4 (U4):

• API (API1) test is to be done with the final HLA RTI API.

TODO

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] http://porticoproject.org/index.php?title=Main_Page
• [6] http://msgpack.org/