OSGi World Congress 2005

2. Issues in Designing
Push Based Mobile
Application Platform
Rafiul Ahad

3. AgendaAgenda
•• Mobile Application ModelsMobile Application Models
•• Why PushWhy Push--Based Mobile ApplicationsBased Mobile Applications
•• Push Design ChoicesPush Design Choices
•• Push Design IssuesPush Design Issues
•• An Example ImplementationAn Example Implementation
•• Implementing Push on an OSGI PlatformImplementing Push on an OSGI Platform
•• Concluding RemarksConcluding Remarks

4. Mobile Application ModelsMobile Application Models
•• Three Models of Mobile ApplicationsThree Models of Mobile Applications
–– Online/Pull ModelOnline/Pull Model
•• Information accessed from the server when neededInformation accessed from the server when needed
–– Offline/Sync ModelOffline/Sync Model
•• Information accessed from a local database which isInformation accessed from a local database which is
synchronized with the server content using conventionalsynchronized with the server content using conventional
synchronization techniquessynchronization techniques
–– Push/Online Sync ModelPush/Online Sync Model
•• Information accessed from cache on the deviceInformation accessed from cache on the device
–– Server pushes new and changed data to the cacheServer pushes new and changed data to the cache
–– Client tries to maintain a session and sends new and changed datClient tries to maintain a session and sends new and changed dataa
to server when session is available (online sync)to server when session is available (online sync)
–– Cache permits Offline use when disconnectedCache permits Offline use when disconnected
–– Dirty data in the cache is synched when connection availableDirty data in the cache is synched when connection available

5. Why PushWhy Push--Based Mobile ApplicationsBased Mobile Applications
(Higher ARPU for Operators)(Higher ARPU for Operators)
•• Push based mobile email has the highest rate ofPush based mobile email has the highest rate of
adoption in enterprise (Frost & Sullivan,2005)adoption in enterprise (Frost & Sullivan,2005)
•• Enterprises are beginning to see positive ROI forEnterprises are beginning to see positive ROI for
mobile applications and are willing to invest moremobile applications and are willing to invest more
–– Spending will triple by 2009 (Strategy Analytics, 2004)Spending will triple by 2009 (Strategy Analytics, 2004)
•• Mobile enterprise applications bring higher ARPUMobile enterprise applications bring higher ARPU
for operators and wireless service providersfor operators and wireless service providers
–– NextelNextel
–– Blackberry emailBlackberry email
•• Beware of the challengesBeware of the challenges
–– Usability, security, costUsability, security, cost

6. Why PushWhy Push--Based Mobile ApplicationsBased Mobile Applications
(Solves Usability Issues)(Solves Usability Issues)
•• Usability Issues with Online and Offline ModelsUsability Issues with Online and Offline Models
–– Online/Pull ModelOnline/Pull Model
•• Having to constantly check for new information and thenHaving to constantly check for new information and then
•• Having to wait for it due to long wireless network latency andHaving to wait for it due to long wireless network latency and
•• Not being able to use it due to lack of coverageNot being able to use it due to lack of coverage
–– Offline/Sync ModelOffline/Sync Model
•• Information not up to date andInformation not up to date and
•• High overhead of conventional sync prohibits frequent syncHigh overhead of conventional sync prohibits frequent sync
•• Push/Online Sync Model Solves the Usability IssuesPush/Online Sync Model Solves the Usability Issues
–– No need to poll for information or wait for resultsNo need to poll for information or wait for results
–– Latest information as long as connection to server is availableLatest information as long as connection to server is available
–– Application still works even if connection to server not availabApplication still works even if connection to server not availablele

