- 1 Mid-Term Report
We deviated from out initial plan as a more efficient and easy method of doing the same was found. A new design was chalked out after the new plans and interaction with the community of other software (poRTIco) used. Some time was lost in the process. After the new plan we started with integration of RTI and writing a RTI client for ns-3. Once the work for the RTI client was completed, a class to handle callbacks from RTI was implemented. Once this was done a dummy federate was written to test the behaviour of ns3 federate. This was followed by development of an entry module (link-to-rti) to read from the client. At present the hla module is created which can be used used for testing. It contains all the RTI files and also a test dummy federate. There is no requirement of installing/downloading any other package, user can clone the repository and test the code. Bulk of the work that requires integration with RTI is completed and ns-3 is receiving messages from other federates. Moreover, timing is also dealt with. Next steps involve writing a HLA API and synchronisation. We would like to get synchronisation out of the way as soon as possible. Next steps also include writing documentation and tests for the created module.
It might appear from the initial proposal that we are behind schedule and may be one (1.1) deliverable short. But most of the functionality of the missing deliverable is incorporated in the new deliverable. Everything else is on schedule and till mid-term we have almost everything which requires the use of external packages done. Some time was lost in making the execution easy for the user, as the project uses external package so methods of simplifying the usage were incorporated in the code and also some supporting scripts were added. This was not dealt in the initial proposal. So, from now the development would be faster as all the supporting frame work is ready and majority of the work of integration, learning and using external package, testing and supporting programs/scripts are ready.
A new Scheduler (not being used)
During the first week of GSoC we worked on a RTI sheduler. This scheduler was suppose to receive messages from RTI through ns-3 federate and had map data structure. It was suppose to convert these messages received into ns-3 events. After few days we analysed the design and figured out that there could be a easier way of doing this by just modifying an implementation of src/syncronization.cc that is wall-clock-syncronizer.cc and using a real-time-simulater-impl.cc as a simulator. Thus, we changed our design a bit.
By the end of second week the new design was ready and we were in touch with the portico community and discussed the project. After input from them we finalised the design. We chucked the RTI scheduler module, although some part of the code was reusable.
ns3 client for communicating with RTI
Next, we worked on getting portico up and running some example federates and creating a federation using two or more federates. Then using the poRTIco documentation we wrote some ns3Federate. ns3Federate basically has the definition for setting up a federation and enabling various features for ns-3 like time definitions. It also creates objects, sets basic attributes and publish and subscribe these objects. Objects can also be registered and deleted through this. It also contains the main simulation loop with all the above mentioned events in order.
After ns3Federate we worked with ns3FedAmb (Federate Ambassador), this basically handles callbacks which the RTI (poRTIco in our case) sends them to ns-3 as and when an object is published, subscribed, deleted or any attribute is changed. A callback is also received in case of a time advance request grant. So, all in all the two classes provide an interface to communicate with the RTI and help in basic synchronisation of the events with other federates by receiving time advance granted callbacks.
Once we were through with this, we had a lot of code but nothing to test it. So, we worked on developing another set of federate and federate ambassador, called dummy and dummyFederateAmbassador. The features of these two were similar to ns-3 but this federate also had a small simulation. It changed the attributes of the object published by ns-3, it changed the MsgType i.e. the type of message to be sent and the Msg i.e. actual text (planning to change it to data rate and delay), so when this federate was run in parallel with ns-3 federate, various functions could be easily tested, like if ns-3 is receiving callbacks when the attributes are changed? and is the changed values of the attributes reflected? After getting rid of some initial bugs everything worked fine.
Getting data from the client to ns3
Next aim was to get these callbacks and messages into ns-3 main code (C++). So a C++ class was created, server.cc. Further, in ns3FedAmb sockets were added. A master - slave configuration was set up between ns3FedAmb and server.cc. When simulation was to be started, finished, object attributes are updated, new objects are published or time advance is granted ns3FedAmb sends a specific string to a given port along with the accompanied message. Server.cc was a simple test program, it reads throgh a port (same as ns3FedAmb) and accordingly take decision. Like on time advance a variable RTI_CLK is incremented. Rest functions for now were only for proof of concept. We also implemented a different thread which hears from ns3FedAmb and main thread can work on something else. It is a requirement since when ns-3 will be handling events from other simulator, it will also have it's own work/events.
Next, we integrated this server.cc code to one of the ns-3 examples for fun (It could later help in developing the HLA API) now a ns-3 example first.cc receives messages from RTI, thus other federates. We tested this by running ns3Fedrate in one shell and parallel running dummy in another shell and first.cc in another. Object was published by ns-3 and dummy both and modified by dummy at each iteration. These changes were transferred to ns3Fedrate and subsequently first.cc and that too keeping time in mind, i.e. synchronised. A very crude form of HLA established.
After this we started refining the server.cc and changed it to link-to-rti.cc and link-to-rti.h. The work on this is still under progress, the idea is that this could be included by hla and user can have API access to these function.
Once link-to-rti is complete we plan to work on Synchronisation and API simultaneously. Then we plan to write some examples to demonstrate the use of API and possible an API test.
(20th July) Synchronisation as of now looks pretty straight forward, although we do have to check it. It seems that just by using the real-time-simulator-impl.cc as the default simulator for hla and changing a synchronizer.cc implementation, i.e. wall-clock-synchronizer.cc to send RTI time as real time, events could be scheduled to RTI time. Moreover, a single function GerRealTime() at presents gives real time, changing it to fetch the value of RTI_CLK might do the trick.
HLA API Design
(27th August) API will be designed for accessing various functions of link-to-rti and also giving the user option to create publishable objects, set and read characteristics. It can easily be used by user in ns-3 scripts in order to access HLA functionalities
(3rd August) Some ns-3 script to demonstrate the use of HLA API will be written to explain the functionality to user.
Testing and Documenting
Rest of the time of the program will be devoted to testing and documenting the code and adding new functionalities (as mentioned in the proposal)