Chapter 4 wireless internet
Download
1 / 134

chapter 4: wireless internet - PowerPoint PPT Presentation


  • 336 Views
  • Updated On :

Chapter 4: Wireless Internet. Introduction What is Wireless Internet? Mobile IP. TCP in Wireless Domain WAP Optimizing Web over Wireless. What is Wireless Internet?. Wireless Internet refers to the extension of the services offered by the Internet to mobile users.

Related searches for chapter 4: wireless internet

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'chapter 4: wireless internet' - lotus


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Chapter 4 wireless internet l.jpg

Chapter 4: Wireless Internet

  • Introduction

  • What is Wireless Internet?

  • Mobile IP

  • TCP in Wireless Domain

  • WAP

  • Optimizing Web over Wireless


What is wireless internet l.jpg
What is Wireless Internet?

  • Wireless Internet refers to the extension of the services offered by the Internet to mobile users.

  • Many issues need to be solved for wireless Internet:

    • Address mobility: Traditional IP addressing does not support address mobility. Mobile IP is a solution to these network layer issue.

    • Inefficiency of transport layer protocols: Traditional TCP might falsely identify that the data loss is because of congestion but in fact because of transmission errors and then reduce the transmitting rate. This would make the situation even worse. Indirect-TCP (ITCP), snoop TCP, and mobile TCP are some solutions to these transport layer issues.

    • Inefficiency of application layer protocols: The capabilities of and the bandwidth for the handheld devices are limited. Traditional application protocols are not efficient for wireless networks. Wireless application protocol (WAP) is some solution to these application layer issues.

  • This chapter is focused on the issues in network, transport, and application layers and the solutions to these problems.


Motivation for mobile ip l.jpg
Motivation for Mobile IP

  • Problem: Routing

    • based on IP destination address, network prefix (e.g. 156.26.10) determines physical subnet

    • change of physical subnet implies change of IP address to have a topological correct address (standard IP) or needs special entries in the routing tables

  • Solution : Changing the IP-address?

    • adjust the host IP address depending on the current location

    • almost impossible to find a mobile system, DNS updates take to long time

    • TCP connections break, security problems

  • Solution: Specific routes to end-systems?

    • change of all routing table entries to forward packets to the right destination

    • does not scale with the number of mobile hosts and frequent changes in the location, .security problems


Requirements to mobile ip rfc 3344 was 3220 2002 l.jpg
Requirements to Mobile IP (RFC 3344, was: 3220, 2002)

  • Compatibility

    • Mobile IP remains compatible with all lower layers protocols

    • no changes to current end-systems and routers required

    • mobile end-systems can communicate with fixed systems

  • Efficiency and scalability

    • only little additional messages to the mobile system required (connection typically via a low bandwidth radio link in Mobile IP)

    • world-wide support of a large number of mobile systems in the whole Internet

  • Transparency

    • mobile end-systems keep their IP address

    • continuation of communication after interruption of link possible

    • point of connection to the fixed network can be changed

  • Security

    • authentication of all messages related to Mobile IP management


Terminology l.jpg
Terminology

  • Mobile Node (MN): system (node) that can change the point of connection to the network without changing its IP address

  • Home Agent (HA)

    • system in the home network of the MN, typically a router

    • registers the location of the MN, tunnels IP datagrams to the COA

  • Foreign Agent (FA)

    • system in the current foreign network of the MN, typically a router

    • forwards the tunneled datagrams to the MN, typically also the default router for the MN

  • Correspondent Node (CN): communication partner

  • Care-of Address (COA)

    • address of the current tunnel end-point for the MN (at FA or MN)

    • actual location of the MN from an IP point of view

    • can be chosen, e.g., via DHCP

    • Two types of addresses:

      • Foreign agent-based COA: The COA could be located at the FA.

      • Co-located COA: The COA is co-located if the MN acquired additional IP address which acts as COA.


Motivation for mobile ip6 l.jpg
Motivation for Mobile IP

Data Path for Foreign Agent Care-of Address

Data Path for Co-located Care-of Address


Motivation for mobile ip7 l.jpg
Motivation for Mobile IP

  • Problem: Routing

    • based on IP destination address, network prefix (e.g. 156.26.10) determines physical subnet

    • change of physical subnet implies change of IP address to have a topological correct address (standard IP) or needs special entries in the routing tables

  • Solution : Changing the IP-address?

    • adjust the host IP address depending on the current location

    • almost impossible to find a mobile system, DNS updates take to long time

    • TCP connections break, security problems

  • Solution: Specific routes to end-systems?

    • change of all routing table entries to forward packets to the right destination

    • does not scale with the number of mobile hosts and frequent changes in the location, .security problems


Example network l.jpg
Example network

HA

MN

Internet

router

home network

mobile end-system

(physical home network

for the MN)

FA

foreign network

router

(current physical network for the MN)

CN

end-system

router


Data transfer to the mobile system l.jpg
Data transfer to the mobile system

HA

2

MN

Internet

home network

3

receiver

foreign

network

FA

1. Sender sends to the IP address of MN,

HA intercepts packet (proxy ARP)

2. HA tunnels packet to COA, here FA,

by encapsulation

3. FA forwards the packet to the MN

1

CN

sender


Data transfer from the mobile system l.jpg
Data transfer from the mobile system

HA

1

MN

Internet

home network

sender

FA

foreignnetwork

1. Sender sends to the IP address of the receiver as usual, FA works as default router

CN

receiver


Overview l.jpg
Overview

COA

foreign

network

router

FA

MN

home

network

router

HA

Internet

CN

router

foreign

network

3.

router

FA

MN

home

network

router

HA

2.

4.

Internet

1.

CN

router


Mobile ip with reverse tunneling l.jpg
Mobile IP with Reverse Tunneling

  • Normally, the Mobile Node sends packets directly back to the Correspondent Node. But this might not work all the time.

    • Ingress filtering: Some routers filter those packets that don’t have the same network subnet as the network where those packets are sent. For example, Without a reverse tunnel a multicast packet sent from the MN will be filtered by the routers.

    • Firewalls: Most firewalls filter and drop packets that originate from outside the local network but appear has a source address that belongs to the local network. The packets sent to the home network might be dropped.

    • Time to live (TTL): TTL in the home network is correct, but might be too low because MN is to far away from the receiver.

  • Router accept often only “topological correct“ addresses (firewall!)

    • A packet from the MN encapsulated by the FA is not topological correct in a foreign network or home network.

    • Reverse tunnels are needed for the MN to participate in multicast .

    • TTL problems should be solved.


Mobile ip with reverse tunneling13 l.jpg
Mobile IP with reverse tunneling

  • With reverse tunneling, the Mobile Node sends packets back to the Correspondent Node through a tunnel between its Care-of Address and the Home Agent. The Home Agent then forwards the packet to the Correspondent Node.

  • Reverse tunneling does not solve

    • problems with firewalls, the reverse tunnel can be abused to circumvent security mechanisms (tunnel hijacking)

    • optimization of data paths, i.e. packets will be forwarded through the tunnel via the HA to a sender (double triangular routing)

  • The reverse tunneling standard

    • Define reverse tunneling as an extension to mobile IP.

    • Designed backwards-compatible to mobile IP

    • An option to mobile IP (RFC 3344)

    • The extensions can be implemented easily and cooperate with those implementations without these extensions.


Reverse tunneling rfc 3024 was 2344 l.jpg
Reverse tunneling (RFC 3024, was: 2344)

HA

2

MN

Internet

home network

1

sender

FA

foreignnetwork

1. MN sends to FA

2. FA tunnels packets to HA

by encapsulation

3. HA forwards the packet to the

receiver (standard case)

3

CN

receiver


Mobile ip with reverse tunneling15 l.jpg
Mobile IP with Reverse Tunneling

Return Data Path for Reverse Tunnelling with Direct Delivery Style

Return Data Path for Reverse Tunneling with Encapsulating Delivery Style


Network integration l.jpg
Network integration

  • Agent Advertisement

    • HA and FA periodically send advertisement messages into their physical subnets

    • MN listens to these messages and detects, if it is in the home or a foreign network (standard case for home network)

    • MN reads a COA from the FA advertisement messages

  • Agent solicitation

    • MN can search for an FA by sending out solicitation messages.

  • Registration (always limited lifetime!)

    • MN signals COA to the HA via the FA, HA acknowledges via FA to MN

    • these actions have to be secured by authentication

  • Integration

    • HA advertises the IP address of the MN (as for fixed systems), i.e. standard routing information

    • routers adjust their entries, these are stable for a longer time (HA responsible for a MN over a longer period of time)

    • packets to the MN are sent to the HA,

    • independent of changes in COA/FA


Agent advertisement l.jpg
Agent advertisement

  • Agent Advertisement

    • Use ICMP with mobility extension

Lifetime: length of time this advertisement is valid.

Preference helps a node choose the router

0

7

8

15

16

23

24

31

type

code

checksum

#addresses

addr. size

lifetime

router address 1

preference level 1

router address 2

preference level 2

type = 16

length = 6 + 4 * #COAs

R: registration required

B: busy, no more registrations

H: home agent

F: foreign agent

M: minimal encapsulation

G: GRE (Generic Routing Encapsulation)

r: =0, ignored (former Van Jacobson compression)

T: FA supports reverse tunneling

reserved: =0, ignored

. . .

type = 16

length

sequence number

T

