NS-MIRACLE Library: Multi InteRfAce Cross Layer Extension for NS
MIRACLE ns2 library is developed by the SIGNET Lab @ the University of Padova, it is designed to allow interlayer communication and flexible multi-layer design in the ns2 simulator. For instance, using this library, e.g., multiple PHY layers can cohexist in the simulator. This allows to simulate, e.g., wireless nodes with multiple radio interfaces. We note that is in general possible to define multiple MAC/ARQ at layer 2 and so on for any other layer of the protocol stack. Additionally, the library contains a set of classes and methods for inter-layer/inter-protocol design and communication. As an example, these primitives allows for the exchange of any type of message/structure/command among modules/protocols. The library is intended to help researcher in implementing any type of cross-layer and multi-technology solution.
The main motivation that drove us to develop this library is to define a standard procedure to generate a multi-layer architecture which also give to us cross layer communication functionalities. In fact, there are already several temptatives to give to ns2 a more flexible structure, i.e., to manage simultaneously multiple technologies at the same time, but all uncoordinated. The results is that now we have different projects that have developed interesting extensions of ns2 but we can not integrate them. Therefore, starting from some primitive ns classes, we define some new classes that are the basic blocks to model heterogeneous architectures. This allows to us to partially reuse the code developed for ns-2 with slight modifications. Moreover, we introduce a standardization in the cross layer messaging in order to give to all the modules/algorithms the possibility of communicating to each others by means of ad hoc structured messages. All these features are introduced in a dynamic fashion, in fact we are developed a dynamic library for ns instead of a classical patch. This allows us to work in very efficient manner, since it not necessary to make any change to the standard ns installation, with the only exception that you have to pacth the first time it in order to give to ns the possibility of managing dynamic library. With such a kind of approach, we would start a new way to developed code for ns. In fact, this method allows to each programmer to developed his onw library with its own new funcionalities/extensions to the standard ns. The standard ns installation should becomes only a skeleton with some basic blocks useful to define the architecture. This will help the diffusion of the several extensions will be developed in all over the world, that nowadays are usually incompatible to each others. Programmers may also take advatage during the debug process, cause the compiling phase of a single library is usually faster than the one in which are involved all the ns packages.
Example of architecture achievable
One of the main basic block of this stucture is rapresented by the class Module. Module is a class designed to contain any protocols or modules that we usually place in stack in order to follow the OSI model in the designing process of the structure, an example of a possible architecture achievable is given in figure above. Since it has to be placed in a stack, its main function is to communicate with the other Modules placed in the above and bottom layers. Therefore we implemented a channel for the communication between module of adjacent layers such as defined in OSI structure, the Service Access Point (SAP). Thanks to the flexibility of the library, it is possible to define any number of modules in any layer and connect them to each other, by means of SAP. This help us in the design of architecture in which are involved multiple techologies for example. SAP are also used to implement the tracing of simulation activity, in fact, thanks to their strategic position, it is possible to trace with an ad hoc format all the packets exchanged between modules at each desidered level. Due to its own nature, we set up an ad hoc module for the channel, in fact it has to be common for all the nodes and have to store some knowledges about all of them (i.e., their spatial position). In order to gives to it such a kind of functionalities we have also to define an ad hoc channel to connect it to all the nodes, that we called Channel SAP (ChSAP). Regarding cross layer communication, we introduce a in each module a new specific type of channel, since OSI does not plan any cross layer messaging in its standard, called Cross-Layer SAP (ClSAP), which is in charge of the delivering of the cross layer messages, this functionality is described in detail in the following section.
NodeCore within the architecture
Another important novelty introduced in this library is the communication between modules by means of Cross Layer Messages, defined in the ClMessage class. These messages are exchanged through the Cross-Layer SAP (ClSAP) and, since all modules are connetected to each others with them, we may use ClMessage as cross layer message. In fact, as mentioned in Module Section, each Module is equipped with a ClSAP and this gives to it the connection to the NodeCore, which is the structure in charge to dispatch all the CLMessage, i.e., we can consider NodeCore as the cross layer bus which also has all the functionalities to manage it. By extending the ClMessage class, it is possible to obtain each ad hoc cross layer message is needed, i.e., it is possible to define new ClMessage with any parameter (structured or not) desiders in order to implement the communication required. To improve the versatility of this structure, we introduce two different types of communication: asynchronous and synchronous. In the first one is not requested any direct answer, the response is not mandatory and, if needed, it may be sent in another ClMessage when it is ready. While, in synchronous ClMessages, it is needed that the recipient answers directly in the same istance of the ClMessage received. This technique gives also to the programmer another important feature: the possibilty to have variables shared by different modules. In fact, when a module receives a syncronous ClMessage, it is sharing the same instance of the ClMessage class with the source, so it may stores this instance and use it as a variable to manage the state of common resources or to exchange information about the current module status.
PlugIn within the architecture
PlugIn class is another novelty introduced to gives more versatility to the structures and so model new architecture. In fact, PlugIn is the father class of Module and it is designed to attach any module direct to the NodeCore external from the stack of modules. In PlugIn are defined only the cross layers communication functionalities of a Module, so it is equipped with the ClSAP in order to be connected to the cross layer bus, placed in NodeCore. This allows to PlugIn to contain all that features that is difficult to put in a fixed position of the stack. We introduced this class in order to give to the programmer the possibilty to place external intelligence that has to collaborate with several modules in the stack and so manage cross-layer functionalities. It is clear that the potentiality of PlugIn are not restricted to the one described above, we may put in this structure for example all the behaviours typical of the whole node (i.e., physical mobility model, energy expenditure model, etc.).
Bin class is a structure implemented for enhanced tracing. In fact, it is in charge to trace all the drops occurrences during the simulation. It is a child class both of SAP and ClSAP, so it inherits all the functions to trace both packets and cross layer messages dropping. Thanks to Bin, a programmer can understand also specific failure situations that normally are not covered by the trace of the sent messages. We design only one instance of Bin for each node in the simulation and then it is provided a connection to it from all the modules/plugins within the architecture.
Generated on Wed Nov 26 15:47:27 2008 for NS-MIRACLE library by
1.5.2