Abstract
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.
1. Introduction
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 [1]. The main requirement for IMS in conjunction with IP connectivity access network (IP-CAN) is to provide quality of service. Quality of service (QoS) is used to differentiate multimedia offering from traditional Internet services, which in most cases do not provide QoS. In order to provide a mechanism for service-aware QoS control and coherent charging, the Policy and Charging Control architecture is standardized. The Policy and Charging Control (PCC) is a key concept in IMS architecture and it is designed to enable flow-based charging, including, for example, online credit control, as well as policy control, which includes support for service authorization and QoS management [2].
In IMS, the user equipment negotiates with the network the session parameters by means of Session Initiation Protocol (SIP) signaling [3]. The service-related information is delivered to PCC functional entities and is used to form authorized IP QoS data (e.g., maximum bandwidth and QoS class) and charging rules as well as user plane event reporting (e.g., bearer loss recovery, access network change, and out of credit) for any access network [4].
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 [5]. The open access to network functions allows 3rd party applications to make use of network functionality and to receive information from the network through application programming interfaces (APIs). Parlay X Web Services are highly abstracted means for access to network functionality [6]. Parlay X provides APIs for a palette of network functions such as call control, data session control, mobility, messaging, QoS control, and charging.
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 2. The PCC architecture with User Data Convergence is discussed in Section 3. Based on the PCC architectural framework, the requirements for open access to flow-based charging and policy control are summarized in Section 4. The standardized capabilities of Parlay X Web Services for open access to PCC are evaluated in Section 5. In Section 6, some enhancements to Parlay X Web Services are suggested having in mind the identified requirements. The Parlay X interfaces implementation requires mapping of interfaces methods onto network control protocols messages. Such mapping does not exist as the PCC specifications are defined after the specification of Parlay X Web Services. The suggested mapping is sketched in Section 7. The Parlay X interfaces applicability is illustrated by typical use cases. Finally, Section 8 concludes by highlighting the benefits of third party QoS management in IP-based multimedia networks.
2. Related Work
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 [7] propose a multilayered policy control architecture that extends the general resource management function being standardized; this extended architecture gives application developers greater control over the way the services are treated in the transport layer. Good et al. [8] suggest enhancements to the PCC framework that extend the end-to-end inter-domain mechanisms to discover the signaling routes at the service control layer and use this to determine the paths traversed by the media at the resource control layer. Because the approach operates at these layers, it is compatible with existing transport networks and exploits already existing QoS control mechanisms. In [9], it is presented an architecture with policy-based network management focusing on access network optimization while taking service level agreements (SLAs), business objectives, routing rules, service information, user profiles, and platform conditions into account. Zhao et al. [10] present a policy-based radio resources allocation scheme. Different channel allocation algorithms and channel allocation strategies form a series of policies, thus constituting a policy-based channel allocation scheme. A policy-based service provisioning system is proposed [11] in order to provide different classes of services.
The necessity of open access to QoS control is substantiated in [12]. Stojanovic et al. [13] address an open issue of end-to-end service specification and mapping in next-generation networks. A centralized approach has been considered via the third party agent that manages the negotiation process in a group of domains. The authors suggest a general structure of the service specification form, which contains technical parameters related to a particular service request. Bormann et al. [14] extend the mediation layer between the operators core network and the charging system by adding capabilities for online charging control. The authors present a prototype that implements and extends parts of the standardized PCC architecture by the use of the open source JAIN SLEE-based framework Mobicents. Akhatar [15] develops a system and method for providing QoS enablers for 3rd party applications. In one embodiment, the method comprises user equipment establishing a session with a third party application server hosting a selected third party application and receiving from the third party application server QoS information comprising at least one of the pluralities of QoS attributes and configuring a QoS of a radio access network in accordance with the obtained QoS information. The method further comprises activating the radio access network QoS for the selected application and establishing an application session with the third party application server via the radio access network. Koutsopoulou et al. [16] present a platform that extends the existing charging collection information mechanisms and billing systems to provide for advanced and flexible charging mechanisms and pricing policies. An approach to per-flow charging with increased scalability of QoS support charging is suggested in [17].
The Parlay X “Application-Driven Quality of Service” (ADQ) [18], defined in 3GPP TS 29.199-17, allows applications to control the QoS available on user connection. It may be used for dynamic management of QoS parameters available on multimedia sessions.
The Parlay X “Payment” Web Service [19], defined in 3GPP TS 29.199-6, supports payment reservation, pre-paid payments, and postpaid payments. It may be used for charging of both volume and currency amounts, a conversion function and a settlement function in case of a financially resolved dispute.
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.
3. Architecture for Open Access to Policy and Charging Control
A possible deployment of Parlay X Web Services in PCC architecture is shown in Figure 1.
Policy and Charging Control architecture is defined in 3GPP TS 23.203 specifications [20]. The Policy and Charging Rule Function (PCRF) encompasses policy control decision and flow-based charging control functionalities. The Policy and Charging Enforcement Function (PCEF) includes service data flow detection, policy enforcement, and flow-based charging functions. It is located at the media gateway. The Online Charging System (OCS) performs online credit control functions. It is responsible for interacting in real time with the user’s account and for controlling or monitoring the charges related to service usage. Offline Charging System (OFCS) is responsible for charging process where charging information is mainly collected after the end of the session and it does not affect in real time the service being used.
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 [21], then the User Data Repository (UDR) acts as a single logical repository for user data. The user data may, for example, contain information about default QoS parameters that have to be applied each time the user creates a session. Functional entities such as HSS and Application Servers keep their application logic, but they do not locally store user data permanently.
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 [22] is the control protocol in interfaces where authentication, authorization, and accounting functions are required. The control protocol in interfaces where session management is performed is Session Initiation Protocol (SIP) [23]. Lightweight Data Access Protocol (LDAP) and Simple Object Access Protocol (SOAP) are the control protocols used to create, read, modify, and delete user data in the UDR and to subscribe for and receive notifications about user data changes [24].
Note that not all charging-related interfaces and policy control functions are shown in Figure 1 for the sake of simplicity.
In Section 4, we study the functionalities of PCC and UDC in order to determine the requirements for open access to QoS management.
4. Requirements for Open Access to Policy and Charging Control
The PCC includes mechanisms for controlling the bearer traffic by using IP policies.
4.1. Gating and QoS Control
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 2 illustrates the application control on QoS resource authorization for given SIP session.
Functional Requirement 1
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 3.
Functional Requirement 2
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.
Functional Requirement 3
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.
4.2. Usage Monitoring
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.
Functional Requirement 4
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.
4.3. User Data Access
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 4.
Functional Requirement 5
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 5. In a similar way, the 3rd party application may cancel one or several existing subscriptions.
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 6.
Functional Requirement 6
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.
4.4. Charging Control
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).
Functional Requirement 7
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 1. These event types can affect the QoS resource authorization and charging.
5. Evaluation of Parlay X Web Services Compared to Policy and Charging Control
5.1. Parlay X Application-Driven Quality of Service
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 [25] there are indications reported over the Rx reference point by the PCRF to the P-CSCF such as recovery of bearer, establishment of bearer, IP-CAN change, out of credit, and usage report. These indications can not be forwarded to the 3rd party application by the existing definition of the enumerated type QoSEvent.
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.
5.2. Parlay X Payment
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 [26], does not provide notifications about media addition or deletion for a particular session. Location-based charging can be applied by combination of Parlay X “Terminal Location,” defined in 3GPP TS 29.199-9 [27], and “Payment” Web Services.
Table 2 shows the Parlay X Web Services support for advanced charging.
6. Enhancement to Parlay X Web Services for PCC Support
We suggest the following interfaces to be added to the definition of “Application-Driven QoS” Web Service in order to support the PCC functionality.
6.1. New Interfaces for Usage Monitoring
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.
6.2. Enhancement to ADQ ApplicationQoS Interface
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).
6.3. New Interfaces for Access to QoS-Related User Data
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.
6.4. Enhancement to Call Notification Functionality
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.
7. Mapping of Parlay X Interfaces onto Network Protocols
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.
7.1. SIP-Based Interface
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 3 shows the mapping of ADQ interfaces onto SIP signaling.
The getQoSHistory operation does not require any signaling in the network and only some actions in the Parlay X Gateway.
7.2. LAPD- and SOAP-Based Interfaces
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 [24]. The subscription/notification operations related to changes in user data stored within the UDR are transferred by HTTP in SOAP envelopes. Any changes in user profile create an LAPD session. To initiate an LDAP session, the Parlay X Gateway first establishes a transport connection with the UDR and then initiates an LDAP session by sending a BindRequest message. Termination of the LDAP session is initiated by the Parlay X Gateway by sending an UnbindRequest message or by the UDR by sending a Notice of Disconnection message.
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 4 shows the mapping of ADQ interfaces onto LAPD signaling.
7.3. Diameter-Based Interfaces
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.
8. Use Cases for Advanced Charging
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 7.
Figure 8 shows a use case of ADQ interfaces for charging, based on the provided QoS on user session. The 3rd party application uses also the “Payment” interface and “Call Notification” interface.
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.
9. Conclusion
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.
Acknowledgment
The research is in the frame of Project DDBY02/13/17.02.2010 funded by the Bulgarian Ministry of Youth, Education and Science.