1. Mobile Communications Chapter 10: Support for Mobility
Mobilkommunikation SS 1998
Mobile Communications Chapter 10: Support for Mobility
File systems
Data bases
WWW and Mobility
WAP (Wireless Application Protocol), i-mode & Co.

2. Mobile, bearable multimedia equipment …
Mobilkommunikation SS 1998
Mobile, bearable multimedia equipment …

3. File systems - Motivation
Mobilkommunikation SS 1998
File systems - Motivation
Goal
efficient and transparent access to shared files within a mobile environment while maintaining data consistency
Problems
limited resources of mobile computers (memory, CPU, ...)
low bandwidth, variable bandwidth, temporary disconnection
high heterogeneity of hardware and software components (no standard PC architecture)
wireless network resources and mobile computer are not very reliable
standard file systems (e.g., NFS, network file system) are very inefficient, almost unusable
Solutions
replication of data (copying, cloning, caching)
data collection in advance (hoarding, pre-fetching)

4. File systems - consistency problems
Mobilkommunikation SS 1998
File systems - consistency problems
THE big problem of distributed, loosely coupled systems
are all views on data the same?
how and when should changes be propagated to what users?
Weak consistency
many algorithms offering strong consistency (e.g., via atomic updates) cannot be used in mobile environments
invalidation of data located in caches through a server is very problematic if the mobile computer is currently not connected to the network
occasional inconsistencies have to be tolerated, but conflict resolution strategies must be applied afterwards to reach consistency again
Conflict detection
content independent: version numbering, time-stamps
content dependent: dependency graphs

5. File systems for limited connectivity I
Mobilkommunikation SS 1998
File systems for limited connectivity I
Symmetry
Client/Server or Peer-to-Peer relations
support in the fixed network and/or mobile computers
one file system or several file systems
one namespace for files or several namespaces
Transparency
hide the mobility support, applications on mobile computers should not notice the mobility
user should not notice additional mechanisms needed
Consistency model
optimistic or pessimistic
Caching and Pre-fetching
single files, directories, subtrees, partitions, ...
permanent or only at certain points in time

6. File systems for limited connectivity II
Mobilkommunikation SS 1998
File systems for limited connectivity II
Data management
management of buffered data and copies of data
request for updates, validity of data
detection of changes in data
Conflict solving
application specific or general
errors
Several early experimental systems exist (late 80s)
Coda (Carnegie Mellon University), Little Work (University of Michigan), Ficus (UCLA) etc.
Many systems use ideas from distributed file systems such as, e.g., AFS (Andrew File System)

7. File systems - Coda I
Mobilkommunikation SS 1998
Coda (Constant Data Availability) is a distributed file system developed as a research project at Carnegie Mellon University
Application transparent extensions of client and server
changes in the cache manager of a client
applications use cache replicates of files
extensive, transparent collection of data in advance for possible future use („Hoarding“)
Consistency
system keeps a record of changes in files and compares files after reconnection
if different users have changed the same file a manual reintegration of the file into the system is necessary
optimistic approach, coarse grained (file size)
mobile client
application
cache
server

8. File systems - Coda II States of a client Hoarding Comparison of files
Mobilkommunikation SS 1998
File systems - Coda II
Hoarding
user can pre-determine a file list with priorities
contents of the cache determined by the list and LRU strategy (Last Recently Used)
explicit pre-fetching possible
periodic updating
Comparison of files
asynchronous, background
system weighs speed of updating against minimization of network traffic
Cache misses
modeling of user patience: how long can a user wait for data without an error message?
function of file size and bandwidth
States of a client
hoarding
strong
connection
weak
connection
disconnection
write
disconnected
connection
disconnection
emulating

9. File systems - Little Work
Mobilkommunikation SS 1998
File systems - Little Work
Only changes in the cache manager of the client
Connection modes and use

10. File systems - further examples
Mobilkommunikation SS 1998
File systems - further examples
Mazer/Tardo
file synchronization layer between application and local file system
caching of complete subdirectories from the server
“Redirector” responses to requests locally if necessary, via the network if possible
periodic consistency checks with bi-directional updating
Ficus
not a client/server approach
optimistic approach based on replicates, detection of write conflicts, conflict resolution
use of „gossip“ protocols: a mobile computer does not necessarily need to have direct connection to a server, with the help of other mobile computers updates can be propagated through the network
MIo-NFS (Mobile Integration of NFS)
NFS extension, pessimistic approach, only token holder can write
connected/loosely connected/disconnected

11. Database systems in mobile environments
Mobilkommunikation SS 1998
Database systems in mobile environments
Request processing
power conserving, location dependent, cost efficient
example: find the fastest way to a hospital
Replication management
similar to file systems
Location management
tracking of mobile users to provide replicated or location dependent data in time at the right place (minimize access delays)
example: with the help of the HLR (Home Location Register) in GSM a mobile user can find a local towing service
Transaction processing
“mobile” transactions can not necessarily rely on the same models as transactions over fixed networks (ACID: atomicity, consistency, isolation, durability)
therefore models for “weak” transaction

12. World Wide Web and mobility
Mobilkommunikation SS 1998
World Wide Web and mobility
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: 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!

13. WWW example non persistent Mobilkommunikation SS 1998
Request to port 80: GET / HTTP/1.0 or: GET / HTTP/1.1 Host: Response from server HTTP/ OK Date: Wed, 30 Oct :44:26 GMT Server: Apache/ (Unix) mod_perl/1.24 Last-Modified: Wed, 30 Oct :16:31 GMT ETag: "2d dbfdbaf" Accept-Ranges: bytes Content-Length: 8994 Connection: close Content-Type: text/html <DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title>FU-Berlin: Institut für Informatik</TITLE> <base href=" <link rel="stylesheet" type="text/css" href=" <!--script language="JavaScript" src="fuinf.js"--> <!--/script--> </head> <body onResize="self.location.reload();"> ...
non persistent

14. HTTP 1.0 (old) and mobility I
Mobilkommunikation SS 1998
HTTP 1.0 (old) and mobility I
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

15. HTTP 1.0 (old) and mobility II
Mobilkommunikation SS 1998
HTTP 1.0 (old) and mobility II
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!

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

17. Approaches toward WWW for mobile devices
Mobilkommunikation SS 1998
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

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

19. System support for WWW in a mobile world I (some historical)
Mobilkommunikation SS 1998
System support for WWW in a mobile world I (some historical)
mobile client
browser
integrated enhancement
Enhanced browsers
Pre-fetching, caching, off-line use
e.g. Internet Explorer
Additional, accompanying application
e.g. original WebWhacker
web
server
mobile client
browser
additional application
web
server