7. Push Design ChoicesPush Design Choices
•• Periodic Poll with Offline ApplicationPeriodic Poll with Offline Application
–– High overhead (connect, login, sync, logout)High overhead (connect, login, sync, logout)
–– May be acceptable for some usersMay be acceptable for some users
–– Simple to implement if you already have the offline appSimple to implement if you already have the offline app
•• Notify and Online SyncNotify and Online Sync
–– If client has data to sendIf client has data to send
•• If a session exists then client sends the data to the serverIf a session exists then client sends the data to the server
•• Else client flags the data as dirty in the cacheElse client flags the data as dirty in the cache
–– If server has data to send it notifies the clientIf server has data to send it notifies the client
•• If a session exists then client retrieves the data from the servIf a session exists then client retrieves the data from the serverer
•• Else client establishes a new session and sync the cacheElse client establishes a new session and sync the cache
•• True PushTrue Push
–– If server has data to send, it sends the data to the clientIf server has data to send, it sends the data to the client
–– Optionally, if client has data to send, it sends it to the serveOptionally, if client has data to send, it sends it to the serverr

8. Implementation Choices (Contd.)Implementation Choices (Contd.)
•• Notification Protocol ChoicesNotification Protocol Choices
–– OMA EMN, OMA DSOMA EMN, OMA DS SyncMLSyncML Server Alerted Notification (SAN),Server Alerted Notification (SAN),
IETF SIP Notification, IMAP IDLE, PIETF SIP Notification, IMAP IDLE, P--IMAP S2C Notification,IMAP S2C Notification,
Lemonade S2S, SNAP: Smart Notification and Alarm Protocol,Lemonade S2S, SNAP: Smart Notification and Alarm Protocol,
Web Service Notification (WSN), HTTP Asynchronous ClientWeb Service Notification (WSN), HTTP Asynchronous Client
Notifications, UDP or TCP/IP Notifications,Notifications, UDP or TCP/IP Notifications, MoMMoM andand
Asynchronous Queues, Programmatic notifications, WAP PushAsynchronous Queues, Programmatic notifications, WAP Push
•• Wireless Bearer ChoicesWireless Bearer Choices
–– SMS, GPRS,SMS, GPRS, WiFiWiFi, and others, and others
•• Device Management ChoicesDevice Management Choices
–– OTA, via desktopOTA, via desktop
•• SecuritySecurity
–– Device securityDevice security
–– Communication security may depend on protocol choiceCommunication security may depend on protocol choice
–– Preventing malicious usePreventing malicious use

9. Push Design IssuesPush Design Issues
•• Session EstablishmentSession Establishment
–– SMS and UDP/IP do not need session, BUTSMS and UDP/IP do not need session, BUT
•• Most Access Point will not permit serverMost Access Point will not permit server--originate UDPoriginate UDP
•• ClientClient--originate UDP has short time out and differ amongoriginate UDP has short time out and differ among
operatorsoperators
–– Need to keep alive via heart beatNeed to keep alive via heart beat
–– Power consumption higher for transmit compared to receivePower consumption higher for transmit compared to receive
–– Assume that wireless transport session is unreliableAssume that wireless transport session is unreliable
•• Power consumption high for TCP/IP session establishmentPower consumption high for TCP/IP session establishment
–– Decouple application session from transport sessionDecouple application session from transport session
•• LongLong--live application (logical) session neededlive application (logical) session needed
•• Resume based on some device IDResume based on some device ID

10. Push Design Issues (Contd.)Push Design Issues (Contd.)
•• Battery LifeBattery Life
–– SMS based push has the best battery life, BUTSMS based push has the best battery life, BUT
•• It could be expensiveIt could be expensive
•• Will not work forWill not work for WiWi--FiFi or Wired networkor Wired network
–– IP Push requires client to listen on a port continuouslyIP Push requires client to listen on a port continuously
•• Continuous listening consumes battery powerContinuous listening consumes battery power
•• Client or server has to send heartbeat to overcome time outClient or server has to send heartbeat to overcome time out
•• Client sending heartbeat seems to consume more powerClient sending heartbeat seems to consume more power
•• Frequent attempts to establish connection can drain powerFrequent attempts to establish connection can drain power
–– Use some back off algorithm to try to reconnectUse some back off algorithm to try to reconnect

