WD99Technical990506

Wireless Application ProtocolTechnical Overview: 

Wireless Application Protocol Technical Overview Natasha Flaherty Senior Marketing Manager Phone.com WAP Forum

Agenda: 

Agenda WAP Architecture Wireless Application Environment Protocol Layers Interoperability Security

Slide3: 

Introduction and Overview WAP Architecture

The WAP Architecture: 

The WAP Architecture

Slide5: 

Internet Comparison between Internet and WAP Technologies

WAP specifies…: 

WAP specifies… Wireless Application Environment WML Microbrowser WMLScript Virtual Machine WMLScript Standard Library Wireless Telephony Application Interface WAP Content Types Wireless Protocols Wireless Session Protocol (WSP) Wireless Transport Layer Security (WTLS) Wireless Transaction Protocol (WTP) Wireless Datagram Protocol (WDP) Wireless network interface definitions

WHY WAP ?: 

WHY WAP ? Wireless networks and phones have specific needs and requirements not addressed by existing Internet technologies. Only be met by participation from entire industry. WAP enables any data transport TCP/IP, UDP/IP, GUTS (IS-135/6), SMS, or USSD. The WAP architecture several modular entities together form a fully compliant Internet entity all WML content is accessed via HTTP 1.1 requests.

WHY WAP ?: 

WHY WAP ? WAP utilizes standard Internet markup language technology (XML) Optimizing the content and airlink protocols The WML UI components map well onto existing mobile phone user interfaces no re-education of the end-users leveraging market penetration of mobile devices WAP utilizes plain Web HTTP 1.1 servers leveraging existing development methodologies CGI, ASP, NSAPI, JAVA, Servlets, etc.

Why is HTTP/HTML not enough?: 

Why is HTTP/HTML not enough? Big pipe - small pipe syndrome

WHY WAP ?: 

WHY WAP ? Good relationships with standards Several Liaisons with ETSI ETSI / WAP compliance profile for GSM and UMTS. CTIA official Liaison Officer to the WAP Forum WAP is actively working with the W3C and IETF HTML-NG (HTML Next Generation) HTTP-NG (HTML Next Generation)

Architecture Group Current Work: 

Architecture Group Current Work End-to-end security Billing Asynchronous Applications Bearer selection Gateway switching PUSH Architecture Persistence Definition Meeting format changes

Slide12: 

WAP Application Environment WML and WMLScript Wireless Telephony Architecture Content Formats Push User Agent Profile

WAE Goals: 

WAE Goals Network-neutral application environment; For narrowband wireless devices; With an Internet/WWW programming model; And a high degree of interoperability.

WAE Requirements: 

WAE Requirements Leverage WSP and WTP Leverage Internet standard technology Device Independent Network Independent International Support

Requirements (cont.): 

Requirements (cont.) Vendor-controlled MMI Initial focus on phones Slow bearers Small memory Limited CPU Small screen Limited input model

WAE First Generation: 

WAE First Generation Architecture Application model Browser, Gateway, Content Server WML Display language WMLScript Scripting language WTA Telephony services API and architecture Content Formats Data exchange

WML Second Generation: 

WML Second Generation Extensions and enhancements Currently under development User Agent Profiling Content customized for device Push Model Network-initiated content delivery Performance Enhancements Caching, etc.

WAE Abstract Network Architecture: 

WSP/HTTP Request {URL} WSP/HTTP Reply {Content} WAE Abstract Network Architecture

Network Example #1: WAP Gateway: 

Web Server WML Decks with WML-Script HTTP WSP/WTP Network Example #1: WAP Gateway

Network Example #2:WAP Application Server: 

WAP Application Server Application Logic WML Decks with WML-Script WSP/WTP Network Example #2: WAP Application Server

WML: 

WML Tag-based browsing language: Screen management (text, images) Data input (text, selection lists, etc.) Hyperlinks & navigation support W3C XML-based language Inherits technology from HDML and HTML

WML (cont.): 

WML (cont.) Card metaphor User interactions are split into cards Navigation occurs between cards Explicit inter-card navigation model Hyperlinks UI Event handling History State management and variables Reduce network traffic Results in better caching

All decks must contain...: 

All decks must contain... Document prologue XML & document type declaration <WML> element Must contain one or more cards

WML Example: 

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

A Deck of Cards: 

