Learning Center
Plans & pricing Sign in
Sign Out



									         Chapter 4: Wireless Internet

 Introduction                  TCP in Wireless Domain
 What is Wireless Internet?    WAP
 Mobile IP                     Optimizing Web over Wireless

             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
 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)
 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
 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                                                                  4
  • authentication of all messages related to Mobile IP management
 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
 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 IP

  Data Path for Foreign Agent Care-of Address

    Data Path for Co-located Care-of Address
               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


   home network                                         mobile end-system
(physical home network
for the MN)
                                                   FA   foreign
                                               (current physical network
                                               for the MN)

          end-system             router

   Data transfer to the mobile system

home network                                  3                 receiver

                                                       FA    foreign

                                   1. Sender sends to the IP address of MN,
                1                     HA intercepts packet (proxy ARP)
                                   2. HA tunnels packet to COA, here FA,
                                      by encapsulation
      sender                       3. FA forwards the packet
                                      to the MN
Data transfer from the mobile system
                                                         1       MN

home network                                             sender

                                                FA    foreign

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



  home           router                                         MN
 network           HA

                                Internet                         network

   CN            router

 home           router                                          MN
                          2.                       FA
network           HA
                               Internet                         network

  CN            router

     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)

 home network                                                      sender

                                                         FA    foreign

                                     1. MN sends to FA
                  3                  2. FA tunnels packets to HA
  CN                                    by encapsulation
                                     3. HA forwards the packet to the
                                        receiver (standard case)

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
  • 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                                                   16
                        Agent advertisement
 Agent Advertisement
    • Use ICMP with mobility extension

 Lifetime: length of time this
 advertisement is valid.            0          7 8         15 16         23 24         31
 Preference helps a node               type         code               checksum
 choose the router                  #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
                                    type = 16         length         sequence number
B: busy, no more registrations        registration lifetime      R B H F M G r T reserved
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
reserved: =0, ignored                                                                   17

         MN     FA       HA        MN     HA



 The COA is at the FA         The COA is co-located in
                                MN                      18
         Mobile IP registration request
               0              7 8         15 16          23 24     31
                   type = 1    S B D MG r T x           lifetime
                                      home address
                                       home agent

                                     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
                                     0              7 8        15 16                         31
                                         type = 3         code               lifetime
                                                            home address
                                                             home agent
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

 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
 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)
 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)
 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

                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
 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                                           original
                                                                                                             original data
       IP identification           flags      fragment offset                                    header
      TTL             GRE                   IP checksum
                        IP address of HA                                              GRE        original
                                                                outer header                                 original data
                     Care-of address COA                                             header      header
C R K S s rec.      rsv.     ver.             protocol
     checksum (optional)                  offset (optional)
                           key (optional)                           new header                    new data
                 sequence number (optional)
                         routing (optional)
  ver.   IHL       DS (TOS)                     length
       IP identification           flags      fragment offset                         RFC 2784
      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                                                                           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
  • Binding acknowledgement: Conformation of binding.
  • Binding warning: In some cases, a handoff may occur, but CN may continue
    to use the old mapping.                                             25
     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
CN                  HA           FAold           FAnew                  MN

       Data               Data                   Data

                         Data                    Data
                                                                             MN changes
                                         Update          Registration
                                          Data              Data

 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.
 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
 The mobility management can be categorized into two types:
  • Macro-mobility protocols such as the Mobile IP deal with the inter-domain
  • 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
  • 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                                      Home
   Mobile IP                                           Network

                                      Macro-mobility         as FA

                    Micro-mobility               Micro mobility
                    handover                        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
  • Access Network Gateway (ANG)
     • The root AR, interfacing with the core IP network
     • Perform mobility management functions to support MobileIP-based
  • Mobile terminal (MT)
     • Runs the user applications
     • Roaming between different APs
                    Mobile IP and IPv6
 Mobile IP was developed for IPv4, but IPv6 simplifies the
  • security is integrated and not an add-on, authentication of registration is
  • 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
  • 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
 Operation:
  • MN obtains co-located COA      1                    Internet
    and registers with HA          2                           HA
  • Handover: MN keeps COA,        3
    new BS answers Reg. Request    4                     Router
    and updates routers
  • MN views BS as foreign agent               Crossover
 Security provisions:                              4      Mobile IP
  • MN-FA authentication mandatory
  • Challenge/Response Extensions         BS    BS        BS
    mandatory                          Mobile IP
                                               MN         MN            DHCP

                    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
  • 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
 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
 Operation:
  • CIP node (gateway) maintains                               Internet
    routing entries (soft state) for MNs
                                                                      Mobile IP
  • Multiple entries possible
  • Routing entries updated based on                       CIP Gateway
    packets sent by MN
 CIP (Cellular IP) Gateway:                from MN 1
  • Mobile IP tunnel endpoint
  • Initial registration processing
                                                  BS      BS    BS
 Security provisions:                                                packets from
                                                                      MN2 to MN 1
  • all CIP Nodes share
    “network key“                                  MN1          MN2
  • MN key: MD5(net key, IP addr)
  • MN gets key upon registration
                    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
 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
  • Transparency: Not transparent to MNs (additional control messages)
  • Security: Public-key encryption of MN keys may be a problem
    for resource-constrained MNs

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