20. System support for WWW in a mobile world II (some historical)
Mobilkommunikation SS 1998
System support for WWW in a mobile world II (some historical)
mobile client
Client Proxy
Pre-fetching, caching, off-line use
e.g., Caubweb, TeleWeb, Weblicator, WebWhacker, WebEx, WebMirror, ...
Network Proxy
adaptive content transformation for bad connections, pre-fetching, caching
e.g., TranSend, Digestor
browser
client
proxy
web
server
mobile client
browser
network
proxy
web
server

21. System support for WWW in a mobile world III (some historical)
Mobilkommunikation SS 1998
System support for WWW in a mobile world III (some historical)
mobile client
browser
client
proxy
Client and network proxy
combination of benefits plus simplified protocols
e.g., MobiScape, WebExpress
Special network subsystem
adaptive content transformation for bad connections, pre-fetching, caching
e.g., Mowgli
Additional many proprietary server extensions possible
“channels”, content negotiation, ...
web
server
network
proxy
mobile client
browser
client
proxy
web
server
network
proxy

22. Introduction to WAP  WAP stands for Wireless Application Protocol
The WAP protocol was designed to show internet contents on wireless clients, like mobile phones.
What is WAP?
The wireless industry came up with the idea of WAP. The point of this standard was to show internet contents on wireless clients, like mobile phones.
 WAP stands for Wireless Application Protocol
 WAP is an application communication protocol
 WAP is used to access services and information
 WAP is inherited from Internet standards
 WAP is for handheld devices such as mobile phones
 WAP is a protocol designed for micro browsers
 WAP enables the creating of web applications for mobile devices.
 WAP uses the mark-up language WML (not HTML)
 WML is defined as an XML 1.0 application

23. The WAP protocol is the leading standard for information services on wireless terminals like digital mobile phones.
The WAP standard is based on Internet standards (HTML, XML and TCP/IP).
It consists of a WML language specification, a WMLScript specification, and a Wireless Telephony Application Interface (WTAI) specification.
WAP is published by the WAP Forum, founded in 1997 by Ericsson, Motorola, Nokia, and Unwired Planet.
Forum members now represent over 90% of the global handset market, as well as leading infrastructure providers, software developers and other organizations.

24. The key features provided by WAP include :
 A programming model similar to the Internet
 Wireless Markup Language(WML)
 WMLScript
 Wireless Telephony Application(WTA)
 Optimized protocol stack
WAP Micro Browsers
To fit into a small wireless terminal, WAP uses a Micro Browser.
A Micro Browser is a small piece of software that makes minimal demands on hardware,
memory and CPU. It can display information written in a restricted mark-up language
called WML.
The Micro Browser can also interpret a reduced version of JavaScript called WMLScript.

25. What is WML?
WML stands for Wireless Markup Language. It is a mark-up language inherited from
HTML, but WML is based on XML, so it is much stricter than HTML.
WML is used to create pages that can be displayed in a WAP browser. Pages in WML are called DECKS. Decks are constructed as a set of CARDS.
What is WMLScript?
WML uses WMLScript to run simple code on the client. WMLScript is a light JavaScript language. However, WML scripts are not embedded in the WML pages.
WML pages only contains references to script URLs. WML scripts need to be compiled into byte code on a server before they can run in a WAP browser.

26. Examples of WAP use  Checking train table information
 Ticket purchase
 Flight check in
 Viewing traffic information
 Checking weather conditions
 Looking up stock values
 Looking up phone numbers
 Looking up addresses
 Looking up sport results

27. Why WAP? Restrictions: Small Display
Standard mobile has a display size of 96 X 65 pixels and PDA slightly larger at 160x160 pixels .WML structures its document in decks and cards.
A card is a single unit of interaction with the end-user, such as a text screen, a selection list, an input field, or a combination of those.
A card is typically small enough to be displayed even on a small screen.

28. Limited Memory and CPU
Wireless devices are usually not equipped with large amounts of memory or computational power in comparison to desktop computers. The memory restriction applies to RAM as well as ROM.
WAP handles these restrictions by defining a lightweight protocol stack. The limited set of functionalities provided by WML and WMLScript makes it possible to implement browsers that make small claims on computational power and ROM resources.
When it comes to RAM, the binary encoding of WML and WMLScript helps to keep the amount of RAM used as small as possible.

29. Low Bandwidth
The size of an average HTML page these days, including graphics, is around 20KB.
With a 56 Kbps modem, the download time for this page would be in the region of 4 seconds.
As the bandwidth of a wireless network is around 9.6Kbps, however, the download time for the data equivalent of just that one page would be around 17 seconds.
WAP addresses this bandwidth issue by minimizing the traffic over the wireless interface.
WML and WMLScript are binary encoded into a compact form before they are transmitted, in order to minimize the bandwidth restriction.

30. Less Connection Stability
Wired network access provides a more or less reliable connection to the network.
In case of wireless networks, services are inaccessible for shorter or longer periods of time due to fading, lost radio coverage, or deficient capacity.
The architects of the WAP protocol Infrastructure, when putting together the specifications for WAP, have taken the problem of connection stability into account and have designed into the layers.

31. WAP - Wireless Application Protocol
Mobilkommunikation SS 1998
WAP - Wireless Application Protocol
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, …)
Forum
was: WAP Forum, co-founded by Ericsson, Motorola, Nokia, Unwired Planet, further information
now: Open Mobile Alliance (Open Mobile Architecture + WAP Forum + SyncML + …)

32. WAP - scope of standardization
Mobilkommunikation SS 1998
WAP - scope of standardization
Browser
“micro browser”, similar to existing, well-known browsers in the Internet
Script language
similar to Java script, adapted to the mobile environment
WTA/WTAI
Wireless Telephony Application (Interface): access to all telephone functions
Content formats
e.g., business cards (vCard), calendar events (vCalender)
Protocol layers
transport layer, security layer, session layer etc.

33. TIA/EIA Telecommunications Industry Association/Electronic Industry Association
PDU Protocol Data Unit
SAP Service Access Point
SDU Service Data Unit
TTR Transmission Trailer
UDCP USSD Dialogue Control Protocol
UDH User-Data Header (see [GSM 03.40])
UDHL User-Data Header Length (see [GSM 03.40])
UDL User-Data Length (see [GSM 03.40])
UDP Unreliable Datagram Protocol
USSD Unstructured Supplementary Service Data
WAE Wireless Application Environment
WAP Wireless Application Protocol
WSP Wireless Session Protocol
WTP Wireless Transaction Protocol

