Wireless Application

Protocol
World Wide Web and Mobility
HTTP/HTML have not been designed for mobile applications/devices
HTTP 1.0 characteristics
designed for large bandwidth, low delay
stateless, client/server, request/response communication
connection oriented, one connection per request
TCP 3-way handshake, DNS lookup overheads
big protocol headers, uncompressed content transfer
primitive caching (often disabled, dynamic objects)
security problems (using SSL/TLS with proxies)
HTML characteristics
designed for computers with “high” performance, color
high-resolution display, mouse, hard disk
typically, web pages optimized for design, not for
communication; ignore end-system characteristics
System Support for Mobile WWW
Enhanced browsers
client-aware support for mobility

Proxies
Client proxy: pre-fetching, caching, off-line use
Network proxy: adaptive content transformation for
connections
Client and network proxy

Enhanced servers
server-aware support for mobility
serve the content in multiple ways, depending on client
capabilities

New protocols/languages
WAP/WML
Wireless Application Protocol (WAP)
Empowers mobile users with wireless devices to easily access and
interact with information and services.
A “standard” created by wireless and Internet companies to enable
Internet access from a cellular phone

wapforum.org:
co-founded by Ericsson, Motorola, Nokia, Phone.com
450 members in 2000, comprise of Handset manufacturers, Wireless service
providers, ISPs, Software companies in the wireless industry
Goals
deliver Internet services to mobile devices
enable applications to scale across a variety of transport options and
device types
independence from wireless network standards
GSM, CDMA IS-95, TDMA IS-136, 3G systems (UMTS, W-CDMA)
WAP: Main Features
Browser
“Micro browser”, similar to existing web browsers
Markup language
Similar to HTML, adapted to mobile devices
Script language
Similar to Javascript, adapted to mobile devices
Gateway
Transition from wireless to wired world
Server
“Wap/Origin server”, similar to existing web servers
Protocol layers
Transport layer, security layer, session layer etc.
Telephony application interface
Access to telephony functions
WAP Architecture

Client Web Server

WAP Gateway
WML

with WML-Script
WML Encoder CGI

WML Decks
WML-S Scripts
WSP/WTP WMLScript
HTTP etc.
cript
Compiler
WTAI
Protocol Adapters Content
Etc.

Source: WAP Forum

WAP Application Server

Client WAP Application Server

with WML-Script
WML WML Encoder
Application

WML Decks
WML-S WSP/WTP WMLScript Logic
cript Compiler
WTAI Protocol Adapters Content
Etc.

Source: WAP Forum

WAP Specifies
Wireless Application Environment
WML Microbrowser
WMLScript Virtual Machine
WMLScript Standard Library
Wireless Telephony Application Interface (WTAI)
WAP content types

Wireless Protocol Stack

Wireless Session Protocol (WSP)
Wireless Transport Layer Security (WTLS)
Wireless Transaction Protocol (WTP)
Wireless Datagram Protocol (WDP)
Wireless network interface definitions
Wireless Application Environment (WAE)

Goals
device and network independent application environment
for low-bandwidth, wireless devices
considerations of slow links, limited memory, low computing
power, small display, simple user interface (compared to
desktops)
integrated Internet/WWW programming model
high interoperability
WAE Components
Architecture
Application model, Microbrowser, Gateway, Server
User Agents
WML/WTA/Others
content formats: vCard, vCalendar, Wireless Bitmap, WML, ...
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)
Proxy (Method/Push)
WAE: Logical Model
Origin Servers Gateway Client

response Method encoded WTA

web
with proxy response user agent
server
content with
content
other Push proxy WML
content user agent
server push encoded
content push
content
encoders other
& WAE
decoders user agents
request encoded
request
WAP Microbrowser

Optimized for wireless devices

Minimal RAM, ROM, Display, CPU and keys
Provides consistent service UI across
devices
Provides Internet compatibility
Enables wide array of available content and
applications
WML: Wireless Markup Language
Based on Standard HTML
Tag-based browsing language:
Screen management (text, images)
Data input (text, selection lists, etc.)
Hyperlinks & navigation support
Takes into account limited display, navigation capabilities of devices
XML-based language
describes only intent of interaction in an abstract manner
presentation depends upon device capabilities
WML Features:
Text and Images
User Interactions
Navigation
Context management
WML
The basic unit is a card. Cards are grouped together into Decks Document ~ Deck (unit of
transfer)
WML deck is similar to HTML Page
User interactions are split into cards
Explicit navigation between cards
All decks must contain
Document prologue
XML & document type declaration
<WML> element
Must contain one or more cards

