Chapter 4 Wireless Internet Introduction What

Chapter 4: Wireless Internet § Introduction § What is Wireless Internet? § Mobile IP § TCP in Wireless Domain § WAP § Optimizing Web over Wireless 1

What is Wireless Internet? § Wireless Internet refers to the extension of the services offered by the Internet to mobile users. § Many issues need to be solved for wireless Internet: • Address mobility: Traditional IP addressing does not support address mobility. Mobile IP is a solution to these network layer issue. • Inefficiency of transport layer protocols: Traditional TCP might falsely identify that the data loss is because of congestion but in fact because of transmission errors and then reduce the transmitting rate. This would make the situation even worse. Indirect-TCP (ITCP), snoop TCP, and mobile TCP are some solutions to these transport layer issues. • Inefficiency of application layer protocols: The capabilities of and the bandwidth for the handheld devices are limited. Traditional application protocols are not efficient for wireless networks. Wireless application protocol (WAP) is some solution to these application layer issues. § This chapter is focused on the issues in network, transport, and application layers and the solutions to these problems. 2

Motivation for Mobile IP § Problem: Routing • based on IP destination address, network prefix (e. g. 156. 26. 10) determines physical subnet • change of physical subnet implies change of IP address to have a topological correct address (standard IP) or needs special entries in the routing tables § Solution : Changing the IP-address? • adjust the host IP address depending on the current location • almost impossible to find a mobile system, DNS updates take to long time • TCP connections break, security problems § Solution: Specific routes to end-systems? • change of all routing table entries to forward packets to the right destination • does not scale with the number of mobile hosts and frequent changes in the location, . security problems 3

Requirements to Mobile IP (RFC 3344, was: 3220, 2002) § Compatibility • Mobile IP remains compatible with all lower layers protocols • no changes to current end-systems and routers required • mobile end-systems can communicate with fixed systems § Efficiency and scalability • only little additional messages to the mobile system required (connection typically via a low bandwidth radio link in Mobile IP) • world-wide support of a large number of mobile systems in the whole Internet § Transparency • mobile end-systems keep their IP address • continuation of communication after interruption of link possible • point of connection to the fixed network can be changed § Security • authentication of all messages related to Mobile IP management 4

Terminology § Mobile Node (MN): system (node) that can change the point of connection to the network without changing its IP address § Home Agent (HA) • system in the home network of the MN, typically a router • registers the location of the MN, tunnels IP datagrams to the COA § Foreign Agent (FA) • system in the current foreign network of the MN, typically a router • forwards the tunneled datagrams to the MN, typically also the default router for the MN § Correspondent Node (CN): communication partner § Care-of Address (COA) • • address of the current tunnel end-point for the MN (at FA or MN) actual location of the MN from an IP point of view can be chosen, e. g. , via DHCP Two types of addresses: • Foreign agent-based COA: The COA could be located at the FA. • Co-located COA: The COA is co-located if the MN acquired additional IP address which acts as COA. 5

Motivation for Mobile IP Data Path for Foreign Agent Care-of Address Data Path for Co-located Care-of Address 6

Motivation for Mobile IP § Problem: Routing • based on IP destination address, network prefix (e. g. 156. 26. 10) determines physical subnet • change of physical subnet implies change of IP address to have a topological correct address (standard IP) or needs special entries in the routing tables § Solution : Changing the IP-address? • adjust the host IP address depending on the current location • almost impossible to find a mobile system, DNS updates take to long time • TCP connections break, security problems § Solution: Specific routes to end-systems? • change of all routing table entries to forward packets to the right destination • does not scale with the number of mobile hosts and frequent changes in the location, . security problems 7

Example network HA MN router home network mobile end-system Internet (physical home network for the MN) FA foreign network router (current physical network for the MN) CN end-system router 8

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

Data transfer from the mobile system HA 1 home network MN sender Internet FA foreign network 1. Sender sends to the IP address of the receiver as usual, FA works as default router CN receiver 10

Overview COA home network router FA router HA MN foreign network Internet router CN home network router HA router FA 2. Internet 3. MN 4. foreign network 1. CN router 11

Mobile IP with Reverse Tunneling § Normally, the Mobile Node sends packets directly back to the Correspondent Node. But this might not work all the time. • Ingress filtering: Some routers filter those packets that don’t have the same network subnet as the network where those packets are sent. For example, Without a reverse tunnel a multicast packet sent from the MN will be filtered by the routers. • Firewalls: Most firewalls filter and drop packets that originate from outside the local network but appear has a source address that belongs to the local network. The packets sent to the home network might be dropped. • Time to live (TTL): TTL in the home network is correct, but might be too low because MN is to far away from the receiver. § Router accept often only “topological correct“ addresses (firewall!) • A packet from the MN encapsulated by the FA is not topological correct in a foreign network or home network. • Reverse tunnels are needed for the MN to participate in multicast. • TTL problems should be solved. 12

Mobile IP with reverse tunneling § With reverse tunneling, the Mobile Node sends packets back to the Correspondent Node through a tunnel between its Care-of Address and the Home Agent. The Home Agent then forwards the packet to the Correspondent Node. § Reverse tunneling does not solve • problems with firewalls, the reverse tunnel can be abused to circumvent security mechanisms (tunnel hijacking) • optimization of data paths, i. e. packets will be forwarded through the tunnel via the HA to a sender (double triangular routing) § The reverse tunneling standard • • Define reverse tunneling as an extension to mobile IP. Designed backwards-compatible to mobile IP An option to mobile IP (RFC 3344) The extensions can be implemented easily and cooperate with those implementations without these extensions. 13

Reverse tunneling (RFC 3024, was: 2344) HA 2 MN home network Internet sender 1 FA 3 CN receiver foreign network 1. MN sends to FA 2. FA tunnels packets to HA by encapsulation 3. HA forwards the packet to the receiver (standard case) 14

Mobile IP with Reverse Tunneling Return Data Path for Reverse Tunnelling with Direct Delivery Style Return Data Path for Reverse Tunneling with Encapsulating Delivery Style 15

Network integration § Agent Advertisement • HA and FA periodically send advertisement messages into their physical subnets • MN listens to these messages and detects, if it is in the home or a foreign network (standard case for home network) • MN reads a COA from the FA advertisement messages § Agent solicitation • MN can search for an FA by sending out solicitation messages. § Registration (always limited lifetime!) • MN signals COA to the HA via the FA, HA acknowledges via FA to MN • these actions have to be secured by authentication § Integration • HA advertises the IP address of the MN (as for fixed systems), i. e. standard routing information • routers adjust their entries, these are stable for a longer time (HA responsible for a MN over a longer period of time) • packets to the MN are sent to the HA, 16 • independent of changes in COA/FA

Agent advertisement § Agent Advertisement • Use ICMP with mobility extension Lifetime: length of time this advertisement is valid. Preference helps a node choose the router 0 7 8 type #addresses 15 16 23 24 checksum lifetime 31 code addr. size router address 1 preference level 1 router address 2 preference level 2 type = 16. . . length = 6 + 4 * #COAs R: registration required type = 16 length sequence number B: busy, no more registrations R B H F M G r T reserved registration lifetime H: home agent COA 1. . . F: foreign agent COA 2 M: minimal encapsulation G: GRE (Generic Routing Encapsulation) r: =0, ignored (former Van Jacobson compression) T: FA supports reverse tunneling 17 reserved: =0, ignored

Registration MN r FA egis requ tration es HA MN r HA egis requ tration es t t regi s requ tration est tion istra reg y repl tion stra regi y repl t tra egis r y repl t § The COA is at the FA § The COA is co-located in MN 18

