1December 16, 2009

BlackBerry Push Service

Overview – March 2010

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

Doesn’t 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 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)

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?

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!

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.

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.

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.

Effects / Experience

→ 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.

→ 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.

→ 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

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

→ Pushes are initiated on the Server Utilizes Research In Motions push

infrastructure

→ 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

→ Push Service Essentials has been optimized for broadcasting less critical information (if the end user does not receive the message, it doesn’t 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

Push Service Plus Push Service Essentials

8kB Content Yes Yes

Single Port Yes Yes

Multiple Casting Methods

Yes Yes

Status Query Yes No

Quality of Service Yes No

Configurable Return URL

Yes No

Controllable Expiry Time

Yes – up to 8 hours Yes – up to 30 days

Pricing

Free1 (1 – if 100,000 or less pushes per day)

Tiered Pricing2 (2 – if above 100,000 pushes per day;

negotiated at time of registration)

Free (at all levels)

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

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

3. Content Provider develops & tests A separate “eval” infrastructure is provided by

RIM

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

Deregistration Disables the device from receiving pushes Push initiators must be sure to deregister if the application is no

longer being used

→ We accept multiple push requests for a device - but we don’t 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 provider’s 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!

→ Quality of Service / Acknowledgements to push initiator 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)

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 un-encryption in the application), if the content submitted is sensitive

Users should be authenticated to the Push Initiator’s server application as part of the registration process

Each push request is authenticated to push Infrastructure

Spam Prevention 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

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)

Test 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

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.aspx

"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