WML File Structure

<?xml version="1.0"?>
<!DOCTYPE WML PUBLIC "-//WAPFORUM//DTD WML 1.0//EN"
"http://www.wapforum.org/DTD/wml.xml">

<WML>
...
</WML>
 WML Example
<WML>
<CARD>
<DO TYPE=“ACCEPT”>
Navigation <GO URL=“#eCard”/>
Card
</DO
Welcome!
</CARD>
<CARD NAME=“eCard”>
<DO TYPE=“ACCEPT”>
Variables <GO Deck
URL=“/submit?N=$(N)&S=$(S)”/>
</DO>
Enter name: <INPUT KEY=“N”/>
Choose speed:
Input <SELECT KEY=“S”>
Elements <OPTION VALUE=“0”>Fast</OPTION>
<OPTION VALUE=“1”>Slow</OPTION>
<SELECT>
</CARD>
</WML>
A Deck of Cards

<WML>
<CARD>
<DO TYPE="ACCEPT" LABEL="Next"> Acme Inc.
<GO URL="#card2"/> Directory
</DO>
_____________
Acme Inc.<BR/>Directory
</CARD>
Next

<CARD NAME="card2">
<DO TYPE="ACCEPT">
<GO URL="?send=$type"/>
</DO> Services
Services 1>Email
<SELECT KEY="type"> 2 Phone
<OPTION VALUE="em">Email</OPTION> ____________
<OPTION VALUE="ph">Phone</OPTION> OK
<OPTION VALUE="fx">Fax</OPTION>
</SELECT>
</CARD>
</WML>

Source: WAP Forum

WML Content Formats
Common interchange formats, for interoperability
Formats:
Business cards: IMC vCard standard
Calendar: IMC vCalendar standard
Images: WBMP (Wireless BitMaP)
Compiled WML, WMLScript
Newly defined formats:
WML text and tokenized format
WMLScript text and bytecode format
WBMP image format
Binary format for size reduction
Bytecodes/tokens for common values and operators
Compressed headers
Data compression (e.g. images)
General-purpose transport compression can still be applied
WMLScript
Complement to WML
Derived from JavaScript™
Provides general scripting capabilities
Procedural logic, loops, conditionals, etc.
Optimized for small-memory, small-cpu devices

Features
local user interaction, validity check of user input
access to device facilities (phone call, address book etc.)
extensions to the device software
configure device, download new functionality after deployment

Bytecode-based virtual machine

Stack-oriented design, ROM-able
Designed for simple, low-impact implementation
WMLScript compiler resides in the network
WMLScript Libraries
Lang - VM constants, general-purpose math functionality,
etc.
String - string processing functions
URL - URL processing
Browser - WML browser interface
Dialog - simple user interface
Float - floating point functions
 WMLScript Example

function currencyConvertor(currency, exchRate)

Functions {
return currency*exchangeRate;
}

Variables function myDay(sunShines) {

var myDay;
if (sunShines) {
Programming myDay = “Good”;
Constructs } else {
myDay = “Not so good”;
};
return myDay;
}

Source: WAP Forum

Wireless Telephony Application (WTA)
Collection of telephony specific extensions
designed primarily for network operators

Example
calling a number (WML)
wtai://wp/mc;07216086415
calling a number (WMLScript)
WTAPublic.makeCall("07216086415");

Implementation
Extension of basic WAE application model
Extensions added to standard WML/WMLScript browser
Exposes additional API (WTAI)
WTA Features
Extension of basic WAE application model
network model for interaction
client requests to server
event signaling: server can push content to the client
event handling
table indicating how to react on certain events from the network
client may now be able to handle unknown events
telephony functions
some application on the client may access telephony functions
WTAI includes:
Call control
Network text messaging
Phone book interface
Event processing
Security model: segregation
Separate WTA browser
Separate WTA port
WTA Logical Architecture
other telephone networks
WTA Origin Server

WML Client
Scrip
ts WTA & mobile WTA
WML network user agent
WML server
deck
s WAE
WTA WAP Gateway services
service
s encoders
&
network operator decoders
other
trusted domain
WTA
servers
third party
origin firewall
servers

Source: Schiller
WTA User Agent
WTA User Agent
WML User agent with extended functionality
can access mobile device’s telephony functions through WTAI
can store WTA service content persistently in a repository
handles events originating in the mobile network

WTA User Agent Context