Access       (level 2)                                 Core
point                                                  network
(level 1)

                          Access        Access
                          router        network
                          (level n-x)   gateway
              Access                    (level n)
              (level 2)

 (level 1)

    Hierarchical Mobile IPv6 (HMIPv6)
 Operation:
  • Network contains mobility anchor point (MAP)             Internet
     • mapping of regional COA (RCOA) to link                           HA
       COA (LCOA)
  • Upon handover, MN informs MAP only
     • gets new LCOA, keeps RCOA
  • HA is only contacted if MAP changes
                                              binding   AR         AR
 Security provisions:                                   LCOAnew LCOAold
  • no HMIP-specific security provisions
                                                        MN              MN
  • binding updates should be authenticated

       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

 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
 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
 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
   • 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
  • 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
  • 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
            IP header
            IP-Header            authentication header
                                Authentification-Header       UDP/TCP data

  • Encapsulation Security Payload
     • protects confidentiality between communication partners
                not encrypted                             encrypted
             IP header               ESP header                 encrypted data
            IP security architecture (2)
 Mobile Security Association for registrations
  • parameters for the mobile host (MH), home agent (HA), and foreign agent
 Extensions of the IP security architecture
  • extended authentication of registration

                  MH-FA authentication       FA-HA authentication
                             MH-HA authentication
                   registration request
                                               registration request
             MH                           FA    registration reply    HA
                    registration reply

  • 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)
                    Key distribution
 Home agent distributes session keys

                        FA                MH

                        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
  mobile node                                                  49
       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
     • 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 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
  • 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
 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)

                                              server           client

     client                      relay
          DHCP - Protocol Mechanisms
     server                            client              server
 (not selected)               initialization             (selected)
                  DHCPDISCOVER           DHCPDISCOVER
determine the                                           determine the
configuration                                           configuration
                  DHCPOFFER              DHCPOFFER
                          collection of replies

                       selection of configuration
                  DHCPREQUEST            DHCPREQUEST
                     (reject)               (options)   confirmation of
                       initialization completed

                                         DHCPRELEASE    delete context

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



                                 Mobile IP,


           Router   End system

                         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
 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                          Client                   Server
                                                        TCP SYN
   • Reliable transport between client and
     server required                                   TCP SYN/ACK          Connection
 TCP                                                                       setup
                                                         TCP ACK
   • Steam oriented, not transaction
     oriented                                          HTTP request
   • Network friendly: time-out                                             Data
                                                       HTTP response
      congestion                                                           transmission
      slow down transmission
                                                                                >15 s
 Well known – TCP guesses quite                                                no data
  often wrong in wireless and mobile                   GPRS: 500ms!         Connection
  networks                                                                  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
  • 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
  • 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.        60
                    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
 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 Wireless

                   TCP over Wireless

Link layer          Split approach     End-to-end
 solutions          based solutions     solutions

 Snoop TCP             I-TCP            ELN
                       M-TCP            WTCP
  link layer                            TCP SACK

        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
                                      Foreign agent                        node (host)
                                      (base station)

                                                        “wired“ Internet

                   snooping of ACKs       buffering of data
node (host)                  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 TCP-
 The usage of delayed duplicate acknowledgements (DUPACKs)
  imitates snoop-TCP without requiring the link layer at BS to be
 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)
 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)   „wired“ Internet

                      „wireless“ TCP                 standard TCP
     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)
 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
  • 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
 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.

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

  Comparison of different approaches for
            a “mobile” TCP
