The Push Service introduces a means to transmit push data from a push initiator to a push recipient (e.g. a UE) without a previous user action. The push concept, as provided by the SMS teleservice, has been very successful in the GSM second generation, both for text messaging (for user viewing) and for other unstandardized data to the SIM (as a building block used for OTA and other purposes). This TS introduces the Push Service as a generalization of existing network capabilities plus the development of new capabilities. The Push Service should therefore be understood as a building block (network capability), which can be used for new services, both public and private, in 3GPP. In the normal client/server model, a client requests a service or information from a server, which then responds in transmitting information to the client. This is known as the "pull" technology, the user pulls information from the content provider. The World Wide Web is a typical example of pull technology, where a user enters a URL (the request) that is sent to a server and the server answers by sending a Web page (the response) to the user. In contrast to this there is also the "push" technology where there is no explicit request from the user before the content provider (push initiator) initiates an information transfer to a user. Another way of saying this is that whereas "pull" transaction of information are always initiated from the user, "push" transactions are content provider initiated. The welcome message received after registration with a visited network whilst roaming is an example of information transfer that has been initiated without a request from the user. Typically, a user signs up with the push initiator and defines their interest, volume of information acceptable and other factors in the push subscription profile. As information becomes available that satisfies the user's push subscription profile, the push initiator delivers it to the user using the Push Service. The Push service may be used to implement high level services such as IP multimedia services, MMS, etc., and new services including public safety, government, corporate IT, transfer of push data to machines and devices, in addition to infotainment type services. Another common use for push services is the delivery of notification from e.g. MMS to the user while the user has the option of "pulling" the actual push data from the push initiator. The PLMN Push function provides the push data to the user agent in the UE. The user agent interprets and presents the push data to a person, device or machine using the UE.

This Technical Specification defines the Stage 1 description of the Push Service and is the set of requirements that shall be supported for the provision of push, seen primarily from the subscriber's, service providers' and delivery network points of view. This TS includes information applicable to network operators, service providers, terminal and network manufacturers. It is of use to manufacturers and organisations which have devices or machines benefiting by availability of push service. This TS contains the core requirements for the Push Service, for operator and external Push Initiators, which are sufficient to provide a complete service capability and service capability feature. This TS defines the requirements for the Push Service to enable delivery of push data, including such functionality as:

• Transfer of push data from a Push Initiator to a Push Recipient
• Latency and Priority classes,
• Definition of handling of undeliverable push data.

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.

• References are either specific (identified by date of publication, edition number, version number, etc.) or non specific.
• For a specific reference, subsequent revisions do not apply.
• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.

Definitions and abbreviations used in the present document are listed in TR 21.905. For the purposes of this document the following definitions and abbreviations apply:

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

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.

The following list gives the high level requirements for the Push service.

The "Security Threats and Requirements" specified in TS 21.133 shall not be compromised. It shall be possible for the Push Service Operator to be assured of the identity of the Push Initiator. It shall be possible for the Push Recipient to be assured of the identity of the Push Initiator. Mechanisms shall be provided to ensure that the push data is sent to and accessed only by the intended addressed entity. It shall be possible for the Push Service or the user to deny unauthorized push data. An authorization may be based on the following:

• identity of the Push Initiator
• the destination user, device or user agent
• push related attributes such as priority and content type

It shall be possible for the user to control acceptance of push data sent to the user based on the trust level of the Push Initiator. The Push Service shall provide data integrity and data confidentiality of the push data. Push Initiators must have authorization (e.g. service level agreement) with the Push Service Operator (e.g. PLMN Operators) in order to use the Push Service.

The Push Service shall ensure compliance with the Push Recipient's privacy requirements as described below. Specific local, national, and regional privacy regulations shall be complied with. An operator shall, at any time, be able to override a Push Recipient's privacy preferences if required to do so by legal authorities. 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 Recipient shall be able to define access rules, in order to control how her privacy requirements shall be handled by the Push function. It shall be possible for the Push Recipient to define the following access rules:

• The Push Recipient shall be able to allow push data from individual push initiators or groups of Push Initiators to transmit push data to the Push recipient
• It shall be possible for the Push Recipient to uniquely identify a Push initiator and the addressed User Agent prior to accepting or declining a request to receive push data from that Push Initiator.
• The Push Recipient shall be able to automatically decline push data from individual push initiators or groups of Push Initiators to transmit push data to the Push recipient
• At any time it shall be possible for the Push Recipient to stop receipt of push data from a Push Initiator. This may include any push data from this Push Initiator or only push data addressed to a particular User Agent of the Push Recipient.
• The Push Recipient shall be able to allow individual push initiators or groups of Push Initiators to transmit push data without user interaction at the Push Recipient's side.

It shall be possible for the Push Recipient to define these access rules based on:

• The identity of the Push Initiator
• The addressed User Agent

In addition it shall be possible for the Push Recipient to specify the validity of these access rules

• Only for the next request of the Push Initiator or
• For a pre-defined period e.g. next hour
• Unlimited, i.e. till modification or removal of the access rule.

This paragraph specifies charging requirements for the Push service. The Push service shall support various charging mechanisms (e.g. reverse, prepaid and reply charging etc.). The following charging scenarios shall be supported:

1. Charging for the push service can be subscription based.
   Different charging options shall be permissible whether the user is provisioned with the Push Service as a Push initiator or as a Push recipient.
2. Charging for the push service can be based on the push data, the resources used and time needed to carry out the push service.
3. Charging for the push service can be based on the size of the push data pushed to a receiver.
4. It shall be possible to charge the Push recipient only, the Push Initiator only, or both.
5. It shall also be possible to mix and match the various different charging scenarios outlined above.
6. It shall be possible to charge for the initial push service activation.
7. It shall be possible to charge a Push initiator for an attempt to send push data to a push recipient, even if the push recipient rejects the push data

It shall be possible to include the following data in the CDRs as charging information if available:

• message types, length, storage time in the network, etc
• delivery time, upload / download method,
• Push service sender / -recipient
• the amount of the push data sent
• the amount of the push data received.
• roaming conditions (e.g. in a visited network)
• location conditions

For each Push recipient the Push Service shall keep a Push subscription profile. This Push subscription profile shall contain the Push recipient's access rules. Optionally (as an operator's option) the Push subscription profile may contain additional Push personalization settings of the Push recipient, e.g.

• Permissible minimal QoS per data format for receiving push data
• Permissible maximum size of data packages permitted to be pushed
• Permissible charging thresholds to receive push data
• …

At any time, the Push Service shall permit a Push recipient to modify her Push subscription profile information. A Push initiator shall be able to interrogate any Push Recipient's Push subscription profile information. However only information relevant to this Push Initiator shall be revealed by the Push Service

Push services shall be available when roaming. The push recipients shall be able to select and receive pushed local services, subject to the user profile settings.

It shall be possible to provide the Push Service to a user regardless of barring status of other services, providing that a bearer to deliver the Push Content is available. It shall be possible for user to bar the Push Service regardless of barring status of other services.