<WML> <CARD> <DO TYPE="ACCEPT" LABEL="Next"> <GO URL="#card2"/> </DO> Acme Inc.<BR/>Directory </CARD> <CARD NAME="card2"> <DO TYPE="ACCEPT"> <GO URL="?send=$type"/> </DO> Services <SELECT KEY="type"> <OPTION VALUE="em">Email</OPTION> <OPTION VALUE="ph">Phone</OPTION> <OPTION VALUE="fx">Fax</OPTION> </SELECT> </CARD> </WML> A Deck of Cards Acme Inc. Directory _____________ Next Services 1>Email 2 Phone ____________ OK

Example: Input Activity: 

Accept Prev Query Deck Back First Name: Jane_ ____________ Next Last Name: Doe_ ____________ Done Example: Input Activity

Defining the Navigation Path: 

Defining the Navigation Path <CARD> <DO TYPE="ACCEPT" LABEL="Next"> <GO URL="#card2"/> </DO> First name: <INPUT KEY="fname"/> </CARD> <CARD NAME="card2"> <DO TYPE="ACCEPT" LABEL="Done"> <GO URL="?get=person" METHOD="POST" POSTDATA="first=$fname&amp;last=$lname"/> </DO> Last name: <INPUT KEY="lname"/> </CARD>

The DO Element: 

<DO TYPE="ACCEPT" LABEL="Next"> <GO URL="http://www.mysite.com/myapp.wml"/> </DO> The DO Element Binds a task to a user action Action type: ACCEPT, OPTIONS, HELP PREV, DELETE, RESET Label: Text string or image (optional) Task: GO PREV, REFRESH, NOOP Destination: URL Post data: if METHOD=POST

Anchored Links: 

Anchored Links Bind a task to the ACCEPT action, when cursor points to a link TITLE= sets the label string (default = “Link”) Links are not allowed in select list options <CARD> Please visit our <A TITLE="Visit"> <GO URL="home.wml"/>home page</A> for details. </CARD> Please visit our home page for ____________ Visit

Task Binding Rules: 

Task Binding Rules User actions are scoped at three levels • Deck • Card • Anchored links & select list options (ACCEPT) When tasks are bound to an action at different levels, the action with narrower scope takes precedence Default task bindings User Action Task ACCEPT, PREV PREV Others NOOP

The TEMPLATE Element: 

<WML> <TEMPLATE> <DO TYPE="OPTIONS" LABEL="Main"> <GO URL="main_menu.wml"/> </DO> </TEMPLATE> <CARD NAME="msg1"> <DO TYPE="ACCEPT" LABEL="Next"> <GO URL="#msg2"/> </DO> First story </CARD> <CARD NAME="msg2"> Second story </CARD> </WML> The TEMPLATE Element Defines actions & events for all cards in a deck First story … _____________ Next Main Second story ... _____________ OK Main

Handling User Input: 

Handling User Input Select lists Choose from a list of options Input fields Enter a string of text or numbers KEY variables Set by SELECT and INPUT elements How user input is passed to other cards and the application server

The SELECT Element: 

<CARD> <DO TYPE="ACCEPT" LABEL="View"> <GO URL="getcity.cgi?location=$city"/> </DO> Forecast <SELECT KEY="city"> <OPTION VALUE="ber">Berlin</OPTION> <OPTION VALUE="rom">Rome</OPTION> <OPTION TITLE="Find" ONCLICK="find.cgi">New City</OPTION> </SELECT> </CARD> Forecast 1 Berlin 2 Rome 3>New City ____________ Find The SELECT Element Display a list of options Each option may set the KEY variable and/or bind a task to the ACCEPT key TITLE= dynamically sets the label string

Other SELECT Attributes: 

Other SELECT Attributes MULTIPLE="TRUE" Allows user to pick multiple items UP.Browser reserves soft key for item-picker Key value is a semicolon-separated list DEFAULT=key_value Default KEY value, if one is not chosen Sets cursor to the default choice entry, if a corresponding OPTION / VALUE exists

A Long Select List: 