Approach          Mechanism                 Advantages               Disadvantages
Indirect TCP      splits TCP connection     isolation of wireless    loss of TCP semantics,
                  into two connections      link, simple             higher latency at
Snooping TCP      “snoops” data and         transparent for end-to- problematic with
                  acknowledgements, local end connection, MAC        encryption, bad isolation
                  retransmission            integration possible     of wireless link
M-TCP             splits TCP connection,    Maintains end-to-end     Bad isolation of wireless
                  chokes sender via         semantics, handles       link, processing
                  window size               long term and frequent overhead due to
                                            disconnections           bandwidth management
Fast retransmit/ avoids slow-start after    simple and efficient     mixed layers, not
fast recovery     roaming                                            transparent
Transmission/     freezes TCP state at      independent of content changes in TCP
time-out freezing disconnect, resumes       or encryption, works for required, MAC
                  after reconnection        longer interrupts        dependant
Selective         retransmit only lost data very efficient           slightly more complex
retransmission                                                       receiver software, more
                                                                     buffer needed
Transaction       combine connection        Efficient for certain    changes in TCP
oriented TCP      setup/release and data    applications             required, not transparent
                TCP Improvements (1)
 Initial research work                                              0.93 * MSS
                                                              BW 
  • Indirect TCP, Snoop TCP, M-TCP, T/TCP, SACK,                     RTT * p
    Transmission/time-out freezing, …                          • max. TCP BandWidth
                                                               • Max. Segment Size
 TCP over 2.5/3G wireless networks                            • 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
  • Already in use
     • i-mode running over FOMA
     • WAP 2.0 (“TCP with wireless profile”)                                77
                 TCP Improvements (2)
 Performance enhancing proxies (PEP, RFC 3135)                      Mobile system
  • 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                           Internet

     • Disables use of IP security
     • Choose between PEP and security!
 More open issues                                                   Comm. partner
  • RFC 3150 (slow links)
     • Recommends header compression, no timestamp
  • RFC 3155 (links with errors)
     • States that explicit congestion notification cannot be used             78
  • In contrast to 2.5G/3G recommendations!
  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
 Forum
  • was: WAP Forum, co-founded by Ericsson, Motorola, Nokia, Unwired
    Planet, further information
  • now: Open Mobile Alliance
    (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
  • Wireless Telephony Application (Interface): access to all telephone
 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                    Gateway                        Client

                          response                     encoded        WTA
                          with                         response     user agent
                          content                      with
                                        decoders                      WML
          other content
                                                                    user agent
             server       push                         encoded
                          content                      push
                                                                    user agents
                          request                      encoded

 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           A-SAP    WAP

  HTML, Java       Application Layer (WAE)             additional services
                                                       and applications
                        Session Layer (WSP)
     HTTP            TR-SAP
                           Transaction Layer (WTP)
   SSL/TLS                     Security Layer (WTLS)

    TCP/IP,                        Transport Layer (WDP)            WCMP
     media                        Bearers (GSM, CDPD, ...)

 WAE comprises WML (Wireless Markup Language), WML Script, WTAI etc.
 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
 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).                                                       83
              WAP - network elements
             fixed network                              wireless network

             HTML               WML    WAP       Binary WML
                       filter          proxy

     HTML                       WML
                                       filter/       Binary WML
     web                        HTML   proxy

                                        WTA      Binary WML

                                   Binary WML: binary file format for clients

    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
                        Usage of WDP
                                       Wireless Data Gateway
                   WTLS                                                   WTLS
GSM-SMS           WDP &                                                  WDP &
                 Adaptation                                             Adaptation
                    SMS                  SMS             Tunnel           Tunnel
                                                    Subnetwork          Subnetwork


          WTLS                                                             WTLS
                                            Internet Service Provider
          UDP                                Remote Access Service         UDP
           IP           Interworking                     IP                 IP
          PPP             Function              PPP
                               PSTN            PSTN        Subnetwork   Subnetwork
        CSD-RF        CSD-RF
                               Circuit         Circuit

 GSM-CSD (GSM Circuit Switched Data)                                            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
  • is based on the TLS (Transport Layer Security) protocol (former SSL, Secure
    Sockets Layer)
  • optimized for low-bandwidth communication channels

  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)
 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)
 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
 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

      Connection mode                      Connectionless mode
        (uses WTP)                         (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)