Mobile IP registration request 0 7 8 type = 1 15 16 S B DMG r T x home address home agent COA 23 24 lifetime 31 identification extensions. . . S: simultaneous bindings B: broadcast datagrams D: decapsulation by MN M mininal encapsulation G: GRE encapsulation r: =0, ignored T: reverse tunneling requested x: =0, ignored 19

Mobile IP registration reply 0 7 8 type = 3 15 16 code home address home agent 31 lifetime identification Example codes: extensions. . . registration successful 0 registration accepted 1 registration accepted, but simultaneous mobility bindings unsupported registration denied by FA 65 administratively prohibited 66 insufficient resources 67 mobile node failed authentication 68 home agent failed authentication 69 requested Lifetime too long registration denied by HA 129 administratively prohibited 131 mobile node failed authentication 133 registration Identification mismatch 135 too many simultaneous mobility bindings 20

Encapsulation § A tunnel establishes a virtual pipe between a tunnel entry and a tunnel endpoint. § Encapsulation is the mechanism of taking a packet consisting of packet header and data and putting it into the data part of a new packet. § Decapsulation is an operation that takes a packet out of the data part of another packet. original IP header new IP header outer header original data new data inner header original data 21

Encapsulation (1) (IP-in-IP encapsulation) § Encapsulation of one packet into another as payload • e. g. IPv 6 in IPv 4 (6 Bone), Multicast in Unicast (Mbone) • here: e. g. IP-in-IP-encapsulation, minimal encapsulation or GRE (Generic Record Encapsulation) § IP-in-IP-encapsulation (mandatory, RFC 2003) • tunnel between HA and COA ver. IHL DS (TOS) length IP identification flags fragment offset TTL IP-in-IP IP checksum IP address of HA Care-of address COA ver. IHL DS (TOS) length IP identification flags fragment offset TTL lay. 4 prot. IP checksum IP address of CN IP address of MN TCP/UDP/. . . payload 22

Encapsulation (2) (Minimal encapsulation) § Minimal encapsulation (optional) • Avoid duplication of identical fields • e. g. TTL, IHL, version, DS (RFC 2474, old: TOS) • only applicable for unfragmented packets, no space left for fragment identification ver. IHL DS (TOS) length IP identification flags fragment offset TTL min. encap. IP checksum IP address of HA care-of address COA lay. 4 protoc. S reserved IP checksum IP address of MN original sender IP address (if S=1) TCP/UDP/. . . payload 23

Generic Routing Encapsulation § Generic routing encapsulation (GRE) supports other network layer protocols in addition to IP. § GRE allows the encapsulation of packets of one protocol suite into the payload portion of a packet of another protocol suite. RFC 1701 IHL DS (TOS) length IP identification flags fragment offset TTL GRE IP checksum IP address of HA Care-of address COA C R K S s rec. rsv. ver. protocol checksum (optional) offset (optional) key (optional) sequence number (optional) routing (optional) ver. IHL DS (TOS) length IP identification flags fragment offset TTL lay. 4 prot. IP checksum IP address of CN IP address of MN original header ver. TCP/UDP/. . . payload outer header GRE header new header original data original header original data new data RFC 2784 C reserved 0 ver. checksum (optional) protocol reserved 1 (=0) 24

Optimization of packet forwarding § Triangular Routing • sender sends all packets via HA to MN • higher latency and network load § Solutions: the optimized mobile IP protocol • • Sender (CN) learns the current location of MN direct tunneling to this location HA informs a sender about the location of MN big security problems! Tunnel hijacking, location exposed § Route optimization • Binding cache: The CN can keep the mapping of MN’s IP address and COA in a cache. • Binding request and binding update: The CN can find the binding using a binding request message, to which the HA responds with a binding update message. • Binding acknowledgement: Conformation of binding. • Binding warning: In some cases, a handoff may occur, but CN may continue 25 to use the old mapping.

Optimization of packet forwarding § Any optimization scheme should try to ensure guaranteed delivery, low latency, and low overhead. § Simultaneous bindings is a feature of Mobile IP that allows an MN to register more than one COA at the same time, that is the HA allows MN to register more than one COA. § The mobile IP variations include four options for packets directed from the MN to the CN and four more options for packets from the CN to the MN. See Table 4. 1 and 4. 2. 26

Change of foreign agent CN HA Data Update FAold FAnew Data MN Data ACK Data Update ACK Data Warning MN changes location Registration Data Request Update ACK Data t 27

Handoffs § A handoff is required when the MN changes its FA because the signal of the current FA becomes weak. § The typical phases involved in handoff are: • Measure the signal strength • Decide where and when to hand off • Establish a new connection § Classification of Handoffs: • Mobile initiated handoff: The MN measures the signal strength and decides the handoff. • Mobile evaluated handoff: The MN measures the signal strength but BS decides the handoff. • Network initiated handoff: the network (BS) measures the signal strength and decides where the MN should be handed over. • Mobile assisted handoff: The MN assists the network initiated scenario by measuring the downlink signal strength. 28

Handoffs § Classification of Handoffs: • Hard handoff: only one active connection at a time. • Soft handoff: two active connections during the handoff. § Signaling procedure-based handoffs: • Forward handoff: MN decides the target BS and requests the target BS for the handoff. • Backward handoff: MN decides the target BS and requests the current BS for the handoff. § Fast handoffs are required to reduce the delay. • Pre-registration handoffs: the registration with the HA takes place before the handoff while the MN is still attached to the old FA. • Post-registration handoffs: registration takes place after the MN is connected to the new FA. 29

Mobility Support § The mobility management can be categorized into two types: • Macro-mobility protocols such as the Mobile IP deal with the inter-domain movement. • Micro-mobility protocols aim to handle local movement (intra-domain) of mobile hosts without interaction with the Mobile IP enabled Internet. § Micro-mobility is required to support: • Efficient local handover inside a foreign domain without involving a home agent • Reduces control traffic on backbone • Especially needed in case of route optimization § Micro-mobility approaches: • • • Handoff Aware Wireless Access Internet Architecture (HAWAII) Cellular IP Terminal Independent Mobility for IP (TIMIP) Hierarchical Mobile IP (HMIP) Hierarchical Mobile IPv 6 (HMIPv 6) § Important criteria: Security Efficiency, Scalability, Transparency, Manageability 30

Macro and Micro mobility Home Agent Macro mobility by Mobile IP Home Network INTERNET FA Macro-mobility handover Micro-mobility handover Gateway as FA Micro mobility domain Handovers in Micro Mobility transparent outside the domain 31

Hierarchical Architecture § Elements in different levels • Access router (AR) • A number of access routers organize access network • Each router incorporates mobility management functions • Access point (AP) • An AR that directly communicates with the mobile terminals at the radio interface • Access Network Gateway (ANG) • The root AR, interfacing with the core IP network • Perform mobility management functions to support Mobile. IP-based macromobility • Mobile terminal (MT) • Runs the user applications • Roaming between different APs 32

Mobile IP and IPv 6 § Mobile IP was developed for IPv 4, but IPv 6 simplifies the protocols • security is integrated and not an add-on, authentication of registration is included • COA can be assigned via auto-configuration (DHCPv 6 is one candidate), every node has address auto-configuration • no need for a separate FA, all routers perform router advertisement which can be used instead of the special agent advertisement; addresses are always co-located • MN can signal a sender directly the COA, sending via HA not needed in this case (automatic path optimization) • “soft“ hand-over, i. e. without packet loss, between two subnets is supported • MN sends the new COA to its old router • the old router encapsulates all incoming packets for the MN and forwards them to the new COA • authentication is always granted 33

