BlackBerry Push Service

Overview March 2010

December 16, 20091

Taking a step back: Differentiating mobile information transmission methods

Polling
A technique where a client periodically asks a server whether an event of interest has occurred Inefficient increases OTA costs and traffic
there may be many polling attempts to fetch a single event

Delays in getting data due to polling latency (interval) Depending on polling interval, received data may be outdated Wastes battery life checking whether an event of interest has occurred Generates extra server traffic and load for your application
1,000,000 devices x 12 polls/hr x 24 hours = 288,000,000 requests per day Doesnt scale

Alert
A notification to the device to wake up an application to do something Like Push, but no content, or content limited to a application activity code

Taking a step back: Differentiating mobile information transmission methods (continued)

Poke-Pull
A technique where a notification and URL are pushed to a device (poke) and the and device fetches the content at the URL (pull) Less efficient than true push Push allows the delivery of content to a device without the device having to request it The data is sent asynchronously to a port on the device where an application is listening for it Push is generally server based/mediated (server typically is the Push Initiator) The Push Initiator submits a request to the Hosted Data Push Service which contains delivery instructions and the payload
The delivery instructions describe where the data is to be sent and how The payload may be any data-type (images, text, audio, video, other formats)

Push

The Push Paradigm

The data is on the device when the user needs it

The data is delivered as soon as it is available (an event of interest occurred)

Application is always actively listening for data arrival (event) The user is alerted (play tune, vibrate, blink, pop-up, icon overlay) when all the data has been delivered, processed, and ready to view, appearance of zero latency

The user experience is that it just happened, automatically and reliably

Why use Push?

Polling

Alerts

Poke & Pull

Description

Application will use resources on the device to open connectivity to a server at regular intervals, whether new information is actually available or not. Needs to occur in very tight intervals to mimic a push experience. Constant connections opening / closing on the device increase drain on battery. Most connections are opened / closed unnecessarily, as there is no new information available. Albeit minimal, customer data plans area effected by empty polling requests.

A very small piece of information is sent to the device, that provides the customer with a notification that something new is available for the respective service. While initial alert is very adequate, customers have to wait for relevant (richer) information to download in separate, disconnected (and at times lengthy) step. Lack of multiple, unique ports contributes to lost alerts / information, as new alerts overwrite unread old alerts.

A very small piece of information is sent to the device, triggering the respective application to wake up and download the data specified in the initial information. Great way to deal with large files, but inefficient, as device has to work on every content delivery (even for small data packets). If used at all times, this will lead to similar effects as Polling

Effects / Experience

The BlackBerry Push Service represents a most efficient way to quench customer information needs! saves device battery life and customer data budgets! creates more immediate user experiences!

Push Paradigm used at BlackBerry

Mail
The original push infrastructure Enterprise (BlackBerry Enterprise Server) and BIS-E

Enterprise through MDS

Enterprise version of Data Push infrastructure Supports PAP and MDS push interfaces

Web Signals
Push browser icon to home screen (for web sites) Predecessor to Data Push infrastructure

BlackBerry Push Service

Push any data type to a specific, registered java-application or web widget on the device

The BlackBerry Push Service

Provides transport infrastructure for Server to Device pushed data Primary focus on consumer applications
Can be used for cross company applications (Enterprises)

Server to Server interface for the push initiator

Server-side application is required Utilizes Research In Motions push infrastructure

Pushes are initiated on the Server

Sends data to a specified Port on the device

Client side Java application required

Basic Flow
1. Content provider sends a push request 2. BlackBerry service returns a response 3. BlackBerry service pushes data to an assigned, specific port on device(s) 4. Device returns response to BlackBerry service 5. BlackBerry service forwards acknowledgement to content provider 6. Read notification is returned to the BlackBerry service

Who can benefit from the BlackBerry Push Service?

(Consumer) Applications that require:
Alerts Poke-Pull model Event driven systems Near real-time notifications Replace polling to improve performance & reduce costs

Generally, every use case that offers (business critical) information:

Weather: updated forecasts, severe weather warnings News, Sports (scores), Traffic Banking & Stocks Social Networking Gaming

Key Features
Allows up to 8kB payload Dedicated application ports avoid port collisions Uses standard push protocols (WAP PAP 2.2) Supported requests (via HTTPS XML):
Submit Push (to PIN) , Cancel Push Query for Status Query for Device Capabilities

Response:
Result notification

Different submission modes:

Point-to-Point (submit push to single PIN) Multicast (submit push to list of PINs) Broadcast (submit to all PINs for a registered application)

Developer-controlled expiry time (Push system will automatically store push requests until expiry time) Supports delivery notifications Developer-set quality of service:
Application (message reached application ) Transport (message reached port on device) Fire & Forget (no acknowledgements)
Items in red are unique to the BlackBerry Push Service and Platform

Options
BlackBerry Push Service provides options depending on the use-case, target market and intended budget:

Push Service Plus

8kB Content Yes

Push Service Essentials

Yes

Single Port
Multiple Casting Methods Status Query Quality of Service Configurable Return URL Controllable Expiry Time

Yes
Yes Yes Yes Yes Yes up to 8 hours Free1
(1 if 100,000 or less pushes per day)

Yes
Yes No No No Yes up to 30 days Free
(at all levels)

Pricing

Tiered Pricing2
(2 if above 100,000 pushes per day; negotiated at time of registration)

Push Service Essentials has been optimized for broadcasting less critical information (if the end user does not receive the message, it doesnt matter) Push Service Plus represents the current gold standard push service, and provides content providers the ability to know where their critical information is every step of the (push) way

Enablement
1. Content Provider registers in section Pricing & Registration at:
https://www.blackberry.com/developers/pushservice/

2. Content Provider obtains documentation:

Downloads Push Service SDK from website Eval App ID, PW provided by RIM
A separate eval infrastructure is provided by RIM

3. Content Provider develops & tests 4. Content Provider requests production 5. RIM reviews application
Follows Tech Schedule guidelines? Provide Production credentials when accepted

6. Content Provider launches service

Distribution through all applicable distribution models (incl. VPL / App Centre / App Store)

Features In Depth

Application Registration
Pushes can only be submitted to devices, that have registered with the push service
Registration
Enables the device to receive Pushes for a specific application from provider Disables the device from receiving pushes Push initiators must be sure to deregister if the application is no longer being used

Deregistration

We accept multiple push requests for a device - but we dont guarantee order For acceptance, the application must have a mechanism for the user to register / deregister when needed (push on / off switch)

Submit Push
Sent to PIN Up to 8K payload Mode:
Point to Point: Information is sent to single PIN Multicast: Information is sent to a list of PINs Broadcast: Information is sent to all PINs that are registered for a given application

Data Push Service will attempt to deliver the message until expiry time
Device is monitored for returning to coverage Push only occurs if device is actually in coverage

Deliver Before (expiry)

Up to 8 hours (Plus Option) / 30 days (Essentials Option) before the message is timed out

Quality of Service
Push Plus option allows to set delivery notifications :
Notifications are sent to push initiator, via content providers notification URL Typically base URL is used from content providers domain (unless otherwise specified by content provider) Be prepared to receive a response for each message sent! Application-level (Push Plus Option only): Information reached the application acknowledged all the way back to the push initiator Transport-level (Push Plus Option only): Information reached the device acknowledged to push initiator Server-level (Push Plus Option only): Information reached the BlackBerry Push Service servers acknowledged to push initiator Fire & forget: No acknowledgements are provided (at any level)

Quality of Service / Acknowledgements to push initiator

Reliability
Choose the appropriate QoS for your application
There are tradeoffs for performance and battery life

Be sure to handle all request failures in your application

Result notifications
Your server app must be prepared to handle these, if you request them Server outages - RIM infrastructure will retry deliveries for a while

Always provide an unsubscribe option in your device application

Highest reliability can be achieved by application acknowledgement direct to your server

Security and Spam Prevention

Security

BlackBerry Push Service is content agnostic will push any content the push initiator submits in the payload (up to 8kB): we deliver what we get! Content provider is responsible for content encryption (and unencryption in the application), if the content submitted is sensitive Users should be authenticated to the Push Initiators server application as part of the registration process
Each push request is authenticated to push Infrastructure 1:1 relationship between push initiator and application Push initiator can only push to their applications All applications must be registered to the Push Infrastructure Push initiator is authenticated to the Push Infrastructure Unique listening port for each application Push initiator can only push to devices registered for their application

Spam Prevention

Building and Testing Applications

Build
Use BlackBerry Push Service SDK to initiate development
Contains installable client and server applications Addresses some of the issues inherent to a push based architecture (registration, listener, et al.)

Implement credentials obtained by RIM (App ID, PW, device port) Your application must be registered in our infrastructure A separate (shared) eval infrastructure is provided for development and testing Eval system is shared with other content providers testing, has limited capacity Upgrade from eval environment to production environment can occur at any time This service will have limited capacity

Test

Appendix

References and Resources

Push Application Protocol, OMA-WAP-TS-PAP-V2_2-20071002-C.pdf,URL: http://www.openmobilealliance.org/Technical/release_program/push_v2_2.a spx "Uniform Resource Locators (URL)", T. Berners-Lee, et al., URL: http://www.ietf.org/rfc/rfc1738.txt "Wireless Application Group User Agent Profile Specification", Open Mobile Alliance, WAP-248-UAProf. URL: http://www.openmobilealliance.org/ "Resource Description Framework (RDF) Model and Syntax Specification", W3C Recommendation, 22-February-1999. URL: http://www.w3.org/TR/REC-rdf-syntax "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", N. Freed, et al., URL: http://www.ietf.org/rfc/rfc2046.txt