WAE - Wireless Application Environment
 Goals
  • network independent application environment for low-bandwidth, wireless
  • 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, ...          93
    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)
<?xml version="1.0"?>
    <card id="card_one" title="simple example">
        <do type="accept">
             <go href="#card_two"/>
        This is a simple first card!
        On the next one you can choose ...

               WML – example (2)
<card id="card_two" title="Pizza selection">
        <do type="accept" label="cont">
             <go href="#card_three"/>
        ... your favorite pizza!
        <select value="Mar" name="PIZZA">
             <option value="Mar">Margherita</option>
             <option value="Fun">Funghi</option>
             <option value="Vul">Vulcano</option>
    <card id="card_three" title="Your Pizza!">
        Your personal pizza parameter is <b>$(PIZZA)</b>!
    </card>                                               96
 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
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)
 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)
  • calling a number (WMLScript)                                          99
           WTA logical architecture
                                    other telephone networks
        WTA server
 scripts                                    mobile               WTA
               WTA & WML                    network            user agent
                                        WAP gateway            repository
                                              &                  device
network operator                           decoders             specific
trusted domain             other                               functions

 third party

                              Voice box example
WTA-User-Agent             WTA-Gateway            WTA-Server          Mobile network            Voice box server
                                                       Indicate new voice message

                                               Generate new deck
      Service Indication          Push URL
Display deck;
user selects
                 WSP Get         HTTP Get

                                              Respond with content
          Binary WML              WML

Display deck;
user selects
                 WSP Get          HTTP Get
                                               Respond with card
                                  WML               for call
          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
<?xml version="1.0"?>
    <card id="card_one" title="Tele voting">
        <do type="accept">
            <go href="#card_two"/>
        <p> Please choose your candidate! </p>
    <card id="card_two" title="Your selection">
        <do type="accept">
            <go href="wtai://wp/mc;$dialno"/>
        <p> Your selection:
        <select name="dialno">
            <option value="01376685">Mickey</option>
            <option value="01376686">Donald</option>
            <option value="01376687">Pluto</option>
      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);

       WTAI - example with WML and
              WMLScript (2)
<?xml version="1.0"?>
    <card id="card_one" title="Tele voting">
        <do type="accept"> <go href="#card_two"/> </do>
        <p> Please choose your candidate! </p>
    <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 id="showResult" title="Result">
        <p> Status: $Message $No </p>
</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

                                 Push Proxy     Push
                  Push OTA        Gateway       Access
      Client                                                  Push Initiator
                  Protocol                      Protocol

    User Agents                                                   Server

         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"?>
      Salad special: The 5 minute offer
         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"?>

Examples for WAP protocol stacks
           (WAP 1.x)
                                                  WAP standardization
   WAE user agent

                                                      outside WAP

                           transaction based
         WSP                   application
                                                       datagram based
         WTP                      WTP                    application
               WTLS                     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
                                                    pure data application
   application with
  complete protocol                                                          108
                                                     additional security
    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)
       • 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
                                     IP         IP      IP            IP
            PDC-P          PDC-P     L2         L2      L2            L2
                                     L1         L1      L1            L1               109
 Email example: i-mode push with SMS
                                         Popular misconception:
              application                WAP was a failure, i-mode is different
                                         and a success – wrong from a
                                         technology point of view, right from a
                WTP                      business point of view…

                 SMS                          i-mode as a business model:
                                              - content providers get >80%
Operator sends an SMS containing a              of the revenue.
push message if a new email has               - independent of technology
arrived. If the user wants to read the          (GSM/GPRS in Europe,
email, an HTTP get follows with the             PDC-P in Japan – but also
email as response.                              UMTS!)

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)

                  i-mode – technical requirements
Functions                     Descriptions                                                  Statu   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       Voice termination notified and responded during i-mode         M      3GPP standard system
during i-mode session         communications
Content charge billing        Per content charge billed to user                              M      Specifications depend on each
                                                                                                    operator’s billing system
Third party payment           Content charge collection on behalf of Content Provider        M      Specifications depend on each
collection                                                                                          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      M      The ID generation algorithm
                              transmission on each content access                                   should be determined by each
                                                                                                    operator and has to be secret