34. WAP 1.x - reference model
WAP is designed in a layered fashion so that it can be extensible, flexible, and scalable.
As a result, the WAP protocol stack is divided into five layers:
 Application Layer
Wireless Application Environment (WAE). This layer is of most interest to content developers because it contains, among other things, device specifications and the content development programming languages, WML and WMLScript.
 Session Layer
Wireless Session Protocol (WSP). Unlike HTTP, WSP has been designed by the WAP Forum to provide fast connection suspension and reconnection.

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

36. Some Bearerers…. Services…..
CDPD (Cellular Digital Packet Data) is a packet-based network,
The CDPD network has an optimal bandwidth of 19.2K, and is run in the same spectrum as the AMPS networks.
CDMA (Code Division Multiple Access) can be either packet based or circuit based, depending on the method of access and version of the technology.
cdmaOne (the version before CDMA2000) uses circuit switch data, that runs at 14.4, and acts as a dial-up connection.
CDMA2000 is packet based, and has a maximum of 144kbps
GSM (Global System Mobile Communication) is the predominant, network
GSM (excluding GPRS and EDGE) is a circuit-based network, which means that the user must make a dial-up connection to access the network.
The GSM network has an optimal bandwidth of 14.4 Kbps.

37. GPRS (General Packet Radio Service) is a packet-based wireless communication service that promises data rates from 56 up to 114 Kbps and continuous connection to the Internet for mobile phone and computer users, but delivers in the 30-50kbps in real world usage. GPRS is added on top of GSM networks and will complement existing services such circuit-switched cellular phone connections and the Short Message Service (SMS). GPRS is NOT related to GPS
TDMA (Time Division Multiple Access) as a standard - technology used in digital cellular telephone communication to divide each traditional AMPS cellular channel into three time slots in order to increase the amount of information that can be carried.
iDEN (integrated Digital Enhanced Network) can be used in either a packet based form or circuit switched form. In circuit switched, it runs are 9.6kbps, in packet based mode, it runs at kbps.

38. It offers three classes of transaction services
Mobilkommunikation SS 1998
WAP layers….
Transaction Layer
Wireless Transaction Protocol (WTP). The WTP runs on top of a datagram service such as User Datagram Protocol (UDP) and is part of the standard suite of TCP/IP protocols used to provide a simplified protocol suitable for low bandwidth wireless stations.
It offers three classes of transaction services
Class0:provides unreliable one-way messages without confirmation
Class1:provide reliable one way message without result
Class2: provides reliable two way request-response messages.
Security Layer
Wireless Transport Layer Security (WTLS). WTLS incorporates security features that are based upon the established Transport Layer Security (TLS) protocol standard.
It includes data integrity checks, privacy, service denial, and authentication services.
Transport Layer
Wireless Datagram Protocol (WDP). The WDP allows WAP to be bearer independent by adapting the transport layer of the underlying bearer.
The WDP presents a consistent data format to the higher layers of the WAP protocol stack, thereby offering the advantage of bearer independence to application developers.

39. WWW programming model Vs WAP programming model

40. In www programming model, the browser at user PC supports HTML and the request as well as response is going to follow the HTTP protocol.
The request from HTML browser is send as an HTTP request and the response from server is replies HTTP response.
There is no protocol conversion, since the client side has sufficient hardware capabilities and user interfaces such a way to support typical HTML pages.

41. WAP programming model

42. WAP gateway, which is responsible for protocol conversion and data formatting/Content Coding.
It acts as the interface between the wired and wireless worlds.
Since mobile nodes, WAP phones have limited capabilities they cannot support typical HTML pages. So that protocol conversion and formatting-encoding are carried out to minimize data transfer.

43. 1. The user selects an option on their mobile device that has a URL with WML content assigned to it.
2. The phone sends the URL request via the phone network to a WAP gateway, using the binary encoded WAP protocol.
3. The gateway translates this WAP request into a conventional HTTP request for the specified URL, and sends it on to the Internet.
4. The appropriate Web server picks up the HTTP request.
5. The server processes the request, just as it would be any other request. If the URL refers to a static WML file, the server delivers it. If a CGI script is requested, it is processed and the content returned as usual.
6. The Web server adds the HTTP header to the WML content and returns it to the gateway.
7. The WAP gateway compiles the WML into binary form.
8. The gateway then sends the WML response back to the phone.
9. The phone receives the WML via the WAP protocol.
10. The micro-browser processes the WML and displays the content on the screen.

44. With my laptop using a Nokia 6110 phone over a infrared link I want to call my computer at home which is connected to an ISDN-line.
Using the V110 protocol I can connect much quicker and don't need an analog modem at home.

45. WAP - network elements fixed network wireless network Internet WAP
Mobilkommunikation SS 1998
WAP - network elements
fixed network
wireless network
Internet
WAP
proxy
WML
Binary WML
HTML
filter
WML
HTML
HTML
filter/
WAP
proxy
Binary WML
web
server
HTML
WTA
server
Binary WML
PSTN
Binary WML: binary file format for clients

46. WDP - Wireless Datagram Protocol
Mobilkommunikation SS 1998
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, ...)
The Personal Handy-phone System (PHS), also marketed as the Personal Access System (PAS)
Terrestrial Trunked Radio (TETRA) (formerly known as Trans-European Trunked Radio) is a professional mobile radio and two-way transceiver (colloquially known as a walkie talkie) specification. TETRA was specifically designed for use by government agencies, emergency services
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)

47. WDP - Service Primitives
Mobilkommunikation SS 1998
WDP - Service Primitives
T-SAP
T-SAP
T-DUnitdata.req (DA, DP, SA, SP, UD)
T-DUnitdata.ind (SA, SP, UD)
T-DUnitdata.req (DA, DP, SA, SP, UD)
T-DError.ind
(EC)
T-DUnitdata.ind service primitive indicates the reception of data. Here destination address and port are only optional parameters.
If a higher layer requests a service the WDP cannot fulfill, this error is indicated with the T-DError.ind service primitive as shown.
An error code (EC) is returned indicating the reason for the error to the higher layer. WDP is not allowed to use this primitive to indicate problems with the bearer service. It is only allowed to use the primitive to indicate local problems, such as a user data size that is too large.

48. Internet Service Provider
Mobilkommunikation SS 1998
Usage of WDP
Wireless Data Gateway
WTLS
WTLS
GSM-SMS
GSM-CSD
WDP &
Adaptation
WDP &
Adaptation
SMS
SMS
Tunnel
Tunnel
Subnetwork
Subnetwork
WAP
Proxy
WTLS
WTLS
Internet Service Provider
Remote Access Service
UDP
UDP IP IP IP
Interworking
Function
PPP
PPP
Subnetwork
Subnetwork
CSD-RF
CSD-RF
PSTN
Circuit
PSTN
Circuit