HAWAII § Operation: • MN obtains co-located COA and registers with HA • Handover: MN keeps COA, new BS answers Reg. Request and updates routers • MN views BS as foreign agent 1 Internet HA 2 3 4 Backbone Router Crossover Router § Security provisions: • MN-FA authentication mandatory • Challenge/Response Extensions mandatory 4 BS BS Mobile IP 3 MN 2 Mobile IP BS MN DHCP Server 1 DHCP 34

HAWAII: Security § Advantages: • Mutual authentication and Challenge/Response extensions mandatory • Only infrastructure components can influence routing entries § Potential problems: • Co-located COA raises DHCP security issues (DHCP has no strong authentication) • Decentralized security-critical functionality (Mobile IP registration processing during handover) in base stations • Authentication of HAWAII protocol messages unspecified (potential attackers: stationary nodes in foreign network) • MN authentication requires PKI (Public Key Infrastructure) or AAA (Authentication, Authorization, and Accounting) infrastructure 35

HAWAII: Other issues § Advantages: • Transparency: Mostly transparent to MNs (MN sends/receives standard Mobile IP messages) • Explicit support for dynamically assigned home addresses § Disadvantages: • Mixture of co-located COA and FA concepts may not be supported by some MN implementations • No private address support possible because of co-located COA 36

Cellular IP § Operation: • CIP node (gateway) maintains routing entries (soft state) for MNs • Multiple entries possible • Routing entries updated based on packets sent by MN § CIP (Cellular IP) Gateway: • Mobile IP tunnel endpoint • Initial registration processing § Security provisions: • all CIP Nodes share “network key“ • MN key: MD 5(net key, IP addr) • MN gets key upon registration Internet Mobile IP data/control packets from MN 1 BS MN 1 CIP Gateway BS BS packets from MN 2 to MN 1 MN 2 37

Cellular IP: Security § Advantages: • Initial registration involves authentication of MNs and is processed centrally by CIP Gateway • All control messages by MNs are authenticated • Replay-protection (using timestamps) § Potential problems: • • • MNs can directly influence routing entries Network key known to many entities (increases risk of compromise) No re-keying mechanisms for network key No choice of algorithm (always MD 5, prefix+suffix mode) Proprietary mechanisms (not, e. g. , IPSec AH) 38

Cellular IP: Other issues § Advantages: Manageability • Simple and elegant architecture • Mostly self-configuring (little management needed) • Integration with firewalls / private address support possible § Disadvantages: • Efficiency: Multiple-path forwarding may cause inefficient use of available bandwidth • Transparency: Not transparent to MNs (additional control messages) • Security: Public-key encryption of MN keys may be a problem for resource-constrained MNs 39

TIMIP § Terminal Independent Mobility for IP (TIMIP) • An Architecture for IP mobility in wireless access networks • Based on principles similar to those in the HAWAII and Cellular IP architectures • Suited for micro-mobility scenarios • using Mobile IP for macro-mobility § TIMIP can be implemented in the network nodes and work transparently to the IP layer of the terminals § Micro-mobility: Whenever the MN moves within the same TIMIP domain, the route updates and the corresponding acknowledgements will propagate up the hierarchy until the crossover AR is reached. § Macro-mobility: Similar to Cellular IP and HAWAII, TIMIP relies solely on Mobile IP to support macro-mobility. 40

TIMIP architecture Access point (level 1) Access router (level 2) Core Tunneling network Access router (level n-x) Access router (level 2) Access network gateway (level n) Access point (level 1) 41

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

Hierarchical Mobile IP: Security § Advantages: • Local COAs can be hidden, which provides some location privacy • Direct routing between CNs sharing the same link is possible (but might be dangerous) § Potential problems: • Decentralized security-critical functionality (handover processing) in mobility anchor points • MNs can (must!) directly influence routing entries via binding updates (authentication necessary) 43

Hierarchical Mobile IP: Other issues § Advantages: • Handover requires minimum number of overall changes to routing tables • Integration with firewalls / private address support possible § Potential problems: • Not transparent to MNs • Handover efficiency in wireless mobile scenarios: • Complex MN operations • All routing reconfiguration messages sent over wireless link 44

Problems with mobile IP § Security Problems • Registration request by a malicious node • Replay attacks • Tunnel hijacking • A FA can itself be a malicious node. • Authentication with FA problematic, for the FA typically belongs to another organization • Patent and export restrictions • IETF is working on the protocol for key management and key distribution has been standardized in the Internet. § Firewalls • typically mobile IP cannot be used together with firewalls, special set-ups are needed (such as reverse tunneling) § Qo. S • many new reservations in case of RSVP (Resource re. Ser. Vation Protocol) • tunneling makes it hard to give a flow of packets a special treatment needed for the Qo. S § Security, firewalls, Qo. S etc. are topics of current research and discussions!45

Security in Mobile IP § Security requirements (Security Architecture for the Internet Protocol, RFC 1825) • Integrity any changes to data between sender and receiver can be detected by the receiver • Authentication sender address is really the address of the sender and all data received is really data sent by this sender • Confidentiality only sender and receiver can read the data • Non-Repudiation (Non-Denial of the message previously sent) • sender cannot deny sending of data (The sender can prove that the message was in fact received by the alleged receiver. ) • The receiver can prove that the message was in fact sent by the alleged sender. • Traffic Analysis creation of traffic and user profiles should not be possible • Replay Protection 46 receivers can detect replay of messages

IP security architecture (1) § Two or more partners have to negotiate security mechanisms to setup a security association • typically, all partners choose the same parameters and mechanisms § Two headers have been defined for securing IP packets: • Authentication-Header • guarantees integrity and authenticity of IP packets • if asymmetric encryption schemes are used, non-repudiation can also be guaranteed IP-Header IP header Authentification-Header authentication header UDP/TCP-Paket UDP/TCP data • Encapsulation Security Payload • protects confidentiality between communication partners not encrypted IP header encrypted ESP header encrypted data 47

IP security architecture (2) § Mobile Security Association for registrations • parameters for the mobile host (MH), home agent (HA), and foreign agent (FA) § Extensions of the IP security architecture • extended authentication of registration MH-FA authentication FA-HA authentication MH-HA authentication registration request MH registration reply registration request FA registration reply HA • prevention of replays of registrations • time stamps: 32 bit time stamps + 32 bit random number • nonces: 32 bit random number (MH) + 32 bit random number (HA) 48

Key distribution § Home agent distributes session keys FA HA MH response: EHA-FA {session key} EHA-MH {session key} § foreign agent has a security association with the home agent § mobile host registers a new binding at the home agent § home agent answers with a new session key foreign agent and 49 mobile node

MRSVP – Resource Reservation § The current Resource re. Ser. Vation Protocol (RSVP) is not adequate for mobile and wireless networks. § Mobility-aware RSVP protocols: • Require that an MN must be able to make advance reservations along data flow paths. • Have information on the set of locations from which the MN requires reservations, mobility specification (MSPEC). • Two types of reservations: • Active: an active reservation is a normal RSVP-like reservation that is on the data flow path from the current location of the MN. • Passive: A passive reservation is made along all paths to and from other locations in MSPEC of the MN. § Components in MRSVP: • Proxy agents (PAs) make reservations on behalf of mobile senders and receivers. • A local proxy agent (LPA) is that to which the MN is currently attached. • Every other agent in the MSPEC will be a remote proxy agent (RPA). 50