A Long Select List <CARD> <DO TYPE="ACCEPT"> <GO URL="get_addr.cgi?id=$recid"/> </DO> Addr [1..9] <SELECT KEY="recid" MULTIPLE="TRUE" DEFAULT="1;3;5"> <OPTION VALUE="1">Neil</OPTION> <OPTION VALUE="2">Kurt</OPTION> <OPTION VALUE="3">Jim</OPTION> <OPTION VALUE="4">Natasha</OPTION> <OPTION VALUE="5">Liz</OPTION> <OPTION VALUE="6">Aneesh</OPTION> <OPTION VALUE="7">Jennifer</OPTION> <OPTION VALUE="8">Jesse</OPTION> <OPTION VALUE="9">Dawnell</OPTION> <OPTION ONCLICK="#card2">More...</OPTION> </SELECT> </CARD>

The INPUT Element: 

<CARD> <DO TYPE="ACCEPT"> <GO URL="?get=person" METHOD="POST" POSTDATA="userid=$ssn"/> </DO> Soc Security: <INPUT KEY="ssn" FORMAT="NNN\-NN\-NNNN"/> </CARD> Soc. Security: 287-33- _ ____________ NUM Soc. Security: 287-33- 7629 ____________ OK The INPUT Element Prompts user to enter a string of text Use FORMAT= to constrain input UP.Browser reserves soft key for text entry mode, if necessary

Other INPUT Attributes: 

Other INPUT Attributes DEFAULT=key_value Default KEY variable (displayed to user) FORMAT=format_specifier If omitted, free-form entry is allowed EMPTYOK="TRUE" Browser will accept null input, even with format TYPE="PASSWORD" Special entry mode handled by the browser MAXLENGTH=number Maximum number of allowed characters

FORMAT Control Characters: 

FORMAT Control Characters N Numeric character A, a Alphabetic character X, x Numeric or alphabetic character M, m Any character Leading backslash specifies forced characters Forced characters included in KEY variable value Leading * specifies 0 or more characters Password: FORMAT=“mmmm*m” Leading number specifies 0..N characters Zipcode: FORMAT=“NNNNN\-4N”

Displaying Images: 

<CARD> <DO TYPE="ACCEPT"> <GO URL="#c2"/> </DO> Continue <IMG LOCALSRC="righthand" ALT="forward..."/> </CARD> <CARD NAME="c2"> <IMG SRC="../images/logo.bmp" ALT="Unwired Planet"/> <BR/>Welcome! </CARD> Displaying Images Insert app images or local icons within display text 1-bit BMP format Images are ignored by non-bitmapped devices Check HTTP_ACCEPT for “image/bmp”

Special WML Characters: 

Special WML Characters Use character entities in display text &quot; " &amp; & &apos; ' &lt; < &gt; > &nbsp; Blank space &shy; Soft hyphen (discretionary line break) Replace the “&” character in URL strings URL="query.cgi?first=$fname&amp;last=$lname" Use “$$” to display a single “$” character

Doing more with WML: 

Doing more with WML Setting card styles to create forms Using variables to cache user data Using card intrinsic events to trigger transparent tasks Using timers Securing WML decks Bookmarking decks

WMLScript: 

WMLScript Scripting language: Procedural logic, loops, conditionals, etc. Optimized for small-memory, small-cpu devices Derived from JavaScript™ Integrated with WML Powerful extension mechanism Reduces overall network traffic

WMLScript (cont.): 

WMLScript (cont.) Bytecode-based virtual machine Stack-oriented design ROM-able Designed for simple, low-impact implementation Compiler in network Better network bandwidth use Better use of terminal memory/cpu.

WMLScript Standard Libraries: 

WMLScript Standard 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 Uses: 

WMLScript Example Uses Reduce network round-trips and enhance functionality. Field validation Check for formatting, input ranges, etc. Device extensions Access device or vendor-specific API Conditional logic Download intelligence into the device

WMLScript Example: 

WMLScript Example WMLScript is very similar to JavaScript function currencyConvertor(currency, exchRate) { return currency*exchangeRate; } function myDay(sunShines) { var myDay; if (sunShines) { myDay = “Good”; } else { myDay = “Not so good”; }; return myDay; }

WTA: 

WTA Tools for building telephony applications Designed primarily for: Network Operators / Carriers Equipment Vendors Network security and reliability a major consideration

WTA (cont.): 

WTA (cont.) WTA Browser Extensions added to standard WML/WMLScript browser Exposes additional API (WTAI) WTAI includes: Call control Network text messaging Phone book interface Indicator control Event processing

WTA (cont.): 