registration lifetime

R

B

H

F

M

G

r

reserved

COA 1

. . .

COA 2


Registration l.jpg
Registration

MN

FA

HA

MN

HA

registration

request

registration

request

registration

request

registration

reply

registration

reply

t

registration

reply

t

  • The COA is at the FA

  • The COA is co-located in MN


Mobile ip registration request l.jpg

S

B

D

M

G

r

Mobile IP registration request

0

7

8

15

16

23

24

31

type = 1

T x

lifetime

home address

home agent

COA

identification

extensions . . .

S: simultaneous bindings

B: broadcast datagrams

D: decapsulation by MN

M mininal encapsulation

G: GRE encapsulation

r: =0, ignored

T: reverse tunneling requested

x: =0, ignored


Mobile ip registration reply l.jpg
Mobile IP registration reply

0

7

8

15

16

31

type = 3

code

lifetime

home address

home agent

identification

Example codes:

registration successful

0 registration accepted

1 registration accepted, but simultaneous mobility bindings unsupported

registration denied by FA

65 administratively prohibited

66 insufficient resources

67 mobile node failed authentication

68 home agent failed authentication

69 requested Lifetime too long

registration denied by HA

129 administratively prohibited

131 mobile node failed authentication

133 registration Identification mismatch

135 too many simultaneous mobility bindings

extensions . . .


Encapsulation l.jpg
Encapsulation

  • A tunnel establishes a virtual pipe between a tunnel entry and a tunnel endpoint.

  • Encapsulation is the mechanism of taking a packet consisting of packet header and data and putting it into the data part of a new packet.

  • Decapsulation is an operation that takes a packet out of the data part of another packet.

original IP header

original data

new IP header

new data

outer header

inner header

original data


Encapsulation 1 ip in ip encapsulation l.jpg
Encapsulation (1) (IP-in-IP encapsulation)

  • Encapsulation of one packet into another as payload

    • e.g. IPv6 in IPv4 (6Bone), Multicast in Unicast (Mbone)

    • here: e.g. IP-in-IP-encapsulation, minimal encapsulation or GRE (Generic Record Encapsulation)

  • IP-in-IP-encapsulation (mandatory, RFC 2003)

    • tunnel between HA and COA

ver.

IHL

DS (TOS)

length

IP identification

flags

fragment offset

TTL

IP-in-IP

IP checksum

IP address of HA

Care-of address COA

ver.

IHL

DS (TOS)

length

IP identification

flags

fragment offset

TTL

lay. 4 prot.

IP checksum

IP address of CN

IP address of MN

TCP/UDP/ ... payload


Encapsulation 2 minimal encapsulation l.jpg
Encapsulation (2) (Minimal encapsulation)

  • Minimal encapsulation (optional)

    • Avoid duplication of identical fields

    • e.g. TTL, IHL, version, DS (RFC 2474, old: TOS)

    • only applicable for unfragmented packets, no space left for fragment identification

ver.

IHL

DS (TOS)

length

IP identification

flags

fragment offset

TTL

min. encap.

IP checksum

IP address of HA

care-of address COA

lay. 4 protoc.

S

reserved

IP checksum

IP address of MN

original sender IP address (if S=1)

TCP/UDP/ ... payload


Generic routing encapsulation l.jpg

original

header

original data

outer header

GRE header

originalheader

original data

new header

new data

Generic Routing Encapsulation

  • Generic routing encapsulation (GRE) supports other network layer protocols in addition to IP.

  • GRE allows the encapsulation of packets of one protocol suite into the payload portion of a packet of another protocol suite.

RFC 1701

ver.

IHL

DS (TOS)

length

IP identification

flags

fragment offset

TTL

GRE

IP checksum

IP address of HA

Care-of address COA

C

R

K

S

s

rec.

rsv.

ver.

protocol

checksum (optional)

offset (optional)

key (optional)

sequence number (optional)

routing (optional)

ver.

IHL

DS (TOS)

length

RFC 2784

IP identification

flags

fragment offset

TTL

lay. 4 prot.

IP checksum

IP address of CN

C

reserved0

ver.

protocol

IP address of MN

checksum (optional)

reserved1 (=0)

TCP/UDP/ ... payload


Optimization of packet forwarding l.jpg
Optimization of packet forwarding

  • Triangular Routing

    • sender sends all packets via HA to MN

    • higher latency and network load

  • Solutions: the optimized mobile IP protocol

    • Sender (CN) learns the current location of MN

    • direct tunneling to this location

    • HA informs a sender about the location of MN

    • big security problems! Tunnel hijacking, location exposed

  • Route optimization

    • Binding cache: The CN can keep the mapping of MN’s IP address and COA in a cache.

    • Binding request and binding update: The CN can find the binding using a binding request message, to which the HA responds with a binding update message.

    • Binding acknowledgement: Conformation of binding.

    • Binding warning: In some cases, a handoff may occur, but CN may continue to use the old mapping.


Optimization of packet forwarding26 l.jpg
Optimization of packet forwarding

  • Any optimization scheme should try to ensure guaranteed delivery, low latency, and low overhead.

  • Simultaneous bindings is a feature of Mobile IP that allows an MN to register more than one COA at the same time, that is the HA allows MN to register more than one COA.

  • The mobile IP variations include four options for packets directed from the MN to the CN and four more options for packets from the CN to the MN. See Table 4.1 and 4.2.


Change of foreign agent l.jpg
Change of foreign agent

CN

HA

FAold

FAnew

MN

Data

Data

Data

Update

ACK

Data

Data

MN changeslocation

Registration

Update

ACK

Data

Data

Data

Warning

Request

Update

ACK

Data

Data

t


Handoffs l.jpg
Handoffs

  • A handoff is required when the MN changes its FA because the signal of the current FA becomes weak.

  • The typical phases involved in handoff are:

    • Measure the signal strength

    • Decide where and when to hand off

    • Establish a new connection

  • Classification of Handoffs:

    • Mobile initiated handoff: The MN measures the signal strength and decides the handoff.

    • Mobile evaluated handoff: The MN measures the signal strength but BS decides the handoff.

    • Network initiated handoff: the network (BS) measures the signal strength and decides where the MN should be handed over.

    • Mobile assisted handoff: The MN assists the network in the network initiated scenario by measuring the downlink signal strength.


Handoffs29 l.jpg
Handoffs

  • Classification of Handoffs:

    • Hard handoff: only one active connection at a time.

    • Soft handoff: two active connections during the handoff.

  • Signaling procedure-based handoffs:

    • Forward handoff: MN decides the target BS and requests the target BS for the handoff.

    • Backward handoff: MN decides the target BS and requests the current BS for the handoff.

  • Fast handoffs are required to reduce the delay.

    • Pre-registration handoffs: the registration with the HA takes place before the handoff while the MN is still attached to the old FA.

    • Post-registration handoffs: registration takes place after the MN is connected to the new FA.


Mobility support l.jpg
Mobility Support

  • The mobility management can be categorized into two types:

    • Macro-mobility protocols such as the Mobile IP deal with the inter-domain movement.

    • Micro-mobility protocols aim to handle local movement (intra-domain) of mobile hosts without interaction with the Mobile IP enabled Internet.

  • Micro-mobility is required to support:

    • Efficient local handover inside a foreign domain without involving a home agent

    • Reduces control traffic on backbone

    • Especially needed in case of route optimization

  • Micro-mobility approaches:

    • Handoff Aware Wireless Access Internet Architecture (HAWAII)

    • Cellular IP

    • Terminal Independent Mobility for IP (TIMIP)

    • Hierarchical Mobile IP (HMIP)

    • Hierarchical Mobile IPv6 (HMIPv6)

  • Important criteria: Security Efficiency, Scalability, Transparency, Manageability


Macro and micro mobility l.jpg

Home Agent

Macro mobility by Mobile IP

Home Network

INTERNET

FA

Gateway

as FA

Macro-mobility

handover

Micro mobility

domain

Micro-mobility

handover

Handovers in Micro Mobility transparent outside the domain

Macro and Micro mobility


Hierarchical architecture l.jpg
Hierarchical Architecture

  • Elements in different levels

    • Access router (AR)

      • A number of access routers organize access network

      • Each router incorporates mobility management functions

    • Access point (AP)

      • An AR that directly communicates with the mobile terminals at the radio interface

    • Access Network Gateway (ANG)

      • The root AR, interfacing with the core IP network

      • Perform mobility management functions to support MobileIP-based macromobility

    • Mobile terminal (MT)

      • Runs the user applications

      • Roaming between different APs


Mobile ip and ipv6 l.jpg
Mobile IP and IPv6

  • Mobile IP was developed for IPv4, but IPv6 simplifies the protocols

    • security is integrated and not an add-on, authentication of registration is included

    • COA can be assigned via auto-configuration (DHCPv6 is one candidate), every node has address auto-configuration

    • no need for a separate FA, all routers perform router advertisement which can be used instead of the special agent advertisement; addresses are always co-located

    • MN can signal a sender directly the COA, sending via HA not needed in this case (automatic path optimization)

    • “soft“ hand-over, i.e. without packet loss, between two subnets is supported

      • MN sends the new COA to its old router

      • the old router encapsulates all incoming packets for the MN and forwards them to the new COA

      • authentication is always granted


Hawaii l.jpg

Internet

HA

Backbone

Router

Crossover

Router

2

Mobile IP

4

BS

