AdHoc Networks Establishing nodetonode communication with no infrastructure

Ad-Hoc Networks Establishing node-to-node communication with no infrastructure needed Authors: Nikola Milanović, nikola 99@EUnet. yu Gvozden Marinković, ć, gvozden. . marinkovic@saga. co. yu Đorđe Trifunović, djole@ europemail. com Tatjana Petrovic, etf. . bg. ac. yu Petrovic, taniusha@rti 7020. etf bg. ac. yu Voislav Galić, vgalic@ bitsyu. net Prof. Dr. Veljko Milutinović, vm@ yu vm@ etf. bg. ac. yu

Introduction l Two basic groups of ad-hoc networks: – Networks of mobile computers handled by users – Wireless sensor networks l Basic characteristic: ability to establish network communication between hosts without any infrastructure needed. – The most significant advance compared to classic fixed systems – Reveals a very large scale of new possibilities 2

Ad-Hoc Networks vs Mobile Networks l Mobile hosts can communicate between each other on much greater distances than covered by their ranges. – That is practicable thanks to presence of other mobile hosts that can be reached by the source host, and that are willing to retransmit its packets further on – Thus, propagating from one MH to another, packets are conveyed to the destination l l That is how multihopwireless communication through a temporally formed ad-hoc network is realized. Major bottleneck: Routing algorithms 3

Routing in Ad-Hoc Networks How to find the right way?

Routing in Ad-Hoc Networks l l l Efficient routing of packets In conventional networks, the most widely used routing algorithms are such as distant vectoror link state Periodical broadcast, with the purpose of keeping routing tables up-to-date In some cases those algorithms were adapted to be used in ad-hoc networks We will just mention two representatives: – Destination-Sequenced Distance-Vector(DSDV) – Wireless Routing Protocol(WRP) l Benefit: Route to every host in the network is always known. But… 5

Routing in Ad-Hoc Networks l Drawbacks of adapted conventional routing algorithms seem to be of much more significance than the benefits : – – – Large bandwidth overhead Batteries quickly become exhausted Significantly reduced scalability Unneeded accumulation of redundant routes Often not able to quickly enough respond to dynamics of changes in systems in which the hosts can move 6

Routing in Ad-Hoc Networks On-demand routing protocols Because of specified constraints of said solutions , we are going to pay more attention on another approach , which is fundamental for the so-calledon demand routing protocols. l We will shortly describe three of those protocols, which attack the problem from different standpoints, introducing different assumptions and diversely prioritising problems that are to be solved: l – – – Dynamic Source Routing (DSR) Ad-Hoc On-Demand Distance Vector Routing (AODV) Temporally Oriented Routing Algorithm (TORA) 7

Routing Protocols - DSR 1. Dynamic Source Routing (DSR) l Based on the concept of source routing : – Sender provides the sequence of nodes through which the packets will be sent – Sequences are held in route cache that every host must maintain for itself l Route is determined dynamically, when it is needed : – There are no periodical advertisements of routers – Instead, every host initiatesroute discovery when it needs to send a packet to another host for which initiator does not have the associated route in its cache 8

Routing Protocols - DSR Route Discovery – route request l Initiated by sending aroute requestpacket: – Propagates through the network until it reaches the destinationhost (if the route exists); – On its way, it collects addresses of all visited hosts, and stores them into itsroute record; 3 1 1, 3, 4, 5 1 src 1, 2 1 5 4 1, 3, 4 2 6 dst 9

Routing Protocols - DSR Route Discovery – route reply The first route request packet that arrives to destination is accepted, its route record is copied and returned to the initiator using the route reply packet. l Destination host returns the route reply to the initiator of route discovery, using the route from its own cache. l (1, 3, 4, 6) 1 3 5 (1, 3, 4, 6) 4 (1, 3, 4, 6) 6 2 10

Routing Protocols - DSR Route Discovery – route reply (2) l If destination host does not have a route to the source host in its cache, there are two options: 1. Route reply is returned using inverse route that was found by the routerequest packet; 2. Destination host initiates routediscovery to find a route to the original initiator. l First option requires symmetric links: – Transfer quality must be the same in both directions; – But that is often not the fact in mobile communications. 11

Routing Protocols - DSR Route Discovery – route reply (3) l Second opportunity(inverse route discovery, from destination to source)is more significant: – Providing support for non-symmetric links (very important merit of this algorithm). – In that case, the original route reply must be sent together with new route request, i. e. attached to it (that is called piggybacking) 12

