Supporting Communication for Multihomed Mobile Devices

Prof. Robin KravetsMobius Group

Dept. of Computer ScienceUniversity of Illinois at Urbana-Champaign

Supporting Communication for Mobile Nodes

Communication resources Multiple choices

No one perfect technology Range vs. Capacity vs. Power

Dynamically changing Need information about

availability Coverage varies

Transparent support from the network

Goal Support mobile devices

Requirements Connectivity Configuration Performance

Cellular Network

Wireless LAN

In-Building Infrared

HomeRF

Satellite Network

GPS NetworkPacket Radio

Network

Wireless LAN

BlueTooth

Infrared

Supporting Communication for Mobile Nodes

Challenge Mobile hosts have multiple

network interfaces Coverage areas of different

technologies overlap Mobile hosts are able to use

network access points from different technologies

Goal Intelligent use of multiple

interfaces Approach

Focus on supporting communication for a single node

IR

WLAN

Cell

Transport:

Network:Contact Networking

Control:Corvus

Link Layer

Mobility Support Throughout the Protocol Stack

Network Layer Connectivity Configuration Expose available interfaces Contact Networking

Transport Layer Performance Expose potential

configurations Resource Management

Efficient use of resources in the current environment

Corvus

Application

Contact Networking

Environment Mobile node Multiple interfaces Unknown environment

Goal Simple efficient communication with other

devices in the current environment, as well as with other devices in the Internet

People Casey Carter, UIUC Jean Tourrilhes, HP Labs

Local vs. Remote Communication

Existing Solutions Focus on

communication with devices in the Internet Remote

communication Inefficient for

communication with local devices

Requires internet access

Requires complex configuration

Remote Communication

Local Communication

MN MIPFA

MIP HA

MN MIPFA

MIP HA

MN MIPFA

MIP HA

MN MIPFA

MIP HA

Con

tact

Net

wor

king

Problems of Remote Communication

Long-haul wireless is inherently slower and more expensive

Two users meet in the desert Can’t use MobileIP without Internet Can’t use DNS without Internet

How about manual configuration? Complicated IP and link layer configuration Fails the “Mom” test

Solution? Just use a floppy!

Con

tact

Net

wor

king

Goals of a Localized Mobility System

Infrastructureless Internetworking without the Internet

Transparent User ignorant of number and type of

interfaces Transparent local/remote communication

Rendezvous, ZeroConf

Simple as beaming a business card between PDAs

Con

tact

Net

wor

king

Realizing a Localized Mobility System

Challenge Link-layer connections are changing dynamically

Goal Maintain an application-layer flow across connection lifetimes

A flow is an end-to-end bit pipe between transports A channel is the end-to-end network-layer pipe through which

transport-layer flows propagate A connection is a link-layer pipe through which channels propagate

Transport

IP

Link

Channel

Connection

Flow

Link Connection

Transport

IP

Link

Con

tact

Net

wor

king

Requirements forLocalized Communication

Neighbor Discovery Name Resolution On-Demand Interface Binding IP Autoconfiguration Neighbor Routing Channel Management Infrastructure Access

Con

tact

Net

wor

king

Requirements:Neighbor Discovery

Presence Mobile node needs to

know what neighbors it can access through its interfaces

Link-layer dependence Discovery mechanism

is necessarily specific to each link layer

Alice Who’s there?

Who’s there?Bob

Con

tact

Net

wor

king

Requirements:Name Resolution

Simplicity Users want to use

names instead of addresses even when DNS is not available

Transparency Local and remote

names should be the same

Alice It’s Bob!

It’s Alice!Bob

Con

tact

Net

wor

king

Requirements:On-Demand Interface Binding

Binding is configuration to select the link-layer medium ESSID in IEEE 802.11

Saving Power Desirable to keep

interfaces in low-power state

Flexibility Can only bind to one

medium at a time

Alice

I want to talk to Alice!

Bob

Con

tact

Net

wor

king

Requirements:IP Autoconfiguration

IP needs an address Can’t rely on DHCP Manual config is

worse Fast and persistent

Link-local IP addresses are insufficient

Alice

Bob

Bob’s IP

Alice’s IP

Con

tact

Net

wor

king

Requirements:Neighbor Routing

Route support Tell IP who is at the

other end of the connection

Bidirectional Ensure symmetric

routing

Alice

I am connected to

Alice!Bob

I am connected to

Bob!Bob via Bob’s IP

Alice via Alice’s IPC

onta

ct N

etw

orki

ng

Requirements:Channel Management

Multiple Neighbors Orchestrate

simultaneous channels to several neighbors

Multiple Interfaces Choose between

potential connections to a neighbor

Switch channel when connection breaks

Proactively switch to better connections

Alice

Bob

Carol

I lost my connection to

Alice!

Switch my connection to

Bob to WLAN.

Con

tact

Net

wor

king

Requirements:Infrastructure Access

Local is better… Prefer local

communication when possible

But people move Seamlessly