BS

DHCP

Server

Mobile IP

MN

MN

DHCP

1

HAWAII

  • Operation:

    • MN obtains co-located COAand registers with HA

    • Handover: MN keeps COA,new BS answers Reg. Requestand updates routers

    • MN views BS as foreign agent

  • Security provisions:

    • MN-FA authentication mandatory

    • Challenge/Response Extensions mandatory

1

2

3

4

BS

3


Hawaii security l.jpg
HAWAII: Security

  • Advantages:

    • Mutual authentication and Challenge/Response extensions mandatory

    • Only infrastructure components can influence routing entries

  • Potential problems:

    • Co-located COA raises DHCP security issues (DHCP has no strong authentication)

    • Decentralized security-critical functionality(Mobile IP registration processing during handover) in base stations

    • Authentication of HAWAII protocol messages unspecified(potential attackers: stationary nodes in foreign network)

    • MN authentication requires PKI (Public Key Infrastructure) or AAA (Authentication, Authorization, and Accounting) infrastructure


Hawaii other issues l.jpg
HAWAII: Other issues

  • Advantages:

    • Transparency: Mostly transparent to MNs(MN sends/receives standard Mobile IP messages)

    • Explicit support for dynamically assigned home addresses

  • Disadvantages:

    • Mixture of co-located COA and FA concepts may not be supported by some MN implementations

    • No private address support possible because of co-located COA


Cellular ip l.jpg

Internet

Mobile IP

CIP Gateway

data/control

packets

from MN 1

BS

BS

BS

packets from

MN2 to MN 1

MN1

MN2

Cellular IP

  • Operation:

    • CIP node (gateway) maintains routing entries (soft state) for MNs

    • Multiple entries possible

    • Routing entries updated based on packets sent by MN

  • CIP (Cellular IP) Gateway:

    • Mobile IP tunnel endpoint

    • Initial registration processing

  • Security provisions:

    • all CIP Nodes share“network key“

    • MN key: MD5(net key, IP addr)

    • MN gets key upon registration


Cellular ip security l.jpg
Cellular IP: Security

  • Advantages:

    • Initial registration involves authentication of MNs and is processed centrally by CIP Gateway

    • All control messages by MNs are authenticated

    • Replay-protection (using timestamps)

  • Potential problems:

    • MNs can directly influence routing entries

    • Network key known to many entities (increases risk of compromise)

    • No re-keying mechanisms for network key

    • No choice of algorithm (always MD5, prefix+suffix mode)

    • Proprietary mechanisms (not, e.g., IPSec AH)


Cellular ip other issues l.jpg
Cellular IP: Other issues

  • Advantages: Manageability

    • Simple and elegant architecture

    • Mostly self-configuring (little management needed)

    • Integration with firewalls / private address support possible

  • Disadvantages:

    • Efficiency: Multiple-path forwarding may cause inefficient use of available bandwidth

    • Transparency: Not transparent to MNs (additional control messages)

    • Security: Public-key encryption of MN keys may be a problemfor resource-constrained MNs


Timip l.jpg
TIMIP

  • Terminal Independent Mobility for IP (TIMIP)

    • An Architecture for IP mobility in wireless access networks

    • Based on principles similar to those in the HAWAII and Cellular IP architectures

    • Suited for micro-mobility scenarios

    • using Mobile IP for macro-mobility

  • TIMIP can be implemented in the network nodes and work transparently to the IP layer of the terminals

  • Micro-mobility: Whenever the MN moves within the same TIMIP domain, the route updates and the corresponding acknowledgements will propagate up the hierarchy until the crossover AR is reached.

  • Macro-mobility: Similar to Cellular IP and HAWAII, TIMIP relies solely on Mobile IP to support macro-mobility.


Timip architecture l.jpg

Tunneling

Tunneling

TIMIP architecture

Accessrouter(level 2)

Corenetwork

Accesspoint(level 1)

Accessrouter(level n-x)

Accessnetworkgateway

(level n)

Accessrouter(level 2)

Accesspoint(level 1)


Hierarchical mobile ipv6 hmipv6 l.jpg

Internet

Hierarchical Mobile IPv6 (HMIPv6)

  • Operation:

    • Network contains mobility anchor point (MAP)

      • mapping of regional COA (RCOA) to link COA (LCOA)

    • Upon handover, MN informs MAP only

      • gets new LCOA, keeps RCOA

    • HA is only contacted if MAP changes

  • Security provisions:

    • no HMIP-specific security provisions

    • binding updates should be authenticated

HA

RCOA

MAP

binding

update

AR

AR

LCOAold

LCOAnew

MN

MN


Hierarchical mobile ip security l.jpg
Hierarchical Mobile IP: Security

  • Advantages:

    • Local COAs can be hidden, which provides some location privacy

    • Direct routing between CNs sharing the same link is possible (but might be dangerous)

  • Potential problems:

    • Decentralized security-critical functionality (handover processing) in mobility anchor points

    • MNs can (must!) directly influence routing entries via binding updates (authentication necessary)


Hierarchical mobile ip other issues l.jpg
Hierarchical Mobile IP: Other issues

  • Advantages:

    • Handover requires minimum number of overall changes to routing tables

    • Integration with firewalls / private address support possible

  • Potential problems:

    • Not transparent to MNs

    • Handover efficiency in wireless mobile scenarios:

      • Complex MN operations

      • All routing reconfiguration messages sent over wireless link


Problems with mobile ip l.jpg
Problems with mobile IP

  • Security Problems

    • Registration request by a malicious node

    • Replay attacks

    • Tunnel hijacking

    • A FA can itself be a malicious node.

    • Authentication with FA problematic, for the FA typically belongs to another organization

    • Patent and export restrictions

    • IETF is working on the protocol for key management and key distribution has been standardized in the Internet.

  • Firewalls

    • typically mobile IP cannot be used together with firewalls, special set-ups are needed (such as reverse tunneling)

  • QoS

    • many new reservations in case of RSVP (Resource reSerVation Protocol)

    • tunneling makes it hard to give a flow of packets a special treatment needed for the QoS

  • Security, firewalls, QoS etc. are topics of current research and discussions!


Security in mobile ip l.jpg
Security in Mobile IP

  • Security requirements (Security Architecture for the Internet Protocol, RFC 1825)

    • Integrityany changes to data between sender and receiver can be detected by the receiver

    • Authenticationsender address is really the address of the sender and all data received is really data sent by this sender

    • Confidentialityonly sender and receiver can read the data

    • Non-Repudiation (Non-Denial of the message previously sent)

      • sender cannot deny sending of data (The sender can prove that the message was in fact received by the alleged receiver.)

      • The receiver can prove that the message was in fact sent by the alleged sender.

    • Traffic Analysiscreation of traffic and user profiles should not be possible

    • Replay Protectionreceivers can detect replay of messages


Ip security architecture 1 l.jpg

IP-Header

IP header

Authentification-Header

authentication header

UDP/TCP-Paket

UDP/TCP data

not encrypted

encrypted

IP security architecture (1)

  • Two or more partners have to negotiate security mechanisms to setup a security association

    • typically, all partners choose the same parameters and mechanisms

  • Two headers have been defined for securing IP packets:

    • Authentication-Header

      • guarantees integrity and authenticity of IP packets

      • if asymmetric encryption schemes are used, non-repudiation can also be guaranteed

    • Encapsulation Security Payload

      • protects confidentiality between communication partners

IP header

ESP header

encrypted data


Ip security architecture 2 l.jpg
IP security architecture (2)

  • Mobile Security Association for registrations

    • parameters for the mobile host (MH), home agent (HA), and foreign agent (FA)

  • Extensions of the IP security architecture

    • extended authentication of registration

    • prevention of replays of registrations

      • time stamps: 32 bit time stamps + 32 bit random number

      • nonces: 32 bit random number (MH) + 32 bit random number (HA)

MH-FA authentication

FA-HA authentication

MH-HA authentication

registration request

MH

FA

registration request

HA

registration reply

registration reply


Key distribution l.jpg
Key distribution

  • Home agent distributes session keys

  • foreign agent has a security association with the home agent

  • mobile host registers a new binding at the home agent

  • home agent answers with a new session key for foreign agent and mobile node

FA

MH

response:

EHA-FA {session key}

EHA-MH {session key}

HA


Mrsvp resource reservation l.jpg
MRSVP – Resource Reservation

  • The current Resource reSerVation Protocol (RSVP) is not adequate for mobile and wireless networks.

  • Mobility-aware RSVP protocols:

    • Require that an MN must be able to make advance reservations along data flow paths.

    • Have information on the set of locations from which the MN requires reservations, mobility specification (MSPEC).

    • Two types of reservations:

      • Active: an active reservation is a normal RSVP-like reservation that is on the data flow path from the current location of the MN.

      • Passive: A passive reservation is made along all paths to and from other locations in MSPEC of the MN.

  • Components in MRSVP:

    • Proxy agents (PAs) make reservations on behalf of mobile senders and receivers.

      • A local proxy agent (LPA) is that to which the MN is currently attached.

      • Every other agent in the MSPEC will be a remote proxy agent (RPA).


