MobileMAN Workshop 2 Cambridge 2 – 4.7.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

Outline Architecture Modules and APIs Last period achievements Steps forward

MobileMAN Consortium/HUT HUT Jose Costa-Requena Nicklas Beijar (Raimo Kantola, Jose Costa-Requena, Nicklas Beijar) Addressing & Resource Discovery Jose Costa-Requena Nicklas Beijar Routing AODV (Lei Xiao) OLSR (Jarrod Creado) ZRP (Juan Gutierrez) Simulation of new algorithms (Ricardo Tormo) MAC (Wei Xiao) SIP ad hoc version (Zhao Xuetao)

Design requirements Support for several routing algorithms and several link technologies Division of the problem into different modules Standardized API allows replacing modules Support for persistent information required when Ad Hoc network is part of another infrastructure (3G, 4G). Resource discovery from the Ad Hoc networks when attached to fixed infrastructure.

Node classification (1) Nodes are different in terms of mobility and resources Node classification 'Smart' nodes Nodes with more resources and less mobility, e.g. laptops, servers, network access points. Only 'Smart' nodes are capable of maintaining large amount of data and provide services 'Dummy' nodes Nodes with less resources and higher mobility, e.g. phones, PDAs Proactive routing between 'Smart' nodes. Reactive routing between 'Dummy' nodes, and between 'Dummy’ and 'Smart' nodes. Groups of collaborating smart nodes form an ”Ad Hoc backbone”

Node classification (2) Classification criteria Link stability Mobility Battery power User preferences This node classification should flexible and dynamic in order to allow nodes to change roles (e.g. 'Smart' node becomes a 'Dummy' node) It is necessary to define Attach – Detach procedure

Preliminary architecture: Main modules (1) Ad Hoc Framework Implements the different ad hoc routing algorithms (proactive, reactive, or others) Interacts with the Linux Kernel for implementing low level routing procedures. Supports necessary extensions to perform service discovery or routing optimisations. Consists of 1 Common module n Routing modules

Preliminary architecture: Main modules (2) Context Roaming Module Provides the API to applications to roam depending on context information Terminal Applications Context Roaming Module AdHoc_Framework Kernel Interface Handler

Preliminary architecture design In order to analyse several routing schemes in a node, a modular architecture with independent but interoperable elements is required. For supporting the activation and deactivation of different routing modules, a Common module that is persistent during the node lifetime is required. Common module Registry module: Stores info about the protocols running in the node. Cache module: Stores the routing information and takes care of replication and synchronization of kernel routing information and the routing information obtained from the protocols running in the node. Routing modules Each routing protocol will be implemented as an independent routing module. Each routing module will interact with the Common module for interworking with other routing protocols running in the node. The communication between the routing modules and the Common module is done with simple messages via interprocess communications.

Preliminary architecture: Ad Hoc Framework The Common Module is a persistent module that maintains routing data and common network information available for any routing algorithm (Cache, Registry). Specific Routing Modules implement the different Ad Hoc routing algorithms (proactive, reactive, or others). The Kernel API and the Generic Ad Hoc module API interact with the Linux Kernel and provides direct access to kernel functionality to reactive protocols. Context Roaming Module AdHoc_Framework Routing Module ZRP Routing Module Routing Module Common Module AODV OLSR Registry Network Service Data Network Modelling Ad Hoc Framework API Cache Common Generic Ad Hoc Module Module API Routing Data ask_rt() Insert_rt() Kernel Ad Hoc API

Preliminary architecture: Kernel Ad Hoc module Communications between the Routing Modules and the Common Module: The Kernel Ad Hoc module implements functions necessary to the Ad Hoc framework module and interacts with the Kernel (i.e. via Kernel API) Any new Routing Module registers to the Registry, so it is visible to other routing modules running in the node (1) and uses the Ad Hoc functionality provided by the Ad Hoc framework infrastructure (2). Any new routes found by the routing modules (OLSR) are pushed directly into the cache that will update the kernel routing table via the kernel Ad Hoc API (3). AODV Routing module Common module 1) Registry (in Common module) 2) Kernel Ad Hoc module (from Use Case View) 3) Kernel Ad Hoc API Cache (in Common module) Kernel API Kernel Routing Table (from Use Case View)

Current state: Framework Last period the ad hoc framework contained the AODV Routing Module and it was integrated and tested into the iPAQ nodes. This period the ad hoc framework contains the Common Module (Registry and Cache). New Routing Modules are under development: OLSR (80% completed) ZRP (50% completed) Simulations using GloMoSim have been done for testing routing algorithms (AODV, DSR). The enhancement of the SIP client for setting up voice calls was not progressed. Internally at HUT was discussed whether this is within the scope of our tasks, so at this point it was not deployed further.

Current state: Testing Framework This period was mainly focused on implementing new modules and they are not completed yet, so there are no testing results available.

Next steps Finalise OLSR and ZRP. Integrate and test with the rest of modules in the iPAQs. Continue the integration of voice capabilities in the framework. Obtain some traffic measurements from voice sessions. Obtain some ideas from real time traffic measurements for proposing a suitable transport protocol design. Analyse the insensitive routing algorithms under study at Netlab. Network modelling using new algorithms still under design phase. Pending target from previous period: Analysis and design of candidate location-based routing protocol, initiate a cross-communication with CNR on this topic. Pending target: Check existing service discovery mechanism and select a suitable one to be integrated into the framework. Test the behaviour within the framework.

Questions? Thank you for your attention!