User Notifications
Ericsson Service-Aware Policy Controller

Contents

1User Notifications Introduction

2
User Notification Function
2.1Notification Mechanism
2.2Notification Policies
2.3Events and Conditions Triggering Notifications
2.4Notification Message Text
2.5Notification Messages to Multiple Destinations
2.5.1Notification Messages Sent to End Users
2.5.2Notification Messages Sent to External Systems
2.6Notification Message Control
2.7Notification Sending Procedure
2.7.1Notification Queue Management
2.7.2Notification Server Connection Management
2.7.3Connection Error Handling
2.8Load Balancing Mechanism

3
User Notification Traffic Cases
3.1SMS
3.2SOAP

4
User Notification Capabilities

5
User Notification Restrictions

6
User Notification Security

Reference List

1   User Notifications Introduction

The purpose of this document is to provide a description of User Notifications function in the SAPC.

2   User Notification Function

The user notification function enables the SAPC to notify a destination (either an end user or an external system) of certain events related to a subscriber. For example, if the user has exceeded the allowed consumption during a period, the conditions of the service delivery may be affected in the way that this user may have the access to certain services blocked or the available bandwidth restricted. As it may not be easy for the user to track the consumption, a network notification is desirable to let the user know when the remaining volume/time is about to expire or when it is already finished.

Notifications can be sent to end users by SMS and to external systems by SMS and SOAP.

The next figure shows a scenario where SMS notifications and SOAP notifications are sent on response to some events happening at traffic plane. When the 80% of the allowed limit is reached, an SMS is delivered to the end user. When the 100% of the allowed limit is reached, an SMS is delivered to the end-user and a SOAP Notification is sent to the external system.

Figure 1   User Notifications Example

The events that may trigger notifications are configured in the SAPC as policy conditions. Notification messages are sent according to the notification mechanisms and addresses configured when a policy condition is fulfilled.

This function gives end users the chance to take some actions, such as subscribe to new services or changing to a different subscriber group. The end user cannot contact directly any SAPC node but it does through the Customer Care Service. Notifications are also useful for operators that want to use the notification messages to be processed by intermediate systems that could take some actions, for example, reformatting or counting.

2.1   Notification Mechanism

The SAPC can use SMPP and SOAP protocol to send notification messages, see Figure 2:

Figure 2   User Notifications Network View

2.2   Notification Policies

The SAPC allows configuring the conditions that must be fulfilled to trigger a notification by policies. The usage of policies provides a flexible way of using operator defined conditions to perform tasks, as notifications in this case. For such purpose, the SAPC defines a specific policy context and action to be used in configuring notification policies. See more information about how policies are evaluated in the SAPC in Subscription and Policy Management.

The notification policies can be defined per subscriber, per subscriber-group or at a global scope. The SAPC searches all notification policies applicable to the subscriber (the notification policies applicable to a subscriber are those associated to the subscriber, to the active groups which the subscriber belongs to and to the global policies). All the rules included in all applicable policies for the subscriber are evaluated to get the set of notifications to be sent. For such purpose, the SAPC provides a rule combination algorithm which returns the result of all the rules that evaluates to true. Finally, for each selected rule whose condition evaluates positively, a notification is triggered.

Conditions based on date and time can be also included as part of the notification policies and they are evaluated by the SAPC policy engine as other logical condition. When the policy is evaluated, if the time and date condition is fulfilled, the notification is triggered. For example, it is possible to include a time condition in a notification policy to avoid triggering the notification if another condition that triggers the notification happens at night. Unlike other policy types, the SAPC does not trigger any particular action when the time condition changes during the IP session lifetime, if no external stimulus is received.

However, it must be taken into account that some notifications could be sent by the SAPC as a consequence of a reauthorization process triggered by the validity expiration of some other policy, see Section 2.3 for a detailed description of the events producing notification policies evaluation.

2.3   Events and Conditions Triggering Notifications

Notifications in the SAPC are intended as a way to notify one or several destinations about a change in the service conditions applying to an end user, not for a general-purpose notification mechanism. Therefore, only some events under certain circumstances can make the SAPC trigger a notification, that is, only some events trigger a notification policy evaluation in the SAPC.

Basically the SAPC evaluates such policies when some event is received in the SAPC indicating some change in the access session for a user or when some other event is received that makes the SAPC initiate a reauthorization for an active IP session. According to this, the SAPC can only trigger notifications related to subscribers with an active IP session. For example, the SAPC is not able to send a notification related to a subscriber which has changed the profile if there is not any active session for that subscriber.

The SAPC makes notification policies evaluation when one of the following events happens:

Time and date conditions in notifications policies do not trigger sending any notification.