WTA (cont.) Network model for client/server interaction Event signaling Client requests to server Security model: segregation Separate WTA browser Separate WTA port WTAI available in WML & WMLScript

WTA Example: 

Placing an outgoing call with WTAI: <WML> <CARD> <DO TYPE=“ACCEPT”> <GO URL=“wtai:cc/mc;$(N)”/> </DO> Enter phone number: <INPUT TYPE=“TEXT” KEY=“N”/> </CARD> </WML> WTA Example

WTA Example: 

Placing an outgoing call with WTAI: function checkNumber(N) { if (Lang.isInt(N)) WTAI.makeCall(N); else Dialog.alert(“Bad phone number”); } WTA Example

Content Formats: 

Content Formats Common interchange formats Promoting interoperability Formats: Business cards: IMC vCard standard Calendar: IMC vCalendar standard Images: WBMP (Wireless BitMaP) Compiled WML, WMLScript

New WAP Content Formats: 

New WAP Content Formats 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

Content Format Example: 

Content Format Example <WML> <CARD> Hello World!<BR/> <IMG SRC=“/world.wbmp” ALT=“[Globe]” /> </CARD> </WML> Example Use of an Image:

Push: 

Push Push is under development Network-push of content Alerts or service indications Pre-caching of data Goals: Extensibility and simplicity Build upon WAP 1.0 End-to-end solution Security User friendly

User Agent Profiles (UAProf): 

User Agent Profiles (UAProf) UAProf is under development Goal: content personalization, based upon: Device characteristics, user preferences Other profile information Working with W3C on CC/PP RDF-based content format Describes “capability and profile” info Efficient transport over wireless links, caching, etc.

WAE Technical Collaboration: 

WAE Technical Collaboration W3C White paper published Technical collaboration CC/PP HTML-NG HTTP-NG Etc. ETSI/MExE Others coming soon

Summary: WAE Status: 

Summary: WAE Status First generation released Implementations are in progress Specifications include: WAE, WML, WMLScript WBMP, WTA, WTAI, etc. Second generation in development Focusing on: Push, Interoperability, UAProf Telephony, Internationalization, etc.

Wireless Session ProtocolWireless Transaction ProtocolWireless Datagram Protocol: 

Wireless Session Protocol Wireless Transaction Protocol Wireless Datagram Protocol Wireless Transport Protocols

WAP Protocol Layers: 

WAP Protocol Layers

WAP Transport Services: 

WAP Transport Services WSP is the Session Layer Protocol WTP is the Transaction-Oriented protocol WDP is the Datagram protocol

WSP Overview: 

WSP Overview Provides shared state between client and server used to optimize content transfer Provides semantics and mechanisms based on HTTP 1.1 Enhancements for WAE, wireless networks and “low-end” devices Compact encoding Push Efficient negotiation

HTTP 1.1 Basis: 

HTTP 1.1 Basis Extensible request/reply methods Extensible request/reply headers Content typing Composite objects Asynchronous requests

Enhancements Beyond HTTP: 

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?: 

Why Not HTTP? Encoding not compact enough No push facility Inefficient capability negotiation

Header Encoding: 

Header Encoding Defined 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: 

Capabilities 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: 

Suspend and Resume Server knows when client can accept a push Multi-bearer devices Dynamic addressing Allows the release of underlying bearer resources

Session Context and Push: 

Session Context and Push Push can take advantage of session headers Server knows when client can accept a push

Connection And Connectionless Modes: 

Connection And Connectionless Modes Connection-mode Long-lived communication Benefits of the session state Reliability Connectionless Stateless applications No session creation overhead No reliability overhead

WSP Work items: 

WSP Work items Support for Quality of Service parameters Multicast data Ordered pipelining WSP Management entities Support for isochronous multimedia objects Other extended functionality that is not a part of the first public version Bug fixes and various corrigenda

Wireless Transaction Protocol: 

Wireless Transaction Protocol Purpose: Provide efficient request/reply based transport mechanism suitable for devices with limited resources over networks with low to medium bandwidth. Advantages: Operator Perspective - Load more subscribers on the same network due to reduced bandwidth utilization. Individual User - Performance is improved and cost is reduced.

WTP Services and Protocols: 