Mrsvp resource reservation51 l.jpg
MRSVP – Resource Reservation

  • MRSVP Schemes:

    • The sender periodically generates ACTIVE PATH messages, and for a mobile sender the Pas will send PASSIVE PATH messages.

    • The PAs for a mobile receiver send the PASSIVE RESV messages while the receiver itself sends the ACTIVE RESV message.

  • The key issues:

    • The identification of proxy agents perform the reservations on behalf of an MN.

    • The identification of flow anchors, a senderAnchor act as fixed points in the flow path.

    • The establishment of both active and passive reservations for the MN according to the MSPEC.

    • The actual message sequences that lead to the reservation depend on the type of the follow and the strategy adopted.


Dhcp dynamic host configuration protocol l.jpg
DHCP: Dynamic Host Configuration Protocol

  • Application

    • simplification of installation and maintenance of networked computers

    • supplies systems with all necessary information, such as IP address, DNS server address, domain name, subnet mask, default router etc.

    • enables automatic integration of systems into an Intranet or the Internet, can be used to acquire a COA for Mobile IP

  • Client/Server-Model

    • the client sends via a MAC broadcast a request to the DHCP server (might be via a DHCP relay)

DHCPDISCOVER

DHCPDISCOVER

server

client

client

relay


Dhcp protocol mechanisms l.jpg
DHCP - Protocol Mechanisms

client

server

(not selected)

server

(selected)

initialization

DHCPDISCOVER

DHCPDISCOVER

determine the

configuration

determine the

configuration

DHCPOFFER

DHCPOFFER

collection of replies

selection of configuration

time

DHCPREQUEST(reject)

DHCPREQUEST(options)

confirmation of

configuration

DHCPACK

initialization completed

release

DHCPRELEASE

delete context


Dhcp characteristics l.jpg
DHCP Characteristics

  • Server

    • several servers can be configured for DHCP, coordination not yet standardized (i.e., manual configuration)

  • Renewal of configurations

    • IP addresses have to be requested periodically, simplified protocol

  • Options

    • available for routers, subnet mask, NTP (network time protocol) timeserver, SLP (service location protocol) directory, DNS (domain name system)

  • Big security problems!

    • no authentication of DHCP information specified


Mobile ad hoc networks l.jpg
Mobile ad hoc networks

  • Standard Mobile IP needs an infrastructure

    • Home Agent/Foreign Agent in the fixed network

    • DNS, routing etc. are not designed for mobility

  • Sometimes there is no infrastructure!

    • remote areas, ad-hoc meetings, disaster areas

    • cost can also be an argument against an infrastructure!

  • Main topic: routing

    • no default router available

    • every node should be able to forward

A

B

C


Manet mobile ad hoc networking l.jpg

Mobile

Router

Manet

Mobile

Devices

Mobile IP,

DHCP

Fixed

Network

Router

End system

Manet: Mobile Ad-hoc Networking


Transport layer l.jpg
Transport layer

  • Functions of Transport layer:

    • Provide point-to-point communication (process to process)

    • Multiplex/de-multiplex data from/to applications.

    • determine the service to the session layer

      • TCP (Transmission Control Protocol) – connection-oriented, in-order reliable data transmission

      • UDP (User Datagram Protocol) – connectionless, unreliable data transmission.

  • TCP Examples:

    • SMTP (Simple Mail Transfer Protocol) – electronic mail

    • Telnet (remote login)

    • FTP (File Transfer Protocol)

    • HTTP (HyperText Transfer Protocol)

    • NNTP (Network News Transfer Protocol)

    • BGP (Border Gateway Protocol) – routing


Transport layer examples l.jpg
Transport Layer Examples

  • E.g. HTTP (used by web services) typically uses TCP

    • Reliable transport between client and server required

  • TCP

    • Steam oriented, not transaction oriented

    • Network friendly: time-out  congestion  slow down transmission

  • Well known – TCP guesses quite often wrong in wireless and mobile networks

    • Packet loss due to transmission errors

    • Packet loss due to change of network

  • Result

    • Severe performance degradation

Client

Server

TCP SYN

TCP SYN/ACK

Connection

setup

TCP ACK

HTTP request

Data

transmission

HTTP response

>15 s

no data

GPRS: 500ms!

Connection

release


Traditional tcp 1 l.jpg
Traditional TCP (1)

  • Transport protocols typically designed for

    • Fixed end-systems

    • Fixed, wired networks

  • Research activities

    • Performance

    • Congestion control

    • Efficient retransmissions

  • TCP congestion control

    • packet loss in fixed networks is typically due to (temporary) overload situations

    • router have to discard packets as soon as the buffers are full

    • TCP recognizes congestion only indirect via missing acknowledgements, retransmissions unwise, they would only contribute to the congestion and make it even worse

    • slow-start algorithm as reaction


Traditional tcp 2 l.jpg
Traditional TCP (2)

  • TCP slow-start algorithm

    • sender calculates a congestion window for a receiver

    • start with a congestion window size equal to one segment

    • exponential increase of the congestion window up to the congestion threshold, then linear increase

    • missing acknowledgement causes the reduction of the congestion threshold to one half of the current congestion window

    • congestion window starts again with one segment

  • TCP fast retransmit/fast recovery

    • TCP sends an acknowledgement only after receiving a packet

    • if a sender receives several acknowledgements for the same packet, this is due to a gap in received packets at the receiver (So the receiver keeps acknowledging the same packet.)

    • however, the receiver got all packets up to the gap and is actually receiving packets

    • therefore, packet loss is not due to congestion, continue with current congestion window (do not use slow-start)

    • The sender then performs fast retransmission and a fast recovery.


Tcp over wireless l.jpg
TCP Over Wireless

  • TCP assumes congestion if packets are dropped

    • typically wrong in wireless networks, here we often have packet loss due to transmission errors

    • furthermore, mobility itself can cause packet loss, if e.g. a mobile node roams from one access point (e.g. foreign agent in Mobile IP) to another while there are still packets in transit to the wrong access point and forwarding is not possible

  • The performance of an unchanged TCP degrades severely

    • however, TCP cannot be changed fundamentally due to the large base of installation in the fixed network, TCP for mobility has to remain compatible

    • the basic TCP mechanisms keep the whole Internet together


Tcp over wireless62 l.jpg
TCP Over Wireless

Snoop TCP

TCP over Wireless

Split approach

based solutions

Link layer

solutions

End-to-end

solutions

I-TCP

ELN

M-TCP

WTCP

TCP-unaware

link layer

TCP SACK

TTCP


Early approach snooping tcp 1 l.jpg
Early approach: Snooping TCP (1)

  • “Transparent“ extension of TCP within the foreign agent

    • buffering of packets sent to the mobile node

    • lost packets on the wireless link (both directions!) will be retransmitted immediately by the mobile node or base station (foreign agent), respectively (so called “local” retransmission)

    • the foreign agent therefore “snoops” the packet flow and recognizes acknowledgements in both directions, it also filters ACKs

    • changes of TCP only within the foreign agent

correspondent

node (host)

local retransmission

Foreign agent

(base station)

“wired“ Internet

snooping of ACKs

buffering of data

mobile

node (host)

end-to-end TCP connection


Snooping tcp 2 l.jpg
Snooping TCP (2)

  • Data transfer to the mobile host

    • FA buffers data until it receives ACK of the MH, FA detects packet loss via duplicated ACKs (DUPACKs) or time-out

    • fast retransmission possible, transparent for the fixed network

  • Data transfer from the mobile host

    • FA detects packet loss on the wireless link via sequence numbers, FA answers directly with a NACK to the MH

    • MH can now retransmit data with only a very short delay

  • Integration of the MAC layer

    • MAC layer often has similar mechanisms to those of TCP

    • thus, the MAC layer can already detect duplicated packets due to retransmissions and discard them

  • Problems

    • snooping TCP does not isolate the wireless link as good as I-TCP

    • snooping might be useless depending on encryption schemes


Tcp unaware link layer l.jpg
TCP-Unaware Link Layer

  • This strategy aims at simulating the behavior of the snoop-TCP protocol without requiring the link layer at the BS to be TCP-aware.

  • The usage of delayed duplicate acknowledgements (DUPACKs) imitates snoop-TCP without requiring the link layer at BS to be TCP-aware.

  • In snoop-TCP retransmissions are triggered by TCP duplicate acknowledgements, but in TCP-unaware link layer retransmissions are triggered by link level ACKs.

  • Advantage: The link layer needs not be TCP-aware.

  • Disadvantage: The optimum value of duplicate acknowledgements delay depends on the wireless link, and this value is crucial in determining the performance.


Indirect tcp 1 l.jpg
Indirect TCP (1)

  • Indirect TCP or I-TCP segments the connection

    • no changes to the TCP protocol for hosts connected to the wired Internet, millions of computers use (variants of) this protocol

    • optimized TCP protocol for mobile hosts

    • splitting of the TCP connection at, e.g., the foreign agent into 2 TCP connections, no real end-to-end connection any longer

    • hosts in the fixed part of the network do not notice the characteristics of the wireless part

mobile node (host)

„wired“ Internet

access point

(foreign agent)

standard TCP

„wireless“ TCP


I tcp socket and state migration l.jpg
I-TCP Socket and State Migration

access point1

socket migration

and state transfer

Internet

access point2

mobile host

  • The old access point acts as a foreign agent buffering and forwarding the packets to the new access point (foreign agent)