When one of the previous events is triggered, the SAPC performs the selection and evaluation of the applicable notification policies. Notification messages are then sent for those policies that meet the conditions and the notification has not been already sent.

As summary, the notification policies are always evaluated when the SAPC answers a Gx-CCA message or when the SAPC initiates a reauthorization.

Figure 3   Triggers for Notification Policies Evaluation

It is important to highlight that notification policies evaluation is always done after the corresponding message has been sent to the PCEF to avoid affecting the performance.

Notification policies are evaluated by the SAPC in the same way as it is done for the rest of policies, so every condition that can be used in the rest of policies can also be used in the notification ones. In fact, taking into account that the SAPC makes PCC decisions based on such dynamic conditions, operator can decide to configure the same conditions in the notification policies to alert the user whether the SAPC requests the PCEF to enforce such decisions.

Even though the SAPC notifications are intended to notify a destination about a change in the subscriber service conditions, not all the notifications sent by the SAPC have to be linked to some policy enforcement requested by the node. Notifications can be also related to some events received in the IP Session which can have no action in the SAPC, for example, a change in the roaming conditions or the surpassing of intermediate limits.

For the sake of clarity, some typical examples of SAPC notifications are described below.

Figure 4   Bill Shock Prevention Traffic Case

2.4   Notification Message Text

The SAPC also allows the configuration of the text to send in each notification. Using the output attribute of the rules, the operator can send a customized description of the event produced in each case. Configured text for each notification can also include dynamic information by using any of the policy engine supported functions and tags. For example, the text to send in a notification could include the MSISDN.

Multi-language character sets are allowed in the text of the notifications. Both ASCII and Unicode Transformation Format (UTF) can be handled by the SAPC notification mechanisms. The SOAP mechanism supports ASCII 7-bits and UTF-8, and SMS supports ASCII 7-bits and UTF-16 character encoding. For SMS Notifications, owing to SMPP protocol limitations, if ASCII is used, up to 160 characters can be included in the SMS. But, if UTF-16 is used, the amount of characters fitting in an SMS is reduced to 70. If more than 160 or 70 characters respectively are used, then the SMS is truncated into several messages. The number of available characters per segment is 153 and 67 characters respectively.

2.5   Notification Messages to Multiple Destinations

The SAPC allows operator to send notification messages to multiple destinations when an event related to a subscriber occurs. The SAPC supports the following combinations regarding notification destinations and messages:

2.5.1   Notification Messages Sent to End Users

The SAPC allows configuring several MSISDN per each subscriber as destination. When a notification is triggered, the SAPC sends notification messages towards all the destinations configured for such subscriber.

Moreover, it is also possible to configure at subscriber group level that notifications for all subscribers belonging to this subscriber group are to be sent to the MSISDN received in the protocol message for this subscriber, simplifying greatly the configuration of destination addresses for subscribers. If there is at least one destination addressed configured at subscriber level, notifications are not sent to the MSISDN received in the traffic message; notification configuration at subscriber level takes precedence over the notification configuration at group level.

All applicable notifications for a subscriber are always sent to all configured destination addresses.

2.5.2   Notification Messages Sent to External Systems

The SAPC allows operators to send notification messages to one or several external systems. An external system is configured as part of a Notification Receiver. A Notification Receiver groups the destination addresses of the external systems together with the mechanisms to use for sending the notification messages (SMPP or SOAP protocol).

2.6   Notification Message Control

For each subscriber that the notification policies are evaluated over, the SAPC maintains a control of the notification messages sent to avoid that the same notification message is sent several times for that subscriber under the same conditions. When the conditions that have launched certain notification cease, the SAPC triggers the notification again if the conditions are fulfilled any time afterwards.

The SAPC identifies the notification messages sent as follows:

The next figure describes the steps included in the execution of the SAPC notification control:

Figure 5   SAPC Notification Control

If several notification mechanisms are configured for a destination, the SAPC iterates through the notification mechanisms, sending a notification message to every address configured at notification mechanism.

For example, if there is a notification to send to an end user because the usage limit has been surpassed, the event is notified just once to the subscriber receiving the usage reporting when the limit is surpassed for the reporting period, see next figure.

Figure 6   Avoiding Sending the Same Notification Twice

The next time a usage reporting event is received for this subscriber in the same reporting period and the condition for the notification is fulfilled, the SAPC realizes this notification message was already sent for this subscriber, and the event is not be notified again until the accumulated usage is reset at the end of the reporting period and the limit is reached again at next billing period.