WTP Services and Protocols WTP (Transaction) provides reliable data transfer based on request/reply paradigm no explicit connection setup or tear down data carried in first packet of protocol exchange seeks to reduce 3-way handshake on initial request supports retransmission of lost packets selective-retransmission segmentation / re-assembly port number addressing (UDP ports numbers) flow control message oriented (not stream) supports an Abort function for outstanding requests supports concatenation of PDUs

WTP Services and Protocols: 

WTP Services and Protocols WTP continued uses the service primitives T-TRInvoke.req .cnf. .ind .res T-TRResult.req .cnf .ind .res T-Abort.req .ind an example of a WTP protocol exchange

WDP Services and Protocols: 

WDP Services and Protocols WDP (Datagram) provides a connection-less, unreliable datagram service WDP is replaced by UDP when used over an IP network layer. WDP over IP is UDP/IP uses the Service Primitive T-UnitData.req .ind

Bearers: 

GSM SMS, USSD, C-S Data, GPRS IS-136 R-Data, C-S Data, Packet CDMA SMS, C-S Data PDC C-S Data, Packet PHS C-S Data CDPD iDEN SMS, C-S Data, Packet FLEX and ReFLEX DataTAC Bearers Bearers currently supported by WAP

Service, Protocol, and Bearer Example: 

WAP Over GSM Circuit-Switched Service, Protocol, and Bearer Example

Service, Protocol, and Bearer Example: 

WAP Over GSM Short Message Service SMS WDP WTP WSP WAE SMS Subnetwork WDP WDP Tunnel Protocol Subnetwork WDP Tunnel Protocol WTP WSP WAE Apps on other servers SMSC WAP Proxy/Server Mobile under development Service, Protocol, and Bearer Example

WPG Current Issues: 

WPG Current Issues Definition of Wireless TCP via liaison with IETF PILC Working Group Over The Air Provisioning Cell Broadcast SMS-C standardized interface (WDP tunneling protocol) UDP Port number assignment from IANA

Slide80: 

WTLS Services & Characteristics WAP Security

WSG Work Area: 

WSG Work Area Provide mechanisms for secure transfer of content, to allow for applications needing privacy, identification, verified message integrity and non-repudiation Transport level security is WTLS, based on SSL and TLS from the Internet community Working on various mechanisms for improved end-to-end security and application-level security

WTLS Services and Characteristics: 

WTLS Services and Characteristics Specifies a framework for secure connections, using protocol elements from common Internet security protocols like SSL and TLS. Provides security facilities for encryption, strong authentication, integrity, and key management Compliance with regulations on the use of cryptographic algorithms and key lengths in different countries Provides end-to-end security between protocol end points

WTLS Services and Characteristics: 

WTLS Services and Characteristics Provides connection security for two communicating applications privacy (encryption) data integrity (MACs) authentication (public-key and symmetric) Lightweight and efficient protocol with respect to bandwidth, memory and processing power Employs special adapted mechanisms for wireless usage Long lived secure sessions Optimised handshake procedures Provides simple data reliability for operation over datagram bearers

Goals and Requirements for WTLS: 

Goals and Requirements for WTLS Interoperable protocols Scalability to allow large scale application deployment First class security level Support for public-key certificates Support for WAP transport protocols

WTLS Internal Architecture: 

Record Protocol Handshake Protocol Alert Protocol Application Protocol Change Cipher Spec Protocol Transaction Protocol (WTP) Datagram Protocol (WDP/UDP) Bearer networks WTLS Record protocol WTLS Internal Architecture

Current Work Items: 

Current Work Items Improved support for end-to-end security Various mechanisms under consideration for extending WTLS protocol endpoint beyond WAP Gateway Introduction of application level mechanisms for encryption and signing, which will be interoperable between WAP and the Internet world

Current Work Items: 

Current Work Items Integrating Smart Cards for security functions Wireless Identity Module specification will integrate Smart Cards into the security framework of WAP Uses Smart Card for storage of security parameters, as well as performing security functions

Current Work Items: 

Current Work Items Providing a scalable framework for Client Identification Public Key Infrastructure for provisioning and management of certificates Simpler mechanisms for clients that do not support certificates

Services and Protocols: 

Services and Protocols Provide reliable data transfer based on request/reply paradigm No explicit connection setup or tear down Data carried in first packet of protocol exchange Seeks to reduce 3-way handshake on initial request Supports port number addressing Message oriented (not stream) Supports an Abort function for outstanding requests Supports concatenation of PDUs User acknowledgement or Stack acknowledgement option acks may be forced from the WTP user (upper layer) default is stack ack

