Real Time Computer Systems
Real Time Computer Systems CSC 714
Popular in Course
Popular in ComputerScienence
This 12 page Class Notes was uploaded by Jaden Jakubowski on Thursday October 15, 2015. The Class Notes belongs to CSC 714 at North Carolina State University taught by Rainer Mueller in Fall. Since its upload, it has received 20 views. For similar materials see /class/223815/csc-714-north-carolina-state-university in ComputerScienence at North Carolina State University.
Reviews for Real Time Computer Systems
Report this Material
What is Karma?
Karma is the currency of StudySoup.
You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!
Date Created: 10/15/15
CSC 714 Real Time Computer Systems RoverNet Mobile Routers and Jammers in Wireless Sensor Networks Progress Report Kunal Kandekar Nandini Kappiah Indraneel Kelkar kakandek nkappia ibkelkar 1 Introduction Denial of Service Dos also known as jamming is a major source of concern in any wireless network Introduction of mobility in wireless nodes further complicates the scenario This proposal aims to study the dynamics of such a system and develop techniques to take advantage S Sender k kecrziver 123 Mobile nodes J Jammer39 Figlre 1 Overview of the RoverNet One possible defense against Dos attacks is introducing mobile nodes to route around his attacks We study and r 391 39 39 a Dos attack The natural counteroffense against such a scheme is the use ofmobile Jammers Hence we study the dynamics of interaction between mobile Routers and Jammers and attempt to develop effective techniques for communication and disruption using mobile wireless nodes 2 Issues issuesin L r 39 ofthe nodes in the wireless network 21 Routing in Mobile Wireless Networks Establishing a route over mobile routers Conventional mobile adhoc network MANET protocols address the mobility aspect of their nodes by maintaining their routing tables in a softstate Since the nodes in rovernet can cover rather large distances relative to their IR range a softstate approach would be inefficient Alternatively a large overhead in terms of data and computation keeping track of the positions of all the mobile nodes would be needed in establishing a route Maintaining the route If a route is eventually established and the nodes keep moving they would leave the range of their previous or nexthop neighbors and disrupt the route There will be a large overhead of control messages required to keep rebuilding a route if it is broken Collisionavoidance All nodes are communicating over a shared medium InfraRed hence chances of a collision are high if there is no established scheme to regulate transmission of messages 22 Detection of Jamming Conventionally jamming can be detected at several levels 0 Physical by analyzing the signal Repeated inability to access wireless channel Repeated collisions Low signaltonoise ratio Excessive received signal level Data Link Bad framing Network and higher Checksum failures Illegal values for addresses or other elds Protocol violations eg missing ACKs We cannot detect jamming at the Physical and Data Link layer due to lack of direct access to the IR communication hardware and information about the actual signal The only indication we do have of a problem at the lower layers is the detection of a collision as provided by the LNP API Hence there is no clear method to distinguish between genuine mediumaccess collisions and jamming 23 Re organizing the rover network on jamming to resume communication On detection of jamming the mobile nodes are to reorganize themselves so as to enable routing around the jammed area Since there is neither absolute nor relative location feedback it is difficult to reorganize the mobile nodes with minimum coordination and movement To address all these issues we developed the RoverNet Protocol RNP which is discussed in detail below 3 RoverNet Protocol RNP Speci cation The broad goals of this transportlevel protocol are Establishing a route over mobile nodes 0 Maintaining the established route Collision avoidance scheme as we do not have control over the datalink layer Ability to function with a minimum number of mobile routers Detection of jamming Avoidance and reorganization when faced with jamming 31 Routing in Mobile Wireless Networks We use a scheme similar to the Dynamic Source Routing 1 However we include modi cations to address the issue of limited communication range compounded with the high mobility of the nodes 311 Establishing a route over mobile routers Rovers move around broadcasting their presence They maintain a table of nodes within their range Entries in this table are removed if there is no heartbeat for some period of time from the corresponding node The source initiates a route establishment request for the speci ed destination Rovers that receive it append their Id to the message and forward it to any other nodes within their range On forwarding the message the rover stops moving for a certain period of time or until it receives a routeestablished message Whenever a node receives this message and has the destination node in its table it broadcasts a routeestablished message which is received by both the destination node as well as the previoushop node The route established response will also have the list of Node Ids so that this message can be forwarded backwards to all nodes along the route All nodes receiving this message will stop moving and transition into routing mode 312 Maintaining the route There is high probability that the established route will be disrupted if the nodes change location To minimize this threat the protocol requires the nodes to stop moving unless it detects jamming 313 Collisionavoidance scheme 7 As we do not have access to the IR communication hardware or the datalink layer that is used by the rovers we need to implement a collisionavoidance scheme at the transport layer The LNP API noti es the application whether its transmission failed due to a collision In case of a collision we use a backoff timer scheme to schedule the retransmission with a minimum probability of collision The backoff time is a function of the node Id which is unique in the rovernet This should increase the probability of a collisionfree retransmission regardless of the participants in the collision 32 Detection of Jamming Due to lack direct access to IR Communication hardware and information of the actual signal it is dif cult for the rover to identify whether it is being jammed From the LegOS LNP API by itself it can only know whether a transmission resulted in success 0 a collision network error miscellaneous Moreover a rover is unable to detect reception of unsuccessful transmissions This in itself is insuf cient data for the rover to determine with certainty if it is being jammed at the datalink level Hence we use a number of probabilistic and heuristic approaches to detect jamming As mentioned earlier a RoverNet node can be in 3 modes Stationary Source Sink Mobile Router and Standby Jamming is detected in the same way by any type of node It assumes that it is beingjammed if It receives several bad packets Jam messages It detects too many successive collisions while sending Any node will also assume that its nexthop neighbor is being jammed if c It does not receive acknowledgements for its transmitted packets It does not receive a heartbeat for a speci ed amount of time It receives a heartbeat with the state eld set to JAMMED However each mode has different techniques of responding to jamming l Stationary Source Sink o On detecting local jamming If it is a standalone tower it stops all transmission until the Jammer node moves away or stops jamming In case there is an alternate SourceSink that it can route to over an outofband connection eg over the LAN to another PC with an IR tower it transfers control to that node On detecting nexthop jamming It initiates a new Route Establishment request so that data can be routed around the jammed area 2 Mobile Router 0 On detecting local jamming It attempts to send heartbeat message with state set to JAMMED to notify nodes within its range If the jamming is too persistent to successfully transmit this message it assumes that the nexthop nodes will detect this through the other abovementioned approaches It then moves away in an attempt to discover a jammingfree area that still allows a route to be established On detecting nexthop jamming It forwards the status of the nexthop neighbor to all nodes within its range 3 Standby Router On detecting local jamming Since it is not on the established route it has 2 choices it can move away to an unjammed area or it can choose to stick around and deceive the jammer decoy On detecting nexthop jamming It attempts to build a new route around the jammed node 31 State Transition Diagrams The protocol basically differentiates between two types of nodes Stationary IR Tower 0 Mobile RCX Rover Each type of node has a different statetransition diagram Othzx mm estahhshzd Jammzd peer mu cmmn pm 1m ammzd P Faxwmhng wnhmn mm a Figure 2 sum Transitinn Dizgxam 11me Ram RauterRequesL Of aadta peer Figure 3 sum Transitinn Dizgxam nf the Tuwer 3 N RNP Protocol Headers Message Types Descn n Fields RNPiROUTE Request Response for Source establishing of route Destination List of NodeIds Type RNPiROUTEiSETUP Setup Request RNPiROUTEiREQiAPPOINT Request appointment RNP ROUTE CNCL APPOINT Cancel Fr 39 RNP ROUTE APPOINT Grant appointment RNPiROUTEiREQiACK Acknowledge route establishment RNPiROUTEiTEARDOWN Request teardown RNPiUCAST Unicast data message Source intended for a speci ed Destination destination within the Sequence broadcast range Len h RNPiMCAST Multicast data message Source Length intended for all nodes within the broadcast range RNPiACK Acknowledgement for Source Unicast message Destination Sequence RNPiNACK A Negative Source Acknowledgement on Destination detecting a gap in sequence Sequence numbers RNPiHBEAT Heartbeat message to notify Source Node all nodes within range of type Status status of the sending node Sequence Statistics RNPiPING An Are you alive query Source Destination Hops RNPiPONG An I am alive response Source Destination Hops RNPiQUENCH Control message to indicate Source that the buffer is full on Destination sending node Previous hop node should desist sending more packets until RNP RESUME RNPiRESUME Control message to indicate Source that node is ready to Destination forward again 4 Jammer It randomly moves around listening for messages If it receives a message it knows that it is in the vicinity of a victim Based on the frequency of received messages it adjusts the rate of its own jamming transmissions saving power It follows a very simple algorithm It starts in seek mode by randomly moving around listening for messages 2 When a message is received the jammer knows it is in the vicinity of an active node It stops moving and starts jamming Periodically it stops jamming and listens for a while to ascertain the node s presence If there is no message from the victim node it goes back into seek mode 5 5 Implementation We implemented a sample mobile embedded wireless node network as described above The mobile nodes are emulated by Lego RCXs units and the LNP IR acts as the broadcast medium This project aims to study the dynamics of such a system and develop techniques to take advantage of mobility in establishment and disruption of wireless communication 51 Design The implementation of this project was divided into the following modules 511 RNP Library We wrote a library for RCX communication using LNP The Rnet APIs which we implemented have been modeled after the socket library providing an interface similar to that of sockets to an end user RNP Programming Interface The RNP API is declared in the meth file int rnpinit void Sets up the 39 for RCX 39 im It starts up the RNP daemon which handles are further communication Its also call lnpiinit which sets up int rnptimedisten long timeout Listens for messages on the broadcast medium for a specified time depending on the argument specified A listened timeout has been implemented due to the unreliable communication of the RCXs If no messages are received in the timeout specified the mpitimedilisten returns 1 If a message is received it return 0 int rnpconnect usigned char dest mpiconnect initiates the dynamic source routing from the source to the specified destinations It returns the connection identifier if the connection is succesfully set up or it returns 1 if the dynamic source routing fails int rnpdisconnectint conn Tears down the connection established Returns 0 if teardown occurs successfully Returns 1 if teardown unsuccessful for unspecified reasons int rnpsendint conn char data int len Transmits the contents of data of length len on the specified connection a unicast send in which the data in sent to the specified destination int rnprecvint conn char data int len mpirecv is a blocking call which waits for on the specified connection Populates the values of data and len for use by the calling function int mptimedrecvint conn char data int len long timeout mpitimedirecv is a blocking call which waits for the specified timeout period on the specified connection Populates the values of data and len for use by the calling function int mpmcastsendchar data int len mpimcast isends provides a multicast send in which the message is broadcast to all listening nodes int I39npmcastrecvchar data int len long timeout mpimcastirecv provides a nonconnection oriented multicast receive int mpstatusvoid mpistatus returns the status of the node The valid states of the node are RNPiFREE 7 indicates that the node is free and moving RNPiCONNECTING 7 indicates that the node is the process of a route establishment and the rover has stopped moving RNPiCONNECTED 7 indicates that the node has successfully established connection and the rover is stationary RNPilNCOMING 7 indicates that the rover is expecting messages the node is stationary is this case as well RNPiJAMMED 7 indicates that the rover is jammed and is capable of moving around RNPisTANDBY 7 indicates that the node is the standby node and is moving around 512 RNP Daemon We designed and implemented an RNP daemon which is responsible for communication between the RCX s and the tower and between the RCX s themselves The RNP daemon runs in the background and handles all communication requests from the tower or the RCX The tower and the RCX send all messages to the RNP daemon which is responsible for transmitting them over the wireless broadcast medium The RNP daemon emulates the CSMACD Carrier Sense Multiple Access Collision Detection and handles collisions in the medium with a back off proportional to its own ID and repeated transmissions This daemon allows for asynchronous communication as the tower hands off the communication requests to the daemon and daemon running on a separate thread is responsible for the communication The actual communication is abstracted for the tower and the rover When a rover gets a packet which is not addressed to it the daemon handles the packet and the rover is unaware of the underlying communication This allows the rover to continue undisrupted until it receives a packet that is intended for it 513 RoverNet Simulator The lack of debugging facilities on the RCX prompted us to create a simulator which simulates the networking aspect of the RCX We created a Java based simulator on multicast environment which simulates the communication between RCX s IPmulticast emulates the IR broadcast medium on which the RCX works We also created a Java multicast network monitor which tracks the messages exchanged between the mobile nodes and provides a useful tool for debugging the complex code involved in this project The monitor also provides a graphical interface which depicts the location of the rovers and their respective broadcast ranges The display provides an intuitive understanding of the network of mobile nodes and the communication that is taking place Our current implementation as of now includes the following features Rnetd Daemon implementation for asynchronous messaging Simulation of mobile wireless node network RCXportable code Emulation of IRbroadcast using IP multicast Graphical Representation of simulation Dynamic Source Routing Multihop forwarding Future work includes Implementing Reliability service using ACKs NACKs Implementing Flow Control using QUENCH RESUME Jamming strategies Antij amming detection and response strategies Open Problems and Potential Solutions Use of Appointments A slight deviation we had to make to pure dynamic source routing is the use of appointments When a number of nodes receive the route establishment request they return an acknowledgment of the route establishment request to the source node upon which the source appoints one of the nodes as the next hop The other nodes are informed of this appointment and they are free to rove further in search of the destination This improvisation has been made to prevent redundant or partial routes from being established Reliable communication We have not implemented any form of reliable communication The packets can be encrypted for protection The current identification of a jammer packet is done by examining the header If it does not follow the protocol format it is considered a jammer packet More extensive methodologies than the one implemented can be used to identify and avoid jamming Congestion control We have not implemented any form of congestion control in our implementation although our protocol provides for it RNPiQUENCH message which indicate that the buffer on the sending node is full and the previous node should desist from sending more packets Alternate routes can be established around the congested node to continue transmissions Strategies for jamming and anti jamming We have only considered few of the methods of the many strategies of jamming and anti jamming The jammers and the nodes can be respectively provided with different jamming and antijamming which results in different behavior of the mobile nodes than the one we simulated 514 Individual contributions Kunal The RNP daemon metd Java RoverNet simulation monitor JRoverNet Nandini The Rover code Tower code and the Jammer code Indraneel Miscellaneous data structures implementation Circular buffers Linked list 616 simulzu39pn stults nnnetting c Cunneeu39nn established Fig 4 simulatlnn 6 Open Issues lnstanee usmg eontmuous loeauon feedback nodes may be able to lnfer the ranges oflts y For peer nodes and plan lts movements more mtelllgen 7 Future Work the slmulator rt eurrentlv laeks for both Routers and Jammers Scenarlu Smgle Sender and smgle Reeelver ate ammer mes to loeate the souree and effectlvelyjam all eommumeatlons Scenarlu Muluple Senders and Reeelver ers and Reeelvers ean eommumeate amongst themselves over an outrofr 2 eva e e ammers wlthout bemg a le to eommumeate to eoor nate Rrologleallvunsplred algonthms sueh as swarm behavlour ean be applled to develop these strategles Scenarlu Swltehmg between short and long range transmlsslons for Routers Strategy The moblle Routers explolt dlfferent eommumeatlon ranges to Lhelr advantage 1t dJrechonal eonslderatlons However lt ls also dlf cult for the Jammers to deteet these llnks and jam them effectively using longrange transmissions without losing an undue amount of power Scenario Robotic Virus Strategy Jammer acts a selfreplicating virus It locates a Router and tries to reprogram infect it to behave as a Jammer This exploits a feature Conclusion This work has several ramifications in realworld scenarios involving mobile sensor networks in military applications We have provided a framework for practical implementation as well as simulation to determine strategies that would be most effective with respect to both communication as well as jamming References JAJA 1 Dynamic Source Routing Protocol httpwww ietf or inte ietfmanetdsr 09tXt 2 AD Wood and JA Stankovic Denial of Service in Sensor Networks IEEE Computer Society Press 2002 3 A D Wood J A Stankovic quotJAM A JammedArea Mapping Service for Sensor Networksquot Sang Hyuk Son RTSS 03 4 Eric Bonabeau Guy Theraulaz Swarm Smarts 7 Scientific American 1998 5 J Butler Mobile robots as gateways into wireless sensor networks httpwwwlinuXdevicescomarticlesAT2705574735html 6 Andrew Howard Maja J Mataric Cover Me A SelfDeployment Algorithm for Mobile Sensor Networks Project Web Page URL httpwww4ncsueduNnkappiartcsprojecthtml
Are you sure you want to buy this material for
You're already Subscribed!
Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'