SYNOPSIS

This paper describes a medium access control protocol for wireless sensor networks designed for broadcast communication. The RI-MAC (Random Interference Medium Access Control) protocol uses random slot assignment in each MAC frame, along with knowledge of neighbors transmission schedules to mitigate some of the energy wasting problems with existing MAC protocols. RI-MAC conserves energy, transmits messages fairly among the nodes in the system, and is adaptive to changes in the topology. Preliminary evaluation tests indicate that RI-MAC uses less energy than CSMA.

INTRODUCTION
Nowadays, there is a huge increase of handled devices. Laptops, mobile phones and PDAs take an important place in the everyday life. Hence, the challenge is now to make all these devices communicate together in order to build a network. Obviously, this kind of networks has to be wireless. Indeed, the wireless topology allows flexibility and mobility. In this context, the idea of ad hoc networks was developed. 1.1 AD HOC NETWORK An ad hoc network is a wireless network formed by wireless nodes without any help of infrastructure. In such a network, the nodes are mobile and can communicate dynamically in an arbitrary manner. The network is characterized by the absence of central administration devices such as base stations or access points. Furthermore, nodes should be able to enter or to leave the network easily. In these networks, the nodes act as routers. They play an important role in the discovery and maintenance of the routes from the source to the destination or from a node to another one. This is the principal challenge to such a network. If link breakages occur, the network has to stay operational by building new routes. The main technique used is the multi-hopping which increase the overall network capacity and performances. By using multi-hopping, one node can deliver data on behalf of another one to a determined destination. Thus, the problem of range radio is solved. 1.2 MAIN CHARACTERISTICS OF AD HOC NETWORKS Dynamic topology

Hosts are mobile and can be connected dynamically in any arbitrary manner. Links of the network vary and are based on the proximity of one host to another one,

 Autonomous No centralized administration entity is required to manage the operation of the different mobile hosts, Bandwidth constrained Wireless links have a significantly lower capacity than the wired ones; they are affected by several error sources that result in degradation of the received signal, Energy constrained Mobile hosts rely on battery power, which is a scarce resource; the most important system design criterion for optimization may be energy conservation, Limited security Mobility implies higher security risks than static operations because portable devices may be stolen or their traffic may cross insecure wireless links.

1.3 NEED FOR ADHOC NETWORKS Ad Hoc networks are needed as mobile hosts need to communicate with each with no fixed infrastructure and no administrative help because 1. It may not be physically possible for infrastructure 2. It may not be practically economical to establish the infrastructure or the establishment of the

3. It may be because of the expediency of the situation does not permit the installation of the infrastructure. Examples of the use of the MANETs are: Tactical operation for fast establishment of military communication during the deployment of forces in unknown and hostile terrain. Rescue mission for communication in areas without adequate wireless coverage. National security for communication in times of national crisis, where the existing communication infrastructure is non-operational due to a natural disaster or a global war. Law enforcement for fast establishment of communication in exhibitions, conferences, or sales presentations. Commercial use for setting up communication in exhibitions, conferences, or sales presentations. Education for operation of wall-free (virtual classrooms). Sensor networks - for communication between intelligent sensors mounted on mobile platforms.

Figure1.1 A Mobile Ad Hoc Network

Nodes in the MANET exhibit nomadic behavior by freely migrating with in some area, dynamically creating and tearing down associations with other nodes. Nodes can communicate with each other at anytime and without restrictions, except for connectivity limitations and subject to security provisions. MANETs are distinguished from other ad hoc networks by rapidly changing network topologies, influenced by the network size and node mobility. Such networks typically have a large span and contain hundreds to thousands of nodes. The following are the features of MANET Robust routing and mobility management algorithms to increase the networks reliability and availability. Adaptive algorithms and protocols to adjust to frequently changing radio propagation, network, and traffic conditions. Low-overhead algorithms and protocols to preserve the radio communication resource. Multiple (distinct) routes between a source and destination to reduce congestion in the vicinity of certain nodes, and to increase reliability and survivability. Robust network architecture to avoid susceptibility to network failure, congestion around high-level nodes, and the penalty due to inefficient routing.

Medium Access Control (MAC):