Routing Protocols - DSR Route Maintenance Implemented by acknowledgements and route error packets. l Acknowledgements may be: l – hop-by-hop – links must be symmetric – end-by-end – important when links are not symmetric 13

Routing Protocols - DSR Route Maintenance (2) l When using hop-by-hop acknowledgement: r aecrk aecrr k – Host which did not get acknowledgement ? for its retransmission sends route error packet with information about hop that broke down; – Upon that error packet, source host truncates routing tree being held in its cache, at the point of that hop : l When using end-by-end acknowledgement: – Information about the point of breakage does not exist; – Source host may only assume that the last hop is broken. 14

Routing Protocols - DSR Summary l Dynamic Source Routing protocol is suitable for appliance in ad-hoc networks: – with moderate numbers of mobile hosts; – which move with moderate velocities. 15

Routing Protocols - AODV 2. Ad-Hoc On-Demand Distance Vector Routing(AODV) l New route is discovered in a manner that looks similar to route discovery by DSR: – Source host (src) broadcasts route request(RREQ) to all of its neighbours when needs to discover route to somedestination host(dst); – Then, it waits forroute reply (RREP). l But similarity is discontinued at this point. ? src 16

Routing Protocols - AODV Route Request l Sequence number – Number that every host generates for itself. – It is incremented every time when something is changed in adjacency (e. g. , when some link breaks). – For every route, destination sequence number(DSN) is stored in therouting table – Last DSN that src earlier knew for any route todst, is sent in RREQ, together with current sequence number of src and other information needed: RREQ ( src, dst, src. SN, dst. DSN, … ) 17