Indirect tcp 2 l.jpg
Indirect TCP (2)

  • Advantages

    • no changes in the fixed network necessary, no changes for the hosts (TCP protocol) necessary, all current optimizations to TCP still work

    • transmission errors on the wireless link do not propagate into the fixed network

    • simple to control, mobile TCP is used only for one hop between, e.g., a foreign agent and mobile host

    • therefore, a very fast retransmission of packets is possible, the short delay on the mobile hop is known

  • Disadvantages

    • loss of end-to-end semantics, now an acknowledgement to a sender does not any longer mean that a receiver really got a packet, foreign agents might crash

    • higher latency possible due to buffering of data within the foreign agent and forwarding to a new foreign agent


Mobile tcp l.jpg
Mobile TCP

  • Special handling of lengthy and/or frequent disconnections

  • M-TCP splits as I-TCP does

    • unmodified TCP fixed network to supervisory host (SH)

    • optimized TCP SH to MN

  • Supervisory host (the node in the wired network that controls a number of APs)

    • no caching, no retransmission

    • monitors all packets, if disconnection detected

      • set sender window size to 0

      • sender automatically goes into persistent mode (the state of the sender will not change no matter how long the receiver is disconnected.)

    • old or new SH reopen the window

  • Advantages

    • maintains semantics, supports disconnection, no buffer forwarding

  • Disadvantages

    • loss on wireless link propagated into fixed network

    • adapted TCP on wireless link


Explicit loss notification eln l.jpg
Explicit Loss Notification - ELN

  • The problem with TCP lies in the fact that it does not know the exact cause for packet loss, and hence has to invariably assume congestion loss.

  • In this situation an idea TCP simply retransmit the lost packet without congestion control mechanism.

  • The strategy is to detect loss at MN and send an explicit loss notification (ELN) to the sender.

  • The sender does not reduce the window size on receiving ELN. This avoids slow start and can handle encrypted data.

  • Disadvantage: This protocol requires the MAC layer of MN to be changed. The information conveyed by the MAC layer might not always be reliable.


Slide71 l.jpg
WTCP

  • WTCP (Reliable Transport Protocol for Wireless Wide-Area Networks) aims at revamping the transport protocol for the wireless domain using:

    • Rate-based transmission at the source

    • Inter-packet separation at the receiver as the congestion metric

    • Mechanisms for detecting the reason for packet loss

    • Bandwidth estimation

  • A unique characteristic of WTCP is the attempt to separate the congestion control and reliability mechanisms.

  • WTCP uses separate sequence numbers for congestion control and reliability mechanisms in order to distinguish the two.

  • The reliability mechanism involves a combination of selective and cumulative acknowledgements, and takes into account the reserve-path characteristics for determining the ACK frequency.


Tcp sack selective retransmission l.jpg
TCP SACK – Selective Retransmission

  • TCP acknowledgements are often cumulative

    • ACK n acknowledges correct and in-sequence receipt of packets up to n

    • if single packets are missing quite often a whole packet sequence beginning at the gap has to be retransmitted (go-back-n), thus wasting bandwidth

  • Selective retransmission as one solution – TCP with selective ACK (TCP SACK)

    • RFC2018 allows for acknowledgements of single packets, not only acknowledgements of in-sequence packet streams without gaps

    • sender can now retransmit only the missing packets

  • Advantage

    • much higher efficiency

  • Disadvantage

    • more complex software in a receiver, more buffer needed at the receiver


Transaction oriented tcp l.jpg
Transaction-Oriented TCP

  • TCP phases

    • connection setup, data transmission, connection release

    • using 3-way-handshake needs 3 packets for setup and release, respectively

    • thus, even short messages need a minimum of 7 packets!

  • Transaction oriented TCP

    • RFC1644, T-TCP, describes a TCP version to avoid this overhead

    • connection setup, data transfer and connection release can be combined

    • thus, only 2 or 3 packets are needed

  • Advantage

    • efficiency

  • Disadvantage

    • requires changed TCP

    • mobility not longer transparent


Impact of mobility fast retransmit fast recovery l.jpg
Impact of Mobility – Fast Retransmit/Fast Recovery

  • Change of foreign agent often results in packet loss

    • TCP reacts with slow-start although there is no congestion

  • Forced fast retransmit

    • as soon as the mobile host has registered with a new foreign agent, the MH sends duplicated acknowledgements on purpose

    • this forces the fast retransmit mode at the communication partners

    • additionally, the TCP on the MH is forced to continue sending with the actual window size and not to go into slow-start after registration

  • Advantage

    • simple changes result in significant higher performance

  • Disadvantage

    • further mix of IP and TCP, no transparent approach


Transmission time out freezing l.jpg
Transmission/Time-out Freezing

  • Mobile hosts can be disconnected for a longer time

    • no packet exchange possible, e.g., in a tunnel, disconnection due to overloaded cells or multiplexed with higher priority traffic

    • TCP disconnects after time-out completely

  • TCP freezing

    • MAC layer is often able to detect interruption in advance

    • MAC can inform TCP layer of upcoming loss of connection

    • TCP stops sending, but does now not assume a congested link

    • MAC layer signals again if reconnected

  • Advantage

    • scheme is independent of data

  • Disadvantage

    • TCP on mobile host has to be changed, mechanism depends on MAC layer



Tcp improvements 1 l.jpg
TCP Improvements (1)

  • Initial research work

    • Indirect TCP, Snoop TCP, M-TCP, T/TCP, SACK,

      Transmission/time-out freezing, …

  • TCP over 2.5/3G wireless networks

    • Fine tuning today’s TCP

    • Learn to live with

      • Data rates: 64 kbit/s up, 115-384 kbit/s down; asymmetry: 3-6, but also up to 1000 (broadcast systems), periodic allocation/release of channels

      • High latency, high jitter, packet loss

    • Suggestions

      • Large (initial) sending windows, large maximum transfer unit, selective acknowledgement, explicit congestion notification, time stamp, no header compression

    • Already in use

      • i-mode running over FOMA

      • WAP 2.0 (“TCP with wireless profile”)

  • max. TCP BandWidth

  • Max. Segment Size

  • Round Trip Time

  • loss probability


Tcp improvements 2 l.jpg
TCP Improvements (2)

Mobile system

  • Performance enhancing proxies (PEP, RFC 3135)

    • Transport layer

      • Local retransmissions and acknowledgements

    • Additionally on the application layer

      • Content filtering, compression, picture downscaling

      • E.g., Internet/WAP gateways

      • Web service gateways?

    • Big problem: breaks end-to-end semantics

      • Disables use of IP security

      • Choose between PEP and security!

  • More open issues

    • RFC 3150 (slow links)

      • Recommends header compression, no timestamp

    • RFC 3155 (links with errors)

      • States that explicit congestion notification cannot be used

    • In contrast to 2.5G/3G recommendations!

wireless

PEP

Internet

Comm. partner


Wap wireless application protocol l.jpg
WAP - Wireless Application Protocol

  • WAP (Wireless Application Protocol)

    • a specification for a set of communication protocols to standardize the way that wireless devices, such as cellular telephones and radio transceivers, can be used for Internet access, including e-mail, the World Wide Web, newsgroups, and Internet Relay Chat (IRC).

  • Goals

    • deliver Internet content and enhanced services to mobile devices and users (mobile phones, PDAs)

    • independence from wireless network standards

    • open for everyone to participate, protocol specifications will be proposed to standardization bodies

    • applications should scale well beyond current transport media and device types and should also be applicable to future developments

  • Platforms

    • e.g., GSM (900, 1800, 1900), CDMA IS-95, TDMA IS-136, 3rd generation systems (IMT-2000, UMTS, W-CDMA, cdma2000 1x EV-DO, …)


Wap scope of standardization l.jpg
WAP - scope of standardization

  • Forum

    • was: WAP Forum, co-founded by Ericsson, Motorola, Nokia, Unwired Planet, further information www.wapforum.org

    • now: Open Mobile Alliance www.openmobilealliance.org(Open Mobile Architecture + WAP Forum + SyncML + …)

  • Browser

    • “micro browser”, similar to existing, well-known browsers in the Internet

  • Script language

    • similar to Java script, adapted to the mobile environment

  • WTA/WTAI

    • Wireless Telephony Application (Interface): access to all telephone functions

  • Content formats

    • e.g., business cards (vCard), calendar events (vCalender)

  • Protocol layers

    • transport layer, security layer, session layer etc.


Wae logical model l.jpg
WAE logical model

Origin Servers

Gateway

Client

WTA

user agent

web

server

response

with

content

encoded

response

with

content

encoders

&

decoders

WML

user agent

other content

server

push

content

encoded

push

content

other

WAE

user agents

request

encoded

request

  • WAP adopts a client-server approach.

  • It specifies a proxy server that acts as an interface between the wireless domain and core wired network.


Wap 1 x reference model and protocols l.jpg
WAP 1.x - reference model and protocols

Internet

WAP

A-SAP

HTML, Java

Application Layer (WAE)

additional services and applications

S-SAP

HTTP

Session Layer (WSP)

TR-SAP

Transaction Layer (WTP)

SEC-SAP

SSL/TLS

Security Layer (WTLS)

T-SAP

TCP/IP,

UDP/IP,

media

Transport Layer (WDP)

WCMP

Bearers (GSM, CDPD, ...)

WAE comprises WML (Wireless Markup Language), WML Script, WTAI etc.