The Medium Access Control (MAC) protocol is used to provide the data link layer of the Ethernet LAN system. The MAC protocol encapsulates a SDU (payload data) by adding a 14 byte header (Protocol Control Information (PCI)) before the data and appending a 4byte (32-bit) Cyclic Redundancy Check (CRC) after the data. The entire frame is preceded by a small idle period (the minimum inter-frame gap, 9.6 microsecond (S)) and a 8 byte preamble. Preamble The purpose of the idle time before transmission starts is to allow a small time interval for the receiver electronics in each of the nodes to settle after completion of the previous frame. A node starts transmission by sending an 8 byte (64 bit) preamble sequence. This consists of 62 alternating 1's and 0's followed by the pattern 11. Strictly speaking the last byte which finished with the '11' is known as the "Start of Frame Delimiter". When encoded using Manchester encoding, at 10 Mbps, the 62 alternating bits produce a 5 MHz square wave. The purpose of the preamble is to allow time for the receiver in each node to achieve lock of the receiver Digital Phase Lock Loop which is used to synchronise the receive data clock to the transmit data clock. At the point when the first bit of the preamble is received, each receiver may be in an arbitrary state (i.e. have an arbitrary phase for its local clock). During the course of the preamble it learns the correct phase, but in so doing it may miss (or gain) a number of bits. A special pattern (11), is therefore used to mark the last two bits of the preamble. When this is received, the Ethernet receive interface starts collecting the bits into bytes for processing by the MAC layer. The purpose of the preamble is to allow time for the receiver in each node to achieve lock of the receiver Digital Phase Lock Loop which is used to synchronise the receive data

clock to the transmit data clock. At the point when the first bit of the preamble is received, each receiver may be in an arbitrary state (i.e. have an arbitrary phase for its local clock). During the course of the preamble it learns the correct phase, but in so doing it may miss (or gain) a number of bits. A special pattern (11), is therefore used to mark the last two bits of the preamble. When this is received, the Ethernet receive interface starts collecting the bits into bytes for processing by the MAC layer. Header The header consists of three parts:

A 6-byte destination address, which specifies either a single recipient node (unicast mode), a group of recipient nodes (multicast mode), or the set of all recipient nodes (broadcast mode).

A 6-byte source address, which is set to the sender's globally unique node address. This may be used by the network layer protocol to identify the sender, but usually other mechanisms are used (e.g. arp). Its main function is to allow address learning which may be used to configure the filter tables in a bridge.

A 2-byte type field, which provides a Service Access Point (SAP) to identify the type of protocol being carried (e.g. the values 0x0800 is used to identify the IP network protocol, other values are used to indicate other network layer protocols). In the case of IEEE 802.3 LLC, this may also be used to indicate the length of the data part. Th type field is also be used to indicate when a Tag field is added to a frame.

CRC The final field in an Ethernet MAC frame is called a Cyclic Redundancy Check (sometimes also known as a Frame Check Sequence). A 32-bit CRC provides error detection in the case where line errors (or transmission collisions in Ethernet) result in corruption of the MAC frame. Any frame with an invalid CRC is discarded by the MAC receiver without further processing. The MAC protocol does not provide any indication that a frame has been discarded due to an invalid CRC.

The link layer CRC therefore protects the frame from corruption while being transmitted over the physical mediuym (cable). A new CRC is added if the packet is forwarded by the router on another Ethernet link. While the packet is being processed by the router the packet data is not protected by the CRC. Router processing errors must be detected by network or transport-layer checksums. Inter Frame Gap After transmission of each frame, a transmitter must wait for a period of 9.6 microseconds (at 10 Mbps) to allow the signal to propagate through the receiver electronics at the destination. This period of time is known as the Inter-Frame Gap (IFG). While every transmitter must wait for this time between sending frames, receivers do not necessarily see a "silent" period of 9.6 microseconds. The way in which repeaters operate is such that they may reduce the IFG between the frames which they regenerate. Byte Order It is important to realise that nearly all serial communications systems transmit the least significant bit of each byte first at the physical layer. Ethernet supports broadcast, unicast, and multicast addresses. The appearance of a multicast address on the cable (in this case an IP multicast address, with group set to the bit pattern 0xxx xxxx xxxx xxxx xxxx xxxx) is therefore as shown below (bits transmitted from left to right): 0 | 23 IP Multicast Address Group 47 | <--------------------------->|

1000 0000 0000 0000 0111 1010 xxxx xxx0 xxxx xxxx xxxx xxxx | Multicast Bit | 0 = Internet Multicast 1 = Assigned for other uses