Other example could be a notification owing to a roaming condition. If a notification is configured to be sent to an end user and to an external system when a subscriber is out of the home area, notification is only sent once to each destination when the user roams out of this area. Each time the SAPC evaluates again this policy when the user is roaming, the condition is fulfilled but the notification is not sent. When the subscriber is back to the home area and roams again then a new notification is sent.

In the case of notifications about active or inactive subscriber groups, if a notification is configured to be sent to an end user and to an external system when a group becomes active/inactive for the subscriber, the notification is sent only once to each destination when the group becomes active/inactive for the subscriber.

If the same policy for a notification returns a different message in each different evaluation owing to the inclusion of some dynamic text, the SAPC handles them as different notifications. For example, this is the case when a notification should be sent every time a subscriber establishes a new IP session in a roaming scenario; including only static text the SAPC only sends a notification message for the first session. However, including the IP address as part of the text (assuming each different session is using a different IP address) the SAPC handles the same notification as different ones because the resulting text in each case is different. In that case, a notification message is sent every time a new session is established for the subscriber out of the home area.

If the destination address is updated for a destination (list of SMS), the list of sent notifications for such destination is deleted, so the same notification could be sent to the new destination address. This behavior is useful if a notification has been sent to an incorrect address and the destination address is corrected.

2.7   Notification Sending Procedure

2.7.1   Notification Queue Management

Before sending notifications to the notification address, the SAPC schedules the notifications in a queue following a First-In First-Out (FIFO) strategy: There is one single notification queue for the SMS notifications and there is one queue for every external system configured. The SAPC allows up to a maximum number of notifications in every queue, default value 2000 (configured by Ericsson personnel).

The notifications stored in the queue are concurrently sent to the notification address through several connections. The maximum number of concurrent notifications delivered depends the number of connections established with the notification server.

One important issue worth mentioning is the way notifications generated by the Notification Policies evaluation are handled. The SAPC logic may generate so many notifications that surpass the notification delivery capacity of the SAPC. In such case, the SAPC prioritizes the notifications to deliver: Newer notifications take precedence over older notifications.

For this reason, when there are so many notifications to be delivered as consequence of having configured so many notifications in the logic or because the Notification Server cannot cope with the amount of notification traffic, it may happen that some notifications are dropped.

A notification may be dropped when one of the following conditions occurs:

2.7.2   Notification Server Connection Management

Whenever the SAPC sends a notification, the SAPC uses an SMPP / HTTP connection towards the notification address. An SMPP / HTTP connection is established when the first SMS/SOAP notification message is to be sent. Such connection may be reused when delivering further SMS/SOAP notification messages (the same connection may be reused by different subscribers).

The number of established connections which is a dynamic value is directly dependent on the SAPC load at the moment and the network delay between the SMS-Center / SOAP Notification Server and the SAPC.

If all the established connections are in use (this means that the SAPC is using every established connection for sending one notification request) and the number of connections established has not reached the maximum allowed number of connections, default value 50 (configured by Ericsson personnel), the SAPC tries to establish a new connection to the notification address.

If all the established connections are in use (this means that the SAPC is using every established connection for sending one notification request) and the number of connections established has reached the maximum allowed number of connections, the SAPC will not be able to create a new connection to the notification address, and the SAPC inserts this notification again in the FIFO queue (at last position) if there is room for this notification.

Also, the SAPC periodically checks the connection status, default value 60 seconds (configured by Ericsson personnel), releasing connections not used during a certain period, default value 5 minutes (configured by Ericsson personnel), or occasionally used and hanged up (connections established between the SAPC and the notification server with broken status but not correctly released) during at least 30 seconds.

2.7.3   Connection Error Handling

When sending a notification or when attempting to establish a connection to the notification address, the SAPC waits for the acknowledgment during a time-out period, default value 5 seconds.

The SAPC attempts to establish the connection up to a maximum number of times, default value 3 (configured by Ericsson Personnel).

After the connection is established, the notification is tried to send up to the maximum number of retries, default value 3.

If the connection is not established after the connection reattempts, or the connection is established but the notification delivery fails (an error is received at protocol level), the SAPC inserts this notification in the FIFO queue at the last position if there is room for one more notification.

The errors which cause the SAPC to insert the notification in the notification queue are the following:

If all connection establishment attempts or all notification delivery attempts fail, the notification is not delivered and the logging event is issued. A connection is considered broken when no response is received after the maximum number of delivery attempts is reached.

If no connection can be established with the notification address, an alarm is raised. After the alarm is raised, to avoid flooding the notification address with connection establishment attempts raised at every notification delivery attempt, the SAPC attempts to establish the connection at regular time intervals, default value 4 seconds (configured by Ericsson personnel), when new notifications need to be sent. The alarm is cleared once the SAPC successfully sends a notification to the corresponding notification address.