Slide83 l.jpg
WAP

  • The Wireless Application Environment (WAE) - Application layer

    • a general-purpose application environment based on a combination of World Wide Web (WWW) and mobile telephony technologies. WAE includes a micro-browser environment containing the following functionalities:

      • Wireless Markup Language (WML) A lightweight markup language, similar to HTML, but optimized for use in hand-held mobile terminals;

      • WMLScript A lightweight scripting language, similar to JavaScript

      • Wireless Telephony Application (WTA) Telephony services and programming interfaces.

  • Wireless Session Protocol (WSP) - Session layer

    • gives the functionality of HTTP but in a more optimized way.

  • Wireless Transaction Protocol (WTP) – Session layer

    • runs on top of a datagram service and provides as a light-weight transaction-oriented protocol.

  • Wireless Transport Layer Security (WTLS) – Transport layer

    • a security protocol analogous to the industry-standard Transport Layer Security (TLS) protocol, formerly known as Secure Sockets Layer (SSL) in WWW model.

  • Wireless Datagram Protocol (WDP) – Transport layer

    • The Transport layer protocol in the WAP architecture is referred to as the Wireless Datagram Protocol (WDP).


Wap network elements l.jpg
WAP - network elements

fixed network

wireless network

Internet

WAP

proxy

WML

Binary WML

HTML

filter

WML

HTML

HTML

filter/

WAP

proxy

Binary WML

web

server

HTML

WTA

server

Binary WML

PSTN

Binary WML: binary file format for clients


Wdp wireless datagram protocol l.jpg
WDP - Wireless Datagram Protocol

  • Protocol of the transport layer within the WAP architecture

    • uses directly transports mechanisms of different network technologies

    • offers a common interface for higher layer protocols

    • allows for transparent communication using different transport technologies (GSM [SMS, CSD, USSD, GPRS, ...], IS-136, TETRA, DECT, PHS, IS-95, ...)

  • Goals of WDP

    • create a worldwide interoperable transport system with the help of WDP adapted to the different underlying technologies

    • transmission services such as SMS, GPRS in GSM might change, new services can replace the old ones

  • Additionally, WCMP (wireless Control Message Protocol) is used for control/error report (similar to ICMP in the TCP/IP protocol suite)


Usage of wdp l.jpg
Usage of WDP

Wireless Data Gateway

WTLS

WTLS

GSM-SMS

GSM-CSD

WDP &

Adaptation

WDP &

Adaptation

SMS

SMS

Tunnel

Tunnel

Subnetwork

Subnetwork

WAP

Proxy

WTLS

WTLS

Internet Service Provider

Remote Access Service

UDP

UDP

IP

IP

IP

Interworking

Function

PPP

PPP

Subnetwork

Subnetwork

CSD-RF

CSD-RF

PSTN

Circuit

PSTN

Circuit

  • GSM-CSD (GSM Circuit Switched Data)


Wtls wireless transport layer security l.jpg
WTLS - Wireless Transport Layer Security

  • Goals

    • data integrity

      • prevention of changes in data

    • privacy

      • prevention of tapping

    • authentication

      • creation of authenticated relations between a mobile device and a server

    • protection against denial-of-service attacks

      • protection against repetition of data and unverified data

  • WTLS

    • is based on the TLS (Transport Layer Security) protocol (former SSL, Secure Sockets Layer)

    • optimized for low-bandwidth communication channels


Wtp wireless transaction protocol l.jpg
WTP - Wireless Transaction Protocol

  • Goals

    • different transaction services, offloads applications

      • application can select reliability, efficiency

    • support of different communication scenarios

      • class 0: unreliable message transfer

      • class 1: reliable message transfer without result message

      • class 2: reliable message transfer with exactly one reliable result message

    • supports peer-to-peer, client/server and multicast applications

    • low memory requirements, suited to simple devices (< 10kbyte )

    • efficient for wireless transmission

      • segmentation/reassembly

      • selective retransmission

      • header compression

      • optimized connection setup (setup with data transfer)


Details of wtp 1 l.jpg
Details of WTP (1)

  • Support of different communication scenarios

    • Class 0: unreliable message transfer

      • Example: push service

    • Class 1: reliable request

      • An invoke message is not followed by a result message

      • Example: reliable push service

    • Class 2: reliable request/response

      • An invoke message is followed by exactly one result message

      • With and without ACK

      • Example: typical web browsing

  • No explicit connection setup or release is available

  • Services for higher layers are called events


Details of wtp 2 l.jpg
Details of WTP (2)

  • Used Mechanisms

    • Reliability

      • Unique transaction identifiers (TID)

      • Acknowledgements

      • Selective retransmission

      • Duplicate removal

    • Optional: concatenation & separation of messages

    • Optional: segmentation & reassembly of messages

    • Asynchronous transactions

    • Transaction abort, error handling

    • Optimized connection setup (includes data transmission)


Wsp wireless session protocol l.jpg
WSP - Wireless Session Protocol

  • Goals

    • HTTP 1.1 functionality

      • Request/reply, content type negotiation, ...

    • support of client/server, transactions, push technology

    • key management, authentication, Internet security services

    • session management (interruption, resume,...)

  • Open topics

    • QoS support)

    • Group communication

    • Isochronous media objects

    • management


Wsp protocols l.jpg
WSP protocols

WSP

Connection mode

(uses WTP)

Connectionless mode

(uses WDP or WTLS)

  • Session Management (class 0, 2)

  • Method Invocation (Kl. 2)

  • Error Report

  • Push (class 0)

  • Confirmed Push (class 1)

  • Session suspend/resume (class 0, 2)

  • Method Invocation

  • Push

  • (in general unreliable)


Wae wireless application environment l.jpg
WAE - Wireless Application Environment

  • Goals

    • network independent application environment for low-bandwidth, wireless devices

    • integrated Internet/WWW programming model with high interoperability

  • Requirements

    • device and network independent, international support

    • manufacturers can determine look-and-feel, user interface

    • considerations of slow links, limited memory, low computing power, small display, simple user interface (compared to desktop computers)

  • Components

    • architecture: application model, browser, gateway, server

    • WML: XML-Syntax, based on card stacks, variables, ...

    • WMLScript: procedural, loops, conditions, ... (similar to JavaScript)

    • WTA: telephone services, such as call control, text messages, phone book, ... (accessible from WML/WMLScript)

    • content formats: vCard, vCalendar, Wireless Bitmap, WML, ...


Wireless markup language wml l.jpg
Wireless Markup Language (WML)

  • WML (Wireless Markup Language) is a language that allows the text portions of Web pages to be presented on cellular telephones and personal digital assistants (PDAs) via wireless access.

  • WML follows deck and card metaphor

    • WML document consists of many cards, cards are grouped to decks

    • a deck is similar to an HTML page, unit of content transmission

    • WML describes only intent of interaction in an abstract manner

    • presentation depends on device capabilities

  • Features

    • text and images

    • user interaction

    • navigation

    • context management


Wml example 1 l.jpg
WML – example (1)

<?xml version="1.0"?>

<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"

"http://www.wapforum.org/DTD/wml_1.1.xml">

<wml>

<card id="card_one" title="simple example">

<do type="accept">

<go href="#card_two"/>

</do>

<p>

This is a simple first card!

<br/>

On the next one you can choose ...

</p>

</card>


Wml example 2 l.jpg
WML – example (2)

<card id="card_two" title="Pizza selection">

<do type="accept" label="cont">

<go href="#card_three"/>

</do>

<p>

... your favorite pizza!

<select value="Mar" name="PIZZA">

<option value="Mar">Margherita</option>

<option value="Fun">Funghi</option>

<option value="Vul">Vulcano</option>

</select>

</p>

</card>

<card id="card_three" title="Your Pizza!">

<p>

Your personal pizza parameter is <b>$(PIZZA)</b>!

</p>

</card>

</wml>


Wmlscript l.jpg
WMLScript

  • WMLScript is the scripting language used in WML pages .

  • Complement to WML

  • Provides general scripting capabilities

  • Features

    • validity check of user input

      • check input before sent to server

    • access to device facilities

      • hardware and software (phone call, address book etc.)

    • local user interaction

      • interaction without round-trip delay

    • extensions to the device software

      • configure device, download new functionality after deployment


Wmlscript example l.jpg
WMLScript - Example

function pizza_test(pizza_type) {

var taste = "unknown";

if (pizza_type = "Margherita") {

taste = "well... ";

}

else {

if (pizza_type = "Vulcano") {

taste = "quite hot";

};

};

return taste;

};


Wireless telephony application wta l.jpg
Wireless Telephony Application (WTA)

  • The Wireless Telephony API is an API and framework for accessing telephony and network services.

  • Collection of telephony specific extensions

  • Extension of basic WAE application model

    • content push

      • server can push content to the client

      • client may now be able to handle unknown events

    • handling of network events

      • table indicating how to react on certain events from the network

    • access to telephony functions

      • any application on the client may access telephony functions

  • Example

    • calling a number (WML)wtai://wp/mc;07216086415

    • calling a number (WMLScript)WTAPublic.makeCall("07216086415");


Wta logical architecture l.jpg

WTA server

WMLscripts

WTA & WML

server

WML

decks

WTA

services

WAP gateway

encoders

&

decoders

WTA logical architecture

other telephone networks

client

mobile

network

WTA

user agent

repository

device

specific

functions

network operator

trusted domain

other

servers

third partyservers

firewall


Voice box example l.jpg
Voice box example

WTA-User-Agent

WTA-Gateway

WTA-Server

Mobile network

Voice box server