However, when the same frame is stored in the memory of a computer, the bits are ordered such that the least significant bit of each byte is stored in the right most position (bits transmitted right-to-left within octets, octets transmitted left-to-right): 0 | | 23 | 47

0000 0001 0000 0000 0101 1110 0xxx xxxx xxxx xxxx xxxx xxxx | Multicast Bit CSMA /CD The Carrier Sense Multiple Access (CSMA) with Collision Detection (CD) protocol is used to control access to the shared Ethernet medium. A switched network (e.g. Fast Ethernet) may use a full duplex mode giving access to the full link speed when used between directly connected NICs, Switch to NIC cables, or Switch to Switch cables. Receiver Processing Algorithm Runt Frame Any frame which is received and which is less than 64 bytes is illegal, and is called a "runt". In most cases, such frames arise from a collision, and while they indicate an illegal reception, they may be observed on correctly functioning networks. A receiver must discard all runt frames. Giant Frame Any frame which is received and which is greater than the maximum frame size, is called a "giant". In theory, the jabber control circuit in the transceiver should prevent any node <---------------------------> IP Multicast Address Group

from generating such a frame, but certain failures in the physical layer may also give rise to over-sized Ethernet frames. Like runts, giants are discarded by an Ethernet receiver. Jumbo Frame Some modern Gigabit Ethernet NICs support frames that are larger than the traditional 1500 bytes specified by the IEEE. This new mode requires support by both ends of the link to support Jumbo Frames. Path MTU Discovery is required for a router to utilise this feature, since there is no other way for a router to determine that all systems on the endto-end path will support these larger sized frames. A Misaligned Frame Any frame which does not contain an integral number of received octets (bytes) is also illegal. A receiver has no way of knowing which bits are legal, and how to compute the CRC-32 of the frame. Such frames are therefore also discarded by the Ethernet receiver. Other Issues The Ethernet standard dictates a minimum size of frame, which requires at least 46 bytes of data to be present in every MAC frame. If the network layer wishes to send less than 46 bytes of data the MAC protocol adds sufficient number of zero bytes (0x00, is also known as null padding characters) to satisfy this requirement. The maximum size of data which may be carried in a MAC frame using Ethernet is 1500 bytes (this is known as the MTU in IP).A protocol known as the "Address Resolution Protocol" (arp) is used to identify the MAC source address of remote computers when IP is used over an Ethernet LAN. Exception to the Rule An extension to Ethernet, known as IEEE 802.11 allows for frames to carry a tag. The tag value adds an extra level of PCI to the Ethernet frame header. This increases the size of the total MAC frame when the tag is used. A side effect of this is that NICs and network

devices designed to support this extension require a modification to the jabber detection circuit.

PROTOCOLS Table-Driven (or Proactive) The nodes maintain a table of routes to every destination in the network, for this reason they periodically exchange messages. At all times the routes to all destinations are ready to use and as a consequence initial delays before sending data are small. Keeping routes to all destinations upto-date, even if they are not used, is a disadvantage with regard to the usage of bandwidth and of network resources. On-Demand (or Reactive) These protocols were designed to overcome the wasted effort in maintaining unused routes. Routing information is acquired only when there is a need for it. The needed routes are calculated on demand. This saves the overhead of maintaining unused routes at each node, but on the other hand the latency for sending data packets will considerably increase.

Destination Sequence Distance Vector (DSDV) Routing

In this routing protocol routing messages are exchanged between neighbouring mobilenodes (i.e mobilenodes that are within range of one another). Routing updates may be triggered or routine. Updates are triggered in case a routing information from one of t he neighbours forces a change in the routing table. A packet for which the route to its destination is not known is cached while routing queries are sent out. The pkts are cached until route-replies are received from the destination. There is a maximum buffer size for caching the pkts waiting for routing information beyond which pkts are dropped. All packets destined for the mobilenode are routed directly by the address dmux to its port dmux. The port dmux hands the packets to the respective destination agents. A port number of 255 is used to attach routing agent in mobilenodes. The mobilenodes al so use a default-target in their classifier (or address demux). In the event a target is not found for the destination in the classifier (which happens when the destination of the packet is not the mobilenode itself), the pkts are handed to the default-ta rget which is the routing agent. The routing agent assigns the next hop for the packet and sends it down to the link layer.