49. WTLS - Wireless Transport Layer Security
Mobilkommunikation SS 1998
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

50. Secure session, full handshake
Mobilkommunikation SS 1998
originator
SEC-SAP
peer
SEC-SAP
SEC-Create.req
(SA, SP, DA, DP, KES, CS, CM)
SEC-Create.ind
(SA, SP, DA, DP, KES, CS, CM)
SEC-Create.res
(SNM, KR, SID, KES‘, CS‘, CM‘)
SEC-Create.cnf
(SNM, KR, SID, KES‘, CS‘, CM‘)
SEC-Exchange.req
SEC-Exchange.ind
SEC-Exchange.res
(CC)
SEC-Commit.req
SEC-Exchange.cnf
(CC)
SEC-Commit.ind
SEC-Commit.cnf
KES: Key Exchange Suite. CS: Cipher Suite. CM: Compression Mode.
SNM: Sequence Number Mode

51. SEC-Unitdata - transferring datagrams
Mobilkommunikation SS 1998
SEC-Unitdata - transferring datagrams
sender
SEC-SAP
receiver
SEC-SAP
SEC-Unitdata.req
(SA, SP, DA, DP, UD)
SEC-Unitdata.ind
(SA, SP, DA, DP, UD)

52. WTP - Wireless Transaction Protocol
Mobilkommunikation SS 1998
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)

53. Details of WTP I Support of different communication scenarios
Mobilkommunikation SS 1998
Details of WTP I
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

54. Details of WTP II Used Mechanisms Reliability
Mobilkommunikation SS 1998
Details of WTP II
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)

55. WTP Class 0 transaction initiator TR-SAP responder TR-SAP
Mobilkommunikation SS 1998
WTP Class 0 transaction
initiator
TR-SAP
responder
TR-SAP
TR-Invoke.req
(SA, SP, DA, DP, A, UD, C=0, H)
TR-Invoke.ind
(SA, SP, DA, DP, A, UD, C=0, H‘)
Invoke PDU

56. WTP Class 1 transaction, no user ack & user ack
Mobilkommunikation SS 1998
WTP Class 1 transaction, no user ack & user ack
initiator
TR-SAP
responder
TR-SAP
TR-Invoke.req
(SA, SP, DA, DP, A, UD, C=1, H)
TR-Invoke.ind
(SA, SP, DA, DP, A, UD, C=1, H‘)
Invoke PDU
TR-Invoke.cnf
(H)
Ack PDU
initiator
TR-SAP
responder
TR-SAP
TR-Invoke.req
(SA, SP, DA, DP, A, UD, C=1, H)
TR-Invoke.ind
(SA, SP, DA, DP, A, UD, C=1, H‘)
Invoke PDU
TR-Invoke.res
(H‘)
TR-Invoke.cnf
(H)
Ack PDU

57. WTP Class 2 transaction, no user ack, no hold on
Mobilkommunikation SS 1998
WTP Class 2 transaction, no user ack, no hold on
initiator
TR-SAP
responder
TR-SAP
TR-Invoke.req
(SA, SP, DA, DP, A, UD, C=2, H)
TR-Invoke.ind
(SA, SP, DA, DP, A, UD, C=2, H‘)
Invoke PDU
TR-Result.req
(UD*, H‘)
TR-Invoke.cnf
(H)
Result PDU
TR-Result.ind
(UD*, H)
TR-Result.res
(H)
TR-Result.cnf
(H‘)
Ack PDU

58. WTP Class 2 transaction, user ack
Mobilkommunikation SS 1998
WTP Class 2 transaction, user ack
initiator
TR-SAP
responder
TR-SAP
TR-Invoke.req
(SA, SP, DA, DP, A, UD, C=2, H)
TR-Invoke.ind
(SA, SP, DA, DP, A, UD, C=2, H‘)
Invoke PDU
TR-Invoke.res
(H‘)
TR-Invoke.cnf
(H)
Ack PDU
TR-Result.req
(UD*, H‘)
TR-Result.ind
(UD*, H)
Result PDU
TR-Result.res
(H)
TR-Result.cnf
(H‘)
Ack PDU

59. WTP Class 2 transaction, hold on, no user ack
Mobilkommunikation SS 1998
WTP Class 2 transaction, hold on, no user ack
initiator
TR-SAP
responder
TR-SAP
TR-Invoke.req
(SA, SP, DA, DP, A, UD, C=2, H)
TR-Invoke.ind
(SA, SP, DA, DP, A, UD, C=2, H‘)
Invoke PDU
TR-Invoke.cnf
(H)
Ack PDU
TR-Result.req
(UD*, H‘)
TR-Result.ind
(UD*, H)
Result PDU
TR-Result.res
(H)
TR-Result.cnf
(H‘)
Ack PDU

60. WSP
WSP provides a shared state between a client and a server to optimize content transfer.
HTTP, a protocol WSP tries to replace within the wireless domain, is stateless, which already causes many problems in fixed networks .
Many web content providers therefore use cookies to store some state on a client machine, which is not an elegant solution.
State is needed in web browsing, for example, to resume browsing in exactly the same context in which browsing has been suspended. This is an important feature for clients and servers.
Client users can continue to work where they left the browser or when the network was interrupted, or users can get their customized environment every time they start the browser.
Content providers can customize their pages to clients’ needs and do not have to retransmit the same pages over and over again.

61. Mobilkommunikation SS 1998
WSP offers the following general features needed for content exchange between cooperating clients and servers:
Session management : WSP introduces sessions that can be established from a client to a server and may be long lived.
Sessions can also be released in an orderly manner. The capabilities of suspending and resuming a session are important to mobile applications.
Assume a mobile device is being switched off – it would be useful for a user to be able to continue operation at exactly the point where the device was switched off.
Session lifetime is independent of transport connection lifetime or continuous operation of a bearer network.

62. ● Capability negotiation: Clients and servers can agree upon a common level of protocol functionality during session establishment. Example parameters to negotiate are maximum client SDU size, maximum outstanding requests, protocol options, and server SDU size.
● Content encoding: WSP also defines the efficient binary encoding for the content it transfers. WSP offers content typing and composite objects, as explained for web browsing.