Routing Protocols - AODV l RREQ does not contain the route record: – Does not collect information about hosts through which it propagates; – Remembers only the number of hops. l Instead, the host through which RREQ propagates adds inverse route (towardssrc) to its routing table: – Stores, together with other relevant information, the address of the neighbour n( 1) that sent RREQ to it; – If that host later receives relevant RREP, it will automatically know that reply should be transferred to the neighbourn 1) ( ; – In that case, it also records the address of the neighbourn 2) ( that sent RREP, thus establishing route towards dst. n 1 RREQ route to src RREP route to dst 18 n 2

Routing Protocols - AODV l Instead of recording the whole route, as with DSR applied, host here keeps onlynext hop (among other relevant information about some destination), i. e. address of its neighbour to which it transfers packets addressed to the destination: D S N A O D V 3 6: 3, 4, 6 5 6: 4, 6 1 4 2 6: 6 3 6: 3 5 6: 4 1 2 6 4 6: 6 19 6

Routing Protocols - AODV Route Reply l When RREQ reaches a host that has a route todst, comparison of. DSNs from the packet and from the routing table is made: – If DSN from RREQ is greater the host’s route todst is not recent enough the host rebroadcasts the request; DSN=10 DSN(dst)=8 – Otherwise, the host returns RREP tosrc, with the calculated information about the discovered route (total hop count, lifetime that remains…), DSN=10 DSN=12 among which more recent DSN, copied from the routing table of the host. DSN(dst)=12 20

Routing Protocols - AODV RREQ may reach dst itself, and thendst returns RREP to src. l Anyway, RREP is returned using inverse route formed by intermediate hosts during the propagation of RREQ. l dst src 21

Routing Protocols - AODV Route Maintenance For every route that a host is acquainted with, it maintains the list of neighbours that use that route, so that it is able to notice them about eventual link breakage on the route. l Link breakage is detected by the absence ofhello messages, which must be emitted by every host after the specified time interval expires. l 22

Routing Protocols - AODV Summary – Advantages of AODV over DSR l Significantly smaller network bandwidth overhead: – Both control and message packets are smaller; – The reason is the requirement of only two addresses when routing (destinationand next hop), instead of the whole route as with sequenced routing; – This is good for scalability, because the size of a packet does not depend on the network diameter. l Provides support for multicasting. 23

Routing Protocols - AODV Summary – AODV drawbacks Works only with symmetric links. l Hosts must periodically advertise hello messages : l – Increased bandwidth overhead; – Reduced possibility of energy conservation by remaining in the sleep mode. l Does not supportmulti pathrouting (offers only one route per destination): – Every time when some link on the route breaks, new route must be discovered ; – Increased probability of congestion. 24

Routing Protocols - TORA 3. Temporally Oriented Routing Algorithm (TORA) Offers an interesting approach to problem solution. l Conceived as link-reversal algorithm. l The idea is to define topology of a network using a directedacyclic graph (DAG): l – Hosts represented as nodes and with directed links ; – Direction of link is realized by assigning height to every node, so that the link is directed from the node with greater height to the node with lower height. 25

Routing Protocols - TORA General idea The destination node should have the minimal height in the graph. l Other nodes get greater and greater height as the distance from the destination grows. l Packets may be sent only from “higher” to “lower” nodes, i. e. , only via downstream links. l 26

Routing Protocols - TORA DAG Forming Starts when node that does not have downstream links wants to send a packet to a destination node. l Initially, all nodes in the graph have undetermined height (NULL), except the destination node that has the height of ZERO (which is considered less even from NULL ). l Source node then broadcasts QRY packet to its neighbours. l QRY packet propagates through the network, marking every node over which it passes as “interested for route discovery” by setting itsroute request flag. l 27

Routing Protocols - TORA When QRY packet arrives to a node that has at least one downstream link, the node then emits the UPD packet. l UPD propagates back through the network, setting the height to all nodes with the route request flag set, at the same time resetting those flags. l Every further node gets greater height then the precedent one on the path of the UPD propagation. l dst src 28

Routing Protocols - TORA Many downstream links can lead to the same destination. l Algorithm enables multiple path routing. l 29

Routing Protocols - TORA l In case of link break: – If the node still has downstream links left, no action is performed – Otherwise, the node broadcasts a UPD packet, thus recovering DAG l Recovering is a one-pass process, except in the case of network partitioning 30

Routing Protocols - TORA Advantages of TORA: l l l Fast route discovery Multiple path routing Recovering is localised Multicast support Lightweight Adaptive Multicast (LAM) algorithm 31

Routing Protocols - TORA Downsides of TORA: Requires external timing mechanism (GPS…) l DAG becomes less optimal as the time passes l – Can be solved using refresh packets 32

Routing Protocols - TORA is designed for: Large networks l Many nodes with dense distribution l 33

Bluetooth Following the steps of King Harald. . .

Bluetooth Special Interest Group (SIG): l l l Ericsson Mobile Communications AB IBM Corp. Intel Corp. Nokia Mobile Phones Toshiba Corp. 35

Bluetoothwireless technology: l l l Open specification for short-range wireless connectivity Effortless, instant connections Wide range of communication devices Based on a radio link Facilitates fast and secure transmission of both voice and data Operates in a globally available frequency band 36

Bluetoothmodule: • ports (USB, UART, PCM) • baseband • voltage regulator • crystal • radio • antenna interface • flash 37

Design of ad-hoc multihop sensor net with Bluetooth: Lessons learned How to make your electronic devices cooperate with each other?

System Overview An open data acquisition system, based on wireless ad-hoc multihopsensor network: l l l Routing protocol Interface and routing module (IFRM) Personal Digital Assistant (PDA) Digital Signal Processing System (DSPS) Software for data acquisition (Shell) Internet accessible database 39

System Overview 40

Implementation - routing protocol Designed with the following guidelines: speed l reliability l simplicity l Existing solutions considered: DSR l AODV l TORA l 41

Implementation - routing protocol Route Request: 42

Implementation - routing protocol Route Reply: 43

Implementation - routing protocol Route Error: 44

Implementation - routing protocol Functioning of the protocol: Master l Gateway l Slave l 45

Implementation - routing protocol Possible network topology 46

Implementation - routing protocol Routing table entry 47

Implementation - DSPS The DSPS architecture: 48

Implementation - Shell Multipurpose software platform: l l l Data acquisition Decision making Signal processing Alarming Tracking the current state of the system Database administration 49

Implementation - Shell Communication with sensors: TCP/IP ports l Two-way socket communication l Conformance to IEEE 999 -1992. SCADA specification l 50

Implementation - Shell System configuration: Type of the sensor l Name of the sensor l Factory address of corresponding. Bluetoothmodule l Range of allowed values l 51

Implementation - Shell Readings display Simple view l Graph view l Real-time monitoring l History l 52

Implementation - Shell Spectrum analysis 53

Implementation - Shell Database Realized with My. SQL Server l ODBC l Flexible, DBMS independent l 54

Implementation - Internet connectivity Standard three-tier architecture is used: 55

AD-HOC for E-TOURISM Sponsors: CNUCE + University of Pisa + University of Santa Anna Details: IEEE Computer, February 2004 56

Architecture of the CNUCE Project USERS GSM Ad-Hoc DM Internet Procedure: Hansa ++ Implementation: 7 Problem: What routing algorithm ? Future: Storage. Tek 57

Essence: Technology + Procedure l l l l Sophisticated mobile phones Mobile agents for behavior monitoring Advanced MMI + Specialized peripherals Data Mining connected to the Internet Advanced security Specialized software engineering Techno-economic issues 58

Extended Applications l Intelligence l Childcare l Emergency l Product lifetime tracking l Medical care l Marketing research l Education Work in progress: Implementation spec 59

A simple application A part of “tourist city” project l User interface in a Virtual Presence system l public class Demo. Midlet extends MIDlet { private Meni meni; private Opis opis; private Slika slika; private String xml. String = ""; private String current. Node. Id = "NODE"; private String web. Service = "http: //193. 203. 26. 94/Java. Mobile/Demo. Java. Mobile. asmx/Vrati. Strukturu. Aplikacije? s="; public Demo. Midlet() { xml. String = load. Xml(web. Service); } public void start. App() { Displayable current = Display. get. Display(this). get. Current(); String logo. String = "BEOGRAD - TURIST"; if (current==null) { Image logo. Picture=null; try { logo. Picture = Image. create. Image("/demo/res/Spomenik. Pobednik. png"); } catch (IOException e) {} Alert alert. Screen = new Alert(null, logo. String, logo. Picture, Alert. Type. INFO); alert. Screen. set. Timeout(5000); set. Screen(current. Node. Id); Display. get. Display(this). set. Current(alert. Screen, meni); } else { Display. get. Display(this). set. Current(current); } } ………………. 60

A simple application (code) public class Slika extends Canvas implements Command. Listener { private Demo. Midlet parent; private String node_id, picture; private Command back. Command; public Slika(Demo. Midlet parent, String node_id, String picture) { this. parent = parent; this. node_id = node_id; this. picture = picture; back. Command = new Command("Nazad", Command. BACK, 2); add. Command(back. Command); set. Command. Listener(this); repaint(); } public void command. Action(Command c, Displayable d) { if (c==back. Command) parent. slika. Back(node_id); } public void paint(Graphics g) { g. set. Color(0 x 00 FFFFFF); g. fill. Rect(0, 0, get. Width(), get. Height()); Image image; try { image = Image. create. Image(picture); g. draw. Image(image, image. get. Width()/2, image. get. Height()/2, Graphics. VCENTER|Graphics. HCENTER); } catch (Exception e) {} } } 61

A simple application (code) public class Meni extends List implements Command. Listener { private Demo. Midlet parent; private Command refresh. Command, exit. Command, back. Command; private String node_id; public Meni(Demo. Midlet parent, String label, String node_id, String[] meni. List) { super(label, List. IMPLICIT); this. parent = parent; this. node_id = node_id; for (int i=0; i<meni. List. length; i++) append(meni. List[i], load. Image("/demo/res/NODE. png")); if (node_id. equals("NODE")) { refresh. Command = new Command("Osvezi", Command. BACK, 2); add. Command(refresh. Command); } else refresh. Command = null; exit. Command = new Command("Izlaz", Command. EXIT, 1); add. Command(exit. Command); if (!node_id. equals("NODE")) { back. Command = new Command("Nazad", Command. BACK, 2); add. Command(back. Command); } else back. Command = null; set. Command. Listener(this); } ………………. } 62

A simple application (screens) 63

References: • • Vladan Devedžić, “Inteligentni informacioni sistemi”, digit/FON Beograd, 2000. J. M. Bradshaw, “Software Agents”, MIT Press, Cambringe, MA, 1997. P. Adrians, D Zanintge, “Data Mining”, Addison-Wesley, Reading, MA, 1996 “FIPA Agent Abstract Architecture Specification”, FIPA, Geneva, Switzerland, 2002. “FIPA ACL Message Structure Specification” , FIPA, Geneva, Switzerland, 2002. “FIPA Agent Management Specification”, FIPA, Geneva, Switzerland, 2002. “Wireless Application Protocol, Architecture Specification”, WAP Forum, 2001. “MIDP (JSR-37) JCP Specification, Java 2 Platform ME, 1. 0 a”, Sun Microsystems, Palo Alto, CA, USA, 2000. http: //www. fipa. org http: //www. wapforum. org http: //www. cisco. com http: //java. sun. com http: //wireless. java. sun. com/midp ………

http: //galeb. etf. bg. ac. yu/vm/ e-mail: vm@etf. bg. ac. yu 65