Chapter 4: Wireless Internet
 Introduction
 What is Wireless Internet?
 Mobile IP
 TCP in Wireless Domain
 WAP
 Optimizing Web over Wireless
1
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.
2
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
3
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
4
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.
5
Motivation for Mobile IP
Data Path for Foreign Agent Care-of Address
Data Path for Co-located Care-of Address
6
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
7
Example network
HA
MN
router
home network
mobile end-system
Internet
(physical home network
for the MN)
FA
foreign
network
router
(current physical network
for the MN)
CN
end-system
router
8
Data transfer to the mobile system
HA
2
MN
home network
Internet
receiver
3
FA
1
CN
sender
foreign
network
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
9
Data transfer from the mobile system
HA
1
home network
MN
sender
Internet
FA
foreign
network
1. Sender sends to the IP address
of the receiver as usual,
FA works as default router
CN
receiver
10
Overview
COA
home
network
router
FA
router
HA
MN
foreign
network
Internet
CN
router
3.
home
network
router
HA
router
FA
2.
MN
4.
Internet
foreign
network
1.
CN
router
11
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.
12
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.
13
Reverse tunneling (RFC 3024, was: 2344)
HA
2
MN
home network
Internet
sender
1
FA
3
CN
receiver
foreign
network
1. MN sends to FA
2. FA tunnels packets to HA
by encapsulation
3. HA forwards the packet to the
receiver (standard case)
14
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
15
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,
16
• independent of changes in COA/FA
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
type
#addresses
15 16
23 24
checksum
lifetime
31
code
addr. size
router address 1
preference level 1
router address 2
preference level 2
type = 16
...
length = 6 + 4 * #COAs
R: registration required
type = 16
length
sequence number
B: busy, no more registrations
R B H F M G r T reserved
registration lifetime
H: home agent
COA
... 1
F: foreign agent
COA 2
M: minimal encapsulation
G: GRE (Generic Routing Encapsulation)
r: =0, ignored (former Van Jacobson compression)
T: FA supports reverse tunneling
17
reserved: =0, ignored
Registration
MN
FA
HA
MN
HA
t
t
 The COA is at the FA
 The COA is co-located in
MN
18
Mobile IP registration request
0
7 8
type = 1
15 16
S B DMG r T x
home address
home agent
COA
23 24
lifetime
31
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
19
Mobile IP registration reply
0
7 8
type = 3
15 16
code
home address
home agent
31
lifetime
identification
Example codes:
extensions . . .
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
20
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
new IP header
outer header
original data
new data
inner header
original data
21
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
22
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
23
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
IP identification
flags
fragment offset
TTL
lay. 4 prot.
IP checksum
IP address of CN
IP address of MN
TCP/UDP/ ... payload
outer header
GRE
header
new header
original
header
original data
original
header
original data
new data
RFC 2784
C
reserved0
ver.
checksum (optional)
protocol
reserved1 (=0)
24
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
25
to use the old mapping.
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.
26
Change of foreign agent
CN
HA
Data
Update
FAold
FAnew
Data
MN
Data
ACK
Data
Data
MN changes
location
Update
ACK
Data
Data
Warning
Registration
Data
Request
Update
ACK
Data
Data
t
27
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.
28
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.
29
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
30
Macro and Micro mobility
Home Agent
Macro mobility by
Mobile IP
Home
Network
INTERNET
FA
Macro-mobility
handover
Micro-mobility
handover
Gateway
as FA
Micro mobility
domain
Handovers in Micro
Mobility transparent
outside the domain
31
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
32
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
33
HAWAII
 Operation:
• MN obtains co-located COA
and registers with HA
• Handover: MN keeps COA,
new BS answers Reg. Request
and updates routers
• MN views BS as foreign agent
1
Internet
HA
2
3
4
Backbone
Router
Crossover
Router
 Security provisions:
• MN-FA authentication mandatory
• Challenge/Response Extensions
mandatory
4
BS
BS
Mobile IP
3
MN
2
Mobile IP
BS
MN
DHCP
Server
1
DHCP
34
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
35
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
36
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
Internet
Mobile IP
CIP Gateway
data/control
packets
from MN 1
BS
MN1
BS
BS
packets from
MN2 to MN 1
MN2
37
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)
38
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 problem
for resource-constrained MNs
39
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.
40
TIMIP architecture
Access
point
(level 1)
Access
router
(level 2)
Core
Tunneling
network
Access
router
(level n-x)
Access
router
(level 2)
Access
network
gateway
(level n)
Access
point
(level 1)
41
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
binding
update
Internet
HA
RCOA
MAP
AR
AR
LCOAnew LCOAold
MN
MN
42
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)
43
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
44
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! 45
Security in Mobile IP
 Security requirements (Security Architecture for the Internet
Protocol, RFC 1825)
• Integrity
any changes to data between sender and receiver can be detected by the
receiver
• Authentication
sender address is really the address of the sender and all data received is
really data sent by this sender
• Confidentiality
only 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 Analysis
creation of traffic and user profiles should not be possible
• Replay Protection
46
receivers can detect replay of messages
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
IP-Header
IP header
Authentification-Header
authentication header
UDP/TCP-Paket
UDP/TCP data
• Encapsulation Security Payload
• protects confidentiality between communication partners
not encrypted
IP header
encrypted
ESP header
encrypted data
47
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
MH-FA authentication
FA-HA authentication
MH-HA authentication
registration request
MH
registration reply
registration request
FA
registration reply
HA
• 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)
48
Key distribution
 Home agent distributes session keys
FA
HA
MH
response:
EHA-FA {session key}
EHA-MH {session key}
 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
49
mobile node
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).
50
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.
51
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
52
DHCP - Protocol Mechanisms
client
initialization
server
(not selected)
determine the
configuration
DHCPDISCOVER
DHCPDISCOVER
DHCPOFFER
DHCPOFFER
server
(selected)
determine the
configuration
collection of replies
selection of configuration
DHCPREQUEST
(reject)
DHCPREQUEST
(options)
confirmation of
configuration
DHCPACK
initialization completed
release
DHCPRELEASE
delete context
53
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
54
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
55
Manet: Mobile Ad-hoc Networking
Mobile
Router
Manet
Mobile
Devices
Mobile IP,
DHCP
Fixed
Network
Router
End system
56
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
57
Transport Layer Examples
 E.g. HTTP (used by web services)
typically uses TCP
• Reliable transport between client and
server required
Client
TCP SYN
TCP SYN/ACK
 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
Server
Connection
setup
TCP ACK
HTTP request
HTTP response
Data
transmission
>15 s
no data
GPRS: 500ms!
Connection
release
• Packet loss due to transmission errors
• Packet loss due to change of network
 Result
• Severe performance degradation
58
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
59
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)
60
• The sender then performs fast retransmission and a fast recovery.
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
61
TCP Over Wireless
TCP over Wireless
Link layer
solutions
Snoop TCP
TCP-unaware
link layer
Split approach
based solutions
I-TCP
M-TCP
End-to-end
solutions
ELN
WTCP
TCP SACK
TTCP
62
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
local retransmission
correspondent
node (host)
Foreign agent
(base station)
“wired“ Internet
snooping of ACKs
mobile
node (host)
buffering of data
end-to-end TCP connection
63
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
64
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 TCPaware.
 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.
65
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)
access point
(foreign agent)
„wireless“ TCP
„wired“ Internet
standard TCP
66
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)
67
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
68
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
69
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.
70
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 reservepath characteristics for determining the ACK frequency.
71
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
72
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
73
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
74
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
75
Comparison of different approaches for
a “mobile” TCP
Approach
Mechanism
Advantages
Disadvantages
loss of TCP semantics,
higher latency at
handover
transparent for end-to- problematic with
“snoops” data and
Snooping TCP
encryption, bad isolation
acknowledgements, local end connection, MAC
of wireless link
integration possible
retransmission
Bad isolation of wireless
Maintains end-to-end
splits TCP connection,
M-TCP
link, processing
semantics, handles
chokes sender via
long term and frequent overhead due to
window size
bandwidth management
disconnections
mixed layers, not
simple and efficient
Fast retransmit/ avoids slow-start after
transparent
roaming
fast recovery
independent of content changes in TCP
freezes TCP state at
Transmission/
or encryption, works for required, MAC
time-out freezing disconnect, resumes
dependant
longer interrupts
after reconnection
slightly more complex
retransmit only lost data very efficient
Selective
receiver software, more
retransmission
buffer needed
changes in TCP
Efficient for certain
combine connection
Transaction
required, not transparent
applications
setup/release and data
oriented TCP
transmission
Indirect TCP
splits TCP connection
into two connections
isolation of wireless
link, simple
76
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
BW 
0.93 * MSS
RTT * p
• max. TCP BandWidth
• Max. Segment Size
• Round Trip Time
• loss probability
• 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
77
• WAP 2.0 (“TCP with wireless profile”)
TCP Improvements (2)
 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!