Abstraction of execution space
Holds current parameters, navigation history, state of user agent
Similar to activation record in a process address space

Uses connection-mode and connectionless services offered by WSP

Specific, secure WDP ports on the WAP gateway
WTA Events and Repository
WTA Events
Network notifies device of event (such as incoming call)
WTA events map to device’s native events
WTA services are aware of and able to act on these events
example: incoming call indication, call cleared, call connected
WTA Repository
local store for content related to WTA services (minimize network traffic)
Channels: define the service
content format defining a WTA service stored in repository
XML document specifying eventid, title, abstract, and resources that
implement a service
Resources: execution scripts for a service
could be WML decks, WML Scripts, WBMP images..
downloaded from WTA server and stored in repository before service is
referenced
Server can also initiate download of a channel
WAP Push Services
Web push
Scheduled pull by client (browser)
example: Active Channels
no real-time alerting/response
example: stock quotes
Wireless push
accomplished by using the network itself
example: SMS
limited to simple text, cannot be used as starting point for
service
example: if SMS contains news, user cannot request specific news item
WAP push
Network supported push of WML content
example: Alerts or service indications
Pre-caching of data (channels/resources)
WAP Push Framework

Source: Heijden
Push Access Protocol
Based on request/response model
Push initiator is the client
Push proxy is the server
Initiator uses HTTP POST to send push message to
proxy
Initiator sends control information as an XML
document, and content for mobile (as WML)
Proxy sends XML entity in response indicating
submission status
Initiator can
cancel previous push
query status of push
query status/capabilities of device
Push Proxy Gateway

WAP stack (communication with mobile device)

TCP/IP stack (communication with Internet push
initiator)
Proxy layer does
control information parsing
content transformation
session management
client capabilities
store and forward
prioritization
address resolution
management function
WAE Summary
WML
analogous to HTML (optimized for wireless)
event based, microbrowser user agent
WMLScript
analogous to JavaScript
features of compiler in the network
WTA
WTAI: different access rights for different applications/agents
WTA User Agent (analogy with operating systems)
Context – Activation Record
Channel – Interrupt Handler
Resource – Shared routines invoked by interrupt handlers
Repository – Library of interrupt handlers
feature of dynamically pushing the interrupt handler before the event
Push
no analogy in Internet
WAP Gateway Summary
Encoders
translate between binary (WML) and text (HTML/WML)
Filters
transcoding between WML (wireless) and HTML (wired)
Method Proxy
similar to standard proxy services
WAP stack on wireless interface and TCP/IP stack on Internet
interface
Push Proxy
Push Access Protocol with Internet Push Initiator (Web Server)
Over the Air Protocol with mobile device (and WAP Push
Initiator)
Performs necessary filtering, translation etc.
WAP Servers Summary
Origin Server
Web server with HTML/WML contents
Runs TCP/IP stack, needs PAP protocol for push, no
end-to-end security
WAP Server
Serves WML content
Runs WAP stack, uses OTA protocol for push, end-to-end
security possible
WTA Server
Specialized for telephony applications (runs WAP stack,
uses push extensively)
Client initiated (make call “hyperlink” from a Yellow pages
service)
Server intiated (incoming call from a Voice mail service)
 WAP: Protocol Stack
Internet A-SA WAP
P
HTML, Java Application Layer (WAE) additional services
S-SA and applications
P
Session Layer (WSP)
TR-S
HTTP
AP
Transaction Layer (WTP)
SEC
-SAP
SSL/TLS Security Layer (WTLS)
T-SA
P
TCP/IP, Transport Layer (WDP) WCMP
UDP/IP,
media Bearers (GSM, CDPD, ...)

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

Source: Schiller
WDP: Wireless Datagram Protocol
Goals
create a worldwide interoperable transport system by adapting WDP to the
different underlying technologies
transmission services, such as SMS in GSM might change, new services can
replace the old ones

WDP
Transport layer protocol within the WAP architecture
uses the Service Primitive
T-UnitData.req .ind
uses transport mechanisms of different bearer technologies
offers a common interface for higher layer protocols
allows for transparent communication despite different technologies
addressing uses port numbers
WDP over IP is UDP/IP
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
SAP: Service Access Point
(EC)
DA: Destination Address
DP: Destination Port
SA: Source Address
SP: Source Port
UD: User Data
EC: Error Code

Source: Schiller
WTLS:Wireless Transport Layer Security
Goals
Provide mechanisms for secure transfer of content, for applications needing
privacy, identification, message integrity and non-repudiation
Provide support for protection against denial-of-service attacks

