4 Overview of the Push Service

22.1743GPPPush ServiceRelease 17Service aspectsStage 1TS

The overview of push is followed by a summary of the relationships among the entities involved (operators, users, push recipients and push initiators).

NOTE: these are functional descriptions: multiple functions may, depending on business arrangements, be performed by a single entity.

Figure 1: Push Service Overview

The Push Service is a service whereby the Push Initiator sends push data through a Push Server to a Push Recipient, without interaction from the Push Recipient.

The typical mode of operation is as follows:

• A Push Recipient (e.g. user, receiving device like a meter) explicitly or implicitly subscribes to a set of value added services offered by various Push Initiators and allow these Push Initiators to send it push data that meet the Push Recipient’s configured criteria. (This configured criteria is part of the Push user profile.)
• A Push Initiator identifies information matching the criteria set by the Push Initiator and package it up into the push data
• The Push Initiator delivers the push data to the Push function, identifying the Recipient’s address, and optionally priority, delivery time parameters, etc.
• The Push function takes the responsibility of delivering the push data, optionally following the priority and delivery time parameters, to the Push Recipient and for providing feedback to the Push Initiator regarding delivery of the push data if requested by the Push Initiator.

Key characteristics of the Push Service include:

• The Push Initiator may, but is not required to deal with the specifics of the wireless transport, selection of appropriate bearers, out-of-coverage or roaming issues, and other wireless network anomalies. These are all managed by the Push Service and hence can be optimised at the network level rather than being handled by all applications. Using an available bearer the push service offers as many capabilities that are available to delivery of the push data following the requested push services requested by the push initiator.
• The push initiator shall be provided with a means to query the push server for a specific recipient’s push user profile subject to privacy considerations.
• The push server shall not change the push data (contents). Any transformations that the Push Server provides shall be compliant with user privacy requirements as defined in the push subscriber profile.
• The push service shall be able to handle user groups (i.e. have the ability to target a certain group of push recipients).
• The push service is capable of supporting asynchronous communication between a Push Initiator and the push recipient on a wireless device.
• The privacy of the user is important and the introduction of the push services should in no way result in unwanted information "spam" being sent to mobile users.

The Push data could contain:

• Application specific data exchanged between a server and its client e.g. ERP, CRM, Field Service management, m-commerce transaction data or a meter reading
• Provisioning or configuration control data

The entities shown in Figure 1 are Push Initiator, Push Server (PLMN) and the Push Recipient. The Push Initiator may be outside the Operators network and hence will require well-defined relationships amongst them.

For example, a Push Initiator can be within the Operator domain (e.g. an operator portal) or an external VASP. A Push Recipient (e.g. a User) will need to be part of the Operators network and will require allowing the network to pass through push data and also subscribing to the Push Initiator to generate the data it wants pushed. To support flexible billing models, it becomes necessary for the Operator to have a defined commercial relationship with the Push Initiator.