MRSVP – Resource Reservation § MRSVP Schemes: • The sender periodically generates ACTIVE PATH messages, and for a mobile sender the Pas will send PASSIVE PATH messages. • The PAs for a mobile receiver send the PASSIVE RESV messages while the receiver itself sends the ACTIVE RESV message. § The key issues: • The identification of proxy agents perform the reservations on behalf of an MN. • The identification of flow anchors, a sender. Anchor act as fixed points in the flow path. • The establishment of both active and passive reservations for the MN according to the MSPEC. • The actual message sequences that lead to the reservation depend on the type of the follow and the strategy adopted. 51

DHCP: Dynamic Host Configuration Protocol § Application • simplification of installation and maintenance of networked computers • supplies systems with all necessary information, such as IP address, DNS server address, domain name, subnet mask, default router etc. • enables automatic integration of systems into an Intranet or the Internet, can be used to acquire a COA for Mobile IP § Client/Server-Model • the client sends via a MAC broadcast a request to the DHCP server (might be via a DHCP relay) DHCPDISCOVER server client relay 52

DHCP - Protocol Mechanisms client initialization server (not selected) DHCPDISCOVER DHCPOFFER determine the configuration server (selected) DHCPOFFER determine the configuration collection of replies time selection of configuration DHCPREQUEST (reject) DHCPREQUEST (options) confirmation of configuration DHCPACK initialization completed release DHCPRELEASE delete context 53

DHCP Characteristics § Server • several servers can be configured for DHCP, coordination not yet standardized (i. e. , manual configuration) § Renewal of configurations • IP addresses have to be requested periodically, simplified protocol § Options • available for routers, subnet mask, NTP (network time protocol) timeserver, SLP (service location protocol) directory, DNS (domain name system) § Big security problems! • no authentication of DHCP information specified 54

Mobile ad hoc networks § Standard Mobile IP needs an infrastructure • Home Agent/Foreign Agent in the fixed network • DNS, routing etc. are not designed for mobility § Sometimes there is no infrastructure! • remote areas, ad-hoc meetings, disaster areas • cost can also be an argument against an infrastructure! § Main topic: routing • no default router available • every node should be able to forward A B C 55

Manet: Mobile Ad-hoc Networking Mobile Router Manet Mobile Devices Mobile IP, DHCP Fixed Network Router End system 56

Transport layer § Functions of Transport layer: • Provide point-to-point communication (process to process) • Multiplex/de-multiplex data from/to applications. • determine the service to the session layer • TCP (Transmission Control Protocol) – connection-oriented, in-order reliable data transmission • UDP (User Datagram Protocol) – connectionless, unreliable data transmission. § TCP Examples: • • • SMTP (Simple Mail Transfer Protocol) – electronic mail Telnet (remote login) FTP (File Transfer Protocol) HTTP (Hyper. Text Transfer Protocol) NNTP (Network News Transfer Protocol) BGP (Border Gateway Protocol) – routing 57

Transport Layer Examples § E. g. HTTP (used by web services) typically uses TCP • Reliable transport between client and server required § TCP • Steam oriented, not transaction oriented • Network friendly: time-out congestion slow down transmission § Well known – TCP guesses quite often wrong in wireless and mobile networks Client TCP SYN/ACK Server Connection setup TCP ACK HTTP request HTTP response Data transmission >15 s no data GPRS: 500 ms! Connection release • Packet loss due to transmission errors • Packet loss due to change of network § Result • Severe performance degradation 58

Traditional TCP (1) § Transport protocols typically designed for • Fixed end-systems • Fixed, wired networks § Research activities • Performance • Congestion control • Efficient retransmissions § TCP congestion control • packet loss in fixed networks is typically due to (temporary) overload situations • router have to discard packets as soon as the buffers are full • TCP recognizes congestion only indirect via missing acknowledgements, retransmissions unwise, they would only contribute to the congestion and make it even worse • slow-start algorithm as reaction 59

Traditional TCP (2) § TCP slow-start algorithm • sender calculates a congestion window for a receiver • start with a congestion window size equal to one segment • exponential increase of the congestion window up to the congestion threshold, then linear increase • missing acknowledgement causes the reduction of the congestion threshold to one half of the current congestion window • congestion window starts again with one segment § TCP fast retransmit/fast recovery • TCP sends an acknowledgement only after receiving a packet • if a sender receives several acknowledgements for the same packet, this is due to a gap in received packets at the receiver (So the receiver keeps acknowledging the same packet. ) • however, the receiver got all packets up to the gap and is actually receiving packets • therefore, packet loss is not due to congestion, continue with current congestion window (do not use slow-start) 60 • The sender then performs fast retransmission and a fast recovery.

TCP Over Wireless § TCP assumes congestion if packets are dropped • typically wrong in wireless networks, here we often have packet loss due to transmission errors • furthermore, mobility itself can cause packet loss, if e. g. a mobile node roams from one access point (e. g. foreign agent in Mobile IP) to another while there are still packets in transit to the wrong access point and forwarding is not possible § The performance of an unchanged TCP degrades severely • however, TCP cannot be changed fundamentally due to the large base of installation in the fixed network, TCP for mobility has to remain compatible • the basic TCP mechanisms keep the whole Internet together 61

TCP Over Wireless TCP over Wireless Link layer solutions Snoop TCP-unaware link layer Split approach based solutions I-TCP M-TCP End-to-end solutions ELN WTCP SACK TTCP 62

Early approach: Snooping TCP (1) § “Transparent“ extension of TCP within the foreign agent • buffering of packets sent to the mobile node • lost packets on the wireless link (both directions!) will be retransmitted immediately by the mobile node or base station (foreign agent), respectively (so called “local” retransmission) • the foreign agent therefore “snoops” the packet flow and recognizes acknowledgements in both directions, it also filters ACKs • changes of TCP only within the foreign agent local retransmission correspondent node (host) Foreign agent (base station) “wired“ Internet snooping of ACKs mobile node (host) buffering of data end-to-end TCP connection 63

Snooping TCP (2) § Data transfer to the mobile host • FA buffers data until it receives ACK of the MH, FA detects packet loss via duplicated ACKs (DUPACKs) or time-out • fast retransmission possible, transparent for the fixed network § Data transfer from the mobile host • FA detects packet loss on the wireless link via sequence numbers, FA answers directly with a NACK to the MH • MH can now retransmit data with only a very short delay § Integration of the MAC layer • MAC layer often has similar mechanisms to those of TCP • thus, the MAC layer can already detect duplicated packets due to retransmissions and discard them § Problems • snooping TCP does not isolate the wireless link as good as I-TCP • snooping might be useless depending on encryption schemes 64

TCP-Unaware Link Layer § This strategy aims at simulating the behavior of the snoop-TCP protocol without requiring the link layer at the BS to be TCPaware. § The usage of delayed duplicate acknowledgements (DUPACKs) imitates snoop-TCP without requiring the link layer at BS to be TCP-aware. § In snoop-TCP retransmissions are triggered by TCP duplicate acknowledgements, but in TCP-unaware link layer retransmissions are triggered by link level ACKs. § Advantage: The link layer needs not be TCP-aware. § Disadvantage: The optimum value of duplicate acknowledgements delay depends on the wireless link, and this value is crucial in determining the performance. 65

Indirect TCP (1) § Indirect TCP or I-TCP segments the connection • no changes to the TCP protocol for hosts connected to the wired Internet, millions of computers use (variants of) this protocol • optimized TCP protocol for mobile hosts • splitting of the TCP connection at, e. g. , the foreign agent into 2 TCP connections, no real end-to-end connection any longer • hosts in the fixed part of the network do notice the characteristics of the wireless part mobile node (host) access point (foreign agent) „wireless“ TCP „wired“ Internet standard TCP 66

