The paper investigates the capabilities of Parlay X Web Services for Policy and Charging Control (PCC) in managing all Internet-protocol-based multimedia networks (IMSs). PCC is one of the core features of evolved packet networks. It comprises flow-based charging including charging control and online credit control, gating control, and Quality of Service (QoS) control. Based on the analysis of requirements for PCC, the functionality for open access to QoS management and advanced charging is identified. Parlay X Web Services are evaluated for the support of PCC, and some enhancements are suggested. Implementation aspects are discussed, and Parlay X interfaces are mapped onto IMS control protocols. Use cases of Parlay X Web Services for PCC are presented.
IMS stands for internet protocol multimedia subsystem which is an architectural framework for service delivery in evolved packet networks. IMS enables various types of multimedia services based on access independency and IP connectivity [
In IMS, the user equipment negotiates with the network the session parameters by means of Session Initiation Protocol (SIP) signaling [
To stimulate service provisioning and to allow applications outside of the network operator domain to invoke communication functions, an approach to opening the network interfaces is developed [
In this paper, we assess the support of existing Parlay X Web Services for access to PCC functions in multimedia networks.
The paper is structured as follows. Some related works are discussed in Section
PCC allows flexible QoS management of ongoing multimedia sessions in case of changing both the access networks and user devices with different capabilities. The PCC can also contribute to seamless service continuity in case of handover between two wireless networks without user intervention and with minimal service disruptions.
Good and Ventura [
The necessity of open access to QoS control is substantiated in [
The Parlay X “Application-Driven Quality of Service” (ADQ) [
The Parlay X “Payment” Web Service [
The Parlay X interfaces are defined before the standardization of IMS PCC. The analysis of PCC functions shows that these interfaces do not cover all QoS management functions that network operator can expose.
A possible deployment of Parlay X Web Services in PCC architecture is shown in Figure
Deployment of Parlay X Web Services in PCC.
Policy and Charging Control architecture is defined in 3GPP TS 23.203 specifications [
The Home Subscriber Server (HSS) contains all subscription-related information needed for PCC rules. If the PCC architecture supports User Data Convergence (UDC) defined in 3GPP TS 23.335 [
Call Session Control Functions (CSCFs) include functions that are common for all services. The Proxy CSCF (P-CSCF) is the first point of contact for user equipment. It deals with SIP compression, secured routing of SIP messages, and SIP sessions monitoring. Serving CSCF (S-CSCF) is responsible for user registration and session management.
Application Servers (ASs) run 3rd party applications that are outside the network operator domain. Parlay X Gateway is a special type of AS that provides Web Services interfaces for 3rd party applications and supports IMS protocols toward the network.
Diameter [
Note that not all charging-related interfaces and policy control functions are shown in Figure
In Section
The PCC includes mechanisms for controlling the bearer traffic by using IP policies.
During the multimedia session establishment and modification, the user equipment negotiates a set of media characteristics. If the network operator applies policy control, then the P-CSCF sends the relevant session description information to the PCRF in order to form IP QoS authorization data. The 3rd party application can be involved in the process of QoS authorization by requesting specific QoS parameters to be applied, modified, or removed. Figure
Application control on QoS during session establishment.
During the SIP session establishment, 3rd party application may require to apply or to modify temporary specific QoS features on user session(s). The required functions include applying temporary QoS parameters, modifying temporary QoS parameters, and removing QoS parameters for a predefined duration (e.g., for session duration). The application logic is activated in case of session initiation, modification, or termination.
In IMS, it is primary the network that decides what kind of bearer the user equipment needs during communication. Having application/service information and based on subscription information and policies, PCRF provides its decision in a form of PCC rules, which are used by the PCEF for gating control.
Any QoS events, such as indication of bearer release or bearer loss/recovery, are reported by the PCEF to the PCRF and P-CSCF. Using the policy control capabilities, the P-CSCF is able to track status of the IMS signaling and user plane bearers that the user equipment currently uses and to receive notifications when some or all service data flows are deactivated. To receive notifications about QoS events the 3rd party application needs to manage its subscriptions for notifications. By using information about bearers and signaling path status, the 3rd party application can improve service execution.
For example, the application can initiate session release on behalf of the user after indication that all service flows assigned to the ongoing session are released, but the P-CSCF has not received session termination request from the user itself. The scenario is shown in Figure
Notification of QoS resource release and application-initiated session release.
The required functions for 3rd party application to manage the QoS event subscription include the following: creating notifications and setting the criteria for QoS; changing notifications by modification of the QoS event criteria; enabling/disabling notifications, and querying for the event criteria set; reporting notifications upon QoS event occurrences.
The 3rd party application should be able to request QoS resource release. Using this function, the application can prevent unauthorized bearer resources after SIP session termination.
The 3rd party application may be interested in the accumulated usage of network resources on per-IP-CAN-session and user basis. This capability may be required for applying QoS control based on the total network usage in real time. For example, the 3rd party application may change the charging rate based on the resource usage (e.g., applying discounts after a specified volume have been reached). Another example is the assignment of a common quota for both fixed and mobile accesses for a limited time period for a defined set of subscriptions. During each session the network elements monitor the common quota, which may be consumed by one or more devices over either the wireless or fixed networks. When a defined percentage of the common quota and/or all common quota has been consumed, the 3rd party application may be notified of the event. When the common quota has been consumed the 3rd party application may block the access to the services.
The 3rd party application should be able to set the applicable thresholds for monitoring. Usage monitoring, if activated, will be performed for a particular application, a group of applications, or all detected traffic within a specific multimedia session. The 3rd party application should be notified when the provided usage monitoring thresholds have been reached.
The 3rd party application may need to retrieve QoS-related user data that are stored in the UDR. For example, the 3rd party application may query the UDR to obtain the QoS-related data from the user profile or its specific components, or it may browse the existing QoS-related data in user profiles in the various UDRs. The 3rd party application may add new QoS-related data in the user profile, remove, or/and modify specific QoS-related data from the repository. It is the responsibility of the Service Provider to define which QoS-related data may be modified or deleted by application providers.
The application access to QoS-related data, stored in the user profile, is depicted in Figure
Open access to QoS-related user data.
The required functions for access to QoS-related user data include the following: querying QoS data in order to retrieve the QoS parameters applied to user sessions by default; creating QoS data in order to add new QoS parameters in user profile; modifying QoS data in order to set new default QoS parameters; deleting QoS in order to erase the QoS parameters from the user profile.
Subscription/notification procedures allow the Parlay X Gateway to get notified when particular QoS data for specific user are updated in the UDR. Using functions for access to QoS-related user data, the 3rd party application can receive up-to-date information. For example, the 3rd application may request notifications about changes in QoS-related data in the user profile as shown in Figure
When the data identified in subscription are changed or when the invoked subscription requests retrieval of all initial values of the referenced data, the 3rd party application is notified as shown in Figure
Subscription to QoS-related user data change.
Notifications upon changes of user data.
To be aware of user’s data changes, the 3rd party application needs functions for subscription management and means for notifications when such QoS-related events occur.
The charging function in PCC supports the following charging models: volume-based charging, time-based charging, time- and -volume-based charging, event-based charging, and no charging. It is possible to apply different rates and charging models (e.g., depending on the user location). The charging system selects the applicable rate based on QoS provided for the service, time of day, and so forth. In case of online charging, the charging actions are taken upon PCEF events (e.g., reauthorization upon QoS change).
In addition to functions for online and offline charging control, notification function is also required. To provide QoS-based charging and flow-based charging, the 3rd party application needs to be notified when some service data flows (e.g., video stream) or all service data flows (i.e., media streams of particular SIP session) have been deactivated, when the session has been terminated, or when access network has been changed.
The event types that should be reported to the 3rd party application involved in QoS management are summarized in Table
QoS-related event types.
Event type | Description |
---|---|
Loss/release of bearer | Loss of bearer that can result in QoS degradation (e.g., the service data flows are deactivated as a consequence). If all the bearers are lost, the application can request QoS resource release |
Recovery/establishment of bearer | Recovery or establishment of a new bearer |
IP-CAN change | The access network providing IP connectivity is changed, which can result in applying specific charging |
Out of credit | The user credit limit is reached |
Session termination | The session terminates normally |
Usage report | Reports that the usage threshold provided by the 3rd party application have been reached |
The “Application-Driven Quality of Service” (ADQ) is a Parlay X Web Service that allows applications to control the QoS available on user connection. Configurable service attributes are upstream rate, downstream rate, and other QoS parameters specified by the service provider. Changes in QoS may be applied either for defined time interval or each time the user connects to the network.
The ADQ ApplicationQoS interface defines operations for applying a new QoS feature to an end user connection. The ApplyQoSFeature operation is used by 3rd party application to request a default QoS feature to be set up on the end user connection, which results in a permanent change in the class of service provided over the end user connection. A default QoS feature governs the traffic flow on the end user connection whenever there are no temporary QoS features active on the connection. The ApplyQoSFeature operation is used by 3rd party application to request also a temporary QoS feature to be set up on the end user connection for a specified period of time. The ModifyQoSFeature operation is used by 3rd party application to alter the configurable service attributes (e.g., duration) of an active temporary QoS feature instance. The RemoveQoSFeature operation is used by 3rd party application to release a temporary QoS feature, which is currently active on the end user connection. Therefore, these operations provide functions required to apply, modify, and remove temporary QoS parameters (e.g., for session duration).
The ADQ Web Service enables applications to register with the service for notifications about network events that affect QoS, temporary configured on the user’s connection.
The ADQ ApplicationQoSNotificationManager is used by 3rd party application to manage their registration for notifications. The startQoSNotification operation is used by 3rd party application to register their interest in receiving notifications of a specific event type(s) in context of specific end users. The stopQoSNotification operation is used by 3rd party application to stop receiving notifications by canceling an existing registration. Therefore, these operations provide functions required to manage the QoS event subscription.
The ADQ ApplicationQoSNotification interface provides the operations for notifying the Application about the impact of certain events on QoS features that were active on the end user connection when these events occurred. The notifyQoS operation reports a network event that has occurred against end user(s) active QoS features. Therefore, this operation provides functions required to report notifications upon QoS event occurrence.
As to 3GPP TS 29.214 [
Currently, not supported by ADQ Web Service functions required for policy control include usage monitoring and resources release.
The Parlay X “Application-Driven QoS” Web service defines operations that allow retrieval of the current status of user sessions, including history list of all QoS transactions previously requested against a user session. As far as the getQoSStatus operation of the ApplicationQoS interface is used by the 3rd party application to access the currently available QoS features on a user session, it is impossible for the 3rd party application to retrieve the configured QoS features stored in the user profile. Further, if the QoS-related data in the user profile have been changed by administrative means, the 3rd party application cannot be notified.
The Parlay X “Payment” Web Service supports payment reservations, prepaid payments, and postpaid payments. It supports payments for any content in an open, Web-like environment. When combined with ADQ Web Service, the “Payment” may be used for charging based on the negotiated QoS. The features for QoS-based charging are restricted to temporary configured QoS parameters but cannot reflect the dynamic QoS change during the session. Flow-based charging is also impossible, as far as the Parlay X “Call notification” Web Service, defined in 3GPP TS 29.199-3 [
Table
Advanced charging functions.
Functions | Parlay X Interface | Operations |
---|---|---|
QoS-based charging | Application-Driven QoS and Payment | Notify QoS event and charge amount, refund amount |
Time-of-day-based charging | Call Notification and Payment | Notify called number and charge amount, refund amount |
Location-based charging | Terminal Location and Payment | Get location and charge amount, refund amount |
Service flow-based charging | Audio Call and Payment | Get media for participant and charge amount, refund amount |
We suggest the following interfaces to be added to the definition of “Application-Driven QoS” Web Service in order to support the PCC functionality.
The UsageMonitoringManager interface may be used by the 3rd party application to manage the usage monitoring for the accumulated usage of network resources on a per-session and user basis. The startUsageMonitoring operation may be used by the 3rd party application to set the applicable thresholds and to activate the usage monitoring. The operation parameters specify the threshold volume and whether the usage monitoring will be performed for a particular application, a group of applications, or all detected traffic belonging to a specific end user session. The stopUsageMonitoring operation may be used by the 3rd party application to cancel the usage monitoring.
The UsageMonitoringNotification interface may be used to report to the 3rd party application when threshold levels are reached. The usageMonitoringReport operation may be used to report the accumulated usage.
A new operation that may be defined for the ADQ ApplicationQoS interface is releaseQoSResources. The operation releases the QoS resources reserved for the user session. It may be used by the 3rd party application to release the authorized QoS resources (e.g., on receiving notification that all bearers assigned to user session are lost).
The UserDataChangeManager interface may be used by the 3rd party application to manage subscriptions for changes of user’s data. The startUserDataChangeNotifications operation may be used by the 3rd party application to subscribe to receive notifications about changes in QoS-related data in user profile, made by network operator or another application. The stopUserDataChangeNotifications operation may be used by the 3rd party application to cancel the subscription for user data changes.
The UserDataChangeNotification interface may be used to report to the 3rd party application any changes in QoS-related data in the user profile. For this purpose the notifyUserDataChange operation is used.
The QoSUserData interface may be used by the 3rd party application to access to QoS-related data stored in the user profile. The interface provides operations to submit, modify, and delete QoS related data. It also provides operations to query for QoS-related data including data identifier, metadata, control data, and QoS data upload date (matching-specific criteria). The application invokes the submitQoSData operation to submit QoS-related data into the user profile. The ADQ Web Service uploads the metadata of the QoS data to the network and the UDR stores the data. The modifyQoSData operation allows a 3rd party application to update previously submitted QoS-related and metadata. The UDR restricts modification to the submitted owner and puts the data into an invisible state until it completes the modification approval. The deleteQoSData operation allows a 3rd party application to delete QoS-related data. The readQoSData operation allows a 3rd party application to fetch the metadata of previously submitted QoS-related data. Request may include multiple data identifiers. The queryQoSData operation allows a 3rd party application to query for QoS-related data that match with specified identifiers.
We also suggest a new operation notifyMediaChange of the CallNotification interface of the Parlay X “Call Notification” Web Service. The notifyMediaChange operation informs the 3rd party application that a media component is added to ongoing session or removed from ongoing session.
In order to make an adequate implementation of Parlay X “Application-Driven QoS” and “Payment” Web Services in the network, the interfaces operations have to be mapped onto messages of network control protocol.
The interfaces between the application server (Parlay X Gateway) and S-CSCF and between S-CSCF and P-CSCF are SIP based. SIP session information (including QoS parameters) is described by means of Session Description Protocol (SDP) and is transferred within the SIP message body. The initial request is sent as SIP INVITE message. The SIP re-INVITE message is used for modification of established session. QoS-related information about SIP session is transferred by INFO message. The management of the subscription to QoS-related events and notifications about QoS-related events are provided by means of SIP SUBSCRIBE/NOTIFY mechanism. The initial filter criteria for application triggering are stored as a part of user data stored and are downloaded to the S-CSCF on user registration.
Table
Mapping overview of ADQ interfaces onto SIP.
ADQ interface operation | SIP message |
---|---|
startQoSNotification | SUBSCRIBE/200[SUBSCRIBE] |
startQoSNotification | SUBSCRIBE/200[SUBSCRIBE] |
notifyQoSEvent | NOTIFY/200[NOTIFY] |
startUsageMonitoring | SUBSCRIBE/200[SUBSCRIBE] |
stopUsageMonitoring | SUBSCRIBE/200[SUBSCRIBE] |
usageMonitoringReport | NOTIFY/200[NOTIFY] |
applyQoSFeature (temporary) | re-INVITE |
modifyQoSFeature | re-INVITE |
removeQoSFeature | re-INVITE |
getQoSStatus | INFO |
releaseQoSResources | BYE, 200[BYE] |
The getQoSHistory operation does not require any signaling in the network and only some actions in the Parlay X Gateway.
All procedures related to querying or to deleting data from the UDR and to creating or updating data within the UDR are controlled by LDAP as specified in 3GPP TS 29.335 [
In order to allow the application to relate a number of operations such as Create, Delete, and Update and to have them performed in one unit of interaction a transaction is used.
The Parlay X Gateway makes subscription for notifications about user data changes on behalf of 3rd party application by Subscribe messages. Subscribe request messages use the HTTP Post method and contain a SOAP message envelope. Subscribe response messages are coded as HTTP response message and contain a SOAP envelope. The Parlay X Gateway is notified about changes in QoS related data in user profile by Notify messages. Notify request messages use the HTTP Post method and contain a SOAP message envelope. Notify response messages are coded as HTTP response message, and contain a SOAP message envelope.
Table
Mapping overview of the suggested ADQ interfaces onto UDC protocols.
ADQ interface operation | UDC protocol message |
---|---|
submitQoSData | LDAP AddRequest/LDAP AddResponse |
modifyQoSData | LDAP ModifyRequest/LDAP ModifyResponse |
deleteQoSData | LDAP DelRequest/LDAP DelResponse |
readQoSData | LDAP SearchRequest |
queryQoSData | LDAP SearchRequest/LDAP SearchResultEntry, SearchResultReference, and SearchResultDone |
notifyUserDataChange | HTTP Post/HTTP Response |
startUserDataChangeNotifications | HTTP Post/HTTP Response |
stopUserDataChangeNotifications | HTTP Post/HTTP Response |
When User Data Convergence is not supported, the Parlay X Gateway is connected to the HSS. The protocol between the Parlay X Gateway and HSS is Diameter, and the 3rd party application access to user data is through Diameter commands.
To perform any changes in user data the Parlay X Gateway opens a Diameter dialogue. All 3rd party application initiated updates in user data are reflected in the HSS through the Diameter commands Profile-Update-Request/Answer (PUR/PUA). The access to user data is provided by the Diameter commands User-Data-Request/Answer (UDR/UDA).
The Parlay X Gateway subscribes to receive notifications on behalf of the 3rd party application using Diameter commands Subscribe-Notifications-Request/Answer (SNR/SNA). Push-Notification-Request/Answer (PNR/PNA) commands are used to notify the Parlay X Gateway about events of interest.
The Rx reference point is defined between the P-CSCF and the PCRF. It is used for policy and charging control. In the context of PCC, the Diameter Authentication-Authorization-Request/Answer (AAR/AAA) commands are used to deliver SIP session information. The Re-Authorization-Request/Answer (RAR/RAA) commands report events related to QoS. The Session-Termination-Request/Answer (STR/STA) commands are used to release the resources, authorized earlier for a SIP session. The Abort-Session-Request/Answer (ASR/ASA) commands are used to provide information that all bearer resources, allocated to SIP session, are released.
To illustrate the usage of Parlay X interfaces for advanced charging we provide two use cases for service flow location-based charging and QoS-based charging.
Ann has a prepaid subscription. Shopping at a mall she decides to call Peter to invite him to a party. While discussing the details, Ann is hesitating which dress to choose and adds a video component to let Peter help her. Because of the high level of traffic load, the video stream is more expensive than usual at premises of the mall. The charging application knows that Ann is a prepaid user and, therefore, it needs to obtain permission from the online charging system (OCS). The OCS processes the credit control request and uses internal rating function to determine the rate of the desired service according to the service-specific information provided by the IMS entity if the cost was not given in the request. Then, OCS reserves an initial amount of money from Ann’s account and returns the corresponding number of minutes Ann is allowed to talk. The charging application requests Ann’s location when she decides to modify the media session including the video component. As Ann is in an area with scarce resources, the application determines that different charging rate has to be applied. The credit control request with charging rate information is sent to the OCS, which reserves the additional amount of money and returns the corresponding number of resources. When the minutes granted to Ann have been consumed or the service has been terminated, the OCS is informed and deducts Ann’s amount from the account. The sequence diagram is shown in Figure
Use case of location-based charging.
Figure
Use case of QoS-based charging.
In the scenario, Peter is at the stadium enjoying a football match. Peter decides to share the emotion with his friend who is away. Peter wants to send to him a video of the football match. However, the current service offering does not support the requested rate and hence it is required a temporary bit rate upgrade for the duration of the video. The QoS management application invokes the applyQoSFeature to apply new QoS parameters to the user session, specifying the higher bit rate and the duration the temporary QoS parameters should be applied. Assuming that the network allows the requested bit rate, the user’s rate will be increased to the rate requested by the application for the specified duration. The application subscribes to notifications of events related to QoS available on user session. During the multimedia session the QoS goes down, so the application is notified and generates charging information based on the delivered QoS, thus correcting the requested one.
The open access to QoS management functions allows for the 3rd party applications dynamic control on QoS available on user sessions. The required functionality for open access to QoS management might be derived from the functional architecture of policy and charging control in the IP Multimedia Subsystem. The access to QoS control, gating control, flow-based charging, and user data management provides 3rd party applications with flexibility in QoS management.
So far standardized application programming interfaces do not support the entire policy and charging control functionality that network operator can expose. The evaluation of the interfaces for QoS management accessed by the 3rd party applications substantiates the need of further extension of management functions in order to provide greater flexibility in expressing communication details.
If the Parlay X approach is adopted in interface definition, besides the access to dynamic QoS control, 3rd party applications can benefit from other APIs that expose a variety of network functions. Implementation issues of the Parlay X APIs provisioning impact on the interfaces toward the network, which are left unconstrained. So, any extension of the functionality of QoS management interfaces has to be mapped onto IMS control protocols like SIP, Diameter, LDAP, and SOAP. The Parlay X Gateway has to incorporate state machines representing the 3rd party application view of interface objects that are extended with respect to the added functionality and the control protocol state machines.
The extension of the open access to QoS control adds more flexibility in resource management as far as the QoS provisioning is one of the main requirements to the IMS. Possible stakeholders that may benefit from Application-managed Quality of Service include Value Added Service providers for QoS management and 3rd party provided services that run on application servers on behalf of particular user groups.
The research is in the frame of Project DDBY02/13/17.02.2010 funded by the Bulgarian Ministry of Youth, Education and Science.