WTLS
is based on the TLS/SSL (Transport Layer Security) protocol
optimized for low-bandwidth communication channels
provides
privacy (encryption)
data integrity (MACs)
authentication (public-key and symmetric)
Employs special adapted mechanisms for wireless usage
Long lived secure sessions
Optimised handshake procedures
Provides simple data reliability for operation over datagram bearers
WTLS: Secure session, Full handshake
originator peer
SEC-SAP 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 SEC-Exchange.req
(SNM, KR, SID, KES‘, CS‘, CM‘) KES: Key Exchange Suite
SEC-Exchange.ind CS: Cipher Suite
SEC-Exchange.res CM: Compression Mode
(CC)
SNM: Sequence Number Mode
SEC-Commit.req SEC-Exchange.cnf
(CC)
SEC-Commit.ind
KR: Key Refresh Cycle
SEC-Commit.cnf
SID: Session Identifier
CC: Client Certificate

Source: Schiller
WTLS: Transferring Datagrams

sender receiver
SEC-SAP SEC-SAP
SEC-Unitdata.req
(SA, SP, DA, DP, UD) SEC-Unitdata.ind
(SA, SP, DA, DP, UD)

Source: Schiller
WTP: Wireless Transaction Protocol
Goals
different transaction services that enable applications to select reliability, efficiency
levels
low memory requirements, suited to simple devices (< 10kbyte )
efficiency for wireless transmission
WTP
supports peer-to-peer, client/server and multicast applications
efficient for wireless transmission
support for different communication scenarios
class 0: unreliable message transfer
unconfirmed Invoke message with no Result message
a datagram that can be sent within the context of an existing Session
class 1: reliable message transfer without result message
confirmed Invoke message with no Result message
used for data push, where no response from the destination is expected
class 2: reliable message transfer with exactly one reliable result message
confirmed Invoke message with one confirmed Result message
a single request produces a single reply
WTP Services and Protocols
WTP (Transaction)
provides reliable data transfer based on request/reply paradigm
no explicit connection setup or tear down
optimized setup (data carried in first packet of protocol exchange)
seeks to reduce 3-way handshake on initial request
supports
header compression
segmentation /re-assembly
retransmission of lost packets
selective-retransmission
port number addressing (UDP ports numbers)
flow control
message oriented (not stream)
supports an Abort function for outstanding requests
supports concatenation of PDUs
supports User acknowledgement or Stack acknowledgement option
acks may be forced from the WTP user (upper layer)
default is stack ack
 WTP Services and Protocols
uses the service primitives
T-TRInvoke.req .cnf. .ind .res
T-TRResult.req .cnf .ind .res
T-Abort.req .ind

Client (PDUs) Server

T-TRInvoke.req
Invoke T-TRInvoke.ind

T-TRInvoke.cnf Ack T-TRInvoke.res

Result
T-TRResult.req
T-TRResult.ind
T-TRResult.res Ack T-TRResult.cnf
WTP Class 0 Transaction

initiator responder
TR-SAP TR-SAP
TR-Invoke.req
(SA, SP, DA, DP, A, UD, C=0, H) TR-Invoke.ind
Invoke
PDU (SA, SP, DA, DP, A, UD, C=0, H‘)

A: Acknowledgement Type
(WTP/User)
C: Class (0,1,2)
H: Handle (socket alias)

Source: Schiller
WTP Class 1 Transaction, no user ack
& user ack
initiator responder
TR-SAP TR-SAP
TR-Invoke.req
(SA, SP, DA, DP, A, UD, C=1, H) TR-Invoke.ind
Invoke
PDU (SA, SP, DA, DP, A, UD, C=1, H‘)
TR-Invoke.cnf U
(H) Ack PD

initiator responder
TR-SAP TR-SAP
TR-Invoke.req
(SA, SP, DA, DP, A, UD, C=1, H) TR-Invoke.ind
Invoke
PDU (SA, SP, DA, DP, A, UD, C=1, H‘)
TR-Invoke.res
(H‘)
TR-Invoke.cnf U
(H) Ack PD

Source: Schiller
WTP Class 2 Transaction, no user ack,
no hold on
initiator responder
TR-SAP TR-SAP
TR-Invoke.req
(SA, SP, DA, DP, A, UD, C=2, H) TR-Invoke.ind
Invoke
PDU (SA, SP, DA, DP, A, UD, C=2, H‘)
TR-Result.req
(UD*, H‘)
TR-Invoke.cnf PDU
(H) Result

