GSOC2012HLA: Difference between revisions

From Nsnam
Jump to navigation Jump to search
No edit summary
No edit summary
Line 99: Line 99:
**1.4 Generating and Sending Time advance Request and taking proper action on the request being granted from the RTI. ('''Done''')  
**1.4 Generating and Sending Time advance Request and taking proper action on the request being granted from the RTI. ('''Done''')  


* 2.0 ns3FederateAmbassador  
* 2.0 ns3FederateAmbassador ('''Ns3Federate''')
**2.1 Define socket communication with link-to-rti ('''Done''')
**2.1 Define socket communication with link-to-rti ('''Done''')
**2.2 Define Semantics for other federates to send message to ns-3 ('''Done''')
**2.2 Define Semantics for other federates to send message to ns-3 ('''Done''')
**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  ('''Done''')
**2.3 Define ambassador for ns3 according to poRTIco definition and adding various functions to interface with poRTIco to receive messages and send request and various other functions  ('''Done''')
**2.4 Integrate all the above classes and write a test code to run the ns3FederateAmbassador. ('''Done''')
**2.4 Integrate all the above classes and write a test code to run the ns3FederateAmbassador. ('''Done''')


Line 117: Line 117:
**0.2 Addition of a functionality in which ns-3 will also be used as a source.  
**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.
**0.3 Making more refined and complex model in which ns-3 will be a federate.
'''New Expected Deliverables'''
* Synchronisation


= Plan/Progress =
= Plan/Progress =

Revision as of 09:34, 9 July 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.

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. LinkToRti
  • 3. Synchronising
  • 4. HLA API

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.

Ns3Federate

It consists of basically two parts -

  • ns3Federate
  • ns3FedAmb

ns3Federate:

It takes care of the creating a federation (if not created else joining it), registering ns3 as a Federate and running the main simulation loop. It also deals with publishing, deleting and registering objects and interaction in the RTI.

ns3FedAmb

This segment is also responsible for creating a port and communicating with the LinkToRti code (C++) This basically handles callbacks from the RTI. These callbacks include notification when attribute of an object is changed, new object is added/registered or deleted and when a time advance request is granted. A server – client paradigm is implemented between ns3FedAmb and link-to-rti. It is implemented by using sockets.

link-to-rti

A message server is set up and appropriate sockets are used get messages from ns3FedAmb. It also acts as an entry level module to ns3 code and links ns3Federate with HLA API. It also controls time values and maintains a RTI_CLOCK.

Synchronisation

There is still a lot of debate in the synchronisation of the RTI clock with ns-3. The present approach finalised and yet to be tested looks like making a minor change in wall-clock-syncronizer.cc by changing the GetRealTime to GetRtiTime (which fetches RTI_CLOCK value) and using the real time simulator with almost no modification. Since it will wait for an event to process till real time has been reached (i.e RTI_CLOCK is the new real time). So the function process_one_event will take care of event scheduling.

HLA API

HLA API will be designed to access various features of ns-3-hla like initialise ns-3 Federate, Create Object, Add Attributes to Object, Accessing Attributes of Object.

Testing approach

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

In order to test if ns-3 is acting like a federate, a dummy federate can be found in ``src/hla/test``. It 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

Note: The bold text details the changes/progress from initial deliverables

  • 1.0 rtiScheduler (renamed link-to-rti)
    • 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 receive messages from the ns3FederateAmbassador and uses them appropriately. (chucked)
    • 1.2 Setting up a message server and using appropriate sockets to get messages from ns3FederateAmbassador(Done)
    • 1.3 Handling/decoding messages received (Done)
    • 1.4 Generating and Sending Time advance Request and taking proper action on the request being granted from the RTI. (Done)
  • 2.0 ns3FederateAmbassador (Ns3Federate)
    • 2.1 Define socket communication with link-to-rti (Done)
    • 2.2 Define Semantics for other federates to send message to ns-3 (Done)
    • 2.3 Define ambassador for ns3 according to poRTIco definition and adding various functions to interface with poRTIco to receive messages and send request and various other functions (Done)
    • 2.4 Integrate all the above classes and write a test code to run the ns3FederateAmbassador. (Done)
  • 3.0 HLA API
    • 3.1 Writing the Informer function and update HLA class (Done, link-to-rti has functions to make it similar to informer)
    • 3.2 Writing HLA API for the designed system
  • 4.0 Complex Network Simulation
    • 4.1 Writing a demo model which is HLA compliant (Done, created dummy federate)
    • 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. (Done, publishing objects)
    • 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.

New Expected Deliverables

  • Synchronisation

Plan/Progress

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