Home Zigbee Tutorial System Performance Helpful scripts for ns-2
NS (Version-2) is an object oriented, discrete event simulator, developed under the VINT project as a joint effort by UC Berkeley, USC/ISI, LBL, and Xerox PARC. It was written in C++ with OTcl as a front-end. The simulator supports a class hierarchy in C++ (compiled hierarchy), and a similar class hierarchy within the OTcl interpreter (interpreted hierarchy). The two hierarchies are closely related to each other; from the user’s perspective, there is a one-to-one correspondence between a class in the interpreted hierarchy and one in the compiled hierarchy.
The network simulator uses two languages because simulator has two different kinds of things it needs to do. On one hand, detailed simulations of protocols requires a systems programming language which can efficiently manipulate bytes, packet headers, and implement algorithms that run over large data sets. For these tasks run-time speed is important and turn-around time (run simulation, find bug, fix bug, recompile, re-run) is less important.
On the other hand, a large part of network research involves slightly varying parameters or configurations, or quickly exploring a number of scenarios. In these cases, iteration time (change the model and re-run) is more important. Since configuration runs once (at the beginning of the simulation), run-time of this part of the task is less important.
ns meets both of these needs with two languages, C++ and OTcl. C++ is fast to run but slower to change, making it suitable for detailed protocol implementation. OTcl runs much slower but can be changed very quickly (and interactively), making it ideal for simulation configuration. ns (via tclcl) provides glue to make objects and variables appear on both languages.
The tcl interface can be used in cases where small changes in the scenarios are easily implemented. Similarly, the C++ code can be changes when processing of all incoming packets are done, or when changes in the behavior of the protocol is anticipated.
In ns, the advance of time depends on the timing of events which are maintained by a scheduler. An event is an object in the C++ hierarchy with an unique ID, a scheduled time and a pointer to an object that handles the event. The scheduler keeps an ordered data structure, with the events to be executed and fires them one by one, invoking the handler of the event.
The simulator is initialized using the TCL interface. It is in this file that a new simulation object is created and several tcl commands relating to the network formation and its properties are added. When a new simulation object is created, the initialization procedure performs the following tasks:
Packets may be handed to NsObjects at scheduled points in time since a node is an event handler and a tasks performed over a packet is an event. Tasks over a packet should be the only type of event scheduled on a node. The initialization of the packet formats will set up the field offsets used for the entire simulation.
The scheduler is an event driven time management mechanism, which launches the earliest scheduled event, executing it to completion and returning back to execute the next event. An event comprises of the time at which it need to be launched along with a handler function. One property of the scheduler to be noted here is when two or more events occur at the same time (meaning, they have to be executed at the same time). Under these circumstances it would decide the precedence based on the order in which they have been scheduled.
A null agent is created to act as a sink for packets, both successfully transmitted and dropped. Packets that are dropped for any reason, or the packets that are not intended to be counted, and the packets that reach the destination node successfully are destined for this agent. The primary part of the simulator is the scheduler which would execute the events at their start times. This is the primary function which forms the root of a tree of other dependent functions. The execution of a branch of this tree of events and their functions would produce an effect of simulating the network behavior.
Given below is a source snippet of the “run” function of the scheduler. Its function is to extract the next event from the heap and dispatch it for execution. Dispatch a single simulator event by setting the system virtual clock to the event’s timestamp and calling its handler.
void Scheduler::run()
{
instance_ = this;
Event *p;
while (!halted_ && (p = deque())) { // Extract the next event
dispatch(p, p->time_); // Dispatch the event.
}
}
Dispatch is a single simulator event by setting the system virtual clock to the event’s timestamp andcalling its handler. Some important models implemented in ns-2 are described here.
Queue Model
The following code block defines the queue class which implements the queuing mechanism.
class Queue : public Connector {
public:
virtual void enque(Packet*) = 0;
virtual Packet* deque() = 0;
void recv(Packet*, Handler*);
void resume();
int blocked();
void unblock();
void block();
protected:
Queue();
int command(int argc, const char*const* argv);
int qlim_; /* maximum allowed pkts in queue */
int blocked_;
int unblock_on_resume_; /* unblock q on idle? */
QueueHandler qh_;
};
The enque and the deque functions are called to add a packet to the queue or to remove a packet from the queue, when its ready for transmission. The resume function is used to revert back to the unblocked state. The qlim variable is used to specify the maximum queue length. However the class is responsible for buffer management and scheduling, and the low level functioning is performed by the class packet queue.
Energy Model
The task of the energy model is to maintain the updated energy content of a node. A class defining the energy model is produced here.
class EnergyModel : public TclObject {
public:
EnergyModel(double energy) {energy_ = energy;}
inline double energy() {return energy_;}
inline void setenergy(double e) {energy_ = e;}
virtual void DecrTxEnergy(double txtime, double P_tx)
{ energy_ -= (P_tx * txtime); }
virtual void DecrRcvEnergy(double rcvtime, double P_rcv)
{ energy_ -= (P_rcv * rcvtime); }
protected:
double energy_;
};
The energy model is implemented pretty simply in NS-2. The function, setenergy is used to initialize a node with initial energy content. The double variable, energy holds the current energy level. After every packet transmission or reception the energy content is decreased. The time taken to transmit or receive along with the power consumed for transmission or reception of a bit/byte of data is passes as parameters to the functions, DecrTxEnergy and DecrRcvEnergy respectively. And these functions would thus decrease the energy content of the node. Given the simplicity of the implementation of the energy model, the results thus obtained by simulations can be quite accurate, as long as the power consumed by transmission/reception of a bit/byte of data is correct.
The simulator needs the tcl scenario file as input. So the intended scenario of the network is presented as a sequence of tcl commands which are fed to the network simulator, and the simulator produces the resultant network performance analysis in two separate files. They are:
The network simulator (ns) comes along with an interesting tool, called the
Network Animator (NAM). Nam is a Tcl/TK based animation tool for viewing network
simulation traces and real world packet trace data. The design theory behind nam
was to create an animator that is able to read large animation data sets and be
extensible enough so that it could be used in different network visualization
situations. Under this constraint NAM was designed to read simple animation
event commands from a large trace file. In order to handle large animation data
sets a minimum amount of information is kept in memory.
Event commands are kept in the file and are read from the file whenever
necessary. A snapshot of NAM in action is presented in figure 1.
Figure 1: NAM Snapshot
The following passages describe the simulation structure, to generate the final statistics. Several scripts and programs have been designed for this project to generate the results. This section of the documentation concentrates in explaining these programs, the passed parameters, in detail and the organization of the programming structure to create the simulation environment which would generate graphable results. The figure 2 explains the inter dependency of the scripts and programs of the simulation environment.
figure 2: Process Structure
The frist step in operating the autosim application, is creating the file, parameters.txt, which holds all the simulation parameters. Its contents include, the number of simulations to be performed, the parameters for the traffic generation, the number of datarates and correspondingly, the datarate values for which simulation is to be performed.
The seed for the random number generator is chosen as the simulation iteration number. Hence if the simulation is conducted for hundred number of times, the seed value ranges anything between one to hundred, based on the current iteration number.
This application is designed to support either frequency band operations. Specifying the frequency of operation of the PAN would allow it to use the right simulation source file (*.tcl).
The program is also responsible for choosing the right simulation path and
the source file (*.tcl)
containing the network scenario and settings, and executing it with ns.
The wireless PAN(*.tcl) file contains parameters and variables which
help change the network scenario and settings and control the simulation
process. Settings like, channel type, propagation model, queue length, node
starting time, beacon order, superframe order, start and stop time of the
simulation, file containing the current seed value, antenna height, and several
other parameters specific to WPAN simulations are referred as TCL commands. The
file also creates the scenario file using the utility, scen gen. It also
contains commands (which can be enabled/disabled) to start the network animator,
and scripts analyzing the trace file, after the simulation.
This file is fed to the network simulator, which would generate additional files, for tracing. The analyzing script file (avg_throughput.awk) takes the trace file as input and writes its results into custom files, which are again used for further processing.
– scen_gen [number-of-nodes] [X-Pos-of-coord] [Y-Pos-of-coord]
[Personal-Operating-Space]
number-of-nodes: Number of nodes to be placed around the coordinator.
X-Pos-of-coord: X position of the coordinator, with respect to the area of the
network dimensions.
Y-Pos-of-coord: Y position of the coordinator, with respect to the area of
operation of the network.
Personal-Operating-Space: The operating space or the reachabilitiy of the
coordinator. The nodes are required to be placed equidistantly around the
coordinator, for the test scenarios in this report, within the operating space
of the coordinator, this parameter is utilized to arrange the nodes along an
imaginary circle drawn around the coordinator with this value as radius.
Example: scen_gen 11 25 25 10
– scen_gen [?/help]
The help/usage messages.
Figure 3: Node placement by scen_gen
It is the node position file, holding the positions of all the nodes around
the coordinator. Currently this
file is being generated with the utility, scen gen. However, it is a simple text
file, which can be easily
edited to place the nodes at desired positions. Note that the positions of the
nodes should respect the
boundaries of the network mentioned in the source file, wpan.tcl
The process structure defined so far would generate the required files that can be used to produce final analyzed results. It has been observed that because of the discrepancy in the device starting time and the time at which traffic for a particular node is started, there are segmentation faults, which result in a failed simulation for a particular seed value. It is to be realized that each seed value would generate a new scenario, which would influence the association phase of the network. In some cases, all devices are associated pretty quickly as soon as they are started, and before they could act as traffic source or destination. However, in cases when the traffic start time is early such type of situations might arise. But these situations can be eliminated by keeping the traffic start time considerably farther than the start time of the node leaving enough room for the devices to successfully associate to the network. But contemplating future situations this utility has been designed to eliminate unsuccessful simulations, and generate the average results. The figure 4 depicting the structure and the inter dependencies on various files to generate the final analyzed results is presented.
figure 4: Analysis Structure
The zigbee modules used in this project have been jointly developed by The City College of New York and Samsung Advanced Institute of Technology, USA. These software modules can be downloaded from the following location [3]. Since the standard defines only the MAC and the PHY layer, the interface to higher layers has been provided with intermediate sub-layer just above the MAC, called the SSCS (Service Specific Convergence Sublayer). Since a full description of the upper layers will be redundant, the SSCS would act as source and destination for the data.
The source code has been adopted with minor modifications to suite the requirements of this project. The changes made are highlighted in the following sections. Firstly, given an introduction of the various primitives in chapter-3, the following section refers to the software implementation of these primitives to give a brief idea of how the functions behave with each other to communicate to its peer node as an entity.
The coordinator of a network is switched ON with the following command. It is used to specify a starting time for the device, along with other initializing parameters such as Beacon order, Superframe order, Beacon Transmissions, etc.
$ns_ at 0.0 "$node_(0) sscs startPANCoord 1 3 3"
;# startPANCoord <txBeacon=1> <BO=3> <SO=3>
This function is directed to the source file corresponding to the sscs layer
and the commands from the tcl script functions are decoded in the function, int
SSCS802_15_4::command, which would extract the commands and the parameters
passed and finally the function responsible to start the coordinator void
SSCS802_15_4::startPANCoord is parsed with these parameters and executed. The
function determines the current ’step’, based on a set of predefined steps, as
in here are the steps corresponding to starting the coordinator and the step
responsible to start the other devices. In the first step, it would enable its
features, like setting the BO and SO, authority to transmit beacons, assigning a
macShortAddress to itself, and finally scanning the channels to establish a
network.
In the first steps of formation of a network, it would save its short address to the PIB attribute value, macShortAddress, by calling the function, Mac802_15_4::MLME_SET_request. The function Mac802_15_4::MLME_SET_confirm would confirm the status of the attempt to write the MAC PIB value, replying with either a success or a failure with an appropriate reason. The node would then call on the function, Mac802_15_4::MLME_SCAN_request to perform a scan of all the supported channels either actively or passively and associate to a channel to establish a PAN network. Again the channel scan mechanism is carried out in a linear fashion. In the first step, beacon transmissions are disabled by setting the BO to 15, and ending any running CSMA-CA sessions. This is followed by the scanning mechanism based on the scan type chosen which is passed as parameter to the function. The scan type chosen can be any of the following:
Once the scantype is resolved, the scanning mechanism is achieved through again as a series of steps. In the first step PIB attribute value for the supported channels is requested using the function, Phy802_15_4::PLME_GET_request, which is later confirmed using the function Phy802_15_4::PLME_GET_confirm. It would assign a macPANId of “0xffff” to itself, indicating it is not yet associated. It would also initialize the variables for scan duration, current channel being scanned, number of scanned channels, etc. The current channel being scanned is saved in the PIB attribute value, phyCurrentChannel to indicate that all further transmission and receptions can be carried out in this channel, using the function, Phy802_15_4::PLME_SET request. The function, would test the validity of the channel by passing it to the function, Phy802_15_4::channelSupported. The result of this attempt to write a PIB attribute value is verified by the function, Mac802_15_4::PLME_SET_confirm.
The function would then call on, Mac802_15_4::dispatch, which handles the control to the procedure, Mac802_15_4::mlme_scan_request. This function call would resume the other steps of the scanning mechanism. The next step being step-1, where the scan mechanism for the active and passive scan is implemented. The part of code executed depends on the type of scan mechanism. For an active scan the part of code issuing a data-request command is implemented, however, for the passive scan type there is no need for a data-request command. It listens for any beacon transmissions in the current channel of operation, by setting its transceiver to the receiver mode. This is implemented using the function, Phy802_15_4::plme_set_trx_state_request by passing on the parameter, p_RX_ON. When the node is operating in the active scan mode, it would wait for its turn to transmit using CSMA-CA and issue a data-request message. One important function that can be mentioned here which is used for a clear channel assessment is the Mac802_15_4::csmacaBegin. This would mark the completion of step-1 and the control would now move back to the calling function.
A graphical view of the above program control flow is presented in the following picture. It is to be understood that only a branch of several such program flows is presented in the figure 5.
figure 5: Program Flow
Several modifications have been done to the original source code to
personalize the code to ZMD’s Transceiver. The source code depends on the way,
data is interfaced. If data is passed directly from the upper layers (SSCS, for
example), the behavior of the code has been in accordance with the protocol.
However, it is always not possible to send data directly from the upper layers.
Frequent changes in the traffic parameters make this a non-idealistic way of
dealing with the situation. Hence, using the 4.7 Software Modifications 36 NS-2
data interface to use external data generators, helps in these situations. But,
this revealed several problems which are discussed in the following sections.
Similarly, problems like Radio frequency selection, number of scanning channels,
triggering of unwanted routing mechanism and address resolution for star
topologies, improper messing up of EDThresh_ (used for Energy Detection
mechanism) and
CSThresh_ (Used for Carrier Sensing) are some of the other
problems that are dealt in this section. The section highlights these problems
in detail and highlights the changes made to the source code to eliminate or
move around these problems.
The receiver ED measurement is intended for use by a network layer as part of
a channel selection algorithm. It is an estimate of the received signal power
within the bandwidth of an IEEE 802.15.4 channel. During the Clear Channel
Assessment procedure for the CSMA-CA algorithm, using mode-1, use the ED
measurement to determine the status of the channel. The Energy Threshold value,
EDThresh_ comes into play as a reference. Thus, any ED measurement which is
above the EDThresh_ value shall indicate the channel is busy, and value less
than the EDThresh_ shall indicate a free medium. Similarly the CSThresh_
indicates the carrier sensing ability of a node. It is the least power signal of
the incoming signal that the receiver can detect. However, in the source code,
the EDThresh_ is never
mentioned and the CCA mechanism in turn uses CSThresh_
as the threshold to assess a clear channel, which is prone to misunderstandings
and confusion. It does not provide a meaningful and understandable distinction
between the CSThresh_ and EDThresh_.
The confusion cannot be understood until we realize the significance of EDThresh_ and CSThresh_. According to the standard, EDThresh_ is atmost 10dB above the Receiver sensitivity. But, the carrier sense threshold, CSThresh_ , is chosen based on the Personal Operating Space of the devices. And in some cases, the receiver may not be sensitive enough, hence is very likely the RXThresh_ to be above the CSThresh_ . Following the original code might allow an error free operation as long as the receiver sensitivity is same as the carrier sensing capability of the device and also when assumed that the EDThresh_ is same as RXThresh_. Its true that these conditions are difficult to implement. Hence, separating the dependence of EDThresh_ on CSThresh_ would give a better control on the architecture.
The following modification is implemented to incorporate EDThresh_ ,
separating it from CSThresh_ . But an ideal implementation would be to modify
the ’mac’ layer files to incorporate the variable individually, which would
allow EDThresh_ to be specified as a TCL command in the scenarios. However, this
is a
much easier method of implementation. An important fact to be remembered
here is that, the EDThresh_ is assumed to be 10dB above the RXThresh_ . Modifiy
the variable, ’aboveRxThresh’ to set it to other value.
Function: Phy802_15_4::CCAHandler
Add the following code at the start of
the function.
// (aboveRxThresh)dB above RxThresh_
int aboveRxThresh = 10;
// Convert
RxThresh_ to dBm
double RxindBm = 10 * log10(RXThresh_ * 1000);
//
EDThresh_ in dBm
double EDThreshIndBm = RxindBm + aboveRxThresh;
//
EDThresh_ in Watts.
double EDThresh_ = pow(10.0, EDThreshIndBm/10.0) * 0.001;
Also modify,
t_status = (rxTotPower[ppib.phyCurrentChannel] >= CSThresh_)?p_BUSY:p_IDLE;
to,
t_status = (rxTotPower[ppib.phyCurrentChannel] >= EDThresh_)?p_BUSY:p_IDLE;
and,
t_status = ((rxTotPower[ppib.phyCurrentChannel] >=CSThresh_)
&&(rxTotNum[ppib.phyCurrentChannel] > 0))?p_BUSY:p_IDLE;
to,
t_status = ((rxTotPower[ppib.phyCurrentChannel] >=EDThresh_)
&&(rxTotNum[ppib.phyCurrentChannel] > 0))?p_BUSY:p_IDLE;
The MAC sublayer builds an MPDU to transmit from the supplied arguments. The TxOptions parameter indicates how the MAC sublayer data service transmits the supplied MSDU.
0x00 −> DirectT ransmission −>
Endnodes
0x02 −> GTStransmission
−> Coordinator/Endnodes
0x04 −>
indirecttransmission −> Coordinator
If the TxOptions parameter is equal to 0x00, indicating a direct transmission, the MAC-Sublayer transmits the MPDU simply by competing for its turn to transmit using slotted CSMA-CA in the CAP for a beacon-enabled PAN or unslotted CSMA-CA for a nonbeacon-enabled PAN.
If the TxOptions parameter specifies that a GTS transmission(0x02) is required, the MAC sublayer will determine whether it has a valid GTS. If the device is a PAN coordinator, it will determine whether it has a receive GTS with the device with the given destination address. If a valid GTS could not be found, the MAC sublayer will issue the MCPS-DATA.confirm primitive with a status of INVALID GTS. If a valid GTS was found, the MAC sublayer will defer, if necessary, until the GTS. At this time, the MAC sublayer transmits the MPDU without using CSMA-CA, provided that the entire transmission and acknowledgment, if requested, can be completed before the end of the GTS.
Similarly a value of 0x04, indicates an Indirect transmission of the MPDU. Generally its a transmission type that is only possible by a coordinator. The coordinator intimates the nodes which have data to receive, in the pending address fields of the beacon. A node upon reception of the node, checks the pending address fields and upon finding its address mentioned, prepares a DataRequest message and transmits it to the coordinator. The coordinator on receiving the datarequest message, acknowledges with an acknowledgement message and if the node has data to be sent, sends the data, using CSMA-CA. Also, the TxOptions parameter can be used to specify, security, which is not implemented in the code, yet and hence is not considered any further.
The implementation of the TxOptions parameter (referred as txoption in the source code), allows to choose the transmission type based on the node in consideration. However, as said earlier, it is not possible to control this parameter when a data generator, like a cbr, tcp or a poisson, is interfaced to NS-2 to generate traffic automatically. The data needs to be passed from the upper layer, which in this case is the SSCS. The code is written to assume a default value of 0x00 for data transmission. So the following modification in the function, ”Mac802_15_4::recv” has been done to choose the right txoption value based on the node type. However, support for GTS transmission type is not yet implemented.
Function: Mac802_15_4::recv
Replace,
txop |= Mac802_15_4::txOption;
with,
if (capability.FFD&&(numberDeviceLink(&deviceLink1) > 0))
txop |= 0x04;
else
txop |= 0x00;
The source code inherently supports the 2.4Ghz of operation. Since the frequency mode of operation for our current study is 868Mhz, the following modification, has been implemented to choose the right frequency band.
Function: SSCS802_15_4::startPANCoord The following lines need to be commented. Presence of these code lines prevent scanning the channels ranging from 0-10, which are the supported by the 868 and 914Mhz, frequency band. The code allows scanning of channels from 0-10, only in the absence of a free channel to establish a PAN, in the range of 11-27. However, working in the current scenario, such situations are remote, because the focus of this study is only a standalone star network topology.
// for (i=11;i<27;i++)
// if ((T_UnscannedChannels & (1 << i)) == 0)
//
break;
// if (i >= 27)
A device working in the 868Mhz or the 914Mhz frequency band, the number of channels supported are 11, together for the 868 and the 914 Mhz bands, a node should scan all of these channels to either associate to a PAN or to establish one. However, since we only simulate a standalone network, without any alien devices present in their vicinity, we limit the number of scanning channels to 3. It is to be noted that this change does not fix any bug in the code, but is implemented only to save simulation time. Also to be noted that, this would give a wrong idea about the association time of the devices. This change need to be taken into consideration before working with association/orphan-scanning times.
File: p802_15_4sscs.cc
// Scan the first three channels. 0, 1 and 2.
UINT_32
SSCS802_15_4::ScanChannels = 0x0007
The number of channels supported is indicated by the parameter, def phyChannelsSupported in the file, p805_15_4const.h.
File: p802_15_4const.h
#define def_phyChannelsSupported 0x07ff
The code does not provide support for passive mode of scanning. The following modifications in their respective indicated locations would implement it.
Function 1: SSCS802_15_4::MLME_SCAN_confirm
Modify,
//Including Passive scantype
if (ScanType == 0x01)
dispatch(status,"MLME_SCAN_confirm");
to,
//Including Passive scantype
if (ScanType == 0x01 || ScanType == 0x02)
dispatch(status,"MLME_SCAN_confirm");
Function 2: Mac802_15_4::scanHandler
Modify,
if (taskP.mlme_scan_request_ScanType == 0x01)
taskP.taskStep(TP_mlme_scan_request)++;
to,
if ((taskP.mlme_scan_request_ScanType == 0x01) ||
(taskP.mlme_scan_request_ScanType == 0x02))
taskP.taskStep(TP_mlme_scan_request)++;
Routing is a method of determining routes to nodes to which information is due for transfer. The routing mechanism is guided with routing tables, which holds the best path to the destination node. These tables might have a direct path to the destination or a path to the nearest node, which can forward the information further, thus bridging the route to the destination node. A node which has data to be transmitted to a destination node, first looks up into its routing table, to determine if a path to the destination is available. If yes, it would go ahead with the transmission to the next nearest node in the path or may transmit a Route Request message to determine a route to the node.
However, a simple STAR topology with one way communication with the coordinator doesn’t require passing through the routing mechanism. Yet, we use the AODV routing in the scenarios. Since there can be no forwarding of data in an IEEE 802.15.4 STAR topology, the next hop to the destination would be the destination itself. Hence there is no need for any determination if an entry of the path is missing in the routing table. Information can be directly sent without any lookup, being assured it is sent in the right path. Given this explanation, the routing table lookup and route finding mechanism is considered, unnecessary. Hence the following changes are made to prevent calling the resolve procedure for route finding, hence always assuming the route is present in the routing table. And finally, filling the next hop address for the node same as the destination. It is to be noted that these changes does not support other topologies which need route resolution.
Function: AODV::recv
Replace,
if ( (u_int32_t)ih->daddr() != IP_BROADCAST)
rt_resolve(p); // Check of route is present
else
forward((aodv_rt_entry*) 0, p, NO_DELAY);
with,
if ( (u_int32_t)ih->daddr() != IP_BROADCAST)
forward((aodv_rt_entry*) 1, p, NO_DELAY); //Always assume
route is present.
else
forward((aodv_rt_entry*) 0, p, NO_DELAY);
Function: AODV::forward
Comment the following lines.
// if(ih->ttl_ == 0) { // Drop the packet if its Time To Live is expired.
//#ifdef DEBUG
// fprintf(stderr, "%s: calling drop()\n", __PRETTY_FUNCTION__);
//#endif // DEBUG
// drop(p, DROP_RTR_TTL);
// return;
// }
Replace,
assert(rt->rt_flags == RTF_UP);
rt->rt_expire = CURRENT_TIME + ACTIVE_ROUTE_TIMEOUT;
ch->next_hop_ = rt->rt_nexthop;
with,
// assert(rt->rt_flags == RTF_UP);
// rt->rt_expire = CURRENT_TIME + ACTIVE_ROUTE_TIMEOUT;
ch->next_hop_ = ih->daddr();
The address resolution protocol is used to resolve the MAC addresses from the IP address. If the node has a mapping of the IP address to the MAC address, it would use it, but if its ARP table does not have an entry of the ARP of a destination node, it issues the ARP request with the IP address of destination. Nodes receiving it, respond with the MAC address of the node, if they have one. And, again as in the case of routing, given the minimal requirements of a STAR topology, an ARP message seeking the MAC address of the destination is unnecessary.
The function, arplookup() is called each time there is a packet to be transmitted. When there is no entry for the destination, the function is originally designed to return 0. And the calling function,arpresolve(), is supposed to send the arp request messages. But since we want to disable any request message transmission, we make changes to give an impression that an address mapping is always present in the arp table.
Reformat the function, ARPTable::arplookup, as in the following:
Function: ARPTable::arplookup
ARPEntry* ARPTable::arplookup(nsaddr_t dst)
{
ARPEntry *a;
// If a match is found, use it.
for(a = arphead_.lh_first; a; a = a->nextarp()) {
if(a->ipaddr_ == dst)
return a;
}
// The following change applies when no arp entry is found. We simply make a
// new entry and enable it by setting the up_ flag, assign the mac address of
// the destination same as the IP Address, and finally return the object.
a = new ARPEntry(&arphead_, dst);
a->up_ = 1;
a->macaddr_ = dst;
return a;
}
The MAC sublayers immediately enables the receiver after the transmission of the MPDU and waits for an acknowledgement from the recipient for at most, macAckWaitDuration. The value is dependent on the frequency of operation.
An important point to be mentioned is that, for 2.4Ghz operation, the ideal
value for macAckWaitDuration is 54. However, for NS-2 simulations, taking a
value, of 55 is appropriate because of an inherent problem with the scheduler.
In certain simulations with 54 as the Ack wait duration, for the 2.4Ghz
operation, there are extensive retransmissions. Generally retransmission are
carried out when the source node cannot receive an acknowledgement with in the
macAckWaitDuration time, if acknowledgements are enabled. And extensive
debugging revealed that the transmission has been successful, and the
destination node responds with an acknowledgement. However, the wait duration
elapses by the time the acknowledgement reaches the source node. Coincidence as
it may seem, the time of reception of the acknowledgement and retransmission of
the next data frame is the same. But the order of these events is determined
only by the scheduler. Since the two events occur at the same time, the
precedence is determined by the earliest scheduled event and hence the
retransmission of the data packet event is
chosen. Changing the scheduler mechanism would be inappropriate in these
situations, hence a longer wait duration for the macAckWaitDuration has been
proposed.
Simulation is a flexible means for assessment of the performance offered by a telecommunication system. However, identifying the correct simulation parameters is key for a successful and nearly realistic analysis of any study. The following discussion focuses on the task of identifying the correct parameters to generate a realistic network scenario, while explaining their meaning and their reason of choice (if any) in detail. General parameters for basic simulations are described here. However, the parameters that impact the network performance are discussed in the next chapter where we introduce the performance analysis of the system.
Traffic Type
This thesis report is based on results simulated with a Constant Bit Rate (CBR) application, based on the internet protocol, UDP (User Datagram Protocol). Its primary features are:
An FTP traffic with a TCP connection is also possible. However, given its advanced features like congestion control, requiring dynamic adjustment of the transmission rate based on the traffic conditions, it is hard to implement simplistic and power efficient devices, for menial applications.
Also a more abstract reason can be that, since a performance analysis would require to test the limits of the network, a CBR traffic with a constant transmission rate, would help us determining the brink of congestion. Performance metrics like delivery ratio would be more meaningful in these situations. Whereas, for a TCP source, flow controlling, would dynamically adjust the transmission rate. Hence delivery ratio would inadvertently be 100%.
Number of Flows
The number of active nodes involved in a communication with the coordinator varies depending on the simulation requirement and the metric being investigated. However, in the simulations indicated in the next chapters the number of flows are 8.
Packet Size
The packet sizes assumed be to 70bytes. This is exclusive of the RTR, MAC and PHY layer headers.
Traffic Direction
The traffic flows are all one way, with the communication directed to the coordinator. The study is being investigated with particular focus on low datarate wireless sensors communicating with a central node updating it with the application information.
The parameters specific to nodes are highlighted in this section.
Number of Nodes
The simulation is carried out with 15 active nodes. One of them being the coordinator.
Coordinators
Since a simple star network topology is being simulated, only a single coordinator is present.
Node Movement
The nodes remain stationary.
Node Position
The nodes are placed along an imaginary circle around the coordinator, with radius equal to the personal operating space of the nodes.
The traffic and node parameters are summarized in the following table.
| Parameter | Value |
| Traffic Type | CBR |
| Number of Nodes | 15 |
| Number of Flows | 8 |
| Number of Coordinators | 1 |
| Node Movement | None |
| Node Position | Manual (Along a circle of radius POS) |
| Traffic Direction | Node -> Coordinator |
| Packet Size | 70Bytes |
Table 1: Traffic Parameters
Radio Propagation Model
There are three propagation models supported by the network simulator. They are:
These models are used to predict the received signal power of each packet. At the physical layer of each of these models there is a Receive threshold value. Each packet received at this layer should be above this threshold. In the current simulations for the IEEE 802.15.4 technology, using a model as simple as Free-Space wouldn’t suit our expectations, given that the nodes may not have a direct line-of-sight all the time. Also, applying the Shadow model would be over estimating the scenario, since the node distances cannot be more than 100 meters. Hence a safe bet is the Two-Ray Ground model.
Antenna Type
The antenna type used in the simulations to deduce these results has been the Omni directional Antenna. The antenna has be chosen for its ability to transmit with equal power in all directions. This is a primary requirement, since the node density is not limited to a fixed location or direction.
Transmitter Gain
It is the ratio of the intensity of the radiated signal to that of the transmitted signal at its input, at the transmitter. It is taken as 1.0, since the transmitter does not amplify the incoming signal power and would radiate whatever it receives.
Receiver Gain
It is the ratio of the received signal power to that of the output power of the receiver. Again the receiver does not amplify the incoming signal power, hence a value of 1.0.
PathLoss
It is the attenuation or power loss (because of obstructions, link distance, or poor antenna height) of an electromagnetic wave during its transmission from the transmitter to the receiver. However, we assume an attenuation of zero hence the pathloss is 1.0.
Distance between nodes
The simulations are carried out with a scenario where the nodes are placed at equidistant positions from the coordinator. It is assumed to be 10m.
The Physical parameters are summarized in the following table.
| Parameter | Value |
| Radio Propagation Model | Two-Ray Ground |
| Antenna Type | OmniAntenna |
| Transmitter gain in dB (Gt ) | 1.0 |
| Receiver Gain in dB (Gr ) | 1.0 |
| PathLoss | 1.0 |
| Distance b/w nodes | 10m |
Table 2: Physical Parameters
Queue Type
The queue type used in the simulations is DropTail. It is a queue management technique, implementing the ”First In First Out” mechanism. Basically, the packet that enters the queue will be served first. When the Queue reaches its limit, the last packet entering the queue will be dropped.
Queue Length
The standard queue length used in the simulations is 150 packets. Once this limit is reached, all packets are dropped, henceforth. Increasing the queue length would have little impact on the network performance, since it only depends on the efficient utilization of the available network resources. Also the low datarates applicable for this technology wouldnt require a big queue to dissipate packets at a faster rate. When delay is calculated with the time of transmission of the data at the application layer, a longer queue, would only make it perceive as more delayed.
These parameters are summarized in the following table.
| Parameter | Value |
| Queue Type | DropTail |
| Queue Length | 150 |
Table 3: Routing Parameters
This section focuses on the power parameters that are provided by ZMD with reference to their tranceiver, ZMD44101.
Transmit Power(Pt_)
It is the power with which the signal is transmitted. According to the regulator document, ETSI EN 300 220 [B10] for the 868Mhz frequency band in Europe, the maximum transmission power level can be at most 25mW. However, the IEEE 802.15.4 standard based devices are envisioned to operate at a transmit power of 0dBm (1mW). Currently the ZMD44101 transceiver is undergoing testing with transmit powers of 0dBm (1mW), -7dBm (0.199mW), -14dBm (0.0398mW), and -21dBm (7.94e−3mW). For the current simulations a transmit power of the ideal case has been assumed. Hence, Pt_is 0dBm(1mW, 0.001W).
Pt_ = 0dBm = 1 mW
= −7dBm = 0.199 mW
= −14dBm = 0.0398 mW
= −21dBm = 7.94e−3 mW (5.1)
Receive Threshold(RXThresh_)
The receive threshold value is the least power level of a packet for its transmission to be detected successfully. If the received signal power is lower than this threshold, it cannot be detected. The ZMD44101 transceiver is built to be very sensitive. It is expected to decode signals with power as low as -97dBm, while levels of -92dBm being ideal. However, it is also being tested with the threshold values of -87 and -82dBm
Receiver Sensitivity = -97dBm
10 �log10(PRXThresh_ /1mW) = −97
=> PRXThresh_= 1.9952 �10−13W
(5.2)
Carrier Sense Threshold(CSThresh_)
The Carrier sense threshold gives the sensing range of the nodes. If the received signal strength is more than this threshold, the transmission can be sensed. But this does not guarantee a successful decoding and detection of the packet. In order the packet is successfully detected, its power level should be atleast equal to the Receive Threshold Value (RXThresh_).
A definite carrier sensing range is not defined. Hence an approximate sensing range is deduced as in the following calculation.
The receiver is intended to be very sensitive. The lowest signal power that the device is capable of detecting is -97dBm. However, since the nodes should be capable of sensing a longer range, or atleast as much as the RXThresh_, the carrier sensing threshold depends on the RXThresh_. In these situations, it can be at most be equal to RXThresh_, even though values that are less than RXThresh indicating a longer sensing range are common. But it cannot be greater than RXThresh_, in which case the variable RXThresh_becomes redundant. Hence the least carrier sensing threshold is the Receiver threshold value.
PCSThresh_= PRXThresh_
(5.3)
=> PCSThresh_= 1.9952 �10−13W
(5.4)
According to the Two-Ray Ground Propagation model, the received power at a distance of d from the transmitter is given by,
Pr(d) = PtGrGthr2ht2/d4L (5.5)
And substituting the following values to deduce the sensing range of the devices:
Pr = −97dBm = 1.9952 �10−13W
Pt_= 0.001W
Gt = 1.0
Gr = 1.0
L = 1.0
ht = 0.0864m
hr = 0.0864m
(5.6)
1.9952 �10−13 =( 0.001 �1.0 �1.0 �(0.0864)2 �(0.0864)2
) / ( d4 �1.0 )
=> d =( ( 0.001 �1.0 �1.0 �(0.0864)2 �(0.0864)2 ) / (1.9952 �10−13 ) )
=> d = 22.9888m @ 23m (5.7)
Therefore using a carrier sensitivity of -97dBm is equivalent to using a sensing range of around 23m around the node. The following lines of code describe the implementation of the sensing and receiving threshold in NS-2:
File: mac/wireless-phy.cc
Function: WirelessPhy::sendUp
if(propagation_) {
s.stamp((MobileNode*)node(), ant_, 0, lambda_);
Pr = propagation_->Pr(&p->txinfo_, &s, this); // Extract the power of the
received packet
if (Pr < CSThresh_) { // Check if power is less than CSThresh_
pkt_recvd = 0; // If less, drop the packet
goto DONE;
}
if (Pr < RXThresh_) { // If power is over the CSThresh_, check if its less than
RXThresh_
hdr_cmn *hdr = HDR_CMN(p);
hdr->error() = 1; // If yes, take up the error routine
}
Capture Threshold(CPThresh_)
Collisions are common phenomenon. When two packets are received simultaneously, the receiver chooses the strongest packet among them. And this decision is based on the capture threshold limit which defines the power ratio between the desired packet (packet at higher power level) with that of the other to choose it for decoding. Hence if the ratio is greater than or equal to the capture threshold limit, the packet is chosen else both the packets are dropped.
For a successful detection of the desired signal in a collision scenario, it is widely accepted that the difference between their power levels be atleast 10dB.
10log10Pa − 10log10Pb >= 10
=> Pa / Pb >= 10
=> CPThresh_ >= 10 (5.8)
Antenna Height
The tests being conducted at ZMD with their
transceiver, ZMD44102, use /4 monopole antennas.
This would reduce the antenna height as follows:
Speed_of_Light(c) = Frequency_of_Operation(f) �avelength(λ) (5.9)
3 �108 = (868 �106) �λ (5.10)
=> λ = 0.345622m (5.11)
AntennaHeight = λ/4 = 0.345622/4 = 0.0864m (5.12)
The antenna height of 0.0864m is the absolute height of the antenna. However for ns simulations, the antenna height is produced as a set of coordinates, projecting it in a three dimensional space. The Z coordinate would give the antenna height over the ground. Hence for the ns simulations the coordinates of the antenna are assumed as follows.
X
= 0
Y = 0
Z = 0.0864m
Transmit Power
The transmit power is the power consumed by the transceiver to transmit a data packet. The size of the data packet determines the transmit power. More the packet length, more is the power consumed. But, due to transmission of data packets and beacons of different sizes, a definite transmit power level for a definitive packet size cannot be produced. Hence the transmit power given here could be for the transmission of an average sized packet. The transmit power is supplied to be 31mA @ 2.4V.
Therefore the transmit power is calculated to be, 31mA �2.4V = 31 �10−3 �2.4 = 0.0744W.
txPower = 0.0744W
Receive Power
It is the power consumed to receive a data packet. The power consumed can be calculated by a current discharge of 27mA @ 2.4V.
rxPower = 27mA �2.4V = 27 �10−3 �2.4 = 0.0648W.
Idle Power
It is the power consumed to by the node during idle/sleep mode of operation. It is to be reminded that the IEEE 802.15.4 devices are designed to be in snooze mode most of the time and wake up only occasionally. However in the current simulation scenario, where the devices are not allowed to sleep (since there is no inactive portion), the focus is to observe the performance metrics like throughput, delivery ratio, energy performance, etc. The idle mode power can be calculated as 2.3μA @ 2.4V.
idlePower = 2.3μA �2.4V = 2.7 �10−6 �2.4 = 0.00000552W.
The following table highlights all the power parameters.
| Parameter | Value |
| Pt_ | 0dBm (1mW) |
| RxThresh_ | -97dBm, -92dBm, -87dBm, -82dBm |
| CSThresh_ | -97dBm (1.9952 �10−13) |
| CPThresh_ | 10 |
| Antenna Height | 1.0m |
| txPower | 0.0744W |
| rxPower | 0.0648W |
| idlePower | 0.00000552W |
Table 4 Power Parameters
Simulation Time
The simulation time is a measure of the operating time of the network. An inappropriate selection of the simulation time may reflect as inaccurate results. However, given the simulation statistics, and the fact that the usual warm up period of the network (association phase of the network) would generally last a few tens of seconds after the start of the first node, the simulation time has been chosen as 1000seconds. The selection leaves ample settling time for the network, to give accurate results.
Initial Energy
The power efficient working of the IEEE 802.15.4 technology is reminded. The technology is designed to work with very low power consumption. These devices are assumed to be working with a single AA battery for anywhere between 6 months to 2 years. The following discussing is given to calculate the energy of a AA battery in joules which is used as the initial/starting energy of a node for our simulations. It is to be noted that the performance of a battery varies based on the operating conditions.
Product Information
Manufacturer : Eveready
Commercial Name : Energizer
Voltage : 1.5V
Type : AA
Using the graph 4.6 as reference, we see that with a constant current discharge of around 10-18mA, the operating time for the battery is around 170 Hours. With this information, the amount of energy available in joules can be calculated as,
figure 6: Constant Current Discharge[4]
Power (in W) = Voltage (in V) �Current (in A)
=> Power = 1.5v �15mA = 22.5 mW = 0.0225 W
Energy available for an operation of 250Hours of constant current discharge
Energy
(in J) = Power (in W) �time (in secs)
Energy (in J) = 0.0225W �(170 �60 �60)
=> Energy = 13770 Joules
In our case where the device is only occasionally active, the energy requirements might be much lower and hence the battery life will be considerably longer. Estimation into the average life of a battery can only be made using the simulation results which follow in the next chapters. For the simulations using NS-2, an initial energy of 13000 Joules is assumed.
The chapter starts with a brief introduction to the network simulator and the network animator. The models like energy, queue, etc are presented, with a brief explanation on how the model is implemented in ns. The trace files of the NS and the animator trace files are presented. Followed by this is the process structure of the entire simulation. It highlights all the programs and scripts used in this project, and their interlink with each other their inter working to generate the final analyzed results is explained.
Some of the programs that have been used in the project are, wpan.tcl,
scen_gen, wpan.scn, cbrgen star, and avg_throughput.awk. These programs are used
to simulate the network scenario file, wpan.tcl to generate the trace file
’wpan.tr’. This trace file is used as input to the analysis part of the
programs. The programs
and scripts used to analyze the results to generate
the final results are analyze, find_avg868.awk, dfind_avg868.awk. The
final_graphable results are obtained in the text files, final_graphs868.txt,
final_drops868.txt. A brief description of the zigbee software modules is
explained by running down the program flow of the association phase.
The software modifications that are done to the zigbee modules are presented followed by the general simulation parameters used in the simulations. Variables corresponding to traffic parameters, node parameters, Physical parameters, Routing layer parameters, and miscellaneous parameters are presented and their choice is explained in detail wherever applicable.
[1] Kevin Fall, Kannan Varadhan, “The NS Manual” VINT Project, May 17, 2005.
[2] Eitan Altman, Tania Jimenez, “NS Simulator for beginners” Lecture Notes,
Univ. de Los Andes, Sophia-Antipolis, December 4, 2003.
[3] http://ees2cy.engr.ccny.cuny.edu/zheng/pub/, “Zigbee Software Modules”,
City College of
NewYork.
[4] http://www.energizer.com/, “Energizer Engineering DataSheet”, Energizer
Battery Co.
Home Back to Top Zigbee Tutorial System Performance Helpful scripts for ns-2