Existing System:
A MAC protocol mediates use of the radio channel among several nodes; it says who is allowed to transmit when. In addition to energy conservation, MAC protocols usually have several other goals. The protocol should be fair: each node should have equal opportunity to communicate with other nodes. The protocol should allow for high bandwidth utilization: the radio channel's time should not be wasted. The protocol should be adaptive to changes in network topology, either due to irregular signals or node mobility. In addition to the energy challenges described above, protocols must also account for the unstable nature of the radios. Studies have shown that even for immobile nodes, link

quality can be poor, can vary with time, and may have irregular propagation patterns (asymmetric links are common) . We take a novel angle on MAC protocol design in deeming energy conservation, fairness, and adaptiveness to be more important goals than bandwidth utilization. This decision reflects the nature of many sensor network applications -- they are long-lived with low duty cycles, and aim to monitor the environment over an extended period of time. To support long lifetimes, energy conservation is crucial.

Propsed System:
We introduce RI-MAC, the Random Interference Medium Access Control protocol. Unlike many MAC protocols for sensor networks, ours is not general-purpose, but restricted to a single traffic pattern: multihop broadcast. This restriction enables us to create a MAC protocol that saves more energy. Multihop broadcast has many applications in sensor networks, often in distributing query or code updates from a base station to the entire network . We do not dictate any specific network layer above RIMAC, except to assume that it is attempting to move data using multihop broadcast, and that all nodes have equal and relatively high throughput. For example, code update applications may need to send many code packets throughout the network. Even though not every node will relay every packet, nodes will be evenly loaded with transmissions and have high throughput. describes related work in MAC protocol development and indicates the benefits of RI-MAC over existing protocols for the multihop broadcast traffic pattern. describes the details of the RI-MAC protocols, with several examples to illustrate. presents a description of our implementation of the RI-MAC protocol we performed to evaluate RIMAC against a CSMA protocol. And . MAC protocols can roughly be divided into contention based and scheduled protocols. Most contention-based protocols are a variant of CSMA; for example, S-MAC and B-MAC . One problem with CSMA protocols for sensor networks is idle listening. B-MAC supports Low Power

Listening (LPL), which aims to overcome the idle listening problem by requiring potential receives to periodically wakes up briefly to listen for activity on the radio channel. The implementation of LPL is tightly integrated with the hardware, and is not currently available for most platforms. Under the high throughput broadcast scenario that we are considering, nodes will usually be either receiving or sending. Under this scenario, CSMA is susceptible to the hidden terminal problem -- and thus many messages will collide. Increasing CSMA backoffs can alleviate this; however, the idle listening factor then comes back into play. Other contention-based protocols, such as S-MAC and TMAC use a request-to-send / clearto- send handshaking protocol to reduce collisions. However, this scheme is appropriate for point-to-point communications rather than broadcast. Scheduled protocols tend to reduce collisions, but waste energy in other ways. TDMA protocols often require 2-hop neighbor information to establish schedules. For example, TRAMA uses random access signaling slots to exchange neighbor and schedule information. The messages involved in this create energy waste through overhead. Furthermore, TDMA protocols usually require time synchronization, another source of overhead. This overhead is exacerbated by the irregular and unreliable radio links that are typical of many sensor networks. The Z-MAC protocol is a TDMA/CSMA hybrid. Under high contention, as our broadcast scenario tends to be, Z-MAC acts similarly to TDMA, and thus has many of the problems discussed above. Finally, TSMA protocols are also scheduled, and while they don't ensure collision-freedom, they guarantee certain quality of service. This approach is similar to our RI-MAC work, except that it still requires time synchronization, and doesn't specify sleeping schedules THE RI-MAC PROTOCOL We introduce RI-MAC, which eliminates many sources of wasted energy for broadcast problems, while allowing fair channel access for all nodes. Like TDMA, RI-MAC divides time into frames, and frames into slots. We willfirst explain RI-MAC assuming that all nodes are timesynchronized, and then later relax this assumption.