Mobile system
wireless
PEP
Internet
Comm. partner
78
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, …)
79
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.
80
WAE logical model
Origin Servers
web
server
other content
server
Gateway
response
with
content
push
content
request
encoders
&
decoders
Client
encoded
response
with
content
encoded
push
content
encoded
request
WTA
user agent
WML
user agent
other
WAE
user agents
 WAP adopts a client-server approach.
 It specifies a proxy server that acts as an interface between the wireless
domain and core wired network.
81
WAP 1.x - reference model and protocols
Internet
HTML, Java
A-SAP
WAP
Application Layer (WAE)
S-SAP
additional services
and applications
Session Layer (WSP)
HTTP
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.
82
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
83
Datagram Protocol (WDP).
WAP - network elements
fixed network
Internet
HTML
wireless network
WML
HTML
filter
WAP
proxy
Binary WML
WML
HTML
web
server
HTML
filter/
WAP
proxy
WTA
server
Binary WML
Binary WML
PSTN
Binary WML: binary file format for clients
84
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)
85
Usage of WDP
Wireless Data Gateway
WTLS
WDP &
Adaptation
SMS
GSM-SMS
Tunnel
WTLS
WDP &
Adaptation
Tunnel
Subnetwork
Subnetwork
SMS
WAP
Proxy
GSM-CSD
WTLS
Internet Service Provider
Remote Access Service
UDP
IP
PPP
CSD-RF
Interworking
Function
CSD-RF
PSTN
Circuit
IP
PPP
PSTN
Circuit
 GSM-CSD (GSM Circuit Switched Data)