Indicate new voice message

Generate new deck

Push URL

Service Indication

Display deck;

user selects

WSP Get

HTTP Get

Respond with content

WML

Binary WML

Display deck;

user selects

WSP Get

HTTP Get

Respond with card

for call

WML

Binary WML

Play requested voice message

Wait for call

Call setup

Setup call

Setup call

Accept call

Accept call

Accept call

Voice connection


Wtai example with wml only l.jpg
WTAI - example with WML only

<?xml version="1.0"?>

<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"

"http://www.wapforum.org/DTD/wml_1.1.xml">

<wml>

<card id="card_one" title="Tele voting">

<do type="accept">

<go href="#card_two"/>

</do>

<p> Please choose your candidate! </p>

</card>

<card id="card_two" title="Your selection">

<do type="accept">

<go href="wtai://wp/mc;$dialno"/>

</do>

<p> Your selection:

<select name="dialno">

<option value="01376685">Mickey</option>

<option value="01376686">Donald</option>

<option value="01376687">Pluto</option>

</select>

</p>

</card>

</wml>


Wtai example with wml and wmlscript 1 l.jpg
WTAI - example with WML and WMLScript (1)

function voteCall(Nr) {

var j = WTACallControl.setup(Nr,1);

if (j>=0) {

WMLBrowser.setVar("Message", "Called");

WMLBrowser.setVar("No", Nr);

}

else {

WMLBrowser.setVar("Message", "Error!");

WMLBrowser.setVar("No", j);

}

WMLBrowser.go("showResult");

}


Wtai example with wml and wmlscript 2 l.jpg
WTAI - example with WML and WMLScript (2)

<?xml version="1.0"?>

<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"

"http://www.wapforum.org/DTD/wml_1.1.xml">

<wml>

<card id="card_one" title="Tele voting">

<do type="accept"> <go href="#card_two"/> </do>

<p> Please choose your candidate! </p>

</card>

<card id="card_two" title="Your selection">

<do type="accept">

<go href="/myscripts#voteCall($dialno)"/> </do>

<p> Your selection:

<select name="dialno">

<option value="01376685">Mickey</option>

<option value="01376686">Donald</option>

<option value="01376687">Pluto</option>

</select> </p>

</card>

<card id="showResult" title="Result">

<p> Status: $Message $No </p>

</card>

</wml>


Wap push architecture with proxy gateway l.jpg

Push

Access

Protocol

Push Proxy

Gateway

Push OTA

Protocol

Client

Push Initiator

User Agents

Server

application

Coding,

checking

WAP push architecture with proxy gateway

  • Push Access Protocol

    • Content transmission between server and PPG (Push Proxy Gateway)

    • First version uses HTTP

  • Push OTA (Over The Air) Protocol

    • Simple, optimized

    • Mapped onto WSP


Push pull services in wap 1 l.jpg
Push/Pull services in WAP (1)

  • Service Indication

    • Service announcement using a pushed short message

    • Service usage via a pull

    • Service identification via a URI

      <?xml version="1.0"?>

      <!DOCTYPE si PUBLIC "-//WAPFORUM//DTD SI 1.0//EN"

      "http://www.wapforum.org/DTD/si.dtd">

      <si>

      <indication href="http://www.piiiizza4u.de/offer/salad.wml"

      created="2002-10-30T17:45:32Z"

      si-expires="2000-10-30T17:50:31Z">

      Salad special: The 5 minute offer

      </indication>

      </si>


Push pull services in wap 2 l.jpg
Push/Pull services in WAP (2)

  • Service Loading

    • short message pushed to a client containing a URI

    • User agent decides whether to use the URI via a pull

    • Transparent for users, always looks like a push

      <?xml version="1.0"?>

      <!DOCTYPE sl PUBLIC "-//WAPFORUM//DTD SL 1.0//EN"

      "http://www.wapforum.org/DTD/sl.dtd">

      <sl

      href="http://www.piiiizza4u.de/offer/salad.wml">

      </sl>


Examples for wap protocol stacks wap 1 x l.jpg
Examples for WAP protocol stacks (WAP 1.x)

WAP standardization

WAE user agent

outside WAP

WAE

WSP

transaction based

application

WTP

WTP

datagram based

application

WTLS

WTLS

WTLS

UDP

WDP

UDP

WDP

UDP

WDP

IP(GPRS, ...)

non IP

(SMS, ...)

IP(GPRS, ...)

non IP

(SMS, ...)

IP(GPRS, ...)

non IP

(SMS, ...)

1.

2.

3.

typical WAP application with complete protocol stack

pure data application with/without additional security