A. Transmission Schedule In RI-MAC, each node chooses a random slot in each frame for transmission. Figure 1 shows an example of five nodes (A through E), where each frame has six slots, and the nodes have picked their transmission slots in each frame (marked with T). We assume that each node knows its onehop neighbors, and the transmission schedules for those neighbors. For this example, we will use the topology in Figure 2. Given the knowledge of its neighbors' transmission schedules, each node fills out its remaining slots as either listening slots (L) or sleeping slots (S) according to the following rules. If exactly one neighbor transmits in a slot, then listen. If no neighbors transmit in a slot, then sleep. If two or more neighbors transmit in a slot, also sleep, as there will only be radio interference. The resulting schedule can be seen in Figure 3. Notice that in the first frame, node B sleeps during slot 3 because its neighbors A and D both transmit. Also note that a node transmits even if a neighbor is scheduled to transmit in the same slot; for example, both B and C transmit during slot 2 of the second frame.

B. Protocol Specifics Let us address several specific aspects of the protocol and its implementation. Neighbor Transmission Schedule. We assumed that a node knows each neighbors transmission schedule. In each packet, we include two data from the sender: its address, and a sequence number indicating where it is in its pseudorandom number sequence. Since a node seeds its own pseudo-random number generator with its own address, these two data can be used by its neighbors to predict the node's transmission schedule. Therefore, once

a node hears one packet from a neighbor, it knows that neighbors entire transmission schedule. To allow nodes to learn its neighbors, RI-MAC has a setup phase of nscheduled listening before entering the main schedule. Clock Synchronization. Initially we assumed that all clocks were synchronized, and thus frames and slots were aligned. In fact, the RI-MAC protocol and its implementation do not require aligned slots. This changes the rules only slightly: a node only listens if a neighbor's transmission is not overlapped by some other neighbor's transmission. In each transmission from a neighbor, a timestamp is included, so a node will know the offset of its own slots with its neighbors slots. Thus, it will be able to predict the overlap of its neighbors transmissions. We do not expect clock drift to be a major problem because of the course-grained nature of our scheduling (we need accuracy on the millisecond level). Studies show that clock drift on mica2 motes, for example, is on the order of 1millisecond over the course of seven hours. However, we do account for clock drift as follows: every time a node receives a message from a neighbor, it updates its internal record of that neighbors schedule in accordance with the timestamp of that receipt. Therefore, the accuracy of a neighbors schedule is with respect to the most recently received message from that neighbor. Energy Conservation. Lets consider the protocol in terms of wasted energy. When a node is sleeping, obviously no energy is wasted. When a node is listening in RI-MAC, no energy is wasted because it will receive a message. The only sources of waste are transmission when a neighbor is not listening, and overhead. Sometimes a sending nodes neighbor will not listen if it knows that another of its own neighbors will be sending at the same time. Overhead in RI-MAC occurs through the setup phase when nodes are discovering their neighbors. m

C. Analytical Comparison We can compare RI-MAC with typical TDMAprotocols given our three goals: energy efficiency, fairness, and adaptability. RI-MAC is more energyefficient, because the overhead involved in RI-MAC neighbor discovery is significantly less than the 2-hop neighborhood information required by other TDMA protocols. Further, RI-MAC does not require synchronized clocks, which can be very energy intensive. TDMA protocols can result in unfair schedules due to irregular radio links. As asymmetric links can lead to schedules that are not collision-free. Since TDMA schedules are typically static, a node with a bad schedule may never get channel access. In RI-MAC, the random schedules, chosen in each frame, ensure that all nodes have equal opportunity, regardless of the radio irregularity. Finally, RI-MAC is more adaptive to changing conditions than TDMA because it requires only 1-hop information for its scheduling algorithm, and thus a node can more easily learn about new neighbors and adjust its schedule accordingly.

5.1 HARDWARE SPECIFICATION To develop this system with IBM compatible personal computer with Pentium IV processor was used. Main processor Hard disk capacity Cache memory Monitor Keyboard Mouse : : : : : : Pentium IV processor 1.13 GHz 40GB 512 MB LG Digital Color Monitor Samsung Logitech

5.2 SOFTWARE SPECIFICATION Operating system Scripting language Protocol developed Scripting : : : : RedHat Linux Network Simulator 2.29 C++ Tool Command Language

