Slide 1 Jose Costa-Requena, Raimo Kantola, Nicklas Beijar / MobileMAN Kick-off/ CNR,Pisa 04-06.11.2002 MobileMAN kick-off Jose Costa-Requena, Raimo Kantola,

Slide 1Jose Costa-Requena, Raimo Kantola, Nicklas Beijar / MobileMAN Kick-off/ CNR,Pisa 04-06.11.2002

MobileMAN kick-offMobileMAN kick-offMobileMAN kick-offMobileMAN kick-off

Jose Costa-Requena, Raimo Kantola, Nicklas Beijar

{Jose, Raimo.Kantola,Nicklas.Beijar}@hut.fi

Networking Laboratory

Helsinki University of Technology

P.O. Box 3000, FIN-02015, Finland


OutlineOutlineOutlineOutline

1. Assumptions

2. Design Requirements

3. Initial Architecture design

4. Ad Hoc framework modules

5. Service discovery extensions in AODV

6. Steps forward


AssumtionsAssumtionsAssumtionsAssumtions

• Initial assumptions to clarify before going forward• Several routing protocols for Ad Hoc networks

• Proactive• Reactive• Hybrid• Which protocol to select?

• Required Services for network and applications functioning• DHCP servers, DNS servers(broadcast or unicast for IPv6 discovery),

Positioning systems, SIP registrars, Gateway Location (for interoperability with fixed networks), etc.

– Service Discovery embedded with routing?-> Common mechanism to be used by ANY upper layer to discover network and application services.

– Horizontal approach?-> Simple and does not complicate the selected routing protocol but it is left up to the application to implement the appropriate Service discovery?Broadcast at application level versus Service Discovery within routing?


Design requirementsDesign requirementsDesign requirementsDesign requirements

1. Some nodes are highly mobile with small resources, some with more resources are quite static• Nodes classification• Classification criteria

2. Support for several routing algorithms and several link technologies• Division of the problem into different modules• Standardized API allows replacing modules

3. Support for persistent data required when Ad Hoc network is part of another infrastructure (3G, 4G)

4. What are the routing requirements for service discovery to support in order to request additional service from other infrastructures (Positioning Services for location information)

5. What are the routing requirements in order to identify the requirements to the Physical Layer.



1. Some nodes are highly mobile with small resources, some quite static with more resources• Nodes classification• Classification criteria






Initial architecture assumptionsInitial architecture assumptionsInitial architecture assumptionsInitial architecture assumptions

• A preliminary basic nodes classification could be:• Smart nodes

– Nodes with more resources and less mobility, e.g. laptops, servers, network access points. Only smart nodes are capable of maintaining large data amounts nodes participate in replication

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

• Information accessible from different locations Reduced load of route discovery

• Flexible node classification in order to allow nodes to change roles (e.g. smart node becomes a dummy node)• Attach – Detach procedure









Initial architecture designInitial architecture designInitial architecture designInitial architecture design

• In order to support Several routing schemes in a node and routing independent of physical layer it is required a modular architecture with differentiated modules.

• 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 to and dependent of terminal applications









Routing moduleRouting moduleRouting moduleRouting module

Communication Module Physical Layer

Application and services

IP Layer (IPv4/IPv6 )

Directory Services

User Services (Messaging Gaming)

Future Services

Context - Sensitive Roaming Layer

Synchronization Replication

module (SCSP)

Routing Information

Routing Algorithm Module

API

Link Layer Protocol

Routing Module

Routing Module

Services and session management

(SIP,HTTP)

Auto - Configuration Module

Physical Layer

Application and services

IP Layer (IPv4/IPv6 )

Directory Services

User Services (Messaging

Gaming) Future

Services

Context - Sensitive Roaming Layer

Synchronization & Replication

Module (SCSP)

Routing Information

Routing Algorithm Module

API

Link Layer Protocol

Routing Module

Routing Module


(SIP,HTTP)


(SIP,HTTP)


(SIP,HTTP)

Auto - Configuration Module

Module Policy Module


Initial architecture modules: Routing moduleInitial architecture modules: Routing moduleInitial architecture modules: Routing moduleInitial architecture modules: Routing module

AdHoc_FrameworkKernel

Context Roaming Module

Interface Handler

Terminal Applications

• Main modules in the architecture design• Context Roaming Module

– Provide the API to the applications to roam depending on context information.

• Ad Hoc Framework– Implement the different Ad Hoc routing