I mode first of all a business model l.jpg
i-mode – first of all a business model!

  • i-mode is a proprietary packet-based information service for mobile phones by NTT DoCoMo.

  • Access to Internet services in Japan provided by NTT DoCoMo

    • Services

      • Email, short messages, web, picture exchange, horoscope, ...

    • Big success – more than 44.3 million users (April 2005) (http://www.nttdocomo.com/companyinfo/subscriber.html)

      • Many use i-mode as PC replacement

      • For many this is the first Internet contact

      • Very simple to use, convenient

    • Technology

      • 9.6 kbit/s (enhancements with 28.8 kbit/s), packet oriented (PDC-P)

      • Compact HTML (cHTML) plus proprietary tags, special transport layer (Stop/go, ARQ, push, connection oriented)

mobile terminal

mobile network

gateway

content provider

cHTML + tags

cHTML + tags

HTTP(S)

HTTP(S)

TL

TL

TCP

TCP

TCP

TCP

PDC-P

PDC-P

IP

IP

IP

IP

L2

L2

L2

L2

L1

L1

L1

L1


Email example i mode push with sms l.jpg
Email example: i-mode push with SMS

Popular misconception:

WAP was a failure, i-mode is different and a success – wrong from a technology point of view, right from a business point of view…

application

WSP

WTP

WDP

SMS

  • i-mode as a business model:

  • content providers get >80% of the revenue.

  • independent of technology (GSM/GPRS in Europe, PDC-P in Japan – but also UMTS!)

Operator sends an SMS containing a push message if a new email has arrived. If the user wants to read the email, an HTTP get follows with the email as response.


I mode protocol stack based on wap 2 0 l.jpg

cHTML

cHTML

HTTP

HTTP

SSL

SSL

WTCP

WTCP

TCP

TCP

IP

IP

IP

IP

L2

L2

L2

L2

L1

L1

L1

L1

i-mode protocol stack based on WAP 2.0

user equipment

gateway

server

i-mode can use WAP 2.0/Internet protocols (example: i-mode in Germany over GSM/GPRS)






Wap 2 0 july 2001 l.jpg
WAP 2.0 (July 2001)

  • WAP 2.0 supports:

    • XHTML with a mobile profile (XHTMLMP)

    • TCP with „Wireless Profile“

    • HTTP

  • WAP 2.0 framework consists of:

    • Bearer networks: GPRS

    • Transport services: TCP, WDP or UDP

    • Transfer services: HTTP, Multi-media messaging Service (MMS)

    • Session services: push OTA (Over The Air)

  • New applications

    • Color graphics

    • Animation

    • Large file download

    • Location based services

    • Synchronization with PIMs

    • Pop-up/context sensitive menus

  • Goal: integration of WWW, Internet, WAP, i-mode


Wap 2 0 architecture l.jpg
WAP 2.0 architecture

Service

discovery

Security

services

Application

framework

Multimedia Messaging (Email)

Content formats

External services EFI

Crypto

libraries

WAE/WTA User Agent (WML, XHTMLMP)

Push

Provisioning

Authenti-cation

Protocol framework

Session

Capability Negotiation

Push

OTA

Cookies

Navigation

Discovery

Identification

Synchronisation

Transfer

Hypermedia transfer (WTP+WSP, HTTP)

Strea-ming

MMS

Service

Lookup

PKI

Transport

Datagrams

(WDP, UDP)

Connections

(TCP with wireless profile)

Secure

transport

Bearer

Secure

bearer

IPv4

CSD

USSD

GPRS

...

IPv6

SMS

FLEX

MPAK

...


Wap 2 0 example protocol stacks l.jpg
WAP 2.0 example protocol stacks

WAP device

WAP gateway

Web server

WAE

WAE

WAP device

WAP proxy

Web server

WSP

WSP

HTTP

HTTP

WTP

WTP

WAE

WAE

WTLS

WTLS

TLS

TLS

HTTP‘

HTTP‘

HTTP

HTTP

WDP

WDP

TCP

TCP

TCP‘

TCP‘

TCP

TCP

bearer

bearer

IP

IP

IP

IP

IP

IP

WAP 1.x Server/Gateway/Client

WAP HTTP Proxy with profiled TCP and HTTP

WAP device

WAP proxy

Web server

WAP device

Web server

WAE

WAE

HTTP

HTTP

WAE

WAE

IP router

TLS

TLS

HTTP

HTTP

TCP‘

TCP‘

TCP

TCP

TCP

TCP

IP

IP

IP

IP

IP

IP

IP

IP

WAP Proxy with TLS tunneling

WAP direct access


Java 2 platform micro edition l.jpg
Java 2 Platform Micro Edition

  • „Java-Boom expected“ (?)

    • Desktop: over 90% standard PC architecture, Intel x86 compatible, typically MS Windows systems

    • Do really many people care about platform independent applications?

  • BUT: Heterogeneous, “small“ devices

    • Internet appliances, cellular phones, embedded control, car radios, ...

    • Technical necessities (temperature range, form factor, power consumption, …) and economic reasons result in different hardware

  • J2ME

    • Provides a uniform platform

    • Restricted functionality compared to standard java platform (JVM)


Applications of j2me l.jpg
Applications of J2ME

  • Example cellular phones

    • NTT DoCoMo introduced ippli

    • Applications on PDA, mobile phone, ...

    • Game download, multimedia applications, encryption, system updates

    • Load additional functionality with a push on a button (and pay for it)!

  • Embedded control

    • Household devices, vehicles, surveillance systems, device control

    • System update is an important factor


Characteristics and architecture l.jpg
Characteristics and architecture

  • Java Virtual Machine

    • Virtual Hardware (Processor)

    • KVM (K Virtual Machine)

      • Min. 128 kByte, typ. 256 kByte

      • Optimized for low performance devices

      • Might be a co-processor

  • Configurations

    • Subset of standard Java libraries depending technical hardware parameters (memory, CPU)

    • CLDC (Connected Limited Device Configuration)

      • Basic libraries, input/output, security – describes Java support for mobile devices

  • Profiles

    • Interoperability of heterogeneous devices belonging to the same category

    • MIDP (Mobile Information Device Profile)

      • Defines interfaces for GUIs, HTTP, application support, …

Applications

Profile

(MIDP)

Configurations

(CDC, CLDC)

Java Virtual Machine

(JVM, KVM)

Operating system

(EPOC, Palm, WinCE)

Hardware

(SH4, ARM, 68k, ...)



Summary j2me l.jpg
Summary J2ME

  • Idea is more than WAP 1.x or i-mode

    • Full applications on mobile phones, not only a browser

    • Includes system updates, end-to-end encryption

  • Platform independent via virtualization

    • As long as certain common interfaces are used

    • Not valid for hardware specific functions

  • Limited functionality compared to JVM

    • Thus, maybe an intermediate solution only – until embedded systems, mobile phones are as powerful as today’s desktop systems


Optimizing web over wireless l.jpg
Optimizing Web over Wireless

  • Protocol (HTTP, Hypertext Transfer Protocol) and language (HTML, Hypertext Markup Language) of the Web have not been designed for mobile applications and mobile devices, thus creating many problems!

  • Typical transfer sizes

    • HTTP request: 100-350 byte

    • responses avg. <10 kbyte, header 160 byte, GIF 4.1kByte, JPEG 12.8 kbyte, HTML 5.6 kbyte

    • but also many large files that cannot be ignored

  • The Web is no file system

    • Web pages are not simple files to download

    • static and dynamic content, interaction with servers via forms, content transformation, push technologies etc.

    • many hyperlinks, automatic loading and reloading, redirecting

    • a single click might have big consequences!


Www example l.jpg
WWW example

Request to port 80:GET / HTTP/1.0

or:GET / HTTP/1.1

Host: www.inf.fu-berlin.de

Response from server

HTTP/1.1 200 OK

Date: Wed, 30 Oct 2002 19:44:26 GMT

Server: Apache/1.3.12 (Unix) mod_perl/1.24

Last-Modified: Wed, 30 Oct 2002 13:16:31 GMT

ETag: "2d8190-2322-3dbfdbaf"

Accept-Ranges: bytes

Content-Length: 8994

Connection: close

Content-Type: text/html

<DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

<title>FU-Berlin: Institut f&uuml;r Informatik</TITLE>

<base href="http://www.inf.fu-berlin.de">

<link rel="stylesheet" type="text/css" href="http://www.inf.fu-berlin.de/styles/homepage.css">

<!--script language="JavaScript" src="fuinf.js"-->

<!--/script-->

</head>

<body onResize="self.location.reload();">

...

non persistent


Optimizing web over wireless126 l.jpg
Optimizing Web over Wireless

  • HTTP Drawbacks

    • High connection overhead

    • Redundant capabilities transmission

    • Verbosity (HTTP is ASCII-encoded and inherently verbose)

  • Four main categories of optimization that could improve the performance of Web over wireless channels are:

    • Caching: cache data persist across browser sessions

    • Differencing: A base object carries basic features. Whenever a new transaction takes place, the server computes the difference stream and only the difference stream is transmitted.

    • Protocol reduction: A persistent TCP/IP connection can be set up between client side interface (CSI) and server side interface (SSI).

    • Header reduction: The CSI sends the header information in the first request and SSI records this information. Then consecutive transmission needs not to send headers each time.


Http 1 0 and mobility 1 l.jpg
HTTP 1.0 and mobility (1)

  • Characteristics

    • stateless, client/server, request/response

    • needs a connection oriented protocol (TCP), one connection per request (some enhancements in HTTP 1.1)

    • primitive caching and security

  • Problems

    • designed for large bandwidth (compared to wireless access) and low delay

    • big and redundant protocol headers (readable for humans, stateless, therefore big headers in ASCII)

    • uncompressed content transfer

    • using TCP

      • huge overhead per request (3-way-handshake) compared with the content, e.g., of a GET request

      • slow-start problematic

    • DNS lookup by client causes additional traffic


Http 1 0 and mobility 2 l.jpg
HTTP 1.0 and mobility (2)

  • Caching

    • quite often disabled by information providers to be able to create user profiles, usage statistics etc.

    • dynamic objects cannot be cached

      • numerous counters, time, date, personalization, ...

    • mobility quite often inhibits caches

    • security problems

      • how to use SSL/TLS together with proxies?

    • today: many user customized pages, dynamically generated on request via CGI, ASP, ...

  • POSTing (i.e., sending to a server)

    • can typically not be buffered, very problematic if currently disconnected

  • Many unsolved problems!


Html and mobile devices l.jpg
HTML and mobile devices

  • HTML

    • designed for computers with “high” performance, color high-resolution display, mouse, hard disk

    • typically, web pages optimized for design, not for communication

  • Mobile devices

    • often only small, low-resolution displays, very limited input interfaces (small touch-pads, soft-keyboards)

  • Additional “features”

    • animated GIF, Java AWT, Frames, ActiveX Controls, Shockwave, movie clips, audio, ...

    • many web pages assume true color, multimedia support, high-resolution and many plug-ins

  • Web pages ignore the heterogeneity of end-systems!

    • e.g., without additional mechanisms, large high-resolution pictures would be transferred to a mobile phone with a low-resolution display causing high costs


Approaches toward www for mobile devices l.jpg
Approaches toward WWW for mobile devices

  • Application gateways, enhanced servers

    • simple clients, pre-calculations in the fixed network

    • compression, filtering, content extraction

    • automatic adaptation to network characteristics

  • Examples

    • picture scaling, color reduction, transformation of the document format (e.g., PS to TXT)

    • detail studies, clipping, zoom

    • headline extraction, automatic abstract generation

    • HDML (handheld device markup language): simple language similar to HTML requiring a special browser

    • HDTP (handheld device transport protocol): transport protocol for HDML, developed by Unwired Planet

  • Problems

    • proprietary approaches, require special enhancements for browsers

    • heterogeneous devices make approaches more complicated


Some new issues that might help mobility l.jpg
Some new Issues that might help mobility?

  • Push technology

    • real pushing, not a client pull needed, channels etc.

  • HTTP/1.1

    • client/server use the same connection for several request/response transactions

    • multiple requests at beginning of session, several responses in same order

    • enhanced caching of responses (useful if equivalent responses!)

    • semantic transparency not always achievable: disconnected, performance, availability  most up-to-date version...

    • several more tags and options for controlling caching (public/private, max-age, no-cache etc.)

    • relaxing of transparency on app. request or with warning to user

    • encoding/compression mechanism, integrity check, security of proxies, authentication, authorization...

  • Cookies: well..., stateful sessions, not really integrated...


System support for www in a mobile world 1 l.jpg

mobile client

integratedenhancement

browser

System support for WWW in a mobile World (1)

  • Enhanced browsers

    • Pre-fetching, caching, off-line use

    • e.g. Internet Explorer, Netscape

  • Additional, accompanying application

    • Pre-fetching, caching, off-line use

    • e.g. original WebWhacker

    • Problem – not transparent, two different ways of accessing content:

      • Directly to the web server

      • Via the additional application

web

server

mobile client

browser

additionalapplication

web

server


System support for www in a mobile world 2 l.jpg
System support for WWW in a mobile World (2)

  • Client Proxy acts as server for the browser and as client for the web server.

    • Pre-fetching, caching, off-line use

    • e.g., Caubweb, TeleWeb, Weblicator,WebWhacker, WebEx, WebMirror

  • Network Proxy supports a mobile client on the network side.

    • adaptive content transformation for bad connections, pre-fetching, caching

    • e.g., TranSend, Digestor

mobile client

browser

client

proxy

web

server

mobile client

browser

network

proxy

web

server


System support for www in a mobile world 3 l.jpg

client

proxy

network

proxy

System support for WWW in a mobile World (3)

  • Client and network proxy

    • combination of benefits plussimplified protocols

    • e.g., MobiScape, WebExpress

  • Special network subsystem

    • adaptive content transformation for bad connections, pre-fetching, caching

    • e.g., Mowgli

  • Additional many proprietary serverextensions possible

    • “channels”, content negotiation, ...

mobile client

browser

client

proxy

web

server

network

proxy

mobile client

browser

web

server


ad