5.3 SOFTWARE DESCRIPTION 5.3.1 THE NETWORK SIMULATOR 2.29 (NS2) Network Simulator (NS2) is a discrete event driven simulator developed at UC Berkeley. It is part of the VINT project. The goal of NS2 is to support networking research and education. It is suitable for designing new protocols, comparing different protocols and traffic evaluations. NS2 is developed as a collaborative environment. It is distributed freely and open source. A large amount of institutes and people in development and research use, maintain and develop NS2. This increases the confidence in it. Versions are available for FreeBSD, Linux, Solaris, Windows and Mac OS X. 5.3.2 STRUCTURE OF NS2 NS2 is built using object oriented methods in C++ and OTcl (object oriented variant of Tcl.

Fig 5.1 Simplified Users View of Ns can see in Fig 5.1, NS2 interprets the simulation scripts written in OTcl. A user has to set the different components (e.g. event scheduler objects, network components libraries and setup module libraries) up in the simulation environment. The user writes his simulation as a OTcl script, plumbs the network components together to the complete simulation. If he needs new network components, he is free to implement them and to set them up in his simulation as well. The event scheduler as the other major component besides network components triggers the events of the simulation (e.g. sends packets, starts and stops tracing). Some parts of NS2 are written in C++ for efficiency reasons. The data path (written in C++) is separated from the control path (written in OTcl). Data path object are compiled and then made available to the OTcl interpreter through an OTcl linkage (tclcl) which maps methods and member variables of the C++ object to methods and variables of the linked OTcl object. The C++ objects are controlled by OTcl objects. It is possible to add methods and member variables to a C++ linked OTcl object.

5.3.3 FUNCTIONALITIES OF NS2.29 Functionalities for wired, wireless networks, tracing, and visualization are available in NS2. Support for the wired world include Routing DV, LS, and PIM-SM. Transport protocols: TCP and UDP for unicast and SRM for multicast. Traffic sources: web, ftp, telnet, cbr (constant bit rate), stochastic, real audio. Different types of Queues: drop-tail, RED, FQ, SFQ, DRR. Quality of Service: Integrated Services and Differentiated Services. Emulation. Support for the wireless world include Ad hoc routing with different protocols, e.g. AODV, DSR, DSDV, TORA Wired-cum-wireless networks Mobile IP Directed diffusion Satellite Senso-MAC Multiple propagation models (Free space, two-ray ground, shadowing) Energy models Tracing Visualization Network Animator (NAM) Trace Graph Utilities Mobile Movement Generator

Fig 5.2 OTcl and C++: the duality

5.3.3.1 MOBILE NETWORKING IN NS2.29 This section describes the wireless model that was originally ported as CMUs Monarch groups mobility extension to NS2. The first section covers the original mobility model ported from CMU/Monarch group. In this section, we cover the internals of a mobile node, routing mechanisms and network components that are used to construct the network stack for a mobile node. The components that are covered briefly are Channel, Network interface, Radio propagation model, MAC protocols, Interface Queue, Link layer and Address resolution protocol model (ARP). CMU trace support and Generation of node movement and traffic scenario files are also covered in this section. The original CMU model allows simulation of pure wireless LANs or multihop ad-hoc networks. Further extensions were made to this

model to allow combined simulation of wired and wireless networks. MobileIP was also extended to the wireless model. 5.3.3.2 THE BASIC WIRELESS MODEL IN NS The wireless model essentially consists of the MobileNode at the core, with additional supporting features that allows simulations of multi-hop adhoc networks, wireless LANs etc. The MobileNode object is a split object. The C++ class MobileNode is derived from parent class Node. A MobileNode thus is the basic Node object with added functionalities of a wireless and mobile node like ability to move within a given topology, ability to receive and transmit signals to and from a wireless channel etc. A major difference between them, though, is that a MobileNode is not connected by means of Links to other nodes or mobilenodes. In this section we shall describe the internals of MobileNode, its routing mechanisms, the routing protocols dsdv, aodv, tora and dsr, creation of network stack allowing channel access in MobileNode, brief description of each stack component, trace support and movement/traffic scenario generation for wireless simulations. 5.3.3.3 MOBILE NODE: CREATING WIRELESS TOPOLOGY MobileNode is the basic nsNode object with added functionalities like movement, ability to transmit and receive on a channel that allows it to be used to create mobile, wireless simulation environments. The class MobileNode is derived from the base class Node. MobileNode is a split object. The mobility features including node movement, periodic position updates, maintaining topology boundary etc are implemented in C++ while

plumbing of network components within MobileNode itself (like classifiers, dmux , LL, Mac, Channel etc) have been implemented in Otcl. Table 5.1: Available Options For Node Configuration Option Address type MPLS Wired Routing II Type Mac Type ifq Type Phy Type Option satNodeType downlinkBW Adhoc Routing Available Values General Flat, Hierarchical ON,OFF Both Satellite and Wireless Oriented ON,OFF LL,LL/sat Mac/802_11,Mac/Csma/Ca, Mac/Sat/Unslotted/Aloha,Mac/Tdma Queue/DropTail, Queue/Droptail/PriQueue Phy/wirelessPhy,Physat Available Values Satellite Oriented Polar,Geo,Terminal,Geo-repeater <bandwidth value, e.g 2MB> Wireless Oriented DIFFUSION/RATE,DIFFUSION/PROB, DSDV,FLOODING,OMNICAST,AODV,TOR propType propInstance antType Channel topoInstance A Propagation/2RayGround,Propagation Shadowing Propagation/2RayGround,Propagation Shadowing Antenna/Omni Antenna Channel/Wireless Channel,Channel/sat <toplogy file> OFF OFF OFF OFF OFF Default Flat OFF OFF OFF OFF OFF OFF Default OFF OFF OFF

MobileIP Energy model Initial Energy rxPower txPower Idle Power AgentTrace routerTrace macTrace movementTrac e Errproc FECProc toraDebug

ON,OFF Energy model <value in joules> <value in W> <value in W> <value in W> ON,OFF ON,OFF ON,OFF ON,OFF UniformErrorProc ? ON,OFF

OFF OFF OFF OFF OFF OFF OFF OFF OFF OFF OFF ? OFF

5.3.3.4 CREATING NODE MOVEMENTS The mobilenode is designed to move in a three dimensional topology. However the third dimension (Z) is not used. That is the mobilenode is assumed to move always on a flat terrain with Z always equal to 0. Thus the mobilenode has X, Y, Z(=0) co-ordinates that is continually adjusted as the node moves. There are two mechanisms to induce movement in mobilenodes. In the first method, starting position of the node and its future destinations may be set explicitly. These directives are normally included in a separate movement scenario file. The start-position and future destinations for a mobilenode may be set by using the following APIs: $node set X_ <x1> $node set Y_ <y1> $node set Z_ <z1> $ns at $time $node setdest <x2> <y2> <speed>

At $time sec, the node would start moving from its initial position of (x1,y1) towards a destination (x2,y2) at the defined speed. In this method the node-movement-updates are triggered whenever the position of the node at a given time is required to be known. This may be triggered by a query from a neighboring node seeking to know the distance between them, or the setdest directive described above that changes the direction and speed of the node.

5.4 NETWORK COMPONENTS IN A MOBILENODE LINK LAYER The link layer for mobilenode has an ARP module connected to it which resolves all IP to hardware (Mac) address conversions. Normally for all outgoing (into the channel) packets, the packets are handed down to the LL by the Routing Agent. The LL hands down packets to the interface queue. For all incoming packets (out of the channel), the mac layer hands up packets to the LL which is then handed off at the node_entry_ point. ARP The Address Resolution Protocol (implemented in BSD style) module receives queries from Link layer. If ARP has the hardware address for destination, it writes it into the mac header of the packet. Otherwise it broadcasts an ARP query, and caches the packet temporarily. For each unknown destination hardware address, there is a buffer for a single packet. Incase additional packets to the same destination is sent to ARP, the earlier

buffered packet is dropped. the hardware address of a packets next hop is known, the packet is inserted into the interface queue. INTERFACE QUEUE The class PriQueue is implemented as a priority queue which gives priority to routing protocol packets, inserting them at the head of the queue. It supports running a filter over all packets in the queue and removes those with a specified destination address TAP AGENTS Agents that subclass themselves as class Tap defined in mac.h can register themselves with the mac object using method installTap(). If the particular Mac protocol permits it, the tap will promiscuously be given all packets received by the mac layer, before address filtering is done. NETWORK INTERFACES The Network Interface layer serves as a hardware interface which is used by mobilenode to access the channel. The wireless shared media interface is implemented as class Phy/WirelessPhy. This interface subject to collisions and the radio propagation model receives packets transmitted by other node interfaces to the channel. The interface stamps each transmitted packet with the meta-data related to the transmitting interface like the transmission power, wavelength etc. This meta-data in packet header is used by the propagation model in receiving network interface to determine if the packet has minimum power to be received and/or captured and/or detected (carrier sense) by the receiving node. 5.5 TRACE FILES

There exist two different trace file formats (old and new). A new trace file format was introduced apart from the wireless trace format with joining the tracing in wired and wireless parts in mind. 5.5.1 OLD WIRELESS TRACE FILE FORMAT A trace in this format always begins with one of the characters in table 1. This character is succeeded by a white space separated list of values specific for the used protocol and the type of the message. For all wireless traces the values specified in the table contain the values for the protocols used in the simulations. 5.5.2 NEW WIRELESS TRACE FILE FORMAT The structure of the new wireless trace file format is changed to be integrated in the new trace file format of the entire simulator. The lines of the trace files begin with the same action flags as in the old format. But this is followed by flag/value pairs. The flags begin with a dash and a letter that specifies the flag type (see table 5.2). Table 5.2: Flag Types New Wireless Trace Format

Table 5.3: Wireless Event Using The New Trace Format

5.5.3 MANET SCENARIO A pure Manet scenario similar to the simulations was set up in order to gain some experience and to verify the structure of the experiment. The simulation settings were as follows:

wireless nodes. Simulation area of 1500m300m. A rectangle area is chosen to have longer distances between the nodes than in a quadratic area, i.e. packets are sent over more hops. IEEE 802.11 MAC. Two ray ground propagation model. Node mobility defined by random waypoint movement model. Constant bit rate traffic. UDP.

5.5.4 REVISED FORMAT FOR WIRELESS TRACES In an effort to merge wireless trace, using cmu-trace objects, with ns tracing, a new, improved trace format has been introduced. This revised trace support is backwards compatible with the old trace formatting and can be enabled by the following command: $ns use-newtrace This command should be called before the universal trace command $ns trace-all <trace-fd>. Sets up new format for wireless tracing by setting a simulator variable called newTraceFormat. Currently this new trace support is available for wireless simulations only and shall be extended to rest of ns in the near future. An example of the new trace format is shown below: s -t 0.267662078 -Hs 0 -Hd -1 -Ni 0 -Nx 5.00 -Ny 2.00 -Nz 0.00 -Ne -1.000000 -Nl RTR -Nw --- -Ma 0 -Md 0 -Ms 0 -Mt 0 -Is 0.255 -Id -1.255 It message -Il 32 -If 0 -Ii 0 -Iv 32 s -t 1.511681090 -Hs 1 -Hd -1 -Ni 1 -Nx 390.00 -Ny 385.00 -Nz 0.00 -Ne -1.000000 -Nl RTR -Nw --- -Ma 0 -Md 0 -Ms 0 -Mt 0 -Is 1.255 -Id -1.255 It message -Il 32 -If 0 -Ii 1 -Iv 32 s -t 10.000000000 -Hs 0 -Hd -2 -Ni 0 -Nx 5.00 -Ny 2.00 -Nz 0.00 -Ne -1.000000 -Nl AGT -Nw --- -Ma 0 -Md 0 -Ms 0 -Mt 0 -Is 0.0 -Id 1.0 -It tcp -Il 1000 -If 2 -Ii 2 -Iv 32 -Pn tcp -Ps 0 -Pa 0 -Pf 0 -Po 0 r -t 10.000000000 -Hs 0 -Hd -2 -Ni 0 -Nx 5.00 -Ny 2.00 -Nz 0.00 -Ne

Conclusion:
RI-MAC is a MAC protocol designed for broadcast communication in wireless sensor networks. We have shown that it wastes less energy than CSMA when frame size is chosen properly. We have further discussed, analytically, the benefits of RI-MAC over TDMA. Future work on RI-MAC will address how to compute the frame size at run time. This will allow nodes to adjust their frame sizes based on the number of neighbors they discover, thus positively impacting the energy, time, and reliability tradeoffs. The current implementation of the protocol does not adapt to nodes entering or leaving the network.

For nodes exiting, such as when a node fails or is destroyed, the protocol should decide when to stop listening for the particular neighbor. The protocol does not detect when a new node has entered, such as during a second deployment wave. A possible solution is to have regular period where nodes listen and reset their local neighbors connections. Adjusting to nodes entering and leaving the system will be much simpler than in TDMA schedules that require 2-hop neighbor information. Other future work will involve further testing using metrics that can illustrate the fairness, and adaptability of the RIMAC protocol.