I-TCP Socket and State Migration access point 1 socket migration and state transfer Internet access point 2 mobile host § The old access point acts as a foreign agent buffering and forwarding the packets to the new access point (foreign agent) 67

Indirect TCP (2) § Advantages • no changes in the fixed network necessary, no changes for the hosts (TCP protocol) necessary, all current optimizations to TCP still work • transmission errors on the wireless link do not propagate into the fixed network • simple to control, mobile TCP is used only for one hop between, e. g. , a foreign agent and mobile host • therefore, a very fast retransmission of packets is possible, the short delay on the mobile hop is known § Disadvantages • loss of end-to-end semantics, now an acknowledgement to a sender does not any longer mean that a receiver really got a packet, foreign agents might crash • higher latency possible due to buffering of data within the foreign agent and forwarding to a new foreign agent 68

Mobile TCP § Special handling of lengthy and/or frequent disconnections § M-TCP splits as I-TCP does • unmodified TCP fixed network to supervisory host (SH) • optimized TCP SH to MN § Supervisory host (the node in the wired network that controls a number of APs) • no caching, no retransmission • monitors all packets, if disconnection detected • set sender window size to 0 • sender automatically goes into persistent mode (the state of the sender will not change no matter how long the receiver is disconnected. ) • old or new SH reopen the window § Advantages • maintains semantics, supports disconnection, no buffer forwarding § Disadvantages • loss on wireless link propagated into fixed network • adapted TCP on wireless link 69

Explicit Loss Notification - ELN § The problem with TCP lies in the fact that it does not know the exact cause for packet loss, and hence has to invariably assume congestion loss. § In this situation an idea TCP simply retransmit the lost packet without congestion control mechanism. § The strategy is to detect loss at MN and send an explicit loss notification (ELN) to the sender. § The sender does not reduce the window size on receiving ELN. This avoids slow start and can handle encrypted data. § Disadvantage: This protocol requires the MAC layer of MN to be changed. The information conveyed by the MAC layer might not always be reliable. 70

WTCP § WTCP (Reliable Transport Protocol for Wireless Wide-Area Networks) aims at revamping the transport protocol for the wireless domain using: • • Rate-based transmission at the source Inter-packet separation at the receiver as the congestion metric Mechanisms for detecting the reason for packet loss Bandwidth estimation § A unique characteristic of WTCP is the attempt to separate the congestion control and reliability mechanisms. § WTCP uses separate sequence numbers for congestion control and reliability mechanisms in order to distinguish the two. § The reliability mechanism involves a combination of selective and cumulative acknowledgements, and takes into account the reservepath characteristics for determining the ACK frequency. 71

TCP SACK – Selective Retransmission § TCP acknowledgements are often cumulative • ACK n acknowledges correct and in-sequence receipt of packets up to n • if single packets are missing quite often a whole packet sequence beginning at the gap has to be retransmitted (go-back-n), thus wasting bandwidth § Selective retransmission as one solution – TCP with selective ACK (TCP SACK) • RFC 2018 allows for acknowledgements of single packets, not only acknowledgements of in-sequence packet streams without gaps • sender can now retransmit only the missing packets § Advantage • much higher efficiency § Disadvantage • more complex software in a receiver, more buffer needed at the receiver 72

Transaction-Oriented TCP § TCP phases • connection setup, data transmission, connection release • using 3 -way-handshake needs 3 packets for setup and release, respectively • thus, even short messages need a minimum of 7 packets! § Transaction oriented TCP • RFC 1644, T-TCP, describes a TCP version to avoid this overhead • connection setup, data transfer and connection release can be combined • thus, only 2 or 3 packets are needed § Advantage • efficiency § Disadvantage • requires changed TCP • mobility not longer transparent 73

Impact of Mobility – Fast Retransmit/Fast Recovery § Change of foreign agent often results in packet loss • TCP reacts with slow-start although there is no congestion § Forced fast retransmit • as soon as the mobile host has registered with a new foreign agent, the MH sends duplicated acknowledgements on purpose • this forces the fast retransmit mode at the communication partners • additionally, the TCP on the MH is forced to continue sending with the actual window size and not to go into slow-start after registration § Advantage • simple changes result in significant higher performance § Disadvantage • further mix of IP and TCP, no transparent approach 74

Transmission/Time-out Freezing § Mobile hosts can be disconnected for a longer time • no packet exchange possible, e. g. , in a tunnel, disconnection due to overloaded cells or multiplexed with higher priority traffic • TCP disconnects after time-out completely § TCP freezing • • MAC layer is often able to detect interruption in advance MAC can inform TCP layer of upcoming loss of connection TCP stops sending, but does now not assume a congested link MAC layer signals again if reconnected § Advantage • scheme is independent of data § Disadvantage • TCP on mobile host has to be changed, mechanism depends on MAC layer 75

Comparison of different approaches for a “mobile” TCP 76

TCP Improvements (1) § Initial research work • Indirect TCP, Snoop TCP, M-TCP, T/TCP, SACK, Transmission/time-out freezing, … § TCP over 2. 5/3 G wireless networks • max. TCP Band. Width • Max. Segment Size • Round Trip Time • loss probability • Fine tuning today’s TCP • Learn to live with • Data rates: 64 kbit/s up, 115 -384 kbit/s down; asymmetry: 3 -6, but also up to 1000 (broadcast systems), periodic allocation/release of channels • High latency, high jitter, packet loss • Suggestions • Large (initial) sending windows, large maximum transfer unit, selective acknowledgement, explicit congestion notification, time stamp, no header compression • Already in use • i-mode running over FOMA 77 • WAP 2. 0 (“TCP with wireless profile”)

TCP Improvements (2) § Performance enhancing proxies (PEP, RFC 3135) • Transport layer • Local retransmissions and acknowledgements • Additionally on the application layer • Content filtering, compression, picture downscaling • E. g. , Internet/WAP gateways • Web service gateways? • Big problem: breaks end-to-end semantics • Disables use of IP security • Choose between PEP and security! § More open issues • RFC 3150 (slow links) • Recommends header compression, no timestamp • RFC 3155 (links with errors) • States that explicit congestion notification cannot be used • In contrast to 2. 5 G/3 G recommendations! Mobile system wireless PEP Internet Comm. partner 78

WAP - Wireless Application Protocol § WAP (Wireless Application Protocol) • a specification for a set of communication protocols to standardize the way that wireless devices, such as cellular telephones and radio transceivers, can be used for Internet access, including e-mail, the World Wide Web, newsgroups, and Internet Relay Chat (IRC). § Goals • deliver Internet content and enhanced services to mobile devices and users (mobile phones, PDAs) • independence from wireless network standards • open for everyone to participate, protocol specifications will be proposed to standardization bodies • applications should scale well beyond current transport media and device types and should also be applicable to future developments § Platforms • e. g. , GSM (900, 1800, 1900), CDMA IS-95, TDMA IS-136, 3 rd generation systems (IMT-2000, UMTS, W-CDMA, cdma 2000 1 x EV-DO, …) 79

WAP - scope of standardization § Forum • was: WAP Forum, co-founded by Ericsson, Motorola, Nokia, Unwired Planet, further information www. wapforum. org • now: Open Mobile Alliance www. openmobilealliance. org (Open Mobile Architecture + WAP Forum + Sync. ML + …) § Browser • “micro browser”, similar to existing, well-known browsers in the Internet § Script language • similar to Java script, adapted to the mobile environment § WTA/WTAI • Wireless Telephony Application (Interface): access to all telephone functions § Content formats • e. g. , business cards (v. Card), calendar events (v. Calender) § Protocol layers • transport layer, security layer, session layer etc. 80