A Server Address is considered unavailable in the following cases:

2.8   Load Balancing Mechanism

The SAPC implements a load balancing mechanism for delivering notification towards a configured Notifications Server. The load balancing mechanism used by the SAPC distributes the delivery of notifications among the set of configured Notification Addresses, belonging to a Notification Server, using the so-called round robin algorithm.

Load balancing mechanism implemented by the SAPC comprises:

The following picture depicts how the round robin algorithm is implemented by the SAPC:

Figure 7   Load balancing mechanism

As precondition, it is assumed that the operator has configured three Notification addresses belonging to the same Notification Address where Notifications are delivered.

3   User Notification Traffic Cases

This chapter explains the interfaces involved in sending user notifications and the common traffic case for notifications.

The notification traffic case can be triggered for two different reasons as described in Section 2.3, the reception of a bearer event from the PCEF and other events producing SAPC reauthorizations.

Next figure describes how the SAPC executes notification control in both scenarios:

Figure 8   Traffic Case for Notifications

As it is shown in the previous figure (steps 6 and 7), the SAPC reauthorization can be triggered by the reception of an external message (for example, a NetConf message updating the user profile or a Gx-CCR for usage reporting when some limit is surpassed) or an internal event as a timer expiration.

It is important to take into account that events triggering reauthorization could affect more than one IP session, therefore notification policy evaluation is performed once per each affected IP session.

The notification control is executed after the Gx-CCA message is sent back to the PCEF. In a SAPC initiated reauthorization scenario, the notification control is performed after the corresponding Gx-RAR message is sent or when the reauthorization process finishes.

The communication towards the corresponding notification server center is described in next sections.

3.1   SMS

If the SMS Notification mechanism is configured, then the SAPC sends the notification message to the configured SMSC center using SMPP protocol version 3.4.

Figure 9   SMS Protocol Binding

The enquire link commands are used to check the connectivity between the SAPC and SMSC. Enquire_link message can only be issued from SMSC and is answered back by the SAPC with resp: "Ok".

3.2   SOAP

SOAP mechanism is configured at Notification Receiver level, as a subscriber is not able to receive a SOAP notification message. SOAP mechanism is intended to send notifications to an external system (web server). As an example, these notifications can be used by the operator for statistical purposes. The SOAP notification is sent to the Web Service End Points configured through the Notification Receiver.

The text in a SOAP notification message must follow the SOAP syntax. The following is an example:

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:xsd="http://www.w3.org/2001/XMLSchema"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-Instance">
 <soap:Body>
    <SAPCNotification>
        <Header>
             <from> SAPC </from>
             <to> Webserver1 </to>
        </Header>
        <Message>
            <MSISDN> 447773609630 </MSISDN>
            <queryString> Quota limit reached, IMSI=123456789 </queryString>
        </Message>
    </SAPCNotification>
  </soap:Body>
</soap:Envelope>

More details about the structure of the SOAP notification message can be found in Configuration Guide for End User Notifications

SOAP uses HTTP as transport protocol. The protocol versions used are SOAP 1.1 and HTTP 1.1. Persistent connections are the default behavior of any HTTP connection in HTTP 1.1, so once a connection is established, several SOAP notification messages may be sent using that connection. For more information, refer to Hypertext Transfer Protocol -- HTTP/1.1, RFC 2616.

Figure 10   SOAP over HTTP Protocol Case

See more details about the structure of the SOAP notification message in Simple Object Access Protocol (SOAP) 1.1, W3C Note 08 May 2000.

4   User Notification Capabilities

Several notification connections per payload processor may be established towards the Notification Server. The number of notification connections established towards the Notification Server depends on the amount of Notifications to deliver.

5   User Notification Restrictions

The following restrictions are applicable to User Notifications

6   User Notification Security

It is supported user and password authentication when sending messages to the SMPP notification servers.

Information contained in notifications may be confidential. For this reason, it is highly recommended to implement IPsec between both parties of the communication channel (the SAPC and the Notification Server).


Reference List

Ericsson Documents
[1] Subscription and Policy Management.
[2] Configuration Guide for End User Notifications.
Standards
[3] 3GPP TS 23.040, V12.2.0 . Technical realization of the Short Message Service (SMS)
[4] Simple Object Access Protocol (SOAP) 1.1, W3C Note 08 May 2000
[5] Hypertext Transfer Protocol -- HTTP/1.1, RFC 2616
[6] The TLS Protocol, version 1.0, RFC 2246
Online References
[7] SMPP Developers Forum.
Legal | © Ericsson España, S