5 Requirements

22.1743GPPPush ServiceRelease 17Service aspectsStage 1TS

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

5.1 General

The Push Service shall allow a Push Initiator (which may be external to the PLMN) to initiate delivery of push data to the Push recipient. It shall be possible to deliver push data to the push recipient without any user intervention, subject to settings in the push subscription profile. The Push Initiator may interrogate the push subscription profile, if available, in order to establish the user preference related to the Push Service.

  • The push mechanism shall be efficient in the use of network resources and terminal resources.
  • It shall be possible to support Push Service independently over CS (including CS data and SMS), PS domains or IMS.
  • NOTE: Operators should be able to choose which of these options they use to deliver Push services, and it should be possible to use these options independently from each other. E.g. delivery over the PS domain would allow operators who are not planning to introduce IMS and SMS to offer Push Services.
  • It shall be possible to deploy Push Services independently of other services defined by 3GPP.
  • The quality of service delivery shall be able to include time-sensitive as well as reliable delivery choices
  • It shall be possible to use all available access networks (e.g. GERAN, UTRAN,).
  • It shall be possible for the Push Initiator to specify a bearer for the Push Service, as a default the push service shall identify the bearer. The Push Initiator may, however, require certain grade of service for delivery, e.g. speed of delivery or delivery acknowledgement.

5.2 Provisioning

The operator shall be able to provision a user or organisation-user (e.g. a subscriber or a VASP) with the Push Service. The provision may include usage of the Push Service as a Push initiator, as a Push recipient or both.

The provision may be:

‑ general: where the service is made available to all user or organisation-users (subject to compatibility restrictions enforced) without prior arrangements being made with the operator;

‑ pre‑arranged: where the service is made available to an individual user or organisation-user only after the necessary arrangements have been made with the operator.

If the user is provisioned with the Push Service as a Push initiator he may use the Push Service in order to transfer push data to the Push Recipient, subject to settings in the push subscription profile of the Push Recipient.

If the user is provisioned with the Push Service as a Push recipient he may use the Push Service in order to receive push data from a Push initiator.

The push subscription profile parameters (user’s settings and preferences) are managed by the user or the operator on behalf of the user.

The operator shall be able to withdraw the provision of the Push service. Withdrawal may be general or pre-arranged.

NOTE: Provisioning with – or subscription to – value added services, that make use the Push service are out of scope of this specification.

NOTE : the concept of organisation user may apply to GUP and if so will not be duplicated here.

5.3 Subscription

The usage of the Push Service to deliver push data from a Push Initiator to a Push Recipient requires as a precondition either an explicit or implicit subscription to the Push Service

Explicit Push Subscription:

A subscriber subscribes to the Push Service together with the Push service provider, i.e. the home PLMN operator. Home PLMN Push service providers may then use the Push service to deliver content to the subscriber.

Implicit Push Subscription:

A Value added service provider shall be able to subscribe to the Push Service on behalf of a subscriber to a value added service provided by this VASP. From a Push service point of view the subscriber becomes a push recipient. From now on the Value added service provider shall be able to use the Push Service capabilities to deliver content to this particular subscriber, i.e. the push recipient.

The Push service subscription is valid for the subscriber to receive push data from the VASP that has subscribed to the Push service as long as the subscription is valid.

5.4 Addressing and Routing

It shall be possible to uniquely identify push recipients.

It shall be possible for push recipients to uniquely identify push initiators.

The addressing model shall include addresses of the device (e.g. IP address, SIP-URI, MSISDN) and application level addressing (i.e. user agents). The addressing model shall be compatible with Internet specifications when applicable.

It shall be possible to deliver push data to a push recipient with a dynamically allocated IP address.

The Push service shall be able to deliver a push data to a push recipient that does not have an IP address currently assigned.

Both telecom and internet numbering and addressing schemes shall be supported.

It shall be possible to address push recipients without allocating E.164 numbers.

5.5 Delivery

The PLMN may set restrictions including maximum size of Push data.

The Push Service may offer classes of priority and service delivery. When offered this shall include support for the following:

  • Delivery time constraints (timing window, i.e. allow the push initiator to specify "deliver after" and "deliver before" parameters)
  • Requested delivery priority (different priorities dependent on for example push initiator, or allowing the push initiator to specify the desired priority)
  • If neither delivery time nor priority is set then a single attempt shall be made to deliver the push data without unnecessary delay.
  • The push service shall be able to send a delivery report to the push initiator, which includes information about a specific submission’s final outcome (delivered, expired, etc.). The report is sent only if the push initiator requested it in the initial push submission or has requested it for all push submissions.
  • It shall be possible to deliver push data both in an acknowledged and an un-acknowledged manner between the push service and the push recipient
  • It shall be possible for the push initiator to request that only one delivery attempt is made.

In case the push recipient declines a specific instance of push data , it shall be provided with means to indicate whether the push service is allowed to re-send it or not.

In the case that classes of priority and service delivery are not offered an attempt to deliver push data to the push recipient shall be made without unnecessary delay.

5.6 Service Management

The basic principle of service management is "the user is in control".

The user is provisioned with the Push Service by a Network Operator. If a user is provisioned with the push service, the provisioning data shall include a push subscription profile for push service settings and push service preferences. .

The push subscription profile of a Push Recipient shall at least contain:

  • General settings, independent of individual Push initiators
    this may include:
  • Permissible minimal QoS per data format for receiving push data
  • Permissible maximum size of push data permitted to be pushed
  • Permissible charging thresholds to receive push data
  • A mechanism for screening push initiators

NOTE: Parameters may be bearer sensitive.