WAE logical model Origin Servers web server other content server Gateway response with content push content request encoders & decoders Client encoded response with content encoded push content encoded request WTA user agent WML user agent other WAE user agents § WAP adopts a client-server approach. § It specifies a proxy server that acts as an interface between the wireless domain and core wired network. 81

WAP 1. x - reference model and protocols Internet HTML, Java A-SAP WAP Application Layer (WAE) S-SAP additional services and applications Session Layer (WSP) HTTP TR-SAP Transaction Layer (WTP) SEC-SAP SSL/TLS Security Layer (WTLS) T-SAP TCP/IP, UDP/IP, media Transport Layer (WDP) WCMP Bearers (GSM, CDPD, . . . ) WAE comprises WML (Wireless Markup Language), WML Script, WTAI etc. 82

WAP § The Wireless Application Environment (WAE) - Application layer • a general-purpose application environment based on a combination of World Wide Web (WWW) and mobile telephony technologies. WAE includes a micro-browser environment containing the following functionalities: • Wireless Markup Language (WML) A lightweight markup language, similar to HTML, but optimized for use in hand -held mobile terminals; • WMLScript A lightweight scripting language, similar to Java. Script • Wireless Telephony Application (WTA) Telephony services and programming interfaces. § Wireless Session Protocol (WSP) - Session layer • gives the functionality of HTTP but in a more optimized way. § Wireless Transaction Protocol (WTP) – Session layer • runs on top of a datagram service and provides as a light-weight transaction-oriented protocol. § Wireless Transport Layer Security (WTLS) – Transport layer • a security protocol analogous to the industry-standard Transport Layer Security (TLS) protocol, formerly known as Secure Sockets Layer (SSL) in WWW model. § Wireless Datagram Protocol (WDP) – Transport layer • The Transport layer protocol in the WAP architecture is referred to as the Wireless 83 Datagram Protocol (WDP).

WAP - network elements fixed network Internet HTML wireless network WML filter WAP proxy Binary WML HTML web server HTML filter/ WAP proxy WTA server Binary WML PSTN Binary WML: binary file format for clients 84

WDP - Wireless Datagram Protocol § Protocol of the transport layer within the WAP architecture • uses directly transports mechanisms of different network technologies • offers a common interface for higher layer protocols • allows for transparent communication using different transport technologies (GSM [SMS, CSD, USSD, GPRS, . . . ], IS-136, TETRA, DECT, PHS, IS-95, . . . ) § Goals of WDP • create a worldwide interoperable transport system with the help of WDP adapted to the different underlying technologies • transmission services such as SMS, GPRS in GSM might change, new services can replace the old ones § Additionally, WCMP (wireless Control Message Protocol) is used for control/error report (similar to ICMP in the TCP/IP protocol suite) 85

Usage of WDP Wireless Data Gateway WTLS WDP & Adaptation SMS Tunnel Subnetwork GSM-SMS WTLS WDP & Adaptation Tunnel Subnetwork SMS WAP Proxy GSM-CSD WTLS Internet Service Provider Remote Access Service UDP IP PPP CSD-RF Interworking Function CSD-RF PSTN Circuit IP PPP PSTN Circuit § GSM-CSD (GSM Circuit Switched Data) Subnetwork WTLS UDP IP Subnetwork 86

WTLS - Wireless Transport Layer Security § Goals • data integrity • prevention of changes in data • privacy • prevention of tapping • authentication • creation of authenticated relations between a mobile device and a server • protection against denial-of-service attacks • protection against repetition of data and unverified data § WTLS • is based on the TLS (Transport Layer Security) protocol (former SSL, Secure Sockets Layer) • optimized for low-bandwidth communication channels 87

WTP - Wireless Transaction Protocol § Goals • different transaction services, offloads applications • application can select reliability, efficiency • support of different communication scenarios • class 0: unreliable message transfer • class 1: reliable message transfer without result message • class 2: reliable message transfer with exactly one reliable result message • supports peer-to-peer, client/server and multicast applications • low memory requirements, suited to simple devices (< 10 kbyte ) • efficient for wireless transmission • • segmentation/reassembly selective retransmission header compression optimized connection setup (setup with data transfer) 88

Details of WTP (1) § Support of different communication scenarios • Class 0: unreliable message transfer • Example: push service • Class 1: reliable request • An invoke message is not followed by a result message • Example: reliable push service • Class 2: reliable request/response • An invoke message is followed by exactly one result message • With and without ACK • Example: typical web browsing § No explicit connection setup or release is available § Services for higher layers are called events 89

Details of WTP (2) § Used Mechanisms • Reliability • • • Unique transaction identifiers (TID) Acknowledgements Selective retransmission Duplicate removal Optional: concatenation & separation of messages Optional: segmentation & reassembly of messages Asynchronous transactions Transaction abort, error handling Optimized connection setup (includes data transmission) 90

WSP - Wireless Session Protocol § Goals • HTTP 1. 1 functionality • Request/reply, content type negotiation, . . . • support of client/server, transactions, push technology • key management, authentication, Internet security services • session management (interruption, resume, . . . ) § Open topics • • Qo. S support) Group communication Isochronous media objects management 91

WSP protocols WSP Connection mode (uses WTP) Connectionless mode (uses WDP or WTLS) • Session Management (class 0, 2) • Method Invocation (Kl. 2) • Push • Error Report (in general unreliable) • Push (class 0) • Confirmed Push (class 1) • Session suspend/resume (class 0, 2) 92

WAE - Wireless Application Environment § Goals • network independent application environment for low-bandwidth, wireless devices • integrated Internet/WWW programming model with high interoperability § Requirements • device and network independent, international support • manufacturers can determine look-and-feel, user interface • considerations of slow links, limited memory, low computing power, small display, simple user interface (compared to desktop computers) § Components • • architecture: application model, browser, gateway, server WML: XML-Syntax, based on card stacks, variables, . . . WMLScript: procedural, loops, conditions, . . . (similar to Java. Script) WTA: telephone services, such as call control, text messages, phone book, . . . (accessible from WML/WMLScript) 93 • content formats: v. Card, v. Calendar, Wireless Bitmap, WML, . . .

Wireless Markup Language (WML) § WML (Wireless Markup Language) is a language that allows the text portions of Web pages to be presented on cellular telephones and personal digital assistants (PDAs) via wireless access. § WML follows deck and card metaphor • • WML document consists of many cards, cards are grouped to decks a deck is similar to an HTML page, unit of content transmission WML describes only intent of interaction in an abstract manner presentation depends on device capabilities § Features • • text and images user interaction navigation context management 94

WML – example (1)

This is a simple first card!
On the next one you can choose. . .

" src="https://present5.com/presentation/ac4dd66bda92cb4acfc4e26ce2bdfc28/image-96.jpg" alt="WML – example (2) " /> WML – example (2)

. . . your favorite pizza! Margherita Funghi Vulcano

WMLScript § WMLScript is the scripting language used in WML pages. § Complement to WML § Provides general scripting capabilities § Features • validity check of user input • check input before sent to server • access to device facilities • hardware and software (phone call, address book etc. ) • local user interaction • interaction without round-trip delay • extensions to the device software • configure device, download new functionality after deployment 97

WMLScript - Example function pizza_test(pizza_type) { var taste = "unknown"; if (pizza_type = "Margherita") { taste = "well. . . "; } else { if (pizza_type = "Vulcano") { taste = "quite hot"; }; }; return taste; }; 98