Subnetwork
WTLS
UDP
IP
Subnetwork
86
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
87
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)
88
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
89
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)
90
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
91
WSP protocols
WSP
Connection mode
(uses WTP)
Connectionless mode
(uses WDP or WTLS)
• Session Management (class 0, 2)
• Method Invocation
• Method Invocation (Kl. 2)
• Push
• Error Report
(in general unreliable)
• Push (class 0)
• Confirmed Push (class 1)
• Session suspend/resume (class 0, 2)
92
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)
93
• content formats: vCard, vCalendar, Wireless Bitmap, WML, ...
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
94
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>
95
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>
96
</wml>
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
97
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;
};
98
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");
99
WTA logical architecture
other telephone networks
WTA server
client
WML
scripts
WTA & WML
server
mobile
network
WTA
user agent
WAP gateway
repository
WML
decks
WTA
services
network operator
trusted domain
third party
servers
encoders
&
decoders
other
servers
device
specific
functions
firewall
100
Voice box example
WTA-User-Agent
WTA-Gateway
WTA-Server
Mobile network
Indicate new voice message
Voice box server
Generate new deck
Service Indication
Display deck;
user selects
WSP Get
Binary WML
Display deck;
user selects
WSP Get
Binary WML
Push URL
HTTP Get
WML
Respond with content
HTTP Get
WML
Respond with card
for call
Play requested voice message
Wait for call
Call setup
Setup call
Setup call
Accept call
Accept call
Accept call
Voice connection
101
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>
102
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");
}
103
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>
104
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
Client
User Agents
Push OTA
Protocol
Push Proxy
Gateway
Coding,
checking
Push
Access
Protocol
Push Initiator
Server
application
105
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>
106
</si>
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>
107
Examples for WAP protocol stacks
(WAP 1.x)
WAP standardization
WAE user agent
outside WAP
WAE
WSP
transaction based
application
WTP
WTP
WTLS
datagram based
application
WTLS
WTLS
UDP
WDP
UDP
WDP
UDP
WDP
IP
non IP
IP
non IP
IP
non IP
(GPRS, ...) (SMS, ...)
(GPRS, ...) (SMS, ...)
(GPRS, ...) (SMS, ...)
1.
2.
3.
typical WAP
application with
complete protocol
stack
pure data application
with/without
additional security
108
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
cHTML + tags
HTTP(S)
TL
TL
PDC-P
PDC-P
TCP
IP
L2
L1
gateway
TCP
IP
L2
L1
TCP
IP
L2
L1
content provider
cHTML + tags
HTTP(S)
TCP
IP
L2
L1
109
Email example: i-mode push with SMS
application
WSP
WTP
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…
WDP
SMS
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 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!)
110
i-mode protocol stack based on WAP 2.0
user equipment
gateway
server
cHTML
cHTML
HTTP
HTTP
SSL
SSL
WTCP
WTCP
TCP
TCP
IP
IP
IP
IP
L2
L2
L2
L2
L1
L1
L1
L1
i-mode can use WAP 2.0/Internet protocols (example: i-mode in Germany over GSM/GPRS)
111
i-mode – technical requirements
Functions
Descriptions
Statu
s
Requirement
WEB Access
Portal Site / Internet Access
M
i-mode HTML (cHTML+tags)
E-mail
Internet e-mail and inter-terminal email
M
HTTP 1.1
Security
End-End security
O
SSL (Version 2, 3), TLS 1
Java
Java application made available
O
Compatible i-mode JAVA
Ringing tone download
Ringing melody download
M
SMF based
Image download
Stand-by screen download
M
GIF (O: JPEG)
Voice call notification
during i-mode session
Voice termination notified and responded during i-mode
communications
M
3GPP standard system
Content charge billing
Per content charge billed to user
M
Specifications depend on each
operator’s billing system
Third party payment
collection
Content charge collection on behalf of Content Provider
M
Specifications depend on each
operator’s billing system
Reverse billing
Packet usage charges can be billed to third party
O
Specifications depend on each
operator’s billing system
Subscriber ID transmission
Hashed subscriber ID from the operator’s portal to the CP
transmission on each content access
M
The ID generation algorithm
should be determined by each
operator and has to be secret
Number of characters per email
Number of characters (byte) per e-mail
M
To be defined by operators
(e.g. 500 byte, 1K byte, 10K
byte)
Character code set
supported
Character code set supported by browser and used to develop
content
M
To be defined by operators
112
i-mode examples (1)
113
i-mode examples (2)
114
i-mode examples (3)
115
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
116
External
services EFI
Crypto
libraries
WAE/WTA User Agent
(WML, XHTMLMP)
Push
Provisioning
Authentication
Identification
Service
Lookup
PKI
Secure
transport
Secure
bearer
Push
OTA
Cookies
Synchronisation
Hypermedia transfer
(WTP+WSP, HTTP)
CSD
IPv6
MMS
Connections
(TCP with
wireless profile)
Datagrams
(WDP, UDP)
IPv4
Streaming
Transport
Navigation
Discovery
Capability Negotiation
USSD
SMS
GPRS
FLEX
MPAK
...
...
Protocol framework
Content
formats
Session
Multimedia Messaging
(Email)
Transfer
Security
services
Bearer
Service
discovery
Application
framework
WAP 2.0 architecture
117
WAP 2.0 example protocol stacks
WAP device
WAE
WSP
WTP
WTLS
WDP
bearer
WAP gateway
WSP
WTP
WTLS
WDP
bearer
Web server
WAE
HTTP
HTTP
TLS
TCP
IP
TLS
TCP
IP
WAP 1.x Server/Gateway/Client
WAP device
WAE
HTTP
TLS
TCP‘
IP
WAP proxy
TCP‘
IP
TCP
IP
Web server
WAE
HTTP
TLS
TCP
IP
WAP Proxy with TLS tunneling
WAP device
WAE
HTTP‘
TCP‘
IP
WAP proxy
HTTP‘
TCP‘
IP
HTTP
TCP
IP
Web server
WAE
HTTP
TCP
IP
WAP HTTP Proxy with profiled TCP and HTTP
WAP device
WAE
HTTP
TCP
IP
IP router
IP
IP
Web server
WAE
HTTP
TCP
IP
WAP direct access
118
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)
119
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
120
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, ...)
121
Hardware independent development
122
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
123
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!
124
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
non persistent
<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.fuberlin.de/styles/homepage.css">
<!--script language="JavaScript" src="fuinf.js"-->
<!--/script-->
</head>
<body onResize="self.location.reload();">
...
125
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.
126
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
127
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!
128
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
129
high costs
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
130
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, maxage, 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...
131
System support for WWW in a mobile
World (1)
 Enhanced browsers
• Pre-fetching, caching, off-line use
• e.g. Internet Explorer, Netscape
mobile client
integrated
enhancement
browser
web
server
 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
mobile client
browser
additional
application
web
server
132
System support for WWW in a mobile
World (2)
 Client Proxy acts as server for the
browser and as client for the web
server.
mobile client
browser
client
proxy
• 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
web
server
mobile client
browser
network
proxy
web
server
133
System support for WWW in a mobile
World (3)
 Client and network proxy
• combination of benefits plus
simplified protocols
• e.g., MobiScape, WebExpress
 Special network subsystem
• adaptive content transformation
for bad connections, pre-fetching,
caching
• e.g., Mowgli
 Additional many proprietary server
extensions possible
• “channels”, content negotiation, ...
mobile client
browser
client
proxy
web
server
network
proxy
mobile client
browser
client
proxy
web
server
network
proxy
134