63. WAP has specified the wireless session protocol/browsing (WSP/B) which comprises protocols and services most suited for browsing-type applications.
In addition to the general features of WSP, WSP/B offers the following features adapted to web browsing:
HTTP/1.1 functionality: offers, such as extensible request/reply methods, composite objects, and content type negotiation.
Exchange of session headers: Client and server can exchange request/reply headers that remain constant over the lifetime of the session. These headers may include content types, character sets, languages, device capabilities, and other static parameters. WSP/B will not interpret header information but passes all headers directly to service users.
Push and pull data transfer: Pulling data from a server is the traditional mechanism of the web. This is also supported by WSP/B using the request/response mechanism from HTTP/1.1. Additionally, WSP/B supports three push mechanisms for data transfer: a confirmed data push within an existing session context, a non-confirmed data push within an existing session context, and a non-confirmed data push without an existing session context.
Asynchronous requests: Optionally, WSP/B supports a client that can send multiple requests to a server simultaneously. This improves efficiency for the requests and replies can now be coalesced (to grow together / to come together to form one group or mass) into fewer messages. Latency is also improved, as each result can be sent to the client as soon as it is available.

64. Mobilkommunikation SS 1998
WSP/B can run over the transaction service WTP or the datagram service WDP. The following shows several protocol sequences typical for session management, method invocation, and push services.
WSP
Connection mode
(uses WTP)
Connectionless mode
(uses WDP or WTLS)
Session Management (class 0, 2)
Method Invocation (Kl. 2)
Error Report
Push (class 0)
Confirmed Push (class 1)
Session suspend/resume (class 0, 2)
Method Invocation
Push
(in general unreliable)

65. WSP/B uses the three service classes of WTP
Class 0 is used for unconfirmed push, session resume, and session management.
Confirmed push uses class 1, method invocation, session resume, and session management class 2.
first example (seeFigure 10.20) shows the session establishment of WSP/B using WTP class 2 transactions. With the S-Connect.req primitive, a client can request a new session. Parameters are the server address (SA), the client address (CA), and the optional client header (CH) and requested capabilities (RC). The session layer directly uses the addressing scheme of the layer below

66. WTP transfers the connect PDU to the server S-SAP where an S-Connect
WTP transfers the connect PDU to the server S-SAP where an S-Connect.ind primitive indicates a new session.
If the server accepts the new session it answers with an S-Connect.res, parameters are an optional server header (SH) with the same function as the client header and the negotiated capabilities (NC) needed for capability negotiation.
WTP now transfers the connreply PDU back to the client; S-Connect.cnf confirms the session establishment and includes the server header (if present) and the negotiated capabilities from the server. WSP/B includes several procedures to refuse a session or to abort session establishment.
Useful feature of WSP/B session suspension and session resume is shown in Figure
If, for example, a client notices that it will soon be unavailable, e.g., the bearer network will be unavailable due to roaming to another network or the user switches off the device, the client can suspend the session.

67. Session suspension will automatically abort all data transmission and
freeze the current state of the session on the client and server side.
A client suspends a session with S-Suspend.req,
WTP transfers the suspend PDU to the server with a class 0 transaction, i.e., unconfirmed and unreliable.
WSP/B will signal the suspension with S-Suspend.ind on the client and server side. The only parameter is the reason R for suspension. Reasons can be a user request or a suspension initiated by the service provider.

68. In Figure 10.21, a client can later resume a suspended session with S-Resume.req. Parameters are server address (SA) and client address (CA).
Resuming a session is a confirmed operation.
It is up to the server’s operator how long this state is conserved.
Terminating a session is done by using the S-Disconnect.req service primitive (Figure 10.22).
This primitive aborts all current method or push transactions
used to transfer data. Disconnection is indicated on both sides using
S-Disconnect.ind. The reason R for disconnection can be, e.g., network error, protocol error, peer request, congestion, and maximum SDU size exceeded.
S-Disconnect.ind can also include parameters that redirect the session to another server where the session may continue.

69. WSP/B session termination
Mobilkommunikation SS 1998
WSP/B session termination
client
S-SAP
server
S-SAP
S-Disconnect.req
(R)
S-Disconnect.ind
(R)
Disconnect PDU
S-Disconnect.ind
(R)
WTP Class 0
transaction
Figure WSP/B session termination

