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
 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?
Polling
 Application will use resources on the
device to open connectivity to a server
Description 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.
Effects /
→ Most connections are opened / closed
Experience unnecessarily, as there is no new
information available.
→ Albeit minimal, customer data plans
area effected by empty polling
requests.
Alerts
 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.
Poke & Pull
 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

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
→ 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
BlackBerry Push Service provides options depending on the use-case, target market and intended budget:

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
Free1
( – if 100,000 or less pushes per day)
1

Pricing Free
Tiered Pricing2 (at all levels)
(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
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
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