P USH M ESSAGING

Introduction Traditional – pull, request-response models Push model – info is sent to a client without the need for any previous user request Two de facto push services: Eg. Paging – mobile client (the pager) waits to receive a push (page) Eg. SMS – similar to paging, but two-way messaging service- ‘coz message can also be initiated from the mobile client Eg. News headlines, stock price alerts, voice mail notifications WAP push – advances these messaging models by integrating them into the WAP application environment on the mobile device and by making them accessible thro’ std internet protocols

Overview First version of WAP specification included push only in terms of WSP primitive, no end-to-end features to actually enable push services WAP forum chartered a push drafting committee in July 1998 and they gave a suite of seven specifications in August 1999, formally adopted in December 1999 WAP Push – Goals Std Internet protocols and content types are cornerstones of WAP push The complexity of underlying mobile networks is completely hidden from the services utilizing WAP Push A simple, transport-independent protocol is required between the Web service and the WAP Push service connected to the mobile network Others – mobile and internet network efficiency, maintaining user control and ensuring simplicity of implementation

WAP Push Framework Has 3 elements Push Initiator(PI) – creates the message to be pushed Push Proxy Gateway – PI to interact with the wireless world WAP client – receives the message

WAP Push Protocols 2 protocols Push Access Protocol (PAP) Push Over-the-air (OTA) Protocol PI uses PAP to submit push messages, cancel previously submitted msgs, query the msg status and WAP client capabilities PPG uses PAP to respond to requests from PIs. PAP is currently transferred over HTTP1.1 (SMTP is being tried) PPG and WAP client communicate using OTA OTA is a thin layer on top of WSP PI PPG WAP Client PAPOTA

WAP Push specific content types 2 MIME media types for creating services based on WAP Push Service Indication XML doc type Indicates that content is waiting for the WAP client and provides a reference to that content – i.e. a URI Service Loading XML doc type Client will automatically, without end-user involvement downloads and executes the content indicated by the reference URI 3 rd special MIME type – Session Initiation Application To inform the WAP client that WSP session creation is required

P USH A CCESS P ROTOCOL Used by PI and PPG to communicate XML-based protocol independent of underlying transport We have: PAP Message Format Operations provided by PAP PAP binding to HTTP1.1

PAP Message Format PAP submission message uses MIME multipart/related document with a maximum of 3 types of info, each encapsulated in a separate MIME multipart entity Other PAP operations use application/XML without MIME multipart/related structure 3 types of information PPG and PI control information Has the requested PAP operation and its attributes The actual Push message Has headers followed by msg body Msg has its own MIME types (unrestricted on content types) Capabilities and preferences information Info is in RDF format defined for WAP UAProf – has preferred or supported media types of the client, device characteristics such as the screen size, color Used in 2 ways: PI assumes the capabilities and puts it as the 3 rd entity in a Push msg submission request – PPG verifies the device capabilities Can be provided by PPG in response to a client capability query from PI, here it is 2 nd entity in a PAP message

PAP operations 5 basic operations Push Submission, and its response Push Cacellation, and its response Push Status Query, and its response Client Capability Query, and its response Result Notification, and its response Push Submission and Result Notification alone have to be supported by PPG implementations PAP operations based on request-response model Push Submission Describes the push message submitted to a PPG for delivery Unique msg id assigned by PI Has info about Delivery parameters – msg to be sent before or after a particular time, if delivery report requested Device address to which the msg to be sent (present in the second entity of the PAP message) Info to identify the originator of the msg QOS parameters defining the priority of the msg and delivery method, desired bearer-type (opt), if PPG unable to satisfy the QOS, it rejects the push msg

Push Submission Response PPG generates a response with the msg id info about the PPG a timestamp to indicate when this response was created Also, status code for the initial msg submission and a PPG implementation specific progress info, if requested by PI Push Cancellation Cancels msgs based on msg IDs Optional – to define recipient addr ( if only for a particular recipient, the msg is to be cancelled) Push Cancellation Response PPG sends back a msg with the msg ID of the cancelled msg and its status code representing the outcome of the cancellation request

Push Status Query PI can query the status of previously submitted msgs using their msg IDs, can narrow down to certain recipient addresses also Push Status Query Response Includes msg ID, possible recipient addr to which this status applies, status code Additionally, can include QOS info describing the delivery methods used, if requested by PI Client Capability Query To obtain info about the WAP client before submitting the msg Assigns an ID to the query, provides both the address of the client and an id for the application in the WAP client about which it is requesting info Client Capability Query Response PPG uses these IDs and selects a suitable set of capabilities and sends back PI can use this msg to tailor the Push Message to be appropriate for the WAP client

Result Notification Sent by PPG to PI All msgs submitted to PPG receives a push submission response when they are accepted for processing If PI wants to know the final status of the msg (i.e whether the msg was delivered, cancelled, or expired or an error occurred), then a request is mentioned in the Push Submission Request Result Notification Response Acknowledges the receipt of the Result Notification. Sent from PI to PPG PAP over HTTP1.1 PAP requests are sent as HTTP POST requests, and PAP responses as HTTP reply PPG has to control which PIs can access it using PAP for security issues in the internet world – SSL, X.509 client certificates can be used

MIME media types for Push Messages Service Indication(SI) Signals the user that an event has occurred Provides info about the event as a small msg describing the event and the URI reference to related service Eg. Voic , or news service notifications Registered MIME types: Application/vnd.wap.sic : a SI in WBXML format Text/vnd.wap.si : SI in text format Contd. In next slide Service Indication Usage Can be optimized by binary encoding using WBXML Before deploying SI in a service, find the different implementations of user-intrusiveness level Depends on handset vendors also

SI additional features Control of user-intrusiveness level -3 specified Signal-low : SI should be automatically postponed for later handling without inquiring the user Signal-medium : SI to be presented in an non-intrusive way to the user Signal-high : SI should be presented as soon as possible Replacement SIs assigned IDs which are later used to detect if same kind of info is coming again The ID is used along with date and time, to allow new msgs to replace old ones Eg. SI 1 could have said – 2 voice mail items received, but now can be replaced to 4 voice mail items received indication Expiration Based on date and time present in the SI – marked as expired or deleted Delete When a SI becomes invalid, it can be deleted by sending a new SI with the delete command and the original msg id Eg. If user checks her voic from some other phone than her WAP client, then the now invalid voice mail SI can be deleted from her WAP client Out-of-order handling Handled based on date and time A SI is silently discarded if it is older than the already received SI carrying an identical ID