The UP.Link platform supports several wireless network types, each of which operate differently. In particular, packet-switched networks treat all data transmissions the same, regardless of their size. Circuit-switched networks, on the other hand, use a special method (SMS) to deliver very short asynchronous transmissions and require the user to explicitly authorize larger data transmissions1. This prevents the UP.Link server from asynchronously pushing large messages to UP.Phones on circuit-switched networks.
To support notifications consistently across different network types, the UP.Link platform provides two logical delivery channels for notifications:
On a packet-switched network, the UP.Link server attempts to deliver pull notifications as quickly as possible (with only the UP.Phone's availability, the network transport layer, and Web server latency impeding delivery time). On a circuit-switched network, the UP.Link server never initiates contact with a UP.Phone to deliver a pull channel notification. The UP.Phone must open a circuit and initiate contact with the UP.Link server before the UP.Link server delivers the notification.
The following sections describes in more detail how the UP.Link server handles push and pull channel notifications.
Figure 5-3 illustrates a simple push notification transaction. The steps in the transaction are described below.
FIGURE 5-3. Push channel notification
The notification specifies the subscriber ID of the UP.Phone the notification is directed to and a TTL, specifying how long the UP.Link server should attempt to deliver the notification.
If the notification contains a cache operation, the UP.Phone removes the specified URL(s) from its cache.
If the notification contains an alert, the UP.Phone signals the user that an alert has arrived and adds the alert to its Inbox card (see Figure 5-2); the following additional steps occur:
Note that the component of the HDML service that initiates the notification (the notifier) and the component that provides the URL specified by the Alert do not have to be integrated. In fact, they can be on different systems.
As mentioned above, the way an UP.Link server delivers a pull notification depends on the type of wireless network the subscriber is on. The figures in this section depict how the UP.Link server delivers notifications over circuit-switched and packet-switched networks.
Figure 5-4 illustrates a typical pull notification delivered over a circuit-switched network. The steps are described below.
FIGURE 5-4. Pull notification over a circuit-switched network
The notification specifies the following: the subscriber ID of the UP.Phone the notification is directed to; a time-to-live (TTL), specifying how long the UP.Link server should attempt to deliver the notification; and a URL that supplies the notification data.
Figure 5-5 illustrates a typical pull notification delivered over a packet-switched network. The steps are described below.
FIGURE 5-5. Pull notification over a packet-switched network
When you send a notification, the UP.Link server adds to its notification queue. How long the notification remains in the queue depends on the following:
A notification that is in the queue but has not been delivered is called a pending notification. A service can delete, or request status for, any pending notification that it has originated. It can also request status for completed notifications.
The UP.Link server and the UP.Phone identify notifications by their URLs and subscriber IDs. When the UP.Link server receives a new notification with a URL and a subscriber ID that matches those of a pending notification, it replaces the pending notification with the new notification. This process is known as coalescing. It allows HDML services to update out-of-date notifications before they are sent to a user's UP.Phone. The UP.Phone also coalesces the notifications that it receives from the UP.Link server.