11. Push Design Issues (Contd.)Push Design Issues (Contd.)
•• SecuritySecurity
–– Server must have a certificateServer must have a certificate
–– Client must have a root certificate of serverClient must have a root certificate of server’’s CAs CA
–– TLS (or SSL) over TCP/IP must be used at a minimum toTLS (or SSL) over TCP/IP must be used at a minimum to
•• Authenticate the server andAuthenticate the server and
•• securely provision security parameters such as encryption key, tsecurely provision security parameters such as encryption key, token,etc.oken,etc.
–– SMS message must be encrypted using provisioned keysSMS message must be encrypted using provisioned keys
–– UDP channel must be securely established using token andUDP channel must be securely established using token and
encryptionencryption
–– Cache on device must be encryptedCache on device must be encrypted

12. Push Design Issues (Contd.)Push Design Issues (Contd.)
•• CostCost
–– Both SMS and GPRS could be expensiveBoth SMS and GPRS could be expensive
•• Unless the operator provides the push based serviceUnless the operator provides the push based service
–– Should support multiple bearersShould support multiple bearers
•• Choose the lowest cost bearers among those availableChoose the lowest cost bearers among those available
–– Wired via cradle or USB when in office or homeWired via cradle or USB when in office or home
–– WiWi--FiFi when availablewhen available
–– GPRS as the last resortGPRS as the last resort

13. Sample ImplementationSample Implementation
Local Cache Notifies
changes to push/sync agent
and applications
Push/Sync Agent sends and
receives changes if network
is up (Online for fast prop-
agation of client changes)
Store changes when network
is down and sync when it
comes up (Offline for
continuous availability)
Server pushes relevant
changes to agent (fast prop-
agation of server changes)
Receives and update
changes from agent
Manage software and device
configuration
Server 1
App 1 App n
Push/Sync
Agent 1
Push/Sync
Agent 1
Server 1
Local
Cache
API 1 API n
Transport
API 1
Transport
API n
Protocol 1 Protocol n
OnDevice
Oracle Collaboration Suite 10g
Push Mail Solution Architecture

14. Sample ImplementationSample Implementation
Inbox
Application
Command
Processor
OCS Push
Email Server
P-IMAP
IMAP
OCS
Mail Server
MAPI
Message
Store
Ops
OCS Push
Windows Mobile®
Email Client
Notification
Processor
SMS or
encrypted
UDP/IP
Events
Ops
Ops
Server
Message
Store
P-IMAP
Transport
Notification
Command
Processing
Service
Notification
Collection
Service
Network
Monitor
Notification
Delivery
Service
Device
Management
Service
Oracle Collaboration Suite 10g Push Mail Solution
Implementation for Windows Mobile Client

15. Implementing Push on OSGI PlatformImplementing Push on OSGI Platform
•• Persistence store API with callback on eventsPersistence store API with callback on events
–– Application and the Push/Sync agent can be notified of changesApplication and the Push/Sync agent can be notified of changes
made by each othermade by each other
•• Connection Manager API with callback on eventsConnection Manager API with callback on events
–– Push/Sync agent can be notified of connection availabilityPush/Sync agent can be notified of connection availability
–– Hierarchy of connections with different cost and batteryHierarchy of connections with different cost and battery
consumption characteristicsconsumption characteristics
•• SMS notification handler APISMS notification handler API
–– Needed as a last resort to notify the client to syncNeeded as a last resort to notify the client to sync
•• Device Management APIDevice Management API
–– Needed to install/upgrade/remove apps and agentsNeeded to install/upgrade/remove apps and agents

16. Concluding RemarksConcluding Remarks
•• Push/ Online Sync is the most usable modelPush/ Online Sync is the most usable model
–– Already proven in enterprise email applicationAlready proven in enterprise email application
•• Enterprises seeing positive ROI for mobile appsEnterprises seeing positive ROI for mobile apps
–– Spending more on mobile applicationsSpending more on mobile applications
•• Usability, security, and cost of solution are issuesUsability, security, and cost of solution are issues
–– Push based solution addresses usabilityPush based solution addresses usability
–– Short battery life could become an issueShort battery life could become an issue
•• Operators can benefit from mobile enterprise appsOperators can benefit from mobile enterprise apps
–– Must invest in pushMust invest in push--based mobile solutions nowbased mobile solutions now