transition between local and remote communication

BobI lost my last connection to

Alice!

Switch my channel to Bob

to remote communication

.

InternetInternet

Alice

Con

tact

Net

wor

king

Approach:Contact Networking (CN)

Architected as several modules in two sub-layers Link-layer

independent part (in IP layer)

Link-layer specific part (in Link layer)

Applications

IP

LinkLayers

Transports

Route Table

CN

DatabaseRoute Control

Interface ManagementCNS ND

Physical Layers

Con

tact

Net

wor

king

Neighbors

Interfaces

Links

Paths

Architecture:Database

A

CBA

CB

What Transport sees:

Con

tact

Net

wor

king

Architecture:Interface Management

Watch for interface plugging Inform higher layers of new interfaces, or Connections broken by interface removal

Monitor traffic to determine connection idleness Don’t waste battery on idle connections

Con

tact

Net

wor

king

Architecture:IP Autoconfiguration

Extend the MobileIP home address approach Use same Globally Routable IP (GRIP) address

on all interfaces Permanent and statically configured node ID

Sidesteps the addressing problem Distinct IP addresses are unnecessary for one

hop communication Infrastructure access still needs topologically

valid addresses

Con

tact

Net

wor

king

Architecture: Contact Naming System (CNS)

Transparency to Users Every node uses its fully qualified DNS

name for CNS The name DNS resolves to its GRIP

Local and remote names are equivalent Transparency to Applications

CNS and DNS use the same name resolution API

Con

tact

Net

wor

king

Contact Naming System (CNS)

Nodes are identified by CNS records Name GRIP Optional service information

Browsing is possible with aliases “any”, “all” Link-layer specific name suffixes

“any.irda” enables IR selection

Con

tact

Net

wor

king

Architecture:Neighbor Discovery

Transport Nodes Query/Advertise CNS records using link-

layer specific mechanisms Active or On-demand discovery

Name resolution requests can trigger neighbor discovery

Caching CNS record is coupled with neighbor knowledge

Discovery adds new Path and Neighbor to Database

Con

tact

Net

wor

king

Architecture:Route Control

The brains of the operation Controls other modules

Several primary responsibilities On-demand binding Neighbor routing Channel control Internet access

Con

tact

Net

wor

king

Route Control:Neighbor Routing

Catch demand indications Queue packets waiting for connection

establishment Create IP routes to reflect link-layer

connectivity Routing is GRIP-specific Enables transport-layer persistence

Con

tact

Net

wor

king

Virtual Neighbor

Internet

Route Control:Infrastructure Access

Treat the Internet as a single virtual neighbor

Virtual paths overlay actual FA paths

Map remote access into virtual neighbor access

FA Path

Virtual Path

Con

tact

Net

wor

king

Route Control:Channel Management

Policy Chooses which path to connect to a

neighbor Decides when to proactively switch

connections Power Conservation

Responds to idleness indications by disconnecting paths and unbinding interfaces

Con

tact

Net

wor

king

Example

The misadventures of hypothetical grad student, Prashant

Three examples show Contact Networking performing Local communication Local communication with handoff Infrastructure access

Con

tact

Net

wor

king

Example Network

MN

/.

InternetDNS

Soda ChipCon

tact

Net

wor

king

Example:Purely Local Communication

Prashant loves FritosTM

Performs purchase transaction with “any.irda”

CNS engages ND to obtain C’s GRIP

First data packet activates path, binds/connects IR

Chip

MNCon

tact

Net

wor

king

CokeTM goes well with FritosTM

As before, but with the soda machine

Prashant pockets the MN, blocking IrDA

Channel management switches paths

Example: Local Communication with Handoff

MN

Soda

Con

tact

Net

wor

king

Example:Infrastructure Access

On the way back to the office, Prashant decides to check the headlines on Slashdot

This is, of course, challenging with a bag of FritosTM in one hand and a can of CokeTM in the otherC

onta

ct N

etw

orki

ng

Example:Infrastructure Access

MN

DNS

/.

Internet

Con

tact

Net

wor

king

Prototype Implementation

Linux 2.4 Kernel Added support for

wireless events

Three link layers IrDA

link-layer notifications 802.11/Ethernet

link-layer notifications Virtual

Dynamics MobileIP

Almost complete Only proactive

discovery No policy support

Static preference order of link layers

No proactive channel switchingC

onta

ct N

etw

orki

ng

Conclusion

Contact Networking extends traditional mobility support with the notion of localized mobility Internetworking without the

Internet Benefits

No changes to IP Link-specific mechanisms

Light-weight discovery Link-failure detection Link-specific optimizations

Simple setup No infrastructure access Simultaneous use of multiple

interfaces

Future Work Integration of Co-Link 802.11 scanning Bluetooth Flexible Network Support

Inverse Multiplexing On-demand ad hoc cloud

formation Integration with resource

management

Con

tact

Net

wor

king

Corvus: A Context-Aware Mobile System

Goals Use of context by the mobile system to support resource