Wireless Telephony Application (WTA) § The Wireless Telephony API is an API and framework for accessing telephony and network services. § Collection of telephony specific extensions § Extension of basic WAE application model • content push • server can push content to the client • client may now be able to handle unknown events • handling of network events • table indicating how to react on certain events from the network • access to telephony functions • any application on the client may access telephony functions § Example • calling a number (WML) wtai: //wp/mc; 07216086415 • calling a number (WMLScript) WTAPublic. make. Call("07216086415"); 99

WTA logical architecture other telephone networks WTA server client WML scripts WML decks WTA services network operator trusted domain third party servers mobile network WTA user agent WAP gateway WTA & WML server repository encoders & decoders other servers device specific functions firewall 100

Voice box example WTA-User-Agent WTA-Gateway WTA-Server Mobile network Indicate new voice message Voice box server Generate new deck Service Indication Display deck; user selects WSP Get Binary WML Push URL HTTP Get WML Respond with content HTTP Get WML Respond with card for call Play requested voice message Wait for call Call setup Setup call Accept call Voice connection 101

WTAI - example with WML only

Please choose your candidate!

WTAI - example with WML and WMLScript (1) function vote. Call(Nr) { var j = WTACall. Control. setup(Nr, 1); if (j>=0) { WMLBrowser. set. Var("Message", "Called"); WMLBrowser. set. Var("No", Nr); } else { WMLBrowser. set. Var("Message", "Error!"); WMLBrowser. set. Var("No", j); } WMLBrowser. go("show. Result"); } 103

WTAI - example with WML and WMLScript (2)

Please choose your candidate!

WAP push architecture with proxy gateway § Push Access Protocol • Content transmission between server and PPG (Push Proxy Gateway) • First version uses HTTP § Push OTA (Over The Air) Protocol • Simple, optimized • Mapped onto WSP Client User Agents Push OTA Protocol Push Proxy Gateway Coding, checking Push Access Protocol Push Initiator Server application 105

Push/Pull services in WAP (1) § Service Indication • Service announcement using a pushed short message • Service usage via a pull • Service identification via a URI Salad special: The 5 minute offer 106

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 107

Examples for WAP protocol stacks (WAP 1. x) WAP standardization WAE user agent outside WAP WAE WSP transaction based application WTP WTLS datagram based application WTLS UDP WDP IP non IP (GPRS, . . . ) (SMS, . . . ) 1. typical WAP application with complete protocol stack (GPRS, . . . ) (SMS, . . . ) 2. (GPRS, . . . ) (SMS, . . . ) 3. pure data application with/without additional security 108

