1. Slide 1/11 Jose Costa-Requena, Raimo Kantola, Nicklas Beijar / MobileMAN M1/ Eurecom 06-03.2003 MobileMAN Workshop 1 Eurecom 06-07.03.2003 Jose Costa-Requena, Raimo Kantola, Nicklas Beijar {Jose, Raimo.Kantola,Nicklas.Beijar}@netlab.hut.fi Networking Laboratory Helsinki University of Technology P.O. Box 3000, FIN-02015, Finland

2. Slide 2/11 Jose Costa-Requena, Raimo Kantola, Nicklas Beijar / MobileMAN M1/ Eurecom 06-03.2003 OutlineOutline 1.Preliminary architecture design 2.Last period achievements 3.Preliminary results 4.Steps forward

3. Slide 3/11 Jose Costa-Requena, Raimo Kantola, Nicklas Beijar / MobileMAN M1/ Eurecom 06-03.2003 Preliminary architecture design In order to analyse several routing schemes in a node and routing independent of physical layer it is required a modular architecture with differentiated elements. Interoperability between modules through standardized API Initiates the discovery procedure Provides an Attach – Detach mechanism Accommodates the rate of updates Initial set of modules Routing module Replication and synchronization module – Requirements for replication – Independence of underlying technology – Different routing protocols above Context Sensitive Roaming Layer – Support the roaming dependent of terminal applications

4. Slide 4/11 Jose Costa-Requena, Raimo Kantola, Nicklas Beijar / MobileMAN M1/ Eurecom 06-03.2003 Preliminary architecture design: Routing module Main modules in the architecture design Context Roaming Module – Provide the API to the applications to roam depending on context information and run in Ad Hoc mode when appropriate. Ad Hoc Framework – Implement the different Ad Hoc routing algorithms (proactive, reactive, or others) – Interact with the Linux Kernel for implementing Attach-detach procedures. – Study necessary extensions to perform service discovery or routing optimisations.

5. Slide 5/11 Jose Costa-Requena, Raimo Kantola, Nicklas Beijar / MobileMAN M1/ Eurecom 06-03.2003 Preliminary architecture: Routing Ad Hoc Frwrk Sub classes: – Specific Routing Module (implement the different Ad Hoc routing algorithms; proactive, reactive, or others) – The Generic Ad Hoc module provides the functionality common to any routing algorithm (packet processing, DB management, replication modul,etc) – Kernel API, interacts with the Linux Kernel. Generic Ad Hoc Module ask_rt() Kernel AdHoc API (from Kernel) Gneric DB Mngt Network Servic Data Routing Data Ad Hoc Framework API + change_Context_Req() Specific Routing Module + Change_Context() Context Roaming Module AdHoc_Framework

6. Slide 6/11 Jose Costa-Requena, Raimo Kantola, Nicklas Beijar / MobileMAN M1/ Eurecom 06-03.2003 Initial architecture: Kernel Ad Hoc module Sub classes: – Kernel API, interacts with the Linux Kernel. – Kernel Ad Hoc module, implements missing functions in order to accomodate Ad Hoc framework module.

7. Slide 7/11 Jose Costa-Requena, Raimo Kantola, Nicklas Beijar / MobileMAN M1/ Eurecom 06-03.2003 Actual state: Framework The initial division and classification of needed modules is done but still the APIs are fuzzy and it needs further work. It has been implemented the basis of the Ad Hoc framework but at this point it only contains AODV Integration of the Ad Hoc framework into iPAQ Integration on series 8500 was straighforward but the integration on 8900 took couple of months because of the binary break in the compiler, the processor is totally different from previous models. primitive test was performed among 4 nodes (using ”ping” for collecting reports of packets statistics). Initiate the integration of SIP client. Initially we tried to use any of the free available implementations. JAVA version required VM and it was not possible to install because of large space it requires in the node. Looking for optimised bytecode versions of the JVM (kaffee is the best candidate so far but even that was too large). C/C++ versions were quite reduced but they required TCL and other libraries, so we implemented an optimised version.

8. Slide 8/11 Jose Costa-Requena, Raimo Kantola, Nicklas Beijar / MobileMAN M1/ Eurecom 06-03.2003 Testing Framework Test consists of 4 iPAQ nodes(addresses pre-configured 10.0.0.1-10.0.0.4) Testing was performed indoors and outdoors with nodes moving randomly at walking speed. The nodes were sepparated to have single link between them. The test environment had additional interferences from WLAN and Cordless phone network working at similar frequency in the Campus. There were additional interference factors such as battery decrease and antenna masquerading that were increasing the error messages. Interesting results: High un-stability of the route since the RREP is received up to the moment where the route is available for bi-directional connectivity. The route setup takes between 4-10s depending on the intermediate errors and possible interferences. The high route setup is difficult to minimise with backoff at higher layer protocols (e.g. SIP can have a backoff of 4s).

9. Slide 9/11 Jose Costa-Requena, Raimo Kantola, Nicklas Beijar / MobileMAN M1/ Eurecom 06-03.2003 Next steps(1/2): 1.Include a link state protocol into the actual framewrok (OSLR from INRIA). Test and integrate into the existing nodes and report the results. 2.Analysis and design of candidate location-based routing protocol, initiate a cross-communication with CNR on this topic. 3.Continue the integration of SIP client for testing with audio sessions. The actual client is quite simple and uses IP addresses rather than hostname. Check the mechanism for providing a suitable naming space and name discovery within the AD Hoc network. 4.Check existing service discovery mechanism and select a suitable one to be integrated into the framework test the behaviour within the framework.

10. Slide 10/11 Jose Costa-Requena, Raimo Kantola, Nicklas Beijar / MobileMAN M1/ Eurecom 06-03.2003 Next steps(2/2): In the previous period there were mainly 2 people working on the implementation & integration. In next period there would be 1 person and probably a 2nd that could be interested on OSLR and the integration on actual framework. The targets for next period are quite ambitious so it is necessary to prioritise the previous 4 steps. Note: ”In previous objectives it was not considered the implementation of user friendly UI, the actual implementation has to be initialised manually and the session is initiaed via command line.”

11. Slide 11/11 Jose Costa-Requena, Raimo Kantola, Nicklas Beijar / MobileMAN M1/ Eurecom 06-03.2003 Thank you for your attention! Thank you for your attention!