management Inclusion of system-level resources as context

Challenges System resources are shared Context involving systems resources has complex

dependencies Context involving systems resources must have access

control People

Al Harris, UIUC

Context and Its Use

What is context? Information Ex: time, location, available bandwidth

What changes when we consider system resources as context? Dependencies between units of context become more

complex Ex: available bandwidth depends on what applications are

using it Access control to context is needed

Ex: some context may be private to an application or the operating system

Simple interface is needed Ex: applications should not need to know system

configurations to use context

Cor

vus

Context Structure

Defines interface between context user and context provider

Types Simple

Single unit of information Ex.:Time, amount of bandwidth available

Complex Multiple units of information Ex.: GPS coordinates, who is present in the room

Cor

vus

Context Acquisition

Means by which context is acquired

Types Basic

Acquired from a single source

Ex.: Time Aggregate

The union multiple units Ex.: Bandwidth usages of

applications Fused

Derived from other units Ex.: Amount of Bandwidth

Available

Cor

vus

Context Mutability

How applications affect context

Types Immutable

Applications can’t change Ex: Time of day

Direct-mutable Application directly change Ex: Desired bandwidth

Indirect-mutable Applications’ actions can

affect the context Ex: Amount of bandwidth

available on the system

APP

APP

APP

Cor

vus

Context Dependency

Problem Context represents dynamically changing

information Goal

Capture the relationships between context to track changes

Approach Context dependency graph (CDG)

Cor

vus

Context Dependency Graphs

Context in the middle of the graph only needs to be recalculated when a leaf changes.

Example CDG for a Content Filtering Application

Available Interfaces

Channel Quality

Application A Channel

Usage

Application B Channel

Usage

Aggregate

Fused

Basic

Presentation Data Unit

Sizes

Time Constraints

Available Bandwidth

Amount of Data to send

What Data to Send

Cor

vus

Context Access Control

Accessing Context Current approach: Context Blackboard Globally readable Globally writable

Problem Applications should not be able to access and/or

alter all context Approach

Extended Context Blackboard

Cor

vus

Extended Blackboard

Extended Blackboard contains access control areas: Global, Application specific and OS specific

Public

Private

Read: GlobalWrite: Global

Read: GlobalWrite: OS

Read: OSWrite: OS

Application A

Read: GlobalWrite: Application A

Read: Application A/OSWrite: Application A

Read: Application A/OSWrite: OS

Application B

Read: GlobalWrite: Application B

Read: Application B/OSWrite: Application B

Read: Application B/OSWrite: OS

Cor

vus

Example Scenario

Video Feeds from two people A friend at home A colleague at work

Presence Detection utility running at both locations

Need to view feed from colleague when available

Cor

vus

Example Scenario

Video Source 1

Mobile Node

MobileIP Foreign Agent

802.11

InternetInternet

Public

Private

Time

PriorityVideo 1: Med

Video 1

BW Needed: 5 - 25fps

BW Available: 25fps

Cor

vus

Example Scenario

Public

Private

Video Source 1

Mobile Node

MobileIP Foreign Agent

802.11

Video Source 2

InternetInternet

Time

Video 1: MedVideo 2: High

Video 1

BW Needed: 5 - 25fps

BW Available: 5fps

Video 2

BW Needed: 15 - 25fps

BW Available: 25fps

Cor

vus

Example Scenario

Public

Private

Video Source 1

Mobile Node

MobileIP Foreign Agent

802.11

Video Source 2

InternetInternet

Time

Video 1: MedVideo 2: High

Video 1

BW Needed: 5 - 25fps

BW Available: 0fps

Video 2

BW Needed: 15 - 25 fps

BW Available: 15fps

Cor

vus

Comparison

Standard Kernel and resource management

0

5

10

15

20

25

30

35

0 5 10 15 20 25 30 35 40

Time (min)

Fra

me

s p

er

Se

co

nd Collegue

Friend

Cor

vus

Comparison

Priority based resource management

0

5

10

15

20

25

30

35

0 5 10 15 20 25 30 35 40

Time (m in)

Fra

me

s p

er

Se

co

nd Collegue

Friend

Cor

vus

Comparison

Corvus performance

0

5

10

15

20

25

30

35

0 5 10 15 20 25 30 35 40

Time (min)

Fra

me

s p

er

Se

co

nd Collegue

Friend

Cor

vus

Conclusions

Corvus: Context distribution and resource management

framework Extended categorization

Capture and understand context relationships Context Dependency Graphs

Represent the application-context and context-context relationships

Extended Blackboard Provided access control

Cor

vus

Future Directions

Policy Enforcement Make sure applications are well-behaved Ex.: Keep applications from trying to use

more bandwidth then Corvus allots Group Management in the Blackboard

Access area for context to be shared between a group of applications, but not globally

Cor

vus

Research in Mobile and Wireless Networking

Robin Kravets

Mobius Group

rhk@cs.uiuc.edu

http://mobius.cs.uiuc.edu