i-mode – first of all a business model! § i-mode is a proprietary packet-based information service for mobile phones by NTT Do. Co. Mo. § Access to Internet services in Japan provided by NTT Do. Co. Mo • Services • Email, short messages, web, picture exchange, horoscope, . . . • Big success – more than 44. 3 million users (April 2005) (http: //www. nttdocomo. com/companyinfo/subscriber. html) • Many use i-mode as PC replacement • For many this is the first Internet contact • Very simple to use, convenient • Technology • 9. 6 kbit/s (enhancements with 28. 8 kbit/s), packet oriented (PDC-P) • Compact HTML (c. HTML) plus proprietary tags, special transport layer (Stop/go, ARQ, push, connection oriented) mobile terminal mobile network c. HTML + tags HTTP(S) TL TL PDC-P TCP IP L 2 L 1 gateway TCP IP L 2 L 1 content provider c. HTML + tags HTTP(S) TCP IP L 2 L 1 109

Email example: i-mode push with SMS application WSP WTP Popular misconception: WAP was a failure, i-mode is different and a success – wrong from a technology point of view, right from a business point of view… WDP SMS Operator sends an SMS containing a push message if a new email has arrived. If the user wants to read the email, an HTTP get follows with the email as response. i-mode as a business model: - content providers get >80% of the revenue. - independent of technology (GSM/GPRS in Europe, PDC-P in Japan – but also UMTS!) 110

i-mode protocol stack based on WAP 2. 0 user equipment gateway server c. HTML HTTP c. HTML SSL HTTP WTCP TCP IP IP L 2 L 2 L 1 L 1 i-mode can use WAP 2. 0/Internet protocols (example: i-mode in Germany over GSM/GPRS) 111

i-mode – technical requirements Functions Descriptions Status Requirement WEB Access Portal Site / Internet Access M i-mode HTML (c. HTML+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 application made available O Compatible i-mode JAVA Ringing tone download Ringing melody download M SMF based Image download Stand-by screen download M GIF (O: JPEG) Voice call notification during i-mode session Voice termination notified and responded during i-mode communications M 3 GPP standard system Content charge billing Per content charge billed to user M Specifications depend on each operator’s billing system Third party payment collection Content charge collection on behalf of Content Provider M Specifications depend on each operator’s billing system Reverse billing Packet usage charges can be billed to third party O Specifications depend on each operator’s billing system Subscriber ID transmission Hashed subscriber ID from the operator’s portal to the CP transmission on each content access M The ID generation algorithm should be determined by each operator and has to be secret Number of characters per email Number of characters (byte) per e-mail M To be defined by operators (e. g. 500 byte, 1 K byte, 10 K byte) Character code set supported by browser and used to develop content M To be defined by operators User Agent Browser specifications to be notified M HTTP 1. 1 112

i-mode examples (1) 113

i-mode examples (2) 114

i-mode examples (3) 115

WAP 2. 0 (July 2001) § WAP 2. 0 supports: • XHTML with a mobile profile (XHTMLMP) • TCP with „Wireless Profile“ • HTTP § WAP 2. 0 framework consists of: • • Bearer networks: GPRS Transport services: TCP, WDP or UDP Transfer services: HTTP, Multi-media messaging Service (MMS) Session services: push OTA (Over The Air) § New applications • • • Color graphics Animation Large file download Location based services Synchronization with PIMs Pop-up/context sensitive menus § Goal: integration of WWW, Internet, WAP, i-mode 116

WAP 2. 0 architecture Crypto libraries WAE/WTA User Agent (WML, XHTMLMP) Push Provisioning Authentication Identification Service Lookup PKI Secure transport Secure bearer Push OTA Hypermedia transfer (WTP+WSP, HTTP) CSD IPv 6 Streaming MMS Connections (TCP with wireless profile) Datagrams (WDP, UDP) IPv 4 Cookies Synchronisation Transport Navigation Discovery Capability Negotiation USSD SMS GPRS FLEX MPAK . . . Protocol framework External services EFI Application framework Content formats Session Multimedia Messaging (Email) Transfer Security services Bearer Service discovery 117

WAP 2. 0 example protocol stacks WAP device WAE WSP WTLS WDP bearer WAP gateway WSP WTLS WDP bearer Web server WAE HTTP TLS TCP IP WAP 1. x Server/Gateway/Client WAP device WAE HTTP TLS TCP‘ IP WAP proxy TCP‘ IP TCP IP Web server WAE HTTP TLS TCP IP WAP Proxy with TLS tunneling WAP device WAE HTTP‘ TCP‘ IP WAP proxy HTTP‘ TCP‘ IP HTTP TCP IP Web server WAE HTTP TCP IP WAP HTTP Proxy with profiled TCP and HTTP WAP device WAE HTTP TCP IP IP router IP IP Web server WAE HTTP TCP IP WAP direct access 118

Java 2 Platform Micro Edition § „Java-Boom expected“ (? ) • Desktop: over 90% standard PC architecture, Intel x 86 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 § J 2 ME • Provides a uniform platform • Restricted functionality compared to standard java platform (JVM) 119

Applications of J 2 ME § Example cellular phones • NTT Do. Co. Mo introduced i ppli • Applications on PDA, mobile phone, . . . • Game download, multimedia applications, encryption, system updates • Load additional functionality with a push on a button (and pay for it)! § Embedded control • Household devices, vehicles, surveillance systems, device control • System update is an important factor 120

Characteristics and architecture § Java Virtual Machine • Virtual Hardware (Processor) • KVM (K Virtual Machine) • Min. 128 k. Byte, typ. 256 k. Byte • Optimized for low performance devices • Might be a co-processor § Configurations • Subset of standard Java libraries depending technical hardware parameters (memory, CPU) • CLDC (Connected Limited Device Configuration) • Basic libraries, input/output, security – describes Java support for mobile devices § Profiles • Interoperability of heterogeneous devices belonging to the same category • MIDP (Mobile Information Device Profile) • Defines interfaces for GUIs, HTTP, application support, … Applications Profile (MIDP) Configurations (CDC, CLDC) Java Virtual Machine (JVM, KVM) Operating system (EPOC, Palm, Win. CE) Hardware (SH 4, ARM, 68 k, . . . ) 121

Hardware independent development 122

Summary J 2 ME § Idea is more than WAP 1. x or i-mode • Full applications on mobile phones, not only a browser • Includes system updates, end-to-end encryption § Platform independent via virtualization • As long as certain common interfaces are used • Not valid for hardware specific functions § Limited functionality compared to JVM • Thus, maybe an intermediate solution only – until embedded systems, mobile phones are as powerful as today’s desktop systems 123

Optimizing Web over Wireless § Protocol (HTTP, Hypertext Transfer Protocol) and language (HTML, Hypertext Markup Language) of the Web have not been designed for mobile applications and mobile devices, thus creating many problems! § Typical transfer sizes • HTTP request: 100 -350 byte • responses avg. <10 kbyte, header 160 byte, GIF 4. 1 k. Byte, JPEG 12. 8 kbyte, HTML 5. 6 kbyte • but also many large files that cannot be ignored § The Web is no file system • Web pages are not simple files to download • static and dynamic content, interaction with servers via forms, content transformation, push technologies etc. • many hyperlinks, automatic loading and reloading, redirecting • a single click might have big consequences! 124

WWW example Request to port 80: GET / HTTP/1. 0 or: GET / HTTP/1. 1 Host: www. inf. fu-berlin. de Response from server HTTP/1. 1 200 OK Date: Wed, 30 Oct 2002 19: 44: 26 GMT Server: Apache/1. 3. 12 (Unix) mod_perl/1. 24 Last-Modified: Wed, 30 Oct 2002 13: 16: 31 GMT ETag: "2 d 8190 -2322 -3 dbfdbaf" Accept-Ranges: bytes Content-Length: 8994 Connection: close Content-Type: text/html non persistent . . . 125

Optimizing Web over Wireless § HTTP Drawbacks • High connection overhead • Redundant capabilities transmission • Verbosity (HTTP is ASCII-encoded and inherently verbose) § Four main categories of optimization that could improve the performance of Web over wireless channels are: • Caching: cache data persist across browser sessions • Differencing: A base object carries basic features. Whenever a new transaction takes place, the server computes the difference stream and only the difference stream is transmitted. • Protocol reduction: A persistent TCP/IP connection can be set up between client side interface (CSI) and server side interface (SSI). • Header reduction: The CSI sends the header information in the first request and SSI records this information. Then consecutive transmission needs not to send headers each time. 126

HTTP 1. 0 and mobility (1) § Characteristics • stateless, client/server, request/response • needs a connection oriented protocol (TCP), one connection per request (some enhancements in HTTP 1. 1) • primitive caching and security § Problems • designed for large bandwidth (compared to wireless access) and low delay • big and redundant protocol headers (readable for humans, stateless, therefore big headers in ASCII) • uncompressed content transfer • using TCP • huge overhead per request (3 -way-handshake) compared with the content, e. g. , of a GET request • slow-start problematic • DNS lookup by client causes additional traffic 127

HTTP 1. 0 and mobility (2) § Caching • quite often disabled by information providers to be able to create user profiles, usage statistics etc. • dynamic objects cannot be cached • numerous counters, time, date, personalization, . . . • mobility quite often inhibits caches • security problems • how to use SSL/TLS together with proxies? • today: many user customized pages, dynamically generated on request via CGI, ASP, . . . § POSTing (i. e. , sending to a server) • can typically not be buffered, very problematic if currently disconnected § Many unsolved problems! 128

HTML and mobile devices § HTML • designed for computers with “high” performance, color high-resolution display, mouse, hard disk • typically, web pages optimized for design, not for communication § Mobile devices • often only small, low-resolution displays, very limited input interfaces (small touch-pads, soft-keyboards) § Additional “features” • animated GIF, Java AWT, Frames, Active. X Controls, Shockwave, movie clips, audio, . . . • many web pages assume true color, multimedia support, high-resolution and many plug-ins § Web pages ignore the heterogeneity of end-systems! • e. g. , without additional mechanisms, large high-resolution pictures would be transferred to a mobile phone with a low-resolution display causing 129 high costs

Approaches toward WWW for mobile devices § Application gateways, enhanced servers • simple clients, pre-calculations in the fixed network • compression, filtering, content extraction • automatic adaptation to network characteristics § Examples • picture scaling, color reduction, transformation of the document format (e. g. , PS to TXT) • detail studies, clipping, zoom • headline extraction, automatic abstract generation • HDML (handheld device markup language): simple language similar to HTML requiring a special browser • HDTP (handheld device transport protocol): transport protocol for HDML, developed by Unwired Planet § Problems • proprietary approaches, require special enhancements for browsers • heterogeneous devices make approaches more complicated 130

Some new Issues that might help mobility? § Push technology • real pushing, not a client pull needed, channels etc. § HTTP/1. 1 • client/server use the same connection for several request/response transactions • multiple requests at beginning of session, several responses in same order • enhanced caching of responses (useful if equivalent responses!) • semantic transparency not always achievable: disconnected, performance, availability most up-to-date version. . . • several more tags and options for controlling caching (public/private, maxage, no-cache etc. ) • relaxing of transparency on app. request or with warning to user • encoding/compression mechanism, integrity check, security of proxies, authentication, authorization. . . § Cookies: well. . . , stateful sessions, not really integrated. . . 131

System support for WWW in a mobile World (1) § Enhanced browsers • Pre-fetching, caching, off-line use • e. g. Internet Explorer, Netscape mobile client integrated enhancement browser web server § Additional, accompanying application • Pre-fetching, caching, off-line use • e. g. original Web. Whacker • Problem – not transparent, two different ways of accessing content: • Directly to the web server • Via the additional application mobile client browser additional application web server 132

System support for WWW in a mobile World (2) § Client Proxy acts as server for the browser and as client for the web server. • Pre-fetching, caching, off-line use • e. g. , Caubweb, Tele. Web, Weblicator, Web. Whacker, Web. Ex, Web. Mirror § Network Proxy supports a mobile client on the network side. mobile client browser client proxy web server mobile client • adaptive content transformation for bad connections, pre-fetching, caching • e. g. , Tran. Send, Digestor browser web server network proxy 133

System support for WWW in a mobile World (3) § Client and network proxy • combination of benefits plus simplified protocols • e. g. , Mobi. Scape, Web. Express § Special network subsystem • adaptive content transformation for bad connections, pre-fetching, caching • e. g. , Mowgli § Additional many proprietary server extensions possible • “channels”, content negotiation, . . . mobile client browser client proxy web server network proxy 134