70. WSP/B completed Transaction
S-MethodInvoke primitive is used to request that an operation is executed by the server.
The result, if any, is sent back using the S-MethodResult primitive (see Figure 10.23).
A client requests an operation with S-MethodInvoke.req.
Parameters are the
client transaction identifier CTID to distinguish between pending transactions,
the method M identifying the requested operation at the server, and
the request URI (Uniform Resource Identifier (Berners-Lee, 1994a) RU.

71. WSP/B method invoke client S-SAP server S-SAP S-MethodInvoke.req
Mobilkommunikation SS 1998
WSP/B method invoke
client
S-SAP
server
S-SAP
S-MethodInvoke.req
(CTID, M, RU)
S-MethodInvoke.ind
(STID, M, RU)
Method PDU
S-MethodInvoke.res
(STID)
S-MethodInvoke.cnf
(CTID)
S-MethodResult.req
(STID, S, RH, RB)
S-MethodResult.ind
(CTID, S, RH, RB)
Reply PDU
S-MethodResult.res
(CTID)
S-MethodResult.cnf
(STID)
WTP Class 2
transaction

72. WTP class 2 transaction service now transports the method PDU to the server.
A method PDU can be either a get PDU or a post PDU as defined in Fielding (1999).
Get PDUs are used for HTTP/1.1 GET, OPTIONS, HEAD, DELETE and TRACE methods, and other methods that do not send content to the server.
A post PDU is used for HTTP/1.1 POST and PUT and other methods that send content to the server.
GET - Requests data from a specified resource
POST - Submits data to be processed to a specified resource
HTTP PUT method used by some clients to store files on a server.
PUT requests are much simpler than a file upload using POST requests
On the server’s side, S-MethodInvoke.ind indicates the request.
In this case a server transaction identifier STID distinguishes between pending transactions.
The server confirms the request, so WSP/B does not generate a new PDU
but relies on the lower WTP layer (see Figure 10.24).

73. WSP/B over WTP - method invocation
Mobilkommunikation SS 1998
WSP/B over WTP - method invocation
client
S-SAP
initiator
TR-SAP
responder
TR-SAP
server
S-SAP
S-MethodInvoke.req
TR-Invoke.req
Invoke(Method)
TR-Invoke.ind
S-MethodInvoke.ind
TR-Invoke.res
S-MethodInvoke.res
Ack PDU
S-MethodInvoke.cnf
TR-Invoke.cnf
TR-Result.req
S-MethodResult.req
Result(Reply)
S-MethodResult.ind
TR-Result.ind
S-MethodResult.res
TR-Result.res
Ack PDU
TR-Result.cnf
S-MethodResult.cnf
Figure WSP utilization of WTP as lower layer

74. the result of the request is sent back to the client using the SMethodResult primitive.
Additional parameters are now the status (S), the response header (RH), and the response body (RB).
Figure shows how WSP (thus also WSP/B) uses the underlying WTP services for its purposes.
The S-MethodInvoke.req primitive triggers the TR-Invoke.req primitive, the parameters of the WSP layer are the user data of the WTP layer.
The invoke PDU of the WTP layer carries the method PDU of the WSP layer inside.
For the confirmation of its service primitives the WSP layer has none of its own PDUs but uses the acknowledgement PDUs of the WTP layer as shown.
S-MethodInvoke.res triggers TR-Invoke.res, the ack PDU is transferred to the initiator, here TR-Invoke.cnf confirms the invoke service and triggers the S-MethodInvoke.cnf primitive which confirms the method invocation service.
**mingling of layers saves a lot of redundant data flow but still allows a separation of the tasks between the two layers

75. WSP neither provides any sequencing between different requests nor does it restore any sequence between responses.
Figure shows four requests on the client’s side (S-MethodInvoke_i.req).
WSP may deliver them in any order on the server’s side as indicated by S-MethodInvoke_i.ind (the confirmation primitives S-MethodInvoke.res and S-MethodInvoke.cnf have been omitted for clarity).
the responses SMethodResult_i.req may be in arbitrary order as the WSP service only delivers them to the client S-SAP where they finally appear as S-MethodResult_i.ind.
This may be completely independent from the original order of the requests.

76. WSP/B over WTP - asynchronous, unordered requests
Mobilkommunikation SS 1998
WSP/B over WTP - asynchronous, unordered requests
client
S-SAP
server
S-SAP
S-MethodInvoke_1.req
S-MethodInvoke_2.req
S-MethodInvoke_2.ind
S-MethodInvoke_1.ind
S-MethodInvoke_3.req
S-MethodResult_1.req
S-MethodInvoke_3.ind
S-MethodResult_1.ind
S-MethodResult_3.req
S-MethodResult_3.ind
S-MethodResult_2.req
S-MethodInvoke_4.req
S-MethodInvoke_4.ind
S-MethodResult_4.req
S-MethodResult_4.ind
S-MethodResult_2.ind
Figure WSP/B asynchronous, unordered requests

77. WSP/B – confirmed / non-confirmed push
Up to now all service primitives allowed the client to pull data from a server.
With the help of push primitives, a server can push data towards a client if allowed.
The simplest push mechanism is the non-confirmed push as shown in Figure
The server sends unsolicited data with the S-Push.req primitive to the client.
Parameters are the push header (PH) and the push body (PB) again, these are the header and the body known from HTTP.
The unreliable, unconfirmed WTP class 0 transaction service transfers the push PDU to the client where S-Push.ind indicates the push event.
Solicit - to ask for

78. Figure 10.26 WSP/B non-confirmed push
Mobilkommunikation SS 1998
Figure WSP/B non-confirmed push
client
S-SAP
server
S-SAP
S-Push.req
(PH, PB)
S-Push.ind
(PH, PB)
Push PDU
WTP Class 0
transaction
A more reliable push service offers the S-ConfirmedPush primitive as
shown in Figure
Here the server has to determine the push using a server push identifier (SPID). This helps to distinguish between different pending pushes.
The reliable WTP class 1 transaction service is now used to transfer the
confpush PDU to the client. On the client’s side a client push identifier (CPID) is used to distinguish between different pending pushes.

80. Using WDP service
It is possible to run WSP/B on top of the connectionless, unreliable WDP service.
As an alternative to WDP, WTLS can always be used if security is required.
The service primitives are directly mapped onto each other.
Example applications could be periodic pushes of weather data from a remote sensor device to a client.
Figure shows the three service primitives available for connectionless session service:
S-Unit-MethodInvoke.req to request an operation on a server,
S-Unit-MethodResult.req to return results to a client, and
S-Unit-Push.req to push data onto a client.
Transfer of the PDUs (method, reply and push) is done with the help of the standard unreliable datagram transfer service of WDP

81. Figure 10.28 WSP/B as connectionless session service
Mobilkommunikation SS 1998
WSP/B over WDP
client
S-SAP
server
S-SAP
S-Unit-MethodInvoke.req
(SA, CA, TID, M, RU)
S-Unit-MethodInvoke.ind
(SA, CA, TID, M, RU)
Method PDU
S-Unit-MethodResult.req
(CA, SA, TID, S, RH, RB)
S-Unit-MethodResult.ind
(CA, SA, TID, S, RH, RB)
Reply PDU
S-Unit-Push.req
(CA, SA, PID, PH, PB)
S-Unit-Push.ind
(CA, SA, PID, PH, PB)
Push PDU
WDP Unitdata
service
Figure WSP/B as connectionless session service

82. TID is communicated transparently from service user to service user.
Besides the server address (SA), the client address (CA), the method (M), and the request URI (RU), which have already been explained above,
the user of the S-Unit-MethodInvoke.req primitive can determine a transaction identifier (TID) to distinguish between different transactions on the user level.
TID is communicated transparently from service user to service user.
function of the S-Unit-MethodResult primitive remains the same as explained above:
the status (S), response header (RH), and response body (RB) represent the result of the operation.
The S-Unit-Push primitive has the parameters
client address (CA), server address (SA), push identifier (PID), push header (PH), and push body (PB).

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

84. WAE logical model Origin Servers Gateway Client WTA user agent web
Mobilkommunikation SS 1998
WAE logical model
Origin Servers
Gateway
Client
WTA
user agent
web
server
response
with
content
encoded
response
with
content
encoders
&
decoders
WML
user agent
other content
server
push
content
encoded
push
content
other
WAE
user agents
request
encoded
request

85. Wireless Markup Language (WML)
Mobilkommunikation SS 1998
Wireless Markup Language (WML)
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

86. WML
an XML-based markup language designed to describe how WAP content is presented on a wireless terminal
case sensitive, all tags and attributes should be in lowercase
Unlike HTML, WML is unforgiving of incorrectly nested tags
WML doesn't assume that a PC keyboard or a mouse is available for user input
provides a smaller, telephony-aware set of tags

87. Mobilkommunikation SS 1998
WML – example I
<?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" " <wml> <card id="card_one" title="simple example"> <do type="accept"> <go href="#card_two"/> </do> <p> This is a simple first card! <br/> On the next one you can choose ... </p> </card>

88. Mobilkommunikation SS 1998
WML – example II
<card id="card_two" title="Pizza selection"> <do type="accept" label="cont"> <go href="#card_three"/> </do> <p> ... your favorite pizza! <select value="Mar" name="PIZZA"> <option value="Mar">Margherita</option> <option value="Fun">Funghi</option> <option value="Vul">Vulcano</option> </select> </p> </card> <card id="card_three" title="Your Pizza!"> Your personal pizza parameter is <b>$(PIZZA)</b>! </wml>

89. WMLScript Complement to WML Provides general scripting capabilities
Mobilkommunikation SS 1998
WMLScript
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

90. Mobilkommunikation SS 1998
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;

91. The WAP Forum has specified several standard libraries for WMLScript
These libraries provide access to the core functionality of a WAP client so they, must be available in the client’s scripting environment. One exception is the float library, which is optional and is only useful if a client can support floating-point operations.
The following six libraries have been defined so far:
● Lang: This library provides functions closely related to WMLScipt itself.
Examples are isInt to check if a value could be converted into an integer or float to check if floating-point operations are supported.
● Float: Many typical arithmetic floating-point operations are in this library (which is optional as mentioned before).
Example functions are round for rounding a number and sqrt for calculating the square root of a given value.
● String: Many string manipulation functions are in this library. Examples are well-known functions such as length to return the length of a string or subString to return a substring of a given string. Nevertheless, this library also provides more advanced functions such as find to find a substring within a string or squeeze to replace several consecutive whitespaces with only one.

92. ● URL: This library provides many functions for handling URLs with the syntax defined
for example:
The function getPath could now extract the path of this URL, i.e., "mypages", getQuery has the query part "j=2&p=1" as return value, and getFragment delivers the fragment used in the URL, i.e., "crd".
● WMLBrowser: This library provides several functions typical for a browser, such as prev to go back one card or refresh to update the context of the user interface. The function go loads the content provided as parameters:
var my_card = "
var my_vars = "j=4&k=7";
WMLBrowser.go(my_card, my_vars);
● Dialogs: For interaction with a user, this library has been defined. An example function is prompt which displays a given message and prompts for user input.
An additional library is the WMLScript Crypto Library
This library contains, for example, functions for signing text in addition to the security functions provided by WTLS. The required keys can be stored on the wireless identity module (WIM) which could be part of the mobile phone’s SIM

93. Wireless Telephony Application (WTA)
Mobilkommunikation SS 1998
Wireless Telephony Application (WTA)
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;
calling a number (WMLScript) WTAPublic.makeCall(" ");

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

95. Voice box example WTA-User-Agent WTA-Gateway WTA-Server Mobile network
Mobilkommunikation SS 1998
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
WML
Binary WML
Display deck;
user selects
WSP Get
HTTP Get
Respond with card
for call
WML
Binary WML
Play requested voice message
Wait for call
Call setup
Setup call
Setup call
Accept call
Accept call
Accept call
Voice connection

96. Someone might leave a message on a voice box server as indicated.
Without WAP, the network operator then typically generates an SMS
indicating the new message on the voice box via a little symbol on the mobile phone.
However, it is typically not indicated who left a message, what messages are stored etc.
Users have to call the voice box to check and cannot choose a particular message.
In a WAP scenario, the voice box can induce the WTA server to generate new content for pushing to the client.
An example could be a WML deck containing a list of callers plus length and priority of the calls.
The server does not push this deck immediately to the client, but sends a push message containing a single URL to the client.
A short note, e.g., “5 new calls are stored", could accompany the push message.
The WTA gateway translates the push URL into a service indication (see section ) and codes it into a more compact binary format.
The WTA user agent then indicates that new messages are stored.

97. If the user wants to listen to the stored messages, he or she can request a list of the messages. This is done with the help of the URL.
A WSP get requests the content the URL points to. The gateway translates this WSP get into an HTTP get and the server responds with the prepared list of callers.
After displaying the content, the user can select a voice message from the list. Each voice message in this example has an associated URL, which can request a certain WML card from the server.
The purpose of this card is to prepare the client for an incoming call.
As soon as the client receives the card, it waits for the incoming call. The call is then automatically accepted.
The WTA server also signals the voice box system to set up a (traditional) voice connection to play the selected voice message.
Setting up the call and accepting the call is shown using dashed lines, as these are standard interactions from the mobile phone network, which are not controlled by WAP.

98. The following examples illustrate the integration of WTA, WTAI library calls, WML and WMLScript, and how authors can use the functions of WTA Imagine you are watching a show on TV. At the end of the show, you may vote for your personal champion.
The traditional method is that each candidate gets an associated phone number and you have to dial the number –this is quite error-prone if long numbers are used.
Using WAP with WTA, the network operator could push a deck with several cards onto your handheld device and present a simple choice for voting as explained in the following paragraphs.
The first example consists of WML only and comprises two cards. The first card tells you to vote. If you accept, then the second card will be displayed.
You can choose between Mickey, Donald, and Pluto. You do not have to dial a number but directly select the name of your champion.
The variable dialno will be set to the value (i.e., the phone number) associated with your champion.
Now note the URI within the do tags. This URI tells the system to use the function mc (make call) from the library wp (WTAPublic) in the WTAI. This function places a call to the specified number (here dialno).
A traditional system can be used for counting calls.

99. WTAI - example with WML only
Mobilkommunikation SS 1998
WTAI - example with WML only
<?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" " <wml> <card id="card_one" title="Tele voting"> <do type="accept"> <go href="#card_two"/> </do> <p> Please choose your candidate! </p> </card> <card id="card_two" title="Your selection"> <go href="wtai://wp/mc;$dialno"/> <p> Your selection: <select name="dialno"> <option value=" ">Mickey</option> <option value=" ">Donald</option> <option value=" ">Pluto</option> </select> </p> </wml>

100. WTAI - example with WML and WMLScript I
Mobilkommunikation SS 1998
WTAI - example with WML and WMLScript I
function voteCall(Nr) { var j = WTACallControl.setup(Nr,1); if (j>=0) { WMLBrowser.setVar("Message", "Called"); WMLBrowser.setVar("No", Nr); } else { WMLBrowser.setVar("Message", "Error!"); WMLBrowser.setVar("No", j); WMLBrowser.go("showResult");

101. WTAI - example with WML and WMLScript II
Mobilkommunikation SS 1998
WTAI - example with WML and WMLScript II
<?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" " <wml> <card id="card_one" title="Tele voting"> <do type="accept"> <go href="#card_two"/> </do> <p> Please choose your candidate! </p> </card> <card id="card_two" title="Your selection"> <do type="accept"> <go href="/myscripts#voteCall($dialno)"/> </do> <p> Your selection: <select name="dialno"> <option value=" ">Mickey</option> <option value=" ">Donald</option> <option value=" ">Pluto</option> </select> </p> <card id="showResult" title="Result"> <p> Status: $Message $No </p> </wml>

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

103. The content may be transcoded to gain greater efficiency during transmission with the push OTA protocol.
If required, the PPG can send success or failure messages to the PI.
A PPG can also multicast messages to a group of receivers.

104. Push access protocol
The push access protocol (PAP) transfers content from a PI to the PPG
Although PAP was developed independently from the underlying transport service, PAP over HTTP is the first implementation.
HTTP POST messages are used for transmission. PAP offers the following operations:
● Push submission: Delivery of push messages from a PI to the PPG for forwarding to a client. The response indicates the initial acceptance or rejection of the forwarding request.
● Result notification: The PPG notifies the PI about the result of the push request. With the help of this notification, the server knows if the message reached the client, if the client deleted the message, if an error occurred at the client or if the message arrived too late.

105. ● Push cancellation: A PI can try to cancel a push request before delivery to a client. The result of the PPG indicates if the cancellation was successful or not. Cancellation may be used, e.g., for periodic news messages buffered at the PPG because the client is currently unavailable. In this case, only the most recent message may be of interest.
Status query: With the help of PAP, the PI can query the status of a push message. The result could indicate, if the PPG already delivered the message or is still trying to reach the client.
● Client capabilities query: The PI might be interested in the client’s capabilities. Additionally, a PPG can inform the PI about its capabilities regarding content transformation (e.g., JPEG coded pictures into WBMP if the client supports WBMP only).

106. Push OTA protocol
The push OTA protocol is a very simple protocol used on top of WSP
The protocol offers delivery of push messages, selection of transport services for push messages and authentication of PIs.
The push service can be connection-oriented or connectionless based on a bidirectional or unidirectional bearer.
The standard bearer for push messages in GSM is SMS as this is typically the only way to reach a mobile phone from within a network.

107. The following service primitives have been defined:
po-push: unacknowledged push of content within a push session via a connection- oriented service (maps to S-Push in WSP);
po-confirmedpush: acknowledged push of content within a push session via a connection-oriented service (maps to S-ConfirmedPush in WSP);
po-pushabort: rejection of a push by the client;
po-unit-push: unacknowledged push of content via a connectionless session service (maps to S-Unit-Push in WSP);

108. The following service primitives are also available for push session management:
● pom-connect: Creation of a push session by the client (maps to S-Connect in WSP);
● pom-suspend: suspension of a push session (maps to S-Suspend in WSP);
● pom-resume: Resume of a push session (maps to S-Resume in WSP);
● pom-disconnect: Termination of a push session (maps to S-Disconnect in WSP);
● pom-sessionrequest: Request for a push session by a server.
Each client has a predefined unsecured (mandatory) and WTLS secured (optional) WDP port for connectionless push services. For unidirectional bearers even the ports for sessions may be predefined so, sessions may already be set-up by default.

109. Push/Pull services in WAP I
Service Indication
Service announcement using a pushed short message
Service usage via a pull
Service identification via a URI
<?xml version="1.0"?>
<!DOCTYPE si PUBLIC "-//WAPFORUM//DTD SI 1.0//EN"
"
<si>
<indication href="
created=" T17:45:32Z"
si-expires=" T17:50:31Z">
Salad special: The 5 minute offer
</indication>
</si>

110. Push/Pull services in WAP II
Service Loading
short message pushed to a client containing a URI
User agent decides whether to use the URI via a pull
Transparent for users, always looks like a push
<?xml version="1.0"?>
<!DOCTYPE sl PUBLIC "-//WAPFORUM//DTD SL 1.0//EN"
"
<sl
href="
</sl>

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

112. i-mode – first of all a business model!
Access to Internet services in Japan provided by NTT DoCoMo
Services
, short messages, web, picture exchange, horoscope, ...
Big success (in some countries) – millions of users
Many use i-mode as PC replacement
For many this was 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 plus proprietary tags, special transport layer (Stop/go, ARQ, push, connection oriented)
mobile terminal
gateway
content provider
mobile network
cHTML + tags
cHTML + tags
HTTP(S)
HTTP(S) TL TL
TCP
TCP
TCP
TCP
PDC-P
PDC-P IP IP IP IP L2 L2 L2 L2 L1 L1 L1 L1
**Personal Digital Cellular-Packet (PDC-P) ; i-mode, which enabled Internet access from mobile phones via PDC-P

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

114. i-mode protocol stack based on WAP 2.0
user equipment
gateway
server
cHTML
HTTP
WTCP IP L2 L1
SSL
TCP
i-mode can use WAP 2.0/Internet protocols (example: i-mode in Germany over GSM/GPRS)

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

116. i-mode – very first examples I

117. i-mode – very first examples II

118. i-mode – very first examples III

119. WAP 2.0 (July 2001) New for developers New applications
XHTML
TCP with “Wireless Profile”
HTTP
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

120. WAP 2.0 architecture Service discovery Security services Application
framework
Multimedia Messaging ( )
Content formats
External services EFI
Crypto
libraries
WAE/WTA User Agent (WML, XHTMLMP)
Push
Provisioning
Authenti-cation
Protocol framework
Session
Capability Negotiation
Push
OTA
Cookies
Navigation
Discovery
Identification
Synchronisation
Transfer
Hypermedia transfer (WTP+WSP, HTTP)
Strea-ming
MMS
Service
Lookup
PKI
Transport
Datagrams
(WDP, UDP)
Connections
(TCP with wireless profile)
Secure
transport
Bearer
Secure
bearer
IPv4
CSD
USSD
GPRS
...
IPv6
SMS
FLEX
MPAK
...

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

122. Java 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
Java ME (source released as: phone ME / was: J2ME)
Provides a uniform platform
Restricted functionality compared to standard java platform (JVM)

123. Applications of Java ME
Example first 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

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

125. Hardware independent development

126. Summary Java 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

127. Other mobile application platforms
Microsoft .NET Compact Framework
run-time environment plus class library with focus on mobile devices – light-weight version of .NET
support of many programming languages (C#, Python, Ruby, C++, Haskell, …)
typically in connection with Windows CE
Qualcomm BREW (Binary Runtime Environment for Wireless)
run-time environment with main focus on games
certified applications only
Google Android
OS + middleware + applications for mobile devices
Java/Linux based, open source