NS2 Mobility Model

Mobility models

Node mobility in MIRACLE is ruled by two classes named BMPosition and GMPosition, derived from Position class. The former utilizes a Basic Movement (BM) model and the latter uses a Gauss-Markov (GM) model.
These models are those we provide with the MIRACLE release, but you can feel free to create your own!

The Basic Movement model moves nodes in uniform straightforward way. Nodes are moved by setting their destination by using the Tcl command setdest, which accepts as inputs the coordinates of the destination and the speed (in meters per second) of the node. The true position of the node is updated only when needed, e.g. when the destination is changed or a calculation (as freespace attenuation or upon a getPosition() call) is requested by an external module. In this model no control is added about borders of simulation field, so this means that a node, reached the setdest coordinates, will move in that direction and will not stop since a new destination is set.

The GMPosition Model is more complex than the previous one. In this case, nodes perform direction changes autonomously and a control of the behavior at borders is provided. Nodes adopting this mobility model requires mean direction (in radians) and a mean speed as inputs.
Speed and direction are calculated form mean values given as inputs multiplicating them by a random value, according to the following law (the law for direction is the same):

speed_ = (alpha_*speed_) + (((1.0-alpha_))*speedMean_) +
+ (sqrt(1.0-pow(alpha_,2.0))*Gaussian());

As could be seen, the current (in this case) speed is calculated from previous value of speed and the mean speed, given as input. The incidence of the mean value is controlled by the alpha parameter, which assumes values between 0 and 1. So the variations of speed are due to the ``old'' current speed and a random value provided by the Gaussian() function. It must be noticed that even if speedMean_ is 0, the current speed could be non-zero. As in the previous model, position update is calculated when needed, but in this case every step from previous update is computed (because a gaussian walk is made of several gaussian steps). The time resolution of each step is provided by the updateTime_ variable.

There are four different behaviors for nodes reaching boundaries. These are REBOUNCE, HARDWALL, SPHERIC and THOROIDAL. In the first case the node rebounces on the border line, it means that if at least one of the coordinates exceeds the x or y field width it will be carried back in the field by a value equal to the difference between the exceeding coordinate and the field maximal coordinate. For example, if the simulation field is 100 meters wide and the new coordinate is 102 meters, then rebounce algo will carry back coordinate to 98 which is 100 - (102 - 100).
The HARDWALL behavior expects that the node stops its movement at the border of the field, if trepassed. In case of SPHERIC behavior the node will be put on the other side of the field, like an overflow. In the last case, THOROIDAL, the node is put at the centre of the field.

Interface of two networks Ns2 Miracle

NS2 Miracle:

Here iam like to aware about ns2 miracle which connect two interface in the networks for wg if you want to connect the UMTS and VANET you can use this or any two interface can be connected by this ns2 miracle

MIRACLE is an extension for the ns2 simulator developed by the Department of Information Engineering at the University of Padova. The acronym stands for Multi InteRfAce Cross Layer Extension and describes one of its new capabilities intoduced by modularity. In fact, using MIRACLE you will be able to manage your nodes in a cross layer fashion and additionally multi technology support (whithin the same node) is provided.

The possibility of loading library dinamically has been introduced in standard ns2 simulator, starting from release 33. By now, we will suppose that you are using this simulator or a more recent one.

In MIRACLE every modification can constitute a stand alone library and can be loaded when necessary with the load command. In this case modifications could be rapidly intercharged, loading the appropriate library. Furtermore a modification of a library requires only to recompile the code associated to that library and it usually requires some seconds. So you can save memory space (you need only a ns2 distribution) and precious time for debugging and simulations.

A motivation for creating the MIRACLE Extension is to fill the gap between ns2 and the simulation of multi technology enviroments and provide the possibility of performing cross layer messaging. This is one of the most advanced field of research and an opportune instrument for simulation is needed. The way MIRACLE reached this goal is a generic and technology independent approach.

MIRACLE node is based on generic entities connected by each other. The protocol stack is implemented through entities called Modules. The novel idea consists in allowing presence of more than one Module per layer. Every Module is connected to another entity called Node Core. It goes off the layer ordering scheme and has the task of coordinating message exchange between modules. It also stores the node actual position in the simulation field in order to allow position-dependent calculations such those related to propagation and interference models.

There are also another kind of entities connected to the Node Core, called PlugIns. As Node Core, they don't depend on layer classification. Due to their independence from the OSI stack, the PlugIn may be exploited for node coordination functionalities (e.g., cognitive engines and multi interfaces manager) and cross layer intelligence.

Communication among different layers is provided by Service Access Points (SAP), accordingly to OSI structure. As in ns2, connections between Modules, NodeCore and PlugIns are made by Connectors, but the latter are completely reprojected to trace packets passing through them according to rules extablished by user.