1. MobileMAN Workshop 2 Cambridge 2 – 4.7.2003
Jose Costa-Requena, Raimo Kantola, Nicklas Beijar
{Jose, Raimo.Kantola,
Networking Laboratory
Helsinki University of Technology
P.O. Box 3000, FIN-02015, Finland

2. Outline Architecture Modules and APIs Last period achievements
Steps forward

3. 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)

4. 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.

5. 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”

6. 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

7. 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

8. 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

9. 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.

10. 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

11. 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)

12. 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.

13. 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.

14. 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.

15. Questions?
Thank you for
your attention!