Number of characters per e-   Number of characters (byte) per e-mail                         M      To be defined by operators
mail                                                                                                (e.g. 500 byte, 1K byte, 10K
Character code set            Character code set supported by browser and used to develop    M                        112
                                                                                                    To be defined by operators
supported                     content
i-mode examples (1)

i-mode examples (2)

i-mode examples (3)

                   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
 Service        Security

                                Multimedia Messaging                Content
discovery       services               (Email)                      formats

  External        Crypto        WAE/WTA User Agent
services EFI     libraries       (WML, XHTMLMP)


                 cation                       Capability Negotiation
                                 Push                                          Cookies
Navigation                       OTA                  Synchronisation

                                                                                                           Protocol framework
  Service                        Hypermedia transfer            Strea-
                   PKI                                                          MMS
  Lookup                         (WTP+WSP, HTTP)                ming

                  Secure                                  Connections
                 transport                                  (TCP with
                                 (WDP, UDP)
                                                         wireless profile)

                  Secure        IPv4      CSD       USSD     GPRS        ...

                                       IPv6     SMS      FLEX    MPAK           ...

      WAP 2.0 example protocol stacks
WAP device     WAP gateway        Web server
   WAE                              WAE
   WSP         WSP                             WAP device       WAP proxy        Web server
                        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
  WAE                               WAE        WAP device                        Web server
  HTTP                              HTTP         WAE                               WAE
   TLS                               TLS         HTTP           IP router          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
 „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
 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
 Java Virtual Machine
   • Virtual Hardware (Processor)
   • KVM (K Virtual Machine)
      • Min. 128 kByte, typ. 256 kByte
      • Optimized for low performance devices                             (MIDP)
      • Might be a co-processor
 Configurations
                                                                      (CDC, CLDC)
   • Subset of standard Java libraries depending technical
     hardware parameters (memory, CPU)                             Java Virtual Machine
   • CLDC (Connected Limited Device Configuration)                     (JVM, KVM)
      • Basic libraries, input/output, security – describes Java
                                                                     Operating system
        support for mobile devices
                                                                   (EPOC, Palm, WinCE)
 Profiles
   • Interoperability of heterogeneous devices belonging to the         Hardware
     same category                                                  (SH4, ARM, 68k, ...)
   • MIDP (Mobile Information Device Profile)
      • Defines interfaces for GUIs, HTTP, application
         support, …
Hardware independent development

                      Summary J2ME
 Idea is more than WAP 1.x or i-mode
  • Full applications on mobile phones, not only a
  • 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
 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
Request to port 80: GET / HTTP/1.0
or:                 GET / HTTP/1.1
Response from server                                      non persistent
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">
    <title>FU-Berlin: Institut f&uuml;r Informatik</TITLE>
    <base href="">
    <link rel="stylesheet" type="text/css" href="http://www.inf.fu-">
    <!--script language="JavaScript" src="fuinf.js"-->

  <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.
           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
   • 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
 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       130
  • heterogeneous devices make approaches more complicated
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
    • 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)
 Enhanced browsers                            mobile client
  • Pre-fetching, caching, off-line use                              enhancement
  • e.g. Internet Explorer, Netscape

 Additional, accompanying                                                server
  • Pre-fetching, caching, off-line use              mobile client
  • e.g. original WebWhacker
  • Problem – not transparent, two different             browser
    ways of accessing content:                                          application
     • Directly to the web server
     • Via the additional application                           web
  System support for WWW in a mobile
              World (2)
 Client Proxy acts as server for the       mobile client
  browser and as client for the web
  server.                                                     client
  • Pre-fetching, caching, off-line use                       proxy
  • e.g., Caubweb, TeleWeb, Weblicator,
    WebWhacker, WebEx, WebMirror                     web

 Network Proxy supports a mobile client     mobile client

  on the network side.
  • adaptive content transformation
    for bad connections, pre-fetching,
    caching                                                   network
  • e.g., TranSend, Digestor                web
                                           server                 133
  System support for WWW in a mobile
              World (3)
 Client and network proxy                 mobile client
  • combination of benefits plus                            client
    simplified protocols                                    proxy
  • e.g., MobiScape, WebExpress

                                                web        network
 Special network subsystem                    server       proxy

  • adaptive content transformation
    for bad connections, pre-fetching,     mobile client
    caching                                                 client
  • e.g., Mowgli                                            proxy

 Additional many proprietary server            web        network
                                               server       proxy
  extensions possible
  • “channels”, content negotiation, ...

To top