algorithms (proactive, reactive, or others)– Interact with the Linux Kernel for

implementing Attach-detach procedures.– Implement the necessary extensions to

perform service discovery.









Initial architecture: Routing Ad Hoc FrameworkInitial architecture: Routing Ad Hoc FrameworkInitial architecture: Routing Ad Hoc FrameworkInitial architecture: Routing Ad Hoc Framework

• 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 Ad Hoc API(f rom Kernel)

Gneric DB Mngt

Network Servic Data

Routing Data

Ad Hoc Framework API

+ change_Context_Req()

Specific Routing Module

+ Change_Context()

Context Roaming Module


Initial architecture: Kernel Ad Hoc moduleInitial architecture: Kernel Ad Hoc moduleInitial architecture: Kernel Ad Hoc moduleInitial 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.

Core Kernel(f rom Use Case View)

Kernel Ad Hoc module(from Use Case View)

Kernel Routing Table(from Use Case View)

Kernel API

(f rom Use Case View)

Kernel Ad Hoc API


Initial architecture design: Multiple interfacesInitial architecture design: Multiple interfacesInitial architecture design: Multiple interfacesInitial architecture design: Multiple interfaces

• The Kernel Ad Hoc module will request information from the network interfaes in order to get link state data.

• This information will be provided to the Ad Hoc Framework module to be utilised by the appropiate AD Hoc algorithm.

WLAN Interface

Core Kernel(f rom Use Case View)

UMTS Interface

Bluetooth Interface









Service discoveryService discoveryService discoveryService discovery

Message Type

Network Service Announcement

Routing Protocol specific fields

Service Type

Network Management (Charging) Service Information[Charging server Address,

Charging, info, Billing,authentication info]

Service Object Service Data

Proposed extensions for network incentive and Service discovery


Service Discovery extensions in AODVService Discovery extensions in AODVService Discovery extensions in AODVService Discovery extensions in AODV

draft-koodli-manet-servicediscovery-00.txt, R. Koodli,C. Perkins,Oct 2002, IETF work ongoing.

Message types:

Service discovery request: SREQ

Service discovery response: SRESP

Type

<Service-type> String

Service TypeLength Reserved

Service Request PRedicate

Type

URL (Variable length)

LifetimeLength

Auth blocks (if any)

URL length

No URL auth


Actual state: FrameworkActual state: FrameworkActual state: FrameworkActual state: Framework

• Initial division and classification of needed modules• Implementation of some components in those modules extracted from existing

implementations (UU, NIST, etc)• Initial set of elements supporting AODV• Tested among (4-5) fixed nodes for debugging purposes

• Including new modules for IPV6 (HUT)• Support for AODV over IPV6• After tested would it would be provided as library

• Next steps:• Extend existing modules to support several routing protocols and underlying

transport layers• Define the functionality of basic Context Sensitive Roaming Layer• Implement the Attach-Detach procedure for separation between smart and

dummy nodes. • Groups of collaborating smart nodes create ”Ad Hoc backbone”• Extend the Ad Hoc Framework including service discovery extensions• Test and provide scalability and performance results.


Additional info: NokiaAdditional info: NokiaAdditional info: NokiaAdditional info: Nokia

• Initial interest for contributing in MobileMAN project as partner proving terminals for testing and participate in IAB.

• After few meetings the interest decreased because of different company interests: BT-enabled terminals and WLAN access but the Ad Hoc is seen as in-mature research area.

• They have some some relevant people working on the area towards more mature technology but not ready to concentrate products on that.

• Result: • They will participate in the IAB but do not provide terminals (The

available terminals that could be ready for adding Ad Hoc feature as a new plug-in are Symbian)

• Latest findings: There is one project researching on alternatives OS to Symbian and they finalised a prototype on Linux. This could be a target for involving Nokia in MobileMAN but it is still too early for getting a clear commitment.


This is where we are This is where we are right now!right now!

Thank you for Thank you for your attention!your attention!

Questions, Questions, suggestions for suggestions for continuing?continuing?

This is where we are This is where we are right now!right now!

Thank you for Thank you for your attention!your attention!

Questions, Questions, suggestions for suggestions for continuing?continuing?

Slide 1 Jose Costa-Requena, Raimo Kantola, Nicklas Beijar / MobileMAN Kick-off/ CNR,Pisa 04-06.11.2002 MobileMAN kick-off Jose Costa-Requena, Raimo Kantola,

Documents