Classes of Operation: 

Classes of Operation WTP Classes of Service Class 0 Unconfirmed Invoke message with no Result message a datagram that can be sent within the context of an existing WSP (Session) connection Class 1 Confirmed Invoke message with no Result message used for data push, where no response from the destination is expected Class 2 Confirmed Invoke message with one confirmed Result message a single request produces a single reply

WTP Ongoing Work Items: 

WTP Ongoing Work Items Define a connection oriented protocol (IETF) Bearer selection/switching Management entity definition (functions and interface) Protocol verification (reference implementation) Quality of service definitions

Wireless Datagram Protocol: 

Wireless Datagram Protocol Purpose: Provide consistent interface to a fundamental transport service across all wireless bearer networks. Provides a connectionless, unreliable datagram service. WDP is adapted to each particular wireless network to provide the generic datagram transport. The basic datagram service is fundamental to all wireless networks and makes it possible to utilize WAP everywhere.

WDP Continued: 

WDP Continued Supports port number addressing WDP was initially specified for the following networks IS-136 (GUTS, R-Data, CSD, Packet Data) GSM (SMS, USSD, GPRS, CSD) CDPD iDEN Flex and ReFLEX WPG has since promoted specs for the following networks PHS PDC CDMA Example: WDP is UDP when used over an IP network layer.

Slide94: 

Wireless Interoperability Group

WIG Mission statement : 

WIG Mission statement “To ensure that WAP products are conformant to WAP specs and interwork with each other.”

WIG Scope: 

WIG Scope Create test documentation for static conformance dynamic conformance interoperability Define product certification process labeling testhouse - type of process

WIG Status: 

WIG Status Static conformance Static Conformance Clauses, defines check lists for a particular device class Dynamic conformance testing Short term Test suites for interoperability testing Long term Test suites and tools for conformance testing Test house-like process

WDP Tunnel Specification: 

SMS Expert Group WDP Tunnel Specification

WDP TUNNEL SpecificationWAP context: 

WDP TUNNEL Specification WAP context

WDP TUNNEL SpecificationScope: 

WDP TUNNEL Specification Scope To provide a flexible, high performing platform and network independent solution for the provision of non-IP mobile network oriented WDP transport services between WAP proxy/servers and Wireless Gateways (such as SMS-centers).

WDP TUNNEL specificationJustification: 

No single industry standard for (short) message entry; Existing protocols are application oriented and geared towards message centre functionality's; Bearer interfaces of WAP proxy/server not clear; Difficult productizing and certification process for proxy/servers; Increased cost of ownership; Proxy/server market fragmentation Vendor-neutral industry standard for WAP related message centre access; Support WAP where no (end-to-end) IP bearer available Optimised protocol for WAP datagrams; Clear Proxy/Server Bearer interface; Facilitates productizing and certification of proxy/server solutions; Reduced cost of ownership Open proxy/server market WDP TUNNEL specification Justification Current situation Desired situation

WDP TUNNEL SpecificationHigh level Requirements: 

WDP TUNNEL Specification High level Requirements Support WAP where no (end-to-end) IP bearer available Targeting all types of WAP-supporting mobile networks Open for future developments by evolution Ready for use in high performance and high throughput environments Rapid time to market - on track to complete Spec this week Interoperability Platform independence

WDP TUNNEL SpecificationRoad Map: 

WDP TUNNEL Specification Road Map Input Papers for Kyoto WAP Forum meeting  Objectives for Kyoto work: Agree on scope  Agree on requirements  Define outline specification  Draft Specification January 99  (working document) Proposed Specification February 99 - on track Ft. Worth Approved Specification May 99

WDP TUNNEL SpecificationCommitment From Major Industry Players: 

WDP TUNNEL Specification Commitment From Major Industry Players CMG, Comverse, Logica-Aldiscon, Nokia, SEMA Group Telecoms Operators, third party vendors, Paging networks, infrastructure suppliers Cross standard development Workshop 3 February Fort Worth

Slide105: 

Thank You !

Slide106: 

Discussion and Q&A Cindy Dahm cindy@corp.phone.com Natasha Flaherty natasha@corp.phone.com