TR-Result.ind
(UD*, H)
TR-Result.res
(H)
Ack PD TR-Result.cnf
U
(H‘)

Source: Schiller
WTP Class 2 Transaction, user ack
initiator responder
TR-SAP TR-SAP
TR-Invoke.req
(SA, SP, DA, DP, A, UD, C=2, H) TR-Invoke.ind
Invoke
PDU (SA, SP, DA, DP, A, UD, C=2, H‘)
TR-Invoke.res
(H‘)
TR-Invoke.cnf U
(H) Ack PD TR-Result.req
(UD*, H‘)
TR-Result.ind PDU
(UD*, H) Result

TR-Result.res
(H)
Ack PD TR-Result.cnf
U
(H‘)

Source: Schiller
WTP Class 2 Transaction, hold on, no
user ack
initiator responder
TR-SAP TR-SAP
TR-Invoke.req
(SA, SP, DA, DP, A, UD, C=2, H) TR-Invoke.ind
Invoke
PDU (SA, SP, DA, DP, A, UD, C=2, H‘)
TR-Invoke.cnf U
(H) Ack PD TR-Result.req
(UD*, H‘)
TR-Result.ind PDU
Result
(UD*, H)
TR-Result.res
(H)
Ack PD TR-Result.cnf
U
(H‘)

Source: Schiller
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

WSP Services
provides shared state between client and server, optimizes content transfer
session management (establish, release, suspend, resume)
efficient capability negotiation
content encoding
push

WSP/B (Browsing)
HTTP/1.1 functionality - but binary encoded
exchange of session headers
push and pull data transfer
asynchronous requests
HTTP 1.1 and WSP
HTTP 1.1
extensible request/reply methods
extensible request/reply headers
content typing
composite objects
asynchronous requests
WSP enhancements beyond HTTP
binary header encoding
session headers
confirmed and non-confirmed data push
capability negotiation
suspend and resume
fully asynchronous requests
connectionless service
Why Not HTTP?
encoding not compact enough, inefficient capability negotiation
no push facility
WSP Overview
Header Encoding
compact binary encoding of headers, content type identifiers and other
well-known textual or structured values
reduces the data actually sent over the network
Capabilities (are defined for):
message size, client and server
protocol options: Confirmed Push Facility, Push Facility, Session Suspend
Facility, Acknowledgement headers
maximum outstanding requests
extended methods
header code pages
Suspend and Resume
server knows when client can accept a push
multi-bearer devices
dynamic addressing
allows the release of underlying bearer resources
WSP Sessions
Session Context and Push
push can take advantage of session headers
server knows when client can accept a push

Connection-mode
long-lived communication, benefits of the session state,
reliability

Connectionless-mode
stateless applications, no session creation overhead, no
reliability overhead
WSP/B session establishment
client server
S-SAP S-SAP
S-Connect.req
(SA, CA, CH, RC) Conne S-Connect.ind
ct PDU
(SA, CA, CH, RC)
S-Connect.res
(SH, NC)
S-Connect.cnf eply PDU
(SH, NC) ConnR

CH: Client Header

WTP Class 2
RC: Requested Capabilities
transaction
SH: Server Header
NC: Negotiated Capabilities

Source: Schiller
WSP/B session suspend/resume
client server
S-SAP S-SAP

S-Suspend.req Suspen S-Suspend.ind

d PDU
S-Suspend.ind (R)
(R) WTP Class 0
transaction
R: Reason for disconnection
S-Resume.req ~ ~
(SA, CA) Resum S-Resume.ind
e PDU
(SA, CA)
S-Resume.res
U
S-Resume.cnf R eply PD

WTP Class 2
transaction

Source: Schiller
WSP/B session termination

client server
S-SAP S-SAP
S-Disconnect.req
(R) Discon S-Disconnect.ind
nect PD
S-Disconnect.ind U (R)
(R) WTP Class 0
transaction

Source: Schiller
WAP Stack Summary
WDP
functionality similar to UDP in IP networks
WTLS
functionality similar to SSL/TLS (optimized for wireless)
WTP
Class 0: analogous to UDP
Class 1: analogous to TCP (without connection setup overheads)
Class 2: analogous to RPC (optimized for wireless)
features of “user acknowledgement”, “hold on”
WSP
WSP/B: analogous to http 1.1 (add features of suspend/resume)
method: analogous to RPC/RMI
features of asynchronous invocations, push (confirmed/unconfirmed)